Forum: Ruby-core Ruby 1.8.6-p383 hangs in dln_load on Snow Leopard

An RMagick user reports that Ruby 1.8.6 hangs when requiring RMagick.
I've determined that Ruby hangs in semaphore_wait_signal_trap() called
from dln_load(). I've pasted the full traceback below.

This is Ruby 1.8.6 (2009-08-04 patchlevel 383) [i686-darwin10.0.0]
running on Snow Leopard installed from source. The hang does not occur
with the version of Ruby that is pre-installed with Snow Leopard
(1.8.7-p72), or with Ruby 1.8.7-p174 installed from source.

Here's the Ruby ./configure command:

$ ./configure --enable-pthread --enable-shared --enable-install-doc

In all cases I'm using RMagick 2.11.1, from 
http://rubyforge.org/frs/download.php/63235/RMagic...
  and ImageMagick 6.5.6-5, from ftp.imagemagick.org. I don't think it
matters precisely which delegate libraries are installed but if it
does I'll be glad to list what I have installed.

A simple reproduction is

ruby -r RMagick -e"puts Magick::Long_version"

I'm using the stock gcc that comes with Snow Leopard:

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)

I'd appreciate advice on how to resolve this problem. Please let me
know if you need any more information. Thanks.

Here's the gdb traceback:

(gdb) whe
#0  0x00007fff80066dc2 in semaphore_wait_signal_trap ()
#1  0x00007fff8006c30d in pthread_mutex_lock ()
#2  0x00007fff83280490 in unmap_image ()
#3  0x00007fff5fc04a34 in __dyld__ZN4dyld11removeImageEP11ImageLoader ()
#4  0x00007fff5fc04ba5 in __dyld__ZN4dyld20garbageCollectImagesEv ()
#5  0x00007fff5fc09e9a in __dyld_dlclose ()
#6  0x00007fff8006e565 in dlclose ()
#7  0x00007fff832783c5 in _read_images ()
#8  0x00007fff8328f25e in map_images_nolock ()
#9  0x00007fff83277bc0 in map_images ()
#10 0x00007fff5fc039b9 in
__dyld__ZN4dyldL18notifyBatchPartialE17dyld_image_statesbPFPKcS0_jPK15dyld_image_infoE
  ()
#11 0x00007fff5fc0c839 in
__dyld__ZN11ImageLoader4linkERKNS_11LinkContextEbbRKNS_10RPathChainE ()
#12 0x00007fff5fc04d48 in
__dyld__ZN4dyld4linkEP11ImageLoaderbRKNS0_10RPathChainE ()
#13 0x00007fff5fc08a29 in __dyld_NSLinkModule ()
#14 0x00007fff8016dfce in NSLinkModule ()
#15 0x0000000100011479 in dln_load (file=0x10023e820 "../../ext/
RMagick/RMagick2.bundle") at dln.c:1469
#16 0x000000010002e761 in rb_require_safe (fname=4296659680, safe=0)
at eval.c:7297
#17 0x0000000100023d00 in rb_call0 (klass=4296796480, recv=4296786760,
id=9449, oid=9449, argc=1, argv=0x7fff5fbfead0, body=0x1001a0af8,
flags=<value temporarily unavailable, due to optimizations>) at eval.c:
5872
#18 0x000000010002403b in rb_call (klass=4296796480, recv=4296786760,
mid=9449, argc=1, argv=0x7fff5fbfead0, scope=1, self=4296786760) at
eval.c:6119
#19 0x000000010001d6b2 in rb_eval (self=4296786760, n=<value
temporarily unavailable, due to optimizations>) at eval.c:3507
#20 0x000000010002e381 in rb_load (fname=4296660280, wrap=<value
temporarily unavailable, due to optimizations>) at eval.c:6914
#21 0x000000010002e7e0 in rb_require_safe (fname=4296662160, safe=0)
at eval.c:7288
#22 0x0000000100023d00 in rb_call0 (klass=4296796480, recv=4296786760,
id=9449, oid=9449, argc=1, argv=0x7fff5fbff450, body=0x1001a0af8,
flags=<value temporarily unavailable, due to optimizations>) at eval.c:
5872
#23 0x000000010002403b in rb_call (klass=4296796480, recv=4296786760,
mid=9449, argc=1, argv=0x7fff5fbff450, scope=1, self=4296786760) at
eval.c:6119
#24 0x000000010001d6b2 in rb_eval (self=4296786760, n=<value
temporarily unavailable, due to optimizations>) at eval.c:3507
#25 0x000000010002fa5b in ruby_exec_internal () at eval.c:1644
#26 0x000000010002fa98 in ruby_exec () at eval.c:1664
#27 0x000000010002fac0 in ruby_run () at eval.c:1674
#28 0x0000000100000ee4 in main (argc=<value temporarily unavailable,
due to optimizations>, argv=<value temporarily unavailable, due to
optimizations>, envp=<value temporarily unavailable, due to
optimizations>) at main.c:48

