Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

astroid crashes with nonsensical query #132

Closed
mardukbp opened this issue May 12, 2016 · 35 comments
Closed

astroid crashes with nonsensical query #132

mardukbp opened this issue May 12, 2016 · 35 comments
Labels
bug need-info notmuch

Comments

@mardukbp
Copy link

By accident I discovered that performing the following query a few times (one after the other) crashes astroid:

tag:flagged from:2015..

I am using version v0.5.r164.ged2256a compiled from git in Arch.
@gauteh
Copy link
Member

gauteh commented May 12, 2016 •
edited
Loading

I cannot reproduce this, please post log of the output, and if you have the coredump post the stacktrace:

$ coredumpctl gdb astroid
(gdb) bt

@mardukbp
Copy link
Author

The log is exactly like when everything works fine. The backtrace is here:

#0  0x00007fefab7b47a0 in Glib::ustring::c_str() const ()
   from /usr/lib/libglibmm-2.4.so.1
#1  0x00007fefac780c6c in Gtk::Entry::set_text(Glib::ustring const&) ()
   from /usr/lib/libgtkmm-3.0.so.1
#2  0x000000000043cc1e in ?? ()
#3  0x00007fefac81b89d in ?? () from /usr/lib/libgtkmm-3.0.so.1
#4  0x00007fefa885714c in ?? () from /usr/lib/libgtk-3.so.0
#5  0x00007fefa7d94fa5 in g_closure_invoke ()
   from /usr/lib/libgobject-2.0.so.0
#6  0x00007fefa7da7294 in ?? () from /usr/lib/libgobject-2.0.so.0
#7  0x00007fefa7daf829 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#8  0x00007fefa7db00bf in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#9  0x00007fefa8999ecc in ?? () from /usr/lib/libgtk-3.so.0
#10 0x00007fefa89ba06b in gtk_window_propagate_key_event ()
   from /usr/lib/libgtk-3.so.0
#11 0x00007fefa89bdacb in ?? () from /usr/lib/libgtk-3.so.0
#12 0x00007fefac8156e4 in Gtk::Widget::on_key_press_event(_GdkEventKey*) ()
   from /usr/lib/libgtkmm-3.0.so.1
#13 0x00007fefac817a24 in Gtk::Widget_Class::key_press_event_callback(_GtkWidget*, _GdkEventKey*) () from /usr/lib/libgtkmm-3.0.so.1
#14 0x00007fefa885714c in ?? () from /usr/lib/libgtk-3.so.0
#15 0x00007fefa7d94fa5 in g_closure_invoke ()
   from /usr/lib/libgobject-2.0.so.0
#16 0x00007fefa7da759e in ?? () from /usr/lib/libgobject-2.0.so.0
#17 0x00007fefa7daf829 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#18 0x00007fefa7db00bf in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#19 0x00007fefa8999ecc in ?? () from /usr/lib/libgtk-3.so.0
#20 0x00007fefa88545c9 in ?? () from /usr/lib/libgtk-3.so.0
#21 0x00007fefa885634c in gtk_main_do_event () from /usr/lib/libgtk-3.so.0
#22 0x00007fefa838e625 in ?? () from /usr/lib/libgdk-3.so.0
#23 0x00007fefa83bb492 in ?? () from /usr/lib/libgdk-3.so.0
#24 0x00007fefa7abef07 in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
#25 0x00007fefa7abf160 in ?? () from /usr/lib/libglib-2.0.so.0
#26 0x00007fefa7abf20c in g_main_context_iteration ()
   from /usr/lib/libglib-2.0.so.0
#27 0x00007fefa8085afd in g_application_run () from /usr/lib/libgio-2.0.so.0
#28 0x000000000042538e in ?? ()
#29 0x00007fefa689e710 in __libc_start_main () from /usr/lib/libc.so.6
#30 0x0000000000426d49 in ?? ()

I just installed astroid in Arch in VirtualBox with an empty notmuch database. I opened astroid, pressed F, pressed the up arrow key and obtained a Segmentation fault.

Maybe there is some error with the code that handles the search history.

@gauteh gauteh added the bug label May 12, 2016
@gauteh
Copy link
Member

