Re: [gnugo-devel] Crash report for OS X Segmentation fault

[Gunnar Farneback]

Allan wrote:
> A while ago I told you that GnuGo always crashes early on OS X. Well, I 
> finally figured out how to get a crash report. Here's what happened with 
> GnuGo 3.1.19:

How early does it crash? Does it always crash at the same point?

> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xbff7dfb0

For some reason it seems to be referencing memory at a very
unreasonable address. This might indicate an array indexing out of
bounds or memory corruption making the pointers completely wrong.

> Thread 0:
>   #0   0x0002b684 in compute_surrounding_moyo_sizes
>   #1   0x00028a74 in make_dragons
>   #2   0x0001e1a8 in examine_position
>   #3   0x0001e71c in do_genmove
>   #4   0x0001e528 in genmove
>   #5   0x00016ff4 in gnugo_genmove
>   #6   0x000055dc in computer_move
>   #7   0x000058d0 in do_move
>   #8   0x000060c0 in play_ascii
>   #9   0x000043c4 in main
>   #10  0x00002750 in _start
>   #11  0x00002580 in start

This is very important information, localizing at least the immediate
problem to the function compute_surrounding_moyo_sizes() in dragon.c.
It's a pity the line number is missing though, since that would have
been much more precise. I don't see any obvious problems with the code
in compute_surrounding_moyo_sizes(), so this is still a mystery.

> PPC Thread State:
>    srr0: 0x0002b684 srr1: 0x0000f030                vrsave: 0x00000000
>     xer: 0x20000020   lr: 0x00028a74  ctr: 0x00013888   mq: 0x00000000
>      r0: 0xfff7ee90   r1: 0xbffff120   r2: 0x004d1460   r3: 0x00000000
>      r4: 0x000a68fc   r5: 0x00000000   r6: 0x002d2a08   r7: 0x000be454
>      r8: 0x004d14c4   r9: 0x00830400  r10: 0x00000320  r11: 0x00000058
>     r12: 0x00013578  r13: 0x00000000  r14: 0x00000033  r15: 0x0005f350
>     r16: 0x00000001  r17: 0x80160fa8  r18: 0x000586a8  r19: 0x00001407
>     r20: 0x00000000  r21: 0x0000001c  r22: 0x70004234  r23: 0x700042c8
>     r24: 0x7016b0dc  r25: 0x006bac3c  r26: 0x8081ab5c  r27: 0x00000000
>     r28: 0x00000000  r29: 0xbfffef00  r30: 0x2a150000  r31: 0x00000001

I don't think it's possible the draw any conclusions from this
information unless you're sitting at the machine.

> Hope this helps...

Information about exactly how to reproduce the problem (options given
when starting the program and moves played before the crash) would
also be valuable.

/Gunnar