Bug #5047

Segfault (most likely involving require)

Added by Jack Christensen almost 3 years ago. Updated over 2 years ago.

[ruby-core:38171]
Status:Closed
Priority:High
Assignee:Koichi Sasada
Category:core
Target version:1.9.3
ruby -v:- Backport:

Description

Rails application randomly segfaults when running rspec. It will segfault about 80% of the time before any specs run. It seems to be related to requiring files. If it succeeds in getting to any specs it will run all of them without segfaulting.

The catalyst for the segfault seems to be the prawn gem. I have tested several rails applications where adding prawn to the Gemfile crashes them. However, there need to be certain other gems in place as well.

source 'http://rubygems.org'

gem 'rails', '3.1.0.rc4'

gem 'tiny_tds'
gem 'activerecord-sqlserver-adapter', :git => 'git://github.com/rails-sqlserver/activerecord-sqlserver-adapter.git'

group :test do
gem 'rspec-rails', '>= 2.6.0'
end

gem "prawn"

This Gemfile will crash most of the time when running bundle exec rspec spec. If I replace the tiny_tds and activerecord-sql-server-adapter with sqlite3 it does not crash. But I do not believe the fault is with the SQL server gems as in my other rails projects I am using the pg gem and they also crash.

Another interesting point is the order of the Gemfile matters. If I move the prawn gem to the top of the Gemfile the segfaults do not occur.

The crashes occur at multiple locations, but the most most common is: activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237.

I've put a whole stack dump below.

/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237: [BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86
64-linux]

-- control frame ----------
c:0042 p:---- s:0143 b:0143 l:000142 d:000142 CFUNC :require
c:0041 p:0012 s:0139 b:0139 l:000131 d:000138 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237
c:0040 p:0054 s:0137 b:0137 l:000136 d:000136 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:225
c:0039 p:0013 s:0132 b:0132 l:000131 d:000131 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237
c:0038 p:0119 s:0127 b:0127 l:000126 d:000126 TOP /usr/local/lib/ruby/gems/1.9.1/gems/rspec-mocks-2.6.0/lib/rspec/mocks/framework.rb:14
c:0037 p:---- s:0125 b:0125 l:000124 d:000124 FINISH
c:0036 p:---- s:0123 b:0123 l:000122 d:000122 CFUNC :require
c:0035 p:0012 s:0119 b:0119 l:000111 d:000118 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:237
c:0034 p:0054 s:0117 b:0117 l:000116 d:000116 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:225
c:0033 p:0013 s:0112 b:0112 l:000111 d:000111 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:237
c:0032 p:0011 s:0107 b:0107 l:000106 d:000106 TOP /usr/local/lib/ruby/gems/1.9.1/gems/rspec-mocks-2.6.0/lib/rspec/mocks.rb:1
c:0031 p:---- s:0105 b:0105 l:000104 d:000104 FINISH
c:0030 p:---- s:0103 b:0103 l:000102 d:000102 CFUNC :require
c:0029 p:0012 s:0099 b:0099 l:000091 d:000098 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237
c:0028 p:0054 s:0097 b:0097 l:000096 d:000096 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:225
c:0027 p:0013 s:0092 b:0092 l:000091 d:000091 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237
c:0026 p:0011 s:0087 b:0087 l:000086 d:000086 TOP /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/mocking/with
rspec.rb:1
c:0025 p:---- s:0085 b:0085 l:000084 d:000084 FINISH
c:0024 p:---- s:0083 b:0083 l:000082 d:000082 CFUNC :require
c:0023 p:0012 s:0079 b:0079 l:000071 d:000078 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237
c:0022 p:0054 s:0077 b:0077 l:000076 d:000076 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:225
c:0021 p:0013 s:0072 b:0072 l:000071 d:000071 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237
c:0020 p:0186 s:0067 b:0067 l:000066 d:000066 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:176
c:0019 p:0016 s:0063 b:0062 l:000061 d:000061 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:135
c:0018 p:0013 s:0058 b:0058 l:000051 d:000057 BLOCK /home/jackc/work/segfault/spec/spec
helper.rb:18
c:0017 p:0062 s:0055 b:0055 l:000054 d:000054 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core.rb:79
c:0016 p:0125 s:0052 b:0052 l:000051 d:000051 TOP /home/jackc/work/segfault/spec/spechelper.rb:10
c:0015 p:---- s:0050 b:0050 l:000049 d:000049 FINISH
c:0014 p:---- s:0048 b:0048 l:000047 d:000047 CFUNC :require
c:0013 p:0011 s:0044 b:0044 l:000043 d:000043 TOP /home/jackc/work/segfault/spec/controllers/application
controllerspec.rb:1
c:0012 p:---- s:0042 b:0042 l:000041 d:000041 FINISH
c:0011 p:---- s:0040 b:0040 l:000039 d:000039 CFUNC :load
c:0010 p:0025 s:0036 b:0036 l:000027 d:000035 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:419
c:0009 p:---- s:0033 b:0033 l:000032 d:000032 FINISH
c:0008 p:---- s:0031 b:0031 l:000030 d:000030 CFUNC :map
c:0007 p:0017 s:0028 b:0028 l:000027 d:000027 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:419
c:0006 p:0074 s:0025 b:0025 l:000024 d:000024 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/command
line.rb:18
c:0005 p:0055 s:0020 b:0020 l:000019 d:000019 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:80
c:0004 p:0101 s:0014 b:0014 l:000013 d:000013 METHOD /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:69
c:0003 p:0021 s:0007 b:0006 l:002108 d:000005 BLOCK /usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:11
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH

