[armedbear-ticket] [armedbear] #89: compiler stack inconsistency
#89: compiler stack inconsistency ----------------------+----------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: 0.20 Keywords: | ----------------------+----------------------------------------------------- In checking out the latest ASDF, I was able to factor out the following case of the compiler generating stack inconsistency: {{{ (defun get-uid (stream uid-string) (with-input-from-string (stream uid-string) (read-line stream) (handler-case (parse-integer (read-line stream)) (error () (error "Unable to find out user ID"))))) }}} Loading the generated code causes a java.lang.VerifyError to be thrown. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by mevenson): Simplified test case (which only produces one stack inconsistency message): {{{ (defun get-uid () (let ((stream (make-string-input-stream "foo" 0))) (read-line stream) (handler-case 42))) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:1> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by mevenson): Without a HANDLER-CASE: {{{ (defun f () (let ((stream (make-string-input-stream "f" 0))) (read-line stream) (lambda () (return-from f)))) }}} -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:2> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by mevenson): Attaching a patch which fixes the last two test cases, but not the original. I suspect that this error was introduced in r12170, which means that P2 -TAGBODY-NODE needs the same sort of fix. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:3> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 0.20 Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by mevenson): * milestone: => 0.20 Comment: That patch doesn't do as much as I had hoped, as the analysis of the problem here is still rather incomplete. Erik has suggested that due to the heavy use of specials in P2, it is rather hard to follow any sufficiently complicated example as the information as to which code sections corresponds to which handler quickly get lost. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:4> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: major | Milestone: 0.20 Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by mevenson): r12620 patches the system to use the interpreted form if a stack inconsistency is detected. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:5> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 0.21 Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann): * priority: major => critical * milestone: 0.20 => 0.21 Comment: Alessio tested this on 0.18.1 and there's no regression here, so, while I do find this a critical prio issue (and raising to that level); I don't see a blocker - not a regression. Increasing milestone to 0.21. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:6> armedbear <http://common-lisp.net/project/armedbear> armedbear
I tracked this back to before the split of 'abcl' from 'j' observing the error through [rev0 of the copy of abcl][1] I keep in Mercurial], so can confirm the lack of regression back to 2008-12-20. 0 e7def953d497 2008-12-20 20:35 +0100 ehuelsmann [svn r11457] Create separate project directories for ABCL and J. [1]: http://trac.common-lisp.net/armedbear/changeset/11457/trunk/abcl -- "No, this is not a disentanglement from, but a progressive /knotting-into/ […]"
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: new Priority: critical | Milestone: 0.21 Component: compiler | Version: 0.20 Resolution: | Keywords: -----------------------+---------------------------------------------------- Comment(by mevenson): Attached a sketch of the idea that came to my mind biking to work today. Essentially, I don't think we have a graph that is very interesting. What we have is a linear list of instructions for which there are various line segments associated with each excution path. Each such path has an expected stack height that would best be represented as a "height" as displacement from the axis of the linear list of instructions. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:7> armedbear <http://common-lisp.net/project/armedbear> armedbear
#89: compiler stack inconsistency -----------------------+---------------------------------------------------- Reporter: mevenson | Owner: ehuelsmann Type: defect | Status: closed Priority: critical | Milestone: 0.21 Component: compiler | Version: 0.20 Resolution: fixed | Keywords: -----------------------+---------------------------------------------------- Changes (by ehuelsmann): * status: new => closed * resolution: => fixed Comment: (In [12639]) Fix #89: Stack inconsistency error when discarding READ-LINE return value. -- Ticket URL: <http://trac.common-lisp.net/armedbear/ticket/89#comment:8> armedbear <http://common-lisp.net/project/armedbear> armedbear
participants (2)
-
armedbear -
Mark Evenson