backtracing can construct bogus objects

[Nikodemus Siivola]

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.

[Alastair Bridgewater (alastair-bridgewater)]

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).

[Nikodemus Siivola (nikodemus)]

One issue remains:

BACKTRACE-AS-LIST can return bogus objects due to stack-allocation. It should replace stack-allocated function arguments with placeholders instead.

[Nikodemus Siivola (nikodemus)]

In SBCL 1.0.46.1.