[zeromq-dev] Something's broken in session_base or there's something I really ought to know about multithreading.

[Claudio Carbone]

On 14/01/13 18:14, Pieter Hintjens wrote:
> However, it's a complex test case to test that problem.
>
> My advice is to (a) determine what is actually wrong with the
> structure passed to the child thread, i.e., which fields are corrupted
> and when; and (b) strip this down to a much simpler test case (it's
> not a pgm issue at all, is it?) and (c) please use a pastebin or gist,
> because source code in emails is hard to play with.
>
Hello Pieter.
Thank you for your suggestions.
I'm sorry I couldn't figure out an even minimal test case, that was the 
best I could do to force the problem.

Anyway finally I found the solution thanks to a guy who had a similar 
problem.
It appears the quandary lied in the temporal buffers allocated by the 
compiler when you do string conversions like this

std::string addr = "192.168.1.1:5678";

zmq_connect(zsock, (const char*)addr.c_str());

In this case it's the compiler that somehow allocates a char array to 
hold the converted string for the called function to take.
Now eventually these buffers expire but you have no control whatsoever 
on any aspect of them.
So it appears that when the program is run normally, the time-to-live of 
these /automatic/ buffers is sufficient, while when you debug you may 
very well hinder the execution speed so much that the buffer is 
eliminated while it is still needed.

At least this is the explanation I've been able to extract from what 
happens because when I made the address a const char array for the 
socket that was giving problems, I was finally able to run the program 
through gdb and step through it at my leisure, whereas before I would 
get the assert error.

Everyone: thank you for your efforts and your patience.
BR
Claudio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130115/8a48723f/attachment.htm>