gauteh commented May 12, 2016

Duplicate of #130. Something weird is going on here.

@gauteh
Copy link
Member

gauteh commented May 12, 2016

Does it happen if you upgrade all libraries (-Syu) and re-compile astroid?

@mardukbp
Copy link
Author

Yes. It took several attempts, maybe 30.

@gauteh
Copy link
Member

gauteh commented May 13, 2016

Marduk Bolaños writes on mai 13, 2016 0:23:

Yes. It took several attempts, maybe 30.

@apm256, @mardukbp: I made some change to master, please update and try
again and see if it still happens.

@apm256
Copy link

apm256 commented May 13, 2016 •
edited
Loading

I've tried the new code, and was able to reproduce the crash with the following procedure:

  1. rm -f searches
  2. astroid --no-auto-poll
  3. press F, then write a query
  4. press F again, while the previous results are still loaded (a % is visible)
  5. press Down

@gauteh
Copy link
Member

gauteh commented May 13, 2016

apm256 writes on mai 13, 2016 10:10:

I've tried the new code, and was able to reproduce the crash with the following procedure:

  1. rm -f searches
  2. astroid --no-auto-poll
  3. press F, then write a query
  4. press F again, while the previous results are still loaded (a % is visible)
  5. press Down

I finally found a way to reproduce this, I think it should be fixed now.

@apm256
Copy link

apm256 commented May 13, 2016

Seems fixed, indeed.
No more crashes here!

@mardukbp
Copy link
Author

I am sorry to tell you that astroid still crashes. Here is a complete backtrace:

Thread 6 (Thread 0x7fade0a53700 (LWP 24627)):
#0  0x00007fadf2ab3abd in poll () from /usr/lib/libc.so.6
#1  0x00007fadf3c1b0fc in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fadf3c1b482 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0x00007fadf42186d6 in ?? () from /usr/lib/libgio-2.0.so.0
#4  0x00007fadf3c41975 in ?? () from /usr/lib/libglib-2.0.so.0
#5  0x00007fadf2d7d474 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007fadf2abcacd in clone () from /usr/lib/libc.so.6

