From: Ricardo C. <sou...@wi...> - 2007-01-22 17:58:20
|
Hi, One of my users is having a problem where he runs 'find' on the filesystem, interrupts it with CTRL-C and the filesystem crashes with a double free() or with a segfault. I have not been able to reproduce this, though. He is using FUSE-2.5.3, SMP kernel 2.6.19, Debian Etch (4.0). The backtraces appear to be messed up but they seem to point to the FUSE library. The last stack frame was in fuse_reply_none() which, AFAICS, is only being called by the default fuse_forget() (my filesystem isn't using the "forget" operation). I have asked him to run the filesystem under valgrind, but in the mean time I have a question. I suspect this could be the problem, but I'm not sure. This is what I'm doing for almost every operation: int error = -fuse_reply_xxx(req, ...); if(error) fuse_reply_err(req, error); Is this valid usage, considering possible errors in sending the replies? Thanks. |
From: John M. <mu...@no...> - 2007-01-22 18:39:41
|
Ricardo Correia wrote: > One of my users is having a problem where he runs 'find' on the filesystem, > interrupts it with CTRL-C and the filesystem crashes with a double free() or > with a segfault. I have not been able to reproduce this, though. > > He is using FUSE-2.5.3, SMP kernel 2.6.19, Debian Etch (4.0). > Maybe it the same as the problem fixed with the patch included here? http://article.gmane.org/gmane.comp.file-systems.fuse.devel/2740/match=fix+crash+caused+libfuse John. -- John Muir NORTEL mu...@no... |
From: Ricardo C. <rco...@wi...> - 2007-01-22 19:15:30
|
On Monday 22 January 2007 18:39, John Muir wrote: > Maybe it the same as the problem fixed with the patch included here? > > http://article.gmane.org/gmane.comp.file-systems.fuse.devel/2740/match=fix+ >crash+caused+libfuse Hmm.. That was merged in FUSE-2.5.3, so that shouldn't be the problem. Actually, I'm now thinking it could be a buffer overrun in my code, since the 2 (messed up) backtraces that I have are also pointing to my readdir operation, which is a little complex. But I'm still wondering if the code excerpt that I've posted is a valid way to handle possibly failed replies? I'm worried that a failed fuse_reply_xxx() and a subsequent fuse_reply_err() for the same request could lead to errors. I'm also not sure in what situations fuse_reply_xxx() could fail, and I'm currently ignoring fuse_reply_err() errors.. |
From: Miklos S. <mi...@sz...> - 2007-01-22 20:19:00
|
> One of my users is having a problem where he runs 'find' on the filesystem, > interrupts it with CTRL-C and the filesystem crashes with a double free() or > with a segfault. I have not been able to reproduce this, though. > > He is using FUSE-2.5.3, SMP kernel 2.6.19, Debian Etch (4.0). > > The backtraces appear to be messed up but they seem to point to the FUSE > library. The last stack frame was in fuse_reply_none() which, AFAICS, is only > being called by the default fuse_forget() (my filesystem isn't using > the "forget" operation). > > I have asked him to run the filesystem under valgrind, but in the mean time I > have a question. I suspect this could be the problem, but I'm not sure. This > is what I'm doing for almost every operation: > > int error = -fuse_reply_xxx(req, ...); > if(error) > fuse_reply_err(req, error); > > Is this valid usage, considering possible errors in sending the replies? It's not valid, and is likely the cause of the double free. You almost never need to care about the return value of the fuse_reply_xxx() functions. The only exceptions are open() and create(), and only if the error is -ENOENT. This means that the operation was interrupted and no release() will be called for it. This special case is an ugly wart in the interface, and I'll get rid of it eventually. Thanks, Miklos |
From: Ricardo C. <rco...@wi...> - 2007-01-22 21:29:34
|
On Monday 22 January 2007 20:18, Miklos Szeredi wrote: > It's not valid, and is likely the cause of the double free. > > You almost never need to care about the return value of the > fuse_reply_xxx() functions. The only exceptions are open() and > create(), and only if the error is -ENOENT. This means that the > operation was interrupted and no release() will be called for it. Alright, I'll fix that and see if it works. Thanks! |