Tobias S. Josefowitz @ Pike developers forum wrote:
I can now confirm that I've been running three hours with io->this = 0 at destruct, and there have not been any coredumps yet. Seems promising.
Four hours now, no coredump. Statistically relatively strong evidence.
I'm still a bit surprised by the premise that a CMODs PIKEFUNs would be entered in/with an object *after* it has been destructed... you guard function entry, so this is apparently not a case of our object getting destructed while we are already executing.
I would think that this is simply not supposed to happen (and that therefore fixing it at this level is the wrong thing to do).
Entering destructed objects happens "all the time" when callbacks to memberfunctions in already destructed objects are being called.
Not really; what does happen is that execution may return to a stack frame in an object that has been destructed.
Normal Pike deals with this, and thus PIKEFUN's have to guard against it too.
I agree with tobi; the Stdio.Buffer code probably does something unusual.
I'm also not sure why you removed several instances of
SET_SVAL(x, PIKE_T_INTEGER, NUMBER_NUMBER, integer, 0);
Also accessing the sval.tu.named_type field directly is not a supported operation; use the TYPEOF() macro instead.
/grubba