Thread 5 (Thread 0x7fade13f09c0 (LWP 24625)):
#0  0x00007fadf3ef0a9b in g_closure_sink () from /usr/lib/libgobject-2.0.so.0
#1  0x00007fadf3f09776 in g_signal_connect_data () from /usr/lib/libgobject-2.0.so.0
#2  0x00007fadf4a5a370 in ?? () from /usr/lib/libgtk-3.so.0
#3  0x00007fadf4a5a6e6 in ?? () from /usr/lib/libgtk-3.so.0
#4  0x00007fadf3f14389 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0
#5  0x00007fadf3ef631b in ?? () from /usr/lib/libgobject-2.0.so.0
#6  0x00007fadf3ef7c01 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#7  0x00007fadf3ef8534 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#8  0x00007fadf4a5abb5 in ?? () from /usr/lib/libgtk-3.so.0
#9  0x00007fadf4b050e9 in gtk_widget_get_style_context () from /usr/lib/libgtk-3.so.0
#10 0x00007fadf4b05238 in ?? () from /usr/lib/libgtk-3.so.0
#11 0x00007fadf4b0546f in gtk_widget_realize () from /usr/lib/libgtk-3.so.0
#12 0x00007fadf4b089f8 in gtk_widget_set_parent () from /usr/lib/libgtk-3.so.0
#13 0x00007fadf49e5f39 in ?? () from /usr/lib/libgtk-3.so.0
#14 0x0000000000466852 in ?? ()
#15 0x000000000043c6d1 in ?? ()
#16 0x00007fadf790d4f8 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib/libglibmm-2.4.so.1
#17 0x00007fadf3ef0fa5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#18 0x00007fadf3f03294 in ?? () from /usr/lib/libgobject-2.0.so.0
#19 0x00007fadf3f0ad71 in g_signal_emitv () from /usr/lib/libgobject-2.0.so.0
#20 0x00007fadf48a679b in ?? () from /usr/lib/libgtk-3.so.0
#21 0x00007fadf48a6d20 in ?? () from /usr/lib/libgtk-3.so.0
#22 0x00007fadf48a6ec0 in ?? () from /usr/lib/libgtk-3.so.0
#23 0x00007fadf48a7f6d in gtk_bindings_activate_event () from /usr/lib/libgtk-3.so.0
#24 0x00007fadf492e7a1 in ?? () from /usr/lib/libgtk-3.so.0
#25 0x00007fadf49b471c in ?? () from /usr/lib/libgtk-3.so.0
#26 0x00007fadf3ef0eff in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#27 0x00007fadf3f0359e in ?? () from /usr/lib/libgobject-2.0.so.0
#28 0x00007fadf3f0b829 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#29 0x00007fadf3f0c0bf in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#30 0x00007fadf4af665c in ?? () from /usr/lib/libgtk-3.so.0
#31 0x00007fadf4b167db in gtk_window_propagate_key_event () from /usr/lib/libgtk-3.so.0
#32 0x00007fadf4b1a24b in ?? () from /usr/lib/libgtk-3.so.0
---Type <return> to continue, or q <return> to quit---
#33 0x00007fadf89726e4 in Gtk::Widget::on_key_press_event(_GdkEventKey*) () from /usr/lib/libgtkmm-3.0.so.1
#34 0x00007fadf8974a24 in Gtk::Widget_Class::key_press_event_callback(_GtkWidget*, _GdkEventKey*) () from /usr/lib/libgtkmm-3.0.so.1
#35 0x00007fadf49b471c in ?? () from /usr/lib/libgtk-3.so.0
#36 0x00007fadf3ef0fa5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#37 0x00007fadf3f0359e in ?? () from /usr/lib/libgobject-2.0.so.0
#38 0x00007fadf3f0b829 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#39 0x00007fadf3f0c0bf in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#40 0x00007fadf4af665c in ?? () from /usr/lib/libgtk-3.so.0
#41 0x00007fadf49b1a79 in ?? () from /usr/lib/libgtk-3.so.0
#42 0x00007fadf49b38c2 in gtk_main_do_event () from /usr/lib/libgtk-3.so.0
#43 0x00007fadf44ea635 in ?? () from /usr/lib/libgdk-3.so.0
#44 0x00007fadf4517582 in ?? () from /usr/lib/libgdk-3.so.0
#45 0x00007fadf3c1af07 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#46 0x00007fadf3c1b160 in ?? () from /usr/lib/libglib-2.0.so.0
#47 0x00007fadf3c1b20c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#48 0x00007fadf41e1afd in g_application_run () from /usr/lib/libgio-2.0.so.0
#49 0x0000000000424fee in ?? ()
#50 0x00007fadf29f5741 in __libc_start_main () from /usr/lib/libc.so.6
#51 0x0000000000426989 in ?? ()

Thread 4 (Thread 0x7fade1254700 (LWP 24626)):
#0  0x00007fadf2ab3abd in poll () from /usr/lib/libc.so.6
#1  0x00007fadf3c1b0fc in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fadf3c1b20c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3  0x00007fadf3c1b249 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0x00007fadf3c41975 in ?? () from /usr/lib/libglib-2.0.so.0
#5  0x00007fadf2d7d474 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007fadf2abcacd in clone () from /usr/lib/libc.so.6

Thread 3 (Thread 0x7faddbfff700 (LWP 24628)):
#0  0x00007fadf2d8309f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007fadf325ea3c in __gthread_cond_wait (__mutex=<optimized out>, __cond=<optimized out>)
    at /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/gthr-default.h:864
#2  std::condition_variable::wait (this=<optimized out>, __lock=...) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/condition_variable.cc:53
#3  0x00000000004ec9a6 in ?? ()
#4  0x00007fadf3264aaf in std::execute_native_thread_routine (__p=0x7fadf94affb0) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:83
#5  0x00007fadf2d7d474 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007fadf2abcacd in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0x7fadda77c700 (LWP 24630)):
#0  0x00007fadf2ab3abd in poll () from /usr/lib/libc.so.6
#1  0x00007fadf3c1b0fc in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x00007fadf3c1b20c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0

