Date: Tue, 8 Oct 2002 10:47:26 GMT From: Arne Woerner <woerner@mediabase-gmbh.de> To: dot@dotat.at, iedowse@maths.tcd.ie Cc: bug-followup@FreeBSD.org, fanf@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/43739: cannot open file without obvious reason Message-ID: <200210081047.g98AlQd4001499@gargano.local.mediabase-gmbh.de>
next in thread | raw e-mail | index | archive | help
> Please would you provide us with the information I have asked for. > I am not asking for it in order to insult you -- I am trying to help > you and I am asking for it because analysing a problem with insufficient > information is hard. > As long as you do not understand that there are only two ICanDo instances active at each point of time in my setting, every further information is futile. I thought it is necessary to reproduce the bug so I did not give so many additional information but only exact hints on the reproduction procedure (which is obviously not minimal). > Also, the output from `sysctl kern.maxfiles` would be useful -- you're > using small-memory machines so I would expect the number to be quite low. > (It would have been useful to know that earlier.) > 80MB is not so small in my opinion but my CO just told me that 512MB is normal nowadays... The value for kern.maxfiles is somewhat over 1200 pieces (but obviously this value cannot be responsible because it works twice and 10 times and 70 times but not 80 times which shows clearly that we have some unwanted residues in the kernel)... > > IT IS THE "LOCKF"! > > While the lockf blocks the session will not terminate. And a new > > session can only be started as soon as the old session terminates. > > See: > > ( repeat 1000000000 ssh cyclops ./ICanDo.sh ) < /dev/null & > > > > I wonder why you both are reading my emails if you do not want to > > understand them. I do not spend my time writing bug reports just for > > your amusement or to allow you to insult me. > > Nobody is trying to insult you, > I hope so. I have heard before that I think too early that somebody spits on me or hates me although I like him and although he only wants to help. > but we do need to ask a few questions > I really thought that my information was exact enough (the real source code and the symptom). I am astonished that there are so ridiculous theories about my source code among experts like you... > to verify the problem, as we get many bogus problem reports that > turn out to be misunderstandings or user errors. > Yes, I know. I wrote one myself some days ago because I thought the 'ls' implementation is buggy on large files (but in fact the 'ext2fs' implementation in OpenBSD 3.1 was responsible for the problem...). (I wrote some followups in the meantime so you could close this report now.) > That is not the > case here, but a few pieces of extra information such as the output > of fstat and the value of kern.*files would have quickly confirmed > to us that there is in fact a real bug. > dito (see line 39pp) > It looks like a fdrop() call in open() (now kern_open) was lost in > revision 1.218 of vfs_syscalls.c. It probably wasn't noticed because > it is in an error case that would rarely occur in practice. Doing > > lockf /dev/null ls > > is a reliable way of repeating the bug, as can be confirmed by > monitoring kern.openfiles. The following patch appears to fix it. > I wonder why there are two equal calls to 'fdrop' if the if-condition evaluates to true but I am not the one to judge over your source code but I would be sorry if my panging leads to funny source code... In general it is clear that you are not forced to believe me or to fix bugs. But I am very glad that I can successfully use your software since 1996. *sniff* Thank you for your cooperation. -Arne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210081047.g98AlQd4001499>