Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#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


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)

TT_md5sum.txt (4.5 KB ) - added by raziel- 9 years ago.
md5sums of data files
Debian PPC GDB Backtrace.jpg (74.8 KB ) - added by digitall 9 years ago.
Backtrace from QEMU PPC Emulation demonstrating bug
tony_be.patch (581 bytes ) - added by digitall 9 years ago.
Patch for initial BE assertion from wjp
PPC BE Image With Patch.jpg (120.4 KB ) - added by digitall 9 years ago.
PPC BE Incorrect Colors

Download all attachments as: .zip

Change History (16)

comment:1 by digitall, 9 years ago

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. does list that this is not tested sufficiently yet.

comment:2 by digitall, 9 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 raziel-, 9 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

by raziel-, 9 years ago

Attachment: TT_md5sum.txt added

md5sums of data files

comment:4 by dreammaster, 9 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:5 by raziel-, 9 years ago

Yay to my endian unsafe system :-(

comment:6 by digitall, 9 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, QEMU ( 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 digitall, 9 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 digitall, 9 years ago

Backtrace from QEMU PPC Emulation demonstrating bug

comment:8 by bluegr, 9 years ago

Component: --Unset--Engine: Tony
Game: Tony Tough

comment:9 by wjp, 9 years ago

Looks like GLOBALS._lpResources is the likely culprit.

comment:10 by digitall, 9 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?

by digitall, 9 years ago

Attachment: tony_be.patch added

Patch for initial BE assertion from wjp

by digitall, 9 years ago

Attachment: PPC BE Image With Patch.jpg added

PPC BE Incorrect Colors

comment:11 by digitall, 9 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 digitall, 9 years ago

Owner: set to digitall
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.