[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] chicken-fuse

From: Jörg F. Wittenberger
Subject: Re: [Chicken-hackers] chicken-fuse
Date: Mon, 17 Mar 2014 22:02:14 +0100
User-agent: Mozilla/5.0 (X11; Linux armv7l; rv:17.0) Gecko/20131104 Icedove/17.0.10

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]