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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: crash
>Status: Pending
>Resolution: Later
Priority: 7
Private: No
Submitted By: Ol L (oliverjl)
Assigned to: Daniel Stenberg (bagder)
Summary: rtorrent/libcurl segfaults intermittently

Initial Comment:
rtorrent (both stable and latest svn) using libcurl (again, I've tried fedora 9 stable packages, self-compiled stable version and self-compiled cvs version) crashes on average every 4 hours or so. Backtraces from the crashes show that the crash is inside libcurl, generally curl_multi_perform().

The relevant rtorrent bug report is at http://libtorrent.rakshasa.no/ticket/1419 , several backtraces are available there.
My most recent backtrace is included here. This was obtained with rtorrent svn and libcurl cvs. Please advise which version of libcurl it would be most useful to you for this to be tested with.

$ curl -V
curl 7.19.0-CVS (x86_64-unknown-linux-gnu) libcurl/7.19.0-CVS OpenSSL/0.9.8g zlib/1.2.3 libidn/0.6.14
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: Debug IDN IPv6 Largefile NTLM SSL libz

$ uname -a
Linux elepaio 2.6.26.1-9.fc9.x86_64 #1 SMP Tue Aug 5 22:39:01 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x000000000013cfb0 in Curl_do (connp=0x3c6a220, done=0x7fffe419fa9c) at url.c:4726
4726 if(conn->handler->do_it) {
Current language: auto; currently c
Missing separate debuginfos, use: debuginfo-install keyutils.x86_64
(gdb) bt full
#0 0x000000000013cfb0 in Curl_do (connp=0x3c6a220, done=0x7fffe419fa9c) at url.c:4726
        result = CURLE_OK
        conn = (struct connectdata *) 0x4943738
        data = (struct SessionHandle *) 0x4b9b178
#1 0x0000000000152586 in multi_runsingle (multi=0x1613728, easy=0x3c6a208) at multi.c:1117
        disconnect_conn = false
        msg = (struct Curl_message *) 0x0
        connected = false
        async = false
        protocol_connect = false
        dophase_done = false
        done = false
        result = CURLM_OK
        k = (struct SingleRequest *) 0x4b90c10
#2 0x0000000000152eed in curl_multi_perform (multi_handle=0x1613728, running_handles=0x7fffe419fc58) at multi.c:1475
        result = CURLM_OK
        multi = (struct Curl_multi *) 0x1613728
        easy = (struct Curl_one_easy *) 0x3c6a208
        returncode = CURLM_OK
        t = (struct Curl_tree *) 0x4a13f30
#3 0x00000000004770d5 in core::CurlStack::perform (this=0x1613410) at curl_stack.cc:74
        count = -716090
        code = CURLM_CALL_MULTI_PERFORM
#4 0x0000000000470d4d in core::PollManagerEPoll::poll (this=0x1613400, timeout={m_time = 1000}) at poll_manager_epoll.cc:92
        t = {tv_sec = 0, tv_usec = 1000}
#5 0x00000000004323af in main (argc=<value optimized out>, argv=0x7fffe419ff08) at main.cc:276
        firstArg = <value optimized out>
        e = <value optimized out>

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

>Comment By: Daniel Stenberg (bagder)
Date: 2008-10-08 00:53

Message:
Thanks, I will then mark this 'pending' and 'later' for now. Feel free to
come back to this same entry if you get more details, or file a new one it
doesn't matter that much which way.

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

Comment By: Ol L (oliverjl)
Date: 2008-10-06 01:57

Message:
Unfortunately I'm not in a position to play with replicating/analysing this
problem. The problem forced me, some time ago, to stop using rtorrent so I
have not obtained any additional crashes. Hopefully by the time I can
analyse the problem is will no longer exist! But if it still does, I will
try and look into it further in a few months...

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

Comment By: Daniel Stenberg (bagder)
Date: 2008-10-05 23:35

Message:
Since I cannot repeat this and we have nothing new, this now goes pending
and will be closed unless we get further details within 14 days.

We can always re-open it later (or open a new one) in case new
details/facts pop up for this later on.

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

Comment By: Daniel Stenberg (bagder)
Date: 2008-09-29 15:14

Message:
Well, it would be useful to get to know about the situation in the last
libcurl function that was used, Curl_single_getsock() in this case. Like
what the local variables contain and what the assert thing it alerts about
is concerning.

I would also again suggest you start trying to craft up a stand-alone
program that repeats this problem since trying to track down the problem
this way is next to impossible for us in the other end...

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

Comment By: Ol L (oliverjl)
Date: 2008-08-26 19:32

Message:
Logged In: YES
user_id=1558607
Originator: YES

A slightly different crash:

torrent: transfer.c:1746: Curl_single_getsock: Assertion
`conn->writesockfd != -1' failed.

Program received signal SIGABRT, Aborted.
0x0000003a41832215 in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Current language: auto; currently c
Missing separate debuginfos, use: debuginfo-install keyutils.x86_64
(gdb) bt
#0 0x0000003a41832215 in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x0000003a41833d83 in abort () at abort.c:88
#2 0x0000003a4182b039 in __assert_fail (assertion=<value optimized out>,
file=<value optimized out>, line=<value optimized out>,
    function=<value optimized out>) at assert.c:78
#3 0x000000000014b4c1 in Curl_single_getsock (conn=0x4ebd5a8,
sock=0x7fff0a428eb0, numsocks=5) at transfer.c:1746
#4 0x0000000000151cf8 in multi_getsock (easy=0x48feb38,
socks=0x7fff0a428eb0, numsocks=5) at multi.c:811
#5 0x0000000000151d70 in curl_multi_fdset (multi_handle=0x1ced728,
read_fd_set=0x1cfdbb0, write_fd_set=0x1cfdc40, exc_fd_set=0x1cfdcd0,
    max_fd=0x7fff0a428f14) at multi.c:836
#6 0x000000000047656c in core::CurlStack::fdset (this=<value optimized
out>, readfds=0x6ef6, writefds=0x6, exceptfds=0xffffffffffffffff)
    at curl_stack.cc:107
#7 0x0000000000470cd9 in core::PollManagerEPoll::poll (this=0x1ced400,
timeout={m_time = 1000}) at poll_manager_epoll.cc:85
#8 0x00000000004323af in main (argc=<value optimized out>,
argv=0x7fff0a429198) at main.cc:276
(gdb) bt full
#0 0x0000003a41832215 in raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
        pid = <value optimized out>
        selftid = <value optimized out>
#1 0x0000003a41833d83 in abort () at abort.c:88
        act = Could not find the frame base for "abort".

If there is some more useful information I could get from gdb then please
let me know.

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

Comment By: Ol L (oliverjl)
Date: 2008-08-26 19:15

Message:
Logged In: YES
user_id=1558607
Originator: YES

I would estimate that, on startup, approximately 270 http requests are
being made simultaneously. On occasion rtorrent has not crashed on startup
but instead has done so after several hours, I would estimate that in these
cases the number of simultaneous requests is significantly lower, although
it is difficult to be accurate.
As far as I can see the only usage of libcurl will be those http requests
and a very small number (possibly only one) https request.

Am I correct in thinking that pipelineing means reusing connections? If
so, digging through the rtorrent source seems to reveal this is disabled
(CURLOPT_FORBID_REUSE is set to '1' with a .._setopt() function). I'm
afraid I know very little more than this without just blindly digging
through source code.. :)

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

Comment By: Daniel Stenberg (bagder)
Date: 2008-08-25 21:17

Message:
Logged In: YES
user_id=1110
Originator: NO

Here my first analysis of the valgrind log:

> ==14481== Invalid write of size 8
> ==14481== at 0x4C6AF8E: multi_runsingle (multi.c:907)
> ==14481== by 0x4C6BEEC: curl_multi_perform (multi.c:1475)

This is easy->easy_conn being a bad pointer. This must be a dangling
pointer since it mentions the "Address 0xc28a0a0" below. easy_conn SHOULD
be pointing to a (valid) connectdata struct at that point. I can't see how
it ends up pointing to a freed struct.

> ==14481== Address 0xc28a0a0 is 8 bytes inside a block of size 1,176
free'd
> ==14481== at 0x4A0609F: free (vg_replace_malloc.c:323)
> ==14481== by 0x4C67135: curl_dofree (memdebug.c:238)
> ==14481== by 0x4C51A46: conn_free (url.c:2158)
> ==14481== by 0x4C51C66: Curl_disconnect (url.c:2242)
> ==14481== by 0x4C55D6F: Curl_done (url.c:4637)

This is the flow that lead to the closure and subsequent free() of the
connectdata struct that an easy handle used. Curl_done() clears the
connectdata pointer at the end of the function (url.c:4655).

The following two problems seem to be identical to this.

> ==14481== Invalid write of size 1
> ==14481== at 0x4C55E31: do_init (url.c:4675)
> ==14481== by 0x4C55FA4: Curl_do (url.c:4724)
> ==14481== by 0x4C6B585: multi_runsingle (multi.c:1117)

This is again a bad connectdata pointer passed in, and in do_init() it
writes to a single-byte struct member. The input pointer seems to again be
a dangling pointer pointing to a freed entry judging from the following:

> ==14481== Address 0xc28a29b is 515 bytes inside a block of size 1,176
free'd
> ==14481== at 0x4A0609F: free (vg_replace_malloc.c:323)
> ==14481== by 0x4C67135: curl_dofree (memdebug.c:238)
> ==14481== by 0x4C51A46: conn_free (url.c:2158)

The size is the same and it certainly looks like it simply remains
pointing to the struct it used to point to, but it is now freed...

Are you using pipelining? Is this only HTTP in use? What easy options do
you set? How many easy handles would you estimate that you need to use
before you ever see these problems?

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

Comment By: Daniel Stenberg (bagder)
Date: 2008-08-25 17:39

Message:
Logged In: YES
user_id=1110
Originator: NO

Right, the 131313 means it points to memory that libcurl has freed.
However, the ->handler pointer should always point to static memory and it
is never made to point to allocated memory which makes odd. Even when the
connectdata struct is allocated (in alocate_conn), ->handler is made to
point to a static "dummy" handler struct to avoid it ever being NULL in
practical use.

So to me it looks like memory is being overwritten. Or possibly the entire
conn struct passed in to Curl_do() is bad.

I'll go over your valgrind log tonight and see if I can figure out what it
warns about!

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

Comment By: Ol L (oliverjl)
Date: 2008-08-25 17:17

Message:
Logged In: YES
user_id=1558607
Originator: YES

The upload form it refusing to allow me to upload the logfile. It's
available at: http://pastebin.ca/raw/1184312

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

Comment By: Ol L (oliverjl)
Date: 2008-08-25 17:13

Message:
Logged In: YES
user_id=1558607
Originator: YES

Running rtorrent as-is with valgrind fails as valgrind appears to not
handle the mincore() call which rtorrent uses. Recompiling rtorrent not to
use this call allows it to run with valgrind, the logfile of which is
attached.

The problem appears to be that conn->handler is invalid:

Program received signal SIGSEGV, Segmentation fault.
0x000000000013cfb0 in Curl_do (connp=0x4516ef0, done=0x7fff41ab83ac) at
url.c:4726
4726 if(conn->handler->do_it) {
Current language: auto; currently c
Missing separate debuginfos, use: debuginfo-install keyutils.x86_64
(gdb) print conn->handler
$1 = (const struct Curl_handler *) 0x1313131313131313
(gdb) print conn->handler->do_it
Cannot access memory at address 0x1313131313131323

Possibly something doing ptr = 0x1313.. when they mean *ptr = 0x1313..?
A quick grep shows that 0x13 is used by your memdebug.c (I have curl built
with debug support) as a junk value in its debug free() function. Might
this suggest something is freeing something and then continuing to use it?
Or that something is failing to initialise its memory properly.

valgrind log should be attached now. A test program would most likely
involve a significant amount of work, but we'll see if it comes to that.

Many thanks,
-ol

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

Comment By: Daniel Stenberg (bagder)
Date: 2008-08-25 12:11

Message:
Logged In: YES
user_id=1110
Originator: NO

We prefer working against a recent CVS version (like you're using).

In order for us to repeat this in an easy manner (without having to use
rtorrent), can you narrow down the specifics of your transfers when this
happens? I think it would be valuable to start working on a stand-alone
application that does the transfers similar to your app to see if that
causes any problems.

In the specific crash location at lib/url.c:4726, is the problem at the
conn->handler point is weird or is it the conn->handler->do_it one?

Have you tried to run rtorrent with valgrind and does it then give any
additional clues?

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

Comment By: Ol L (oliverjl)
Date: 2008-08-25 11:58

Message:
Logged In: YES
user_id=1558607
Originator: YES

Crash with memory map:

*** glibc detected *** rtorrent: malloc(): memory corruption:
0x000000000406b018 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a4187b5df]
/lib64/libc.so.6(__libc_malloc+0x98)[0x3a4187ce18]
/lib64/libc.so.6(__backtrace_symbols+0x10a)[0x3a418f937a]
rtorrent[0x431b04]
rtorrent[0x43634a]
/lib64/libc.so.6[0x3a418322a0]
/usr/local/lib/libcurl.so.4(Curl_do+0x41)[0x13cfb0]
/usr/local/lib/libcurl.so.4[0x152586]
/usr/local/lib/libcurl.so.4(curl_multi_perform+0x5c)[0x152eed]
rtorrent[0x4770d5]
rtorrent[0x470d4d]
rtorrent[0x4323af]
/lib64/libc.so.6(__libc_start_main+0xfa)[0x3a4181e32a]
rtorrent(_ZNSt8ios_base4InitD1Ev+0x69)[0x40c4c9]
======= Memory map: ========
00110000-00177000 r-xp 00000000 fd:00 9515946
/usr/local/lib/libcurl.so.4.1.0
00177000-00376000 ---p 00067000 fd:00 9515946
/usr/local/lib/libcurl.so.4.1.0
00376000-00379000 rw-p 00066000 fd:00 9515946
/usr/local/lib/libcurl.so.4.1.0
00400000-004cd000 r-xp 00000000 fd:00 3850248
/usr/local/bin/rtorrent
006cc000-006ce000 rw-p 000cc000 fd:00 3850248
/usr/local/bin/rtorrent
006ce000-006d1000 rw-p 006ce000 00:00 0
006d1000-00784000 r-xp 00000000 fd:00 3883019
/usr/local/lib/libtorrent.so.11.0.2
00784000-00983000 ---p 000b3000 fd:00 3883019
/usr/local/lib/libtorrent.so.11.0.2
00983000-00987000 rw-p 000b2000 fd:00 3883019
/usr/local/lib/libtorrent.so.11.0.2
00987000-00992000 r-xp 00000000 fd:00 4825115
/lib64/libnss_files-2.8.so
00992000-00b91000 ---p 0000b000 fd:00 4825115
/lib64/libnss_files-2.8.so
00b91000-00b92000 r--p 0000a000 fd:00 4825115
/lib64/libnss_files-2.8.so
00b92000-00b93000 rw-p 0000b000 fd:00 4825115
/lib64/libnss_files-2.8.so
00b93000-0449b000 rw-p 00b93000 00:00 0
[heap]
35a1600000-35a162d000 r-xp 00000000 fd:00 4825105
/lib64/libncursesw.so.5.6
35a162d000-35a182d000 ---p 0002d000 fd:00 4825105
/lib64/libncursesw.so.5.6
35a182d000-35a182e000 rw-p 0002d000 fd:00 4825105
/lib64/libncursesw.so.5.6
3752a00000-3752a0e000 r-xp 00000000 fd:00 9518429
/usr/lib64/liblber-2.4.so.2.0.6
3752a0e000-3752c0e000 ---p 0000e000 fd:00 9518429
/usr/lib64/liblber-2.4.so.2.0.6
3752c0e000-3752c0f000 rw-p 0000e000 fd:00 9518429
/usr/lib64/liblber-2.4.so.2.0.6
3753200000-375323f000 r-xp 00000000 fd:00 9518434
/usr/lib64/libldap-2.4.so.2.0.6
375323f000-375343f000 ---p 0003f000 fd:00 9518434
/usr/lib64/libldap-2.4.so.2.0.6
375343f000-3753442000 rw-p 0003f000 fd:00 9518434
/usr/lib64/libldap-2.4.so.2.0.6
3a41400000-3a4141d000 r-xp 00000000 fd:00 4825116
/lib64/ld-2.8.so
3a4161c000-3a4161d000 r--p 0001c000 fd:00 4825116
/lib64/ld-2.8.so
3a4161d000-3a4161e000 rw-p 0001d000 fd:00 4825116
/lib64/ld-2.8.so
3a41800000-3a41962000 r-xp 00000000 fd:00 4825144
/lib64/libc-2.8.so
3a41962000-3a41b62000 ---p 00162000 fd:00 4825144
/lib64/libc-2.8.so
3a41b62000-3a41b66000 r--p 00162000 fd:00 4825144
/lib64/libc-2.8.so
3a41b66000-3a41b67000 rw-p 00166000 fd:00 4825144
/lib64/libc-2.8.so
3a41b67000-3a41b6c000 rw-p 3a41b67000 00:00 0
3a41c00000-3a41c84000 r-xp 00000000 fd:00 4825195
/lib64/libm-2.8.so
3a41c84000-3a41e83000 ---p 00084000 fd:00 4825195
/lib64/libm-2.8.so
3a41e83000-3a41e84000 r--p 00083000 fd:00 4825195
/lib64/libm-2.8.so
3a41e84000-3a41e85000 rw-p 00084000 fd:00 4825195
/lib64/libm-2.8.so
3a42000000-3a42002000 r-xp 00000000 fd:00 4825172
/lib64/libdl-2.8.so
3a42002000-3a42202000 ---p 00002000 fd:00 4825172
/lib64/libdl-2.8.so
3a42202000-3a42203000 r--p 00002000 fd:00 4825172
/lib64/libdl-2.8.so
3a42203000-3a42204000 rw-p 00003000 fd:00 4825172
/lib64/libdl-2.8.so
3a42400000-3a42416000 r-xp 00000000 fd:00 4825207
/lib64/libpthread-2.8.so
3a42416000-3a42615000 ---p 00016000 fd:00 4825207
/lib64/libpthread-2.8.so
3a42615000-3a42616000 r--p 00015000 fd:00 4825207
/lib64/libpthread-2.8.so
3a42616000-3a42617000 rw-p 00016000 fd:00 4825207
/lib64/libpthread-2.8.so
3a42617000-3a4261b000 rw-p 3a42617000 00:00 0
3a42800000-3a4281a000 r-xp 00000000 fd:00 4825185
/lib64/libselinux.so.1
3a4281a000-3a42a19000 ---p 0001a000 fd:00 4825185
/lib64/libselinux.so.1
3a42a19000-3a42a1a000 r--p 00019000 fd:00 4825185
/lib64/libselinux.so.1
3a42a1a000-3a42a1b000 rw-p 0001a000 fd:00 4825185
/lib64/libselinux.so.1
3a42a1b000-3a42a1c000 rw-p 3a42a1b000 00:00 0

3a42c00000-3a42c15000 r-xp 00000000 fd:00 4825226
/lib64/libz.so.1.2.3
3a42c15000-3a42e14000 ---p 00015000 fd:00 4825226
/lib64/libz.so.1.2.3
3a42e14000-3a42e15000 rw-p 00014000 fd:00 4825226
/lib64/libz.so.1.2.3
3a43400000-3a43407000 r-xp 00000000 fd:00 4825221
/lib64/librt-2.8.so
3a43407000-3a43607000 ---p 00007000 fd:00 4825221
/lib64/librt-2.8.so
3a43607000-3a43608000 r--p 00007000 fd:00 4825221
/lib64/librt-2.8.so
3a43608000-3a43609000 rw-p 00008000 fd:00 4825221
/lib64/librt-2.8.so
3a4c000000-3a4c031000 r-xp 00000000 fd:00 4825146
/lib64/libidn.so.11.5.28
3a4c031000-3a4c231000 ---p 00031000 fd:00 4825146
/lib64/libidn.so.11.5.28
3a4c231000-3a4c232000 rw-p 00031000 fd:00 4825146
/lib64/libidn.so.11.5.28
3a4c800000-3a4c811000 r-xp 00000000 fd:00 4825231
/lib64/libresolv-2.8.so
3a4c811000-3a4ca11000 ---p 00011000 fd:00 4825231
/lib64/libresolv-2.8.so
3a4ca11000-3a4ca12000 r--p 00011000 fd:00 4825231
/lib64/libresolv-2.8.so
3a4ca12000-3a4ca13000 rw-p 00012000 fd:00 4825231
/lib64/libresolv-2.8.so
3a4ca13000-3a4ca15000 rw-p 3a4ca13000 00:00 0
3a4d000000-3a4d016000 r-xp 00000000 fd:00 4825203
/lib64/libgcc_s-4.3.0-20080428.so.1
3a4d016000-3a4d215000 ---p 00016000 fd:00 4825203
/lib64/libgcc_s-4.3.0-20080428.so.1
3a4d215000-3a4d216000 rw-p 00015000 fd:00 4825203
/lib64/libgcc_s-4.3.0-20080428.so.1
3a4d400000-3a4d402000 r-xp 00000000 fd:00 4825232
/lib64/libcom_err.so.2.1
3a4d402000-3a4d601000 ---p 00002000 fd:00 4825232
/lib64/libcom_err.so.2.1
3a4d601000-3a4d602000 rw-p 00001000 fd:00 4825232
/lib64/libcom_err.so.2.1
3a4e000000-3a4e005000 r-xp 00000000 fd:00 9512642
/usr/lib64/libsigc-2.0.so.0.0.0
3a4e005000-3a4e204000 ---p 00005000 fd:00 9512642
/usr/lib64/libsigc-2.0.so.0.0.0
3a4e204000-3a4e205000 rw-p 00004000 fd:00 9512642
/usr/lib64/libsigc-2.0.so.0.0.0
3a4e800000-3a4e824000 r-xp 00000000 fd:00 3793074
/usr/lib64/libk5crypto.so.3.1
3a4e824000-3a4ea23000 ---p 00024000 fd:00 3793074
/usr/lib64/libk5crypto.so.3.1
3a4ea23000-3a4ea25000 rw-p 00023000 fd:00 3793074
/usr/lib64/libk5crypto.so.3.1
3a4ec00000-3a4ec02000 r-xp 00000000 fd:00 4825230
/lib64/libkeyutils-1.2.so
3a4ec02000-3a4ee01000 ---p 00002000 fd:00 4825230
/lib64/libkeyutils-1.2.so
3a4ee01000-3a4ee02000 rw-p 00001000 fd:00 4825230
/lib64/libkeyutils-1.2.so
3a4f000000-3a4f02e000 r-xp 00000000 fd:00 3793079
/usr/lib64/libgssapi_krb5.so.2.2
3a4f02e000-3a4f22d000 ---p 0002e000 fd:00 3793079
/usr/lib64/libgssapi_krb5.so.2.2
3a4f22d000-3a4f22f000 rw-p 0002d000 fd:00 3793079
/usr/lib64/libgssapi_krb5.so.2.2
3a4f400000-3a4f49f000 r-xp 00000000 fd:00 3793075
/usr/lib64/libkrb5.so.3.3
3a4f49f000-3a4f69e000 ---p 0009f000 fd:00 3793075
/usr/lib64/libkrb5.so.3.3
3a4f69e000-3a4f6a2000 rw-p 0009e000 fd:00 3793075
/usr/lib64/libkrb5.so.3.3

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

Comment By: Ol L (oliverjl)
Date: 2008-08-24 19:58

Message:
Logged In: YES
user_id=1558607
Originator: YES

This issue seems to occur more frequently when rtorrent has a large number
of open torrents. This would probably correspond to curl being asked to
carry out a large number of simultaneous http or https requests
simultaneously.

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2071932&group_id=976
Received on 2008-10-08