[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range

[Nick Kledzik]

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