Patron segfaults under ruby 2.0.0p247 #72

bhaberer opened this Issue Jul 9, 2013 · 18 comments


None yet
bhaberer commented Jul 9, 2013

Just a heads up, was doing some checking to see how things were looking for ruby 2.0.0, and Patron was one of the handful of gems that just seems to segfault.

~/src/patron > rvm use 2.0.0
Using /Users/bhaberer/.rvm/gems/ruby-2.0.0-p247

~/src/patron > git fetch upstream

~/src/patron > bundle
The source :rubygems is deprecated because HTTP requests are insecure.
Please change your source to '' if possible, or '' if not.
Fetching gem metadata from
Fetching gem metadata from
Resolving dependencies...
Installing rake (
Using bundler (1.3.5)
Installing diff-lcs (1.1.3)
Using patron (0.4.18) from source at .
Installing rake-compiler (0.7.9)
Installing rcov (0.9.11)
Installing rspec-core (2.7.1)
Installing rspec-expectations (2.7.0)
Installing rspec-mocks (2.7.0)
Installing rspec (2.7.0)
Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.

~/src/patron > bundle exec irb
The source :rubygems is deprecated because HTTP requests are insecure.
Please change your source to '' if possible, or '' if not.
2.0.0-p247 :001 > require 'patron'
 => true
2.0.0-p247 :002 > session =
 => #<Patron::Session:0x007fca24110648 @headers={}, @timeout=5, @connect_timeout=1, @max_redirects=5, @auth_type=:basic>
2.0.0-p247 :003 > session.base_url = 'http://localhost/'
 => "http://localhost/"
2.0.0-p247 :004 > session.get ''
/Users/bhaberer/src/patron/lib/patron/session.rb:228: [BUG] Segmentation fault
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]

- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:
     * ~/Library/Logs/CrashReporter
     * /Library/Logs/CrashReporter
     * ~/Library/Logs/DiagnosticReports
     * /Library/Logs/DiagnosticReports
   the more detail of.

-- Control frame information -----------------------------------------------
c:0021 p:---- s:0092 e:000091 CFUNC  :handle_request
c:0020 p:0478 s:0088 e:000087 METHOD /Users/bhaberer/src/patron/lib/patron/session.rb:228
c:0019 p:0017 s:0077 e:000076 METHOD /Users/bhaberer/src/patron/lib/patron/session.rb:129
c:0018 p:0008 s:0072 e:000071 EVAL   (irb):4 [FINISH]
c:0017 p:---- s:0070 e:000069 CFUNC  :eval
c:0016 p:0024 s:0063 e:000062 METHOD /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/workspace.rb:86
c:0015 p:0025 s:0056 e:000054 METHOD /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/context.rb:380
c:0014 p:0022 s:0050 e:000049 BLOCK  /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:492
c:0013 p:0040 s:0042 e:000041 METHOD /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:624
c:0012 p:0009 s:0037 e:000036 BLOCK  /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:489
c:0011 p:0118 s:0033 e:000032 BLOCK  /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:247 [FINISH]
c:0010 p:---- s:0030 e:000029 CFUNC  :loop
c:0009 p:0007 s:0027 e:000026 BLOCK  /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:233 [FINISH]
c:0008 p:---- s:0025 e:000024 CFUNC  :catch
c:0007 p:0015 s:0021 e:000020 METHOD /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:232
c:0006 p:0030 s:0018 E:000298 METHOD /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:488
c:0005 p:0008 s:0015 e:000014 BLOCK  /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:397 [FINISH]
c:0004 p:---- s:0013 e:000012 CFUNC  :catch
c:0003 p:0143 s:0009 E:000578 METHOD /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:396
c:0002 p:0122 s:0004 E:0019c8 EVAL   /Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/bin/irb:16 [FINISH]
c:0001 p:0000 s:0002 E:000698 TOP    [FINISH]

