Opened 11 years ago
Closed 11 years ago
#6476 closed defect (fixed)
DC: Soltys (CGE) crashes at start up
| Reported by: | SF/xvallejo | Owned by: | zeldin |
|---|---|---|---|
| Priority: | high | Component: | Engine: CGE |
| Version: | Keywords: | ||
| Cc: | Game: | Soltys |
Description
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 ?
Ticket imported from: bugs/6476.
Attachments (1)
Change History (20)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
| Summary: | Soltys Dreamcast: Scummvm crash at start → DC: Soltys (CGE) crashes at start up |
|---|
by , 11 years ago
| Attachment: | dreamcast-serial-trace-of-Soltys-English-crash.txt added |
|---|
comment:3 by , 11 years ago
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
comment:5 by , 11 years ago
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...
comment:6 by , 11 years ago
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.
comment:7 by , 11 years ago
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.
comment:8 by , 11 years ago
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
comment:9 by , 11 years ago
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?
comment:10 by , 11 years ago
"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.
comment:11 by , 11 years ago
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...
comment:12 by , 11 years ago
Ah. Fixed compilation of ScummVM by adding -fno-use-cxa-atexit to CXXFLAGS. Still need to test the resulting binary.
comment:13 by , 11 years ago
Great. I had a feeling there should be an option to turn that nonsense off, but couldn't think what it was. :-)
comment:14 by , 11 years ago
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.
comment:15 by , 11 years ago
Solution works. Have uploaded a scummvm.elf and got the following from sh-elf-addrline: scummvm/engines/cge/bitmap.cpp:77
comment:16 by , 11 years ago
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.
comment:17 by , 11 years ago
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
comment:18 by , 11 years ago
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
comment:19 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.