[zeromq-dev] Race condition in tcp_socket_t
Christian Gudrian
christian at gudrian.org
Fri Nov 12 18:17:12 CET 2010
Am 12.11.2010 17:32, schrieb Martin Sustrik:
> Can you possibly get the backtraces for the two threads accessing the
> same tcp_socket_t the in parallel?
That's a tough one. Apart from C++Builder not being able to copy stack
traces to the clipboard it's quite hard to make the threads stop at the
right time to get a usable trace.
I've instrumented tcp_socket_t so that it records
1. which thread called open()
2. which thread called close()
3. which thread called write()
I've added assertions and tweaked abort() so that it puts the process
into an endless loop rather than terminate it.
This is the call stack of thread 3024 which called the close method on a
tcp_socket_t instance which got opened by thread 8212:
http://dl.dropbox.com/u/9848985/zeromq/zmq-1.png
That thread (8212) was also the last one to call the write method on
that particular instance. Currently that threat waits for the Winsock
select function to return. It's current call stack is of no use.
This is the call stack of thread 8348 which called the close method on a
tcp_socket_t instance it also opened, but which got written to by thread
9348:
http://dl.dropbox.com/u/9848985/zeromq/zmq-2.png
Thread 9348, however, just called the close method on a tcp_socket_t
instance that got opened by thread 6708:
http://dl.dropbox.com/u/9848985/zeromq/zmq-3.png
And thread 6708 just called the close method on a tcp_socket_t instance
it opened itself, but which got written to by thread 8444:
http://dl.dropbox.com/u/9848985/zeromq/zmq-4.png
That is as close as I could get to the heart of the matter.
HTH,
Christian
More information about the zeromq-dev
mailing list