Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote: >> 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. Hmmm, ok. That would mean that a pikefun cannot be called after the object has been destructed. >I agree with tobi; the Stdio.Buffer code probably does something unusual. The most likely cause for this are the callback-methods that auto-flush or auto-append to the Buffer. Maybe the number of spots to test for a destructed object can be reduced to only those functions that are being called from external spots. >I'm also not sure why you removed several instances of > SET_SVAL(x, PIKE_T_INTEGER, NUMBER_NUMBER, integer, 0); They set it to zero, to test for later. However, some outside code (outside of buffer.cmod) seems to access this svalue and free it at times. After freeing it, leaves the value at -1 and the type set to PIKE_T_FREE or PIKE_T_UNKNOWN. So then the code in buffer.cmod would have to accomodate for either the explicit zero or the PIKE_T_FREE or the PIKE_T_UNKNOWN. This can all be simplified by simply testing for PIKE_T_FUNCTION instead. It then covers all internal freeing methods, as well as any external ones. >Also accessing the sval.tu.named_type field directly is not a supported >operation; use the TYPEOF() macro instead. Ok, I'll fix that. -- Stephen.
