gcl-devel
[Top][All Lists]
Advanced

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

RE: [Gcl-devel] HEAD Maxima and HEAD trad GCL


From: Mike Thomas
Subject: RE: [Gcl-devel] HEAD Maxima and HEAD trad GCL
Date: Wed, 7 Jan 2004 14:34:36 +1000

Hi Camm.

Thanks for the detailed feedback, am digesting it.

| What you want to do now is set a break point at funlink.c:71 (Though
| in my source the line you appear to be at is 55???), conditionalize it
| as follows:

Possibly the line number is different because I'm using HEAD rather than
stable CVS?


|
| cond <break number> fun->cf.cf_self == 0x1030c130
|
| Also set a break at the troublesome address:
|
| b *0x1030c130
|
| run, and at the first breakpoint, please do
|
| p fun->cf.cf_name->st
|
| and then continue once, where you should be at the address above.
| Then you can do disassemble.

OK, I have to set the breakpoint at *0x1030c130 (breakpoint 2) AFTER I get
to the conditionalised breakpoint 1 otherwise I get:

(gdb) run
Starting program: c:\cvs\head\gcl\pcl/../unixport/saved_gcl.exe
Warning:
Cannot insert breakpoint 2.
Error accessing memory address 0x1030c130: Input/output error.

After getting there, the disassembly fails:

============================================================================
===
$ gdb --directory ../o --directory ../lsp --directory ../mod --directory
../cmp
new --directory ../gmp3 --directory ../h --directory ../unixport --directory
..
/clcs ../unixport/saved_gcl.exe
GNU gdb 6.0
Copyright 2003 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 funlink.c:71
Breakpoint 1 at 0x4314a4: file funlink.c, line 71.
(gdb) cond 1 fun->cf.cf_self == 0x1030c130
(gdb) r
Starting program: c:\cvs\head\gcl\pcl/../unixport/saved_gcl.exe
        0x005407A0 BSS start in memory.
        0x004e0000 BSS offset in saved executable.
        0x00113710 BSS size in bytes.
        0x00113710 bytes read.
        0x10100000 Heap start in memory.
        0x00400000 Heap offset in executable.
        0x000e0000 Heap size in bytes.
        0x10100000 file base.
GCL (GNU Common Lisp)  (2.7.0) Mon Jan  5 18:01:01 EAST 2004
Licensed under GNU Library General Public License
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>(load "../clcs/package.lisp")

Loading ../clcs/package.lisp
Finished loading ../clcs/package.lisp

.. blah blah ..

Loading binary of PCL_FAST_INIT...
Loading binary of PCL_BRAID...

Breakpoint 1, call_or_link (sym=0x1022c3a8, link=0x1031d57c) at funlink.c:71
71                  ( *(void (*)()) (fun->cf.cf_self)) ();
(gdb) p fun->cf.cf_name->st
$1 = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced = 0x0,
  st_hasfillp = 4784, st_adjustable = 84,
  st_self = 0x103ce800 "GET-DFUN-CONSTRUCTORWRAPPER1WRAPPER0ACCESSOR-TYPE",
  st_fillp = 20, st_dim = 270352720}
(gdb) b *0x1030c130
Breakpoint 2 at 0x1030c130
(gdb) c
Continuing.

Breakpoint 2, 0x1030c130 in ?? ()
(gdb) disassemble
No function contains program counter for selected frame.

(gdb) whatis 0x1030c130
type = int
(gdb) *0x1030c130
Undefined command: "".  Try "help".
(gdb) whatis *0x1030c130
type = int
(gdb) bt
#0  0x1030c130 in ?? ()
#1  0x004314ac in call_or_link (sym=0x1022c3a8, link=0x1031d57c)
    at funlink.c:71
