From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.bugs Subject: bug#14141: Abort in RTL VM Date: Fri, 5 Apr 2013 13:29:25 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec5299451e72d3704d9a06edb X-Trace: ger.gmane.org 1365278734 30943 80.91.229.3 (6 Apr 2013 20:05:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Apr 2013 20:05:34 +0000 (UTC) Cc: 14141 <14141@debbugs.gnu.org> To: Noah Lavine Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat Apr 06 22:05:32 2013 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UOZJV-0007UX-PR for guile-bugs@m.gmane.org; Sat, 06 Apr 2013 22:02:14 +0200 Original-Received: from localhost ([::1]:54167 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOATX-0004Ax-Ly for guile-bugs@m.gmane.org; Fri, 05 Apr 2013 13:30:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOATQ-0004Ai-NK for bug-guile@gnu.org; Fri, 05 Apr 2013 13:30:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UOATO-0000iP-83 for bug-guile@gnu.org; Fri, 05 Apr 2013 13:30:48 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOATN-0000iK-Un for bug-guile@gnu.org; Fri, 05 Apr 2013 13:30:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UOAWY-00048J-0W for bug-guile@gnu.org; Fri, 05 Apr 2013 13:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noah Lavine Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 05 Apr 2013 17:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14141 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 14141-submit@debbugs.gnu.org id=B14141.136518318515807 (code B ref 14141); Fri, 05 Apr 2013 17:34:01 +0000 Original-Received: (at 14141) by debbugs.gnu.org; 5 Apr 2013 17:33:05 +0000 Original-Received: from localhost ([127.0.0.1]:35832 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOAVc-00046s-Bl for submit@debbugs.gnu.org; Fri, 05 Apr 2013 13:33:05 -0400 Original-Received: from mail-pd0-f174.google.com ([209.85.192.174]:53011) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOAVa-00046g-K5 for 14141@debbugs.gnu.org; Fri, 05 Apr 2013 13:33:03 -0400 Original-Received: by mail-pd0-f174.google.com with SMTP id p12so2131198pdj.19 for <14141@debbugs.gnu.org>; Fri, 05 Apr 2013 10:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=JLdNWGv9gl9NzkbuzTmtdLR3UktNplW+b4O2TFGpbCg=; b=EQ2gE7lw/Yx5T6HVSJM4pHN+mZKd+XRMIc39gNXJlJ+ysqGhaAgAyTaApiMH9p9jLD pOEqeCJ9OVT2IUUxb0jn8knbG8IVAi3AisEVXlFdGdPCsYv0strl0bXV4Cjxa4GKY2Tl hWVq6YTvAJDOAM1uSRmua01/NpLiQY4doMeyV4A+9oN9Hipm+Q0bwFujXqLdNDDp+2Y6 E8vauJM9tsrtmC+uXw0jEbuotieo6xTUlW2cUBrQCLkNDdr4Hj/BxCGqW9GNLxBjzcRb uo4g06PMGsS060q+kP4Q+xotvjDERPWvnRPMFEDvGitEivVP14oPtMpdqxi3qJFEgYF1 S+rA== X-Received: by 10.66.26.44 with SMTP id i12mr16725978pag.151.1365182985479; Fri, 05 Apr 2013 10:29:45 -0700 (PDT) Original-Received: by 10.68.157.42 with HTTP; Fri, 5 Apr 2013 10:29:25 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: SRmmuIiOa1SBj21qoFQdtcrbTBU X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7069 Archived-At: --bcaec5299451e72d3704d9a06edb Content-Type: text/plain; charset=ISO-8859-1 Hello, Just a quick update - it seems to be related to the order of the reserve-locals and bind-rest calls. If I reverse those, the problem goes away. However, I still don't know why this happens, and why the problem doesn't happen when the variables aren't boxed. I think there might be something weird going on in bind-rest when the argument is zero. It has a loop like this: while (nargs-- > dst) { ... }. When dst is zero, doesn't nargs end up getting set to -1? (Which, since it's unsigned, is really 2^32 - 1.) That might make any later instructions that use nargs (like reserve-locals) do odd things. Noah On Thu, Apr 4, 2013 at 3:44 PM, Noah Lavine wrote: > Oh, I forgot to mention one important fact. I *do* get the expected result > if I eliminate the stuff with boxes. This works fine: > > > scheme@(guile-user)> (assemble-program '((begin-program foo) > (assert-nargs-ge 0) > (reserve-locals 4) > (bind-rest 0) > (cache-current-module! 2 foo) > (cached-toplevel-ref 2 foo car) > (tail-call 1 2) > (end-program))) > > Best, > Noah > > On Thu, Apr 4, 2013 at 3:22 PM, Noah Lavine wrote: > >> Hello, >> >> I'm actually testing on the wip-rtl-cps branch, but this error involves >> code that I believe is the same on that branch and on the wip-rtl branch. >> Try opening a new Guile and doing the following: >> >> scheme@(guile-user)> (use-modules (system vm rtl)) >> scheme@(guile-user)> (assemble-program '((begin-program foo) >> (assert-nargs-ge 0) >> (reserve-locals 4) >> (bind-rest 0) >> (box 1 0) >> (cache-current-module! 2 foo) >> (cached-toplevel-ref 2 foo car) >> (box-ref 3 1) >> (mov 0 3) >> (tail-call 1 2) >> (end-program))) >> ... ... ... ... ... ... ... ... ... ... $1 = # >> scheme@(guile-user)> ($1 'hello) >> >> The expected result is >> $2 = hello >> >> What I actually get is, >> >> Program received signal SIGABRT, Aborted. >> 0x00007ffff7440425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 >> >> The full backtrace is below. The interesting part is that it seems to be >> tripping the check at libguile/vm-engine.c:1868, which checks whether an >> object is a variable before doing a box-ref on it. When I look at it in >> GDB, it seems that whatever is at register 1 does not satisfy >> scm_variable_p, although I'm not very experienced with debugging Guile. >> However, I am somewhat surprised at this, because I have used boxes and >> box-ref before in the past with no trouble. >> >> Another surprising thing is that if I open Guile, do some other things >> for a while, and then run this code, the problem sometimes doesn't appear. >> That is especially disturbing. >> >> Does anyone have any idea where the issue is or how I should find it? >> >> Thanks, >> Noah >> >> Here's the backtrace: >> >> (gdb) bt >> #0 0x00007ffff7440425 in raise () >> from /lib/x86_64-linux-gnu/libc.so.6 >> #1 0x00007ffff7443b8b in abort () >> from /lib/x86_64-linux-gnu/libc.so.6 >> #2 0x00007ffff7b30986 in rtl_vm_debug_engine (vm=0x6a6860, >> program=0xdcec90, argv=0x6a9548, nargs_=1) at vm-engine.c:1868 >> #3 0x00007ffff7b1aaf1 in vm_debug_engine (vm=0x6a6860, >> program=0xdcec90, argv=0x7fffffffd028, nargs=1) at vm-engine.c:419 >> #4 0x00007ffff7b38f6c in scm_c_vm_run (vm=0x6a6860, >> program=0x75dbe0, argv=0x7fffffffd028, nargs=1) at vm.c:791 >> #5 0x00007ffff7a5bff3 in scm_primitive_eval (exp=0x7fe7f0) >> at eval.c:691 >> #6 0x00007ffff7a5c0ad in scm_eval (exp=0x7fe7f0, >> module_or_state=0x7e0090) at eval.c:725 >> #7 0x00007ffff7acef2d in scm_shell (argc=1, argv=0x7fffffffe478) >> at script.c:441 >> #8 0x0000000000400bd0 in inner_main (closure=0x0, argc=1, >> argv=0x7fffffffe478) at guile.c:62 >> #9 0x00007ffff7a82663 in invoke_main_func (body_data=0x7fffffffe350) >> at init.c:336 >> #10 0x00007ffff7a563c9 in c_body (d=0x7fffffffe220) >> at continuations.c:513 >> #11 0x00007ffff7afc96c in apply_catch_closure (clo=0x81b360, >> args=0x304) at throw.c:146 >> #12 0x00007ffff7acf739 in apply_1 (smob=0x81b360, a=0x304) >> at smob.c:141 >> #13 0x00007ffff7b05cc8 in vm_regular_engine (vm=0x6a6860, >> program=0x7443e0, argv=0x7fffffffe0c0, nargs=2) >> at vm-i-system.c:873 >> #14 0x00007ffff7b38f6c in scm_c_vm_run (vm=0x6a6860, >> program=0x79d5d0, argv=0x7fffffffe0c0, nargs=4) at vm.c:791 >> #15 0x00007ffff7a5b793 in scm_call_4 (proc=0x79d5d0, arg1=0x404, >> arg2=0x81b360, arg3=0x81b340, arg4=0x81b320) at eval.c:513 >> #16 0x00007ffff7afc767 in scm_catch_with_pre_unwind_handler ( >> key=0x404, thunk=0x81b360, handler=0x81b340, >> pre_unwind_handler=0x81b320) at throw.c:86 >> #17 0x00007ffff7afca44 in scm_c_catch (tag=0x404, >> body=0x7ffff7a563a1 , body_data=0x7fffffffe220, >> handler=0x7ffff7a563d8 , handler_data=0x7fffffffe220, >> pre_unwind_handler=0x7ffff7a5642c , >> pre_unwind_handler_data=0x751160) at throw.c:213 >> #18 0x00007ffff7a5623d in scm_i_with_continuation_barrier ( >> body=0x7ffff7a563a1 , body_data=0x7fffffffe220, >> handler=0x7ffff7a563d8 , handler_data=0x7fffffffe220, >> pre_unwind_handler=0x7ffff7a5642c , >> pre_unwind_handler_data=0x751160) at continuations.c:451 >> #19 0x00007ffff7a564c3 in scm_c_with_continuation_barrier ( >> func=0x7ffff7a82613 , data=0x7fffffffe350) >> at continuations.c:547 >> #20 0x00007ffff7af97ba in with_guile_and_parent (base=0x7fffffffe290, >> base@entry=, >> data=0x7fffffffe2d0, >> data@entry=) >> at threads.c:907 >> #21 0x00007ffff71b6f55 in GC_call_with_stack_base ( >> fn=, arg=) at misc.c:1553 >> #22 0x00007ffff7af9894 in scm_i_with_guile_and_parent ( >> func=0x7ffff7a82613 , data=0x7fffffffe350, >> parent=0x0) at threads.c:950 >> #23 0x00007ffff7af98c0 in scm_with_guile ( >> func=0x7ffff7a82613 , data=0x7fffffffe350) >> at threads.c:956 >> #24 0x00007ffff7a825f4 in scm_boot_guile (argc=1, >> argv=0x7fffffffe478, main_func=0x400bac , closure=0x0) >> at init.c:319 >> #25 0x0000000000400c35 in main (argc=1, argv=0x7fffffffe478) >> at guile.c:81 >> >> >> > --bcaec5299451e72d3704d9a06edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Just a quick update - it seems to be re= lated to the order of the reserve-locals and bind-rest calls. If I reverse = those, the problem goes away. However, I still don't know why this happ= ens, and why the problem doesn't happen when the variables aren't b= oxed.

