Re: [Gcl-devel] Re: possible GCL/Windows compiler bug

[Camm Maguire]

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