c:0001 p:0000 s:0002 b:0002 l:000688 d:000688 TOP

-- Ruby level backtrace information ----------------------------------------
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:11:in block in autorun'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:69:in
run'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/runner.rb:80:in run_in_process'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/command_line.rb:18:in
run'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:419:in load_spec_files'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:419:in
map'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:419:in block in load_spec_files'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:419:in
load'
/home/jackc/work/segfault/spec/controllers/applicationcontrollerspec.rb:1:in <top (required)>'
/home/jackc/work/segfault/spec/controllers/application_controller_spec.rb:1:in
require'
/home/jackc/work/segfault/spec/spechelper.rb:10:in <top (required)>'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core.rb:79:in
configure'
/home/jackc/work/segfault/spec/spec
helper.rb:18:in block in <top (required)>'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:135:in
mockwith'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/configuration.rb:176:in mock_framework='
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in
require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:225:in load_dependency'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in
block in require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237:in require'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-core-2.6.4/lib/rspec/core/mocking/with_rspec.rb:1:in
'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:237:in require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:225:in
loaddependency'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:237:in block in require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in
require'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-mocks-2.6.0/lib/rspec/mocks.rb:1:in <top (required)>'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in
require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:225:in load_dependency'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in
block in require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active
support/dependencies.rb:237:in require'
/usr/local/lib/ruby/gems/1.9.1/gems/rspec-mocks-2.6.0/lib/rspec/mocks/framework.rb:14:in
'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/activesupport/dependencies.rb:237:in require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:225:in
load
dependency'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in block in require'
/usr/local/lib/ruby/gems/1.9.1/gems/activesupport-3.1.0.rc4/lib/active_support/dependencies.rb:237:in
require'

-- C level backtrace information -------------------------------------------
/usr/local/bin/ruby(rbvmbugreport+0x9e) [0x523b6e]
/usr/local/bin/ruby() [0x565508]
/usr/local/bin/ruby(rbbug+0xb1) [0x5656a1]
/usr/local/bin/ruby() [0x4b2ca8]
/lib/libpthread.so.0(+0xf8f0) [0x7fa523e988f0]
/usr/local/bin/ruby(st
freetable+0x43) [0x4bbb33]
/usr/local/bin/ruby() [0x426cf5]
/usr/local/bin/ruby() [0x4277ed]
/usr/local/bin/ruby() [0x4c0562]
/usr/local/bin/ruby(rb
usasciistrnew+0x13) [0x4c0683]
/usr/local/bin/ruby(rbfileexpandpath+0x42) [0x5706c2]
/usr/local/bin/ruby() [0x56a63a]
/usr/local/bin/ruby(rb
requiresafe+0x25d) [0x56aa8d]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x5168c1]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rb
iseqeval+0x1ee) [0x519aee]
/usr/local/bin/ruby() [0x569a08]
/usr/local/bin/ruby(rb
requiresafe+0x647) [0x56ae77]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x5168c1]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rb
iseqeval+0x1ee) [0x519aee]
/usr/local/bin/ruby() [0x569a08]
/usr/local/bin/ruby(rb
requiresafe+0x647) [0x56ae77]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x5168c1]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rb
iseqeval+0x1ee) [0x519aee]
/usr/local/bin/ruby() [0x569a08]
/usr/local/bin/ruby(rb
requiresafe+0x647) [0x56ae77]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x5168c1]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rb
iseqeval+0x1ee) [0x519aee]
/usr/local/bin/ruby() [0x569a08]
/usr/local/bin/ruby(rb
requiresafe+0x647) [0x56ae77]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x515546]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rb
iseqeval+0x1ee) [0x519aee]
/usr/local/bin/ruby() [0x569a08]
/usr/local/bin/ruby() [0x569b6b]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x515546]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rb
yield+0x66) [0x521d56]
/usr/local/bin/ruby() [0x53ac15]
/usr/local/bin/ruby() [0x51307f]
/usr/local/bin/ruby() [0x515546]
/usr/local/bin/ruby() [0x519499]
/usr/local/bin/ruby(rbvminvokeproc+0x9f) [0x51c38f]
/usr/local/bin/ruby(rb
execendproc+0x238) [0x41c5b8]
/usr/local/bin/ruby() [0x41c684]
/usr/local/bin/ruby(rubycleanup+0x12d) [0x41c7fd]
/usr/local/bin/ruby(ruby
runnode+0x3d) [0x41cb0d]
/usr/local/bin/ruby(main+0x49) [0x419c49]
/lib/libc.so.6(
libcstart_main+0xfd) [0x7fa52325cc4d]
/usr/local/bin/ruby() [0x419b39]

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

