Segmentation fault when adding Curl::Easy instances to a Curl::Multi about curb HOT 13 CLOSED

Do you have a sample use case?

from curb.

Not sure what you mean with use case? I have sent you the the code and samples from valgrind.

from curb.

Andre, are you by any chance setting the headers anywhere in your code? We are seeing the exact same problem, and looking at our backtrace, it segfaults when we are allocating a new curl instance and are trying to initialize some headers (specifically, it's the first time we try to access the header hash)... hence the st_lookup segfault.

taf2, any ideas or suggestions?

from curb.

Ilya, we are setting the usual headers: accept, user_agent etc. The first time I have seen this problem it has not been related to setting headers butwhen one of the callback methods is called. We where using gem v0.6.0 at this time. I did some tests with valgrind with gem v0.6.4. With this version the segfault looked like what you described.
We run on EC2. For some reason we see the problem only on 64 bit machines. Our (crapy) fix at the moment is to run the crawlers on small instances.

from curb.

Hmm, same setup. EC2, 64 bit (xlarge). CentOS 5.1.

Latest & greatest version curl on the server, etc.

from curb.

Ilya, I'm going to use your suggest of the first access on a my 64 box and see if i can reproduce...

from curb.

Todd, also I should mention that I'm seeing this problem in exact same setup as described above: within the success callback I'm creating a new curl easy instance and queuing it up into the multi-loop. The idea is to keep the multi loop always occupied, always running several hundred connections.

from curb.

Can you try this patch: http://gist.github.com/290650

from curb.

Also, in HEAD I changed the order of easy_setup and multi_add. My thought is that maybe there are bad easy handles getting into the multiple handle... so before if an easy handle was added and than raised an exception the multi handle could be left in a bad state. Now if the easy handle is going to raise it'll raise before it gets into the multi handle... maybe give this a try after the other patch above and please let me know the effects... to really isolate this issue down to something repeatable... would be ideal..

from curb.

Grabbed HEAD and applied your patch -- running now. The challenge is and will be in reproducing the actual bug. We use curl-multi interface to drive our downloaders, and sometimes they go for hours before the process falls down. I haven't been able to reproduce this problem reliably before..

Interestingly enough though, I have run extended tests against local endpoints (nginx server) and same code did not fail me there. It's almost like it has something to do with a specific site / URL.

Last but not least: we're actually using 0.4.6.0 in production at the moment. I recently upgraded several of our production boxes to latest gem, but for some reason, our throughput dropped by more than 2x immediately following the upgrade. We couldn't spot any obvious problems after several hours of investigation, and ended up reverting to the older version -- perhaps something to look into. The same segfault problem showed up in 0.6.x release as well though.

ig

from curb.

Aha, I think we're on the right track. Got a different stack trace this time. Looks like it's SEGV'ing when it tries to invoke the on_failure callback:

/pr/core/app/keystone/downloader.rb:136: [BUG] Segmentation fault
ruby 1.9.2dev (2009-07-18 trunk 24186) [x86_64-linux]

-- control frame ----------
c:0030 p:---- s:0094 b:0094 l:000093 d:000093 CFUNC :on_failure
c:0029 p:0011 s:0091 b:0091 l:000228 d:000090 BLOCK /pr/core/app/keystone/downloader.rb:136
c:0028 p:---- s:0088 b:0088 l:000087 d:000087 FINISH
c:0027 p:---- s:0086 b:0086 l:000085 d:000085 CFUNC :call
c:0026 p:---- s:0084 b:0084 l:000083 d:000083 CFUNC :new

from curb.

I wonder if this is bug in the version of ruby 1.9.2 ?

from curb.

I wonder if the recent refactoring for issue 24 has had additional impact on this issue? Also, I was looking at a few of the bug fixes in most recent versions of libcurl and was thinking they could also be suspect....

from curb.