#2  0x1031cb77 in ?? ()
#3  0x1022c3a8 in ?? ()
#4  0x1031d57c in ?? ()
#5  0x10268858 in ?? ()
#6  0x1030e4b7 in ?? ()
#7  0x10242c3c in ?? ()
#8  0x005a57e0 in small_fixnum_table ()
#9  0x1031f054 in ?? ()
#10 0x1030e4eb in ?? ()
#11 0x00000630 in ?? ()
#12 0x00000630 in ?? ()
#13 0x005b0e8c in value_stack ()
#14 0x1037c6f0 in ?? ()
#15 0x1031f054 in ?? ()
#16 0x10344ec4 in ?? ()
#17 0x005b0e9c in value_stack ()
#18 0x005b0e88 in value_stack ()
#19 0x005b0e78 in value_stack ()
#20 0x005a7c20 in sLAprint_baseA ()
#21 0x0022bee8 in ?? ()
---Type <return> to continue, or q <return> to quit---q
Quit (expect signal SIGINT when the program is resumed)
(gdb) p/x *0x1030c130
$2 = 0x53565755

(gdb) up
#1  0x004314ac in call_or_link (sym=0x1022c3a8, link=0x1031d57c)
    at funlink.c:71
71                  ( *(void (*)()) (fun->cf.cf_self)) ();
(gdb)  p fun->cf.cf_name->st
$6 = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced = 0x0,
  st_hasfillp = 4784, st_adjustable = 84,
  st_self = 0x103ce800 "GET-DFUN-CONSTRUCTORWRAPPER1WRAPPER0ACCESSOR-TYPE",
  st_fillp = 20, st_dim = 270352720}
(gdb) p sym->s
$7 = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', m = 0 '\0', s_dbind = 0x0,
  s_sfdef = 0x5412b0 <Cnil_body>,
  st_self = 0x103ce800 "GET-DFUN-CONSTRUCTORWRAPPER1WRAPPER0ACCESSOR-TYPE",
  st_fillp = 20, s_gfdef = 0x101d4150, s_plist = 0x1020b030,
  s_hpack = 0x10103d00, s_stype = 0, s_mflag = 0}
(gdb) p sym->s.s_gfdef->cf
$8 = {t = 20 '\024', flag = 0 '\0', s = 0 '\0', m = 0 '\0',
  cf_name = 0x1022c3a8, cf_self = 0x1030c130, cf_data = 0x102d6294}
(gdb) p sym->s.s_gfdef->cf.cf_name->st
$9 = {t = 8 '\b', flag = 0 '\0', s = 0 '\0', m = 0 '\0', st_displaced = 0x0,
  st_hasfillp = 4784, st_adjustable = 84,
  st_self = 0x103ce800 "GET-DFUN-CONSTRUCTORWRAPPER1WRAPPER0ACCESSOR-TYPE",
  st_fillp = 20, st_dim = 270352720}
(gdb)


============================================================================
===



| You or we can then look for suspicious
| points at which the program jumps to the spurious 0x0022be88 listed in
| stack 11.





| I can only imagine three possibilities right now, with the third the
| most likely
|
| 1) The address reported for fun->cf.cf_self is wrong/corrupted.  This
|    could be due to a relocation error when the module containing it
|    was loaded.  I can show you how to trap the address at relocation
|    time if this appears to be the case.
|
| 2) There is a missing flush of the data cache as is required on some
|    architectures in calling addresses dynamically loaded into the
|    .data section (e.g. arm, several others).  This is definitely not
|    needed on Linux x86 and sparc (as well as several others), and when
|    it does show up, one often gets non-reproducible behavior, so I'm
|    doubting this one.
|
| 3) Some earlier corruption has been introduced into the body of this
|    function (or perhaps its address) as a result of earlier resettings
|    of function pointers in call_link -- after all this problem goes
|    away without fast-linking.  When we get the function name and
|    disassembly, we can set harwared watchpoints to detect when the
|    spurious values get introduced.

OK, applying what little I understand about this to your three suggestions:

I take it that the unsuccessful attempt to disassemble the function implies
that the address is incorrect. (I'm assuming that corruption of the function
body itself does not affect whether the debugger thinks that the address
points to an executable function body or not)?

Because the problem is reproducible across at least three different machines
we can likely discount 2?

Grateful for further orders!

Mike Thomas.






reply via email to

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