Menu ▾ ▴

#6476 DC: Soltys (CGE) crashes at start up

Soltys
closed-fixed
Marcus Comstedt
Unknown Crash/Other (1602)
7
2014-01-17
2013-12-30
xvallejo
No

ScummVM crashes when Soltys starts (Dreamcast reboots).

ScummVM version: any with Soltys support (last tested: 1.6.0 stable )
Game: Soltys (any version, tested with Polish and Spanish) downloaded from ScummVM site
Platform: Sega Dreamcast

Note: It does work in nullDC (emulador), so it might be memory aligment issues like bug #5932 ?

Discussion

  • digitall

    digitall - 2014-01-11

    The referenced bug #5932 is "Soltys WINCE: Scummvm crash at start":
    https://sourceforge.net/p/scummvm/bugs/5932/

    This is still open despite fuzzie committing a number of alignment fixes.
    It does look very similar, but I wonder if both are caused by out of memory, screen size issues or the CGE engine running very slowly?

    Will try to eliminate and get more information on the cause of this on the Dreamcast.

     

  • digitall

    digitall - 2014-01-11
    • summary: Soltys Dreamcast: Scummvm crash at start --> DC: Soltys (CGE) crashes at start up
     

  • digitall

    digitall - 2014-01-11

    Replicated on my Dreamcast with the latest Git master build from buildbot i.e. b3c377aa and Soltys English. The CD mastered had all versions of Soltys, CGE plugin and ScummVM binary only.

    Serial output trace attached.

    The critical error is:
    sbrk [65536B alloc, 1623k tot, 10692k left -> (void *)0x8c48f000]
    EXCEPTION AT (void )0x8c3050e0 {pr = (void )0x8c3050d0} : 00000100
    r0 = 0x8c4487d2, r1 = 0x8c2eaf04, r2 = 0xe7e70000, r3 = 0x00004000
    r4 = 0x0000402d, r5 = 0xe7e7e7e7, r6 = 0x8c4487f5, r7 = 0x8c2eae78
    r8 = 0x00000023, r9 = 0x8c4487f5, r10 = 0x8c4487f7, r11 = 0x8c4487d0
    r12 = 0x8c44866e, r13 = 0x00000027, r14 = 0x00000138, r15 = 0x8cfff350
    (void )0x8cfff350 : (void )0x8c448668
    (void )0x8cfff354 : (void )0x8c44866c

     
    dreamcast-serial-trace-of-Soltys-English-crash.txt

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-12

    Exception 0x00000100 is an unaligned write.

     

  • digitall

    digitall - 2014-01-12

    Thanks Marcus. Any idea from the error trace where the badly aligned access is? I assume in the CGE engine, where there are a number of void * pointer usages in fileio.cpp which could be changed to byte * fairly easily...

     

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-12

    No, the trace is not usable on it's own, you need to correlate it with the ELF. And if you've built the engine as a dynamic plugin, then it won't even be in the ELF.

    I suggest you rebuild ScummVM with the CGE engine as a static builtin. You can disable all other engines, but don't disable support for dynamic plugins completely, since that may lead to a link error. Then, when you get the crash the next time, you can use sh-elf-addr2line with the ELF and the exception address to find where in the engine the problem is.

     

  • digitall

    digitall - 2014-01-12

    Ah thanks for the information.

    I am still having trouble getting ScummVM to build with my toolchain. Any ideas?

    I am building with:
    ../scummvm/configure --enable-plugins --host=dreamcast --disable-all-engines --enable-engine=cge

    The linking error associated is:
    backends/platform/dc/dcmain.o: In function __static_initialization_and_destruction_0': /scummvm/backends/platform/dc/dcmain.cpp:338: undefined reference to___dso_handle'

    This seems to be the static instance of OSystem_Dreamcast... but not sure why this fails.

     

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-12

    You should use --enable-engine-static=cge, otherwise I think it will be built as a plugin.

    Regarding __dso_handle, I think you can work around that simply by creating the symbol __dso_handle with any unique value (the idea is just that it should have different values in different shared objects). See e.g. http://www.ic.unicamp.br/~islene/2s2008-mo806/libc/csu/dso_handle.c

     

  • digitall

    digitall - 2014-01-12

    Ah thanks..Did the first change. Still getting the same error and addng the code from dso_handle.c to dcmain.cpp didn't work and just got another undefined / multiple definition of __dso_handle error.

    Any idea why this doesn't occur with buildbot toolchain i.e. Have I build the toolchain or newlib incorrectly... or is there some other way to work around?

     

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-12

    "Another undefined / multiple definition" doesn't even make sense. If you got a multiple definition, just remove one, but you just said that you had none, so how could you have multiple? If you got undefined symbol, then check the symbol that you did define (using nm) so that it is correctly spelled, i.e. not C++ mangled, correct number of leading underscores, etc.

    The buildbot toolchain probably doesn't have DSO support at all.

     

  • digitall

    digitall - 2014-01-13

    Sorry was unclear. I meant that with no __dso_handle definition, I get the "undefined reference" error earlier, but if I add the code from dso_handle.c to dcmain.cpp, I get a conflicting definition error... :/

    ../scummvm/backends/platform/dc/dcmain.cpp: In function ‘int DC_Flash::flash_read_sector(int, int, unsigned char)’:
    ../scummvm/backends/platform/dc/dcmain.cpp:288:38: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
    ../scummvm/backends/platform/dc/dcmain.cpp: At global scope:
    ../scummvm/backends/platform/dc/dcmain.cpp:340:74: warning: ‘visibility’ attribute ignored [-Wattributes]
    ../scummvm/backends/platform/dc/dcmain.cpp:343:26: error: conflicting declaration ‘void     dso_handle’
    ../scummvm/backends/platform/dc/dcmain.cpp:340:19: error: ‘    dso_handle’ has a previous declaration as ‘const void const __dso_handle’
    make:     ** [backends/platform/dc/dcmain.o] Error 1

    Not sure what is going on here...

     

  • digitall

    digitall - 2014-01-13

    Ah. Fixed compilation of ScummVM by adding -fno-use-cxa-atexit to CXXFLAGS. Still need to test the resulting binary.

     

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-13

    Great. I had a feeling there should be an option to turn that nonsense off, but couldn't think what it was. :-)

     

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-13

    Also, the error you got was not a multiple definition, it was complaining that there was an earlier declaration, and that the prototypes did not match. Changing your definition to match the declaration should have fixed the problem.

     

  • digitall

    digitall - 2014-01-16

    Solution works. Have uploaded a scummvm.elf and got the following from sh-elf-addrline:
    scummvm/engines/cge/bitmap.cpp:77

     

  • Marcus Comstedt

    Marcus Comstedt - 2014-01-16

    Right. If the problem actually occurs on that line (some fuzz may happen due to optimization), then I'd guess lsiz is odd. v is probably aligned, since it was returned by new[] (which calls malloc), but if lsiz is odd then v+lsiz-2 will be unaligned, and the write instruction crash just like in the trace.

     

  • digitall

    digitall - 2014-01-17

    Yes. lsiz is odd. Debugging output from a build I hacked is below:
    WARNING: Bitmap::Bitmap(140, 8, 231)!
    WARNING: dsiz: 35!
    WARNING: lsiz: 39!
    WARNING: psiz: 312!
    WARNING: v size: 1280!
    EXCEPTION AT (void )0x8c0344b2 {pr = (void )0x8c0344a2} : 00000100

    The exception decodes to the same line as before in bitmap.cpp:
    (uint16 )(v + lsiz - 2) = TO_LE_16(kBmpSKP | ((kScrWidth / 4) - dsiz))
    ; // gap

     

  • digitall

    digitall - 2014-01-17

    Fixed in commit 3cf79e079256947c3c0c37046fce10d95f390bc2.

    Have tested this on Dreamcast, x86_64 and PPC (BE) VM, with no issues.

    xvallejo: Please try the next nightly build from here, which will incorporate this fix:
    http://buildbot.scummvm.org/builds.html

     

  • digitall

    digitall - 2014-01-17
    • status: open --> closed-fixed