[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