[B2-devel] SheepShaver startup "fake" crash? (OS X)

[Alexei S. <isv...@sy...>]

So, I have been trying, without luck, to isolate the "fake" crash  
SheepShaver experiences on startup on OS X (PPC Mac). Basically, when  
it runs, a few seconds in, the Mac OS X CrashReporter dialog opens up  
saying SheepShaver has crashed (even though SheepShaver itself  
continues to run, and do its thing fine).

The report generated by CrashReporter is something like:

> Date/Time:      2006-02-15 18:36:04.736 -0500
> OS Version:     10.4.4 (Build 8G32)
> Report Version: 3
>
> Command: SheepShaver
> Path:    ./SheepShaver
> Parent:  bash [395]
>
> Version: ??? (???)
>
> PID:    1557
> Thread: 0
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x40810000
>
> Thread 0 Crashed:
>
> Thread 1:
> 0   libSystem.B.dylib 	0x9001f20c select + 12
> 1   SheepShaver       	0x0002acec receive_func(void*) + 144  
> (ether_unix.cpp:849)
> 2   libSystem.B.dylib 	0x9002b200 _pthread_body + 96
>
> Thread 2:
> 0   libSystem.B.dylib 	0x9001f20c select + 12
> 1   SheepShaver       	0x0002ac3c slirp_receive_func(void*) + 360  
> (ether_unix.cpp:807)
> 2   libSystem.B.dylib 	0x9002b200 _pthread_body + 96
>
> Thread 3:
> 0   libSystem.B.dylib 	0x90040258 mach_wait_until + 8
> 1   libSystem.B.dylib 	0x90040020 nanosleep + 384
> 2   SheepShaver       	0x00014594 Delay_usec(unsigned) + 76  
> (timer_unix.cpp:274)
> 3   SheepShaver       	0x00028bc0 redraw_func(void*) + 128  
> (video_sdl.cpp:2138)
> 4   SheepShaver       	0x0003bbac SDL_RunThread + 72 (SDL_thread.c: 
> 219)
> 5   SheepShaver       	0x00045fa0 RunThread + 16 (SDL_systhread.c:83)
> 6   libSystem.B.dylib 	0x9002b200 _pthread_body + 96
>
> Thread 4:
> 0   libSystem.B.dylib 	0x90040258 mach_wait_until + 8
> 1   libSystem.B.dylib 	0x90040020 nanosleep + 384
> 2   SheepShaver       	0x00014594 Delay_usec(unsigned) + 76  
> (timer_unix.cpp:274)
> 3   SheepShaver       	0x00005ae8 tick_func(void*) + 116  
> (main_unix.cpp:1208)
> 4   libSystem.B.dylib 	0x9002b200 _pthread_body + 96
>
> Thread 5:
> 0   libSystem.B.dylib 	0x90040258 mach_wait_until + 8
> 1   libSystem.B.dylib 	0x90040020 nanosleep + 384
> 2   SheepShaver       	0x00014594 Delay_usec(unsigned) + 76  
> (timer_unix.cpp:274)
> 3   SheepShaver       	0x00005724 nvram_func(void*) + 100  
> (main_unix.cpp:1183)
> 4   libSystem.B.dylib 	0x9002b200 _pthread_body + 96
>
> Thread 0 crashed with PPC Thread State 64:
>   srr0: 0x0000000040c6624c srr1:  
> 0x000000000000f930                        vrsave: 0x0000000000000000
>     cr: 0x4010e0f0          xer: 0x0000000000000000   lr:  
> 0x0000000040ca7388  ctr: 0x0000000040c60000
>     r0: 0x0000000000000000   r1: 0x00000000203fffea   r2:  
> 0x0000000000000000   r3: 0x0000000040810000
>     r4: 0x000000004cdf1808   r5: 0x0000000000000000   r6:  
> 0x0000000000002070   r7: 0x0000000000000000
>     r8: 0x0000000000000000   r9: 0x000000004cdf1808  r10:  
> 0x0000000000000006  r11: 0x00000000000002f4
>    r12: 0x0000000000000861  r13: 0x0000000000000000  r14:  
> 0x0000000000000000  r15: 0x000000000002003d
>    r16: 0x0000000040810000  r17: 0x0000000000000000  r18:  
> 0x00000000408153ee  r19: 0x000000004085976c
>    r20: 0x0000000040814c1e  r21: 0x0000000023ffff88  r22:  
> 0x000000004080020a  r23: 0x0000000000000000
>    r24: 0x0000000040815542  r25: 0x0000000000000027  r26:  
> 0x0000000000000000  r27: 0x0000000000006054
>    r28: 0x0000000000000000  r29: 0x0000000040ca7388  r30:  
> 0x0000000040c60000  r31: 0x0000000068fff000

Notice how no symbols are displayed in the backtrace for the thread  
that crashed. I'm guessing this is because it is happening in  
assembly code, somewhere after jump_to_rom() is called.  
Unfortunately, due to my limited knowledge of assembly, I cannot  
reliably say that this is actually what is happening, due to not  
knowing how to effectively debug such a problem.

Running SheepShaver under GDB (and skipping GDB's paranoia about what  
the paranoia_check() function does - sending inter-thread user- 
defined signals ;), the actual crash happens thusly:

> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x40810000
> 0x40c6624c in ?? ()

> (gdb) info threads
>   6 process 1570 thread 0x4803  0x90040258 in mach_wait_until ()
>   5 process 1570 thread 0x4703  0x90040258 in mach_wait_until ()
>   4 process 1570 thread 0x4603  0x90040258 in mach_wait_until ()
>   3 process 1570 thread 0x4503  0x9001f20c in select ()
>   2 process 1570 thread 0x4403  0x9001f20c in select ()
> * 1 process 1570 local thread 0xf03  0x40c6624c in ?? ()

> (gdb) backtrace
> #0  0x40c6624c in ?? ()
> #1  0x40ca7388 in ?? ()
> warning: Previous frame identical to this frame (corrupt stack?)
> #2  0x40805600 in ?? ()

Now, since I am just about all out of ideas of what else I can do to  
try to debug and isolate, and hopefully fix the problem (and no,  
turning off CrashReporter in OS X isn't an adequate solution), does  
anyone else have any thoughts on this? Or is this already a known  
issue and has a fix in the works?

-Alexei