Aborted

I've attached the minimal rails test app I could get to fail below.

segfault.zip - Rails app that segfaults when running specs (33.6 KB) Jack Christensen, 07/19/2011 03:47 AM

5047.patch Magnifier (8.27 KB) Yusuke Endoh, 07/24/2011 09:09 PM

Associated revisions

Revision 32669
Added by Yusuke Endoh over 2 years ago

  • proc.c (struct METHOD), gc.c (gcmarks), vmmethod.c (rbgcmarkunlinkedlivemethodentries): fix SEGV bug. rbmethodentryt was free'd even when the method is still on the stack if it is BMETHOD (i.e., Method#call). This is because rbmethodentryt is embedded in struct METHOD. This commit separates them and marks the live method entries. See in detail. fix [Bug #5047]

History

#1 Updated by Hiroshi Nakamura almost 3 years ago

  • Category set to core
  • Status changed from Open to Assigned
  • Assignee set to Hiroshi Nakamura
  • Target version set to 1.9.2

Confirmed the SEGV on my machine. I'll investigate it.

#2 Updated by Hiroshi Nakamura almost 3 years ago

  • Target version changed from 1.9.2 to 1.9.3

I get SEGV with ruby 1.9.3dev (2011-07-21 revision 32592) [x86_64-linux] as well. Still investigating.

Note: Don't forget to backport when we fixes it.

#3 Updated by Motohiro KOSAKI almost 3 years ago

  • Priority changed from Normal to High

#4 Updated by Hiroshi Nakamura almost 3 years ago

Can someone enlighten me to find the bug?

Here's a way to replicate the bug. 4 steps. I'm on Ubuntu 11.04 64bit.

1. extract the attached app

% unzip segfault.zip
% cd segfault

2. install bundler via rubygems

% gem install bundler --user-install
% export PATH=$PATH:/home/nahi/.gem/ruby/1.9.1/bin

3. run bundle to install gems to ./ruby

% bundle install --path=.

4. execute it

% ruby -rbundler -e 'Bundler.setup; require "rspec/core"; RSpec::Core::Runner.run(["spec"], $stderr, $stdout)'

And here's my gdb session.

