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/