On Oct 3, 2009, at 4:26 PM, Timothy Hunter wrote:

> An RMagick user reports that Ruby 1.8.6 hangs when requiring RMagick.

I'm that user and RMagick isn't the only Ruby extension affected.  A
plist extension shipped with TextMate shows the same behavior.  This
extension is a trivial wrapper over a framework provided in the OS.
These are the only two extensions I've noticed are affected, so far.

If you have TextMate installed on Snow Leopard, it's super easy to
trigger this hang:

   $ ruby -r /Applications/TextMate.app/Contents/SharedSupport/Support/
lib/osx/plist -e1

It's also worth nothing that when Tim says the process hangs, he means
it. It cannot be interrupted and I have to kill -9 the process to get
it to stop.

James Edward Gray II

On Oct 3, 2009, at 14:52 , James Edward Gray II wrote:

> trigger this hang:
>
>  $ ruby -r /Applications/TextMate.app/Contents/SharedSupport/Support/ 
> lib/osx/plist -e1

can you run `file` on all the binaries involved pls?

On Oct 3, 2009, at 7:04 PM, Ryan Davis wrote:

>> the OS.  These are the only two extensions I've noticed are  
>> affected, so far.
>>
>> If you have TextMate installed on Snow Leopard, it's super easy to  
>> trigger this hang:
>>
>> $ ruby -r /Applications/TextMate.app/Contents/SharedSupport/Support/ 
>> lib/osx/plist -e1
>
> can you run `file` on all the binaries involved pls?

Here's the Ruby I compiled, RMagick (if I used the right path), and
TextMate's plist extension:

$ file /usr/local/bin/ruby
/usr/local/bin/ruby: Mach-O 64-bit executable x86_64
$ file /usr/local/lib/ruby/gems/1.8/gems/rmagick-2.11.1/ext/RMagick/
RMagick2.bundle
/usr/local/lib/ruby/gems/1.8/gems/rmagick-2.11.1/ext/RMagick/
RMagick2.bundle: Mach-O 64-bit bundle x86_64
$ file /Applications/TextMate.app/Contents/SharedSupport/Support/lib/
osx/plist.bundle
/Applications/TextMate.app/Contents/SharedSupport/Support/lib/osx/
plist.bundle: Mach-O universal binary with 3 architectures
/Applications/TextMate.app/Contents/SharedSupport/Support/lib/osx/
plist.bundle (for architecture ppc7400):  Mach-O bundle ppc
/Applications/TextMate.app/Contents/SharedSupport/Support/lib/osx/
plist.bundle (for architecture i386):  Mach-O bundle i386
/Applications/TextMate.app/Contents/SharedSupport/Support/lib/osx/
plist.bundle (for architecture x86_64):  Mach-O 64-bit bundle x86_64

Here's Apple's Ruby for comparison:

$ file /usr/bin/ruby
/usr/bin/ruby: Mach-O universal binary with 3 architectures
/usr/bin/ruby (for architecture x86_64):  Mach-O 64-bit executable 
x86_64
/usr/bin/ruby (for architecture i386):  Mach-O executable i386
/usr/bin/ruby (for architecture ppc7400):  Mach-O executable ppc
Cakey-Please:~ $ file /Applications/Tex
TextEdit.app/ TextMate.app/

