Assertion failures under 1.2beta23PL4

Hi Guys,

Any hints as to what would cause the following before I disable the
assertions?

This one probably rasied it head due to the reload_into_ims patch I sent. This
would happen if two REFRESH requests came in for the same object and tripped
over each other. I'm guessing the race condition was always there, but now
it's exercised because of the higher number of REFRESH requests coming in. I'm
going for the solution of simply shutting down the connection and let the user
retry as a quick fix. Would someone care to speculate how this event MAY get
triggered? Then fix?

Assertion failed: entry->store_status != STORE_ABORTED, file client_side.c,
line 393

This one is tricky and I'm not certain as to how much damage would occur if
it was ignored. This also occurs the most... This might be caused by me
using ACLs to prevent forwarding loops??

Assertion failed: fwdState->fail.err_code, file forward.c, line 62

I'm guessing that this assertion is pretty safe to just return since the object
will otherwise be STORE_OK or STORE_ABORTED. If it's STORE_OK then it's
already finished writing, so who cares? If it's already STORE_ABORTED,
then who cares. The object is ABORTED and that's what the caller wanted
to happen already.

Assertion failed: e->store_status == STORE_PENDING, file store.c, line 481

Comments anyone?

        Stew.

-- 
Stewart Forster (Snr. Development Engineer)
connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email: slf@connect.com.au   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666