>>#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. >
