Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!lanl!newshost.lanl.gov!russo From: russo@lanl.gov (Thomas Russo) Subject: Interesting cause of kernel panic. Message-ID: <RUSSO.93Mar19100825@bogon.lanl.gov> Summary: two processes executing same mv command simultaneously causes panic Sender: news@newshost.lanl.gov Organization: Theoretical Chemistry and Molecular Modeling Group, LANL, NM Date: Fri, 19 Mar 1993 17:08:25 GMT Lines: 49 Just last night I discovered what was causing my 386bsd kernel to panic just about every OTHER time I logged in through xdm. I'd love to poke around in the kernel to find out why it's doing what it's doing, but I don't know what tools one uses to debug kernels (as one might use adb -k on other platforms). Anyone who wishes to expend the time making suggestions via email is invited to do so, but barring that I'll just tell you all what was doing it, and someone with kernel debugging experience and time to spare can take a look. I started using procmail on my pc to sort my incoming mail several weeks ago, and procmail logs part of the header for each piece of mail that comes in. In order to prevent it from growing without bound I used to put the following in my .bashrc: if [ -f ~/Mail/from ]; then mv ~/Mail/from ~/Mail/from~ fi But when I log in through xdm my .xsession starts up 2 xterms, each of which runs the above code. On most platforms this is ok, as one of two things happens (I've used procmail on other systems for at least a year now): 1) the two login shells try to execute the if at differenttimes, and only one of the tests returns true. 2) the two login shells try to execute the if at the same time, both getting true for [ -f ... ], one of them succeeds in doing the mv, the other prints an error "file not found" or some such. But guess what my 386 does? Yup, kernel panic: trap. The reason it only happens ever other time should be clear -- the mv is already done, so [ -f ~/Mail/from ] returns false and everything is copesetic. Removing the offending test from my .bashrc ends the frustrating kernel panics. So, how would I go about tracking down why this happens? Is this a problem with locking in the kernel, so that the two mv's are trying to tweak the same inode at the same time? Or what? Has anyone else ever seen this kind of thing happen? In general what sort of tools can one use to examine the core dumps that appear in /var/crash after a panic? -- Thomas Russo russo@bogon.lanl.gov Los Alamos National Lab, T-12, Theoretical Chemistry and Molecular Physics *Opinions expressed are those of the author alone and do not represent *positions or policies of Los Alamos National Laboratory or the University *of California --------