Re: [Chicken-hackers] chicken-fuse

[Jörg F. Wittenberger]

Turns out there's some other bug (though in fuse.scm)

Am 17.03.2014 15:55, schrieb "Jörg F. Wittenberger":
> Hi Evan,
>
> I'm running up against some crazy segfault.  It happens under some 
> locally reproducibly circumstances, though I do not yet understand it.
>
> Nevertheless, I'm concerned with the inconsistent  related use of 
> fuse_file_info_fh's result.
>
> As far as I see it's only set in fuse_open_callback to the result of 
> object-evict of the users value.
>
> In fuse_release_callback it is used as - correspondingly - expected by 
> first calling object-unevict on fuse_file_info_fh's return value.
>
> However fuse_read_callback and fuse_write_callback both simply pass 
> the result up to the user code.  This strikes me as wrong, isn't it?

These concerns remain valid IMHO.  Aren't they?


However my problem was caused by fuse_create_callback, which indeed 
seems broken.

According to fuse.h " If the file does not exist, first create it with 
the specified mode, and then open it" I understand that the create 
procedure is supposed to return a file handle, not simply a error code.  
That is the wrapper in fuse.scm should set the info file handle like this:

(define-callback (fuse_create_callback (c-string path) (mode_t mode) 
(fuse_file_info fi)) int
  (let ((v ((current-filesystem-callback 7) path mode)))
    (fuse_file_info_fh_set! fi (object-evict v))
    (callback-result 'create v)))


With this change the code already works much better.  ;-)

> Unfortunately: that won't fix my problem.  I'm using (as per 
> documented recommendation) integer values as handles anyway.  I would 
> assume them to not be damaged that way.  (BEWARE: that's a wild guess.)
>
> The segfault I'm getting however is always when the return value 
> fuse_file_info_fh is accessed.  I tried to wrap an object-unevict 
> around it - same.  Just that the segfault is then no longer in my 
> code, but right in the object-unevict I inserted into fuse.scm.
>
> Continuing my wild guesswork: the stack trace from gdb points right 
> into srfi-69 code and up the call chain the next I'm seeing is the 
> "(let copy ...)" loop from object-unevict.  The offending call seems 
> to be hash-table-ref/default in the cond within that "copy" loop.

Sorry for this noise.