I think there might be something weird going on in bind-rest= when the argument is zero. It has a loop like this:

whil= e (nargs-- > dst) { ... }.

When dst is zero, doesn'= ;t nargs end up getting set to -1? (Which, since it's unsigned, is real= ly 2^32 - 1.) That might make any later instructions that use nargs (like r= eserve-locals) do odd things.

Noah


On Thu, Apr 4, 2013 at 3:44 PM, Noah Lavine <n= oah.b.lavine@gmail.com> wrote:
Oh, I forgot to mention one= important fact. I *do* get the expected result if I eliminate the stuff wi= th boxes. This works fine:


scheme@(guile-user)> (assemble-program '((begin-program foo)=
=A0(assert-nargs-ge 0)
=A0(reserve-locals 4)
=A0(bind-rest 0)
=A0(cache-current-module! 2 foo)
=A0(cached-toplevel-ref 2 foo car)
=A0(tail-call 1 2)
=A0(end-p= rogram)))

Best,
Noah
=
On Thu, Apr 4, 2013 at 3:22 PM, Noah Lavine <noah.b.lavine@gmail.c= om> wrote:
Hello,

I'm actually testing on the wip-rtl-cps branch, b= ut this error involves code that I believe is the same on that branch and o= n the wip-rtl branch. Try opening a new Guile and doing the following:

