From unknown Mon Jun 23 13:10:15 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#14141 <14141@debbugs.gnu.org> To: bug#14141 <14141@debbugs.gnu.org> Subject: Status: Abort in RTL VM Reply-To: bug#14141 <14141@debbugs.gnu.org> Date: Mon, 23 Jun 2025 20:10:15 +0000 retitle 14141 Abort in RTL VM reassign 14141 guile submitter 14141 Noah Lavine severity 14141 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 04 15:32:58 2013 Received: (at submit) by debbugs.gnu.org; 4 Apr 2013 19:32:58 +0000 Received: from localhost ([127.0.0.1]:34050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNpu5-0000ec-CO for submit@debbugs.gnu.org; Thu, 04 Apr 2013 15:32:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37865) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNpu2-0000eV-My for submit@debbugs.gnu.org; Thu, 04 Apr 2013 15:32:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNpqt-0004Fz-2c for submit@debbugs.gnu.org; Thu, 04 Apr 2013 15:29:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-101.6 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:36010) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNpqs-0004Fk-VD for submit@debbugs.gnu.org; Thu, 04 Apr 2013 15:29:38 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNpqq-0001Uf-PJ for bug-guile@gnu.org; Thu, 04 Apr 2013 15:29:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNpqp-0004Em-1D for bug-guile@gnu.org; Thu, 04 Apr 2013 15:29:36 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:64788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNpk3-0001Vq-5d for bug-guile@gnu.org; Thu, 04 Apr 2013 15:22:35 -0400 Received: by mail-pd0-f175.google.com with SMTP id g10so1370104pdj.6 for ; Thu, 04 Apr 2013 12:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=Z3yQwbSmBO0/l7gx1yC7GIiJnPcgmReUW9JQUu6ax0w=; b=NVRv8MrXTHoxUpa1UA1EB16A2PabjdOTFXgrp/IAr8jRGYoYgrhNwD+LBVJYRGJVw4 c/gZu3FtJygxxn5Tt9qNE3AKcEYXE+ZtyX/f8E3bwQWPP9y3VbYrRkOISgbX55MIPOTb jAcYr+dNjXFWBnEt+y9T3kVSoacpUuY9sjorVP4qol10+Ll8/q3iANckfVqqs00iKoDE h+MaTGKOLObGzHaEovp+fNtIkM5hRlXLaB8AAam0VodDBB+Yf/AWDcL/zznBC9gldp1K W9Qhj8FMThrv2QHsD/sqVe1SBXcbR7PPdsqX5A5MWfxgI1ueEi94ZCgjVdWNO2jRk8Eg O+CA== X-Received: by 10.68.247.163 with SMTP id yf3mr10490856pbc.113.1365103353676; Thu, 04 Apr 2013 12:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.157.42 with HTTP; Thu, 4 Apr 2013 12:22:13 -0700 (PDT) From: Noah Lavine Date: Thu, 4 Apr 2013 15:22:13 -0400 X-Google-Sender-Auth: joVpXtn4C1q3lobFQ9t_W6gp3vo Message-ID: Subject: Abort in RTL VM To: bug-guile@gnu.org Content-Type: multipart/alternative; boundary=047d7b2e3d087a4c1c04d98de464 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.9 (-----) --047d7b2e3d087a4c1c04d98de464 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7b2e3d087a4c1c04d98de464 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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)
=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