% gdb /usr/local/bin/ruby
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/bin/ruby...done.
(gdb) run -rbundler -e 'Bundler.setup; require "rspec/core"; RSpec::Core::Runner.run(["spec"], $stderr, $stdout)'
Starting program: /usr/local/bin/ruby -rbundler -e 'Bundler.setup; require "rspec/core"; RSpec::Core::Runner.run(["spec"], $stderr, $stdout)'
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff6682700 (LWP 13255)]
[Thread 0x7ffff6682700 (LWP 13255) exited]
[New Thread 0x7ffff6682700 (LWP 13257)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ab5c99 in stforeach (table=0x28b5020, func=0x7ffff7a0c230 <markentry>, arg=140737488315296) at ../st.c:745
745 key = (stdatat)table->bins[i*2];
(gdb) where
#0 0x00007ffff7ab5c99 in stforeach (table=0x28b5020, func=0x7ffff7a0c230 <markentry>, arg=140737488315296) at ../st.c:745
#1 0x00007ffff7a0be88 in marktbl (objspace=0x6038a0, ptr=19563040, lev=5) at ../gc.c:1445
#2 gc
markchildren (objspace=0x6038a0, ptr=19563040, lev=5) at ../gc.c:1801
#3 0x00007ffff7a0b8d8 in gc
markchildren (objspace=0x6038a0, ptr=35333200, lev=4) at ../gc.c:1795
#4 0x00007ffff7a0b8d8 in gc
markchildren (objspace=0x6038a0, ptr=35333280, lev=3) at ../gc.c:1795
#5 0x00007ffff7a0c1d6 in mark
constentryi (key=, ce=, data=)
at ../gc.c:1562
#6 0x00007ffff7ab5d1c in stforeach (table=0x19131a0, func=0x7ffff7a0c1c0 <markconstentryi>, arg=140737488315616)
at ../st.c:787
#7 0x00007ffff7a0bead in markconsttbl (objspace=0x6038a0, ptr=10364280, lev=2) at ../gc.c:1573
#8 gcmarkchildren (objspace=0x6038a0, ptr=10364280, lev=2) at ../gc.c:1802
#9 0x00007ffff7a0bb7e in gcmarkchildren (objspace=0x6038a0, ptr=27521040, lev=1) at ../gc.c:1688
#10 0x00007ffff7b02bb5 in iseqmark (ptr=0x2398250) at ../iseq.c:106
#11 0x00007ffff7a0baba in gc
markchildren (objspace=0x6038a0, ptr=30252840, lev=3) at ../gc.c:1839
#12 0x00007ffff7a0c2c8 in mark
methodentry (key=, me=, data=)
at ../gc.c:1506
#13 mark
methodentryi (key=, me=, data=) at ../gc.c:1530
#14 0x00007ffff7ab5d1c in stforeach (table=0x23d4f70, func=0x7ffff7a0c270 <markmethodentryi>, arg=140737488315968)
at ../st.c:787
#15 0x00007ffff7a0be59 in markmtbl (objspace=0x6038a0, ptr=21024760, lev=2) at ../gc.c:1541
#16 gcmarkchildren (objspace=0x6038a0, ptr=21024760, lev=2) at ../gc.c:1800
#17 0x00007ffff7a0b8d8 in gcmarkchildren (objspace=0x6038a0, ptr=41607400, lev=1) at ../gc.c:1795
#18 0x00007ffff7a0df82 in marklocationsarray (start=, end=) at ../gc.c:1401
#19 gcmarklocations (start=, end=) at ../gc.c:1414
#20 rbgcmarklocations (start=, end=) at ../gc.c:1420
#21 0x00007ffff7b0768e in env
mark (ptr=0x2bfda70) at ../vm.c:238
#22 0x00007ffff7a0baba in gcmarkchildren (objspace=0x6038a0, ptr=41607040, lev=1) at ../gc.c:1839
#23 0x00007ffff7a0df82 in marklocationsarray (start=, end=) at ../gc.c:1401
#24 gcmarklocations (start=, end=) at ../gc.c:1414
#25 rbgcmarklocations (start=, end=) at ../gc.c:1420
#26 0x00007ffff7b0768e in env
mark (ptr=0x2562950) at ../vm.c:238
#27 0x00007ffff7a0baba in gcmarkchildren (objspace=0x6038a0, ptr=41607000, lev=1) at ../gc.c:1839
#28 0x00007ffff79fc9d5 in procmark (ptr=0x277bf80) at ../proc.c:53
#29 0x00007ffff7a0baba in gc
markchildren (objspace=0x6038a0, ptr=41606920, lev=2) at ../gc.c:1839
#30 0x00007ffff7a0c2fc in mark
methodentry (key=, me=, data=)
at ../gc.c:1509
#31 mark
methodentryi (key=, me=, data=) at ../gc.c:1530
#32 0x00007ffff7ab5d1c in stforeach (table=0x25b2070, func=0x7ffff7a0c270 <markmethodentryi>, arg=140737488316608)
at ../st.c:787
#33 0x00007ffff7a0be59 in markmtbl (objspace=0x6038a0, ptr=33366880, lev=1) at ../gc.c:1541
#34 gcmarkchildren (objspace=0x6038a0, ptr=33366880, lev=1) at ../gc.c:1800
#35 0x00007ffff7b02ba5 in iseqmark (ptr=0x27528f0) at ../iseq.c:107
#36 0x00007ffff7a0baba in gc
markchildren (objspace=0x6038a0, ptr=33147080, lev=2) at ../gc.c:1839
#37 0x00007ffff7a0be2b in gc
markchildren (objspace=0x6038a0, ptr=, lev=1) at ../gc.c:1815
#38 0x00007ffff7b02bf5 in iseq
mark (ptr=0x27520f0) at ../iseq.c:102
#39 0x00007ffff7a0baba in gcmarkchildren (objspace=0x6038a0, ptr=33147560, lev=2) at ../gc.c:1839
#40 0x00007ffff7a0be2b in gcmarkchildren (objspace=0x6038a0, ptr=, lev=1) at ../gc.c:1815
#41 0x00007ffff7b02bf5 in iseqmark (ptr=0x2751db0) at ../iseq.c:102
#42 0x00007ffff7a0baba in gc
markchildren (objspace=0x6038a0, ptr=33148280, lev=5) at ../gc.c:1839
#43 0x00007ffff7a0c2c8 in mark
methodentry (key=, me=, data=)
at ../gc.c:1506
#44 mark
methodentryi (key=, me=, data=) at ../gc.c:1530
#45 0x00007ffff7ab5d1c in stforeach (table=0x27e52d0, func=0x7ffff7a0c270 <markmethodentryi>, arg=140737488317232)
---Type to continue, or q to quit---quit
at ../st.Quit
(gdb) up 2
#2 gcmarkchildren (objspace=0x6038a0, ptr=19563040, lev=5) at ../gc.c:1801
1801 marktbl(objspace, RCLASSIVTBL(obj), lev);
(gdb) p *obj
$1 = {as = {free = {flags = 4130, next = 0x665b20}, basic = {flags = 4130, klass = 6708000}, object = {basic = {flags = 4130,
klass = 6708000}, as = {heap = {numiv = 42751520, ivptr = 0x2af3720, iv
indextbl = 0x0}, ary = {42751520, 45037344,
0}}}, klass = {basic = {flags = 4130, klass = 6708000}, ptr = 0x28c5620, m
tbl = 0x2af3720, ivindextbl = 0x0},
flonum = {basic = {flags = 4130, klass = 6708000}, floatvalue = 2.1122057339494968e-316}, string = {basic = {
flags = 4130, klass = 6708000}, as = {heap = {len = 42751520, ptr = 0x2af3720 "\340\263\333\367\377\177", aux = {
capa = 0, shared = 0}}, ary = " V\214\002\000\000\000\000 7\257\002", '\000' }}, array = {
basic = {flags = 4130, klass = 6708000}, as = {heap = {len = 42751520, aux = {capa = 45037344, shared = 45037344},
ptr = 0x0}, ary = {42751520, 45037344, 0}}}, regexp = {basic = {flags = 4130, klass = 6708000}, ptr = 0x28c5620,
src = 45037344, usecnt = 0}, hash = {basic = {flags = 4130, klass = 6708000}, ntbl = 0x28c5620, iter
lev = 45037344,
ifnone = 0}, data = {basic = {flags = 4130, klass = 6708000}, dmark = 0x28c5620, dfree = 0x2af3720, data = 0x0},
typeddata = {basic = {flags = 4130, klass = 6708000}, type = 0x28c5620, typedflag = 45037344, data = 0x0}, rstruct = {
basic = {flags = 4130, klass = 6708000}, as = {heap = {len = 42751520, ptr = 0x2af3720}, ary = {42751520, 45037344,
0}}}, bignum = {basic = {flags = 4130, klass = 6708000}, as = {heap = {len = 42751520, digits = 0x2af3720}, ary = {
42751520, 0, 45037344, 0, 0, 0}}}, file = {basic = {flags = 4130, klass = 6708000}, fptr = 0x28c5620}, node = {
flags = 4130, nd
reserved = 6708000, u1 = {node = 0x28c5620, id = 42751520, value = 42751520, cfunc = 0x28c5620,
tbl = 0x28c5620}, u2 = {node = 0x2af3720, id = 45037344, argc = 45037344, value = 45037344}, u3 = {node = 0x0, id = 0,
state = 0, entry = 0x0, cnt = 0, value = 0}}, match = {basic = {flags = 4130, klass = 6708000}, str = 42751520,
rmatch = 0x2af3720, regexp = 0}, rational = {basic = {flags = 4130, klass = 6708000}, num = 42751520, den = 45037344},
complex = {basic = {flags = 4130, klass = 6708000}, real = 42751520, imag = 45037344}}}
(gdb) p 4130 & 0x1f
$2 = 2
(gdb) p obj.as.klass
$3 = {basic = {flags = 4130, klass = 6708000}, ptr = 0x28c5620, mtbl = 0x2af3720, ivindextbl = 0x0}
(gdb) p obj.as.klass.m
tbl
$4 = (struct sttable *) 0x2af3720
(gdb) p *obj.as.klass.m
tbl
$5 = {type = 0x7ffff7dbb3e0, numbins = 11, entriespacked = 1, numentries = 0, bins = 0x28c1730, head = 0x0, tail = 0x0}
(gdb) p obj.as.klass.m
tbl.bins[0]
$6 = (struct sttableentry *) 0x0

(gdb)

#5 Updated by Eric Wong almost 3 years ago

Hiroshi Nakamura nakahiro@gmail.com wrote:

Can someone enlighten me to find the bug?

I started looking into this, too, but haven't found the exact
cause/solution, either.

It does not seem to be in the tinytds nor bcrypt C extensions,
I put in early returns for each extensions' Init_* functions
to avoid hitting C code outside of Ruby trunk.

It seems to be related to how the parser/loader sets up (or fails to set
up) objects for GC. Some backtraces I get are very deep inside gc_mark*
functions (500-700+ C stack frames).

I cannot reproduce this with GC.disable or a huge malloc limit
(RUBYGCMALLOC_LIMIT=800000000).

#6 Updated by Eric Hodel almost 3 years ago

  • ruby -v changed from ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux] to -