/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/bin/irb:16:in `<main>'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:396:in `start'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:396:in `catch'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:397:in `block in start'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:488:in `eval_input'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:232:in `each_top_level_statement'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:232:in `catch'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:233:in `block in each_top_level_statement'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:233:in `loop'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/ruby-lex.rb:247:in `block (2 levels) in each_top_level_statement'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:489:in `block in eval_input'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:624:in `signal_status'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb.rb:492:in `block (2 levels) in eval_input'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/context.rb:380:in `evaluate'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/workspace.rb:86:in `evaluate'
/Users/bhaberer/.rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/irb/workspace.rb:86:in `eval'
(irb):4:in `irb_binding'
/Users/bhaberer/src/patron/lib/patron/session.rb:129:in `get'
/Users/bhaberer/src/patron/lib/patron/session.rb:228:in `request'
/Users/bhaberer/src/patron/lib/patron/session.rb:228:in `handle_request'

-- C level backtrace information -------------------------------------------

-- Other runtime information -----------------------------------------------

We see this happening in ruby 1.9.3 as well (ubuntu)

pravi commented Apr 4, 2014

This is blocking debian's efforts to remove ruby 1.9 from archive as we are not able to update patron. Can someone look into this?

pravi commented Apr 9, 2014

seems like a hard to reproduce consistently.

I ran into this problem today, patron is a dependency of parse-ruby-client, and it segfault on every single post request.
I thought it could be something related to heartbleed, I upgraded openssl to 1.0.1g, but the error's still there.
I'm using Ruby 2.1.1.
Any suggestion/idea?

App 87866 stderr: /Users/gregorio/.rvm/gems/ruby-2.1.1/gems/patron-0.4.18/lib/patron/session.rb:223: [BUG] 
App 87866 stderr: Segmentation fault at 0x00000000000110
App 87866 stderr: ruby 2.1.1p76 (2014-02-24 revision 45161) [x86_64-darwin13.0]
App 87866 stderr: 
App 87866 stderr: -- Crash Report log information --------------------------------------------
App 87866 stderr:    See Crash Report log file under the one of following:
App 87866 stderr:      * ~/Library/Logs/CrashReporter
App 87866 stderr:      * /Library/Logs/CrashReporter
App 87866 stderr:      * ~/Library/Logs/DiagnosticReports
App 87866 stderr:      * /Library/Logs/DiagnosticReports
App 87866 stderr:    for more details.
App 87866 stderr: 
App 87866 stderr: -- Control frame information -----------------------------------------------
App 87866 stderr: c:0087 p:---- s:0488 e:000487 CFUNC  :handle_request

Due to the segfault issues, I have basically migrated all of my code to use nahi's httpclient gem, which has an excellent API, is mostly pure-ruby plus some calls to openssl, works in ruby 1.9, ruby 2.0, ruby 2.1, and jruby 1.6/1.7, across all platforms, and comes with a bundled CA and verifies certs properly in strict mode, and has excellent thread-safety.

Ok, I noticed that patron works just fine with thin as server (WEBrick as well), but doesn't seem to work with passenger + apache.
Anybody has any idea? It's weird, passenger is not some sort of unknown webserver.

I solved the problem switching to Faraday which works perfectly with my setup, at least until a better solution is discovered for Patron.

pravi commented May 21, 2014

patron is removed from debian testing because it was failing to build because segfaulting tests

Faraday folks are not interested to maintain it lostisland/faraday#377
asking if anyone from webmock wants to maintain it bblimke/webmock#391

hemanth commented May 21, 2014


We switched from patron to typhoeus. No more segfaults.


Guys, could you please try to reproduce your segfaults with #93? I fixed some segfaults but not sure if there are any more such issues in C code.

hggh commented Aug 25, 2015

@marshall-lee I have tested the commit from #93 the patch resolves the issue with the Segfault. But the tests fail within ruby 2.2 on debian.

hggh commented Aug 25, 2015

update: with #92 it works within ruby2.2. @toland could you please release a new gem?


yeah, would be good

toland commented Sep 8, 2015

Hey guys. Sorry it took me so long to respond to this. I was out of town for a week and it took me a while to get my dev environment set back up once I returned. Anyway, I have released version 0.5.0 of Patron with all of the fixes to date.

All of the tests pass for me with Ruby 2.2.3 on OSX. Let me know if you see any other issues.

@toland toland closed this Sep 8, 2015
julik commented May 2, 2016 edited

@desmondhume As a matter of fact I know exactly what this is. And it only happens on OSX. The problem is we can't fix it within Patron itself. If you are still experiencing the issue, you need to install curl from homebrew and force it to --with-openssl. The reason this stopped happening is because under Passenger you do your curl_easy_perform in a forked process, which triggers a bug in Apple's secure transport. With Thin you are within the same process, so the issue stays masked. Same for our tests.

julik commented May 2, 2016

@pravi so far there was a couple of segfaults fixed AFAIK, and one segfault is a known issue with OSX curl linked against Apple SSL libraries, and only when using forking. Moreover, this specific segfault also happens in curb and in various PHP forking situations too. It is very unlikely it is relevant for debian.

I was not able to find references to build logs for debian bug you likned. Meanwhile, you opened issues on 3 projects to remove Patron support (???), while the actual cause of the issue was not found until recently. Maybe you could let them know we are still kicking now?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment