From: Damien.Olivier.Robert+ruby@...
Date: 2017-03-24T23:38:29+00:00
Subject: [ruby-core:80317] [Ruby trunk Bug#13236] Ruby segfault

Issue #13236 has been updated by Gondolin (Damien Robert).


nobu (Nobuyoshi Nakada) wrote:
> Could you enable debugging?

So I *think* I have managed to bisect the segfault. When I comment a specific test I never see the segfault, but when I uncomment it I get (sometimes) the segfault. The test itself in isolation does not segfault, it is only when I run a fairly large amount of other tests that I can get the segfault. Contrary to what I was thinking at first, the tests about graphs with loops are not the ones responsible for the segfault. I can provide the debugging information if you still need but they only concern the other tests, not the one that causes the segfault.

Here is the tested code and the test
~~~ ruby

module Meta
  extend self
  #convert a class into a module using refinements
  #ex: (Class.new { include Meta.refined_module(String) { def length; super+5; end } }).new("foo").length #=> 8
  #This uses the fact that a refining module of klass behaves as if it had
  #klass has his direct ancestor
  def refined_module(klass,&b)
    klass=klass.singleton_class unless Module===klass
    Module.new do
      #including the module rather than just returning it allow us to
      #still be able to use 'using' ('using' does not work directly on
      #refining modules, only the enclosing ones)
      include refine(klass) {
        module_eval(&b) if block_given?
      }
    end
  end
end

describe Meta do
  it "Can convert a class to module" do
    (Class.new { include DR::Meta.refined_module(String) { def length; super+5; end } }).new("foo").length.must_equal(8)
  end
end
~~~

----------------------------------------
Bug #13236: Ruby segfault
https://bugs.ruby-lang.org/issues/13236#change-63788

* Author: Gondolin (Damien Robert)
* Status: Feedback
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.4.0p0 (2016-12-24 revision 57164) [x86_64-linux]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
I have a program that segfault under certain conditions. It does not happen often, so it is hard to get the segfault.
The code is in https://github.com/DamienRobert/drain
You can run 'rake test' to (sometime, not often) get the core dump. I was able to get the coredump across different computers and different ruby versions.
In the tests I construct a graph with a cyclic path, so there is probably a bug in the gc when there are cyclic dependencies.

I join a coredump (compressed with xz), here is the backtrace (not very usefull because I did not compile ruby with debugging symbols):

```
Core was generated by `/usr/bin/ruby -w -Ilib:test -I/usr/lib/ruby/gems/2.4.0/gems/rake-12.0.0/lib /us'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007facdff1304f in raise () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7face08fe700 (LWP 7251))]
(gdb) bt
#0  0x00007facdff1304f in raise () from /usr/lib/libc.so.6
#1  0x00007facdff1447a in abort () from /usr/lib/libc.so.6
#2  0x00007face03096e1 in ?? () from /usr/lib/libruby.so.2.4
#3  0x00007face03c50ee in ?? () from /usr/lib/libruby.so.2.4
#4  <signal handler called>
#5  0x00007face02c9b44 in ?? () from /usr/lib/libruby.so.2.4
#6  0x00007face0321d0d in ?? () from /usr/lib/libruby.so.2.4
#7  0x00007face0322f13 in ?? () from /usr/lib/libruby.so.2.4
#8  0x00007face032515d in rb_gc_call_finalizer_at_exit ()
   from /usr/lib/libruby.so.2.4
#9  0x00007face03104c4 in ruby_cleanup () from /usr/lib/libruby.so.2.4
#10 0x00007face0310645 in ruby_run_node () from /usr/lib/libruby.so.2.4
#11 0x00000000004007cb in ?? ()
#12 0x00007facdff00291 in __libc_start_main () from /usr/lib/libc.so.6
#13 0x00000000004007fa in _start ()
```

---Files--------------------------------
ruby.coredump.xz (1.1 MB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>