#6112 DREAMWEB: Crash after Intro on OS X

[Saint of Killers]

ScummVM 1.5.0 stable
OS X 10.8.0
The game crashes right after the third intro sequence (the credits and tiles) with this error on console

User picked target 'dreamweb-it' (gameid 'dreamweb')...
Looking for a plugin supporting this gameid... DreamWeb engine
Starting 'DreamWeb'
scummvm(1294,0xac617a28) malloc: *** error for object 0x8922cb4: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Bus error: 10

Any other game seems working fine

[digitall]

aculotarpa: Thank you for filing a bug report. Please supply the following to help us debug this:
1. Please confirm your Dreamweb release version and language? The dreamweb-it seems to indicate that this is detected as an Italian language variant? Is this correct?
2. Please attach a text file to this bug with a file listing of your Dreamweb datafiles along with file MD5sums. The output of a tool such as http://md5summer.org/ would be optimal.
There are other tools available. See:
http://wiki.scummvm.org/index.php/Reporting_unknown_MD5_checksums
Note: We need the full file md5sum checksums, rather than the restricted size ones used for detection... so simple "md5sum *" would be fine.

This is to allow us to unique identify your version, work out if this is due to a corrupted datafile or variant version and identify the datafiles which vary.
3) Running ./scummvm -d 10 at the command line and attaching the log file output of debug and warning as a text file may also be useful.

[Saint of Killers]

[Saint of Killers]

Yes, it's Dreamweb Floppy Italian version.
Attached you'll find the md5 checksum and the detailed log file, I hope it's all correct.

[digitall]

aculotarpa: Thank you for the information.

I have just realised that you are reporter of bug #3523338 - "DREAMWEB: Incorrect Charset in Italian Version" which was fixed 2012-05-04, but not confirmed by yourself.
http://sourceforge.net/tracker/?func=detail&aid=3523338&group_id=37116&atid=418820

Could you confirm the following:
1. Did this fix solve the problem for you and allow you to play Dreamweb with these datafiles?
2. If this has been working for you with recent nightly builds from Buildbot?
3. If this broke when you upgraded to OSX 10.8.0 or when you updated a ScummVM version?

i.e. This will tell us if this is a regression in ScummVM, did we never fix the issue correctly or if OSX 10.8.0 has broken some API....

The md5sums you attached match the ones previously supplied, but are completely at variance with all the English Floppy/CD versions I have, so having to debug at a distance.

[digitall]

aculotarpa: One other thing to try. Please try running your Dreamweb ITA Floppy version with ScummVM v1.5.0 on a Win32 or Linux box and see if the same problem or similar crash is observed? i.e. trying to work out if the bug is caused by your Dreamweb ITA version on all platforms or just on OSX.

[Saint of Killers]

I'm sorry for the lack of comments on the previous bugfix (bug #3523338), but the ticket was closed before I had the possibility to confirm.
Anyway, the italian version displayed the right characters since then

