llvm dev - Oct 2012 - [LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range

Nick,
   While enhancing the fink llvm32 packaging to support the polly tool, I ran
into
a dyld failure when the dragonegg plugin tries to load LLVMPolly.so plugin...

dyld: lazy symbol binding failed: fast lazy bind offset out of range (39257,
max=7640) in image
/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1
dyld: fast lazy bind offset out of range (39257, max=7640) in image
/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1
Trace/BPT trap

which backtraces as...

(gdb) bt
#0  0x00007fff5fc0106d in __dyld_dyld_fatal_error ()
#1  0x00007fff5fc048c8 in __dyld__ZN4dyld4haltEPKc ()
#2  0x00007fff5fc04948 in __dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm
()
#3  0x00007fff90af7716 in dyld_stub_binder_ ()
#4  0x0000000100f3b2c0 in Json::Value::maxUInt ()
#5  0x00007fff5fc0fda6 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
#6  0x00007fff5fc0faf2 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#7  0x00007fff5fc0d2e4 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
#8  0x00007fff5fc0e0b7 in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
#9  0x00007fff5fc031b9 in __dyld__ZN4dyld15runInitializersEP11ImageLoader ()
#10 0x00007fff5fc09657 in __dyld_dlopen ()
#11 0x00007fff90af795b in dlopen ()
#12 0x0000000142f3888e in llvm::sys::DynamicLibrary::getPermanentLibrary ()
#13 0x0000000142f256bd in llvm::PluginLoader::operator= ()
#14 0x000000014280fbda in llvm::cl::opt<llvm::PluginLoader, false,
llvm::cl::parser<std::string> >::handleOccurrence ()
#15 0x0000000142f1730c in CommaSeparateAndAddOccurence ()
#16 0x0000000142f1395f in ProvideOption ()
#17 0x0000000142f1224b in llvm::cl::ParseCommandLineOptions ()
#18 0x000000014280d3ff in InitializeBackend ()
#19 0x000000014280c191 in llvm_emit_globals ()

This will be difficult to testcase since the FSF gcc 4.7.2 compiler is involved
but I was hoping that you might be able
to make some guesses about the origin of the problem from the current polly and
dragonegg source code. There doesn't
seem to be any reports of this error type (but then again few plugins,
dragonegg, indirectly call additional plugins,
LLVMPolly. Thanks in advance for any hints.
           Jack

Jack,

Some binary has an initializer which dyld is calling.  Somehow the initializer
gets to:
#4  0x0000000100f3b2c0 in Json::Value::maxUInt ()
which is calling a function in another dylib for the first time.  When you call
a function in another dylib, you actually jump through a (lazy) pointer.  The
pointer initially points to a helper which loads an index parameter specifying
which function to bind, then jumps into dyld.  Dyld is erroring because the
index is out of range.

Either:
1) The binary is corrupt. You can check that by running:
  dyldinfo -lazy_bind to see the lazy pointers
or
2) Something else is wrong with the initializer and it happens to be jumping to
the helper (that jumps into dyld), but the index parameter is garbage. 
You'll need to step though this in the debugger.

-Nick

On Oct 21, 2012, at 9:27 AM, Jack Howarth wrote
> Nick,
>   While enhancing the fink llvm32 packaging to support the polly tool, I
ran into
> a dyld failure when the dragonegg plugin tries to load LLVMPolly.so
plugin...
> 
> dyld: lazy symbol binding failed: fast lazy bind offset out of range
(39257, max=7640) in image
/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1
> dyld: fast lazy bind offset out of range (39257, max=7640) in image
/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1
> Trace/BPT trap
> 
> which backtraces as...
> 
> (gdb) bt
> #0  0x00007fff5fc0106d in __dyld_dyld_fatal_error ()
> #1  0x00007fff5fc048c8 in __dyld__ZN4dyld4haltEPKc ()
> #2  0x00007fff5fc04948 in
__dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm ()
> #3  0x00007fff90af7716 in dyld_stub_binder_ ()
> #4  0x0000000100f3b2c0 in Json::Value::maxUInt ()
> #5  0x00007fff5fc0fda6 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
> #6  0x00007fff5fc0faf2 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
> #7  0x00007fff5fc0d2e4 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
> #8  0x00007fff5fc0e0b7 in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
> #9  0x00007fff5fc031b9 in __dyld__ZN4dyld15runInitializersEP11ImageLoader
()
> #10 0x00007fff5fc09657 in __dyld_dlopen ()
> #11 0x00007fff90af795b in dlopen ()
> #12 0x0000000142f3888e in llvm::sys::DynamicLibrary::getPermanentLibrary ()
> #13 0x0000000142f256bd in llvm::PluginLoader::operator= ()
> #14 0x000000014280fbda in llvm::cl::opt<llvm::PluginLoader, false,
llvm::cl::parser<std::string> >::handleOccurrence ()
> #15 0x0000000142f1730c in CommaSeparateAndAddOccurence ()
> #16 0x0000000142f1395f in ProvideOption ()
> #17 0x0000000142f1224b in llvm::cl::ParseCommandLineOptions ()
> #18 0x000000014280d3ff in InitializeBackend ()
> #19 0x000000014280c191 in llvm_emit_globals ()
> 
> This will be difficult to testcase since the FSF gcc 4.7.2 compiler is
involved but I was hoping that you might be able
> to make some guesses about the origin of the problem from the current polly
and dragonegg source code. There doesn't
> seem to be any reports of this error type (but then again few plugins,
dragonegg, indirectly call additional plugins,
> LLVMPolly. Thanks in advance for any hints.
>           Jack

On Sun, Oct 21, 2012 at 06:00:36PM -0700, Nick Kledzik
wrote:
> Jack,
> 
> Some binary has an initializer which dyld is calling.  Somehow the
initializer gets to:
> #4  0x0000000100f3b2c0 in Json::Value::maxUInt ()
> which is calling a function in another dylib for the first time.  When you
call a function in another dylib, you actually jump through a (lazy) pointer. 
The pointer initially points to a helper which loads an index parameter
specifying which function to bind, then jumps into dyld.  Dyld is erroring
because the index is out of range.
> 
> Either:
> 1) The binary is corrupt. You can check that by running:
>   dyldinfo -lazy_bind to see the lazy pointers
Nick,
    I attached dragonegg_so_lazy_bind.txt and LLVMPolly_so_lazy_bind.txt to
