Opened 9 years ago
Closed 9 years ago
#758 closed defect (fixed)
ARM-specific error during compilation
| Reported by: | gb | Owned by: | gb |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Runtime (threads, GC) | Version: | trunk |
| Keywords: | Cc: |
Description
During compilation (often if not always during compilation of some file in "ccl:level-0;ARM;"), our build system sometimes gets the following error (or something very, very much like it):
> Error: value 0 is not of the expected type LIST. > While executing: MEMEQL, in process listener(1).
This is ultimately due to the fact that *FEATURES* is getting bound to '(0 . 0) in COMPILE-FILE, but it's not clear how/why that happens.
In the backtrace in:
http://setf.clozure.com:8010/builders/linuxarm/builds/72/steps/shell_2/logs/stdio
the local variable VALUES has the value ((0 . 0)), and *FEATURES* is bound to the CAR of that value (via PROGV.) VALUES is effectively bound to the value returned by:
(list (append nil *features*))
I've seen this happen, but haven't yet been able to determine why. There are lots of suspects ...
Change History (2)
comment:1 Changed 9 years ago by gb
- Owner set to gb
- Status changed from new to assigned
comment:2 Changed 9 years ago by gb
- Resolution set to fixed
- Status changed from assigned to closed
(In [14495]) arm-gc.c: GC integrity checks check cstack on ARM. arm-spentry.s: in progvsave: since we use the last physical word in the stack-consed gvector in which special-bindings are saved, the element-count of that gvector must be odd.
Fixes ticket:758.
I had this happen again, after fixing several bugs in pc_luser_xp().
GC integrity checks complain that the (0 . 0) points to free heap space, which suggests a bug in the forwarder (possibly forward_xp()).