Backport #5003

Enumerator#next segfaults in OS X Lion (10.7)

Added by Ganesh Gunasegaran almost 3 years ago. Updated over 2 years ago.

[ruby-core:37913]
Status:Assigned
Priority:Normal
Assignee:Yuki Sonoda

Description

=begin
((foo.rb (Test program)))

puts RUBYVERSION
hash = {:name => "Ganesh", :age => 30}
hash
iter = hash.toenum
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

ruby_2011-07-09-135159_imac.crash (8.83 KB) Ganesh Gunasegaran, 07/09/2011 05:28 PM

ruby_2011-07-10-112902_macbook.crash (15.9 KB) Ivan Larionov, 07/11/2011 05:50 AM

ruby_openid_segfault.txt Magnifier (15.6 KB) Ivan Larionov, 07/11/2011 05:50 AM


Related issues

Duplicated by ruby-trunk - Bug #5031: Enumerable#zip SEGFAULTs with a Range Object (Mac OS X 10... Closed 07/16/2011

History

#1 Updated by Ivan Larionov almost 3 years ago

There's something like Ganesh's.

#2 Updated by Nobuyoshi Nakada almost 3 years ago

  • Priority changed from Normal to Low

#3 Updated by Motohiro KOSAKI almost 3 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.

#4 Updated by Sebastian Morawietz over 2 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

#5 Updated by Motohiro KOSAKI over 2 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?

#6 Updated by Yui NARUSE over 2 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.

#7 Updated by Sebastian Morawietz over 2 years ago

@ Motohiro Kosaki: Ok!

CrashOverride:~ smorawietz $ ruby --version
ruby 1.9.2p290 (2011-07-09) [x8664-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) [x8664-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.

#8 Updated by Kenta Murata over 2 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=x8664-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

#9 Updated by Peter Aronoff over 2 years ago

On Fri Jul 22 2011 @ 5:34, Kenta Murata wrote:

Issue #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 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

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

#10 Updated by Motohiro KOSAKI over 2 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.

#11 Updated by Motohiro KOSAKI over 2 years ago

  • Status changed from Open to Assigned
  • Assignee set to Motohiro KOSAKI
  • Priority changed from Low 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. ;-/

#12 Updated by Motohiro KOSAKI over 2 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.

#13 Updated by Motohiro KOSAKI over 2 years ago

  • Assignee changed from Motohiro KOSAKI to Yuki Sonoda
  • Target version changed from 1.9.3 to 1.9.2

#14 Updated by Yui NARUSE over 2 years ago

  • Parent task set to #5076

#15 Updated by Matthew Conway over 2 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.

#16 Updated by Motohiro KOSAKI over 2 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.

#17 Updated by Motohiro KOSAKI over 2 years ago

  • Tracker changed from Bug to Backport
  • Project changed from ruby-trunk to Backport92
  • Category changed from core to core
  • Target version deleted (1.9.2)
  • Parent task deleted (#5076)

Also available in: Atom PDF