[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Gunnar Farneback
Subject: Re: [gnugo-devel] Crash report for OS X Segmentation fault
Date: Sun, 06 Jan 2002 19:20:10 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]