[#61171] Re: [ruby-changes:33145] normal:r45224 (trunk): gc.c: fix build for testing w/o RGenGC — SASADA Koichi <ko1@...>
(2014/03/01 16:15), normal wrote:
3 messages
2014/03/01
[#61243] [ruby-trunk - Feature #9425] [PATCH] st: use power-of-two sizes to avoid slow modulo ops — normalperson@...
Issue #9425 has been updated by Eric Wong.
4 messages
2014/03/03
[#61359] [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs — normalperson@...
Issue #9609 has been reported by Eric Wong.
5 messages
2014/03/07
[#61360] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— SASADA Koichi <ko1@...>
2014/03/07
(2014/03/07 19:09), normalperson@yhbt.net wrote:
[#61362] Re: [ruby-trunk - Bug #9609] [Open] [PATCH] vm_eval.c: fix misplaced RB_GC_GUARDs
— Eric Wong <normalperson@...>
2014/03/07
SASADA Koichi <ko1@atdot.net> wrote:
[#61424] [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals — Eric Wong <normalperson@...>
I'm unsure about this. I _hate_ the extra branches this adds;
13 messages
2014/03/12
[#61466] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/13
Hi Eric,
[#61471] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/13
SASADA Koichi <ko1@atdot.net> wrote:
[#61508] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— SASADA Koichi <ko1@...>
2014/03/15
(2014/03/14 2:12), Eric Wong wrote:
[#61509] Re: [REJECT?] xmalloc/xfree: reduce atomic ops w/ thread-locals
— Eric Wong <normalperson@...>
2014/03/15
SASADA Koichi <ko1@atdot.net> wrote:
[#61452] [ruby-trunk - Feature #9632] [Open] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been reported by Eric Wong.
3 messages
2014/03/13
[#61496] [ruby-trunk - Feature #9638] [Open] [PATCH] limit IDs to 32-bits on 64-bit systems — normalperson@...
Issue #9638 has been reported by Eric Wong.
4 messages
2014/03/14
[#61568] hash function for global method cache — Eric Wong <normalperson@...>
I came upon this because I noticed existing st numtable worked poorly
7 messages
2014/03/17
[#61605] Re: hash function for global method cache
— SASADA Koichi <ko1@...>
2014/03/20
(2014/03/18 8:03), Eric Wong wrote:
[#61606] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/20
SASADA Koichi <ko1@atdot.net> wrote:
[#61631] Re: hash function for global method cache
— =?KOI8-R?B?4NLJyiDzz8vPzM/X?= <funny.falcon@...>
2014/03/22
what's the profit from using binary tree in place of hash?
[#61632] Re: hash function for global method cache
— Eric Wong <normalperson@...>
2014/03/22
Юрий Соколов <funny.falcon@gmail.com> wrote:
[#61687] [ruby-trunk - Bug #9606] Ocassional SIGSEGV inTestException#test_machine_stackoverflow on OpenBSD — normalperson@...
Issue #9606 has been updated by Eric Wong.
3 messages
2014/03/26
[#61760] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — normalperson@...
Issue #9632 has been updated by Eric Wong.
3 messages
2014/03/30
[ruby-core:61650] [ruby-trunk - Bug #9666] [Open] Segmentation fault while printing out C level backtrace information, when $0 is set
From:
Rei.Odaira@...
Date:
2014-03-24 07:33:33 UTC
List:
ruby-core #61650
Issue #9666 has been reported by Rei Odaira.
----------------------------------------
Bug #9666: Segmentation fault while printing out C level backtrace information, when $0 is set
https://bugs.ruby-lang.org/issues/9666
* Author: Rei Odaira
* Status: Open
* Priority: Normal
* Assignee:
* Category:
* Target version:
* ruby -v: ruby 2.2.0dev (2014-03-24) [powerpc64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
This might be related to [Bug #9654], but when $0 is set, a segmentation fault happens while printing out C-level backtrace. Due to this issue, `TestRubyOptions#test_segv_setproctitle` fails in my environment (ppc64 linux).
~~~
ruby -e '$0="foo.rb"; Process.kill :SEGV, $$'
-e:1: [BUG] Segmentation fault at 0x001f80
ruby 2.2.0dev (2014-03-24) [powerpc64-linux]
-- Control frame information -----------------------------------------------
c:0003 p:---- s:0009 e:000008 CFUNC :kill
c:0002 p:0021 s:0004 E:0006f4 EVAL -e:1 [FINISH]
c:0001 p:0000 s:0002 E:000cd4 TOP [FINISH]
-- Ruby level backtrace information ----------------------------------------
-e:1:in `<main>'
-e:1:in `kill'
-- C level backtrace information -------------------------------------------
foo.rb [0x20774264]
foo.rb [0x207e250c]
foo.rb(rb_bug+0xc4) [0x207e2844]
foo.rb [0x206e64f0]
(__kernel_sigtramp_rt32+0x0) [0x100360]
foo.rb [0x20782ee8]
foo.rb(rb_f_kill+0x98) [0x206e74f8]
foo.rb [0x2075294c]
foo.rb [0x2075c5ac]
foo.rb [0x20771c60]
foo.rb [0x207699a8]
foo.rb [0x2076d8c8]
foo.rb(rb_iseq_eval_main+0x2f8) [0x2076def8]
foo.rb [0x20611884]
foo.rb(ruby_run_node+0xa4) [0x206136c4]
foo.rb [0x2060f77c]
/lib/libc.so.6(Segmentation fault
~~~
Here is the stack trace at the second segmentation fault.
~~~
(gdb) bt
#0 0x2030a994 in strlen () from /lib/libc.so.6
#1 0x2085ce70 in kvprintf (fmt=0x208f0c45 "+0x%lx) [0x%lx] %s/%s:%d\n")
at addr2line.c:1014
#2 kprintf (fmt=0x208f0c45 "+0x%lx) [0x%lx] %s/%s:%d\n") at addr2line.c:776
#3 0x2085e8d8 in rb_dump_backtrace_with_lines (num_traces=18,
traces=0x2096790c, syms=0x20c27190) at addr2line.c:678
#4 0x2084428c in rb_print_backtrace () at vm_dump.c:690
#5 rb_vm_bugreport () at vm_dump.c:825
#6 0x208b250c in report_bug (file=<value optimized out>,
line=<value optimized out>, fmt=0x208e88dc "Segmentation fault at %p",
args=0x209d0034) at error.c:312
#7 0x208b2844 in rb_bug (fmt=0x208e88dc "Segmentation fault at %p")
at error.c:339
#8 0x207b64f0 in sigsegv (sig=<value optimized out>, info=0x209d00c0,
ctx=<value optimized out>) at signal.c:704
#9 <signal handler called>
#10 0x202b674c in kill () from /lib/libc.so.6
#11 0x20852ef4 in ruby_kill (pid=<value optimized out>,
sig=<value optimized out>) at thread.c:5185
<<<<< snip >>>>>
~~~
Again, line->sname points to some out-of-range address.
--
https://bugs.ruby-lang.org/