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

Soltys
closed-fixed
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

1 2 > >> (Page 1 of 2)
  • 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

     
  • 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...

     
  • 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.

     
  • 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?

     
  • "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.

     
1 2 > >> (Page 1 of 2)