David Bremner writes on november 3, 2017 13:18:
Gaute Hope writes:
Not sure if this is talloc_abort() anymore.
Actually, at this point this seems to be caused by different GMime
versions used for binary and notmuch library.
Regards, Gaute
OK, that sounds like not-a-notmuch-bug.
Yes..
Gaute Hope writes:
>> Not sure if this is talloc_abort() anymore.
>
> Actually, at this point this seems to be caused by different GMime
> versions used for binary and notmuch library.
>
> Regards, Gaute
OK, that sounds like not-a-notmuch-bug.
d
___
Gaute Hope writes on november 3, 2017 11:45:
David Bremner writes on februar 17, 2017 16:35:
Gaute Hope writes:
threads != NULL
terminate called after throwing an instance of 'Xapian::DatabaseModifiedError'
Yeah, that looks like a different problem. But it _should_ be something
we can catch
David Bremner writes on februar 17, 2017 16:35:
Gaute Hope writes:
threads != NULL
terminate called after throwing an instance of 'Xapian::DatabaseModifiedError'
Yeah, that looks like a different problem. But it _should_ be something
we can catch in libnotmuch.
For reference; I'm getting s
Gaute Hope writes:
> threads != NULL
> terminate called after throwing an instance of 'Xapian::DatabaseModifiedError'
Yeah, that looks like a different problem. But it _should_ be something
we can catch in libnotmuch.
d
___
notmuch mailing list
notmuc
David Bremner writes on februar 17, 2017 13:28:
Gaute Hope writes:
David Bremner writes on mars 7, 2016 13:01:
Gaute Hope writes:
Of course _why_ this error is happening could still be notmuch's
fault. Can you reproduce the problem under valgrind?
Hi again,
For future reference: Attac
Gaute Hope writes:
> David Bremner writes on mars 7, 2016 13:01:
>> Gaute Hope writes:
>>
>> Of course _why_ this error is happening could still be notmuch's
>> fault. Can you reproduce the problem under valgrind?
>
> Hi again,
>
> For future reference: Attached is C++ test code that demonstra
David Bremner writes on mars 7, 2016 13:01:
Gaute Hope writes:
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).
I'm not sure what you exp
Gaute Hope writes:
> 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).
I'm not sure what you expect libnotmuch to do here. There's a fatal
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.
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 wh
Gaute Hope writes:
> Hi,
>
> a user of astroid [0] ran into a issue [1] (full trace at issue) where
> reading a long query causes a talloc_abort in notmuch_thread_get_tags
> (). 'notmuch new' is running at the same time, and most likely a thread
> in the query has been modified since the query wa
Hi,
a user of astroid [0] ran into a issue [1] (full trace at issue) where
reading a long query causes a talloc_abort in notmuch_thread_get_tags
(). 'notmuch new' is running at the same time, and most likely a thread
in the query has been modified since the query was done. Note that a
notmuch_thr
13 matches
Mail list logo
