curl-library
OOM leak in multi code
Date: Wed, 22 Jun 2011 21:41:13 -0700
There has been a memory leak in an out-of-memory situation in the multi
interface code for quite a while now. It shows up in the torture tests I'm
running in the autobuilds (for example
http://curl.haxx.se/dev/log.cgi?id=20110622123024-30152#prob1). All the
torture test failures are multi interface tests, so it's likely that
the root cause is only one or two problems in the code.
I tracked the first one down some time ago, but it hasn't been clear to me
what the best fix is. You can see the failure in the current git
source by running "make test TEST_Q='-a -p -n -k -v -t992 526'" (you may
want to compile with CPPFLAGS=-DMEMDEBUG_LOG_SYNC or you could lose some
memdump logs, confusing the parser).
This is a failure of Curl_llist_insert_next() called from
Curl_addHandleToPipeline() which ends up propagating with a CURLE_OUT_OF_MEMORY
error code until multi_runsingle() calls multi_addmsg() (at line 1676) to
signal CURLMSG_DONE. Of course, being in an OOM situation, multi_addmsg()
fails as well when it attempts to do a Curl_llist_insert_next() of its
own. But the next line sets the state to CURLM_STATE_MSGSENT which
doesn't seem right since the multi_addmsg() failed, and things continue
downhill from there (there's at least one more failing memory allocation after
that point, and it all ends in a segfault when a freed recv_pipe pointer is
dereferenced).
I'm not very familiar with the multi code, but there doesn't appear to be a
simple fix for this. Does anyone have any ideas?
>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-06-23