home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / bsd / 5138 < prev    next >
Encoding:
Text File  |  1992-09-04  |  3.1 KB  |  65 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!news.byu.edu!ux1!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe.Eng.Sandy.Novell.COM!terry
  3. From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
  4. Subject: Re: GDB under 386bsd 0.1
  5. Message-ID: <1992Sep4.175818.1691@gateway.novell.com>
  6. Keywords: gdb, ptrace
  7. Sender: news@gateway.novell.com (NetNews)
  8. Nntp-Posting-Host: thisbe.eng.sandy.novell.com
  9. Organization: Novell NPD -- Sandy, UT
  10. References: <1992Sep4.005417.3876@gumby.dsd.trw.com>
  11. Date: Fri, 4 Sep 1992 17:58:18 GMT
  12. Lines: 51
  13.  
  14. In article <1992Sep4.005417.3876@gumby.dsd.trw.com> gottloeb@eel.dsd.trw.com writes:
  15. >I have noticed a problem using gdb under 386bsd 0.1.
  16. >
  17. >When at least one breakpoint has been set and the program terminates,
  18. >e.g. executes exit(), the breakpoint is not removed from the process's
  19. >text image.  When the program is subsequently re-executed under gdb,
  20. >gdb remembers that a breakpoint is supposed to at the memory location
  21. >and puts one there again.  However this time it shadows the breakpoint
  22. >instruction from the previous run rather than the original instruction.
  23. >When execution begins after reaching the breakpoint, various traps occur.
  24. >
  25. >If the program is run after quitting gdb, a Trace/BPT trap occurs.
  26. >
  27. >I think the problem is that gdb assumes that when ptrace modifies the
  28. >process's image the kernel either makes a private copy of the text image
  29. >or it will throw away the text image after the process terminates.
  30. >However, this is not the case - the kernel keeps the modified text image
  31. >around and executes it rather than a fresh copy from the original file.
  32. [ ... ]
  33. >Does anybody have a fix or any suggestions on how to fix this?
  34.  
  35.     This is a long standing bug in memory management, which (I thought)
  36. was resolved in BSD 4.2.  The problem is that text pages are not marked
  37. dirty on write; thus the remain shared.
  38.  
  39.     An extremely graphic demonstration of this can be had by using
  40. gdb on "su".  Patch the "su" image to start a shell without asking for
  41. a password.  Leave the debugger running.  Type "su" on another terminal:
  42. voila!  root!
  43.  
  44.     This is a serious issue to be addressed.  The fix is basically
  45. to disallow use of text pages which have been marked dirty, and to force
  46. a reload of the instance of the text page.  Since I am not sure whether
  47. provision has been made for multiple instances of text pages representing
  48. the same file blocks to be in core simultaneously, nor whether marking
  49. the pages dirty would result in their being erroneously written to disk,
  50. I am unsure as to the approach you would want to take to fix it.  Any
  51. fix should still allow for sharing of text pages.  If I "debug" vi,
  52. and write one of it's text pages, and there are two other users of vi,
  53. the two users should be sharing a single copy and I should have my own.
  54. Any other soloution will negatively impact our ability to support shared
  55. libraries in the future (one of my pet projects 8-).
  56.  
  57.  
  58.                     Terry Lambert
  59.                     terry_lambert@gateway.novell.com
  60.                     terry@icarus.weber.edu
  61.  
  62. ---
  63. Disclaimer:  Any opinions in this posting are my own and not those of
  64. my present or previous employers.
  65.