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.
_______________________________________________
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers