backtracing can construct bogus objects
Bug #310175 reported by
Nikodemus Siivola
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
High
|
Unassigned |
Bug Description
Due to conservative stack backtracing can construct bogus objects,
which can lead the GC astray.
Enabling heap sanity checks (details of how to do that here) catches
badness during tests.
Changed in sbcl: | |
status: | New → Incomplete |
Changed in sbcl: | |
importance: | Undecided → High |
status: | Incomplete → Confirmed |
Changed in sbcl: | |
assignee: | nobody → Nikodemus Siivola (nikodemus) |
Changed in sbcl: | |
status: | Triaged → In Progress |
tags: | added: pending |
tags: | removed: pending |
Changed in sbcl: | |
assignee: | Nikodemus Siivola (nikodemus) → nobody |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
This bug description appears to be badly worded. Perhaps the following (providing more information) is better?
"Due to the unique nature of the x86 and x86-64 ports (conservative stack scavenging, no separate number stack, sharing the control stack with alien code), invalid pointers to within heap space may be constructed when performing a backtrace, which then can cause problems detectable via the GC heap sanity checks (not normally enabled).
"To enable the heap sanity checks, edit gencgc.c and set verify_gens to a lower number (such as 0, to verify after every GC), and optionally set pre_verify_gen_0 to a non-zero value. Alternately, use WITH-ALIEN or an EXTERN-ALIEN to access them from Lisp."
As an update to the present description, this isn't bad. However, after updating the heap sanity checks in 1.0.38.2 to account for per-thread storage (mainly control stacks, for d-x allocation), the test suite no longer has any additional failures or problems with the sanity checks enabled, thus this bug may actually have been fixed (not that we don't have other backtrace bugs).