On Jul 22, 2011, at 2:41 PM, Eric Wong wrote:

Hiroshi Nakamura nakahiro@gmail.com wrote:

Can someone enlighten me to find the bug?

I started looking into this, too, but haven't found the exact
cause/solution, either.

It does not seem to be in the tinytds nor bcrypt C extensions,
I put in early returns for each extensions' Init_* functions
to avoid hitting C code outside of Ruby trunk.

It seems to be related to how the parser/loader sets up (or fails to set
up) objects for GC. Some backtraces I get are very deep inside gc_mark*
functions (500-700+ C stack frames).

I cannot reproduce this with GC.disable or a huge malloc limit
(RUBYGCMALLOC_LIMIT=800000000).

Does GC.stress help?

#7 Updated by Eric Wong almost 3 years ago

Eric Hodel drbrain@segment7.net wrote:

Does GC.stress help?

I tried it for a while but lost patience while waiting. I suppose
I'll try it again while I poke at other things...

--
Eric Wong

#8 Updated by Hiroshi Nakamura almost 3 years ago

On Sat, Jul 23, 2011 at 07:56, Eric Wong normalperson@yhbt.net wrote:

Does GC.stress help?

I tried it for a while but lost patience while waiting.  I suppose
I'll try it again while I poke at other things...

