Crash to LDB in backtrace from internal-error when built with gcc-4.3

Bug #999972 reported by Alastair Bridgewater on 2012-05-15
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Found this one on a lightly-loaded test server. If the SBCL runtime is compiled with gcc-4.3 (but not with gcc-4.4), and a GC occurs while doing a backtrace when there's an internal-error trap context on the stack, the system fails a GC assertion at the bottom of scavenge(). Found on (x86), confirmed on 1.0.23 (x86-64), 1.0.35 (x86), and (x86).

Again, this only happens when compiling with gcc-4.3, and I have only tested on x86 and x86-64 linux boxes.

My primary questions are: Why does this happen? Why doesn't it happen with gcc-4.4? And, finally, how do we know that nothing similar (or worse) happens in such scenarios, regardless of which compiler is used?

nyef@kana:~/src/lisp/sbcl$ echo "*features* (load (compile-file \"backtrace-test.lisp\")) (dotimes (i 5000) (try-to-break))" | sh ./sbcl-git/
(running SBCL from: /home/nyef/src/lisp/sbcl/sbcl-git)
This is SBCL, an implementation of ANSI Common Lisp.
More information about SBCL is available at <>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
; compiling file "/home/nyef/src/lisp/sbcl/backtrace-test.lisp" (written 09 MAY 2012 10:22:19 PM):
; compiling (DEFUN TESTFUN ...)
; compiling (DEFUN MAYBE-DIE ...)
; compiling (DEFUN TRY-BACKTRACE ...)
; compiling (DEFUN TRY-TO-BREAK ...)

; /home/nyef/src/lisp/sbcl/backtrace-test.fasl written
; compilation finished in 0:00:00.058
* Final object pointer 0x18e441d0, start 0xc722000, end 0xc722270
fatal error encountered in SBCL pid 1834(tid 4158908096):
GC invariant lost, file "gc-common.c", line 191

Welcome to LDB, a low-level debugger for the Lisp runtime environment.

This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers