dgen crashed with SIGSEGV in __libc_start_main()

[Yagisan]

Binary package hint: dgen

crashed while loading a rom file

ProblemType: Crash
Architecture: amd64
Date: Thu Aug 9 20:09:20 2007
Disassembly: 0x1:
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/dgen
NonfreeKernelModules: vmnet vmblock vmmon
Package: dgen 1.23-9
PackageArchitecture: amd64
ProcCmdline: dgen Sonic\ and\ Knuckles\ -\ Knuckles\ in\ Sonic\ 3\ #\ SMD.SMD
ProcCwd: /home/yagisan/emulator
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_AU.UTF-8
Signal: 11
SourcePackage: dgen
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 ?? ()
 __libc_start_main () from /lib/libc.so.6
Title: dgen crashed with SIGSEGV in __libc_start_main()
Uname: Linux doomguy 2.6.22-9-generic #1 SMP Fri Aug 3 00:20:35 GMT 2007 x86_64 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin netdev plugdev scanner video
SegvAnalysis:
 Segfault happened at: 0x1:
 PC (0x00000001) not located in a known VMA region (needed executable region)!
SegvReason: executing NULL VMA

[Apport retracing service (apport)]

StacktraceTop:?? ()
?? ()
?? ()
?? ()
__libc_start_main () from /lib/libc.so.6

[Fabien Lusseau (fabien-beosfrance)]

Same problem here !!! ...

[Dylan Leigh (dleigh-cs)]

Dgen uses Niel Bradley's MZ80 core, which doesn't seem to be 64-bit clean. As dgen-sdl isn't being maintained, it doesn't look like this will be fixed. Unfortunately, Gens has the same problem on amd64.

[Cesar Eduardo Barros (cesarb)]

Backtrace without stripping the executable:

(gdb) bt
#0 0x0000000000000001 in ?? ()
#1 0x000000000046bd30 in mz80exec (dwCycles=<value optimized out>)
    at zz80.c:14960
#2 0x000000000040458f in md::one_frame_musa (this=0x7fff6af1c580,
    bm=0x6b8a00, retpal=0x0, sndi=0x6b8a20) at mdfr.cpp:168
#3 0x000000000040d2fe in main (argc=<value optimized out>,
    argv=<value optimized out>) at main.cpp:465

Looking at that line, it is expecting to find a 0xffffffff marker at the end of a list, which is somewhere else set to (UINT32)-1. The problem is that UINT32 is #defined to "unsigned long int", which is 64 bits on x86-64, and thus the marker ends up as 0xffffffffffffffff.

A simple fix is to use <stdint.h> for the correct types. This exposes the next problem (which gcc helpfully warns about when attempting to compile): in several places it uses "(UINT32) pbPC - (UINT32) cpu.z80Base", where pbPC and z80Base are pointers. "(UINT32) (pbPC - cpu.z80Base)" is a portable alternative, which should always have the same result, even on 32-bit (assuming pbPC points to within z80Base, which it should do for the subtraction to make sense).

Running the code with these fixes crashes elsewhere (looks like MZ80 wasn't that 64-bit unclean after all); however, at the new crash site there are no helpful defines to help us this time, and untangling the correct sizes of the types will take some more time.

(gdb) bt
#0 0x00000000004088b0 in md_vdp::draw_plane_back1 (this=0x7fffd3281970,
    line=<value optimized out>) at ras.cpp:466
#1 0x000000000040caca in md_vdp::draw_scanline (this=0x7fffd3281970,
    bits=<value optimized out>, line=17) at ras.cpp:752
#2 0x0000000000404606 in md::one_frame_musa (this=0x7fffd3281930,
    bm=0x6b7860, retpal=0x0, sndi=0x6b7880) at mdfr.cpp:277
#3 0x000000000040d2ee in main (argc=<value optimized out>,
    argv=<value optimized out>) at main.cpp:465

The code at that point also doesn't seem to be -fstrict-aliasing safe (a simple workaround would be to add -fno-strict-aliasing).

Attached is a patch with the changes I've made so far. I might try to fix it further at some later time.

[Cesar Eduardo Barros (cesarb)]

The same change should also be made to makez80.c (which isn't used, but can be used to regenerate zz80.c).

[Cesar Eduardo Barros (cesarb)]

A few more changes were enough to make it run without crashing. However:

1. The result cannot be distributed without permission of the mz80 author, since it modifies the mz80 code (even though the result is exactly the same).
2. The sound seems to have some problems. Finding the cause will be harder, since it's not a crash (where you can simply look at the backtrace).

If someone else wants to continue where I left off, feel free to.

[Karl Ostmo (kostmo)]

Here's a related forum posting of other people experiencing the bug, for the sake of consolidation:
http://ubuntuforums.org/showthread.php?t=358206

[Cesar Eduardo Barros (cesarb)]

I would suggest either not building this package for 64-bit targets or building a 32-bit version of it for 64-bit targets (like the wine package). Both approaches would "fix" this bug.

[Cesar Eduardo Barros (cesarb)]

I managed to successfully compile a working dgen for x86_64, with the attached changes to configure.in to make it use -m32 when necessary.

Several other steps have to be done by hand for a sucessful compile (not included in the patch to make it smaller and thus easier to review):

# Copy a recent enough version of config.guess and config.sub
cp -a /usr/share/misc/config.{guess,sub} .

# Regenerate the makefiles and configure script
# Calling aclocal causes problems for some reason (it pulls in something which AC_PREREQs a newer autoconf)
#aclocal-1.4
touch aclocal.m4
automake-1.4 --foreign --include-deps
autoconf2.13

# Create the missing .so symbolic links locally (these should be in ia32-libs instead)
ln -s /usr/lib32/libSDL-1.2.so.0.11.1 libSDL.so
ln -s /usr/lib32/libXt.so.6.0.0 libXt.so
ln -s /usr/lib32/libICE.so.6.3.0 libICE.so
ln -s /usr/lib32/libGL.so.1.2 libGL.so

# Use the symbolic links created above
export LDFLAGS=-L`pwd`

I have not tested generating an actual package, only building the executable and running it.

[dino99 (9d9)]

That version has died long ago; no more supported