Return to BSD News archive
Xref: sserve comp.bugs.4bsd:1939 comp.os.386bsd.bugs:542 Newsgroups: comp.bugs.4bsd,comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!uunet!pipex!uknet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: flock broken - I could use some help Message-ID: <1993Apr23.071135.28560@cs.few.eur.nl> Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam References: <C5t8wH.Hs@moxie.hou.tx.us> <1993Apr21.184636.1121@cs.few.eur.nl> <1993Apr22.183734.4448@wotan.compaq.com> Date: Fri, 23 Apr 1993 07:11:35 GMT Lines: 20 In <1993Apr22.183734.4448@wotan.compaq.com> hackney@wotan.compaq.com (Greg Hackney) writes: >> The problem is a dangling pointer left in the lockf structure belonging to >> the current lock holder. >> ------- ufs_lockf.c ------- >> *** /tmp/da16367 Wed Apr 21 20:36:22 1993 >> --- ufs/ufs_lockf.c Wed Apr 21 20:35:47 1993 >I applied your code fragment to ufs_lockf.c. However it didn't solve the >problem, as my system still panics and reboots using the aforementioned >test code. I'm pretty sure the problem is in that area though. Now, my proposed patch may be faulty and cause panics of its own. I suggest you have a look at a kernel stack trace (option DDB) at the time of the panic. I recommend applying the changes to the DDB module that display source line numbers, it makes life so much easier. -pk