--047d7b2e3d087a4c1c04d98de464-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 04 15:48:26 2013 Received: (at 14141) by debbugs.gnu.org; 4 Apr 2013 19:48:26 +0000 Received: from localhost ([127.0.0.1]:34076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNq93-00011o-3X for submit@debbugs.gnu.org; Thu, 04 Apr 2013 15:48:25 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:49324) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UNq90-00011h-Gb for 14141@debbugs.gnu.org; Thu, 04 Apr 2013 15:48:23 -0400 Received: by mail-pd0-f171.google.com with SMTP id z10so1624322pdj.16 for <14141@debbugs.gnu.org>; Thu, 04 Apr 2013 12:45:10 -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:content-type; bh=946UzBxPSRQksOa0a1vlFvTZjlCRN5Hu2kfCHtV8RM8=; b=Jq5YbWdFF3Ajb9WFS7oThC6EH1NpX5psPCr3VKusEg95MzsHY+O1+TCnYNk98/Z0Tb w0on3NFigt6dKjc16QdqqcUmmUCm5BZW3G+XfhDCe+IBvXnIgrB3Ru/VUPvUF8s++rvx unGWcx7Q8qotQ4hDJFe6ormTsB82vsgoM3eFEJvuxQQkWqEoyv8/f+AtMsycRZoj39nu p2JgTKKxXWcPYBncgazTR0BMKvj9cUDbvzkhDo2wCFx8D09PTDVIi+fUmq13J4bmQ4b4 7riJtDwbv49e8o32ics58V4r2UzHNaVIbdt/7pMbb9lZU9i8nyzzXK4PjJLm1GEiKhJD TUvA== X-Received: by 10.68.1.231 with SMTP id 7mr10516036pbp.124.1365104710236; Thu, 04 Apr 2013 12:45:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.157.42 with HTTP; Thu, 4 Apr 2013 12:44:50 -0700 (PDT) In-Reply-To: References: From: Noah Lavine Date: Thu, 4 Apr 2013 15:44:50 -0400 X-Google-Sender-Auth: PVTDY2vfFoc9-5ZDK_3RMsPQH74 Message-ID: Subject: Re: bug#14141: Abort in RTL VM To: 14141@debbugs.gnu.org Content-Type: multipart/alternative; boundary=bcaec53042e355c41404d98e356b X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 14141 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) --bcaec53042e355c41404d98e356b Content-Type: text/plain; charset=ISO-8859-1 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 > > > --bcaec53042e355c41404d98e356b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oh, I forgot to mention one important fact. I *do* get the= expected result if I eliminate the stuff with boxes. This works fine:
<= br>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-program= )))

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



