Ticket #595 (closed bug: fixed)

Opened 13 years ago

Last modified 13 years ago

Panic when rethrowing null

Reported by: isop Owned by: whiteknight
Priority: normal Milestone:
Component: none Version: trunk
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


Using parrot from svn, r38390.

Following PIR code: .sub 'foo' :main

$P0 = null rethrow $P0


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


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'


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


throw_panic.txt Download (3.4 KB) - added by isop 13 years ago.
parrotbug report
handle_null_exceptions.patch Download (2.0 KB) - added by whiteknight 13 years ago.

Change History

Changed 13 years ago by isop

parrotbug report

Changed 13 years ago by whiteknight

  • owner set to 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.

Changed 13 years ago by whiteknight

  • status changed from new to assigned

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.

Changed 13 years ago by whiteknight

Changed 13 years ago by 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.

Changed 13 years ago by 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.

Changed 13 years ago by whiteknight

  • status changed from assigned to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.