srfi-34 segfaults stability and master when using bare (raise 'obj)

[Christian Kellermann]

As reported by Mark Carter on chicken-users, this fails

$ csi -n

CHICKEN
(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.0.5-st (stability/4.7.0)
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
compiled 2012-03-13 on devpool08 (Linux)

#;1> (use srfi-34)
; loading /home/ckellerm/chickens/4.7.0-stability/lib/chicken/6/srfi-34.import.so ...
; loading /home/ckellerm/chickens/4.7.0-stability/lib/chicken/6/chicken.import.so ...
; loading /home/ckellerm/chickens/4.7.0-stability/lib/chicken/6/scheme.import.so ...
; loading /home/ckellerm/chickens/4.7.0-stability/lib/chicken/6/srfi-34.so ...
#;2> (raise 'obj)
Segmentation fault

It also segfaults on current master. The egg's tests pass though.
So this might be due to the mixing of the egg's raise procedure without having changed the error-handlers correctly? I am guessing...

[sjamaan]

Now it doesn't segfault anymore for me, but it simply hangs...

Perhaps the R7RS implementation could be taken and used in this egg? IIUC it's more-or-less the same idea.

[evhan]

Replying to sjamaan:

Perhaps the R7RS implementation could be taken and used in this egg? IIUC it's more-or-less the same idea.

I think that's right, R7RS just gives a slightly stronger guarantee about what happens if the handler returns. I can try something like that.

This is currently a bit weird, it looks like ##sys#current-exception-handler is being set to '() in some cases, which probably isn't healthy.

[sjamaan]

I think it should be fixed, for the time being (r31188). It's probably better to replace it with the R7RS implementation later.

It's impossible to write a test for this, I think: it only fails at toplevel, when there are no exception handlers defined.