[bug #29574] VM stack overflows aren't properly handled [1.9.10]

[bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ludovic Courtès]

URL:
  <http://savannah.gnu.org/bugs/?29574>

                 Summary: VM stack overflows aren't properly handled [1.9.10]
                 Project: Guile
            Submitted by: civodul
            Submitted on: Fri 16 Apr 2010 09:01:52 AM GMT
                Category: None
                Severity: 5 - Blocker
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hello,

VM stack overflows lead to a native stack overflow (and segfault) when trying
to raise an exception:

#v+
$ ./meta/gdb-uninstalled-guile 
GNU gdb (GDB) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ludo/src/guile/libguile/.libs/guile...done.
(gdb) r
Starting program: /home/ludo/src/guile/libguile/.libs/guile 
[Thread debugging using libthread_db enabled]
;;; note: autocompilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-autocompile argument to disable.
;;; compiling /home/ludo/src/guile/guile-readline/ice-9/readline.scm
;;; compiled
/home/ludo/src/guile/cache/guile/ccache/2.0-0.P-LE-8/home/ludo/src/guile/guile-readline/ice-9/readline.scm.go
[New Thread 0x7ffff5566710 (LWP 3308)]
GNU Guile 1.9.10
Copyright (C) 1995-2010 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (let loop () (cons 's (loop)))

Program received signal SIGSEGV, Segmentation fault.
GC_malloc_atomic (bytes=35) at thread_local_alloc.c:171
171     {

[...]

(gdb) bt -20
#41877 0x00007ffff7b3c1af in scm_vm_apply (vm=0x6bc430, program=0x749580,
args=0x304) at vm.c:559
#41878 0x00007ffff7b4d660 in vm_debug_engine (vm=<value optimized out>,
program=0x749580, argv=<value optimized out>, nargs=4) at vm-engine.c:269
#41879 0x00007ffff7b3c1af in scm_vm_apply (vm=0x6bc430, program=0x749580,
args=0x304) at vm.c:559
#41880 0x00007ffff7b4d660 in vm_debug_engine (vm=<value optimized out>,
program=0x749580, argv=<value optimized out>, nargs=4) at vm-engine.c:269
#41881 0x00007ffff7b3c1af in scm_vm_apply (vm=0x6bc430, program=0x749580,
args=0x304) at vm.c:559
#41882 0x00007ffff7b4d660 in vm_debug_engine (vm=<value optimized out>,
program=0x749580, argv=<value optimized out>, nargs=4) at vm-engine.c:269
#41883 0x00007ffff7b3c1af in scm_vm_apply (vm=0x6bc430, program=0x749580,
args=0x304) at vm.c:559
#41884 0x00007ffff7b4d660 in vm_debug_engine (vm=<value optimized out>,
program=0x1182a60, argv=<value optimized out>, nargs=18370328) at
vm-engine.c:269
#41885 0x00007ffff7ad5f23 in scm_primitive_eval (exp=0x8ab030) at eval.c:858
#41886 0x00007ffff7ad5f83 in scm_eval (exp=0x8ab030,
module_or_state=0x898e00) at eval.c:892
#41887 0x00007ffff7b17b6f in scm_shell (argc=1, argv=0x7fffffffc4e8) at
script.c:762
#41888 0x00007ffff7aeaf3f in invoke_main_func (body_data=0x7fffffffc3e0) at
init.c:380
#41889 0x00007ffff7acdf5a in c_body (d=0x7fffffffc310) at
continuations.c:475
#41890 0x00007ffff7b4e420 in vm_debug_engine (vm=<value optimized out>,
program=0x7f7ca0, argv=<value optimized out>, nargs=<value optimized out>) at
vm-i-system.c:924
#41891 0x00007ffff7ad4ee3 in scm_call_4 (proc=0x6590c0, arg1=<value optimized
out>, arg2=<value optimized out>, arg3=<value optimized out>, arg4=<value
optimized out>) at eval.c:594
#41892 0x00007ffff7ace1a3 in scm_i_with_continuation_barrier (body=<value
optimized out>, body_data=0x7fffffffc310, handler=0x7ffff7acdf70 <c_handler>,
handler_data=0x7fffffffc310, 
    pre_unwind_handler=<value optimized out>, pre_unwind_handler_data=<value
