talloc_abort in notmuch_thread_get_tags () when db has been modified
Gaute Hope
eg at gaute.vetsj.com
Mon Mar 7 01:14:00 PST 2016
Gaute Hope writes on January 18, 2016 13:45:
> David Bremner writes on January 18, 2016 13:25:
>> The most likely cause of such a crash looks to me like nm_thread is NULL
>> or corrupted when passed in to get_tags. It's used without checking as a
>> talloc context, and that call to talloc never returns.
>>
>
> Ok, I'll check some further. I am checking whether nm_thread is NULL
> though, [...]
Hi,
The stack trace that I get is as follows:
```
Stack trace of thread 15719:
#0 0x00007fc80cd9f2a8 raise (libc.so.6)
#1 0x00007fc80cda072a abort (libc.so.6)
#2 0x00007fc80c95889c n/a (libtalloc.so.2)
#3 0x00007fc80c95a02d talloc_named_const (libtalloc.so.2)
#4 0x00007fc814d674c5 _notmuch_string_list_create (libnotmuch.so.4)
#5 0x00007fc814d75f32 notmuch_thread_get_tags (libnotmuch.so.4)
#6 0x00000000004757cb _ZN7Astroid13NotmuchThread8get_tagsEP15_notmuch_thread (astroid)
```
this happens when:
1) start a long running query loading in the background
2) modify the db enough for the query to get invalidated.
as far as I can see, there is _no_ way to catch this error without
completely crashing the application. I would have to isolate this code
in a separate process or trap SIGABRT (which is certainly messy).
Best regards, Gaute
More information about the notmuch
mailing list