Re: loading binary prevent segfault on dl-load. #15535

[Ilya Plenne <libbkmz dot dev at gmail dot com>]

Sorry, this is my first experience of using mailing lists. I, forgot
to add libc-help@sourceware.org to cc. And fixing this in this email.

On 11 June 2013 23:41, Ilya Plenne <libbkmz.dev@gmail.com> wrote:
> I'm start with core dumps, because glibc compiling or rust compiling
> take a lot of time to be proceed.
>
> Now, I'm enable core files and run gdb with given core file
> core.ld-linux.so.2.4589
> startup output of gdb:
> Reading symbols from /usr/bin/rust...(no debugging symbols found)...done.
>
> warning: core file may not match specified executable file.
> [New LWP 4589]
>
> warning: Could not load shared library symbols for linux-gate.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> Core was generated by `./elf/ld-linux.so.2 --library-path
> .:./math:./elf:./dlfcn:./nss:./nis:./rt:./re'.
> Program terminated with signal 11, Segmentation fault.
> #0  open_verify (name=<optimized out>, name@entry=0xb76e4136 <Address
> 0xb76e4136 out of bounds>, fbp=fbp@entry=0xbfdde01c,
>     loader=0xb771b950, whatcode=whatcode@entry=8,
> found_other_class=found_other_class@entry=0xbfdde013,
>     free_name=free_name@entry=false) at dl-load.c:1876
> 1876                    __lseek (fd, ph->p_offset, SEEK_SET);
> (gdb) info sharedlibrary
> From        To          Syms Read   Shared Object Library
> 0xb76fa860  0xb771281c  Yes         ./elf/ld-linux.so.2
>                         No          linux-gate.so.1
> (gdb) bt
> #0  open_verify (name=<optimized out>, name@entry=0xb76e4136 <Address
> 0xb76e4136 out of bounds>, fbp=fbp@entry=0xbfdde01c,
>     loader=0xb771b950, whatcode=whatcode@entry=8,
> found_other_class=found_other_class@entry=0xbfdde013,
>     free_name=free_name@entry=false) at dl-load.c:1876
> #1  0xb770241e in _dl_map_object (loader=0xb771b950, name=0x80483a9
> "libstd-c3ca5d77d81b46c1-0.7-pre.so", type=1,
>     trace_mode=trace_mode@entry=0, mode=0, nsid=0) at dl-load.c:2270
> #2  0xb7706870 in openaux (a=0xbfdde3e8) at dl-deps.c:63
> #3  0xb7708afa in _dl_catch_error (objname=objname@entry=0xbfdde3e4,
> errstring=errstring@entry=0xbfdde3e0,
>     mallocedp=mallocedp@entry=0xbfdde3df,
> operate=operate@entry=0xb7706830 <openaux>,
> args=args@entry=0xbfdde3e8)
>     at dl-error.c:177
> #4  0xb7706a5c in _dl_map_object_deps (map=map@entry=0xb771b950,
> preloads=preloads@entry=0x0, npreloads=npreloads@entry=0,
>     trace_mode=<optimized out>, open_mode=<optimized out>,
> open_mode@entry=0) at dl-deps.c:254
> #5  0xb76fcc72 in dl_main (phdr=<optimized out>, phnum=<optimized
> out>, user_entry=0xbfdde53c, auxv=0xbfdde654)
>     at rtld.c:1738
> #6  0xb770ee47 in _dl_sysdep_start
> (start_argptr=start_argptr@entry=0xbfdde5d0,
> dl_main=dl_main@entry=0xb76fb5e0 <dl_main>)
>     at ../elf/dl-sysdep.c:246
> #7  0xb76fe99b in _dl_start_final (arg=0xbfdde5d0) at rtld.c:331
> #8  _dl_start (arg=<optimized out>) at rtld.c:557
> #9  0xb76fb057 in _start () from ./elf/ld-linux.so.2
>
> rust - is not a usual binary, it's a programming language, and when i
> try to compile it on this machine i get the same segfault on the first
> stage, when it try link files. Like so, I do not remember exactly.
> That was so long ago.
>
>
> PS: Sorry for my english
>
> On 11 June 2013 22:07, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 06/11/2013 07:40 AM, Ilya Plenne wrote:
>>> I'm compiled by the given manual glibc from git. And now i'm tested
>>> rust binary. And get the same error:
>>>
>>> [bkmz@localhost glibc-build]$ ./testrun.sh /usr/bin/rust
>>> Segmentation fault (core dumped)
>>>
>>> How can I run gdb under this glibc to get proper backtrace? So, in the
>>> other hand, error are the same, I don't know what to do. In the ticket
>>> I posted backtrace from arch glibc with debug info.
>>
>> Please keep libc-help@sourceware.org in the CC so others can learn
>> about the problem and the solutions you're working on.
>>
>> You have two ways forward which I would recommend:
>>
>> (a) Turn on core files.
>> - Run your program.
>> - Get a core file.
>> - Debug the core file with gdb.
>> - Double check that `info shared' shows the right libraries from the new build.
>>
>> (b) Follow "Compile against glibc in a fixed location"
>> - Easiest method if you can recompile the target binary.
>> - See the instructions here:
>> http://sourceware.org/glibc/wiki/Testing/Builds#Compile_against_glibc_in_fixed_location
>>
>> Start with one of these first.
>>
>> Cheers,
>> Carlos.