Regarding this bug (#3553538), I can confirm my version of the game works fine on Win32 and Wii 1.5.0 stable builds.

I did'nt used ScummVM in the last weeks, the svn from early july worked fine. I only checked the stable build since I upgraded to 10.8.0 some days ago and noticed Dreamweb was not working reading a post in the forum, so I cannot confirm when the problem appeared.

[digitall]

OK Thanks, so this does appear to be an OSX specific issue. Unfortunately, I don't have any OSX boxes, so this may take a while to debug. Please stand by.

[Anonymous]

With SCUMMVM 1.5.0 on OS X 10.8, Dreamweb US CD crashes immediately after the intro reporting the following:

User picked target 'dreamweb-cd-us' (gameid 'dreamweb')...
Looking for a plugin supporting this gameid... DreamWeb engine
Starting 'DreamWeb'
scummvm(769,0xac1c2a28) malloc: *** error for object 0x274fcb4: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Bus error: 10

[digitall]

Chilijohn: Thank you for confirming this. Definately an OSX specific issue, rather than Dreamweb version dependent.

aculotarpa / Chilijohn: Can you confirm if you see the same problem with the current v1.6.0git development build?:
http://buildbot.scummvm.org/builds.html

[Saint of Killers]

Yes, same error at same point with

ScummVM 1.6.0git240-g52a1a6e (Aug 3 2012 04:14:32)
Features compiled in: TAINTED Vorbis FLAC MP3 SEQ TiMidity RGB zLib

BUT
I have tried to run the game with a 3x scaler and it crashed at the same point but returning the following error

WARNING: SDL_SetVideoMode says we can't switch to that mode (No video mode large enough for 640x480)!

Running the game with OpenGL renderer Works fine!!

Maybe, it's an issue with SDL under 10.8.0

[digitall]

OK Thanks... Again, I don't have an OSX box and few of the developers do, so we will need you to provide sufficient debug information to pin this down.

1. Could you run the development version of ScummVM under gdb i.e. gdb ./scummvm. At the command line, just type "run" then play the game to the crash, the gdb console will appear again, then type "bt" (backtrace) and post the result here. If more than 5-10 lines, please attach as a text file.

See https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/gdb.1.html for further details on usage.

2. Running this under Valgrind would provide a better and more complete trace: http://www.valgrind.org/
This is supported on OSX, but it may need some work to put it together. There may be a port in FinkPorts or similar.
If you manage to do this and get output, please attach as a text file.

[Thierry Crozat]

I started looking at this. Here is what I found (with the french version):
1. Release 1.5.0 crashes on both MacOS X 10.6 and MacOS X 10.8. So this is not specific to 10.8. (the error is the same as the one reported above).
2. With the daily build from builbot (1.6.0git240-g52a1a6e) it does not crash on either system.
3. With my own 1.6.0git build it does not crash either.
4. With my own 1.5.0 build it does not crash either.

So the only version I could reproduce the crash with is the 1.5.0 release build on our download page. I suspect there is an issue with that build, not with our source code.

For my own builds I am using SDL 1.2.14 on my OS X 10.6 box and 1.2.15 on the 10.8 box.
For my 1.5.0 build I have tried both with and without --enable-release with the same result (it works in both cases).

[Thierry Crozat]

And by the way if you really want the backtrace, here it is. But since I can only reproduce it with the release build it does not look very useful.

#0 0x002a8842 in ?? ()
#1 0x0029c4b2 in ?? ()
#2 0x0029d31f in ?? ()
#3 0x0029d381 in ?? ()
#4 0x002a083d in ?? ()
#5 0x00295858 in ?? ()
#6 0x00006573 in ?? ()
#7 0x00007296 in ?? ()
#8 0x000049e7 in ?? ()
#9 0x00be0c1b in ?? ()
#10 0x97c62d92 in __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 ()
#11 0x9a550481 in ___CFXNotificationPost_block_invoke_0 ()
#12 0x9a49bb5a in _CFXNotificationPost ()
#13 0x97c4b8c8 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#14 0x962470ce in -[NSApplication _postDidFinishNotification] ()
#15 0x96246d88 in -[NSApplication _sendFinishLaunchingNotification] ()
#16 0x96243cef in -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] ()
#17 0x96243804 in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] ()
#18 0x9244c628 in -[NSObject performSelector:withObject:withObject:] ()
#19 0x97c6637a in __76-[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_0 ()
#20 0x97c65ed1 in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#21 0x97c65cce in _NSAppleEventManagerGenericHandler ()
#22 0x9a3895b3 in aeDispatchAppleEvent ()
#23 0x9a35fdde in dispatchEventAndSendReply ()
#24 0x9a35fc9d in aeProcessAppleEvent ()
#25 0x94092394 in AEProcessAppleEvent ()
#26 0x9623fdfd in _DPSNextEvent ()
#27 0x9623f28c in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#28 0x962356dc in -[NSApplication run] ()
#29 0x00be1388 in ?? ()
#30 0x00002d02 in ?? ()
#31 0x00002c29 in ?? ()

[Saint of Killers]

Ok, fisrt I have updated to

ScummVM 1.6.0git244-gde752a5 (Aug 5 2012 04:14:11)
Features compiled in: TAINTED Vorbis FLAC MP3 SEQ TiMidity RGB zLib

- Playing in window mode works at any scale factor.
- In fullscreen mode it works at 1x or 2x (any scaler) but doesn't fullfill the screen (black frame all around).
- In fullscreen at 3x (any scaler) it crashes.
- In OpenGL works always fullfilling the entire screen at correct 4:3 ar (the software renderers always give stretched image, disregarding the options in graphic tab)

I'm sorry, but I was not able to produce a backtrace using gdb, the use of Developers Tools goes far beyond my skills :(

[digitall]

aculotarpa: That is probably a different issue due to user error.

Try run ScummVM from a command line and you will then be able to see any error messages on "crash".
I would suspect that ScummVM is shutting down with an error as it can't find a large enough graphics output i.e.
As applying 3x Scaler to 640x480 means the output window would be 1920x1440 and I doubt your real screen can do that resolution at fullscreen. If it is crashing, that is still probably due to this.

[digitall]

Chilijohn / aculotarpa:

GDB is not hard to use. Please can you run a version which exhibits the crash under it and get a backtrace.

This is purely a case of running "gdb ./scummvm" at a command line, then typing "run", play the game to the crash and then type "bt" at the gdb command line and copying the messages produced to a text file and attaching to this bug.

[Thierry Crozat]

aculotarpa: Fullscreen 3x for me displays an error message in ScummVM at the start of the intro: "Could not switch to resolution: '640x480'." When clicking on OK ScummVM closes. Do you have a different behaviour?

[digitall]

Chilijohn / aculotarpa: Apologies. I have spoken to criezy and I was unaware that despite OSX being billed as an open Unix platform, it does not come bundled with GCC/GDB or other compiler tools... and installing XCode is a PITA requiring a developer account from Apple (which though free to get). This makes debugging on OSX a PITA and probably explains why we have a number of open and undiagnosed bugs on OSX.

Please see http://www.finkproject.org/ which provides the ability to install open tools such as GCC and GDB in a simple manner without requiring banging your head on Apple's control freakery and paranoia.

[Thierry Crozat]

Running valgrind on a nightly build doesn't give any error. On the 1.5.0 release it gives me the following just before the crash. Since there is no debug symbols I am afraid it is not very useful however.

==46092== Invalid free() / delete / delete[] / realloc()
==46092== at 0x123743A: free (vg_replace_malloc.c:430)
==46092== by 0x2A884C: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x29C4B1: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x29D31E: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x29D380: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x2A083C: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x295857: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x6572: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x7295: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x49E6: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0xBE0C1A: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x4E67E5B: _nsnote_callback (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==46092== Address 0x1782bb94 is 117,940 bytes inside a block of size 134,780 alloc'd
==46092== at 0x1237581: malloc (vg_replace_malloc.c:266)
==46092== by 0x18F8616: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==46092== by 0x293F8E: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0xAB82C8: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x5FA1: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x7295: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x49E6: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0xBE0C1A: ??? (in ScummVM 1.5.0.app/Contents/MacOS/scummvm)
==46092== by 0x4E67E5B: _nsnote_callback (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)
==46092== by 0x1BF7762: __CFXNotificationPost (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==46092== by 0x1BF7169: _CFXNotificationPostNotification (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation)
==46092== by 0x4E5CC4F: -[NSNotificationCenter postNotificationName:object:userInfo:] (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation)

[Anonymous]

I can confirm that the 8/7/2012 nightly build is working with Dreamweb CD US and I see the same crash using 3x scalers in Fullscreen Mode, though not Windowed, on my 1440x900 MacBook Pro. Also there are two different errors generated for the 3x & HQX 3x and AdvMAME 3x:

3x / HQX 3x: "Bus Error: 10"

AdvMAME 3x: "WARNING: SDL_SetVideoMode says we can't switch to that mode (No video mode large enough for 960x600)!"

Regarding screen rendering, the 2x modes are letterboxed with what looks like a 320x200 game area inside a 320x240 frame with or without Aspect Ratio Correction enabled. OpenGL corrected has only a vertical stretch while uncorrected fills the screen without significant distortion, but looks a bit rough at 1440x900 without filtering.

[Saint of Killers]

I'd want to add, any other game with 640x480 resolution (Monkey 3, Brocken Sword, Discworld 2 etc...), when launched with a 3x scaler, automatically fallbacks to a lower working scaler. I suppose Dreamweb should do the same.

[Torbjörn Andersson]

Slightly off topic, but most (all?) game engines assume that the default scaler only applies to low-resolution games. Setting a 3x scaler specifically for a high-resolution game should work, though.