[...] > > but it didn't help, it's not triggered > > > > Hmm, well that's the only place I could see in replay.c that could leak > (and it's a pretty straightforward piece of code). This is getting > interesting. Just to confirm where we currently are... > > - replay cache disabled --> no leak > - replay cache enabled (with or without the above patch) --> leak > yes and yes.
> I'll take another look, but I doubt the leak is in replay.c so... maybe > a reply from the cache is somehow handled incorrectly and that causes the > leak elsewhere? (Just a random hunch at this point.) > it works ok in 7.2, so it would be interesting to compare changes ... > > Thanks for the explanation on the cache, things are begining to make sense. > > If I understand, the reason for this cache is to prevent re-applying an > > already performed rpc, which could lead to data corruption > > > > Yep, you've got it. It is basically a bandaid for the poor transport > semantics provided by UDP. > > Having fun with this one. Thanks for the help, rick > I'm glad :-) danny _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"