Re: [Chicken-hackers] chicken-fuse

[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?


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.

So unless someone is found, who is competent enough to debug 
object-evict/object-unevict, I'm afraid I'm lost.

At worst I'd recommend to simply remove the ability to use any Scheme 
object as file handle and simply require them to be integers.  Then we 
could do away with the evict/unevict code.

Any thought?

Thanks

/Jörg

Am 10.03.2014 09:34, schrieb "Jörg F. Wittenberger":
> Am 09.03.2014 21:01, schrieb Evan Hanson:
> > Hi Jörg, thanks for looking into this.
> >
> > Indeed, there's definitely more copying happening than really needs to.