Open Source Projects Europe

Thanks for reporting this. The cause is probably 'something' in the process incorrectly closing descriptor 19 (here used by libc for ip address stuff), and reusing it for something else. Then when libc wants to use it, it gets wrong (or no) data, and crashes the process. There is a discussion of what libc does here: https://patchwork.ozlabs.org/patch/535239/

The difficulty is that I have no idea whatsoever of what part of the code is doing this. It could be recoll code, or it could be in qt, and it's probably completely asynchronous and unrelated to the call stack at the point where glibc discovers the issue.

The only approach I can think of would be to run the process under strace or such, and try to determine who messed with the descriptor. Of course, if the problem takes a lot of time to occur, this will produce a monster trace, so it may not be very practical.

The other issue is that I was never able to reproduce the issue (but I don't keep the GUI open much, I just start it when I need it). I'll try to keep an instance open and see if it crashes.

Closing this, because I can't reproduce it, and I have actually no reason to believe that this is a recoll issue (rather than a toolkit / desktop one). Feel free to reopen if you can find something more specific, like maybe the GUI reaching some CPU time or memory usage limit (which would be surprising by the way, as the GUI is almost fully passive as far as I can see).

• Description has changed:

Diff:

--- old
+++ new
@@ -1,4 +1,3 @@
-
 Same as Issue 316: Unexpected error 9 on netlink descriptor 19

• milestone: -->

• status: open --> closed

• status: closed --> open

My apologies it seems it was a Recoll issue actually.

Should hopefully be fixed in release 1.23.8. The probable cause was a double close() on a file descriptor used by the lock file object ensuring that only one indexer can run.

• status: open --> closed