#ifdef PIKE_USE_MACHINE_CODE call_check_threads_etc(); #endif
I assume you have machine code enabled. call_check_threads_etc()
Normally I do, however, to get to the bottom of this, I temporarily compiled with: gcc-9 -g -O1 -pipe -DPIKE_DEBUG=1 --with-cdebug --with-rtldebug --with-valgrind --with-double-precision --with-long-int \ --disable-noopty-retry \ --without-machine-code \ --with-poll \ --with-portable-bytecode \
Well, that actually makes it more interesting (in you could say a bad sense), because without that call to call_check_threads_etc() we once more have no explanation for how the object could have been destructed between interpret.c:2403 and interpret.c:2506.
Actually no,
2503 #ifndef PIKE_USE_MACHINE_CODE 2504 FAST_CHECK_THREADS_ON_CALL(); 2505 #endif
would then be to blame. So ok, not so mysterious.
Now, what to do about it... indeed check at every function entry that we're not destructed? I don't know, but that just doesn't feel cool.
Actually, it seems like Pike actually does this check before *every* access of a local variable. I.e. in those numerous cases I had to deal with in pgsql I invariably got an exception like "lookup in destructed object". With that in mind, a check upon function entry does not sound so bad.
Well, I mean, so either we can manually do it in every "C function", or we can just have "Pike" prevent it from happening (I'm assuming here there aren't any cases in which we actualy want or even need to call functions in destructed objects). In which case I'd prefer to not having to manually check in each case if
* my function might actually be safe to be called in a destructed object, or * my object is destructed.
P.S. Speaking about asynchronous destructs. One of the "fun" things I discovered about three months ago was that since the actual destruct() method can also be called while being inside a totally random stackframe (very far beyond the stackframe where the object scope actually already ended), it is quite hazardous to try to acquire any kind of mutex from within a destruct() method, since it can result in very random and very rare deadlock situations. -- Stephen.