[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: |
15 Oct 2004 15:27:08 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Matt Kaufmann <address@hidden> writes:
> Thank you for the quick reply, and for the suggestion to go ahead with the
> ACL2
> release. In the interim, I guess J and I can put up gazonk520.lsp with a
> recommendation to compile/load it.
>
> Below is my understanding of what you'd like me to do next; please let me know
> if I have this right.
>
> Thanks --
> -- Matt
> Cc: address@hidden, address@hidden
> From: Camm Maguire <address@hidden>
> Date: 15 Oct 2004 12:28:37 -0400
> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> Content-Type: text/plain; charset=us-ascii
> X-SpamAssassin-Status: No, hits=-2.6 required=5.0
> X-UTCS-Spam-Status: No, hits=-332 required=180
>
> Greetings, and thanks again as always!
>
> OK, here is the executive summary as best as I can currently tell:
>
> 1) The call address at 0x102dcbbc is not subsequently trashed, but is
> set to its final value (at the segfault):
>
> 0xf01502e9 (little endian, relative offset)+0x102dcbbb = 0x42cea4
>
> at the initial load of gazonk520.o
>
> 2) Subsequent reload of gazonk520.o gives the same address:
>
> 0xeed11f69 (little endian, relative offset +0x1171ae20+284-1 =
> 0x42cea4
>
> This should be the address of Lreverse or reverse in your image,
> which should be checkable in gdb by p/x reverse and p/x Lreverse.
>
> So, I will start up the defective ACL2 image in gdb and then do:
>
> p/x reverse
> p/x Lreverse
>
Yes, please!
> 3) The fault must therefore be at the previous instruction, which was
> rounded up to the nearest word when reported by gdb. Here is the
> relevant portion of the dump:
>
> 114: ff 35 14 00 00 00 pushl 0x14
> 11a: e8 00 00 00 00 call 11f <_LnkTLI5+0x1f>
>
> The word before 0x11c straddles the two instructions.
>
> 4) The code corresponding to the pushl for both loads looks correct at
> first glance.
>
> 0x102dcc54(little endian, absolute address)-0x102dcaa0=0x1b4
> 0x1171afd4(little endian, absolute address)-0x1171ae20=0x1b4
>
> which lies beyond the code segment (ending at 0x19f) and is either
> in the .data or .bss section of the gazonk520.o file. You can see
> which with objdump -h gazonk520.o at the shell.
>
> I'll do the objdump and email you the result.
>
Thanks!
> 5) The only ways I can envision a segfault, therefore, are the
> following:
>
> a) you are out of stack space. 'i reg esp' and 'p/x cs_org'
> in gdb at the location of the fault should show this.
>
> Is is also possible here that you have simply exceeded Mike
> Thomas' stack limit emulation, and that the NULL_OR_ON_C_STACK
> macro therefore failed in some gc call or the like. Here is
> the relevant section for mingw from main.c:
>
> {
> unsigned int dummy;
>
> _stackbottom = (unsigned int ) &dummy;
> _stacktop = _stackbottom - 0x10000; // ???
>
> }
>
> You might also want to do 'p/x _stackbottom' and 'p/x
> _stacktop' at the fault location when you do 'i reg esp'.
>
> So, I start up the image, cause the error, and then submit to gdb:
>
> i reg esp
> p/x cs_org
> p/x _stackbottom
> p/x _stacktop
>
> and also, for b) just below:
>
> p/x *(int *)0x102dcc54
>
Yes, please! And also 'p/x *((char *)0x102dcc54-16)@32'.
> b) The address 0x102dcc54 is not readable, either because it
> has not been loaded, or mprotected somehow. 'p/x *(int
> *)0x102dcc54' at the location of the fault should let you
> know. 'p/x *(int *)0x1171afd4' after the .o has been reloaded
> should let you know what the right value should be.
>
> Then after the fault I type 'c' in gdb, then in Lisp
>
> :q
I thought this part did not work. You can rather load the gazonk520.o
before issuing the error sequence. Right after loading from lisp,
Control-C back to gdb.
> (load "gazonk250.o")
> Control-C
>
> and in gdb I then type:
>
> 'p/x *(int *)0x1171afd4
>
Yes, please! And also 'p/x *((char *)0x1171afd4-16)@32'.
Take care,
> Both of these scenarios are quite unlikely given the sequences you
> report, but so far these are the only possibilities that come to
> mind. Perhaps our windows expert Mike Thomas might know more. To
> my knowledge, signals, including SIGSEGV, are emulated in some way
> on mingw. Could there be another cause, Mike?
>
> 6) It is still possible, of course that something is trashing the
> .data or .bss section of the code -- this however should not result
> in a segfault when merely loading said supposed corrupted value
> onto the stack. So in short, while we cannot definitely pinpoint
> this as yet, my hunch is that acl2 is not implicated, and you
> should go ahead with your release.
>
> Take care,
>
> Matt Kaufmann <address@hidden> writes:
>
> > Please see comments below.
> >
> > > Cc: address@hidden, address@hidden
> > > From: Camm Maguire <address@hidden>
> > > Date: 14 Oct 2004 17:09:50 -0400
> > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > Content-Type: text/plain; charset=us-ascii
> > > X-SpamAssassin-Status: No, hits=-2.6 required=5.0
> > > X-UTCS-Spam-Status: No, hits=-332 required=180
> >
> > > Greetings, and thanks again for the feedback!
> >
> > > Matt Kaufmann <address@hidden> writes:
> >
> > > > Hi, Camm --
> > > >
> > > > OK, I've tried to carry out your additional instructions, and had
> limited
> > > > success. Please see below.
> > > >
> > > > Cc: address@hidden, address@hidden
> > > > From: Camm Maguire <address@hidden>
> > > > Date: 14 Oct 2004 10:10:38 -0400
> > > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > > Content-Type: text/plain; charset=us-ascii
> > > > X-SpamAssassin-Status: No, hits=-2.6 required=5.0
> > > > X-UTCS-Spam-Status: No, hits=-342 required=180
> > > >
> > > > 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.
> > > >
> > > > Here is a log. I think it gives you ask for above.
> > > >
> > > > gdb ./custom-gcl-saved_acl2.gcl.exe
> > > > GNU gdb 5.2.1
> > > > Copyright 2002 Free Software Foundation, Inc.
> > > > GDB is free software, covered by the GNU General Public License, and
> you are
> > > > welcome to change it and/or distribute copies of it under certain
> conditions.
> > > > Type "show copying" to see the conditions.
> > > > There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> > > > This GDB was configured as "i686-pc-mingw32"...
> > > > (gdb) r
> > > > Starting program: C:\matt\acl2\v2-9/./custom-gcl-saved_acl2.gcl.exe
> > > >
> > > > 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...}
> > > > (gdb) p/x *((char *)0x102dcbbc-16)@32
> > > > $2 = {0x8, 0x6a, 0x1, 0x68, 0x64, 0xcc, 0x2d, 0x10, 0xff, 0x35,
> 0x54, 0xcc,
> > > > 0x2d, 0x10, 0xe8, 0xe9, 0x2, 0x15, 0xf0, 0xc9, 0xc3, 0x8d, 0x76,
> 0x0, 0x55,
> > > > 0x89, 0xe5, 0x8d, 0x55, 0xc, 0x83, 0xec}
> >
> > > Great, so this does look like a bogus address.
> >
> > > > (gdb) c
> > > > Continuing.
> > > >
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x102dcbbc in ?? ()
> > > > (gdb)
> > > >
> > > > 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'
> > > >
> > > > Unfortunately, all that "c" did above was throw me back into gdb. I
> couldn't
> > > > submit ":q" to the running ACL2:
> > > >
> >
> > > So please rerun from gdb ('r'), and load the .o before trigerring the
> > > error sequence, which as your previous email indicated, should make
> > > the error go away. Find the start address of the .o, Control-C l at
> > > the lisp prompt to return to gdb, and print out the correct code with
> > > 'p/x *((char *)<new_start_address_output_above>+284-16)@32'.
> >
> > Just below are the gdb log and corresponding ACL2 for the above. After
> these,
> > search for "OK, I did the experiment" to find my next comment quickly.
> >
> >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > gdb ./custom-gcl-saved_acl2.gcl.exe
> > GNU gdb 5.2.1
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> are
> > welcome to change it and/or distribute copies of it under certain
> conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> > This GDB was configured as "i686-pc-mingw32"...
> > (gdb) r
> > Starting program: C:\matt\acl2\v2-9/./custom-gcl-saved_acl2.gcl.exe
> >
> > Program received signal SIGINT, Interrupt.
> > [Switching to thread 1864.0x2e0]
> > 0x77ec8ef8 in _libwsock32_a_iname ()
> > (gdb) p/x *((char *)0x1171ae20+284-16)@32
> > $1 = {0x8, 0x6a, 0x1, 0x68, 0xe4, 0xaf, 0x71, 0x11, 0xff, 0x35, 0xd4,
> 0xaf,
> > 0x71, 0x11, 0xe8, 0x69, 0x1f, 0xd1, 0xee, 0xc9, 0xc3, 0x8d, 0x76, 0x0,
> 0x55,
> > 0x89, 0xe5, 0x8d, 0x55, 0xc, 0x83, 0xec}
> > (gdb)
> >
> >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > GCL (GNU Common Lisp) 2.6.5 CLtL1 Aug 23 2004 14:56:58
> > Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
> > Binary License: GPL due to GPL'ed components: (UNEXEC)
> > Modifications of this banner must retain notice of a compatible license
> > Dedicated to the memory of W. Schelter
> >
> > Use (help) to get some basic information on how to use GCL.
> > Loading init.lsp
> > Finished loading init.lsp
> >
> > ACL2 Version 2.9 built October 13, 2004 18:35:51.
> > Copyright (C) 2004 University of Texas at Austin
> > ACL2 comes with ABSOLUTELY NO WARRANTY. This is free software and you
> > are welcome to redistribute it under certain conditions. For details,
> > see the GNU General Public License.
> >
> > Initialized with (INITIALIZE-ACL2 'INCLUDE-BOOK *ACL2-PASS-2-FILES*
> > NIL).
> > See the documentation topic note-2-9 for recent changes.
> >
> > NOTE!! Proof trees are disabled in ACL2. To enable them in emacs,
> > look under the ACL2 source directory in interface/emacs/README.doc;
> > and, to turn on proof trees, execute :START-PROOF-TREE in the ACL2
> > command loop. Look in the ACL2 documentation under PROOF-TREE.
> >
> > ACL2 Version 2.9. Level 1. Cbd "C:/matt/acl2/v2-9/".
> > Type :help for help.
> > Type (good-bye) to quit completely out of ACL2.
> >
> > ACL2 !>:q
> >
> > Exiting the ACL2 read-eval-print loop. To re-enter, execute (LP).
> > ACL2>(load "gazonk520.o")
> >
> > Loading gazonk520.o
> > start address -T 1171ae20 Finished loading gazonk520.o
> > 480
> >
> > ACL2>(f-put-global 'safe-mode t state)
> >
> > ACL2_INVISIBLE::|The Live State Itself|
> >
> > ACL2>(ACL2_*1*_ACL2::MATCH-CLAUSE 'DCL '(& . &) '(T))
> >
> > ((AND (CONSP DCL)) (LET () T))
> >
> > ACL2>
> >
> >
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > > > >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.
> > > >
> > > > So at this point, is it looking like it's not an ACL2 issue? It
> would be good
> > > > not to hold up the ACL2 release this Saturday if ACL2 isn't broken
> here.
> >
> > > It could very well be a gcl issue. But until we find what is stepping
> > > on the code, it is always possible that some bit of compiled lisp
> > > assumes some arg is of one type, writes to it without an explicit type
> > > check, which when compiled with safety 0 (the default) and passed say
> > > a fixnum can write pretty much anywhere in memory.
> >
> > > This brings to mind a possible gcl improvement. Binary code loaded
> > > like this should be mprotected read-only regardless of the state of
> > > sgc. Then we'd get a simple fault when the offending code attempts to
> > > trash the instructions.
> >
> > > >
> > > > 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)
> > > >
> > > > I tried the above, but it seemed that the break happened way too
> early (ACL2
> > > > wasn't even out of axioms.lisp yet, and the problem occurs when
> processing
> > > > the next source file, basis.lisp). Here is a log, perhaps with more
> > > > information than you wanted.
> > > >
> > > > gdb gcl/my-gcl.exe
> > > > GNU gdb 5.2.1
> > > > Copyright 2002 Free Software Foundation, Inc.
> > > > GDB is free software, covered by the GNU General Public License, and
> you are
> > > > welcome to change it and/or distribute copies of it under certain
> conditions.
> > > > Type "show copying" to see the conditions.
> > > > There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> > > > This GDB was configured as "i686-pc-mingw32"...
> > > > (gdb) b main
> > > > Breakpoint 1 at 0x402342
> > > > (gdb) r
> > > > Starting program: C:\matt\acl2\v2-9/gcl/my-gcl.exe
> > > >
> > > > Breakpoint 1, 0x00402342 in main ()
> > > > (gdb) p/x heap_end
> > > > $1 = 0x0
> > > > (gdb) watch heap_end
> > > > Hardware watchpoint 2: {<data variable, no debug info>} 5508064
> > > > (gdb) cond 2 heap_end > 0x102dcbbc
> > > > (gdb) c
> > > > Continuing.
> > > > Hardware watchpoint 2: {<data variable, no debug info>} 5508064
> > > >
> > > > Old value = 271314944
> > > > New value = 271437824
> > > > 0x00404022 in alloc_page ()
> > > > (gdb) disable 2
> > > > (gdb) p/x *(char *)address@hidden
> > > > $2 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
> > > > (gdb) watch *(int *)0x102dcbbc
> > > > Hardware watchpoint 3: *(int *) 271436732
> > > > (gdb) p/x *((char *)0x102dcbbc-16)@32
> > > > $3 = {0x0 <repeats 32 times>}
> > > > (gdb) display/x *((char *)0x102dcbbc-16)@32
> > > > 1: /x *((char *) 271436732 - 16) @ 32 = {0x0 <repeats 32 times>}
> > > > (gdb) c
> > > > Continuing.
> > > > Hardware watchpoint 3: *(int *) 271436732
> > > >
> > > > Old value = 0
> > > > New value = 99
> > > > 0x77c3dc94 in _libwsock32_a_iname ()
> > > > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69,
> 0x6e, 0x65,
> > > > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> > > > 0x0 <repeats 15 times>}
> > > > (gdb) c
> > > > Continuing.
> > > > Hardware watchpoint 3: *(int *) 271436732
> > > >
> > > > Old value = 99
> > > > New value = 29795
> > > > 0x77c3dc94 in _libwsock32_a_iname ()
> > > > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69,
> 0x6e, 0x65,
> > > > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> 0x74,
> > > > 0x0 <repeats 14 times>}
> > > > (gdb) bt
> > > > #0 0x77c3dc94 in _libwsock32_a_iname ()
> > > > #1 0x106d8ccc in ?? ()
> > > > #2 0x0041fd8e in writec_stream ()
> > > > #3 0x00421562 in writestr_stream ()
> > > > #4 0x004546ef in princ_str ()
> > > > #5 0x0048458b in LI6 ()
> > > > #6 0x0041acab in quick_call_sfun ()
> > > > #7 0x00419953 in eval ()
> > > > #8 0x00455d39 in Fprogn ()
> > > > #9 0x0041129a in Fcatch ()
> > > > #10 0x00419a4e in eval ()
> > > > #11 0x00455d39 in Fprogn ()
> > > > #12 0x00419a4e in eval ()
> > > > #13 0x00411476 in Funwind_protect ()
> > > > #14 0x00419a4e in eval ()
> > > > #15 0x00455d39 in Fprogn ()
> > > > #16 0x004344ca in Flet ()
> > > > #17 0x00419a4e in eval ()
> > > > #18 0x00455d39 in Fprogn ()
> > > > #19 0x004344ca in Flet ()
> > > > #20 0x00419a4e in eval ()
> > > > #21 0x00455d39 in Fprogn ()
> > > > #22 0x00419a4e in eval ()
> > > > #23 0x00411476 in Funwind_protect ()
> > > > #24 0x00419a4e in eval ()
> > > > #25 0x00455d39 in Fprogn ()
> > > > #26 0x004344ca in Flet ()
> > > > #27 0x00419a4e in eval ()
> > > > #28 0x004184c3 in funcall ()
> > > > #29 0x00419953 in eval ()
> > > > #30 0x00415785 in Fwhen ()
> > > > #31 0x00419a4e in eval ()
> > > > #32 0x00455d39 in Fprogn ()
> > > > #33 0x00419a4e in eval ()
> > > > #34 0x00411476 in Funwind_protect ()
> > > > #35 0x00419a4e in eval ()
> > > > #36 0x00455d39 in Fprogn ()
> > > > #37 0x004344ca in Flet ()
> > > > #38 0x00419a4e in eval ()
> > > > #39 0x00455d39 in Fprogn ()
> > > > #40 0x0043462e in FletA ()
> > > > #41 0x00419a4e in eval ()
> > > > #42 0x00455d39 in Fprogn ()
> > > > #43 0x00419a4e in eval ()
> > > > #44 0x00411476 in Funwind_protect ()
> > > > #45 0x00419a4e in eval ()
> > > > #46 0x00455d39 in Fprogn ()
> > > > #47 0x004344ca in Flet ()
> > > > #48 0x00419a4e in eval ()
> > > > #49 0x004184c3 in funcall ()
> > > > #50 0x00442329 in IapplyVector ()
> > > > #51 0x00419f35 in fLapply ()
> > > > #52 0x0042c4aa in c_apply_n ()
> > > > #53 0x004421c1 in IapplyVector ()
> > > > #54 0x0041897a in funcall ()
> > > > #55 0x00419953 in eval ()
> > > > #56 0x0041a83e in Ieval ()
> > > > #57 0x0040b5c5 in Fsetq ()
> > > > #58 0x00419a4e in eval ()
> > > > #59 0x00455d39 in Fprogn ()
> > > > #60 0x00419a4e in eval ()
> > > > #61 0x00455bbf in Ftagbody ()
> > > > #62 0x00419a4e in eval ()
> > > > #63 0x0041085d in Fblock ()
> > > > #64 0x00419a4e in eval ()
> > > > #65 0x004184c3 in funcall ()
> > > > #66 0x00419953 in eval ()
> > > > #67 0x004102df in let_bind ()
> > > > #68 0x004344b6 in Flet ()
> > > > #69 0x00419a4e in eval ()
> > > > #70 0x00415995 in Funless ()
> > > > #71 0x00419a4e in eval ()
> > > > #72 0x00455d39 in Fprogn ()
> > > > #73 0x004344ca in Flet ()
> > > > #74 0x00419a4e in eval ()
> > > > #75 0x004151c8 in Fcond ()
> > > > #76 0x00419a4e in eval ()
> > > > #77 0x004184c3 in funcall ()
> > > > #78 0x00419953 in eval ()
> > > > #79 0x0041a93d in fLeval ()
> > > > #80 0x0042c4aa in c_apply_n ()
> > > > #81 0x0044246f in Iinvoke_c_function_from_value_stack ()
> > > > #82 0x0041a8f5 in Leval ()
> > > > #83 0x1051a392 in ?? ()
> > > > #84 0x1051a955 in ?? ()
> > > > #85 0x0041acc0 in quick_call_sfun ()
> > > > #86 0x00418912 in funcall ()
> > > > #87 0x102b0ee6 in ?? ()
> > > > #88 0x102a5624 in ?? ()
> > > > #89 0x103d77f1 in ?? ()
> > > > #90 0x1043163b in ?? ()
> > > > #91 0x10436e21 in ?? ()
> > > > #92 0x0041acab in quick_call_sfun ()
> > > > #93 0x102ec9b7 in ?? ()
> > > > #94 0x102ee171 in ?? ()
> > > > #95 0x102ee381 in ?? ()
> > > > #96 0x102eef45 in ?? ()
> > > > #97 0x102f5743 in ?? ()
> > > > #98 0x104be86a in ?? ()
> > > > #99 0x104be954 in ?? ()
> > > > #100 0x0042d094 in call_proc_new ()
> > > > #101 0x104c71ef in ?? ()
> > > > #102 0x104bec0c in ?? ()
> > > > #103 0x0042d094 in call_proc_new ()
> > > > #104 0x104c7183 in ?? ()
> > > > #105 0x104c014e in ?? ()
> > > > #106 0x0042d094 in call_proc_new ()
> > > > #107 0x105223d7 in ?? ()
> > > > #108 0x1051dbd3 in ?? ()
> > > > #109 0x00419968 in eval ()
> > > > #110 0x0041a93d in fLeval ()
> > > > #111 0x0042c4aa in c_apply_n ()
> > > > #112 0x004421c1 in IapplyVector ()
> > > > #113 0x0041897a in funcall ()
> > > > #114 0x00419953 in eval ()
> > > > #115 0x004184c3 in funcall ()
> > > > #116 0x00419953 in eval ()
> > > > #117 0x0041a93d in fLeval ()
> > > > #118 0x0042c4aa in c_apply_n ()
> > > > #119 0x004421c1 in IapplyVector ()
> > > > #120 0x0041897a in funcall ()
> > > > #121 0x0051e95e in LI1 ()
> > > > #122 0x0041ac32 in quick_call_sfun ()
> > > > #123 0x00418912 in funcall ()
> > > > #124 0x00442329 in IapplyVector ()
> > > > #125 0x00419e3d in fLfuncall ()
> > > > #126 0x0042c4aa in c_apply_n ()
> > > > #127 0x004421c1 in IapplyVector ()
> > > > #128 0x0041897a in funcall ()
> > > > #129 0x00419953 in eval ()
> > > > #130 0x004184c3 in funcall ()
> > > > #131 0x00419953 in eval ()
> > > > #132 0x004184c3 in funcall ()
> > > > #133 0x004027a1 in main ()
> > > > (gdb) c
> > > > Continuing.
> > > > Hardware watchpoint 3: *(int *) 271436732
> > > >
> > > > Old value = 29795
> > > > New value = 2126947
> > > > 0x77c3dc94 in _libwsock32_a_iname ()
> > > > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69,
> 0x6e, 0x65,
> > > > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> 0x74,
> > > > 0x20, 0x0 <repeats 13 times>}
> > > > (gdb) bt
> > > > #0 0x77c3dc94 in _libwsock32_a_iname ()
> > > > #1 0x106d8ccc in ?? ()
> > > > #2 0x0041fd8e in writec_stream ()
> > > > #3 0x00421562 in writestr_stream ()
> > > > #4 0x004546ef in princ_str ()
> > > > #5 0x0048458b in LI6 ()
> > > > #6 0x0041acab in quick_call_sfun ()
> > > > #7 0x00419953 in eval ()
> > > > #8 0x00455d39 in Fprogn ()
> > > > #9 0x0041129a in Fcatch ()
> > > > #10 0x00419a4e in eval ()
> > > > #11 0x00455d39 in Fprogn ()
> > > > #12 0x00419a4e in eval ()
> > > > #13 0x00411476 in Funwind_protect ()
> > > > #14 0x00419a4e in eval ()
> > > > #15 0x00455d39 in Fprogn ()
> > > > #16 0x004344ca in Flet ()
> > > > #17 0x00419a4e in eval ()
> > > > #18 0x00455d39 in Fprogn ()
> > > > #19 0x004344ca in Flet ()
> > > > #20 0x00419a4e in eval ()
> > > > #21 0x00455d39 in Fprogn ()
> > > > #22 0x00419a4e in eval ()
> > > > #23 0x00411476 in Funwind_protect ()
> > > > #24 0x00419a4e in eval ()
> > > > #25 0x00455d39 in Fprogn ()
> > > > #26 0x004344ca in Flet ()
> > > > #27 0x00419a4e in eval ()
> > > > #28 0x004184c3 in funcall ()
> > > > #29 0x00419953 in eval ()
> > > > #30 0x00415785 in Fwhen ()
> > > > #31 0x00419a4e in eval ()
> > > > #32 0x00455d39 in Fprogn ()
> > > > #33 0x00419a4e in eval ()
> > > > #34 0x00411476 in Funwind_protect ()
> > > > #35 0x00419a4e in eval ()
> > > > #36 0x00455d39 in Fprogn ()
> > > > #37 0x004344ca in Flet ()
> > > > #38 0x00419a4e in eval ()
> > > > #39 0x00455d39 in Fprogn ()
> > > > #40 0x0043462e in FletA ()
> > > > #41 0x00419a4e in eval ()
> > > > #42 0x00455d39 in Fprogn ()
> > > > #43 0x00419a4e in eval ()
> > > > #44 0x00411476 in Funwind_protect ()
> > > > #45 0x00419a4e in eval ()
> > > > #46 0x00455d39 in Fprogn ()
> > > > #47 0x004344ca in Flet ()
> > > > #48 0x00419a4e in eval ()
> > > > #49 0x004184c3 in funcall ()
> > > > #50 0x00442329 in IapplyVector ()
> > > > #51 0x00419f35 in fLapply ()
> > > > #52 0x0042c4aa in c_apply_n ()
> > > > #53 0x004421c1 in IapplyVector ()
> > > > #54 0x0041897a in funcall ()
> > > > #55 0x00419953 in eval ()
> > > > #56 0x0041a83e in Ieval ()
> > > > #57 0x0040b5c5 in Fsetq ()
> > > > #58 0x00419a4e in eval ()
> > > > #59 0x00455d39 in Fprogn ()
> > > > #60 0x00419a4e in eval ()
> > > > #61 0x00455bbf in Ftagbody ()
> > > > #62 0x00419a4e in eval ()
> > > > #63 0x0041085d in Fblock ()
> > > > #64 0x00419a4e in eval ()
> > > > #65 0x004184c3 in funcall ()
> > > > #66 0x00419953 in eval ()
> > > > #67 0x004102df in let_bind ()
> > > > #68 0x004344b6 in Flet ()
> > > > #69 0x00419a4e in eval ()
> > > > #70 0x00415995 in Funless ()
> > > > #71 0x00419a4e in eval ()
> > > > #72 0x00455d39 in Fprogn ()
> > > > #73 0x004344ca in Flet ()
> > > > #74 0x00419a4e in eval ()
> > > > #75 0x004151c8 in Fcond ()
> > > > #76 0x00419a4e in eval ()
> > > > #77 0x004184c3 in funcall ()
> > > > #78 0x00419953 in eval ()
> > > > #79 0x0041a93d in fLeval ()
> > > > #80 0x0042c4aa in c_apply_n ()
> > > > #81 0x0044246f in Iinvoke_c_function_from_value_stack ()
> > > > #82 0x0041a8f5 in Leval ()
> > > > #83 0x1051a392 in ?? ()
> > > > #84 0x1051a955 in ?? ()
> > > > #85 0x0041acc0 in quick_call_sfun ()
> > > > #86 0x00418912 in funcall ()
> > > > #87 0x102b0ee6 in ?? ()
> > > > #88 0x102a5624 in ?? ()
> > > > #89 0x103d77f1 in ?? ()
> > > > #90 0x1043163b in ?? ()
> > > > #91 0x10436e21 in ?? ()
> > > > #92 0x0041acab in quick_call_sfun ()
> > > > #93 0x102ec9b7 in ?? ()
> > > > #94 0x102ee171 in ?? ()
> > > > #95 0x102ee381 in ?? ()
> > > > #96 0x102eef45 in ?? ()
> > > > #97 0x102f5743 in ?? ()
> > > > #98 0x104be86a in ?? ()
> > > > #99 0x104be954 in ?? ()
> > > > #100 0x0042d094 in call_proc_new ()
> > > > #101 0x104c71ef in ?? ()
> > > > #102 0x104bec0c in ?? ()
> > > > #103 0x0042d094 in call_proc_new ()
> > > > #104 0x104c7183 in ?? ()
> > > > #105 0x104c014e in ?? ()
> > > > #106 0x0042d094 in call_proc_new ()
> > > > #107 0x105223d7 in ?? ()
> > > > #108 0x1051dbd3 in ?? ()
> > > > #109 0x00419968 in eval ()
> > > > #110 0x0041a93d in fLeval ()
> > > > #111 0x0042c4aa in c_apply_n ()
> > > > #112 0x004421c1 in IapplyVector ()
> > > > #113 0x0041897a in funcall ()
> > > > #114 0x00419953 in eval ()
> > > > #115 0x004184c3 in funcall ()
> > > > #116 0x00419953 in eval ()
> > > > #117 0x0041a93d in fLeval ()
> > > > #118 0x0042c4aa in c_apply_n ()
> > > > #119 0x004421c1 in IapplyVector ()
> > > > #120 0x0041897a in funcall ()
> > > > #121 0x0051e95e in LI1 ()
> > > > #122 0x0041ac32 in quick_call_sfun ()
> > > > #123 0x00418912 in funcall ()
> > > > #124 0x00442329 in IapplyVector ()
> > > > #125 0x00419e3d in fLfuncall ()
> > > > #126 0x0042c4aa in c_apply_n ()
> > > > #127 0x004421c1 in IapplyVector ()
> > > > #128 0x0041897a in funcall ()
> > > > #129 0x00419953 in eval ()
> > > > #130 0x004184c3 in funcall ()
> > > > #131 0x00419953 in eval ()
> > > > #132 0x004184c3 in funcall ()
> > > > #133 0x004027a1 in main ()
> > > > (gdb)
> >
> > > I think you might be able to keep going. The watch will be triggered
> > > 4 times for each write if its being done 1 char at a time. You should
> > > be able to eventually get to a break between the start and finish of
> > > the gazonk520.o load. This piece of memory is apparently used for
> > > some other intermediate memory malloced by winsock. My guess is that
> > > it is subsequently freed, after which it is later reused for the load
> > > of gazonk520.o.
> >
> > > If you have to manually continue too many times, you can 'ignore 3
> > > 500', or something to skip over 500 triggers. If there are truly too
> > > many of these, we'd likely be better off trying with gcl
> > > --enable-debug, *in a separate location -- not overwriting this
> > > build*, and making sure the error still exists in same. More likely
> > > than not, though, this will move the location of the error. While we
> > > have it somewhat cornered, it would be great to pinpoint.
> >
> > OK, I did the experiment, after hitting "c" (or <return>) over 300 times
> (I
> > believe). Here is the result (with some extra irrelevant stuff
> surrounding the
> > part of interest, but mostly with such extra stuff deleted as indicated
> by
> > the <<< etc. >>> marker). Extra comments are added as ";;; !!!".
> >
> > gdb gcl/my-gcl.exe
> > GNU gdb 5.2.1
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> are
> > welcome to change it and/or distribute copies of it under certain
> conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> > This GDB was configured as "i686-pc-mingw32"...
> > (gdb) b main
> > Breakpoint 1 at 0x402342
> > (gdb) r
> > Starting program: C:\matt\acl2\v2-9/gcl/my-gcl.exe
> >
> > Breakpoint 1, 0x00402342 in main ()
> > (gdb) p/x heap_end
> > $1 = 0x0
> > (gdb) watch heap_end
> > Hardware watchpoint 2: {<data variable, no debug info>} 5508064
> > (gdb) cond 2 heap_end > 0x102dcbbc
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 2: {<data variable, no debug info>} 5508064
> >
> > Old value = 271314944
> > New value = 271437824
> > 0x00404022 in alloc_page ()
> > (gdb) disable 2
> > (gdb) p/x *(char *)address@hidden
> > $2 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
> > (gdb) watch *(int *)0x102dcbbc
> > Hardware watchpoint 3: *(int *) 271436732
> > (gdb) p/x *((char *)0x102dcbbc-16)@32
> > $3 = {0x0 <repeats 32 times>}
> > (gdb) display/x *((char *)0x102dcbbc-16)@32
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x0 <repeats 32 times>}
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 0
> > New value = 99
> > 0x77c3dc94 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69, 0x6e,
> 0x65,
> > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> > 0x0 <repeats 15 times>}
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 99
> > New value = 29795
> > 0x77c3dc94 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69, 0x6e,
> 0x65,
> > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> 0x74,
> > 0x0 <repeats 14 times>}
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 29795
> > New value = 2126947
> > 0x77c3dc94 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69, 0x6e,
> 0x65,
> > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> 0x74,
> > 0x20, 0x0 <repeats 13 times>}
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 2126947
> > New value = 706770019
> > 0x77c3dc94 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x64, 0x65, 0x66, 0x69, 0x6e,
> 0x65,
> > 0x20, 0x56, 0x56, 0x20, 0x28, 0x28, 0x6f, 0x62, 0x6a, 0x65, 0x63,
> 0x74,
> > 0x20, 0x2a, 0x0 <repeats 12 times>}
> >
> > <<< etc. >>>
> >
> > (gdb)
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 674238479
> > New value = 1160777743
> > 0x77c3e410 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x2d, 0x45, 0x51, 0xf, 0x4,
> 0x2f,
> > 0x4e, 0x55, 0x4c, 0x4c, 0xf, 0x3, 0x2f, 0x43, 0x41, 0x52, 0xf, 0x10,
> 0x30,
> > 0x45, 0x51, 0x55, 0x41, 0x64, 0x20, 0x2a, 0x29, 0x26, 0x4c, 0x6e,
> 0x6b, 0x34}
> > (gdb)
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 1160777743
> > New value = 1160777728
> > 0x77c3df24 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x8, 0x6a, 0x1, 0x68, 0x24,
> 0x0, 0x0,
> > 0x0, 0xff, 0x35, 0x14, 0x0, 0x0, 0x0, 0xe8, 0x0, 0x0, 0x10, 0x30,
> 0x45,
> > 0x51, 0x55, 0x41, 0x4c, 0x2d, 0x58, 0x2d, 0x43, 0x4f, 0x4e, 0x53, 0x54}
> > ;;; !!! Current last line of ACL2 output: "Loading gazonk520.o"
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = 1160777728
> > New value = -922746880
> > 0x77c3df24 in _libwsock32_a_iname ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x8, 0x6a, 0x1, 0x68, 0x24,
> 0x0, 0x0,
> > 0x0, 0xff, 0x35, 0x14, 0x0, 0x0, 0x0, 0xe8, 0x0, 0x0, 0x0, 0x0, 0xc9,
> 0xc3,
> > 0x55, 0x41, 0x4c, 0x2d, 0x58, 0x2d, 0x43, 0x4f, 0x4e, 0x53, 0x54}
> > ;;; !!! Current last line of ACL2 output is STILL: "Loading gazonk520.o"
> > (gdb) bt
> > #0 0x77c3df24 in _libwsock32_a_iname ()
> > #1 0x0022e320 in ?? ()
> > #2 0x77c3dfdf in _libwsock32_a_iname ()
> > #3 0x00462b0e in fasload ()
> > #4 0x004229a1 in Lload ()
> > #5 0x00419968 in eval ()
> > #6 0x00455d39 in Fprogn ()
> > #7 0x004344ca in Flet ()
> > #8 0x00419a4e in eval ()
> > #9 0x00415995 in Funless ()
> > #10 0x00419a4e in eval ()
> > #11 0x00455d39 in Fprogn ()
> > #12 0x004344ca in Flet ()
> > #13 0x00419a4e in eval ()
> > #14 0x004151c8 in Fcond ()
> > #15 0x00419a4e in eval ()
> > #16 0x004184c3 in funcall ()
> > #17 0x00419953 in eval ()
> > #18 0x0041a93d in fLeval ()
> > #19 0x0042c4aa in c_apply_n ()
> > #20 0x0044246f in Iinvoke_c_function_from_value_stack ()
> > #21 0x0041a8f5 in Leval ()
> > #22 0x1051a392 in ?? ()
> > #23 0x1051a955 in ?? ()
> > #24 0x0041acc0 in quick_call_sfun ()
> > #25 0x00418912 in funcall ()
> > #26 0x102b0ee6 in ?? ()
> > #27 0x102a5624 in ?? ()
> > #28 0x103d77f1 in ?? ()
> > #29 0x1043163b in ?? ()
> > #30 0x10436e21 in ?? ()
> > #31 0x0041acab in quick_call_sfun ()
> > #32 0x102ec9b7 in ?? ()
> > #33 0x102ee171 in ?? ()
> > #34 0x102ee381 in ?? ()
> > #35 0x102eef45 in ?? ()
> > #36 0x102f5743 in ?? ()
> > #37 0x104be86a in ?? ()
> > #38 0x104be954 in ?? ()
> > #39 0x104bec0c in ?? ()
> > #40 0x104c014e in ?? ()
> > #41 0x1051dbd3 in ?? ()
> > #42 0x00419968 in eval ()
> > #43 0x0041a93d in fLeval ()
> > #44 0x0042c4aa in c_apply_n ()
> > #45 0x004421c1 in IapplyVector ()
> > #46 0x0041897a in funcall ()
> > #47 0x00419953 in eval ()
> > #48 0x004184c3 in funcall ()
> > #49 0x00419953 in eval ()
> > #50 0x0041a93d in fLeval ()
> > #51 0x0042c4aa in c_apply_n ()
> > #52 0x004421c1 in IapplyVector ()
> > #53 0x0041897a in funcall ()
> > #54 0x0051e95e in LI1 ()
> > #55 0x0041ac32 in quick_call_sfun ()
> > #56 0x00418912 in funcall ()
> > #57 0x00442329 in IapplyVector ()
> > #58 0x00419e3d in fLfuncall ()
> > #59 0x0042c4aa in c_apply_n ()
> > #60 0x004421c1 in IapplyVector ()
> > #61 0x0041897a in funcall ()
> > #62 0x00419953 in eval ()
> > #63 0x004184c3 in funcall ()
> > #64 0x00419953 in eval ()
> > #65 0x004184c3 in funcall ()
> > #66 0x004027a1 in main ()
> > (gdb) c
> > Continuing.
> > Hardware watchpoint 3: *(int *) 271436732
> >
> > Old value = -922746880
> > New value = -907012862
> > 0x00462d0e in fasload ()
> > 1: /x *((char *) 271436732 - 16) @ 32 = {0x8, 0x6a, 0x1, 0x68, 0x64,
> 0xcc,
> > 0x2d, 0x10, 0xff, 0x35, 0x54, 0xcc, 0x2d, 0x10, 0xe8, 0xe9, 0x2, 0x15,
> 0xf0,
> > 0xc9, 0xc3, 0x8d, 0x76, 0x0, 0x55, 0x89, 0xe5, 0x8d, 0x55, 0xc, 0x83,
> 0xec}
> > ;;; !!! Current last line of ACL2 output is STILL: "Loading gazonk520.o"
> > (gdb) bt
> > #0 0x00462d0e in fasload ()
> > #1 0x004229a1 in Lload ()
> > #2 0x00419968 in eval ()
> > #3 0x00455d39 in Fprogn ()
> > #4 0x004344ca in Flet ()
> > #5 0x00419a4e in eval ()
> > #6 0x00415995 in Funless ()
> > #7 0x00419a4e in eval ()
> > #8 0x00455d39 in Fprogn ()
> > #9 0x004344ca in Flet ()
> > #10 0x00419a4e in eval ()
> > #11 0x004151c8 in Fcond ()
> > #12 0x00419a4e in eval ()
> > #13 0x004184c3 in funcall ()
> > #14 0x00419953 in eval ()
> > #15 0x0041a93d in fLeval ()
> > #16 0x0042c4aa in c_apply_n ()
> > #17 0x0044246f in Iinvoke_c_function_from_value_stack ()
> > #18 0x0041a8f5 in Leval ()
> > #19 0x1051a392 in ?? ()
> > #20 0x1051a955 in ?? ()
> > #21 0x0041acc0 in quick_call_sfun ()
> > #22 0x00418912 in funcall ()
> > #23 0x102b0ee6 in ?? ()
> > #24 0x102a5624 in ?? ()
> > #25 0x103d77f1 in ?? ()
> > #26 0x1043163b in ?? ()
> > #27 0x10436e21 in ?? ()
> > #28 0x0041acab in quick_call_sfun ()
> > #29 0x102ec9b7 in ?? ()
> > #30 0x102ee171 in ?? ()
> > #31 0x102ee381 in ?? ()
> > #32 0x102eef45 in ?? ()
> > #33 0x102f5743 in ?? ()
> > #34 0x104be86a in ?? ()
> > #35 0x104be954 in ?? ()
> > #36 0x104bec0c in ?? ()
> > #37 0x104c014e in ?? ()
> > #38 0x1051dbd3 in ?? ()
> > #39 0x00419968 in eval ()
> > #40 0x0041a93d in fLeval ()
> > #41 0x0042c4aa in c_apply_n ()
> > #42 0x004421c1 in IapplyVector ()
> > #43 0x0041897a in funcall ()
> > #44 0x00419953 in eval ()
> > #45 0x004184c3 in funcall ()
> > #46 0x00419953 in eval ()
> > #47 0x0041a93d in fLeval ()
> > #48 0x0042c4aa in c_apply_n ()
> > #49 0x004421c1 in IapplyVector ()
> > #50 0x0041897a in funcall ()
> > #51 0x0051e95e in LI1 ()
> > #52 0x0041ac32 in quick_call_sfun ()
> > #53 0x00418912 in funcall ()
> > #54 0x00442329 in IapplyVector ()
> > #55 0x00419e3d in fLfuncall ()
> > #56 0x0042c4aa in c_apply_n ()
> > #57 0x004421c1 in IapplyVector ()
> > #58 0x0041897a in funcall ()
> > #59 0x00419953 in eval ()
> > #60 0x004184c3 in funcall ()
> > #61 0x00419953 in eval ()
> > #62 0x004184c3 in funcall ()
> > #63 0x004027a1 in main ()
> > (gdb) c
> >
> > Continuing.
> >
> > At this point it continued on well past gazonk520 (and gazonk521,
> gazonk522,
> > ...) so I killed it.
> >
> > > Take care,
> >
> > Let me know if you need anything else. It should be easy enough to set
> you up
> > on Jared's machine -- I could presumably copy over the small
> modifications I
> > made to ACL2 in support of these experiments.
> >
> > Thank you for your responsiveness. I'd appreciate any further opinions
> on
> > whether we should proceed with the ACL2 2.9 release Saturday morning.
> >
> > -- Matt
> >
> > > >
> > > > If you can reproduce with gcl built with --enable-debug, then
> > > >
> > > > I don't seem to have the gcl sources yet....
> > > >
> > > > 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
> > > >
> > > > Feel free to send further instructions. I'm heading into work
> shortly, but I
> > > > can do some more tonight.
> > > >
> > > > -- Matt
> > > >
> > > >
> > > > _______________________________________________
> > > > Gcl-devel mailing list
> > > > address@hidden
> > > > http://lists.gnu.org/mailman/listinfo/gcl-devel
> > > >
> > > >
> > > >
> >
> > > --
> > > Camm Maguire address@hidden
> > >
> ==========================================================================
> > > "The earth is but one country, and mankind its citizens." --
> Baha'u'llah
> >
> >
> >
> > _______________________________________________
> > Gcl-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gcl-devel
> >
> >
> >
>
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
>
--
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, 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, 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/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 <=
- 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
- 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
- RE: [Gcl-devel] Re: possible GCL/Windows compiler bug, Mike Thomas, 2004/10/18
- RE: [Gcl-devel] Re: possible GCL/Windows compiler bug, Mike Thomas, 2004/10/19
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Matt Kaufmann, 2004/10/23
- RE: [Gcl-devel] Re: possible GCL/Windows compiler bug, Mike Thomas, 2004/10/25
- Re: [Gcl-devel] Re: possible GCL/Windows compiler bug, Camm Maguire, 2004/10/25