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