Yeah, I waited 2 hours before I quit the way. :-(

Adding rb_gc() to several part at load.c but I still cannot narrow
down where the broken object created...

Regards,
// NaHi

#9 Updated by Hiroshi Nakamura almost 3 years ago

Random note;
* SEGV on trunk, ruby193 and 1.9.2-p280
* SEGV on x86
64-linux but NOT on x8664-darwin10.8.0 according to @nagachika
* SEGV at GC mark or sweep, and the broken object looks like a singleton class object
* SEGV caused at autoload from autoload from autoload... or at finalizing VM at exit.
* slight change of code, different location of SEGV.
* lack of RB
GC_GUARD for a Node which is used in particular code?

#10 Updated by Yusuke Endoh almost 3 years ago

Hello,

Thank you for the reproducing process. I could also comfirmed it.
This is one of the most difficult bug that I have seen...

In short, I've not solved this issue, but I found valgrind with -O0
enlightens us the (maybe) important point:

#11 Updated by Yusuke Endoh almost 3 years ago

Follow-up.

I found activesupport uses UnboundMethod and #bind to check whether
a class instance is singleton or not.

102 def singletonclass?
103 # in case somebody is crazy enough to overwrite allocate
104 allocate = Class.instance
method(:allocate)
105 # object.class always points to a real (non-singleton) class
106 allocate.bind(self).call.class != self
107 rescue TypeError
108 # MRI/YARV/JRuby all disallow creating new instances of a
singleton class
109 true
110 end

Of course, this is not a fault of activesupport, but this seems
one factor to this SEGV.
If you need to work around this issue right now, the following patch
for activesupport might work.

$ diff -u activesupport/coreext/class/attribute.rb.orig
activesupport/coreext/class/attribute.rb
--- activesupport/coreext/class/attribute.rb.orig 2011-07-24
11:51:32.690364370 +0900
+++ activesupport/coreext/class/attribute.rb 2011-07-24
11:51:35.990380754 +0900
@@ -100,6 +100,7 @@

private
def singleton_class?
  • return !ancestors.include?(self)
    # in case somebody is crazy enough to overwrite allocate
    allocate = Class.instance_method(:allocate)
    # object.class always points to a real (non-singleton) class

    At least, SEGV does not occur with this patch on my machine.
    Could anyone please try it?

    Again, this is not a fault of activesupport. This is just workaround
    patch.

    Yusuke Endoh mame@tsg.ne.jp

#12 Updated by Yusuke Endoh almost 3 years ago

2011/7/24 Yusuke ENDOH mame@tsg.ne.jp:

If you need to work around this issue right now, the following patch
for activesupport might work.

FYI, Aaron fixed activesupport in trunk so quickly :-)