--bcaec53042e355c41404d98e356b-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 05 13:33:05 2013 Received: (at 14141) by debbugs.gnu.org; 5 Apr 2013 17:33:05 +0000 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 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 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) MIME-Version: 1.0 Received: by 10.68.157.42 with HTTP; Fri, 5 Apr 2013 10:29:25 -0700 (PDT) In-Reply-To: References: From: Noah Lavine Date: Fri, 5 Apr 2013 13:29:25 -0400 X-Google-Sender-Auth: SRmmuIiOa1SBj21qoFQdtcrbTBU Message-ID: Subject: Re: bug#14141: Abort in RTL VM To: Noah Lavine Content-Type: multipart/alternative; boundary=bcaec5299451e72d3704d9a06edb X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: 14141 Cc: 14141 <14141@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.6 (-) --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-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 06 10:52:59 2013 Received: (at 14141) by debbugs.gnu.org; 6 Apr 2013 14:52:59 +0000 Received: from localhost ([127.0.0.1]:36964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOUUE-0003Co-OS for submit@debbugs.gnu.org; Sat, 06 Apr 2013 10:52:59 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:59277) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UOUUB-0003Cc-Ds for 14141@debbugs.gnu.org; Sat, 06 Apr 2013 10:52:56 -0400 Received: by mail-pa0-f42.google.com with SMTP id kq13so2492167pab.29 for <14141@debbugs.gnu.org>; Sat, 06 Apr 2013 07:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bG4X/Uqw02Tb3hWvfgZ7xWnNzIYdproux8tOumwgimg=; b=NOQyiZgkiy4E2lteaCM89tnx9O295IhQywll6XjnISYTGQb9ANwQMe6AAucfeqxiUG idGmy5EXNvab6VDrs1UUSS7Ki5scFCtIcVow27ICEsqtKw/7/19BdPus02LOVg6xK9Ha XHMDOLWHSfNLQyWdRJu36bJt22dvz9UZSHYWIG0l1A2FN+OXV00s+L4MTclKENSh47mu +j/9oZCTtZwtuRwDyTbVPHXiT8eW+yUe8HuT231g1IDcs8FjTGxKxjmP/NgCWPC71Z6I fJMjN48+pNJ4MvbxOJeuv/F8MGwmoLwuAxvF7ucPww1IvJ+Kmd+03eAs/GVtfSbFEc4H lRUg== MIME-Version: 1.0 X-Received: by 10.68.226.201 with SMTP id ru9mr20419874pbc.102.1365259772989; Sat, 06 Apr 2013 07:49:32 -0700 (PDT) Received: by 10.70.22.5 with HTTP; Sat, 6 Apr 2013 07:49:32 -0700 (PDT) In-Reply-To: References: Date: Sat, 6 Apr 2013 16:49:32 +0200 Message-ID: Subject: Re: bug#14141: Abort in RTL VM From: Stefan Israelsson Tampe To: Noah Lavine Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 14141 Cc: 14141 <14141@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) Yeah, you really found the problem. I would put a if(nargs) to guard the while just to make it more robust. /Stefan On Fri, Apr 5, 2013 at 7:29 PM, Noah Lavine wrote: > 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 >>> >>> >> > From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 12 13:54:32 2013 Received: (at 14141) by debbugs.gnu.org; 12 Apr 2013 17:54:33 +0000 Received: from localhost ([127.0.0.1]:47676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UQiBD-00015Y-3q for submit@debbugs.gnu.org; Fri, 12 Apr 2013 13:54:32 -0400 Received: from mail-pb0-f51.google.com ([209.85.160.51]:59147) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UQiB8-00014x-Ua for 14141@debbugs.gnu.org; Fri, 12 Apr 2013 13:54:29 -0400 Received: by mail-pb0-f51.google.com with SMTP id rr4so1536699pbb.10 for <14141@debbugs.gnu.org>; Fri, 12 Apr 2013 10:50:30 -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=0lV2MNuIgIkZNoxNI2o07JD4uUiB+HaYp/9ntHz1xZA=; b=gdRtRFJ0L/x1VX4AQHuSYNcLHz99OOyWF9yRwiKD6vctZffSs9rkMTmO3XuDPtwL+t Q/HE3okkb6j2dB7HgbnZfQKa2Jh6vIL4lSRn+eEhzFYkIqqCPI7SHNKfdElWlemCTWxK N3OOra68fPnUGfKbgFVB+S5isriyCKjttC6NPv1OSICSvnJxszIiZnOF9qdVBEEg0afh vGgx31/+1bA7vIw6MBAKkKNFgixDwzTbzdxtDeh2M4Os7bFyfm2wJrn9xdDz/IXhIHSH ts9aYtRnNN535h17pttv9o++xbsFcyI30+qmfEVA4N0P/t3K7lmeEHIHHm2qR4sWNMAH oK9Q== X-Received: by 10.68.200.10 with SMTP id jo10mr3714461pbc.53.1365789030121; Fri, 12 Apr 2013 10:50:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.7.9 with HTTP; Fri, 12 Apr 2013 10:50:10 -0700 (PDT) In-Reply-To: References: From: Noah Lavine Date: Fri, 12 Apr 2013 13:50:10 -0400 X-Google-Sender-Auth: lSh5MmXsWEEezrUb9EskJvKVjUo Message-ID: Subject: Re: bug#14141: Abort in RTL VM To: Stefan Israelsson Tampe Content-Type: multipart/alternative; boundary=047d7b15b17dfa880004da2d89ea X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 14141 Cc: 14141 <14141@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.3 (--) --047d7b15b17dfa880004da2d89ea Content-Type: text/plain; charset=ISO-8859-1 Case closed! (At least for now.) Although the bug in reserve-locals is real (you can check with the debugger), the program never actually got far enough for that to affect anything. Instead, here's what happened: - reserve-locals worked fine, reserving space for 4 local variables - bind-rest shrunk the stack back down, leaving enough space for only one local variable - the call to toplevel-ref invoked the old (non-RTL) VM, through line 479 of modules.c. - the old VM put its initial frame on the stack right after the stack pointer - but since the stack pointer had been decremented by bind-rest, that overwrote the 4 local variables in the RTL function. In particular, it overwrote the variable that held the box (fp[1], for the record). - after the old VM returned, the new VM continued, tried to use the incorrect fp[1] value, and aborted. So, mystery solved. Coming soon: patches to fix the bug you hit if you try to do reserve-locals after bind-rest ... Noah On Sat, Apr 6, 2013 at 10:49 AM, Stefan Israelsson Tampe < stefan.itampe@gmail.com> wrote: > Yeah, you really found the problem. > > I would put a if(nargs) to guard the while just to make it more robust. > > /Stefan > > > On Fri, Apr 5, 2013 at 7:29 PM, Noah Lavine > wrote: > > 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 = # 609bc0> > >>> 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 > >>> > >>> > >> > > > --047d7b15b17dfa880004da2d89ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Case closed! (At l= east for now.)

