Re: some issues with emacs 25

[David Bremner]

Matthew Lear  writes:

> On 03/12/16 01:58, David Bremner wrote:
>> Matthew Lear  writes:
>> 
>>>
>>> I'd happily post some debug info to help analyse this if somebody could
>>> give me a few pointers about what would be needed and the emacs-fu
>>> needed to generate this.
>>>
>> 
>> I think the best thing at this point would be to find (or create)
>> another public message where you can duplicate the problem.
>
> I've sent two test emails directly to David for analysis.
> --  Matt

So I _finally_ got around to looking at these, and I think it's roughly
the same shr bug as before but some different functions.

I could actually only duplicate the bug with emacs-reply-fail-ec
message, but that was fixed by the following patch against the emacs-25
branch. Does this patch fix both failures for you?

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index 6c35a33c9c..2bc37c64bd 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1993,6 +1993,9 @@ shr-pixel-buffer-width
 (if (get-buffer-window)
(car (window-text-pixel-size nil (point-min) (point-max)))
   (save-window-excursion
+;; Avoid errors if the selected window is a dedicated one,
+;; and they just want to insert a document into it.
+(set-window-dedicated-p nil nil)
(set-window-buffer nil (current-buffer))
(car (window-text-pixel-size nil (point-min) (point-max)))
 
@@ -2036,6 +2039,9 @@ shr-render-td-1
(shr-indentation 0))
(shr-descend dom))
   (save-window-excursion
+;; Avoid errors if the selected window is a dedicated one,
+;; and they just want to insert a document into it.
+(set-window-dedicated-p nil nil)
(set-window-buffer nil (current-buffer))
(unless fill
  (setq natural-width
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: talloc_abort in notmuch_thread_get_tags () when db has been modified

[David Bremner]

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
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: talloc_abort in notmuch_thread_get_tags () when db has been modified

[Gaute Hope]

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: Attached is C++ test code that demonstrates the problem
(at least on my setup). It is part of the astroid test suite.



And did you try running this under valgrind?



``` 
$ valgrind test/test_notmuch_standalone

==9543== Memcheck, a memory error detector
==9543== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9543== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==9543== Command: test/test_notmuch_standalone
==9543== 
db: running test query..

query: *, approx: 10 threads.
thread id to change: 0002, thread no: 3
restarting query..
moving to thread: 2
tags: unread 
tags: inbox 
continue loading..

threads != NULL
terminate called after throwing an instance of 'Xapian::DatabaseModifiedError'
==9543== 
==9543== Process terminating with default action of signal 6 (SIGABRT): dumping core

==9543==at 0xE46E04F: raise (in /usr/lib/libc-2.24.so)
==9543==by 0xE46F479: abort (in /usr/lib/libc-2.24.so)
==9543==by 0xD7494EC: __gnu_cxx::__verbose_terminate_handler() 
(vterminate.cc:95)
==9543==by 0xD7472A5: __cxxabiv1::__terminate(void (*)()) 
(eh_terminate.cc:47)
==9543==by 0xD7472F0: std::terminate() (eh_terminate.cc:57)
==9543==by 0xD747507: __cxa_throw (eh_throw.cc:87)
==9543==by 0xEEB987D: ??? (in /usr/lib/libxapian.so.30.2.0)
==9543==by 0xEEBC4A7: ??? (in /usr/lib/libxapian.so.30.2.0)
==9543==by 0xEEBEE14: ??? (in /usr/lib/libxapian.so.30.2.0)
==9543==by 0xEEBF0B7: ??? (in /usr/lib/libxapian.so.30.2.0)
==9543==by 0xEEBFF77: ??? (in /usr/lib/libxapian.so.30.2.0)
==9543==by 0xEE9539A: ??? (in /usr/lib/libxapian.so.30.2.0)
==9543== 
==9543== HEAP SUMMARY:

==9543== in use at exit: 332,606 bytes in 1,171 blocks
==9543==   total heap usage: 28,503 allocs, 27,332 frees, 3,835,392 bytes 
allocated
==9543== 
==9543== LEAK SUMMARY:

==9543==definitely lost: 232 bytes in 1 blocks
==9543==indirectly lost: 285 bytes in 2 blocks
==9543==  possibly lost: 8,577 bytes in 93 blocks
==9543==still reachable: 323,432 bytes in 1,074 blocks
==9543==   of which reachable via heuristic:
==9543== newarray   : 1,536 bytes in 16 blocks
==9543== suppressed: 0 bytes in 0 blocks
==9543== Rerun with --leak-check=full to see details of leaked memory
==9543== 
==9543== For counts of detected and suppressed errors, rerun with: -v

==9543== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted (core dumped)
```


The test-code must be adapted to your _test_ notmuch db.

To pick up on this again, this issue started cropping up more frequently
again, and I can't see a way currently to anticipate or recover from
this from a user application of the notmuch library. There seems to be
an XapianError, which may or may not be handled by notmuch.


Previously you only reported a talloc error. Do you have a new stacktrace?



Yeah - unsure if it is the same.

```

(gdb) r
Starting program: /home/gaute/dev/mail/notm/astroid/test/test_notmuch_standalone 
[Thread debugging using libthread_db enabled]

Using host libthread_db library "/usr/lib/libthread_db.so.1".
db: running test query..
query: *, approx: 10 threads.
thread id to change: 0002, thread no: 3
restarting query..
moving to thread: 2
tags: unread 
tags: inbox 
continue loading..

threads != NULL
terminate called after throwing an instance of 'Xapian::DatabaseModifiedError'

Program received signal SIGABRT, Aborted.
0x7fffee46b04f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x7fffee46b04f in raise () at /usr/lib/libc.so.6
#1  0x7fffee46c47a in abort () at /usr/lib/libc.so.6
#2  0x7fffef2624ed in __gnu_cxx::__verbose_terminate_handler() ()
   at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x7fffef2602a6 in __cxxabiv1::__terminate(void (*)()) (handler=)
   at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x7fffef2602f1 in std::terminate() ()
   at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:57
#5  0x7fffef260508 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) 
(obj=0xb0eff0, tinfo=0x7fffede100b8 , 
dest=0x7fffedaa7e30 )
   at /build/gcc-multilib/src/gcc/libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x7fffedac587e in  () at /usr/lib/libxapian.so.30
#7  0x7fffedac84a8 in  () at /usr/lib/libxapian.so.30
#8  0x7fffedacae15 in  () at /usr/lib/libxapian.so.30
#9  0x7fffedacb0b8 in  () at /usr/lib/libxapian.so.30
#10 0x7fffedacbf78 in  () at /usr/lib/libxapian.so.30
#11 

Re: talloc_abort in notmuch_thread_get_tags () when db has been modified

[David Bremner]

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 demonstrates the problem
> (at least on my setup). It is part of the astroid test suite.
>

And did you try running this under valgrind?

> The test-code must be adapted to your _test_ notmuch db.
>
> To pick up on this again, this issue started cropping up more frequently
> again, and I can't see a way currently to anticipate or recover from
> this from a user application of the notmuch library. There seems to be
> an XapianError, which may or may not be handled by notmuch.

Previously you only reported a talloc error. Do you have a new stacktrace?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch