Segmentation fault in Marshal.load

Dan (or whoever else), can you provide a code snippet that triggers the bug on Ubuntu? I tried the example from the upstream bug, but it would not segfault. Here's my test case:

ubuntu@lucid-server:~$ cat fault.rb
#!/usr/bin/ruby
require File.expand_path("/usr/share/rails/activesupport/lib/active_support/multibyte/unicode_database.rb", __FILE__)
ActiveSupport::Multibyte::UnicodeDatabase.new.codepoints
puts "No crash"
ubuntu@lucid-server:~$ ./fault.rb
No crash

Here is a test which consistently segfaults on my Lucid box.

bug_test.tar.gz contains two files:
testdata.xml - a ~1MB data file of XML
test.rb - a script that opens and parses that data file several times to cause the crash

Example run:
$ ruby -v
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
$ ./test.rb
parsed 0
parsed 1
parsed 2
/var/lib/gems/1.8/gems/activesupport-2.3.2/lib/active_support/xml_mini/libxml.rb:125: [BUG] Segmentation fault
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

Aborted

To test on plain lucid, you would need to:

    $ sudo apt-get install rails libxml-ruby
    $ gem install activesupport --version 2.3.2

And then run the above test-case. It reliably segfault for me, so marking confirmed.

Do we have confirmation that this is resolved in the Maverick version?

Issue sounds like it is isolated to amd64, and not fixed yet.

== Lucid (i386) ==
$ ./test.rb
parsed 0
parsed 1
parsed 2
parsed 3
parsed 4
parsed 5
parsed 6
parsed 7
parsed 8
parsed 9
parsed 10
parsed 11
parsed 12
parsed 13
parsed 14

== Maverick (amd64) ==
$ ./test.rb
DEPRECATION WARNING: require "activesupport" is deprecated and will be removed in Rails 3. Use require "active_support" instead.. (called from /usr/lib/ruby/1.8/activesupport.rb:2)
parsed 0
parsed 1
parsed 2
parsed 3
/usr/lib/ruby/1.8/active_support/xml_mini/libxml.rb:125: [BUG] Segmentation fault
ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]

== Natty (amd64) ==
$ ./test.rb
DEPRECATION WARNING: require "activesupport" is deprecated and will be removed in Rails 3. Use require "active_support" instead.. (called from /usr/lib/ruby/1.8/activesupport.rb:2)
parsed 0
parsed 1
/usr/lib/ruby/1.8/active_support/xml_mini/libxml.rb:125: [BUG] Segmentation fault
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]

Aborted (core dumped)

This seems to affect rails, not ruby. Updating as appropriate.

Dave is correct, maverick is also affected. Don't have a natty install nearby to test, so I am not sure.

I thought the bug was specific to ruby 1.8.7 p249, per the linked upstream report. In comment 8, it's reported as fixed. I am not sure anymore whether it is fixed upstream or not.

Etienne, it don't think the ruby upstream report In comment 8 is related.

This bug was fixed in the package rails - 2.3.5-1.2ubuntu1

---------------
rails (2.3.5-1.2ubuntu1) natty; urgency=low

  * debian/patches/cdata-and-white-space-handling.patch: Handle CDATA and
    improve white space handling, fixing a Segmentation Fault in some
    circumstances. Patch based on subset of upstream commit range.
    (LP: #670571)
 -- Dave Walker (Daviey) <email address hidden> Wed, 16 Mar 2011 01:03:12 +0000

The specific test case seems to be resolved in Natty now.. however, whilst testing the patch, i discovered that the segmentation fault is non-deterministic - which is somewhat concerning. There could indeed be a deeper bug in ruby. Attaching a backtrace.

Not sure if this is related, http://groups.google.com/group/emm-ruby/browse_thread/thread/950573fc9eb248ae

Can someone actually affected by the bug provide us with some more insight? It would be good to fix the underlying segfault, but we would need to better understand what triggers it. Has it been fixed upstream at all?

Hi Etienne. I'm not sure that we have any more info here, what else would you like us to provide? I'll do what I can, but we had hoped that providing a testcase that triggers the bug would be sufficient...

Indeed, the test-case is resolved in natty. That does not mean the underlying bug is fixed, though.

Mark, we'll need to know whether the underlying bug is indeed fixed or not in upstream Ruby, and ideally figure which commit fixed it. Failing that, a better (more specific?) test-case that segfault deterministically would help, although it's not guaranteed.

Hi again, just to make sure I understand, when you say "we" above, do you mean that is something that you (ubuntu) folks need to/are going to do, or that it is something that I need to do?

If it's something that we (those affected by the issue) need to do, then I may be fundamentally misunderstanding the purpose of this bug. Should we be working directly with the ruby devs to get this fixed and then just use this space to point ubuntu folks to a patch number, or do you all do the sort of deeper analysis necessary for the above?

Thanks, and sorry for my general lack of insight into how this process works.

Mark, no problem, and no apologies required. Fundamentally, the problem is that we do not have a corresponding upstream commit that would fix the bug. In fact, it's not entirely clear whether the bug is fixed upstream or not. Without a good knowledge of the Ruby interpreter code base, it is close to impossible to figure out exactly what is going on.

Also, from what I understand, Dave committed a fix in natty for the specific test-case we currently have (posted by Dan Van Derveer). Does that fix actually address the problem as you experience it? If so, then I guess it could be considered for lucid. If not, then we will need a more specific test-case.

Dave, does the above make any sense to you?

Could this actually be http://rubyforge.org/tracker/?func=detail&atid=1971&aid=26863&group_id=494?