Tuesday, December 13, 2011, 3:30:06 PM, you wrote: > No other thread can call vc->do_io_close if they don't have the pointer to > it.
Turns out that at least other thread does have a pointer. > It is up to the protocol engine to ensure that all pointers are clear. Still not clear on how the protocol engine clears pointers in other threads. > That means that you need to ensure that even if there are two different > classes in two different threads that the pointers to the NetVC are stored > under the same instance of Mutex. That doesn't help, unless one of the threads holds the mutex the entire lifetime of the object. If at any time one (non-NetHandler) thread drops the mutex, then the other (NetHandler) thread can modify the VC to a state where using the pointer will cause a crash, such as by swizzling the VFPTR, or setting the nh member to zero (which ironically crashes on the mutex check in do_io_close), or even re-allocating it so the wrong connection is closed. Preventing simultaneous access isn't effective if single access processing can leave the target of the pointer in an undetectably bad state. > So you clear all pointers except > the last one, call vc->do_io_closed() then clear the last via vc = NULL and > you are done. Again, the problem is the implementation mechanism by which those pointers are cleared. If only there were some technique were you could, say, keep a count of the number of outstanding pointers and only call do_io_close when the last one was cleared. > This is multi-threaded programming 101. If you can't handle this then you > can't write multi-threaded code. I'll just re-assign all my bugs to you and zwoop, then, since I appear to lack even basic programming knowledge. > It sounds like there is a bug in the way that the HTTP sessions are > handled. I need to look at the stack traces and see if I can figure out > where the bug is. I you have some way to reproduce the problem that would > be great too. Set up forward transparent proxy and drive traffic through it. Prior to 3.1.1, we would get a crash every few hours. bcall and weijin have seen the same crash. > Smart pointers are a way of hiding the bugs, not a solution. Some one should let the C++ Standards Committee know.
