Panic when rethrowing null

[isop]

Using parrot from svn, r38390.

Following PIR code: .sub 'foo' :main

$P0 = null rethrow $P0

.end

Gives the following:

Parrot VM: PANIC: Illegal rethrow! C file src/exceptions.c, line 464 Parrot file (not available), line (not available)

We highly suggest you notify the Parrot team if you have not been working on Parrot. Use parrotbug (located in parrot's root directory) or send an e-mail to parrot-dev@…. Include the entire text of this error message and the text of the script that generated the error. If you've made any modifications to Parrot, please describe them as well.

Version : 1.1.0-devel Configured : Tue Apr 28 18:49:03 2009 GMT Architecture: i386-linux JIT Capable : Yes Interp Flags: 0 Exceptions : (missing from core)

Dumping Core... Quit

--- osname= linux osvers= 2.6.24-16-server arch= i486-linux-gnu-thread-multi cc= cc --- Flags:

category=core severity=medium ack=no

--- Summary of my parrot 1.1.0 (r38390) configuration:

configdate='Tue Apr 28 18:49:03 2009 GMT' Platform:

osname=linux, archname=i486-linux-gnu-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl

Compiler:

cc='cc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -funit-at-a-time -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wlogical-op -Wmissing-braces -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wc++-compat -Wdeclaration-after-statement -Werror=declaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -DHAS_GETTEXT',

Linker and Libraries:

ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags=, libs='-ldl -lm -lpthread -lcrypt -lreadline '

Dynamic Linking:

share_ext='.so', ld_share_flags='-shared -O2 -g -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -O2 -g -L/usr/local/lib -fPIC'

Types:

iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8, longdoublesize=12

--- Environment:

HOME =/home/isop LANG =en_US.UTF-8 LANGUAGE =en_US:en LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH =/home/isop/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games SHELL =/bin/bash

[isop]

parrotbug report

[whiteknight]

A fix shouldn't be too hard here, the question is what we want the behavior of this system to be? What happens when we throw or rethrow a null exception?

1) Do we throw another exception? This is what happens when we try to "throw" a null, it eventually throws a not-implemented exception 2) Is that a no-op? 3) Do we treat it like a regular exception, and just move control to the next handler (which then might raise all sorts of issues when we try to access the exception object from the handler)?

Anything we do is obviously better then a full Panic, but there are a few options to consider.

[whiteknight]

Asked today at #ps and Allison++ says the result should always be a fatal error. I'll implement that when I next have a chance.

[whiteknight]

I've attached a patch here that adds a new "die_from_null_exception" that prints out a simple error message and then calls Parrot_exit(). I'm not entirely sure if we have to do any other cleanup here. I'm not sure how we should handle the condition when it happens in a thread, do we close the whole application or just terminate that thread? At the moment the behavior is to terminate the whole application, so that can be changed if we need.

[NotFound]

I think that throwing a exception with severity EXCEPT_fatal will be more appropiate. Throwing or rethrowing a null is not such an abnormal situation that requires killing the interpreter/thread/whatever. EXCEPT_fatal seems fatal enough.

BTW the throw P opcode sets the attribute "resume" in the exception before throwing, it causing an NULL PMC exception, so this patch can't catch all cases.

[whiteknight]

I put in a basic fix in r38519. Probably needs some improvements, but it's a start. Resolved.