On 18/10/17(Wed) 14:33, Helg Bredow wrote: > On Wed, 18 Oct 2017 15:03:21 +0200 > Martin Pieuchot <[email protected]> wrote: > > > On 18/10/17(Wed) 12:51, Helg Bredow wrote: > > > On Wed, 18 Oct 2017 10:04:07 +0200 > > > Martin Pieuchot <[email protected]> wrote: > > > > > > > On 17/10/17(Tue) 15:30, Helg Bredow wrote: > > > > > If you execute "fuse-zip -V" it prints the version and then dumps > > > > > core. This is because fuse-zip does not initialise the mount point > > > > > pointer to NULL. This patch ensures that it's always initialised to > > > > > NULL. > > > > > > > > It's hard to understand your fix if you don't explain what "dumps core". > > > > > > > > I had to install the package and look at the trace myself. You could > > > > save me these tasks by either posting the backtrace, saying that free(3) > > > > is call on an uninitialized memory or both. > > > > > > > > That said, I'd suggest different fix. Initializing `mp' in fuse_setup() > > > > is very fragile. Instead I'd declare a local variable and don't use > > > > `mp' at all in these function. > > > > In case of sucsses, just before returning the "struct fuse" pointer I'd > > > > assign *mp, if not NULL, to the local variable. > > > > > > > > By the way, what does "mp" stand for? I find the name confusing. > > > > > > > > > > Sorry, I've been looking at this for so long I assumed the diff was > > > self-explanatory. Thanks for your patience. I like your suggestion and > > > have modified the patch accordingly. A NULL test before the assignment is > > > superfluous since the code won't be reached if dir is NULL. > > > > But what if mp is NULL? > > Good point; I hadn't considered that. I've added the check.
Committed thanks. It would be nice if you could audit the others functions of the library and fix any similar bug. Fuzzing the library might also help.
