Menu
▾
▴
#5732 DC: Toonstruck demo launch error
Platform: Dreamcast
ScummVM Version: dc-master-c86a6c46 (Dev)
Plugin Engine: Toon
Game: Toonstruck DOS demo (German)
Hello.
I recently attempted to create a Dreamcast disc, with the newly added Toon engine support. So I downloaded the Toonstruck demo, and the 1.3.0 stable plain files for the Dreamcast. After creating the disc image, I loaded it up in the system, where it loaded to the game selection menu. I liked the verbose message on what plugins were being loaded by the way ;) .
Well what happened was that after selecting the detected demo from the menu, the Dreamcast crashes with a reboot. I then moved on to trying out the Dev version I used for this report. As it does the exact same thing, I was unable to pull up the ScummVM version info from the in-game menu, so I just included the archive name.
Since there isn't any debug mechanism for Dreamcast crashes, I've uploaded a logfile output by running the image through NullDC here.
http://pastebin.com/tTpzkbdj
NullDC Log
Attached log as pastebin may wipe this before the DC maintainer gets to looking at this bug.
Looks like a null-pointer dereference, but the log doesn't provide enough information, so I'll need to try to reproduce it myself...
Not sure if the demo needs the toon.dat supplementary datafile.. Probably does, if so, then if this is missing and error handling is not good, this may result... If you can't replicate this immediately, this might be the first thing to check.
toon.dat is needed, but if you don't have it there is a dialog saying "You're missing the 'toon.dat' file. Get it from the ScummVM website", and then after an "unknown error" you get back to the gane selector.
Now, with the 'toon.dat' file, the demo starts and gets to the menu screen. But when you select "Neues Spiel Starten", the demo crashes. This is actually a detection bug, reproducable on e.g. Linux/SDL.
The problem is that the game "toon" is deteced both in INSTALL and in INSTALL/MISC. But if you choose to start it from INSTALL/MISC, it will fail to open INSTALL/ACT1/ZCROSS/ZCROSS.PAK, and crash (due to poor error handling). Only if the game is started from INSTALL will it work. So detecting it in INSTALL/MISC is actually a bug.
Although after making a workaround for the detection bug, it kind of looks like this game won't run in 16M RAM... :-6
I'd suggest that your refer both of those issues to the main engine developer for Toon, SylvainTV.
Halved Toon pathfinding heap memory usage in d035bcae826e4212ddda531633d3cf0666d57109. This may allow this to work correctly now.
marcus_c: Is this still occuring with the latest nightly development builds?
I don't know about the nightlies specifically, but if I build master with the same configure options, I am able to select the demo, choose "Neues Spiel Starten", and walk around on the first screen. If I follow the right path and walk onto the next screen however, ScummVM quits with what I assume is an uncaught exception (abort is called from inside unwind-dw2.c).
marcus_c: Is this still occuring with v1.5.0git development builds?
Just that this might have been fixed by commit 24e50eb218db5de3bad806737cba247798112a2a
If not, then this bug can be closed.
If it is still occuring, can you replicate this with a Desktop build, preferably for Linux x86_32 from latest Git master?
tdhs: Yes, exact same behaviour (abort in unwind-dw2.c when following the rightmost path to the next screen) on git master. 24e50eb seems unrelated since it targets a bug specific to the Russian localization, and the demo is in German.
I also traced the exception this time, and it's the new operator throwing a std::bad_alloc beacuse malloc() returned NULL. So it's an out of memory error yet again.
marcus_c: Thank you for confirming the cause. Not surprising since the Dreamcast only has 16M...
If you can identify the specific offending malloc() call in Toon, I can look to see if we can reduce the memory usage...
But I would like your view as the DC porter as to whether we should instead close this bug as postponded and work more generally on documenting on the Dreamcast wiki page which engines/games are supported and which are not due to memory limitations, with a view towards checking if any of the borderline cases can be fixed by minor changes to stop unecessarily large allocations etc.
The offending new is
_gridTemp = new int32[_width*_height];
in PathFinding::init trying to allocate 2M when there is less than 1M of free heap remaining.
Well, I dunno, looking at the WIkipedia article for Toonstruck, it seems that the minimum requirement for the original engine was an 8MB system. So that means there was 8MB in total, for DOS, the engine, any game data, and engine workspace. When I'm in the launcher in ScummVM on the DC, with not only the toon engine loaded but also the much larger scumm engine, there is still >8.5MB of pristine unfragmented heap space available, that can be used for game data and engine workspace exclusively. So it can't be impossible to make it work. Don't know how much tweaking would be necessary though. But if it's just one or a few things using excessive amounts (such as the pathfinder, which keeps popping up here :) it might be feasible.
marcus_c: Have commited a number of RAM reduction fixes to the Toon engine as of 57d34d2576d38a2820afeae0ba860dc863a34b08
Based on desktop memprof, these save around 2 Megabytes, this should allow the Toon Demo to work correctly.
Since I now have a DC and debug cable, I will look at this to see if I can locate any other leaks or memory issues.
Nice work! It's now possible to enter the second room, with 640K (ought to be enough for everyone!) free memory. (I'm just looking at brk() here, there may be additional free memory in fragments.) Still the game crashes on out of memory if you enter the department store though. Feels like we are getting there one room at a time... ;-)
Hm, actually, if I build ScummVM without any static plugins, and load only the TOON plugin, then I can enter the department store as well, with almost 2 MB to go. After starting a conversation with the salesdog however, the available memory trickled down to 0 and the game crashed before I ran out of dialogue options. Maybe some kind of leak in the VO handling?
marcus_c: I doubt the leak is in the engine code as I have profiled most engines on Linux x86_32 using Valgrind to find and close any leakage, including Toon.
With a recent DC buildbot v1.5.0git, SCUMM plugin and The Dig, I also observed an apparent leakage via the "memory left" debug serial output as dialog progressed, so I think the issue is in the DC backend... possibly in the audio output.
If you could pop into the #scummvm IRC channel on freenode at some point, we can talk about this (My nick is digitall) as conversing via bug tracker is a bit of slow pain and not really the correct medium! :)
I did pop into #scummvm, but you were not there. :-)
The DC backend does not use dynamic memory (except for the screen buffer, which is (re)allocated only on resolution change), so it's rather impossible for it to leak. :-)
Anyway, I found that I don't actually need to talk to the dog, just standing in the room for a while causes memory consumption to go up. I did some memory profiling, and found that between the point where I had just entered the room (and stood there for like 5 seconds) to where the crash happens, the memory consumption of PakFile::getFileData had gone up by 550K, and the memory consumption of Animation::loadAnimation had gone up by 1.2M.
I added some traces to the Animation class, and found that the animations WPTWST1.CAF, WFPUNCH1.CAF, and WPTONG1.CAF, all rather large, are loaded dynamically, but then not freed when the animation has stopped playing. I assume they are freed when you leave the room or quit the engine or something, which is why this leak would not be caught by valgrind.
marcus_c: Yes, I unfortunately missed you by a few hours.
Well, no mallocs apart from that, but a fair number of "new", but yes, not as likely as engine memory usage.
I agree that Valgrind will only catch leaks at exit, rather than running leaks which are then cleaned up.
If you have some time this weekend, then I hope we can chat on #scummvm in realtime as I need a little help with cross compiler setup, and would prefer to discuss in realtime! :)
If you want to set a specific time, please drop me an e-mail at <my IRC nick>@scummvm.org FYI My local TZ is UTC+0