Segfault due to retaining header string

[willglynn]

I'm getting intermittent segfaults that I've traced back to:

Streamly::Request.new(
  :method => :get,
  :url => ...,
  :response_body_Handler => Proc.new {...},
  :response_header_handler => Proc.new { |header|
    if header =~ /^Last-Modified: ([^\r\n]+)[\r\n]+$/i
      found_mtime = $1
    end
  }).execute
puts found_mtime.inspect

Dies with:

ruby(33776,0x7fff71160c20) malloc: *** error for object 0x106468b40: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Abort trap

This makes them go away:

found_mtime = $1.to_sym.to_s

It appears that the header value is somehow getting GC'd away while it's still needed. I'm doing a lot of string handling in the :response_body_handler (though none of it affecting the string captured from the header -- that's not used until after the request is done), so the GC is undoubtedly being invoked.

Platform: Mac OSX 10.6.4, ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

I'm still trying to distill this into a testcase, but it's fickle and intermittent. It's definitely server-dependent, probably requires Transfer-Encoding: chunked, and possibly could involve Content-Encoding: gzip and/or a timing variable.

[brianmario]

Does this happen with the current code from master?

[willglynn]

Unrelated:

$ gem build streamly.gemspec
ERROR:  While executing gem ... (Gem::InvalidSpecificationException)
   ["spec/sinatra.rb"] are not files

But past that, looks like no, it doesn't still happen. Or, if it does, it doesn't happen nearly as often. I've done ten runs now without incident, while the previous failure rate was about 40%.

So, great, thanks!

[brianmario]

Fixed the gemfile, thanks for trying it out! I'll do my best to push the new version tonight

[brianmario]

Pushed, lemme know if you have any trouble!