optimized out>) at continuations.c:452
#41893 0x00007ffff7ace240 in scm_c_with_continuation_barrier (func=<value
optimized out>, data=<value optimized out>) at continuations.c:493
#41894 0x00007ffff7b38232 in scm_i_with_guile_and_parent (func=<value
optimized out>, data=<value optimized out>, parent=<value optimized out>) at
threads.c:734
#41895 0x00007ffff7aeaef5 in scm_boot_guile (argc=<value optimized out>,
argv=<value optimized out>, main_func=0, closure=0x1) at init.c:363
#41896 0x0000000000400bb0 in main (argc=35, argv=0x7ffff7b73557) at
guile.c:70
#v-

Thanks,
Ludo'.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29574>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ludovic Courtès]

Update of bug #29574 (project guile):

             Assigned to:                    None => civodul                

    _______________________________________________________

Follow-up Comment #1:

The problem stems from the fact that `throw' is now implemented in Scheme, so
it needs VM stack space to run.

I've come up with the following hack: a small VM stack space is reserved and
made available only upon stack overflow, so that `throw' can run to
completion.  (See attached patch.)

An alternative would be create a new VM and switch the current thread's VM
for the dynamic extent of the scm_throw () call.  That seems overkill and
fragile though.

Comments?

Thanks,
Ludo'.

(file #20509)
    _______________________________________________________

Additional Item Attachment:

File name: vm-stack-overflow.patch        Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29574>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: [bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Andy Wingo]

Hi Ludo,

> I've come up with the following hack: a small VM stack space is reserved and
> made available only upon stack overflow, so that `throw' can run to
> completion.  (See attached patch.)

The patch didn't come through the mail, and I'm in an internetless cafe,
so I can't see it now -- but it seems a somewhat sane hack.

Did you see Dybvig's paper about underflow and overflow handlers? That
does solve this problem in a more robust way, including allowing for
stack extension instead of thrown exceptions. Of course that's probably
a larger project.

Andy
-- 
http://wingolog.org/

Re: [bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ludovic Courtès]

Hi Andy,

Please reply through the bug tracker
<http://savannah.gnu.org/bugs/?29574>.  The patch is there.

Andy Wingo <wingo@pobox.com> writes:

> Did you see Dybvig's paper about underflow and overflow handlers? That
> does solve this problem in a more robust way, including allowing for
> stack extension instead of thrown exceptions. Of course that's probably
> a larger project.

I just glanced at “Representing Control in the Presence of First-Class
Continuations”.  The idea of having linked stack segments sounds
interesting and more flexible than what I suggested.  Needs more
thought...

Thanks,
Ludo’.

Re: [bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Andy Wingo]

On Sat 22 May 2010 11:34, ludo@gnu.org (Ludovic Courtès) writes:

> Please reply through the bug tracker
> <http://savannah.gnu.org/bugs/?29574>.  The patch is there.

I never doubted the presence of the patch, I was only a bit miffed as I
work best offline. Perhaps this should form part of our ongoing
conversations with Sylvain ;)

Andy
-- 
http://wingolog.org/

Re: [bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ludovic Courtès]

Hey,

Andy Wingo <wingo@pobox.com> writes:

> On Sat 22 May 2010 11:34, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Please reply through the bug tracker
>> <http://savannah.gnu.org/bugs/?29574>.  The patch is there.
>
> I never doubted the presence of the patch, I was only a bit miffed as I
> work best offline.

Oh right.

> Perhaps this should form part of our ongoing conversations with
> Sylvain ;)

Definitely!  :-)

Ludo’.

Re: [bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ken Raeburn]

On May 22, 2010, at 11:55, Ludovic Courtès wrote:
>>> Please reply through the bug tracker
>>> <http://savannah.gnu.org/bugs/?29574>.  The patch is there.
>> 
>> I never doubted the presence of the patch, I was only a bit miffed as I
>> work best offline.
> 
> Oh right.

If savannah's bug tracker doesn't have a useful offline mode, make sure you file a bug report. :-)

The ability to fetch the desired subset of the database (or the whole thing, if it's not huge) with rsync or some such tool, and view it through emacs or a local debbugs web server is probably adequate....

Ken

[bug #29574] VM stack overflows aren't properly handled [1.9.10]

[Ludovic Courtès]

Update of bug #29574 (project guile):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

Applied:
http://git.savannah.gnu.org/cgit/guile.git/commit/?id=f1046e6b78f3044db6d9fd64cf272864366a1182
.

Andy suggested looking at stack overflow/underflow handlers by Hieb et al.,
which could be an option in the longer term.  My understanding is that the
paper suggests creating a new stack segment upon stack overflow and linking it
to the previous stack.  

This policy may not always be desirable.  Raising a stack-overflow exception
as we currently do leaves it up to the application to decide which policy to
apply.  IOW, it separates mechanism from policy.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29574>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/