From: Matt Diephouse (via RT) <[EMAIL PROTECTED]>
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?
[EMAIL PROTECTED]> ./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/
