[LLVMdev] dyld: lazy symbol binding failed: fast lazy bind offset out of range
Nick Kledzik
kledzik at apple.com
Tue Oct 23 17:10:02 PDT 2012
On Oct 23, 2012, at 4:46 PM, Jack Howarth wrote:
> On Tue, Oct 23, 2012 at 02:03:15PM -0700, Nick Kledzik wrote:
>>
>> On Oct 23, 2012, at 1:57 PM, Jack Howarth wrote:
>>> Nick,
>>> Can I do this without access to a debug version of dyld? Using the copy of LLVMPolly.so with isl/cloog-isl/gmp statically linked,
>>> I find that if I set the breakpoint to the address of the initializer...
>>>
>>> dyld: calling initializer function 0x100ebb3a0 in /sw/opt/llvm-3.2/lib/LLVMPolly.so
>>> dyld: lazy symbol binding failed: fast lazy bind offset out of range (114808, max=2928) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1
>>> dyld: fast lazy bind offset out of range (114808, max=2928) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1
>>>
>>> with...
>>>
>>> (gdb) break *0x100ebb3a0
>>> Breakpoint 2 at 0x100ebb3a0
>>>
>>> this lands me at...
>>>
>>> dyld: weak bind: LLVMPolly.so:0x1010F4BD0 = libc++.1.dylib:__Znwm, *0x1010F4BD0 = 0x7FFF898BD0DF
>>>
>>> Breakpoint 2, 0x0000000100ebb3a0 in pch_address_space ()
>>> (gdb) si
>>> 0x0000000100ebb3a1 in pch_address_space ()
>>> (gdb) si
>>> 0x0000000100ebb3a4 in pch_address_space ()
>>> (gdb) si
>>> 0x0000000100ebb380 in pch_address_space ()
>>> (gdb) si
>>> 0x0000000100ebb381 in pch_address_space ()
>>> ...
>>> and on in various dyld calls. Will I really be able to get anything useful from this without a debug build of the system
>>> dyld installed?
>>>
>> You just need a build of LLVMPolly.so that does not have symbols stripped. Or get the .dSYM file for your build of LLVMPolly.so and load that in gdb.
>>
>> -Nick
>>
>
> Nick,
> I have uploaded a bzip2 compressed log of the 'si' walk from the failing initializer in LLVMPolly.so
> to http://llvm.org/bugs/attachment.cgi?id=9408 in http://llvm.org/bugs/show_bug.cgi?id=14140. The backtrace
> from the final crash point shows...
>
> (gdb) bt
> #0 0x00007fff5fc0123f in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
> #1 0x00007fff5fc02138 in __dyld__ZN4dyld4haltEPKc ()
> #2 0x00007fff5fc04048 in __dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm ()
> #3 0x00007fff8bd808ee in dyld_stub_binder_ ()
> #4 0x0000000100faf3e0 in Json::Value::maxUInt ()
> #5 0x0000000100ebad65 in pch_address_space ()
> #6 0x0000000100ebb5a0 in pch_address_space ()
> #7 0x0000000100ebb5b9 in pch_address_space ()
> #8 0x00007fff5fc13378 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
> #9 0x00007fff5fc13762 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
> #10 0x00007fff5fc1006e in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE ()
> #11 0x00007fff5fc0feba in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE ()
> #12 0x00007fff5fc04e38 in __dyld__ZN4dyld15runInitializersEP11ImageLoader ()
> #13 0x00007fff5fc0a87c in __dyld_dlopen ()
> #14 0x00007fff8bd81dd8 in dlopen ()
> #15 0x0000000142f9820f in llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x141328d38 "/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6a0) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/DynamicLibrary.cpp:77
> #16 0x0000000142f79ced in llvm::sys::DynamicLibrary::LoadLibraryPermanently (Filename=0x141328d38 "/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", ErrMsg=0x7fff5fbfe6a0) at DynamicLibrary.h:77
> #17 0x0000000142f79ab9 in llvm::PluginLoader::operator= (this=0x143497418, Filename=@0x7fff5fbfe780) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/PluginLoader.cpp:29
> #18 0x00000001422137de in llvm::cl::opt_storage<llvm::PluginLoader, false, true>::setValue<std::string> (this=0x143497418, V=@0x7fff5fbfe780, initial=false) at CommandLine.h:1072
> #19 0x0000000142213271 in llvm::cl::opt<llvm::PluginLoader, false, llvm::cl::parser<std::string> >::handleOccurrence (this=0x1434973e0, pos=2, ArgName={Data = 0x1413259f1 "load=/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 4, static npos = 18446744073709551615}, Arg={Data = 0x1413259f6 "/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 63, static npos = 18446744073709551615}) at CommandLine.h:1131
> #20 0x0000000142f5e731 in llvm::cl::Option::addOccurrence (this=0x1434973e0, pos=2, ArgName={Data = 0x1413259f1 "load=/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 4, static npos = 18446744073709551615}, Value={Data = 0x1413259f6 "/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 63, static npos = 18446744073709551615}, MultiArg=false) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/CommandLine.cpp:883
> #21 0x0000000142f635ab in CommaSeparateAndAddOccurence (Handler=0x1434973e0, pos=2, ArgName={Data = 0x1413259f1 "load=/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 4, static npos = 18446744073709551615}, Value={Data = 0x1413259f6 "/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 63, static npos = 18446744073709551615}, MultiArg=false) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/CommandLine.cpp:259
> #22 0x0000000142f5ea31 in ProvideOption (Handler=0x1434973e0, ArgName={Data = 0x1413259f1 "load=/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 4, static npos = 18446744073709551615}, Value={Data = 0x1413259f6 "/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/build/lib/LLVMPolly.so", Length = 63, static npos = 18446744073709551615}, argc=4, argv=0x141325a40, i=@0x7fff5fbfefb0) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/CommandLine.cpp:299
> #23 0x0000000142f5c7d4 in llvm::cl::ParseCommandLineOptions (argc=4, argv=0x141325a40, Overview=0x0) at /sw/src/fink.build/llvm32-3.2-0/llvm-3.2/lib/Support/CommandLine.cpp:724
> #24 0x0000000142209df1 in ConfigureLLVM () at /sw/src/fink.build/dragonegg-gcc47-3.2-0/dragonegg-3.2/src/Backend.cpp:372
> #25 0x0000000142208762 in InitializeBackend () at /sw/src/fink.build/dragonegg-gcc47-3.2-0/dragonegg-3.2/src/Backend.cpp:583
> #26 0x00000001422079a8 in llvm_emit_globals () at /sw/src/fink.build/dragonegg-gcc47-3.2-0/dragonegg-3.2/src/Backend.cpp:1741
> (gdb)
>
> The crash shows up as in the walk as...
>
> (gdb)
> 0x00007fff5fc24182 in __dyld_mach_init ()
> (gdb)
> 0x00007fff5fc01239 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
> (gdb)
> 0x00007fff5fc0123c in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
> (gdb)
> 0x00007fff5fc0123f in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
> (gdb)
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
> 0x00007fff5fc0123f in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
>
> The llvm build is built as a debug build as is the dragonegg build so both have been
> built with -g and are unstripped. I am still very unclear on how I am supposed to
> extract the offending symbol from this log. Since dyld seems to be from reading pch,
> I assume this is a symbol from libstdc++. This would seem odd since cc1 isn't built
> with c++ on gcc 4.7.2 and isn't linked against libstdc++. The dragonegg plugin that
> dlopens the LLVMPolly plugin is built with c+ and linked against libstdc++ but I
> verified that building it with the c compiler to avoid the libstdc++ linkage doesn't
> solve this bug. Thanks in advance for any analysis of the log.
> Jack
Jack,
Do you know about
(gdb) display/i $pc
It will cause gdb to disassemble the next instruction after each single step.
The program goes bad after only 25 instructions:
Breakpoint 1, 0x0000000100ebb5b0 in pch_address_space ()
(gdb) si
0x0000000100ebb5b1 in pch_address_space ()
(gdb)
0x0000000100ebb5b4 in pch_address_space ()
(gdb)
0x0000000100ebb590 in pch_address_space ()
(gdb)
0x0000000100ebb591 in pch_address_space ()
(gdb)
0x0000000100ebb594 in pch_address_space ()
(gdb)
0x0000000100ebb59b in pch_address_space ()
(gdb)
0x0000000100ebad50 in pch_address_space ()
(gdb)
0x0000000100ebad51 in pch_address_space ()
(gdb)
0x0000000100ebad54 in pch_address_space ()
(gdb)
0x0000000100ebad58 in pch_address_space ()
(gdb)
0x0000000100ebad5c in pch_address_space ()
(gdb)
0x0000000100ebad60 in pch_address_space ()
(gdb)
0x0000000100ebb480 in pch_address_space ()
(gdb)
0x0000000100ebb481 in pch_address_space ()
(gdb)
0x0000000100ebb484 in pch_address_space ()
(gdb)
0x0000000100ebb48b in pch_address_space ()
(gdb)
0x0000000100ebb492 in pch_address_space ()
(gdb)
0x0000000100ebb496 in pch_address_space ()
(gdb)
0x0000000100ebb499 in pch_address_space ()
(gdb)
0x0000000100f5f96e in pch_address_space ()
(gdb)
0x0000000100f62356 in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f6235b in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f607d0 in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f607d7 in dyld_stub___cxa_guard_release ()
(gdb)
0x0000000100f607d9 in dyld_stub___cxa_guard_release ()
(gdb)
0x00007fff8bd80878 in dyld_stub_binder ()
The call to dyld_stub_binder already has a bad parameter at this point.
To double check what image is 0x0000000100ebb499 and 0x0000000100f5f96e in ? LLVMPolly.so?
It looks like it is trying to call __cxa_guard_release (at least gdb thinks that). That is odd for the start of an initializer. There should have been a previous call to __cxa_guard_acquire.
For reference, here is stepping through hello-world:
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000100000f00 <main+0>: push %rbp
0x0000000100000f01 <main+1>: mov %rsp,%rbp
0x0000000100000f04 <main+4>: sub $0x10,%rsp
0x0000000100000f08 <main+8>: lea 0x51(%rip),%rdi # 0x100000f60
0x0000000100000f0f <main+15>: movl $0x0,-0x4(%rbp)
0x0000000100000f16 <main+22>: mov $0x0,%al
0x0000000100000f18 <main+24>: callq 0x100000f34 <dyld_stub_printf>
0x0000000100000f1d <main+29>: mov $0x0,%ecx
0x0000000100000f22 <main+34>: mov %eax,-0x8(%rbp)
0x0000000100000f25 <main+37>: mov %ecx,%eax
0x0000000100000f27 <main+39>: add $0x10,%rsp
0x0000000100000f2b <main+43>: pop %rbp
0x0000000100000f2c <main+44>: retq
End of assembler dump.
(gdb) display/i $pc
1: x/i $pc 0x100000f08 <main+8>: lea 0x51(%rip),%rdi # 0x100000f60
(gdb) si
0x0000000100000f0f in main ()
1: x/i $pc 0x100000f0f <main+15>: movl $0x0,-0x4(%rbp)
(gdb)
0x0000000100000f16 in main ()
1: x/i $pc 0x100000f16 <main+22>: mov $0x0,%al
(gdb)
0x0000000100000f18 in main ()
1: x/i $pc 0x100000f18 <main+24>: callq 0x100000f34 <dyld_stub_printf>
(gdb)
0x0000000100000f34 in dyld_stub_printf ()
1: x/i $pc 0x100000f34 <dyld_stub_printf>: jmpq *0x106(%rip) # 0x100001040
(gdb)
0x0000000100000f56 in dyld_stub_printf ()
1: x/i $pc 0x100000f56: pushq $0xc
(gdb)
0x0000000100000f5b in dyld_stub_printf ()
1: x/i $pc 0x100000f5b: jmpq 0x100000f3c
(gdb)
0x0000000100000f3c in dyld_stub_printf ()
1: x/i $pc 0x100000f3c: lea 0xed(%rip),%r11 # 0x100001030
(gdb)
0x0000000100000f43 in dyld_stub_printf ()
1: x/i $pc 0x100000f43: push %r11
(gdb)
0x0000000100000f45 in dyld_stub_printf ()
1: x/i $pc 0x100000f45: jmpq *0xdd(%rip) # 0x100001028
(gdb)
0x00007fff8e2576a0 in dyld_stub_binder ()
1: x/i $pc 0x7fff8e2576a0 <dyld_stub_binder>: push %rbp
(gdb)
The stub (PLT entry) is just a single instruction jump through a pointer ("jmpq *0x106(%rip)"). The first time used, it points to a helper the push extra parameters and jumps into dyld. In this example, the "pushq $0xc" instruction tells dyld which lazy pointer to bind. In your crashing case, the 114808 seems to have been pushed, but that is too big.
-Nick
More information about the llvm-dev
mailing list