Looks like I've spotted this bug too. I am using libcurl version
7.18.2-8lenny2 rebuilt with --enable-ares (via debuild).
Application uses curl_multi_perfrom to grab many pages in a single thread.
100 easy handles are created and then repeatedly removed/readded to multi
handle when each download finishes.
It fails after several hours, here is a gdb session on coredump.
Note the bogus pipeline pointer (yes, all easy handles have
CURLOPT_USERAGENT set to "curl")
Program terminated with signal 11, Segmentation fault.
[New process 29449]
#0 Curl_removeHandleFromPipeline (handle=0x1b2b8a50, pipeline=0x1bb35670) at
url.c:2304
(gdb) bt
#0 Curl_removeHandleFromPipeline (handle=0x1b2b8a50, pipeline=0x1bb35670) at
url.c:2304
#1 0x00007f18475fecea in Curl_done (connp=0x1c0ebca8, status=CURLE_OK,
premature=false) at url.c:4461
#2 0x00007f18476135ec in multi_runsingle (multi=0x1aee3d80, easy=0x1c0ebc90)
at multi.c:1347
#3 0x00007f18476140bb in curl_multi_perform (multi_handle=0x1aee3d80,
running_handles=0x7fff4fa483bc) at multi.c:1460
#4 0x000000000040604d in curlm::get (this=0x7fff4fa48450,
a...@0x7fff4fa48b80, limit=<value optimized out>)
  at curlget.cpp:104
#5 0x00000000004072de in main (argc=<value optimized out>,
argv=0x7fff4fa48dd8) at grabber.cpp:264
(gdb) bt full
#0 Curl_removeHandleFromPipeline (handle=0x1b2b8a50, pipeline=0x1bb35670) at
url.c:2304
  curr = (struct curl_llist_element *) 0x6567412d72657355
#1 0x00007f18475fecea in Curl_done (connp=0x1c0ebca8, status=CURLE_OK,
premature=false) at url.c:4461
  result = <value optimized out>
  conn = (struct connectdata *) 0x1bf9bee0
  data = (struct SessionHandle *) 0x1b2b8a50
#2 0x00007f18476135ec in multi_runsingle (multi=0x1aee3d80, easy=0x1c0ebc90)
at multi.c:1347
  disconnect_conn = <value optimized out>
  connected = <value optimized out>
  async = <value optimized out>
  protocol_connect = false
  dophase_done = <value optimized out>
  done = <value optimized out>
  result = CURLM_CALL_MULTI_PERFORM
#3 0x00007f18476140bb in curl_multi_perform (multi_handle=0x1aee3d80,
running_handles=0x7fff4fa483bc) at multi.c:1460
  result = <value optimized out>
  easy = (struct Curl_one_easy *) 0x1c0ebc90
  returncode = CURLM_OK
  t = <value optimized out>
(gdb) print *curr
Cannot access memory at address 0x6567412d72657355
(gdb) print pipeline
$3 = (struct curl_llist *) 0x1bb35670
(gdb) print *pipeline
$4 = {head = 0x6567412d72657355, tail = 0x6c727563203a746e, dtor =
0x7f0030000a0d, size = 0}
(gdb) x/s pipeline
0x1bb35670: "User-Agent: curl\r\n"

-- System Information:
Debian Release: 5.0.2
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libcurl3 depends on:
ii ca-certificates 20080809 Common CA certificates
ii libc-ares2 1.5.2-4 library for asyncronous name resol
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libidn11 1.8+20080606-1 GNU libidn library, implementation
ii libkrb53 1.6.dfsg.4~beta1-5lenny1 MIT Kerberos runtime libraries
ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries
ii libssh2-1 0.18-1 SSH2 client-side library
ii libssl0.9.8 0.9.8g-15+lenny1 SSL shared libraries
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime

libcurl3 recommends no packages.

libcurl3 suggests no packages.

-- debconf-show failed

Reply via email to