[perl #40824] loadlib opcode causes problems with exceptions

[Matt Diephouse]

# New Ticket Created by Matt Diephouse
# Please include the string: [perl #40824]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40824 >

If a loadlib fails, it doesn't throw a catchable exception. The t/
library/pg.t test was changed because it was failing on platforms
where pg wasn't available. In particular, this assertion was getting
tripped on:

src/inter_call.c:122: failed assertion `PObj_is_PMC_TEST(sig_pmc) &&
sig_pmc->vtable->base_type == enum_class_FixedIntegerArray'
Abort trap

The fix was this patch:

=== t/library/pg.t
==================================================================
--- t/library/pg.t (revision 23578)
+++ t/library/pg.t (local)
@@ -32,6 +32,10 @@
test = new 'Test::Builder'
test.'plan'(N_TESTS)
push_eh no_pg
+
+ # TODO: fix when exception handling works again
+ loadlib $P0, 'libpq'
+ unless $P0 goto no_pg
load_bytecode 'postgres.pir'
clear_eh
test.'ok'(1, 'load_bytecode')

--
Matt Diephouse

[Bob Rogers]

From: Matt Diephouse (via RT) <parrotbug...@parrotcode.org>
Date: Sat, 11 Nov 2006 16:46:20 -0800

If a loadlib fails, it doesn't throw a catchable exception. The t/
library/pg.t test was changed because it was failing on platforms
where pg wasn't available. In particular, this assertion was getting
tripped on:

src/inter_call.c:122: failed assertion `PObj_is_PMC_TEST(sig_pmc) &&
sig_pmc->vtable->base_type == enum_class_FixedIntegerArray'
Abort trap

I don't think it's loadlib itself; I believe the library :init code is
trying to throw an error. If that is the case, then it's a continuation
barrier problem. Before the error, do you see this "oops" message?

rogers@rgrjr> ./parrot t/library/pg.t
1..43
[oops; continuation 0x81e4d64 of type 25 is trying to jump from runloop 9 to runloop 1]
not ok 1 #skip skipped
not ok 2 #skip skipped
not ok 3 #skip skipped
not ok 4 #skip skipped
not ok 5 #skip skipped
. . .

The :init code in runtime/parrot/library/postgres.pir is running in a
separate runloop, so when it throws an error, the error doesn't actually
get to the handler, and the loadlib op appears to complete normally.

I don't recall seeing this "failed assertion" before, though.
Probably we should turn this "oops" into an internal_exception, since
memory might be getting corrupted subsequently.

The fix was this patch . . .

Looks good to me. I see chromatic has already committed this as
r15413.

-- Bob Rogers
http://rgrjr.dyndns.org/

[Chromatic]

On Saturday 11 November 2006 19:01, Bob Rogers wrote:

> I don't think it's loadlib itself; I believe the library :init code is
> trying to throw an error. If that is the case, then it's a continuation
> barrier problem. Before the error, do you see this "oops" message?

Yes, and agreed. Matt and I discussed that just after he sent the message.

> I don't recall seeing this "failed assertion" before, though.
> Probably we should turn this "oops" into an internal_exception, since
> memory might be getting corrupted subsequently.
>
> The fix was this patch . . .
>
> Looks good to me. I see chromatic has already committed this as
> r15413.

It just gets the test to pass; there are still outstanding questions with
regard to exceptions and continuations and the C barrier.

-- c