Although the bug in reserve-locals is real (you= can check with the debugger), the program never actually got far enough fo= r that to affect anything. Instead, here's what happened:

=A0- reserve-locals worked fine, reserving space for 4 local vari= ables
=A0- bind-rest shrunk the stack back down, leaving enough sp= ace for only one local variable
=A0- the call to toplevel-ref invo= ked the old (non-RTL) VM, through line 479 of modules.c.
=A0- the old VM put its initial frame on the stack right after the st= ack pointer - but since the stack pointer had been decremented by bind-rest= , that overwrote the 4 local variables in the RTL function. In particular, = it overwrote the variable that held the box (fp[1], for the record).
=A0- after the old VM returned, the new VM continued, tried to use th= e incorrect fp[1] value, and aborted.

So, mystery solved. Comi= ng soon: patches to fix the bug you hit if you try to do reserve-locals aft= er bind-rest ...

Noah


On Sat, Apr 6, 2013 at 10:49 AM, Stefan Israelsson Tampe <stefan.itampe@gmail.com> wrote:
Yeah, you really found the problem.

I would put a if(nargs) to guard the while just to make it more robust.

/Stefan


On Fri, Apr 5, 2013 at 7:29 PM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
> 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 go= es
> away. However, I still don't know why this happens, and why the pr= oblem
> doesn't happen when the variables aren't boxed.
>
> I think there might be something weird going on in bind-rest when the<= br> > 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 <noah.b.lavine@gmail.com> wrote:
>>
>> Oh, I forgot to mention one important fact. I *do* get the expecte= d result
>> if I eliminate the stuff with 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-program)))
>>
>> Best,
>> Noah
>>
>> On Thu, Apr 4, 2013 at 3:22 PM, Noah Lavine <noah.b.lavine@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> I'm actually testing on the wip-rtl-cps branch, but this e= rror 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)
>>> =A0(assert-nargs-ge 0)
>>> =A0(reserve-locals 4)
>>> =A0(bind-rest 0)
>>> =A0(box 1 0)
>>> =A0(cache-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-progra= m dcec90 609bc0>
>>> scheme@(guile-user)> ($1 'hello)
>>>
>>> The expected result is
>>> $2 =3D 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 s= eems 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_v= ariable_p,
>>> although I'm not very experienced with debugging Guile. Ho= wever, 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 othe= r things
>>> for a while, and then run this code, the problem sometimes doe= sn't appear.
>>> That is especially disturbing.
>>>
>>> Does anyone have any idea where the issue is or how I should f= ind it?
>>>
>>> Thanks,
>>> Noah
>>>
>>> Here's the backtrace:
>>>
>>> (gdb) bt
>>> #0 =A00x00007ffff7440425 in raise ()
>>> =A0 =A0from /lib/x86_64-linux-gnu/libc.so.6
>>> #1 =A00x00007ffff7443b8b in abort ()
>>> =A0 =A0from /lib/x86_64-linux-gnu/libc.so.6
>>> #2 =A00x00007ffff7b30986 in rtl_vm_debug_engine (vm=3D0x6a6860= ,
>>> =A0 =A0 program=3D0xdcec90, argv=3D0x6a9548, nargs_=3D1) at vm= -engine.c:1868
>>> #3 =A00x00007ffff7b1aaf1 in vm_debug_engine (vm=3D0x6a6860, >>> =A0 =A0 program=3D0xdcec90, argv=3D0x7fffffffd028, nargs=3D1) = at vm-engine.c:419
>>> #4 =A00x00007ffff7b38f6c in scm_c_vm_run (vm=3D0x6a6860,
>>> =A0 =A0 program=3D0x75dbe0, argv=3D0x7fffffffd028, nargs=3D1) = at vm.c:791
>>> #5 =A00x00007ffff7a5bff3 in scm_primitive_eval (exp=3D0x7fe7f0= )
>>> =A0 =A0 at eval.c:691
>>> #6 =A00x00007ffff7a5c0ad in scm_eval (exp=3D0x7fe7f0,
>>> =A0 =A0 module_or_state=3D0x7e0090) at eval.c:725
>>> #7 =A00x00007ffff7acef2d in scm_shell (argc=3D1, argv=3D0x7fff= ffffe478)
>>> =A0 =A0 at script.c:441
>>> #8 =A00x0000000000400bd0 in inner_main (closure=3D0x0, argc=3D= 1,
>>> =A0 =A0 argv=3D0x7fffffffe478) at guile.c:62
>>> #9 =A00x00007ffff7a82663 in invoke_main_func (body_data=3D0x7f= ffffffe350)
>>> =A0 =A0 at init.c:336
>>> #10 0x00007ffff7a563c9 in c_body (d=3D0x7fffffffe220)
>>> =A0 =A0 at continuations.c:513
>>> #11 0x00007ffff7afc96c in apply_catch_closure (clo=3D0x81b360,=
>>> =A0 =A0 args=3D0x304) at throw.c:146
>>> #12 0x00007ffff7acf739 in apply_1 (smob=3D0x81b360, a=3D0x304)=
>>> =A0 =A0 at smob.c:141
>>> #13 0x00007ffff7b05cc8 in vm_regular_engine (vm=3D0x6a6860, >>> =A0 =A0 program=3D0x7443e0, argv=3D0x7fffffffe0c0, nargs=3D2)<= br> >>> =A0 =A0 at vm-i-system.c:873
>>> #14 0x00007ffff7b38f6c in scm_c_vm_run (vm=3D0x6a6860,
>>> =A0 =A0 program=3D0x79d5d0, argv=3D0x7fffffffe0c0, nargs=3D4) = at vm.c:791
>>> #15 0x00007ffff7a5b793 in scm_call_4 (proc=3D0x79d5d0, arg1=3D= 0x404,
>>> =A0 =A0 arg2=3D0x81b360, arg3=3D0x81b340, arg4=3D0x81b320) at = eval.c:513
>>> #16 0x00007ffff7afc767 in scm_catch_with_pre_unwind_handler (<= br> >>> =A0 =A0 key=3D0x404, thunk=3D0x81b360, handler=3D0x81b340,
>>> =A0 =A0 pre_unwind_handler=3D0x81b320) at throw.c:86
>>> #17 0x00007ffff7afca44 in scm_c_catch (tag=3D0x404,
>>> =A0 =A0 body=3D0x7ffff7a563a1 <c_body>, body_data=3D0x7f= ffffffe220,
>>> =A0 =A0 handler=3D0x7ffff7a563d8 <c_handler>, handler_da= ta=3D0x7fffffffe220,
>>> =A0 =A0 pre_unwind_handler=3D0x7ffff7a5642c <pre_unwind_han= dler>,
>>> =A0 =A0 pre_unwind_handler_data=3D0x751160) at throw.c:213
>>> #18 0x00007ffff7a5623d in scm_i_with_continuation_barrier ( >>> =A0 =A0 body=3D0x7ffff7a563a1 <c_body>, body_data=3D0x7f= ffffffe220,
>>> =A0 =A0 handler=3D0x7ffff7a563d8 <c_handler>, handler_da= ta=3D0x7fffffffe220,
>>> =A0 =A0 pre_unwind_handler=3D0x7ffff7a5642c <pre_unwind_han= dler>,
>>> =A0 =A0 pre_unwind_handler_data=3D0x751160) at continuations.c= :451
>>> #19 0x00007ffff7a564c3 in scm_c_with_continuation_barrier ( >>> =A0 =A0 func=3D0x7ffff7a82613 <invoke_main_func>, data= =3D0x7fffffffe350)
>>> =A0 =A0 at continuations.c:547
>>> #20 0x00007ffff7af97ba in with_guile_and_parent (base=3D0x7fff= ffffe290,
>>> =A0 =A0 base@entry=3D<error reading variable: value has bee= n optimized out>,
>>> data=3D0x7fffffffe2d0,
>>> =A0 =A0 data@entry=3D<error reading variable: value has bee= n optimized out>)
>>> =A0 =A0 at threads.c:907
>>> #21 0x00007ffff71b6f55 in GC_call_with_stack_base (
>>> =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 func=3D0x7ffff7a82613 <invoke_main_func>, data= =3D0x7fffffffe350,
>>> =A0 =A0 parent=3D0x0) at threads.c:950
>>> #23 0x00007ffff7af98c0 in scm_with_guile (
>>> =A0 =A0 func=3D0x7ffff7a82613 <invoke_main_func>, data= =3D0x7fffffffe350)
>>> =A0 =A0 at threads.c:956
>>> #24 0x00007ffff7a825f4 in scm_boot_guile (argc=3D1,
>>> =A0 =A0 argv=3D0x7fffffffe478, main_func=3D0x400bac <inner_= main>, closure=3D0x0)
>>> =A0 =A0 at init.c:319
>>> #25 0x0000000000400c35 in main (argc=3D1, argv=3D0x7fffffffe47= 8)
>>> =A0 =A0 at guile.c:81
>>>
>>>
>>
>

