This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Undefined symbol


Segmentation fault (core dumped)

Okay, that's confusing.  Please install relevant debugging information
and re-run the test case under valgrind, with and without LD_BIND_NOW.
Maybe this way, we'll obtain additional information.

Indeed. Got libc6 with debug info, my program itself is also compiled with debug info. Without LD_BIND_NOW valgrind reports no issues (except it prints the symbol fail issue). With it it fails with:

==3088== Memcheck, a memory error detector
==3088== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3088== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==3088== Command: ./ConsoleApplication347
==3088==
==3088== Jump to the invalid address stated on the next line
==3088==    at 0x0: ???
==3088==    by 0x26A9B8: ??? (in /mnt2/root/mkie/ConsoleApplication347)
==3088==    by 0xFFF000567: ???
==3088==    by 0x1B: ???
==3088==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==3088==
==3088==
==3088== Process terminating with default action of signal 11 (SIGSEGV)
==3088==  Bad permissions for mapped region at address 0x0
==3088==    at 0x0: ???
==3088==    by 0x26A9B8: ??? (in /mnt2/root/mkie/ConsoleApplication347)
==3088==    by 0xFFF000567: ???
==3088==    by 0x1B: ???
==3088==
==3088== HEAP SUMMARY:
==3088==     in use at exit: 0 bytes in 0 blocks
==3088==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==3088==
==3088== All heap blocks were freed -- no leaks are possible
==3088==
==3088== For counts of detected and suppressed errors, rerun with: -v
==3088== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

The call it fails at is _start, specifically:
callq  __libc_start_main@PLT

from gdb it looks like:
0x000000000026a9b4 <+36>: callq 0x26e860 <pthread_mutex_timedlock@plt+16>
Goes here:
=> 0x000000000026e860 <+16>:    jmpq   *0xd72(%rip)        # 0x26f5d8
Goes to 0x0000000 (LD_BIND_NOW=1)

so it's like in mode LD_BIND_NOW=1 the plt jump table is somehow empty.

Without LD_BIND_NOW=1 the jmpq jumps over itself and calls what seems to be symbol loading code, fails with an error, either way it never seems to go into libc_start_main.
--
Carlo Kok
RemObjects Software


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]