AVER, MEMQ ... END-STACK failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
High
|
Unassigned |
Bug Description
Perhaps related to 1722342.
Found with random tester. Two failures were found, which may or may not be related. I have included both.
(defun f3 (x)
(block b1
(multiple-
(block b2 (return-from b1 (catch 'c (return-from b2 x)))))))
debugger invoked on a SB-INT:BUG in thread
#<THREAD "main thread" RUNNING {100192EAB3}>:
failed AVER: (NOT (SB-INT:MEMQ PUSH SB-C::END-STACK))
-------------
(defun f4 ()
(block b1
(multiple-
(tagbody
tag4))))
debugger invoked on a SB-INT:BUG in thread
#<THREAD "main thread" RUNNING {100192EAB3}>:
failed AVER: (NOT (SB-INT:MEMQ PUSH SB-C::END-STACK))
Changed in sbcl: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
These two failures, yes, are related to each other. One of them is virtually identical to the case reported on the mailing list on the 29th of March this year.
In both cases, what's happening is that MAYBE-DELETE-EXIT is deleting an EXIT with no value semantics (either because it's a TAGBODY/GO or because it's returning to a block whose value is simply being ignored), removing it from the ENTRY. From there, MAY-DELETE- VESTIGIAL- EXIT sees that the ENTRY has no EXITs leading to it, and thus decides that there won't be any cleanup code generated for it, which turns out not to be the case.
Test cases added to compiler.pure.lisp in 9acc615ae49d6fa efe7e5a83216c12 15be18f858, because we might as well do it now, even if we don't have a fix yet.
As a side note, it appears as though ONLY-HARMLESS- CLEANUPS, as used by MAYBE-CONVERT- TAIL-LOCAL- CALL, will make the same determination with respect to cleanup code generation, which suggests that there may be a bug there as well.