Hi,
How exactly do you resolve the symbols with crashes caused by software compiled with FORTIFY_SOURCE=2?
I'm seeing a crash in xsupplicant (from extras) and would like to get it fixed, but as the program is halted by glibc/kernel, I can't run gdb on it to backtrace and to get the symbols. Installing debuginfo doesn't help; debuginfo can be used to find the symbols manually (w/ objdump) but doing so would be a lot of work though.
I googled around quite a bit but couldn't find any automation or help (akin to old 'ksymoops') in decoding the numbers. There's very probably something, but I just can't find it. Or if there isn't, we should certainly merge it.
Any pointers?
................ [root@dhcp-142 tmp]# *** buffer overflow detected ***: xsupplicant terminated ======= Backtrace: ========= /lib/libc.so.6(__chk_fail+0x41)[0xa43c45] xsupplicant[0x8069a77] xsupplicant[0x806a189] xsupplicant[0x806a641] xsupplicant[0x806a6e6] xsupplicant[0x806a84e] xsupplicant[0x806bdfa] xsupplicant[0x804b0bd] xsupplicant[0x804b243] /lib/libc.so.6(__libc_start_main+0xdf)[0x97ad5f] xsupplicant[0x804a7d1] ======= Memory map: ======== 004cb000-004da000 r-xp 00000000 03:01 64194 /lib/libresolv-2.3.5.so 004da000-004db000 r-xp 0000e000 03:01 64194 /lib/libresolv-2.3.5.so 004db000-004dc000 rwxp 0000f000 03:01 64194 /lib/libresolv-2.3.5.so 004dc000-004de000 rwxp 004dc000 00:00 0 004e0000-004e2000 r-xp 00000000 03:01 68214 /lib/libcom_err.so.2.1 004e2000-004e3000 rwxp 00001000 03:01 68214 /lib/libcom_err.so.2.1 004e5000-004fc000 r-xp 00000000 03:01 187614 /usr/lib/libgssapi_krb5.so.2.2 004fc000-004fd000 rwxp 00017000 03:01 187614 /usr/lib/libgssapi_krb5.so.2.2 004ff000-0056e000 r-xp 00000000 03:01 187613 /usr/lib/libkrb5.so.3.2 0056e000-00571000 rwxp 0006e000 03:01 187613 /usr/lib/libkrb5.so.3.2 00573000-00596000 r-xp 00000000 03:01 187612 /usr/lib/libk5crypto.so.3.0 00596000-00597000 rwxp 00023000 03:01 187612 /usr/lib/libk5crypto.so.3.0 00599000-0059b000 r-xp 00000000 03:01 180990 /usr/lib/libkrb5support.so.0.0 0059b000-0059c000 rwxp 00001000 03:01 180990 /usr/lib/libkrb5support.so.0.0 0059e000-005d3000 r-xp 00000000 03:01 68216 /lib/libssl.so.0.9.7f 005d3000-005d6000 rwxp 00035000 03:01 68216 /lib/libssl.so.0.9.7f 005d8000-006d0000 r-xp 00000000 03:01 68215 /lib/libcrypto.so.0.9.7f 006d0000-006e2000 rwxp 000f8000 03:01 68215 /lib/libcrypto.so.0.9.7f 006e2000-006e5000 rwxp 006e2000 00:00 0 006f2000-006fb000 r-xp 00000000 03:01 68212 /lib/libgcc_s-4.0.1-20050727.so.1 006fb000-006fc000 rwxp 00009000 03:01 68212 /lib/libgcc_s-4.0.1-20050727.so.1 00948000-00962000 r-xp 00000000 03:01 68207 /lib/ld-2.3.5.so 00962000-00963000 r-xp 00019000 03:01 68207 /lib/ld-2.3.5.so 00963000-00964000 rwxp 0001a000 03:01 68207 /lib/ld-2.3.5.so 00966000-00a89000 r-xp 00000000 03:01 68208 /lib/libc-2.3.5.so 00a89000-00a8b000 r-xp 00123000 03:01 68208 /lib/libc-2.3.5.so 00a8b000-00a8d000 rwxp 00125000 03:01 68208 /lib/libc-2.3.5.so 00a8d000-00a8f000 rwxp 00a8d000 00:00 0 00ab8000-00aba000 r-xp 00000000 03:01 68210 /lib/libdl-2.3.5.so 00aba000-00abb000 r-xp 00001000 03:01 68210 /lib/libdl-2.3.5.so 00abb000-00abc000 rwxp 00002000 03:01 68210 /lib/libdl-2.3.5.so 00abe000-00ad0000 r-xp 00000000 03:01 173735 /usr/lib/libz.so.1.2.2.2 00ad0000-00ad1000 rwxp 00011000 03:01 173735 /usr/lib/libz.so.1.2.2.2 00fc0000-00fc1000 r-xp 00fc0000 00:00 0 [vdso] 08048000-08083000 r-xp 00000000 03:01 175223 /usr/sbin/xsupplicant 08083000-08084000 rw-p 0003b000 03:01 175223 /usr/sbin/xsupplicant 08084000-08085000 rw-p 08084000 00:00 0 09738000-09759000 rw-p 09738000 00:00 0 [heap] b7fba000-b7fbe000 rw-p b7fba000 00:00 0 b7fc9000-b7fcc000 rw-p b7fc9000 00:00 0 bfab7000-bfacc000 rw-p bfab7000 00:00 0 [stack]
On Mon, 2005-11-07 at 01:20 +0200, Pekka Savola wrote:
Hi,
How exactly do you resolve the symbols with crashes caused by software compiled with FORTIFY_SOURCE=2?
I'm seeing a crash in xsupplicant (from extras) and would like to get it fixed, but as the program is halted by glibc/kernel, I can't run gdb on it to backtrace and to get the symbols. Installing debuginfo doesn't help; debuginfo can be used to find the symbols manually (w/ objdump) but doing so would be a lot of work though.
I googled around quite a bit but couldn't find any automation or help (akin to old 'ksymoops') in decoding the numbers. There's very probably something, but I just can't find it. Or if there isn't, we should certainly merge it.
Any pointers?
IIRC, there was a proposed patch to glibc which would make the backtrace functions use DWARF line number information (if available) instead of the ELF symbol table, but the glibc maintainer rejected it.
So, put a breakpoint on __chk_fail and then run xsupplicant or else just look at the core dump.
On Sun, 6 Nov 2005, Nicholas Miell wrote:
IIRC, there was a proposed patch to glibc which would make the backtrace functions use DWARF line number information (if available) instead of the ELF symbol table, but the glibc maintainer rejected it.
So, put a breakpoint on __chk_fail and then run xsupplicant or else just look at the core dump.
Thanks. (Brown paper bag) due to the message (no mention of core dump), I didn't even realize it was dumping core; gdb debugged the problem quite nicely.