Let me know if I didn't use a good path for RMagick or you want to see
others.

James Edward Gray II

On Oct 3, 2009, at 11:21 PM, James Edward Gray II wrote:

>>> A plist extension shipped with TextMate shows the same behavior.   
>> can you run `file` on all the binaries involved pls?
> $ file /Applications/TextMate.app/Contents/SharedSupport/Support/lib/ 
> Here's Apple's Ruby for comparison:
> Let me know if I didn't use a good path for RMagick or you want to  
> see others.
>
> James Edward Gray II
>
>


Snow Leopard's Ruby:

$ file /usr/bin/ruby
/usr/bin/ruby: Mach-O universal binary with 3 architectures
/usr/bin/ruby (for architecture x86_64):  Mach-O 64-bit executable 
x86_64
/usr/bin/ruby (for architecture i386):  Mach-O executable i386
/usr/bin/ruby (for architecture ppc7400):  Mach-O executable ppc

Here's RMagick2.bundle when built using Snow Leopard's Ruby 1.8.7:

$ file RMagick2.bundle
RMagick2.bundle: Mach-O universal binary with 2 architectures
RMagick2.bundle (for architecture i386):  Mach-O bundle i386
RMagick2.bundle (for architecture x86_64):  Mach-O 64-bit bundle x86_64

And ImageMagick:

$ file libMagickCore.dylib
libMagickCore.dylib: Mach-O 64-bit dynamically linked shared library
x86_64

On Oct 3, 10:26 pm, Timothy Hunter <cycli...@nc.rr.com> wrote:
> An RMagick user reports that Ruby 1.8.6 hangs when requiring RMagick.  
> I've determined that Ruby hangs in semaphore_wait_signal_trap() called  
> from dln_load(). I've pasted the full traceback below.

It looks like Snow Leopard broke backwards compatibility with
NSLinkModule as backporting the changes in dln.c from 1.8.7 to 1.8.6
seems to fix the problems for me - at least it lets me load RMagick
without hanging. NSLinkModule and friends have been deprecated for a
while now (10.4, I think) and I'm betting that they didn't get much
attention when Apple were optimising dyld for Snow Leopard.

On Oct 12, 2009, at Oct 12 7:56 AM, Andrew White wrote:

> while now (10.4, I think) and I'm betting that they didn't get much
> attention when Apple were optimising dyld for Snow Leopard.
>

Fascinating. Thanks for running this down, Andrew. Do you think I
should open a bug on Redmine? Were you planning to submit a patch?

On 13 Oct 2009, at 21:25, Timothy Hunter wrote:

> Fascinating. Thanks for running this down, Andrew. Do you think I  
> should open a bug on Redmine? Were you planning to submit a patch?

Well I wasn't going to as I thought that since the change took place
in revision 11810 (Feb 23rd, 2007) I was assuming that it hadn't been
applied to 1.8.6 for backward compatibility reasons. It's not a
priority for me since I'm only building 1.8.6 for developing and
testing on my computer as our servers are running Ubuntu 8.04 LTS
which is still 1.8.6-p111. However, I'll submit a patch if you think
it's worthwhile.

On Oct 13, 2009, at 11:56 PM, Andrew White wrote:

> which is still 1.8.6-p111. However, I'll submit a patch if you think  
> it's worthwhile.

A lot of people I know are still using Ruby 1.8.6.  A lot of people I
know are also on or moving to Snow Leopard.  These people could see
some problems.  It affects at least RMagick and some of TextMate, both
of which are popular tools.

The point of all of this is that I think we're talking about some
pretty mainstream usage here.  I believe that's worth a patch, yes.

We know it's broken.  We know what's broken.  Is there much of a
downside to fixing it?

James Edward Gray II

Yes. Submit a patch please. I will get it added and tested.

Kirk Haines
Sent from my Verizon Wireless BlackBerry