Project

General

Profile

Actions

Bug #11930

closed

Segmentation Fault in gc_mark_ptr in 2.3.0p0

Added by b264 (Brian Giaraffa) about 8 years ago. Updated over 4 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]
[ruby-core:72623]

Description

/home/devbox/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.5/lib/active_support/core_ext/module/attribute_accessors.rb:208: [BUG] Segmentation fault at 0x00000000000000
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]


Files

ruby_exception.txt (158 KB) ruby_exception.txt Segmentation fault at 0x00000000000000 b264 (Brian Giaraffa), 12/30/2015 07:52 PM
ruby_2016-01-05-141309_galaxy.crash (48.5 KB) ruby_2016-01-05-141309_galaxy.crash felixbuenemann (Felix Bünemann), 01/05/2016 01:48 PM

Updated by b264 (Brian Giaraffa) about 8 years ago

Brian Giaraffa wrote:

/home/devbox/.rvm/gems/ruby-2.3.0/gems/activesupport-4.2.5/lib/active_support/core_ext/module/attribute_accessors.rb:208: [BUG] Segmentation fault at 0x00000000000000
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]

I have discovered more information--
This problem is occurring in a Rails application and if you attempt to start Sidekiq it will happen again.

Updated by b264 (Brian Giaraffa) about 8 years ago

devbox@devbox:~/code/project_name$ sidekiq
/home/devbox/.rvm/gems/ruby-2.3.0/gems/loofah-2.0.3/lib/loofah.rb:12: [BUG] Segmentation fault at 0x00000000000000
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0044 p:---- s:0127 e:000126 CFUNC :require
c:0043 p:0121 s:0123 e:000122 TOP /home/devbox/.rvm/gems/ruby-2.3.0/gems/loofah-2.0.3/lib/loofah.rb:12 [FINISH]
c:0042 p:---- s:0121 e:000120 CFUNC :require
c:0041 p:0017 s:0117 e:000116 TOP /home/devbox/.rvm/gems/ruby-2.3.0/gems/rails-html-sanitizer-1.0.2/lib/rails-html-sanitizer.rb:2 [FINISH]
c:0040 p:---- s:0115 e:000114 CFUNC :require
c:0039 p:0026 s:0111 e:000110 TOP /home/devbox/.rvm/gems/ruby-2.3.0/gems/actionview-4.2.5/lib/action_view/helpers/sanitize_helper.rb:3 [FINISH]
c:0038 p:---- s:0109 e:000108 CFUNC :require
c:0037 p:0026 s:0107 e:000105 CLASS /home/devbox/.rvm/gems/ruby-2.3.0/gems/actionview-4.2.5/lib/action_view/helpers/text_helper.rb:32

Updated by nobu (Nobuyoshi Nakada) about 8 years ago

  • Status changed from Open to Feedback

Seems a GC problem with Proc.

-- C level backtrace information -------------------------------------------
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(rb_vm_bugreport+0x51f) [0x7fe25c8c6b7f] vm_dump.c:688
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(rb_bug_context+0xd0) [0x7fe25c750320] error.c:435
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(sigsegv+0x3e) [0x7fe25c82f7ee] signal.c:890
/lib/x86_64-linux-gnu/libc.so.6 [0x7fe25c341d40]
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(gc_mark_ptr+0x62) [0x7fe25c773cd2] gc.c:1067
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(proc_mark+0x68) [0x7fe25c75dd68] 

If you can reproduce it with a debugger, could you show the content of *proc in this proc_mark frame?

Updated by b264 (Brian Giaraffa) about 8 years ago

