Backport #5003
closedEnumerator#next segfaults in OS X Lion (10.7)
Description
=begin
((foo.rb (Test program)))
puts RUBY_VERSION
hash = {:name => "Ganesh", :age => 30}
hash_iter = hash.to_enum
p hash_iter.next
p hash_iter.next
Output on ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin11.0.0]
→ ruby foo.rb
1.9.2
[:name, "Ganesh"]
[BUG] Segmentation fault
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin11.0.0]
-- control frame ----------
c:0005 p:---- s:0009 b:0009 l:0016b0 d:000008 IFUNC
c:0004 p:---- s:0007 b:0007 l:000006 d:000006 CFUNC :each
c:0003 p:---- s:0005 b:0005 l:000004 d:000004 CFUNC :each
c:0002 p:---- s:0003 b:0003 l:0016b0 d:000002 IFUNC
c:0001 p:---- s:0001 b:-001 l:000000 d:000000 ------
-- Ruby level backtrace information ----------------------------------------
foo.rb:0:in each' foo.rb:0:in
each'
-- C level backtrace information -------------------------------------------
[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
Abort trap: 6
Same program runs fine on ruby 1.8.7 (2010-01-10 patchlevel 249) [universal-darwin11.0]
→ ruby foo.rb
1.8.7
[:age, 30]
[:name, "Ganesh"]
I have attached the crash report, let me know if you need another information. I haven't tried this in any lower version of Mac OS X or other operating systems.
=end
Files
Updated by xeron (Ivan Larionov) over 13 years ago
- File ruby_2011-07-10-112902_macbook.crash ruby_2011-07-10-112902_macbook.crash added
- File ruby_openid_segfault.txt ruby_openid_segfault.txt added
There's something like Ganesh's.
Updated by nobu (Nobuyoshi Nakada) over 13 years ago
- Priority changed from Normal to 3
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- Status changed from Open to Feedback
We haven't try the Lion beta release, but We've try the Lion production release.
(yeah, the Lion has been released yesterday)
And I'd report we confirmed your testcase work for me on Lion production release.
Can you please try latest Lion release?
Thanks.
Updated by cenobyte (Sebastian Morawietz) over 13 years ago
I can absolutely confirm Ganesh's crash. Here is my backtrace:
1.9.2
[:name, "Ganesh"]
[BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.0]
-- control frame ----------
c:0005 p:---- s:0009 b:0009 l:0001e0 d:000008 IFUNC
c:0004 p:---- s:0007 b:0007 l:000006 d:000006 CFUNC :each
c:0003 p:---- s:0005 b:0005 l:000004 d:000004 CFUNC :each
c:0002 p:---- s:0003 b:0003 l:0001e0 d:000002 IFUNC
c:0001 p:---- s:0001 b:-001 l:000000 d:000000 ------
-- Ruby level backtrace information ----------------------------------------
./crash.rb:0:in each' ./crash.rb:0:in
each'
-- C level backtrace information -------------------------------------------
[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
Abort trap: 6
Some more information:
I'm running an rvm installation of ruby-1.9.2-p290, but the crash reproduces on -p180 too. Updated to Mac OS X 10.7 Lion yesterday.
LANG=de_DE.UTF-8
This snippet crashes too, btw (with exactly the same backtrace):
#!/usr/bin/env ruby
a=[1,2,3].to_enum
a.next
a.next
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- ruby -v changed from ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin11.0.0] to -
I can absolutely confirm Ganesh's crash. Here is my backtrace:
1.9.2
[:name, "Ganesh"]
[BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.0]
Hmm...
I have no idea why we got different result. can you please try trunk too?
Updated by naruse (Yui NARUSE) over 13 years ago
This is built with llvm-gcc with -O option (not -O0), isn't it?
If so, it is llvm's issue from too radical optimization.
Differences between trunk and 1.9.2 is because of my recent fixes like r32201.
Updated by cenobyte (Sebastian Morawietz) over 13 years ago
@ Motohiro Kosaki: Ok!
CrashOverride:~ smorawietz $ ruby --version
ruby 1.9.2p290 (2011-07-09) [x86_64-darwin11.0.0]
CrashOverride:~ smorawietz $ ruby -e "[].to_enum.next"
-e:1: [BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09) [x86_64-darwin11.0.0]
-- control frame ----------
c:0004 p:---- s:0009 b:0009 l:001660 d:001660 CFUNC :next
c:0003 p:0016 s:0006 b:0006 l:001b28 d:0015b8 EVAL -e:1
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:001b28 d:001b28 TOP
-- Ruby level backtrace information ----------------------------------------
-e:1:in <main>' -e:1:in
next'
-- C level backtrace information -------------------------------------------
And for trunk:
CrashOverride:tmp smorawietz $ ruby --version
ruby 1.9.4dev (2011-07-21 trunk 32598) [x86_64-darwin11.0.0]
CrashOverride:tmp smorawietz $ ruby -e "[].to_enum.next"
-e:1:in next': iteration reached an end (StopIteration) from -e:1:in
'
@ Yui Naruse
CrashOverride:tmp smorawietz $ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Updated by mrkn (Kenta Murata) over 13 years ago
This is occurred by ruby-1.9.2p290 built with gcc-4.2 (non-llvm gcc) on Lion.
$ gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/gcc/gcc-5666.3~278/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
$ ruby -rrbconfig -e 'p RbConfig::CONFIG["CC"]'
"gcc-4.2"
$ ruby -rrbconfig -e 'p RbConfig::CONFIG["optflags"]'
"-O3 -mtune=core2 -march=core2"
$ ruby -ve '(0..255).zip(0..255)'
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.0]
-e:1: [BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-darwin11.0.0]
-- control frame ----------
c:0007 p:---- s:0016 b:0016 l:001890 d:001890 CFUNC :next
c:0006 p:---- s:0014 b:0014 l:000009 d:000013 IFUNC
c:0005 p:---- s:0012 b:0012 l:000011 d:000011 CFUNC :each
c:0004 p:---- s:0010 b:0010 l:000009 d:000009 CFUNC :zip
c:0003 p:0014 s:0006 b:0006 l:001e68 d:0016f8 EVAL -e:1
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:001e68 d:001e68 TOP
-- Ruby level backtrace information ----------------------------------------
-e:1:in <main>' -e:1:in
zip'
-e:1:in each' -e:1:in
next'
-- C level backtrace information -------------------------------------------
[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
Abort trap: 6
Updated by telemachus (Peter Aronoff) over 13 years ago
On Fri Jul 22 2011 @ 5:34, Kenta Murata wrote:
> I have attached the crash report, let me know if you need another information. I haven't tried this in any lower version of Mac OS X or other operating systems. > =endIssue #5003 has been updated by Kenta Murata.
This is occurred by ruby-1.9.2p290 built with gcc-4.2 (non-llvm gcc) on
Lion.
I get the same segfault on 1.9.2-p290 built with the same tools on Lion. On
OSX 10.6.8 (using Xcode 3), the program runs fine. Just another data point.
[D]igital information lasts forever--or five years, whichever comes first.
"Ensuring the Longevity of Digital Information", Jeff Rothenberg
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- Category set to core
- Status changed from Feedback to Open
This is occurred by ruby-1.9.2p290 built with gcc-4.2 (non-llvm gcc) on Lion.
I canceled 'feedback' status then.
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- Status changed from Open to Assigned
- Assignee set to kosaki (Motohiro KOSAKI)
- Priority changed from 3 to Normal
- Target version set to 1.9.3
Sigh, I've purchased Lion due to I gave up to resist from a lot of no hint bug reprot. ;-/
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
vanilla trunk + -O0: works
vanilla trunk + -O3: works
192p290 + -O0: works
192p290 + -O3: crash
192p290 + -O3 + r32201: works
So, I believe it's back port issue.
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- Assignee changed from kosaki (Motohiro KOSAKI) to yugui (Yuki Sonoda)
- Target version changed from 1.9.3 to 1.9.2
Updated by naruse (Yui NARUSE) over 13 years ago
- Parent task set to #5076
Updated by wr0ngway (Matthew Conway) over 13 years ago
I tired applying the diff from r32201 to 1.9.2p290, and while it mostly works, and seems to fix this problem, it also causes another. In our rails app, which used to work just fine on 1.9.2p290 on OS X Snow Leopard, I get the following error running a rails console:
/Users/mconway/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.0.0/lib/rails/commands.rb:21:in <top (required)>': uninitialized fiber (FiberError) from script/rails:10:in
require'
from script/rails:10:in `'
I built on OS X Lion, using rvm 1.6.25, and XCode 4.1 (4B110) (/usr/bin/gcc)
Not sure if the patch is just not compatible with 1.9.2 branch, or if something else is going on. A vanilla rails app loads just fine, so could be something in our stack - just weird that it used to work before this patch.
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
I tired applying the diff from r32201 to 1.9.2p290, and while it mostly works, and seems to fix this problem, it also causes another. Â In our rails app, which used to work just fine on 1.9.2p290 on OS X Snow Leopard, I get the following error running a rails console:
/Users/mconway/.rvm/gems/ruby-1.9.2-p290/gems/railties-3.0.0/lib/rails/commands.rb:21:in
<top (required)>': uninitialized fiber (FiberError) Â Â Â Â from script/rails:10:in
require'
    from script/rails:10:in `'I built on OS X Lion, using rvm 1.6.25, and XCode 4.1 (4B110) (/usr/bin/gcc)
Not sure if the patch is just not compatible with 1.9.2 branch, or if something else is going on. Â A vanilla rails app loads just fine, so could be something in our stack - just weird that it used to work before this patch.
I think your issue is the same with [Bug #5082]. we now tracking by
another ticket.
If you want to know our Lion activity, please track aggregated ticket
[Bug #5076].
In fact, XCode4.1 gcc is NOT truth gcc. it's gcc-llvm. and llvm
optimization seems have
a lot of over optimization issue. I recommend to use gcc-4.2 (i.e.
true gcc) instead until we
finish our llvm adoption.
Thanks.
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- Tracker changed from Bug to Backport
- Project changed from Ruby master to Backport192
- Category changed from core to core
- Target version deleted (
1.9.2) - Parent task deleted (
#5076)
Updated by naruse (Yui NARUSE) over 8 years ago
- Status changed from Assigned to Rejected