#3  0x00007fadda78443d in ?? () from /usr/lib/gio/modules/libdconfsettings.so
---Type <return> to continue, or q <return> to quit---
#4  0x00007fadf3c41975 in ?? () from /usr/lib/libglib-2.0.so.0
#5  0x00007fadf2d7d474 in start_thread () from /usr/lib/libpthread.so.0
#6  0x00007fadf2abcacd in clone () from /usr/lib/libc.so.6

Thread 1 (Thread 0x7fadd8f79700 (LWP 24638)):
#0  0x00007fadf8d31aac in notmuch_threads_valid () from /usr/lib/libnotmuch.so.4
#1  0x00000000004ad9ca in ?? ()
#2  0x00007fadf3264aaf in std::execute_native_thread_routine (__p=0x7fadf981b7c0) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:83
#3  0x00007fadf2d7d474 in start_thread () from /usr/lib/libpthread.so.0
#4  0x00007fadf2abcacd in clone () from /usr/lib/libc.so.6

@gauteh
Copy link
Member

gauteh commented May 17, 2016

This is a different problem. I am closing this issue. If you identify what caused the new crash, please open a new issue.

@gauteh gauteh closed this as completed May 17, 2016
@mardukbp
Copy link
Author

mardukbp commented May 17, 2016 via email

@gauteh
Copy link
Member

gauteh commented May 18, 2016

What version of notmuch are you running?

@gauteh
Copy link
Member

gauteh commented May 18, 2016

The first crash was not related to the query, but to how search-history was browsed. It crashed when you press up or down in the search bar. The second crash seems related to the specific query.

@mardukbp
Copy link
Author

I am using notmuch 0.22. I tried this query in notmuch and obtained the following:

notmuch search: A Xapian exception occurred
A Xapian exception occurred performing query: Unknown range operation
Query string was: tag:flagged from:2015..

This makes me believe that astroid is not handling the Xapian exception correctly.

@gauteh
Copy link
Member

gauteh commented May 18, 2016

Marduk Bolaños writes on mai 18, 2016 21:04:

I am using notmuch 0.22. I tried this query in notmuch and obtained the following:

notmuch search: A Xapian exception occurred
A Xapian exception occurred performing query: Unknown range operation
Query string was: tag:flagged from:2015..

This makes me believe that astroid is not handling the Xapian exception correctly.

Please test newest git, I am now checking the status output.

Astroid does not have access to the exceptions through the Notmuch C
library. But this error seems to have been included in the status
value for newer notmuches.

@gauteh gauteh added the notmuch label May 18, 2016
@mardukbp
Copy link
Author

I tested the newest git. It took me 5 attempts to crash it. Hopefully something can be done to fix this. The exception is generated whenever you enter a query that notmuch does not understand. For example, when there is a typo in a prefix (date, from, etc.).

@gauteh
Copy link
Member

gauteh commented May 19, 2016

Marduk Bolaños writes on mai 18, 2016 22:44:

I tested the newest git. It took me 5 attempts to crash it. Hopefully something can be done to fix this. The exception is generated whenever you enter a query that notmuch does not understand. For example, when there is a typo in a prefix (date, from, etc.).

I need to know exactly which queries crash. The from:XXXX.. crash is now
handled. If there are others that do not result in a bad status message,
but still crashes they need to be included in notmuch (if it is indeed
the same crash).

@mardukbp
Copy link
Author

mardukbp commented May 19, 2016 via email

@gauteh
Copy link
Member

gauteh commented May 19, 2016

Marduk Bolaños writes on mai 19, 2016 21:44:

I did some testing and arrived at the conclusion that every query that
includes an invalid range expression will crash astroid.

My suggestion would be to pre-process every query before sending it to
notmuch. If the string ".." is found, make sure that it belongs to a
valid date expression as specified in man notmuch-search-terms. Then
decide if the expression will be sent to notmuch or not.

It is not a good idea to start pre-processing the queries and fixing
stuff that should be working in notmuch. This will be easy to get wrong
and hard to maintain. Then it should rather be fixed in notmuch, and we
should handle the errors that notmuch gives us. If notmuch does not
handle the error, we cannot handle the error and it is a notmuch bug.

What exact query are you trying now? With the newest commit on the
master branch (from today) the date:2015.. query does not crash astroid
for me anymore. Have you tested to recompile astroid? Please update and
recompile before testing.