https://github.com/rails/rails/commit/cdc4274931c2d6bafdf2b97f7e4ecedf89a8202e

--
Yusuke Endoh mame@tsg.ne.jp

#13 Updated by Yusuke Endoh almost 3 years ago

  • File 5047.patchMagnifier added
  • Assignee changed from Hiroshi Nakamura to Koichi Sasada

I probably managed to fix this issue.
Could anyone try the attached patch?
ko1: May I commit it?

This problem is caused by the combination of the wrong design
of Method class and lack of YARV method entry marking, with
obfuscated by conservative GC and Fiber's machine stack...

Each method has struct rbmethodentryt. The struct is free'd
when its method is removed, except the method is "live" (i.e.,
method being now executed).
To prevent live rb
methodentryt from being free'd, YARV
traverses the YARV stack and marks each live rbmethodentryt
at GC marking phase.
However, when the method is BMETHOD (i.e., Method#call), the
system does not work correctly because rb
methodentryt is
embedded in the internal structure of Method class (i.e.,
struct METHOD). The rbmethodentry_t is free'd when the Method
object is GC'd, even if the YARV attempts to prevent it.

My patch separates rbmethodentry_t from struct METHOD,

struct METHOD {
VALUE recv;
VALUE rclass;
ID id;
- rbmethodentryt me;
+ rb
methodentryt *me;
};

and marks them explicitly at each marking phase.

I tried to create a small test for this issue, but didn't
succeeded because of conservative GC.

The following is Japanese translation.

拙い英語で書いただけだと後でわからなくなる自信があるので日本語でも
簡単に。

要は、struct METHOD 中の rbmethodentryt をポインタにするパッチ
です。
rb
methodentryt は YARV スタックに載っている限りは free しちゃ
ダメなんですが、struct METHOD に埋めこまれた状態だと、Method オブ
ジェクトが解放された時にあわせて free されてしまって、でもスタック
には乗ってるので解放領域を mark とかしてメモリが破壊されているので
した。
rbmethodentry_t をポインタに切り分けて別途 malloc するようにし
たら直った気がします。

小さい例も作りたかったんですが、conservative GC がなかなか Method
を解放してくれず、作れませんでした。

rbmethodentry_t を作ったのはささださんなので、一応ささださんに
確認して欲しいです。

Yusuke Endoh mame@tsg.ne.jp

#14 Updated by Eric Wong almost 3 years ago

Yusuke Endoh mame@tsg.ne.jp wrote:

I probably managed to fix this issue.
Could anyone try the attached patch?

Seems to work for me.

Explanation is good and makes sense to me. Thanks!

sidenote: I didn't realize xmalloc() (via rbunlinkmethodentry) is
safe/allowed inside bm
free(); but apparently it's only rbnewobj()
that's prevented inside GC.

--
Eric Wong

#15 Updated by Hiroshi Nakamura almost 3 years ago

Yusuke Endoh wrote:

I probably managed to fix this issue.
Could anyone try the attached patch?
ko1: May I commit it?

With the patch, both trunk and ruby19_3 run without SEGV. My hat's off to you for your exhausting job.

#16 Updated by Koichi Sasada almost 3 years ago

(2011/07/25 6:35), Hiroshi Nakamura wrote:

With the patch, both trunk and ruby19_3 run without SEGV. My hat's off to you for your exhausting job.

Me too. Thanks a lot.

--
// SASADA Koichi at atdot dot net

#17 Updated by Motohiro KOSAKI almost 3 years ago

With the patch, both trunk and ruby19_3 run without SEGV. My hat's off to you for your exhausting job.

Me too. Thanks a lot.

Me too. You are great.

Offtopic: now 1.9.3 have two high priority (i.e. crash related) bug, #5039 and this. And this was
most mysterious and difficult one. Now I don't doubt 1.9.3 is going to be released on a planned schedule.
Of course, there still are several normal priority bugs. we'll do our best.

#18 Updated by Yusuke Endoh over 2 years ago

Thank you for the trying the patch.
Nobu pointed out that the patch may cause memory leak.
I'll commit a revised version soon.

2011/7/25 Eric Wong normalperson@yhbt.net:

sidenote: I didn't realize xmalloc() (via rbunlinkmethodentry) is
safe/allowed inside bm
free(); but apparently it's only rbnewobj()
that's prevented inside GC.

Good point. I was not aware of this.
Indeed, GC does not occur recursively even if vmxmalloc is called
during GC. But NoMemoryError may be raised from bm
free()... It
will probably make the interpreter state inconsistent, so I guess
it is not possible to sanely continue the execution by rescue'ing
the exception.
But I have no solution about the case. Frankly speaking, I think
we can do nothing if just few dozens byte allocation is failed.

2011/7/25 Motohiro KOSAKI kosaki.motohiro@gmail.com:

With the patch, both trunk and ruby19_3 run without SEGV. My hat's off to you for your exhausting job.

Me too. Thanks a lot.

Me too. You are great.

Thanks for the compliment!

--
Yusuke Endoh mame@tsg.ne.jp

#19 Updated by Eric Wong over 2 years ago

Yusuke ENDOH mame@tsg.ne.jp wrote:

2011/7/25 Eric Wong normalperson@yhbt.net:

sidenote: I didn't realize xmalloc() (via rbunlinkmethodentry) is
safe/allowed inside bm
free(); but apparently it's only rbnewobj()
that's prevented inside GC.

Good point. I was not aware of this.
Indeed, GC does not occur recursively even if vmxmalloc is called
during GC. But NoMemoryError may be raised from bm
free()... It
will probably make the interpreter state inconsistent, so I guess
it is not possible to sanely continue the execution by rescue'ing
the exception.
But I have no solution about the case. Frankly speaking, I think
we can do nothing if just few dozens byte allocation is failed.

We can pre-allocate the unlinkedmethodentrylistentry struct
in the METHOD struct and then push it into unlinkedmethodentrylist
in bm
free (untested patch below):

--- a/proc.c
+++ b/proc.c
@@ -19,6 +19,7 @@ struct METHOD {
VALUE rclass;
ID id;
rbmethodentryt *me;
+ struct unlinked
methodentrylist_entry *ume;
};

VALUE rbcUnboundMethod;
@@ -868,7 +869,11 @@ static void
bm
free(void *ptr)
{
struct METHOD *data = ptr;
- rbunlinkmethodentry(data->me);
+ struct unlinked
methodentrylistentry *ume = data->ume;
+
+ ume->me = data->me;
+ ume->next = GET
VM()->unlinkedmethodentrylist;
+ GET
VM()->unlinkedmethodentry_list = ume;
xfree(ptr);
}

@@ -978,6 +983,7 @@ mnew(VALUE klass, VALUE obj, ID id, VALUE mclass, int scope)
data->me = me2;
*data->me = *me;
data->me->def->aliascount++;
+ data->ume = ALLOC(struct unlinked
methodentrylist_entry);

  OBJ_INFECT(method, klass);

@@ -1088,6 +1094,7 @@ methodunbind(VALUE obj)
*data->me = *orig->me;
if (orig->me->def) orig->me->def->alias
count++;
data->rclass = orig->rclass;
+ data->ume = ALLOC(struct unlinkedmethodentrylistentry);
OBJ_INFECT(method, obj);

  return method;

--
Eric Wong

#20 Updated by Yusuke Endoh over 2 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r32669.
Jack, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • proc.c (struct METHOD), gc.c (gcmarks), vmmethod.c (rbgcmarkunlinkedlivemethodentries): fix SEGV bug. rbmethodentryt was free'd even when the method is still on the stack if it is BMETHOD (i.e., Method#call). This is because rbmethodentryt is embedded in struct METHOD. This commit separates them and marks the live method entries. See in detail. fix [Bug #5047]

#21 Updated by Yusuke Endoh over 2 years ago

2011/7/25 Eric Wong normalperson@yhbt.net:

We can pre-allocate the unlinkedmethodentrylistentry struct
in the METHOD struct and then push it into unlinkedmethodentrylist
in bm
free (untested patch below):

I see! I'll import it if make check passes. Thanks.

--
Yusuke Endoh mame@tsg.ne.jp

Also available in: Atom PDF