Bugs item #1152972, was opened at 2005-02-27 19:15
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1152972&group_id=976

Category: libcurl
Group: crash
>Status: Closed
Resolution: Works For Me
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel Stenberg (bagder)
Summary: libcurl crash when connection can't be established

Initial Comment:
I can reproduce this bug on linux and widows ( v1.13.0 ).
It happens when network connection can not be
established ( when i disable eth0 for example )

Output:

[m] 27.02.2005 17:27:03 864 url :
http://www.micr.cz/images/dokumenty/Working_paper_beyond2005.htm
[d] 27.02.2005 17:27:03 864 Couldn't find host
www.micr.cz in the _netrc file, using defaults
[d] 27.02.2005 17:27:03 864 Re-using existing
connection! (#0) with host www.micr.cz
[d] 27.02.2005 17:27:03 864 Connected to www.micr.cz
(81.0.237.99) port 80
[d] 27.02.2005 17:27:03 864 Send failure: Socket is not
connected
[d] 27.02.2005 17:27:03 864 Failed sending HTTP request
[d] 27.02.2005 17:27:03 864 Re-used connection seems
dead, get a new one
[d] 27.02.2005 17:27:03 864 Empty reply from server
[d] 27.02.2005 17:27:03 864 Closing connection #0

It looks that memory is freed twice ( callstack ) ->

_free_dbg_lk(void * 0xfeeefeee, int 1) line 1044 + 48 bytes
_free_dbg(void * 0xfeeefeee, int 1) line 1001 + 13 bytes
free(void * 0xfeeefeee) line 956 + 11 bytes
Curl_done(connectdata * * 0x00b9d91c, int 52) line 3527
+ 15 bytes
curl_multi_perform(void * 0x00b9c970, int * 0x02e8847c)
line 468 + 19 bytes

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2005-03-30 00:56

Message:
Logged In: YES
user_id=1110

Closed until we get more details. Reopen this or file a new
bug report if a way to repeat this problem appears.

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-16 20:26

Message:
Logged In: YES
user_id=1232234

I got one linux box with dual cpu. I'll try to debug it there.

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-16 20:23

Message:
Logged In: YES
user_id=1232234

I catch that in this case was ftp protocol but i'm sure that
gpf was born from http too. I really tryin catch problem
again and debug it but today
aplication running for about 20 hours and everything is ok (
i catch that err msg without gpf ).

I'll try to reproduce it again and debug it...

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-16 20:10

Message:
Logged In: YES
user_id=1110

Does this happen with all protocols? Does it happen with
libcurl 7.13.1 as well?

Can you tell us with more details how you make the problem
appear so we can attempt to repeat it?

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-16 07:10

Message:
Logged In: YES
user_id=1232234

I did set conditional break point in debug msg ( when catch
"sending failure" )

Curl_disconnect() free conn structure and returns CURLE_OK (
hm ? )

curl_multi_perform() returns CURLM_OK and set
context->running to 0

this seems be ok...

callstack ->

debug_msg(void * 0x01a40068, int 0, char * 0x01a4034c,
unsigned int 0, void * 0x00000000) line 59
showit(SessionHandle * 0x01a40068, int 0, char * 0x01a4034c,
unsigned int 35) line 454 + 34 bytes
Curl_debug(SessionHandle * 0x01a40068, int 0, char *
0x01a4034c, unsigned int 35, connectdata * 0x00000000) line
503 + 21 bytes
Curl_failf(SessionHandle * 0x01a40068, const char *
0x00afaf14) line 172 + 26 bytes
Curl_write(connectdata * 0x01a6aef0, unsigned int 2584, void
* 0x0163eaa0, unsigned int 6, int * 0x0163ea9c) line 312 +
33 bytes
Curl_ftpsendf(connectdata * 0x01a6aef0, const char *
0x00afb6e4) line 2384 + 40 bytes
ftp_quit(connectdata * 0x01a6aef0) line 2420 + 19 bytes
Curl_ftp_disconnect(connectdata * 0x01a6aef0) line 2449 + 9
bytes
Curl_disconnect(connectdata * 0x01a6aef0) line 1456 + 15 bytes
ConnectionExists(SessionHandle * 0x01a40068, connectdata *
0x00b9d8f0, connectdata * * 0x0163f164) line 1612 + 9 bytes
CreateConnection(SessionHandle * 0x01a40068, connectdata * *
0x01a695cc, Curl_dns_entry * * 0x0163f3a0, unsigned char *
0x0163f3d8) line 3099 + 23 bytes
Curl_connect(SessionHandle * 0x01a40068, connectdata * *
0x01a695cc, unsigned char * 0x0163f3d8) line 3471 + 21 bytes
curl_multi_perform(void * 0x00b92258, int * 0x10f7cf94) line
379 + 23 bytes

I can not reproduce GPF with conditional breakpoints......
-------------------------------------------------------------------------------------

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-14 22:34

Message:
Logged In: YES
user_id=1110

Are you reading?

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-14 01:26

Message:
Logged In: YES
user_id=1110

Given the problems to debug this, can you please work on
getting a test recipe that can make this problem appear so
that we can use that in our ends to repeat this problem and
thus debug it?

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-08 22:38

Message:
Logged In: YES
user_id=1110

Even so, I want to know some basic info on where it crashes
and from where it was called.

If it truely is a free() call that crashes, what does the
pointer look like that is passed to free()? If that is bad,
how come it is so bad? Is the 'conn' pointer wrong as well?
If so, how com the conn pointer is wrong at that point.

etc

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-08 18:15

Message:
Logged In: YES
user_id=1232234

I'm sorry but these days i can access only win32 box with
msvc's debugger.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-08 17:21

Message:
Logged In: YES
user_id=1110

I was referring to a stack trace, such as the one you get
when you run gdb and type 'where' (after the crash or while
post-mortem analyzing the core dump).

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-08 16:14

Message:
Logged In: YES
user_id=1232234

If this will not help I'll try to catch the problem this
weekend.

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-08 16:12

Message:
Logged In: YES
user_id=1232234

curl_multi_perform(void * 0x11372f28, int * 0x05c98d7c) line
468 + 19 bytes

        multi_handle 0x11372f28
- running_handles 0x05c98d7c
                0
+ msg 0x00000000
        async 204 'Ì'
- multi 0x11372f28
        type 764702
- easy {...}
+ next 0x116fd818
+ prev 0x00000000
+ easy_handle 0x00000000
+ easy_conn 0x00000000
        state 0
        result 0
+ msg 0x00000000
        msg_num 0
        num_easy 1
        num_msgs 4
- hostcache 0x11372f90
+ table 0x11372fd8
        dtor 0x00ab23ff freednsentry(void *)
        slots 7
        size 1
- easy 0x116fd818
+ next 0x00000000
- prev 0x11372f2c
+ next 0x116fd818
+ prev 0x00000000
+ easy_handle 0x00000000
+ easy_conn 0x00000000
        state 0
        result 0
+ msg 0x00000000
        msg_num 0
- easy_handle 0x1136a9d0
+ hostcache 0x11372f90
        multi 0x11372f28
+ share 0x00000000
+ set {...}
+ change {...}
+ cookies 0x00000000
+ progress {...}
+ state {...}
+ info {...}
- easy_conn 0x11700918
+ data 0xdddddddd
        connectindex -572662307
        protocol -572662307
+ dns_entry 0xdddddddd
+ ip_addr 0xdddddddd
+ ip_addr_str 0xdddddddd ""
+ protostr 0x11700930
"ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ"
+ host {...}
+ proxy {...}
+ pathbuffer 0xdddddddd ""
+ path 0xdddddddd ""
        port -572662307
        remote_port 56797
        bytecount -2459565876494606883
        headerbytecount -572662307
        deductheadercount -572662307
+ range 0xdddddddd ""
        resume_from -2459565876494606883
+ user 0xdddddddd ""
+ passwd 0xdddddddd ""
+ proxyuser 0xdddddddd ""
+ proxypasswd 0xdddddddd ""
+ now {...}
+ created {...}
+ sock 0x117009b0
        maxdownload -2459565876494606883
+ ssl 0x117009c0
+ ssl_config {...}
+ bits {...}
        curl_do 0xdddddddd
        curl_done 0xdddddddd
        curl_do_more 0xdddddddd
        curl_connect 0xdddddddd
        curl_disconnect 0xdddddddd
        curl_close 0xdddddddd
        sockfd 3722304989
        size -2459565876494606883
+ bytecountp 0xdddddddd
        writesockfd 3722304989
+ writebytecountp 0xdddddddd
+ allocptr {...}
+ newurl 0xdddddddd ""
+ proto {...}
+ keep {...}
        upload_present -572662307
+ upload_fromhere 0xdddddddd ""
        fread 0xdddddddd
        fread_in 0xdddddddd
+ ntlm {...}
+ proxyntlm {...}
+ syserr_buf 0x11700b18
"ÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝÝ"
+ async {...}
+ sec_conn 0xdddddddd
        xfertype -572662307
        state 4
        result 52
+ msg 0x00000000
        msg_num 0
        done 204 'Ì'
        connected 204 'Ì'
        result 0

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-04 09:52

Message:
Logged In: YES
user_id=1110

Can you rebuild libcurl with debug info (configure
--enable-debug) and get a full stack trace for the core
dump? Would help me a lot on this.

----------------------------------------------------------------------

Comment By: niel (n13l)
Date: 2005-03-04 05:03

Message:
Logged In: YES
user_id=1232234

I'm using not so good cdma modem for accesing internet.
sometimes data can not be send. so i think that you can
reproduce this problem if you switch down eth after curl
will verbose output "Connected to .... ."

Maybe better checking of send(). ( I'm not sure about that )

I usually push many urls and processing downloads.
( Sometimes it works more then hour )
When I catch "Send failure: Socket is not
connected" in my text output function. I know that next call
of curl_multi_perform() will core dumped.

Btw I checking all return codes as a caller.

1)

  switch( curl_multi_add_handle(url_chain->mh, cdata->curl) ) {
  case CURLM_CALL_MULTI_PERFORM:
  case CURLM_OK:
    url_chain->mh_attach = 1;
    break;
  default:
    log_warrn("url add handler failed");
    url_chain->mh_attach = 0;
    break;
  }

2) for( ;; ) {
      code = curl_multi_perform(url->mh, &url->running);
      if( code != CURLM_CALL_MULTI_PERFORM)
        break;
    }

    if( code != CURLM_OK ) {
      log_warrn("internal error (code %d)", code);
    }

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2005-03-03 09:57

Message:
Logged In: YES
user_id=1110

I'm sorry, but I can't see how this can happen.

The Curl_done() line is a free() on line 3527, which in the
7.13.0 version was a free(conn->range).

I don't see how this can be freed already. Can you please
provide a step-by-step description on how we can proceed to
repeat this problem?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-02-27 19:18

Message:
Logged In: NO

reported anonymously because of ->
Within the next 24 hours, you should receive an email at
niel_at_rtfm.cz from SourceForge.net.

This email will be used to confirm the email address you
provided.

If you do not receive this email within 24 hours or if you
specified a bad email address, you may start the
registration process again. If problems persist, please
contact SourceForge.net staff for assistance after waiting
24 hours for the email.
Welcome to SourceForge.net.

:)

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1152972&group_id=976
_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-tracker
Received on 2005-03-30