On Sun, 25 Sep 2011, Martin Lemke wrote:

> - the multi.easy has a flag has a state state = CURLM_STATE_MSGSENT
> and result = CURLE_OPERATION_TIMEDOUT:

> 643 if(easy->easy_conn &&
> 644 (easy->easy_conn->send_pipe->size +
> 645 easy->easy_conn->recv_pipe->size > 1) &&
> 646 easy->state > CURLM_STATE_WAITDO &&
> 647 easy->state < CURLM_STATE_COMPLETED) {

> Just for a test I out the state check prior to
> easy->easy_conn->send_pipe->size - this just moved the crash to other
> portions of the code.

Right, we need to make sure that 'easy_conn' is properly set to NULL when no
longer valid. That's what the code assumes.

If you run this code with valgrind, does it then tell you where that memory it
tries to access was freed or can you otherwise detect where in the multi.c
code the easy->easy_conn first becomes a dead pointer?

> I'd like to understand what kind of tests can I do to pinpoint the problem,
> which direction to go. As I said, even if timeout occurs the crash isn't
> always happening.

I think you should try to find where easy->easy_conn goes wrong the first
time, and that's probably easiest to find by spriknling the code with
printf()/infof() lines to output info. I usually favour real debugger usage,
but I figure your case may require some level of timing so single-stepping in
a debugger might not work - at least not if not done too early or too much.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html