Opened 12 years ago
Closed 12 years ago
#379 closed defect (fixed)
results of HEAP-UTILIZATION on x8632 are fishy
Reported by: | rme | Owned by: | gb |
---|---|---|---|
Priority: | minor | Milestone: | IA-32 port |
Component: | Runtime (threads, GC) | Version: | trunk |
Keywords: | Cc: |
Description
Welcome to Clozure Common Lisp Version 1.3-dev-r11353M-trunk (DarwinX8632)! ? (heap-utilization) Object type Count Total Size in Bytes CONS 126038 1008304 BOGUS 3 0 BIGNUM 149 1156 SHORT-FLOAT 24 96 DOUBLE-FLOAT 12 144 COMPLEX 1 8 MACPTR 139 2636 FUNCTION 12138 5348712 BASIC-STREAM 34 22355952 SYMBOL 34835 975380 XCODE-VECTOR 1 0 LOCK 120 2880 HASH-TABLE-VECTOR 72 324848 POOL 23 92 POPULATION 22 268 PACKAGE 15 480 SLOT-VECTOR 4628 199512 STANDARD-INSTANCE 4183 50196 STRUCTURE 3283 123116 INTERNAL-STRUCTURE 2587 67232 VALUE-CELL 19 76 SIMPLE-VECTOR 23960 1089208 SIMPLE-UNSIGNED-LONG-VECTOR 1 4092 SIMPLE-BASE-STRING 7683 473928 SIMPLE-BIT-VECTOR 1 2097152
Those BASIC-STREAM objects are pretty heavyweight...not to mention the presence of BOGUS and XCODE-VECTOR objects that take up no space.
Change History (4)
comment:1 Changed 12 years ago by gb
comment:2 Changed 12 years ago by gb
Trying to save an image on win32:
? (save-application "new.image") > Error: Fault during read of memory address #x97 > While executing: CCL::STD-INSTANCE-CLASS-CELL-TYPEP, in process Initial(0). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 >
This is almost certainly the heap walk in CLEAR-IOBLOCK-STREAMS. (It's likely easier to debug the HEAP-UTILIZATION case by setting a breakpoint when we increment an impossible/bogus type's count/size, or when we find one of these gigantic BASIC-STREAMs.)
comment:3 Changed 12 years ago by gb
- Status changed from new to assigned
This might be fixed by r11363 (at the very least, HEAP-UTILIZATION results look less fishy.)
One way to debug this:
- define a stack frame slot "prev" in each of WALK-STATIC-AREA and %WALK-DYNAMIC-AREA.
- in each function, store "obj" in "prev" after doing the call (and before incrementing "obj".
- set a breakpoint on some anomalous condition in the function (e.g., a BASIC-STREAM with more than 10 elements). When the breakpoint (ccl::dbg) is reached, step through the code on return, look at "prev", maybe set "obj" to "prev" and step through the code that tries to skip past it to the next object.
The "prev" register variable in the PPC and x8664 versions of these functions exists solely for this reason.
comment:4 Changed 12 years ago by gb
- Resolution set to fixed
- Status changed from assigned to closed
The win32 lisp that couldn't save an image reliably was able to do so after r11363, so it looks like this is fixed. Knock wood.
Perhaps some of the BOGUS objects are of negative size and others have positive sizes. These things even out ...
I got an x8632 FreeBSD mostly working the other day. The cross-compiled version would fault in CLEAR-IOBLOCK-STREAMS, which walks the heap just before an image is saved. I commented that out and built it natively and eventually reenabled the call to CLEAR-IOBLOCK-STREAMS, but it may be that there are still some problems in %WALK-DYNAMIC-AREA. (I was willing to blame that on cross-compilation artifacts, but it's not clear what those unspecified artifacts would be.)