(Illustration by Gaich Muramatsu)
On Thu, Jun 05, 2003 at 08:36:29AM -0700, Steve Simitzis wrote: > On 06/05/03, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote: > > What I'm trying to say is, all these arbitrary limits seem to be stupid. > > These MultiRPC contexts seem like just another pool allocator that > > doesn't scale. I'm tempted to just rip out and remove the 9 RPCs per > > user limit. But this is not a change that I wanted to mix in with the > > 6.0.0 stuff at the last minute. > > okay, it's that old problem. as long as we're talking about venus > crashes, here's one i haven't seen before. venus crashes while running > stats: Never seen it before either. What compiler are you using? I just went through the code and checked every place we assign anything to VnodeType. We only assign Invalid when the object is recycled in the cache, but in that case all of the other things would be cleared as well (no name, no fid, no rc rights, you get the point). Only when we get new status information from the server do we assign a possibly unknown value to the object. But in that case your client client would die shortly after it fetched the object. There are asserts all over the place that trigger when something is not a valid File, Directory, or SymLink VnodeType. So this is either memory corruption, which I would have expected to have noticed before as I've been running this stuff for several months now. Or a compiler related problem, which I'm very wary of after the broken ptr-to-member code in 6.0.0 and the failing implicit struct copy operation that was reported on bugtraq. JanReceived on 2003-06-05 13:01:40