@mardukbp
Copy link
Author

mardukbp commented May 19, 2016 via email

@gauteh
Copy link
Member

gauteh commented May 20, 2016

Marduk Bolaños writes on mai 20, 2016 0:37:

I totally agree that this has to be fixed in notmuch. However, I do not
expect that to happen anytime soon. The threading issue that I reported
here has been known to them since 2014 and it is still waiting for a
fix.

This is different. I have generally found notmuch to be fairly active.
But I am not yet sure that this is a bug in notmuch.

I updated to the latest commit and managed to crash astroid with the
query dat:2015...

Please update and try again, I added some more checks. If you have other
queries that crash, please provide them.

It is still not clear to me why does astroid crash. I have not looked
into the code, but my guess is that when the query is successful
libnotmuch returns some data type and when it is not, it returns another
data type. I would expect a crash if you feed the data returned by
libnotmuch directly to Gtk without verifying that the types match. But,
this is just speculation.

No, this is incorrect. If you have a look at the last commits and the
code around them you will see more of what is going on. Notmuch returns
an unsuccessful status value, which makes the notmuch objects invalid.
Since I did not properly check for the status Astroid crashed when I
attempted to use the notmuch objects.

@mardukbp
Copy link
Author

But I am not yet sure that this is a bug in notmuch.

IMHO notmuch should check that a query is valid before sending it to Xapian (and reject it when it is invalid), instead of waiting for things to blow up on the Xapian side.

If you have other queries that crash, please provide them.

I updated to the latest commit and crashed astroid with tag:flagged dat:2015... My guess is that you will have to consider several combinations of prefixes with typos. But I could be wrong (again).

@gauteh
Copy link
Member

gauteh commented May 20, 2016

Marduk Bolaños writes on mai 20, 2016 20:11:

But I am not yet sure that this is a bug in notmuch.

IMHO notmuch should check that a query is valid before sending it to Xapian (and reject it when it is invalid), instead of waiting for things to blow up on the Xapian side.

No - parsing and checking the query beforehand is difficult and
error-prone, it also duplicates all the error-checking in Xapian. Better
to try the query on the Xapian side and handle the errors correctly -
then propagate the error to the client application. This is what notmuch
does now, the problem arises if there are scenarios when the error is
not propagated, but rather results in a segfault. This cannot be handled
and recovered on the client side.

If you have other queries that crash, please provide them.

I updated to the latest commit and crashed astroid with tag:flagged dat:2015... My guess is that you will have to consider several combinations of prefixes with typos. But I could be wrong (again).

It is a bad idea to validate the query on the a) application side, or
b) the notmuch side. It should be validated in Xapian like it is now. We
should handle the error, not duplicate the error checking. The logic
will be exactly the same, but we cannot implement it better or
anticipate all the ingenious ways a user may enter a faulty query.

Please try again the latest commit, I forgot a check. So far it seems
that all faulty queries are handled and propagated by notmuch, but have
not been handled properly by astroid (yet!).

@mardukbp
Copy link
Author

mardukbp commented May 20, 2016 via email

@gauteh
Copy link
Member

gauteh commented May 21, 2016

Marduk Bolaños writes on mai 20, 2016 22:47:

but we cannot implement it better or anticipate all the ingenious ways
a user may enter a faulty query.

I apologize for being so persistent with this, but it really interests
me and I want to learn. I appreciate your patience.

From my naive point of view, if you know exactly what is the structure
of a valid query then anything that does not comply with it is by
definition an invalid query. Therefore, you do not have to care about
all the possible ways to formulate an invalid query.

My naive implementation of a query parser would do this. Given a query,
search for "words" delimited by quotes (these are strings of words
separated by spaces), store them in a list and remove them from the
query. Given the new query split it at every occurrence of the space
character. This results in a list of words. Given a word search for a
colon character. If you find it, then split the word in a left and a
right part. In the left part you will only accept words that belong to
the list of prefixes. If the left part is date, then on the right part
you will only accept dates and ranges that conform to the formats
specified in the manual. If the left part is not date, then on the right
part you will not interpret .. as a range.

