home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / sysv386 / 14302 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  2.0 KB
  1. Path: sparky!uunet!wupost!sdd.hp.com!caen!kuhub.cc.ukans.edu!husc-news.harvard.edu!husc8.harvard.edu!maziere1
  2. Newsgroups: comp.unix.sysv386
  3. Subject: Re: perl 4.035 induces kernel panic in SVR4
  4. Message-ID: <1992Sep10.204557.15522@husc3.harvard.edu>
  5. From: maziere1@husc8.harvard.edu (David Mazieres)
  6. Date: 10 Sep 92 20:45:56 EDT
  7. References: <1992Sep7.002515.15426@husc3.harvard.edu> <jrh.715877574@mustang> <1992Sep9.180635.27817@crd.ge.com>
  8. Organization: Harvard University Science Center
  9. Nntp-Posting-Host: husc8.harvard.edu
  10. Lines: 25
  11.  
  12. In article <1992Sep9.180635.27817@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
  13. >In article <jrh.715877574@mustang>, jrh@mustang.dell.com (Randy Howard) writes:
  14. >| maziere1@husc8.harvard.edu (David Mazieres) writes:
  15. >| 
  16. >| >I'm running Consensys SVR4.0.3.  Perl-4.035 compiled fine with the native
  17. >| >cc (gcc gave problems).  When I do a "make test," however, it gets as far
  18. >| >as comp/for and then the kernel panics.  I'm not even running it as root.
  19. >
  20. >| I have built perl 4.035 here on Dell SVR4, and with gcc I believe.  I 
  21. >| suspect that you may not have answered the configure questions all correctly
  22. >| or something *real* wierd is going on.  I can either send you my build tree
  23. >
  24. >Randy, I hate to disagree, but I don't care how badly he messed up his
  25. >build parameters, if the kernel panics the o/s is at fault, not the
  26. >user or the software.
  27. >
  28.  
  29. Thanks for all the help I've gotten.  In fact, my problem was simply that I
  30. was including libucb before libc.  I changed the library flags to -lc -lucb,
  31. and the new version tested fine.  When I posted I figured I'd probably messed
  32. up the flags somehow--the really disturbing thing is that a non-root user can
  33. bring the whole system down.  I know the ucb library has tons of bugs in it,
  34. but should even the most bizarely warped and misused system calls panic the
  35. kernel?  (i.e. not should as in is this a good thing, but should as in have
  36. other people been able to crash their SVR4 kernels reproducibly)
  37.