--047d7b15b17dfa880004da2d89ea-- From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 04 23:06:08 2013 Received: (at control) by debbugs.gnu.org; 5 Dec 2013 04:06:08 +0000 Received: from localhost ([127.0.0.1]:58709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoQCV-0004jf-DO for submit@debbugs.gnu.org; Wed, 04 Dec 2013 23:06:07 -0500 Received: from world.peace.net ([96.39.62.75]:37878) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoQCS-0004jW-NH for control@debbugs.gnu.org; Wed, 04 Dec 2013 23:06:05 -0500 Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VoQCN-0003Jl-5V; Wed, 04 Dec 2013 23:05:59 -0500 From: Mark H Weaver To: control@debbugs.gnu.org Date: Wed, 04 Dec 2013 23:04:57 -0500 Message-ID: <874n6okknq.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: close 14141 tags 15807 moreinfo tags 14550 moreinfo tags 14421 moreinfo tags 14042 moreinfo tags 13205 moreinfo tags 15470 wontfix severity 14109 wishlist retitle 15065 VM stack overflows sometimes cause an abort (Guile 2.0) thanks [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: close 14141 tags 15807 moreinfo tags 14550 moreinfo tags 14421 moreinfo tags 14042 moreinfo tags 13205 moreinfo tags 15470 wontfix severity 14109 wishlist retitle 15065 VM stack overflows sometimes cause an abort (Guile 2.0) thanks [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject close 14141 tags 15807 moreinfo tags 14550 moreinfo tags 14421 moreinfo tags 14042 moreinfo tags 13205 moreinfo tags 15470 wontfix severity 14109 wishlist retitle 15065 VM stack overflows sometimes cause an abort (Guile 2.0) thanks From unknown Mon Jun 23 13:10:15 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 02 Jan 2014 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator