search

purebred-mua / hs-notmuch

Modern Haskell binding to the Notmuch mail indexer
11 stars 2 forks source link

core dump when searching for a lot of threads #22

Closed romanofski closed 6 years ago

romanofski commented 6 years ago

I think I've introduced a regression with adding support for threads. When the query yields a lot of search results, I'm running into a SIGABRT with purebred. I don't have a reproducer yet, only data to offer.

Compiled against: b6dd23038a76c63a63ad7cd112545ee105d9fad3

(gdb) backtrace
#0  0x00007ffff65bf69b in raise () at /lib64/libc.so.6
#1  0x00007ffff65c13b1 in abort () at /lib64/libc.so.6
#2  0x00007ffff799858c in  () at /lib64/libtalloc.so.2
#3  0x00007ffff7999ec9 in talloc_named_const () at /lib64/libtalloc.so.2
#4  0x00007ffff7bc7dfd in _notmuch_thread_create () at /lib64/libnotmuch.so.5
#5  0x00007ffff7bc4d89 in notmuch_threads_get () at /lib64/libnotmuch.so.5
#6  0x00000000004bcaa2 in notmuchzm0zi1zi0zi0zmCHTTkRw0ag8J6oXLxvNsa1_NotmuchziBinding_queryzusearchzuthreads2_info ()
#7  0x0000000000000000 in  ()
frasertweedale commented 6 years ago

@romanofski So this was not including the new commit(s) from that latest hs-notmuch PR?

frasertweedale commented 6 years ago

The error occurs during in query_search_threads. What version of libnotmuch is this built against? (Check libnotmuch.h)

frasertweedale commented 6 years ago

I have a reproducer (well I'm not 100% sure because I have nfi what fedora is doing with my core dumps...). Looks like maybe we have to keep the query live for thread iteration (this does not seem to be the case for messages...)

romanofski commented 6 years ago

In regards to hs-notmuch, it was not including the new commits. I can safely rule them out. Libnotmuch version is 5.0.0 and package version of notmuch-devel is 0.25

romanofski commented 6 years ago

Oh and in regards to the core dumps, I think the default is configured to use 'abrt' so the CLI version is 'abrt-cli'

frasertweedale commented 6 years ago

@romanofski thanks, I think I have a fix. Got to test some related scenarios.

frasertweedale commented 6 years ago

The problem goes much deeper... I've found lots of different scenarios that cause problems. I think I'm gonna have to redesign the library somewhat :O

romanofski commented 6 years ago

ooh oh I'd be interested to know what you've found out.

frasertweedale commented 6 years ago

Basically its to do with pointer ownership. Some iterators seem to point back into the object that they were created from (e.g. threads_t iterator points into query, messages_t iterator points into thread, etc). But it may go even further than that, e.g. with messages created from a message iterator pointed back into the owner object. So the goal of detaching all the pointers and just letting haskell's GC take care of cleanup is not cutting it.