scheme@(guile-user)> (use-modules (system vm rtl))
scheme@(guile-= user)> (assemble-program '((begin-program foo)
=A0(assert-nargs-g= e 0)
=A0(reserve-locals 4)
=A0(bind-rest 0)
=A0(box 1 0)
=A0(ca= che-current-module! 2 foo)
=A0(cached-toplevel-ref 2 foo car)
=A0(box-ref 3 1)
=A0(mov 0 3)
= =A0(tail-call 1 2)
=A0(end-program)))
... ... ... ... ... ... ... ...= ... ... $1 =3D #<rtl-program dcec90 609bc0>
scheme@(guile-user)&g= t; ($1 'hello)

The expected result is
$2 =3D hello

Wha= t I actually get is,

Program received signal SIGABRT, Aborted.
0x= 00007ffff7440425 in raise () from /lib/x86_64-linux-gnu/libc.so.6

The full backtrace is below. The interesting part is that it see= ms to be tripping the check at libguile/vm-engine.c:1868, which checks whet= her an object is a variable before doing a box-ref on it. When I look at it= in GDB, it seems that whatever is at register 1 does not satisfy scm_varia= ble_p, although I'm not very experienced with debugging Guile. However,= I am somewhat surprised at this, because I have used boxes and box-ref bef= ore in the past with no trouble.

Another surprising thing is that if I open Guile, do some other things = for a while, and then run this code, the problem sometimes doesn't appe= ar. That is especially disturbing.

Does anyone have any i= dea where the issue is or how I should find it?

Thanks,
Noah

Here's the backtrace:<= br>
(gdb) bt
#0=A0 0x00007ffff7440425 in raise ()
=A0=A0 from /lib= /x86_64-linux-gnu/libc.so.6
#1=A0 0x00007ffff7443b8b in abort ()
=A0= =A0 from /lib/x86_64-linux-gnu/libc.so.6
#2=A0 0x00007ffff7b30986 in rtl_vm_debug_engine (vm=3D0x6a6860,
=A0=A0= =A0 program=3D0xdcec90, argv=3D0x6a9548, nargs_=3D1) at vm-engine.c:1868#3=A0 0x00007ffff7b1aaf1 in vm_debug_engine (vm=3D0x6a6860,
=A0=A0=A0 = program=3D0xdcec90, argv=3D0x7fffffffd028, nargs=3D1) at vm-engine.c:419 #4=A0 0x00007ffff7b38f6c in scm_c_vm_run (vm=3D0x6a6860,
=A0=A0=A0 prog= ram=3D0x75dbe0, argv=3D0x7fffffffd028, nargs=3D1) at vm.c:791
#5=A0 0x00= 007ffff7a5bff3 in scm_primitive_eval (exp=3D0x7fe7f0)
=A0=A0=A0 at eval.= c:691
#6=A0 0x00007ffff7a5c0ad in scm_eval (exp=3D0x7fe7f0,
=A0=A0=A0 module_or_state=3D0x7e0090) at eval.c:725
#7=A0 0x00007ffff7ac= ef2d in scm_shell (argc=3D1, argv=3D0x7fffffffe478)
=A0=A0=A0 at script.= c:441
#8=A0 0x0000000000400bd0 in inner_main (closure=3D0x0, argc=3D1, <= br>=A0=A0=A0 argv=3D0x7fffffffe478) at guile.c:62
#9=A0 0x00007ffff7a82663 in invoke_main_func (body_data=3D0x7fffffffe350)=A0=A0=A0 at init.c:336
#10 0x00007ffff7a563c9 in c_body (d=3D0x7fffff= ffe220)
=A0=A0=A0 at continuations.c:513
#11 0x00007ffff7afc96c in ap= ply_catch_closure (clo=3D0x81b360,
=A0=A0=A0 args=3D0x304) at throw.c:146
#12 0x00007ffff7acf739 in apply_1= (smob=3D0x81b360, a=3D0x304)
=A0=A0=A0 at smob.c:141
#13 0x00007ffff= 7b05cc8 in vm_regular_engine (vm=3D0x6a6860,
=A0=A0=A0 program=3D0x7443= e0, argv=3D0x7fffffffe0c0, nargs=3D2)
=A0=A0=A0 at vm-i-system.c:873
#14 0x00007ffff7b38f6c in scm_c_vm_run (v= m=3D0x6a6860,
=A0=A0=A0 program=3D0x79d5d0, argv=3D0x7fffffffe0c0, narg= s=3D4) at vm.c:791
#15 0x00007ffff7a5b793 in scm_call_4 (proc=3D0x79d5d0= , arg1=3D0x404,
=A0=A0=A0 arg2=3D0x81b360, arg3=3D0x81b340, arg4=3D0x81b320) at eval.c:513<= br>#16 0x00007ffff7afc767 in scm_catch_with_pre_unwind_handler (
=A0=A0= =A0 key=3D0x404, thunk=3D0x81b360, handler=3D0x81b340,
=A0=A0=A0 pre_un= wind_handler=3D0x81b320) at throw.c:86
#17 0x00007ffff7afca44 in scm_c_catch (tag=3D0x404,
=A0=A0=A0 body=3D0x= 7ffff7a563a1 <c_body>, body_data=3D0x7fffffffe220,
=A0=A0=A0 hand= ler=3D0x7ffff7a563d8 <c_handler>, handler_data=3D0x7fffffffe220,
= =A0=A0=A0 pre_unwind_handler=3D0x7ffff7a5642c <pre_unwind_handler>, <= br> =A0=A0=A0 pre_unwind_handler_data=3D0x751160) at throw.c:213
#18 0x00007= ffff7a5623d in scm_i_with_continuation_barrier (
=A0=A0=A0 body=3D0x7fff= f7a563a1 <c_body>, body_data=3D0x7fffffffe220,
=A0=A0=A0 handler= =3D0x7ffff7a563d8 <c_handler>, handler_data=3D0x7fffffffe220,
=A0=A0=A0 pre_unwind_handler=3D0x7ffff7a5642c <pre_unwind_handler>, <= br>=A0=A0=A0 pre_unwind_handler_data=3D0x751160) at continuations.c:451
= #19 0x00007ffff7a564c3 in scm_c_with_continuation_barrier (
=A0=A0=A0 fu= nc=3D0x7ffff7a82613 <invoke_main_func>, data=3D0x7fffffffe350)
=A0=A0=A0 at continuations.c:547
#20 0x00007ffff7af97ba in with_guile_an= d_parent (base=3D0x7fffffffe290,
=A0=A0=A0 base@entry=3D<error readi= ng variable: value has been optimized out>, data=3D0x7fffffffe2d0,
= =A0=A0=A0 data@entry=3D<error reading variable: value has been optimized= out>)
=A0=A0=A0 at threads.c:907
#21 0x00007ffff71b6f55 in GC_call_with_stack_= base (
=A0=A0=A0 fn=3D<optimized out>, arg=3D<optimized out>= ) at misc.c:1553
#22 0x00007ffff7af9894 in scm_i_with_guile_and_parent (=
=A0=A0=A0 func=3D0x7ffff7a82613 <invoke_main_func>, data=3D0x7fff= ffffe350,
=A0=A0=A0 parent=3D0x0) at threads.c:950
#23 0x00007ffff7af98c0 in scm_w= ith_guile (
=A0=A0=A0 func=3D0x7ffff7a82613 <invoke_main_func>, da= ta=3D0x7fffffffe350)
=A0=A0=A0 at threads.c:956
#24 0x00007ffff7a825f= 4 in scm_boot_guile (argc=3D1,
=A0=A0=A0 argv=3D0x7fffffffe478, main_func=3D0x400bac <inner_main>, c= losure=3D0x0)
=A0=A0=A0 at init.c:319
#25 0x0000000000400c35 in main = (argc=3D1, argv=3D0x7fffffffe478)
=A0=A0=A0 at guile.c:81




--bcaec5299451e72d3704d9a06edb--