This very likely does not cover all cases, but so far is it reasonable?

But it is totally pointless when there already is a complete, tested,
fully-functional, always-up-to-date, fast, easy-to-use, and ready
query-parser including validator ready in Xapian. So yes, it could
probably catch some cases, it would probably get some false positives as
well (which would prevent the user from doing legitimate queries). But
unless it is complete and perfect, what is the point?

Parsers are hard to get right, it would require a lot of work to make it
good. And whenever something changes upstream we would lag behind, or do
something wrong depending on the version the user has installed.

What do you think would be the difference in behaviour if we implemented it
ourselves?

Please try again the latest commit, I forgot a check.

I tried the latest commit and it crashed again with the query
tag:flagged dat:2015...

What is the backtrace? Please send the log as well.

@mardukbp
Copy link
Author

mardukbp commented May 21, 2016 via email

@gauteh
Copy link
Member

gauteh commented May 21, 2016

Marduk Bolaños writes on mai 21, 2016 14:52:

You are right. Xapian is doing its job and it does it well.

I spent some hours researching how do the queries work all the way from
astroid through notmuch to xapian. It seems to me that the current
programming practices in C++ lead to very fragile and hard to understand
code. For example, a lot of code depends on implicit behavior rather
than explicitly stating what is to be done. It is difficult to
understand a piece of code unless you have in mind all the things that
are assumed.

I have read and written some Lisp and Racket and the code is much easier
to understand, potentially leading to less bugs. I think it is true that
learning some Lisp makes you a better programmer in any language.

True, there is some weird things going on some times. But C++ interfaces
with C, and there are bindings for everything completely up-to-date and
it's fast. Sticking to some conventions makes things better.

What is the backtrace? Please send the log as well.

#0 0x00007ff9a7e64295 in raise () from /usr/lib/libc.so.6
#1 0x00007ff9a7e656da in abort () from /usr/lib/libc.so.6
#2 0x00007ff9a77188ac in ?? () from /usr/lib/libtalloc.so.2
#3 0x00007ff9a771846f in _talloc_free () from /usr/lib/libtalloc.so.2
#4 0x00000000004ad862 in ?? ()
#5 0x00007ff9a86c0aaf in std::execute_native_thread_routine (__p=0x7ff9aea41730) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:83
#6 0x00007ff9a81d9474 in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007ff9a7f18acd in clone () from /usr/lib/libc.so.6

Please send the log as well.

This is with the exact query: "tag:flagged dat:2015.." ? Does it crash
with notmuch on the command line as well? It does not crash for me.

This crash is in notmuch, but it might be fixed in notmuch-git.

@gauteh
Copy link
Member

gauteh commented May 21, 2016

By the way: Make sure you have the latest git version of astroid
compiled and running, because this error should in theory be the same as
the "from:2015.." error.

@gauteh
Copy link
Member

gauteh commented May 22, 2016

Gaute Hope writes on mai 21, 2016 17:42:

Marduk Bolaños writes on mai 21, 2016 14:52:

[...]

True, there is some weird things going on some times. But C++ interfaces
with C, and there are bindings for everything completely up-to-date and
it's fast. Sticking to some conventions makes things better.

By the way: https://github.com/gauteh/astroid/wiki/Style

@gauteh gauteh mentioned this issue May 22, 2016
Closed
@mardukbp
Copy link
Author

mardukbp commented May 22, 2016 via email

@kirschner
Copy link

I just had the same problem as described in this thread with astroid 0.8. When I search for
dat:2015.. it crashed. When I restarted astroid dat:2015.. said "no mails", when I did it a second tme with the same search it crashed again.

If you cannot reproduce it, and you need any additional information from me, please let me know.

@gauteh
Copy link
Member

gauteh commented Apr 19, 2017 via email

@kirschner
Copy link

My notmuch version is 0.24.1-2. So that should not be the problem, right?

gauteh added a commit that referenced this issue Apr 20, 2017
@gauteh
ql: #132: do not try to free notmuch_threads_destory on unsuccessfull…
79ef1c6 
… search
@gauteh
Copy link
Member

gauteh commented Apr 20, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug need-info notmuch
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@gauteh @mardukbp @apm256 @kirschner