[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: possible GCL/Windows compiler bug
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: possible GCL/Windows compiler bug |
Date: |
14 Oct 2004 10:10:38 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings, and thanks Matt for the very useful debugging info. We
should be close now.
I can correlate your assembler outputs just fine. Unfortunately, gdb
truncated the bit of the output we need to see what is going on:
Program received signal SIGSEGV, Segmentation fault.
0x102dcbbc in ?? ()
(gdb) p/x *(char *)address@hidden
$1 = {0x55, 0x89, 0xe5, 0x57, 0x56, 0x53, 0x83, 0xec, 0xc, 0x8b, 0x35, 0x0,
0x68, 0x5a, 0x0, 0x8d, 0x5e, 0xc, 0x3b, 0x1d, 0x50, 0x6d, 0x5a, 0x0, 0x8b,
0x7d, 0xc, 0x89, 0x1d, 0x0, 0x68, 0x5a, 0x0, 0xf, 0x83, 0xcd, 0x0, 0x0, 0x0,
0x8b, 0x15, 0x40, 0xcc, 0x2d, 0x10, 0x81, 0x7a, 0x4, 0x50, 0x2, 0x54, 0x0,
0xf, 0x84, 0x8e, 0x0, 0x0, 0x0, 0x68, 0x50, 0x2, 0x54, 0x0, 0x68, 0x50, 0x2,
0x54, 0x0, 0x57, 0xff, 0x75, 0x8, 0xff, 0x15, 0x6c, 0xcc, 0x2d, 0x10, 0x89,
0x4, 0x24, 0x89, 0xc3, 0x8b, 0x3d, 0x84, 0x5, 0x63, 0x0, 0xff, 0x15, 0x68,
0xcc, 0x2d, 0x10, 0x83, 0xc4, 0x10, 0x3d, 0x50, 0x2, 0x54, 0x0, 0xc7, 0x45,
0xf0, 0x90, 0x6b, 0x5a, 0x0, 0x74, 0x38, 0x83, 0xec, 0xc, 0x57, 0xff, 0x15,
0x64, 0xcc, 0x2d, 0x10, 0xff, 0x75, 0x10, 0x50, 0xff, 0x35, 0x48, 0xcc,
0x2d, 0x10, 0x6a, 0x3, 0xe8, 0x19, 0x92, 0x15, 0xf0, 0x83, 0xc4, 0x1c, 0x50,
0xff, 0x75, 0xf0, 0x6a, 0x2, 0xe8, 0x7, 0x91, 0x15, 0xf0, 0x89, 0x35, 0x0,
0x68, 0x5a, 0x0, 0x8d, 0x65, 0xf4, 0x5b, 0x5e, 0x5f, 0xc9, 0xc3, 0x90, 0x83,
0xec, 0xc, 0x53, 0xff, 0x15, 0x64, 0xcc, 0x2d, 0x10, 0x5a, 0x59, 0x50, 0xff,
0x35, 0x44, 0xcc, 0x2d, 0x10, 0xe8, 0x70, 0x7b, 0x12, 0xf0, 0x89, 0x45,
0xf0, 0x83, 0xc4, 0x10, 0xeb, 0xa8...}
The ... at the end hides the location of the possible corruption.
0x102dcbbc-0x102dcaa0=0x11c=284, so 'p/x *((char *)0x102dcbbc-16)@32'
here should do the trick.
After printing this out, try the following:
(gdb) c
>>:q
>(load "gazonk520.o")
>l
(gdb) 'p/x *((char *)<new_start_address_output_above>+284-16)@32'
>From your dumps, we see there is a problem in the code doing the call
to the external function reverse:
static object LnkTLI5(object first,...){object V1;va_list
ap;va_start(ap,first);V1=call_proc_new(VV[5],(void **)(void
*)&LnkLI5,1,first,ap);va_end(ap);return V1;} /* REVERSE */
00000100 <_LnkTLI5>:
100: 55 push %ebp
101: 89 e5 mov %esp,%ebp
103: 8d 55 0c lea 0xc(%ebp),%edx
106: 83 ec 14 sub $0x14,%esp
109: 52 push %edx
10a: ff 75 08 pushl 0x8(%ebp)
10d: 6a 01 push $0x1
10f: 68 24 00 00 00 push $0x24
114: ff 35 14 00 00 00 pushl 0x14
11a: e8 00 00 00 00 call 11f <_LnkTLI5+0x1f>
11f: c9 leave
120: c3 ret
121: 8d 76 00 lea 0x0(%esi),%esi
The above disassembly is not yet relocated. The 'p/x' gdb command
above will show how it has been relocated.
The lack of idempotency tells me that it is likely that the loader
itself is ok, but that something later on is trashing the code at this
point. So what we eventually want to do is run the (presumably acl2
build sequence) steps that first loaded this file under gdb, breaking
at fasload, and conditionalizing this break to only stop at
gazonk520. We'll step through the function, 'p/x *((char
*)0x102dcbbc-16)@32' the code after it is first relocated to make sure
it is correct, then set a hardware watchpoint to stop when this
location is written to. This should let us know definitively what is
going on.
If you don't have gcl compiled with debugging yet, we won't be able to
conditionalize a fasload break, so we'll set the hardware watchpoint
up front, stopping once when the code is first loaded, and then a
second time when it is trashed. This watchpoint can only be set when
the memory area in question is first allocated. We might be so lucky
that this is so when gcl is first fired up. We know we can set the
watch when heap_end > 0x102dcbbc. So in the absence of gcl
--enable-debug, perhaps the following will do the trick.
gdb saved_gcl
(gdb) b main
(gdb) r
(breakpoint 1)
(gdb) p/x heap_end
(gdb) watch heap_end
(gdb) cond 2 heap_end > 0x102dcbbc
(gdb) c
> (do the acl2 build sequence)
(breakpoint 2)
(gdb) disable 2
(gdb) p/x *(char *)address@hidden
(gdb) watch *(int *)0x102dcbbc
(gdb) p/x *((char *)0x102dcbbc-16)@32
(gdb) display/x *((char *)0x102dcbbc-16)@32
(gdb) c
(breakpoint 3)
(gdb) (code displayed on first load, send me this)
(gdb) c
(breakpoint 3)
(gdb) (code displayed when trashed, send me this)
(gdb) bt (send me this, as well as lisp output right above this)
If you can reproduce with gcl built with --enable-debug, then
gdb saved_gcl
(gdb) b main
(gdb) r
(breakpoint 1)
(gdb) b sfasl.c:365
(gdb) cond 2 strstr(filename,"gazonk520")
(gdb) c
> (do acl2 build sequence)
(breakpoint 2)
(gdb) p/x *((char *)0x102dcbbc-16)@32
(gdb) display/x *((char *)0x102dcbbc-16)@32
(gdb) watch *(int *)0x102dcbbc
(gdb) c
(breakpoint 3)
(gdb) (code displayed when trashed, send me this)
(gdb) bt (send me this, as well as lisp output right above this)
Thanks for your help with this. And please excuse the tedium -- I
don't have access to one of these machines myself.
Take care,
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, (continued)
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/13
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Camm Maguire, 2004/10/13
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/13
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Camm Maguire, 2004/10/13
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/13
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/14
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug,
Camm Maguire <=
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/14
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Camm Maguire, 2004/10/14
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/14
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/14
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Camm Maguire, 2004/10/15
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/15
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Camm Maguire, 2004/10/15
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/15
- RE: [Gcl-devel] Re: possible GCL/Windows compiler bug, Mike Thomas, 2004/10/18
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/18