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, 12 Apr 2013 13:50:10 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b15b17dfa880004da2d89ea X-Trace: ger.gmane.org 1365789083 18366 80.91.229.3 (12 Apr 2013 17:51:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Apr 2013 17:51:23 +0000 (UTC) Cc: 14141 <14141@debbugs.gnu.org> To: Stefan Israelsson Tampe Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Apr 12 19:51:27 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 1UQi8B-0006ad-Ns for guile-bugs@m.gmane.org; Fri, 12 Apr 2013 19:51:24 +0200 Original-Received: from localhost ([::1]:50032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQi8B-0007Cj-EU for guile-bugs@m.gmane.org; Fri, 12 Apr 2013 13:51:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQi81-0007CI-TP for bug-guile@gnu.org; Fri, 12 Apr 2013 13:51:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQi7v-0003wx-D0 for bug-guile@gnu.org; Fri, 12 Apr 2013 13:51:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQi7v-0003w7-7J for bug-guile@gnu.org; Fri, 12 Apr 2013 13:51:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UQiBi-00019C-BE for bug-guile@gnu.org; Fri, 12 Apr 2013 13:55: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, 12 Apr 2013 17:55:02 +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.13657892734206 (code B ref 14141); Fri, 12 Apr 2013 17:55:02 +0000 Original-Received: (at 14141) by debbugs.gnu.org; 12 Apr 2013 17:54:33 +0000 Original-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 Original-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 Original-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) Original-Received: by 10.68.7.9 with HTTP; Fri, 12 Apr 2013 10:50:10 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: lSh5MmXsWEEezrUb9EskJvKVjUo 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:7089 Archived-At: --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--