#6176 closed defect (fixed)
TONY: Assertion in mpal/memory.cpp on launching
| Reported by: | raziel- | Owned by: | digitall |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Tony |
| Version: | Keywords: | ||
| Cc: | Game: | Tony Tough |
Description
ScummVM 1.6.0git (Oct 31 2012 16:18:17) Features compiled in: Vorbis FLAC MP3 RGB zLib Theora AAC FreeType2
I get this and a black screen (and a crash of the system) when launching the game.
assertion "item->_id == BLOCK_ID" failed: file "engines/tony/mpal/memory.cpp", line 82
Tony Tough and the Night of Roasted Moths (Windows/English)
AmigaOS - PPC - SDL - BE gcc (GCC) 4.2.4 (adtools build 20090118)
Ticket imported from: #3582583. Ticket imported from: bugs/6176.
Attachments (4)
Change History (16)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
raziel_: Can you please attach a text file containing a file listing with full file md5sums of your Tony datafiles to this bug? This is so we can eliminate datafile issues i.e. corruption, bad dump, variant version as a cause of this...
comment:3 by , 12 years ago
With pleasure.
I don't know which files are needed so i did a complete md5sum list the files in root and the files in the roasted/ subdir have sizes attached.
If you need all the sized, please let me know and i'll update them
comment:4 by , 12 years ago
I suspect that this is indeed a Big Endian issue. The assert in question was added in because the original code frequently intermixed pointers cast as longs with memory block handles, and I wanted to make sure the right method was being called for a given value.
The most likely cause of the error That you're getting now is that some bit of code isn't yet endian safe, and is causing a memory overrun/corruption. Because if it was just an issue with the wrong method type being called, it would be identical across all systems.
Ideally we'd need someone with a BE system and Valgrind (or similiar tool), to try and identify points where overruns are occurring, and use that as a basis for identifying non-endian safe code. Either that, or manually going through all the loading code to try and identify points that are missing endian wrappers.
In either case, not an easy job. :(
comment:6 by , 12 years ago
dreammaster: Thank you for this analysis. Since very few of us have a working BE machine to test this on, and those that do tend to be slow or have issues with debug channels i.e. Wii, I was wondering if we could use a OS level VM solution towards investigating this and other BE/Endian issues i.e.
We use http://gxemul.sourceforge.net/, QEMU (http://wiki.qemu.org/Main_Page) or similar Machine level/OS level VM capable of emulating a CPU different from the host i.e. emulated PPC on x86 machine, then run say PPC Linux in this and then valgrind and ScummVM on that. The result should provide the required information / valgrind traces and though not quick, shouldn't be painfully slow on a modern Desktop CPU.
comment:7 by , 12 years ago
dreammaster: Have managed to get this solution working. Now have a QEMU VM emulating a PPC (BE) machine on a Win32 x86 LE host machine, running Debian PPC Squeeze. Have replicated the bug with ScummVM git master and got a gdb backtrace, which I am attaching as a screenshot.
by , 12 years ago
| Attachment: | Debian PPC GDB Backtrace.jpg added |
|---|
Backtrace from QEMU PPC Emulation demonstrating bug
comment:8 by , 12 years ago
| Component: | --Unset-- → Engine: Tony |
|---|---|
| Game: | → Tony Tough |
comment:10 by , 12 years ago
Attaching patch from wjp. This has corrected the initial assertion/segfault in BE, but the graphics output is incorrect wrt. colors (Frankly, it is psychadelic!).
Attaching a jpg of this... Possibly a graphics format cross blit issue or endian issue in Graphics Loading?
comment:11 by , 12 years ago
Image loading bug fixed in 43520ce4f38c632eb438c6cada9224dad90e8621 supplied by wjp and fuzzie.
I am going to close this now as the original reported bug is fixed.
Raziel^: You should now be able to do a full playtest through the game on your BE machine. If you could do this and report any further issues, that would be optimal. Thanks.
comment:12 by , 12 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
This piece of code contains the assertion triggered: /** * Returns a size of a memory block given its pointer */ uint32 MemoryManager::getSize(MpalHandle handle) { MemoryItem *item = (MemoryItem *)handle; assert(item->_id == BLOCK_ID); return item->_size; }
I don't see this issue when starting the engine on Linux x86_32 with latest Git master, and a review of the engine code shows a number of "read(" calls which are known to be tricky wrt. endian issues, so I suspect that this is a real issue on Big Endian. http://wiki.scummvm.org/index.php/Tony/TODO does list that this is not tested sufficiently yet.