home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18178 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.6 KB  |  59 lines
  1. Newsgroups: comp.os.vms
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!darwin.sura.net!haven.umd.edu!decuac!pa.dec.com!e2big.mko.dec.com!nntpd.lkg.dec.com!virrus.zko.dec.com!diewald
  3. From: diewald@virrus.zko.dec.com (Jeff Diewald)
  4. Subject: Re: sys$hiber/sys$wake problems? - SUMMARY
  5. Message-ID: <1992Nov18.144244.13282@nntpd.lkg.dec.com>
  6. Lines: 46
  7. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  8. Reply-To: diewald@virrus.zko.dec.com (Jeff Diewald)
  9. Organization: Digital Equipment Corporation
  10. References: <BxIAFn.2p6@unx.sas.com> <1992Nov10.180054.23127@fripp.ri.cadre.com> <BxIrqM.2pF@unx.sas.com> <1992Nov11.003646.249@rlgsc.com> <Bxnt96.8oJ@unx.sas.com>
  11. Date: Wed, 18 Nov 1992 14:42:44 GMT
  12.  
  13.  
  14. In article <Bxnt96.8oJ@unx.sas.com>, sasjzs@falcon.unx.sas.com (Joseph Slater) writes:
  15. |>I determined the spurious $wake was not coming from the PPL
  16. |>rtl by patching the rtl so that any calls to $wake from 
  17. |>within the rtl went to a stub routine in my main image. The
  18. |>stub routine then called Lib$signal with SS$_DEBUG where the 
  19. |>call frame was traced and it afterwards called the real 
  20. |>sys$wake. No calls were made from pplrtl (isn't patch wonderful?). 
  21. |>I then looked at the other shareable images loaded and
  22. |>determined that the most likely culprit was.... (drum roll)
  23. |>THE DEBUGGER.
  24. |>
  25. |>And sure enough, the problem doesn't occur when the debugger
  26. |>isn't active. 
  27. |>
  28. |>As many of you suggested, we will eventually add code to check
  29. |>the state on exit from $hiber and to re-hiber if we get awakened
  30. |>prematurely.
  31. |>
  32. |>Today's rhetorical question: How do you debug a problem caused
  33. |>by the debugger? 
  34.  
  35. This is a known, documented problem in the Debugger, described in the 
  36. Debugger release notes.  Debug uses $hiber/$wake to synchronize the Debugger 
  37. main process (all the UI + symbolization code + other things) and the process 
  38. being debugged.
  39.  
  40. Now - there is an option.  Define DBG$PROCESS as "NONE".  This forces the
  41. Debugger main to live in the same process as the program being debugged.
  42. It also eliminates the use of $HIBER/$WAKE in the Debugger.  
  43.  
  44. This has its drawbacks though.  There are features that are not supported
  45. under the one process Debugger - such as the new and vastly improved Motif
  46. UI. 
  47.  
  48. Using a different synchronization mechanism in the Debugger to avoid this
  49. problem is on our list of things to do, although I don't know when we'll get
  50. to it. 
  51.  
  52. Finally - to "answer" your rhetorical question - we use the Debugger to debug
  53. itself.  ;-)
  54.  
  55. -------------------------------------------------------------------------------
  56.     Jeff Diewald            EASYNET:   VIRRUS::DIEWALD
  57.     Debug group            INTERNET:  diewald@virrus.zko.dec.com
  58.     Digital Equipment Corp.
  59.