home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / unix / ultrix / 8948 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.6 KB  |  77 lines
  1. Path: sparky!uunet!pipex!warwick!uknet!comlab.ox.ac.uk!mbeattie
  2. From: mbeattie@black.ox.ac.uk (Malcolm Beattie)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: Segmentation fault when listing all processes
  5. Message-ID: <1992Dec18.115557.6607@black.ox.ac.uk>
  6. Date: 18 Dec 92 11:55:57 GMT
  7. References: <1992Dec17.085159.7728@imec.be> <1992Dec17.101316.10127@dcs.warwick.ac.uk>
  8. Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, U
  9. Lines: 65
  10. Originator: mbeattie@black
  11.  
  12. In article <1992Dec17.101316.10127@dcs.warwick.ac.uk> rince@dcs.warwick.ac.uk (James Bonfield) writes:
  13. >In <1992Dec17.085159.7728@imec.be> elsen@imec.be (Marc  Elsen) writes:
  14. >y
  15. >
  16. >> 
  17. >>  - In VAX Ultrix 4.2 on a 3900 I sometimes (intermittent) get
  18. >>  
  19. >>    % ps aux
  20. >>    Segmentation fault
  21. >> 
  22. >>   Has anyone seen this before ?
  23. >
  24. >I've seen the problem (and posted it here) before on A Dec5000/240 running
  25. >Ultrix 4.2. It's possible to force the problem too. Imagine the following
  26. >scenario:
  27. >
  28. >jkb@rutland[home3/jkb]& cat a.c
  29. >main() {
  30. >    vfork();
  31. >    pause();
  32. >}
  33. >jkb@rutland[home3/jkb]& ps
  34. >  PID TT STAT   TIME COMMAND
  35. >[ fairly long process list ommited ]
  36. >jkb@rutland[home3/jkb]& cc a.c
  37. >jkb@rutland[home3/jkb]& ./a.out &
  38. >[1] 13671
  39. >jkb@rutland[home3/jkb]& ps
  40. >  PID TT STAT   TIME COMMAND
  41. >Segmentation fault
  42. >jkb@rutland[home3/jkb]& kill %1
  43. >[1]+  Terminated              ./a.out
  44. >jkb@rutland[home3/jkb]& ps
  45. >  PID TT STAT   TIME COMMAND
  46. >[ working process list once more ]
  47. >jkb@rutland[home3/jkb]& 
  48. >
  49. >    Unfortunately I do not know of any solution. The problem you have
  50. >could easily be the same. If, intermittently, other users create processes of
  51. >the same type, and you try to examine their processes using 'ps aux'. I'm not
  52. >sure precisely which status the process is in that causes ps to die. There are
  53. >other processes (eg pagedaemon) in disk wait (D).
  54. >
  55. >
  56. >-- 
  57. >James Bonfield (jkb@mrc-lmba.cam.ac.uk / rince@dcs.warwick.ac.uk)
  58. >Medical Research Council Laboratory of Molecular Biology, Hills Road,
  59. >Cambridge, CB2 2QH, England. Tel: 0223 402499   Fax: 0223 412282
  60.  
  61. Here's a problem with ps that I occasionally see on our
  62. DEC 5500, Ultrix 4.2: an error message of the form
  63.  
  64. ps: cant read u for pid 12345 from /dev/drum
  65.  
  66. sometimes appears, seemingly while file system intensive
  67. processes are running. Is this something that I should
  68. worry about?
  69.  
  70. --Malcolm
  71.  
  72. -- 
  73. Malcolm Beattie <mbeattie@black.ox.ac.uk> | I'm not a kernel hacker
  74. Oxford University Computing Services      | I'm a kernel hacker's mate
  75. 13 Banbury Road, Oxford, OX2 6NN (U.K.)   | And I'm only hacking kernels
  76. Tel: +44 865 273232 Fax: +44 865 273275   | 'Cos the kernel hacker's late
  77.