http://llvm.org/bugs/show_bug.cgi?id=14140.
Is there anything significant in those lists of lazy pointers relative to the
failure we are seeing? FYI, I see the same
failure for both x86_64-apple-darwin11 and x86_64-apple-darwin12 with current
llvm/polly/dragonegg svn using Xcode 4.5.1's
linker.
> or
> 2) Something else is wrong with the initializer and it happens to be
jumping to the helper (that jumps into dyld), but the index parameter is
garbage.  You'll need to step though this in the debugger.
>From the backtrace quoted below, can you suggest a logical place to set the
breakpoint as the starting point to step through this code?
Thanks in advance.
       Jack
> 
> -Nick
> 
> On Oct 21, 2012, at 9:27 AM, Jack Howarth wrote
> > Nick,
> >   While enhancing the fink llvm32 packaging to support the polly tool,
I ran into
> > a dyld failure when the dragonegg plugin tries to load LLVMPolly.so
plugin...
> > 
> > dyld: lazy symbol binding failed: fast lazy bind offset out of range
(39257, max=7640) in image
/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1
> > dyld: fast lazy bind offset out of range (39257, max=7640) in image
/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1
> > Trace/BPT trap
> > 
> > which backtraces as...
> > 
> > (gdb) bt
> > #0  0x00007fff5fc0106d in __dyld_dyld_fatal_error ()
> > #1  0x00007fff5fc048c8 in __dyld__ZN4dyld4haltEPKc ()
> > #2  0x00007fff5fc04948 in
__dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm ()
> > #3  0x00007fff90af7716 in dyld_stub_binder_ ()
> > #4  0x0000000100f3b2c0 in Json::Value::maxUInt ()
> > #5  0x00007fff5fc0fda6 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
> > #6  0x00007fff5fc0faf2 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
> > #7  0x00007fff5fc0d2e4 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
> > #8  0x00007fff5fc0e0b7 in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
> > #9  0x00007fff5fc031b9 in
__dyld__ZN4dyld15runInitializersEP11ImageLoader ()
> > #10 0x00007fff5fc09657 in __dyld_dlopen ()
> > #11 0x00007fff90af795b in dlopen ()
> > #12 0x0000000142f3888e in
llvm::sys::DynamicLibrary::getPermanentLibrary ()
> > #13 0x0000000142f256bd in llvm::PluginLoader::operator= ()
> > #14 0x000000014280fbda in llvm::cl::opt<llvm::PluginLoader, false,
llvm::cl::parser<std::string> >::handleOccurrence ()
> > #15 0x0000000142f1730c in CommaSeparateAndAddOccurence ()
> > #16 0x0000000142f1395f in ProvideOption ()
> > #17 0x0000000142f1224b in llvm::cl::ParseCommandLineOptions ()
> > #18 0x000000014280d3ff in InitializeBackend ()
> > #19 0x000000014280c191 in llvm_emit_globals ()
> > 
> > This will be difficult to testcase since the FSF gcc 4.7.2 compiler is
involved but I was hoping that you might be able
> > to make some guesses about the origin of the problem from the current
polly and dragonegg source code. There doesn't
> > seem to be any reports of this error type (but then again few plugins,
dragonegg, indirectly call additional plugins,
> > LLVMPolly. Thanks in advance for any hints.
> >           Jack