Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!network.ucsd.edu!swrinde!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe.Eng.Sandy.Novell.COM!terry From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) Newsgroups: comp.unix.bsd Subject: Re: GDB under 386bsd 0.1 Keywords: gdb, ptrace Message-ID: <1992Sep4.175818.1691@gateway.novell.com> Date: 4 Sep 92 17:58:18 GMT References: <1992Sep4.005417.3876@gumby.dsd.trw.com> Sender: news@gateway.novell.com (NetNews) Organization: Novell NPD -- Sandy, UT Lines: 51 Nntp-Posting-Host: thisbe.eng.sandy.novell.com In article <1992Sep4.005417.3876@gumby.dsd.trw.com> gottloeb@eel.dsd.trw.com writes: >I have noticed a problem using gdb under 386bsd 0.1. > >When at least one breakpoint has been set and the program terminates, >e.g. executes exit(), the breakpoint is not removed from the process's >text image. When the program is subsequently re-executed under gdb, >gdb remembers that a breakpoint is supposed to at the memory location >and puts one there again. However this time it shadows the breakpoint >instruction from the previous run rather than the original instruction. >When execution begins after reaching the breakpoint, various traps occur. > >If the program is run after quitting gdb, a Trace/BPT trap occurs. > >I think the problem is that gdb assumes that when ptrace modifies the >process's image the kernel either makes a private copy of the text image >or it will throw away the text image after the process terminates. >However, this is not the case - the kernel keeps the modified text image >around and executes it rather than a fresh copy from the original file. [ ... ] >Does anybody have a fix or any suggestions on how to fix this? This is a long standing bug in memory management, which (I thought) was resolved in BSD 4.2. The problem is that text pages are not marked dirty on write; thus the remain shared. An extremely graphic demonstration of this can be had by using gdb on "su". Patch the "su" image to start a shell without asking for a password. Leave the debugger running. Type "su" on another terminal: voila! root! This is a serious issue to be addressed. The fix is basically to disallow use of text pages which have been marked dirty, and to force a reload of the instance of the text page. Since I am not sure whether provision has been made for multiple instances of text pages representing the same file blocks to be in core simultaneously, nor whether marking the pages dirty would result in their being erroneously written to disk, I am unsure as to the approach you would want to take to fix it. Any fix should still allow for sharing of text pages. If I "debug" vi, and write one of it's text pages, and there are two other users of vi, the two users should be sharing a single copy and I should have my own. Any other soloution will negatively impact our ability to support shared libraries in the future (one of my pet projects 8-). Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.