Date: Sun, 20 Oct 1996 14:41:45 +0200 (MET DST) From: Greg Lehey <grog@lemis.de> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/1849: gdb handles library breakpoints incorrectly Message-ID: <199610201241.OAA12576@freebie.lemis.de> Resent-Message-ID: <199610201300.GAA14530@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 1849 >Category: bin >Synopsis: gdb sets library breakpoints on the wrong address >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Oct 20 06:00:01 PDT 1996 >Last-Modified: >Originator: Greg Lehey >Organization: LEMIS grog@lemis.de Schellnhausen 2 Tel: +49-6637-919123 36325 Feldatal Fax: +49-6637-919122 Germany >Release: FreeBSD 2.2-CURRENT-ctm-2592 i386 >Environment: FreeBSD 2.2-CURRENT >Description: gdb doesn't set breakpoint addresses correctly for library functions. In a statically linked executable, it sets a breakpoint on the corresponding function in a (presumably non-linked) dynamic library. I consider this problem relatively serious because it makes it very difficult to catch bugs by waiting for them to issue a system call. In this case, the new version of sendmail is calling gethostbyaddr() even though it has been compiled without DNS support. >How-To-Repeat: To be hunted down and shot. I did it with the latest version of sendmail. Here sample output: === root@freebie (/dev/ttyp3) /S/FreeBSD/Mail/sendmail-8.8.2/src -> gdb sendmail (gdb) b gethostbyname Breakpoint 1 at 0x43164 (gdb) b gethostbyaddr Breakpoint 2 at 0x4320a (gdb) b write Breakpoint 3 at 0x5ce88 (gdb) b read Breakpoint 4 at 0x5cec8 (gdb) b main Breakpoint 5 at 0x13ce9: file main.c, line 128. (gdb) b socket Breakpoint 6 at 0x50fb8 (gdb) b sendto Breakpoint 7 at 0x52ff8 (gdb) r -bD -q10m Starting program: /S/FreeBSD/Mail/sendmail-8.8.2/src/sendmail -bD -q10m During symbol reading...unknown symbol type 0x1e...Breakpoint 1 at 0x80b0285 Breakpoint 2 at 0x80b035e Breakpoint 3 at 0x80d0914 Breakpoint 4 at 0x80d0974 Breakpoint 6 at 0x80bfd24 Breakpoint 7 at 0x80c1fe4 Breakpoint 5, main (argc=3, argv=0xefbfd344, envp=0xefbfd354) at main.c:128 128 bool queuemode = FALSE; /* process queue requests */ (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x5ceb5 in select () (gdb) bt #0 0x5ceb5 in select () #1 0x4d02c in res_send () #2 0x4a127 in res_query () #3 0x44490 in _gethostbydnsaddr () #4 0x43260 in gethostbyaddr () #5 0x66e2 in load_if_names () at conf.c:4069 #6 0x147f2 in main (argc=3, argv=0xefbfd344, envp=0xefbfd354) at main.c:482 (gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y 0x080b0285 <gethostbyname+17> 2 breakpoint keep y 0x080b035e <gethostbyaddr+18> 3 breakpoint keep y 0x080d0914 <write> 4 breakpoint keep y 0x080d0974 <read> 5 breakpoint keep y 0x00013ce9 in main at main.c:128 breakpoint already hit 1 times 6 breakpoint keep y 0x080bfd24 <socket> 7 breakpoint keep y 0x080c1fe4 <sendto> (gdb) Comments: At first this looks like a problem with ptrace() or whatever substitutes for it in the procfs, but if you look at the addresses carefully you'll notice that the breakpoint on gethostbyaddr is at address 0x080b035e, but the copy of gethostbyaddr in the stack trace is at address 0x43260. I'm guessing that the first address is a dynamic library address, though it's not clear why gdb should find this in a statically linked executable. The same appears to be the case for the breakpoints on socket() and sendto(). Further information: Here's the memory map of the gdb process and the sendmail process, in case they're of any use: === root@freebie (/dev/ttyp5) /usr/home/grog -> ps aux|grep sendmail root 11722 0.0 8.9 2840 2708 p3 I 12:11PM 0:01.40 emacs /etc/sendmail.cf root 12129 0.0 2.6 2092 780 p3 I+ 1:36PM 0:00.93 gdb sendmail root 12136 0.0 1.1 672 320 p3 TX 1:47PM 0:00.08 /S/FreeBSD/Mail/sendmail-8.8.2/src/sendmail -bD -q10m === root@freebie (/dev/ttyp5) /usr/home/grog -> cat /proc/12129/map 0x1000 0x9a000 22 0 r-x COW vnode 0x9a000 0xa2000 1 4 rwx COW vnode 0xa2000 0x1ec000 44 300 rwx COW default 0x809a000 0x80a7000 9 0 r-x COW vnode 0x80a7000 0x80a9000 2 2 rw- COW vnode 0x80a9000 0x80b0000 7 7 rw- COW swap 0x80b3000 0x80cb000 18 0 r-x COW vnode 0x80cb000 0x80cf000 4 4 rwx COW vnode 0x80cf000 0x80d2000 3 0 r-x COW vnode 0x80d2000 0x80d3000 1 1 rwx COW vnode 0x80d3000 0x80da000 2 0 r-x COW vnode 0x80da000 0x80db000 0 1 rwx COW vnode 0x80db000 0x8133000 72 0 r-x COW vnode 0x8133000 0x8137000 3 2 rwx COW vnode 0x8137000 0x8144000 0 2 rwx COW swap 0x8144000 0x814e000 0 7 rw- COW swap 0xefbde000 0xefbfe000 4 5 rwx COW default === root@freebie (/dev/ttyp5) /usr/home/grog -> cat /proc/12136/map 0x1000 0x2000 0 1 r-x COW vnode 0x2000 0x13000 0 0 r-x COW vnode 0x13000 0x14000 0 1 r-x COW vnode 0x14000 0x6b000 0 0 r-x COW vnode 0x6b000 0x6f000 0 4 rwx COW vnode 0x6f000 0x89000 0 22 rwx default 0x806b000 0x8078000 7 0 r-x COW vnode 0x8078000 0x807a000 0 2 rw- COW vnode 0x807a000 0x8082000 0 7 rw- swap 0x8082000 0x8083000 0 1 rw- swap 0x8084000 0x80dc000 71 0 r-x COW vnode 0x80dc000 0x80e0000 0 0 rwx COW vnode 0x80e0000 0x80ed000 0 0 rwx swap 0x80ed000 0x80f7000 0 4 rw- swap 0xefbde000 0xefbfe000 0 4 rwx default >Fix: None known. >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610201241.OAA12576>