From: Raymond W. <ra...@or...> - 2000-03-08 13:05:19
|
Douglas T. Crosher writes: > Raymond Wiker wrote: > ... > > William Harold Newman writes: > > > On Tue, Mar 07, 2000 at 11:45:11AM +0100, Raymond Wiker wrote: > > > > Question: in output/cold-sbcl.map, there are two addresses > > > > listed for each function, and it appears that the difference between > > > > the first and the last (which appears in a comment) is 0x17. Could > > > > anyone tell me what these two addresses are? (My guess is that the > > > > first is the entry point, and the second is the header address, but > > > > this may well be wrong :-) > > Yes, one is the raw entry address and the other the object with its > function tag. Ok. > ... > > The crash happens when scan_fdefn is called for an fdefn > > structure with the following data: > > > > 0x480add38: 0x000003b6 (fdefn header) > > 0x480add3c: 0x480add07 (name(?), other pointer) > > 0x480add40: 0x4d64d4f9 (function, function pointer, val = 0x4d64d4f8) > > 0x480add44: 0x08<something> (raw_addr, = closure_tramp (from x86-assem.S) ) > > > > 0x4d64d4f8: 0x00000382 (simple array signed byte 30) ??? > > The header values appear to differ from the CMUCL values as none of > the CMUCL branches has the fdefn object with a header value of > 0xb6. I think this is to be expected, given the differences in the build pricess between SBCL and CMUCL. Might be helpful to compare sbcl.h between a Linux and a FreeBSd build of SBCL, though. > > This fdefn object is the only object where the second branch > > of the if test in scav_fdefn is called - at least, up to that > > point. As a result, the values (lispobjs) that follow are treated obe > > by one, and eventually, the foreign address for closure_tramp is > > treated like a lispobj. Ka-boom :-) > > Check the raw_addr of the closure_tramp; if correctly aligned it > should appear to be a fixnum and thus be safe to scavenge. Hmmm... It doesn't appear to be aligned so that it looks like a fixnum; I could probably fix this by changing x86-assem.S. > > closure_tramp should never appear like this. The reference to > > 0x4d64d4f8 seems odd, as does the values stored in that area. > > Yes, if this were a vector it would be invalid; double check the > header values. For standard CMUCL the header of 0x82 = 130 is a > closure header? > > I'd be very keen to track down any such bug. If it is repeatable > on standard CMUCL could someone please point me towards an example. It's *probably* not a CMUCL bug, unless it's related to ELF/a.out differences or something like that. //Raymond. |