devbox@devbox:~/code/project_name$ gdb --args /usr/bin/env ruby_executable_hooks /home/devbox/.rvm/gems/ruby-2.3.0/bin/sidekiq
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/env...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/env ruby_executable_hooks /home/devbox/.rvm/gems/ruby-2.3.0/bin/sidekiq
process 9095 is executing new program: /usr/bin/env
process 9095 is executing new program: /home/devbox/.rvm/rubies/ruby-2.3.0/bin/ruby
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff5700 (LWP 9099)]
[New Thread 0x7ffff1fb1700 (LWP 9100)]
[New Thread 0x7ffff1d2f700 (LWP 9101)]
[New Thread 0x7ffff19eb700 (LWP 9102)]
[New Thread 0x7ffff1606700 (LWP 9103)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7986cd2 in RVALUE_MARKED (obj=2318347108263927840) at gc.c:1067
1067	gc.c: No such file or directory.
(gdb) up
#1  gc_mark_set (objspace=0x603a00, obj=2318347108263927840) at gc.c:4162
4162	in gc.c
(gdb) up
#2  gc_mark_ptr (objspace=0x603a00, obj=2318347108263927840) at gc.c:4284
4284	in gc.c
(gdb) up
#3  0x00007ffff79871fd in gc_mark (obj=<optimized out>, objspace=<optimized out>) at gc.c:4297
4297	in gc.c
(gdb) up
#4  rb_gc_mark (ptr=<optimized out>) at gc.c:4303
4303	in gc.c
(gdb) up
#5  0x00007ffff7970d68 in proc_mark (ptr=0x15c5f20) at proc.c:55
55	proc.c: No such file or directory.
(gdb) p *proc
$1 = {block = {self = 0, ep = 0x16ef9b0, iseq = 0xd010c, proc = 17195200}, safe_level = 0 '\000', is_from_method = 0 '\000', is_lambda = 0 '\000'}
(gdb) 

Updated by felixbuenemann (Felix Bünemann) about 8 years ago

I think I'm getting the same crash in gc_mark_ptr with ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15] when using the pg 0.18.4 gem and activerecord 4.2.4:

(lldb) target create "/Users/felix/.rvm/rubies/ruby-2.3.0/bin/ruby"
Current executable set to '/Users/felix/.rvm/rubies/ruby-2.3.0/bin/ruby' (x86_64).
(lldb) settings set -- target.run-args  "bin/rake" "export:csv"
(lldb) r
Process 83586 launched: '/Users/felix/.rvm/rubies/ruby-2.3.0/bin/ruby' (x86_64)
Exporting data...
Process 83586 stopped Event: create_hist_info Processed: 0 / 8727   0% |                                                                                             |  ETA: ??:??:??
* thread #1: tid = 0x1a0148, 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077
   1074	RVALUE_MARKED(VALUE obj)
   1075	{
   1076	    check_rvalue_consistency(obj);
-> 1077	    return RVALUE_MARK_BITMAP(obj) != 0;
   1078	}
   1079
   1080	#if USE_RGENGC
(lldb) bt
* thread #1: tid = 0x1a0148, 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077
    frame #1: 0x00000001000700b8 libruby.2.3.0.dylib`gc_mark_ptr [inlined] gc_mark_set at gc.c:4172
    frame #2: 0x00000001000700b8 libruby.2.3.0.dylib`gc_mark_ptr(objspace=0x0000000101800000, obj=1125899906842624) + 40 at gc.c:4294
    frame #3: 0x000000010005706b libruby.2.3.0.dylib`proc_mark(ptr=0x00000001052b0800) + 75 at proc.c:55
    frame #4: 0x000000010006d7d1 libruby.2.3.0.dylib`gc_start + 567 at gc.c:5635
    frame #5: 0x000000010006d59a libruby.2.3.0.dylib`gc_start [inlined] gc_marks_start(objspace=0x0000000101800000) + 464 at gc.c:5210
    frame #6: 0x000000010006d3ca libruby.2.3.0.dylib`gc_start [inlined] gc_marks(full_mark=<unavailable>) + 102 at gc.c:5465
    frame #7: 0x000000010006d364 libruby.2.3.0.dylib`gc_start(objspace=0x0000000101800000, full_mark=<unavailable>, immediate_mark=<unavailable>, immediate_sweep=<unavailable>, reason=<unavailable>) + 1268 at gc.c:6401
    frame #8: 0x000000010006cd44 libruby.2.3.0.dylib`newobj_slowpath [inlined] heap_prepare(objspace=0x0000000101800000, heap=<unavailable>) + 1004 at gc.c:1643
    frame #9: 0x000000010006c958 libruby.2.3.0.dylib`newobj_slowpath [inlined] heap_get_freeobj_from_next_freepage(heap=0x0000000101800028) at gc.c:1655
    frame #10: 0x000000010006c958 libruby.2.3.0.dylib`newobj_slowpath [inlined] heap_get_freeobj(objspace=0x0000000101800000, heap=0x0000000101800028) + 21 at gc.c:1689
    frame #11: 0x000000010006c943 libruby.2.3.0.dylib`newobj_slowpath(klass=4312187040, flags=5, v1=0, v2=0, v3=0, objspace=0x0000000101800000, wb_protected=<unavailable>) + 195 at gc.c:1818
    frame #12: 0x000000010006c854 libruby.2.3.0.dylib`newobj_slowpath_wb_protected(klass=<unavailable>, flags=<unavailable>, v1=<unavailable>, v2=<unavailable>, v3=<unavailable>, objspace=<unavailable>) + 20 at gc.c:1830
    frame #13: 0x000000010012519e libruby.2.3.0.dylib`str_new0 [inlined] str_alloc(klass=4312187040) + 8 at string.c:629
    frame #14: 0x0000000100125196 libruby.2.3.0.dylib`str_new0(klass=4312187040, ptr="-", len=1, termlen=1) + 54 at string.c:651
    frame #15: 0x0000000100125661 libruby.2.3.0.dylib`rb_tainted_str_new [inlined] str_new(klass=<unavailable>, ptr=<unavailable>, len=<unavailable>) + 33 at string.c:671
    frame #16: 0x0000000100125656 libruby.2.3.0.dylib`rb_tainted_str_new [inlined] rb_str_new(ptr=<unavailable>, len=<unavailable>) + 12 at string.c:677
    frame #17: 0x000000010012564a libruby.2.3.0.dylib`rb_tainted_str_new(ptr=<unavailable>, len=<unavailable>) + 10 at string.c:793
    frame #18: 0x0000000102aabe48 pg_ext.bundle`pg_text_dec_string(conv=<unavailable>, val=<unavailable>, len=<unavailable>, tuple=<unavailable>, field=<unavailable>, enc_idx=1) + 24 at pg_text_decoder.c:68
    frame #19: 0x0000000102aab461 pg_ext.bundle`pgresult_values(self=4368468480) + 209 at pg_result.c:899
    frame #20: 0x00000001001984a0 libruby.2.3.0.dylib`vm_call_cfunc [inlined] vm_call_cfunc_with_frame + 220 at vm_insnhelper.c:1638
    frame #21: 0x00000001001983c4 libruby.2.3.0.dylib`vm_call_cfunc(th=0x0000000100700000, reg_cfp=0x00000001019ff680, calling=<unavailable>, ci=<unavailable>, cc=<unavailable>) + 84 at vm_insnhelper.c:1733
    frame #22: 0x0000000100181d25 libruby.2.3.0.dylib`vm_exec_core(th=0x0000000100700000, initial=<unavailable>) + 11317 at insns.def:995
    frame #23: 0x0000000100192ed9 libruby.2.3.0.dylib`vm_exec(th=0x0000000100700000) + 121 at vm.c:1645
    frame #24: 0x000000010018e3a7 libruby.2.3.0.dylib`rb_yield [inlined] invoke_block_from_c_splattable(th=<unavailable>, block=<unavailable>, self=<unavailable>, argc=0, argv=<unavailable>, blockptr=<unavailable>, cref=<unavailable>) + 183 at vm.c:983
    frame #25: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] vm_yield(th=<unavailable>, argc=0) at vm.c:1018
    frame #26: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] rb_yield_0(argc=0) at vm_eval.c:1008
    frame #27: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield(val=<unavailable>) + 178 at vm_eval.c:1021
    frame #28: 0x0000000100006719 libruby.2.3.0.dylib`rb_ary_each(ary=4365752440) + 41 at array.c:1815
    frame #29: 0x00000001001984a0 libruby.2.3.0.dylib`vm_call_cfunc [inlined] vm_call_cfunc_with_frame + 220 at vm_insnhelper.c:1638
    frame #30: 0x00000001001983c4 libruby.2.3.0.dylib`vm_call_cfunc(th=0x0000000100700000, reg_cfp=0x00000001019ffa40, calling=<unavailable>, ci=<unavailable>, cc=<unavailable>) + 84 at vm_insnhelper.c:1733
    frame #31: 0x0000000100181b35 libruby.2.3.0.dylib`vm_exec_core(th=0x0000000100700000, initial=<unavailable>) + 10821 at insns.def:964
    frame #32: 0x0000000100192ed9 libruby.2.3.0.dylib`vm_exec(th=0x0000000100700000) + 121 at vm.c:1645
    frame #33: 0x000000010018e3a7 libruby.2.3.0.dylib`rb_yield [inlined] invoke_block_from_c_splattable(th=<unavailable>, block=<unavailable>, self=<unavailable>, argc=0, argv=<unavailable>, blockptr=<unavailable>, cref=<unavailable>) + 183 at vm.c:983
    frame #34: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] vm_yield(th=<unavailable>, argc=0) at vm.c:1018
    frame #35: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] rb_yield_0(argc=0) at vm_eval.c:1008
    frame #36: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield(val=<unavailable>) + 178 at vm_eval.c:1021
    frame #37: 0x000000010004e957 libruby.2.3.0.dylib`rb_ensure(b_proc=(libruby.2.3.0.dylib`rb_yield at vm_eval.c:1019), data1=4345466400, e_proc=<unavailable>, data2=<unavailable>) + 167 at eval.c:898
    frame #38: 0x00000001001984a0 libruby.2.3.0.dylib`vm_call_cfunc [inlined] vm_call_cfunc_with_frame + 220 at vm_insnhelper.c:1638
    frame #39: 0x00000001001983c4 libruby.2.3.0.dylib`vm_call_cfunc(th=0x0000000100700000, reg_cfp=0x00000001019ffb40, calling=<unavailable>, ci=<unavailable>, cc=<unavailable>) + 84 at vm_insnhelper.c:1733
    frame #40: 0x0000000100181b35 libruby.2.3.0.dylib`vm_exec_core(th=0x0000000100700000, initial=<unavailable>) + 10821 at insns.def:964
    frame #41: 0x0000000100192ed9 libruby.2.3.0.dylib`vm_exec(th=0x0000000100700000) + 121 at vm.c:1645
    frame #42: 0x00000001001916f2 libruby.2.3.0.dylib`vm_invoke_proc [inlined] invoke_block_from_c_unsplattable + 194 at vm.c:991
    frame #43: 0x00000001001916c7 libruby.2.3.0.dylib`vm_invoke_proc(th=0x0000000100700000, proc=0x0000000105eea3b0, self=4312196640, argc=2, argv=0x00007fff5fbfe090, blockptr=0x0000000000000000) + 151 at vm.c:1039
    frame #44: 0x0000000100199664 libruby.2.3.0.dylib`vm_call_opt_call [inlined] rb_vm_invoke_proc(proc=<unavailable>, argv=<unavailable>, blockptr=<unavailable>) + 228 at vm.c:1067
    frame #45: 0x000000010019961c libruby.2.3.0.dylib`vm_call_opt_call(th=0x0000000100700000, cfp=<unavailable>, calling=<unavailable>, ci=<unavailable>, cc=<unavailable>) + 156 at vm_insnhelper.c:1864
    frame #46: 0x0000000100181d25 libruby.2.3.0.dylib`vm_exec_core(th=0x0000000100700000, initial=<unavailable>) + 11317 at insns.def:995
    frame #47: 0x0000000100192ed9 libruby.2.3.0.dylib`vm_exec(th=0x0000000100700000) + 121 at vm.c:1645
    frame #48: 0x000000010018e3a7 libruby.2.3.0.dylib`rb_yield [inlined] invoke_block_from_c_splattable(th=<unavailable>, block=<unavailable>, self=<unavailable>, argc=0, argv=<unavailable>, blockptr=<unavailable>, cref=<unavailable>) + 183 at vm.c:983
    frame #49: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] vm_yield(th=<unavailable>, argc=0) at vm.c:1018
    frame #50: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] rb_yield_0(argc=0) at vm_eval.c:1008
    frame #51: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield(val=<unavailable>) + 178 at vm_eval.c:1021
    frame #52: 0x0000000100006719 libruby.2.3.0.dylib`rb_ary_each(ary=4399107000) + 41 at array.c:1815
    frame #53: 0x00000001001984a0 libruby.2.3.0.dylib`vm_call_cfunc [inlined] vm_call_cfunc_with_frame + 220 at vm_insnhelper.c:1638
    frame #54: 0x00000001001983c4 libruby.2.3.0.dylib`vm_call_cfunc(th=0x0000000100700000, reg_cfp=0x00000001019ffc00, calling=<unavailable>, ci=<unavailable>, cc=<unavailable>) + 84 at vm_insnhelper.c:1733
    frame #55: 0x0000000100181b35 libruby.2.3.0.dylib`vm_exec_core(th=0x0000000100700000, initial=<unavailable>) + 10821 at insns.def:964
    frame #56: 0x0000000100192ed9 libruby.2.3.0.dylib`vm_exec(th=0x0000000100700000) + 121 at vm.c:1645
    frame #57: 0x000000010018e3a7 libruby.2.3.0.dylib`rb_yield [inlined] invoke_block_from_c_splattable(th=<unavailable>, block=<unavailable>, self=<unavailable>, argc=0, argv=<unavailable>, blockptr=<unavailable>, cref=<unavailable>) + 183 at vm.c:983
    frame #58: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] vm_yield(th=<unavailable>, argc=0) at vm.c:1018
    frame #59: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield [inlined] rb_yield_0(argc=0) at vm_eval.c:1008
    frame #60: 0x000000010018e3a2 libruby.2.3.0.dylib`rb_yield(val=<unavailable>) + 178 at vm_eval.c:1021
    frame #61: 0x0000000100006719 libruby.2.3.0.dylib`rb_ary_each(ary=4317407240) + 41 at array.c:1815
    frame #62: 0x00000001001984a0 libruby.2.3.0.dylib`vm_call_cfunc [inlined] vm_call_cfunc_with_frame + 220 at vm_insnhelper.c:1638
    frame #63: 0x00000001001983c4 libruby.2.3.0.dylib`vm_call_cfunc(th=0x0000000100700000, reg_cfp=0x00000001019ffe00, calling=<unavailable>, ci=<unavailable>, cc=<unavailable>) + 84 at vm_insnhelper.c:1733
    frame #64: 0x0000000100181b35 libruby.2.3.0.dylib`vm_exec_core(th=0x0000000100700000, initial=<unavailable>) + 10821 at insns.def:964
    frame #65: 0x0000000100192ed9 libruby.2.3.0.dylib`vm_exec(th=0x0000000100700000) + 121 at vm.c:1645
    frame #66: 0x000000010004d9e4 libruby.2.3.0.dylib`ruby_exec_internal(n=<unavailable>) + 148 at eval.c:244
    frame #67: 0x000000010004d8f6 libruby.2.3.0.dylib`ruby_run_node [inlined] ruby_exec_node(n=<unavailable>) + 54 at eval.c:309
    frame #68: 0x000000010004d8e8 libruby.2.3.0.dylib`ruby_run_node(n=<unavailable>) + 40 at eval.c:301
    frame #69: 0x0000000100000f1f ruby`main(argc=<unavailable>, argv=<unavailable>) + 79 at main.c:36
    frame #70: 0x00007fff8105c5ad libdyld.dylib`start + 1
    frame #71: 0x00007fff8105c5ad libdyld.dylib`start + 1
(lldb) register read
General Purpose Registers:
       rax = 0x0004000000000000
       rbx = 0x0000000101800000
       rcx = 0x0000000000000000
       rdx = 0x0000000000000000
       rdi = 0x0000000101800000
       rsi = 0x0004000000000000
       rbp = 0x00007fff5fbfc7b0
       rsp = 0x00007fff5fbfc7a0
        r8 = 0x0000000000838805
        r9 = 0x0000000000000010
       r10 = 0x0000000000000000
       r11 = 0x0000000000000000
       r12 = 0x0000000000000000
       r13 = 0x0000000000000001
       r14 = 0x0004000000000000
       r15 = 0x0000000101800000
       rip = 0x00000001000700e2  libruby.2.3.0.dylib`gc_mark_ptr + 82 [inlined] RVALUE_MARKED + 42 at gc.c:4172
  libruby.2.3.0.dylib`gc_mark_ptr + 40 [inlined] gc_mark_set at gc.c:4294
  libruby.2.3.0.dylib`gc_mark_ptr + 40 at gc.c:4294
    rflags = 0x0000000000010206
        cs = 0x000000000000002b
        fs = 0x0000000000000000
        gs = 0x0000000000000000

And more info from another crash (see attached crash log):

/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:168: [BUG] Segmentation fault at 0x00000000000000??
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15]

-- Control frame information -----------------------------------------------
c:0039 p:---- s:0177 e:000176 CFUNC  :values
c:0038 p:0044 s:0174 e:000171 BLOCK  /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.
c:0037 p:0042 s:0167 e:000166 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:590
c:0036 p:0023 s:0159 e:000158 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.
c:0035 p:0021 s:0153 e:000152 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb
c:0034 p:0044 s:0147 e:000146 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb
c:0033 p:0083 s:0141 e:000140 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:70
c:0032 p:0032 s:0134 e:000133 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/querying.rb:39
c:0031 p:0040 s:0125 e:000124 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation.rb:639
c:0030 p:0014 s:0120 e:000119 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation.rb:515
c:0029 p:0008 s:0117 e:000116 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation.rb:243
c:0028 p:0267 s:0114 e:000113 METHOD /Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation/batches.rb:128
[...]

-- Ruby level backtrace information ----------------------------------------
./bin/rake:4:in `<main>'
[...]
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation/batches.rb:128:in `find_in_batches'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation.rb:243:in `to_a'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation.rb:515:in `load'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/relation.rb:639:in `exec_queries'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/querying.rb:39:in `find_by_sql'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:70:in `select_all'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:32:in `select_all'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:351:in `select'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:160:in `exec_query'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql_adapter.rb:590:in `execute_and_clear'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:168:in `block in exec_query'
/Users/felix/.rvm/gems/ruby-2.3.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/postgresql/database_statements.rb:168:in `values'

-- Machine register context ------------------------------------------------
 rax: 0x0004000000000000 rbx: 0x00007fdcc9407000 rcx: 0x0000000000000000
 rdx: 0x0000000000000000 rdi: 0x00007fdcc9407000 rsi: 0x0004000000000000
 rbp: 0x00007fff5e5fc7d0 rsp: 0x00007fff5e5fc7c0  r8: 0x0000000000802805
  r9: 0x0000000000000006 r10: 0x0000000006960641 r11: 0x000000000696d7f9
 r12: 0x0000000000000001 r13: 0x0000000000800000 r14: 0x0004000000000000
 r15: 0x00007fdcc9407000 rip: 0x00000001016710e2 rfl: 0x0000000000010206

-- C level backtrace information -------------------------------------------
0   libruby.2.3.0.dylib                 0x00000001017a32d4 rb_vm_bugreport + 388
1   libruby.2.3.0.dylib                 0x00000001016456e3 rb_bug_context + 483
2   libruby.2.3.0.dylib                 0x0000000101717e63 sigsegv + 83
3   libsystem_platform.dylib            0x00007fff937ffeaa _sigtramp + 26
4   libruby.2.3.0.dylib                 0x00000001016710e2 gc_mark_ptr + 82
5   ???                                 0x00007fdccc843a10 0x0 + 140586300750352

Another lldb run, trying to print *proc (unsuccessfully):

(lldb) r
Process 84735 launched: '/Users/felix/.rvm/rubies/ruby-2.3.0/bin/ruby' (x86_64)
Exporting data...
Process 84735 stopped Event: create_hist_info Processed: 0 / 8727   0% |                                                                                                                                                    |  ETA: ??:??:??
* thread #1: tid = 0x1a4b1a, 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077
   1074	RVALUE_MARKED(VALUE obj)
   1075	{
   1076	    check_rvalue_consistency(obj);
-> 1077	    return RVALUE_MARK_BITMAP(obj) != 0;
   1078	}
   1079
   1080	#if USE_RGENGC
(lldb) bt
* thread #1: tid = 0x1a4b1a, 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00000001000700e2 libruby.2.3.0.dylib`gc_mark_ptr [inlined] RVALUE_MARKED(obj=1125899906842624) + 42 at gc.c:1077
    frame #1: 0x00000001000700b8 libruby.2.3.0.dylib`gc_mark_ptr [inlined] gc_mark_set at gc.c:4172
    frame #2: 0x00000001000700b8 libruby.2.3.0.dylib`gc_mark_ptr(objspace=0x00000001004069d0, obj=1125899906842624) + 40 at gc.c:4294
    frame #3: 0x000000010005706b libruby.2.3.0.dylib`proc_mark(ptr=0x00000001052c1eb0) + 75 at proc.c:55
[...]
(lldb) up
frame #1: 0x00000001000700b8 libruby.2.3.0.dylib`gc_mark_ptr [inlined] gc_mark_set at gc.c:4172
   4169	static inline int
   4170	gc_mark_set(rb_objspace_t *objspace, VALUE obj)
   4171	{
-> 4172	    if (RVALUE_MARKED(obj)) return 0;
   4173	    MARK_IN_BITMAP(GET_HEAP_MARK_BITS(obj), obj);
   4174	    return 1;
   4175	}
(lldb) up
frame #2: 0x00000001000700b8 libruby.2.3.0.dylib`gc_mark_ptr(objspace=0x00000001004069d0, obj=1125899906842624) + 40 at gc.c:4294
   4291	{
   4292	    if (LIKELY(objspace->mark_func_data == NULL)) {
   4293		rgengc_check_relation(objspace, obj);
-> 4294		if (!gc_mark_set(objspace, obj)) return; /* already marked */
   4295		gc_aging(objspace, obj);
   4296		gc_grey(objspace, obj);
   4297	    }
(lldb) up
frame #3: 0x000000010005706b libruby.2.3.0.dylib`proc_mark(ptr=0x00000001052c1eb0) + 75 at proc.c:55
   52  	    RUBY_MARK_UNLESS_NULL(proc->block.proc);
   53  	    RUBY_MARK_UNLESS_NULL(proc->block.self);
   54  	    if (proc->block.ep) {
-> 55  		RUBY_MARK_UNLESS_NULL(rb_vm_proc_envval(proc));
   56  	    }
   57  	    if (proc->block.iseq && RUBY_VM_IFUNC_P(proc->block.iseq)) {
   58  		rb_gc_mark((VALUE)(proc->block.iseq));
(lldb) frame variable *proc
(rb_proc_t) *proc = <parent failed to evaluate: no location, value may have been optimized out>

(lldb) frame variable proc
(rb_proc_t *) proc = <no location, value may have been optimized out>

(lldb) frame variable --no-args
(rb_proc_t *) proc = <no location, value may have been optimized out>

(VALUE) markobj = <variable not available>

Updated by felixbuenemann (Felix Bünemann) about 8 years ago

  • Subject changed from Segmentation Fault in activesupport-4.2.5 gem to Segmentation Fault in gc_mark_ptr with activesupport 4.2.x

Updated by b264 (Brian Giaraffa) about 8 years ago

alex maznev wrote:

Running into the same issue here. https://github.com/mperham/sidekiq/issues/2763

Using bundle exec seems to clear this up for me. I think there is still a problem somewhere though.

Updated by b264 (Brian Giaraffa) about 8 years ago

  • Subject changed from Segmentation Fault in gc_mark_ptr with activesupport 4.2.x to Segmentation Fault in gc_mark_ptr in 2.3.0p0

Nobuyoshi Nakada wrote:

Seems a GC problem with Proc.

-- C level backtrace information -------------------------------------------
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(rb_vm_bugreport+0x51f) [0x7fe25c8c6b7f] vm_dump.c:688
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(rb_bug_context+0xd0) [0x7fe25c750320] error.c:435
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(sigsegv+0x3e) [0x7fe25c82f7ee] signal.c:890
/lib/x86_64-linux-gnu/libc.so.6 [0x7fe25c341d40]
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(gc_mark_ptr+0x62) [0x7fe25c773cd2] gc.c:1067
/home/devbox/.rvm/rubies/ruby-2.3.0/bin/../lib/libruby.so.2.3(proc_mark+0x68) [0x7fe25c75dd68] 

If you can reproduce it with a debugger, could you show the content of *proc in this proc_mark frame?

Do you still need feedback?

Actions #11

Updated by jeremyevans0 (Jeremy Evans) over 4 years ago

  • Status changed from Feedback to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0