Stack overflowing recursion of SB-PCL::UPDATE-CLASS while compiling defmethod's
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
High
|
Unassigned |
Bug Description
Our large application QRes has a web of classes, with forward references to superclasses and to classes referred in methods and typechecking declarations. It compiles and runs fine with CCL 1.8, and compiles and mostly runs fine with SBCL 1.0.41.
While trying to update our SBCL, I find that it enters the low-level debugger with a stack overflow while compiling some defmethod or some other, with a backtrace that involves a great number of repetitions of the pattern below. Depending on whether I compile from clean or retry with previously built fasl, the failure moves, suggesting that the behavior is affected by side-effects of compile-file not present in the fasl. Also, the first failure (as reproducible by building from clean) can be averted by a
(eval-when (:compile-toplevel)
(sb-mop:
which suggests that SBCL is failing to automatically maintain the state of its inheritance graph.
There's a whole pile of infrastructure, and my feeble attempts at reproducing the bug on my side have been unsuccessful so far, but I could try harder.
The bug affects at least sbcl 1.0.56.60, 1.0.56, 1.0.55, 1.0.54, 1.0.53. I haven't tried 1.0.52 or earlier yet, which were known to have another bug preventing the compilation of this code base. Sigh.
Note: I am running on linux/x64.
It seems that my optimization settings while compiling and getting these errors are:
(optimize (speed 1) (space 1) (safety 3) (debug 3) (compilation-speed 1))
Changed in sbcl: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in sbcl: | |
assignee: | nobody → Nikodemus Siivola (nikodemus) |
status: | Confirmed → In Progress |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
status: | Fix Released → Fix Committed |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
Note that there's a cycle of length 2 in the backtrace (elided in the attachment) between classes LEGACY-PNR and LEGACY-PNR-PAX, where each class refers to the other one in the :type declarations of its slots, its associated methods, and more places that may or may not matter.
I will attach a full cycle.? field.comment= Note that there's a cycle of length 2 in the backtrace (elided in the attachment) between classes LEGACY-PNR and LEGACY-PNR-PAX, where each class refers to the other one in the :type declarations of its slots.
I will attach a full cycle.