Ticket #1 (defect)

Hey Zanchey, thanks for this very first bug report on tinymail.

The problem seems to be happening in the Camel library. Can you specify which version of Camel you used? Have you tried with the camel build by camel-lite-builder (ps. http://tinymail.org/trac/camel-lite-builder for more information)?

Thanks

Note to myself: A possible reason can be that the folder was already destroyed (Zanchey says he clicked around, which is something that causes folders to get destroyed) at a time that his GtkTreeView requests a value from one of the headers of that folder.

Perhaps a workaround/guard can be put in place to prevent the tinymail framework to access a destroyed folder.

Whoops, sorry, forgot the obligatory 'first report' rider.

The current version of libcamel installed on my machines is Debian's libcamel1.2-8 1.6.3-1+b1, which appears to be upstream version 1.6.3. I will give camel-lite-builder a go.

Reproducible after building with camel-lite-builder's current version of libcamel.

New backtrace:

Thread 2 (process 10633):
#0  0xb73c2e19 in poll () from /lib/tls/libc.so.6
#1  0xb74a21a9 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#2  0xb74a2537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0xb7f20844 in libnm_glib_init () from /usr/lib/libnm_glib.so.0
#4  0xb74bc5df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#5  0xb74380bd in start_thread () from /lib/tls/libpthread.so.0
#6  0xb73cc8fe in clone () from /lib/tls/libc.so.6

Thread 1 (process 10620):
#0  0x00000000 in ?? ()
#1  0xb70a0d8f in camel_message_info_ptr (mi=0x832cb68, id=1) at camel-folder-summary.c:2997
#2  0xb7452c27 in tny_camel_header_get_from (self=0x8298b80) at tny-camel-header.c:350
#3  0xb7473b43 in tny_header_get_from (self=0x8298b80) at tny-header.c:309
#4  0xb7465a85 in tny_gtk_header_list_model_get_value (self=0x8298b80, iter=0xbfe4aa3c, column=0,
    value=0xbfe4aac8) at tny-gtk-header-list-model.c:385
#5  0xb7b25965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#6  0xb7b2e981 in gtk_tree_model_sort_new_with_model () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb7b25965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb7b4fcd7 in gtk_tree_view_column_cell_set_cell_data () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7b492c3 in _gtk_tree_view_column_autosize () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7a74110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb75a9fc9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#12 0xb75aba0b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb75bc4bf in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#14 0xb75bd158 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#15 0xb75bd529 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#16 0xb7b5dcc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb7a6eecf in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb78f2e00 in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#19 0xb78f2faf in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb79e0107 in gtk_container_check_resize () from /usr/lib/libgtk-x11-2.0.so.0
#21 0xb749d451 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#22 0xb749ee2c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#23 0xb74a2176 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#24 0xb74a2537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#25 0xb7a6f141 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x0804af14 in main (argc=1, argv=0xbfe4b424) at tny-main.c:130

What type of account is it? IMAP, NNTP or POP (or a custom one using url_string)?

That core file (or a new one) might indeed be useful. Feel free to contact me on IRC so that you can send it to me.

It would also be interesting to know which Gtk+ version you are running. As the GtkTreeView widget might influence the behaviour happening here.

I added additional checks and some debugging aid to the code for this issue. Can you retry and paste both the console output and gdb stack traces if the problem is persistent? If the problem vanished, they it would be interesting to know this too (as the checks aren't a bugfix, they would be a workaround).

Oh, btw. (And I keep adding comments) :-)

It would also be interesting, if you know how of course, to run the application using the different valgrind tools (not just the massif one, as that one is not going to give you very interesting information about this bug).

Valgrind can help with detecting incorrect memory access. Which this bug is doing. If I find some time I'll create a wiki page on these trac pages about it. If you have to learn how to do it, and are very eager to try and learn it ;), feel free to start such a wiki page using the know-how you aquired for helping spotting this bug.

Heh :)

For others who want to investigate this bug: "what might be happening"

Knows: o. Each time a new folder is selected, the model unrefs all the headers it was showing. o. Each time a header is finalized (cause of that event) an internal reference count (on the folder instance) is decreased. o. If that internal reference count reaches zero, then the folder is destroyed.

Possible cause of this problem: o. It looks like a header of which the folder is destroyed, is being accessed o. This might be because of a behaviour of the GtkTreeView being used by Zanchey (Gtk+ version specific). For example the GtkTreeView ordered the model (which is a TnyHeaderListModel? behind a GtkTreeSortableModel?, so it can be behaviour of my TnyHeaderListModel?, behaviour of the sortable and behaviour of the treeview) to finalize which causes TnyHeaderListModel? to unref -- in the background using a g_idle! and this might be important! -- all the header instances once. Yet the treeview asks for just a few columns when this is happening. So the header instance is destroyed yet the view is asking for a final (late) value of it. Or the folder of the header instances is destroyed, the header isn't yet destroyed, and the view is asking for a final (late) value of one of the header instances in the model. Situations like this. The questions are of course: which situation is it. How can the treeview/model and sortable be instructed not to do this (in a gtk+ version unspecific way). And finally: is one (or multiple) of these situations really the reason, and using different gtk+ versions: how are we going to detect whether or not it is?

And Camel?

The bug probably happens in camel because:

Camel will free the summary field (in the bug it's the subject field) if the folder is destroyed, of all the summary items. In tinymail, a TnyHeader is the representative that keeps a bunch of summary items together. Like from, subject, to, cc, etc etc.

So when the tinymail code asks the summary system of camel for such a field, yet the folder is destroyed in camel, then camel will have a segmentation error (accessing a freed pointer).

In case of the mmap patch, the older will unmap the memory that contains this data. So the pointer will not be a freed one, but will be pointing to a location that is "no longer" mmap()ed.

Both will cause a segmentation error.

A few things to catch up on!

I am connecting to an IMAP server. GTK+ version is Debian's libgtk, 2.8.20-1.

I will sync the source now, and retry. I would be happy to provide corefiles (sans my password ;) - I'll contact you on IRC at some stage.

Hmm, good point on the password.

The libtinymail-gnome-desktop will not cache your password if it was compiled with gnome options. That's because in that case, the password is kept in gnome-keyring (and re-requested each time it's needed).

However. Without the gnome options, the password will be cached in the memory area of tinymail. And therefore will it be in the core file which you would send. Unencrypted indeed. Another solution would be to let it (tinymail) ask the user each time the password is needed again. Which wouldn't be what you want.

Whether or not the password is cached, depends on the per-device specific implementation. Eg. libtinymail-gnome-desktop, libtinymail-maemo, libtinymail-gpe and libtinymail-olpc.

With the changes applied, it looks like I'm still crashing in the same place.

Console output:

libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files
Invalid network manager installation. Going to assume Online status
Invalid network manager installation. Going to assume Online status

(tinymail:16741): camel-CRITICAL **: camel_object_is: assertion `o != NULL' failed
(tinymail:16741): camel-CRITICAL **: camel_stream_reset: assertion `CAMEL_IS_STREAM (stream)' failed
(above two lines repeated many times)

Segmentation fault - core dumped

GDB backtrace:

Thread 3 (process 12596):
#0  0xb740ce19 in poll () from /lib/tls/libc.so.6
#1  0xb74ec1a9 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#2  0xb74ec537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0xb7f6a844 in libnm_glib_init () from /usr/lib/libnm_glib.so.0
#4  0xb75065df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#5  0xb74820bd in start_thread () from /lib/tls/libpthread.so.0
#6  0xb74168fe in clone () from /lib/tls/libc.so.6

Thread 2 (process 12964):
#0  0xb7370ec2 in textdomain () from /lib/tls/libc.so.6
#1  0xb736ef95 in ngettext () from /lib/tls/libc.so.6
#2  0xb736ea0f in gettext () from /lib/tls/libc.so.6
#3  0xb736de8d in dcgettext () from /lib/tls/libc.so.6
#4  0xb749ef2c in tny_camel_folder_refresh_async_thread (thr_user_data=0x8287c70)
    at tny-camel-folder.c:452
#5  0xb75065df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#6  0xb74820bd in start_thread () from /lib/tls/libpthread.so.0
#7  0xb74168fe in clone () from /lib/tls/libc.so.6

Thread 1 (process 12587):
#0  0x082ff463 in ?? ()
#1  0xb70ead8f in camel_message_info_ptr (mi=0x82a334c, id=1) at camel-folder-summary.c:2997
#2  0xb749cc27 in tny_camel_header_get_from (self=0x834e548) at tny-camel-header.c:350
#3  0xb74bdb43 in tny_header_get_from (self=0x834e548) at tny-header.c:309
#4  0xb74afa85 in tny_gtk_header_list_model_get_value (self=0x834e548, iter=0xbff9410c, column=0,
    value=0xbff94198) at tny-gtk-header-list-model.c:385
#5  0xb7b6f965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#6  0xb7b78981 in gtk_tree_model_sort_new_with_model () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb7b6f965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb7b99cd7 in gtk_tree_view_column_cell_set_cell_data () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7b932c3 in _gtk_tree_view_column_autosize () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7abe110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb75f3fc9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#12 0xb75f5a0b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb76064bf in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#14 0xb7607158 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#15 0xb7607529 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#16 0xb7ba7cc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb7ab8ecf in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb793ce00 in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#19 0xb793cfaf in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb7a2a107 in gtk_container_check_resize () from /usr/lib/libgtk-x11-2.0.so.0
#21 0xb74e7451 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#22 0xb74e8e2c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#23 0xb74ec176 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#24 0xb74ec537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#25 0xb7ab9141 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x0804af14 in main (argc=1, argv=0xbff94af4) at tny-main.c:130

Whoops, helps if you run make install!

Latest SVN produces:

Console output:

libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files
Invalid network manager installation. Going to assume Online status
Invalid network manager installation. Going to assume Online status

(tinymail:17599): Gtk-CRITICAL **: gtk_tree_model_sort_get_path: assertion `GTK_TREE_MODEL_SORT (tree_model)->stamp == iter->stamp' failed
Strange behaviour, adding headers while old headers are still loaded
(lots more times)
(tinymail:17599): camel-WARNING **: Trying to check junk data is OBJECT 'CamelFolder'
(tinymail:17599): camel-CRITICAL **: camel_object_is: assertion `check_magic(o, ctype, CAMEL_OBJECT_MAGIC)' failed
Strange behaviour, adding headers while old headers are still loaded
(lots more times)
Segmentation fault (core dumped)

All-threads backtrace:

Thread 3 (process 17607):
#0  0xb73dfe19 in poll () from /lib/tls/libc.so.6
#1  0xb74bf1a9 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#2  0xb74bf537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0xb7f3d844 in libnm_glib_init () from /usr/lib/libnm_glib.so.0
#4  0xb74d95df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#5  0xb74550bd in start_thread () from /lib/tls/libpthread.so.0
#6  0xb73e98fe in clone () from /lib/tls/libc.so.6

Thread 2 (process 17951):
#0  0xb73e25c7 in select () from /lib/tls/libc.so.6
#1  0xb7109da6 in camel_read (fd=502, 
    buf=0xb0803df0 "* 285 FETCH (UID 1925)\r\nB00003 OK Fetch completed.\r\n* OK [PERMANENTFLAGS (\\Answered \\Flagged \\Deleted \\Seen \\Draft \\*)] Flags permitted.\r\n* 285 EXISTS\r\n* 0 RECENT\r\n* OK [UIDVALIDITY 1107671630] UIDs v"..., n=1024) at camel-file-utils.c:459
#2  0xb710a1dd in camel_read_socket (fd=-514, buf=0xfffffdfe <Address 0xfffffdfe out of bounds>, 
    n=4294966782) at camel-file-utils.c:593
#3  0xb70d7e01 in stream_read (stream=0xfffffdfe, buffer=0x0, n=0) at camel-tcp-stream-raw.c:250
#4  0xb712d331 in camel_stream_read (stream=0x8144bf8, 
    buffer=0xb0803df0 "* 285 FETCH (UID 1925)\r\nB00003 OK Fetch completed.\r\n* OK [PERMANENTFLAGS (\\Answered \\Flagged \\Deleted \\Seen \\Draft \\*)] Flags permitted.\r\n* 285 EXISTS\r\n* 0 RECENT\r\n* OK [UIDVALIDITY 1107671630] UIDs v"..., n=1024) at camel-stream.c:98
#5  0xb712b9f1 in camel_stream_buffer_gets (sbf=0x8144db0, buf=0xb4141ed0 "", max=1024)
    at camel-stream-buffer.c:411
#6  0xb616a92b in camel_imap_store_readline (store=0x81426a0, dest=0xb4142308, ex=0x81416a0)
    at camel-imap-store.c:3006
#7  0xb615b6bd in camel_imap_command_response (store=0x81426a0, response=0xfffffdfe, ex=0x81416a0)
    at camel-imap-command.c:298
#8  0xb615b976 in imap_read_response (store=0x81426a0, ex=0x81416a0) at camel-imap-command.c:374
#9  0xb615b175 in camel_imap_command (store=0x81426a0, folder=0x82749d8, ex=0x81416a0, 
    fmt=0xb080f660 "") at camel-imap-command.c:116
#10 0xb615d67c in imap_refresh_info (folder=0x82749d8, ex=0x81416a0) at camel-imap-folder.c:517
#11 0xb70b0bf9 in disco_refresh_info (folder=0x82749d8, ex=0x0) at camel-disco-folder.c:268
#12 0xb70bfcaf in camel_folder_refresh_info (folder=0x82749d8, ex=0xfffffdfe) at camel-folder.c:298
#13 0xb747207b in tny_camel_folder_refresh_async_thread (thr_user_data=0x82eb9f0)
    at tny-camel-folder.c:480
#14 0xb74d95df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#15 0xb74550bd in start_thread () from /lib/tls/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#16 0xb73e98fe in clone () from /lib/tls/libc.so.6

Thread 1 (process 17599):
#0  0x0829cf25 in ?? ()
#1  0xb70bdd8f in camel_message_info_ptr (mi=0x8289560, id=1) at camel-folder-summary.c:2997
#2  0xb746fc7f in tny_camel_header_get_from (self=0x1) at tny-camel-header.c:366
#3  0xb7490b43 in tny_header_get_from (self=0x82df648) at tny-header.c:309
#4  0xb7482aa3 in tny_gtk_header_list_model_get_value (self=0x82df648, iter=0xbfb656cc, column=0, 
    value=0xbfb65758) at tny-gtk-header-list-model.c:385
#5  0xb7b42965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#6  0xb7b4b981 in gtk_tree_model_sort_new_with_model () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb7b42965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb7b6ccd7 in gtk_tree_view_column_cell_set_cell_data () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7b662c3 in _gtk_tree_view_column_autosize () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7a91110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb75c6fc9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#12 0xb75c8a0b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#13 0xb75d94bf in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#14 0xb75da158 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#15 0xb75da529 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#16 0xb7b7acc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb7a8becf in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb790fe00 in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#19 0xb790ffaf in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb79fd107 in gtk_container_check_resize () from /usr/lib/libgtk-x11-2.0.so.0
#21 0xb74ba451 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#22 0xb74bbe2c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#23 0xb74bf176 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#24 0xb74bf537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#25 0xb7a8c141 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x0804af14 in main (argc=1, argv=0xbfb660b4) at tny-main.c:130

I've found ways to reproduce this bug. It happens more frequently when a large unprevloaded folder is clicked and the camel cancellation therefore is needed (clicking rapidly on smaller folders will also cause it).

I'm therefore no longer excluding camel as the source of the defect.

Funny. Because I never nuke my .tinymail directory, and because you always do that (you mentioned that), and because the wonders of IRC made it possible for you to communicate that to me, it made me nuke mine too.

And that way I more or less found the bug.

It's a Camel bug in the CamelOperation? type. Tinymail always cancels operations that are still ongoing. That's because I assume that, on a mobile device, if something in the background is happening .. you want the new operation anyway. And simply forget about the old one.

Imagine opening a folder. If you click a new one before the other is done, you don't want the other. You want the new one. Right? Well on a mobile device that is *probably* right. On a desktop, that might not always be the case. But remember that tinymail does have a focus on mobile devices and embedded appliances. So I simplified the possibilities (which doesn't mean that others aren't allowed to complicate it a little bit, by designing optional cancellations versus optional queueing -- like what Evolution does --).

However. Lot's of yadi yada. The problem is that Camel, after such a cancellation, doesn't always correctly recover it's state. More specifically, its providers don't always return clean and correct CamelFolder? instances anylonger.

SO what I did was add code (pronounce that in a dirty way, like how a pirat would do it: ceuwduh) that kicks Camel a few times in the but by checking lots of time whether the instance returned is a correct one. And if not, leak the old one and try to get a new one.

Very ugly shit, indeed. But it does seem to, at least in most cases, make it stable. I don't write here: fix it. And I indeed don't consider it fixed. I need to investigate why Camel is behaving this way, and fix it in Camel. I do agree with that.

However. Nor should tinymail crash. In no circumstances. And definitely shouldn't a tinymail 1.0 crash. Hard period.

That's why I added this "code" to tny-camel-folder.c.

I hope it solves your problem. It should. Else, I kindly invite you to flood me with backtraces, core dump files and other stuff. Also feel free to experiment with different Camel versions. The more versioning information I have, the better I can compare differences.

Like: Using this version, it happens 30% of the times. That version causes it to happen 100% of the times. You'll see Camel warnings passing by. And tinymail now also has a g_critical when this issue is happening. You can in gdb break on g_log if you want to breakpoint the event.

Changing the title of this report

Oh, not only your note that you nuke .tinymail each time, also a can of RedBull? was responsible. That gave me that kick-in-the-head to start experimenting aggressively to actually find this bug.

For people on development, please often nuke your .tinymail folder too :-)

...

Or drink RedBull?, but they don't sponsor me. And drinking that a lot might not be healthy.

:-)

Looks like it's still crashing. SVN revision 976, built and installed today. Core dump is available - I'm on IRC fairly regularly. I haven't nuked .tinymail for a while, so it's still happening.

Console output:

libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files
Invalid network manager installation. Going to assume Online status
Invalid network manager installation. Going to assume Online status

(tinymail:8745): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'

(tinymail:8745): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Segmentation fault (core dumped)

All-threads stack backtrace:

Thread 3 (process 8758):
#0  0xb741fe19 in poll () from /lib/tls/libc.so.6
#1  0xb74ff1a9 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#2  0xb74ff537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#3  0xb7f7d844 in libnm_glib_init () from /usr/lib/libnm_glib.so.0
#4  0xb75195df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#5  0xb74950bd in start_thread () from /lib/tls/libpthread.so.0
#6  0xb74298fe in clone () from /lib/tls/libc.so.6

Thread 2 (process 11509):
#0  0xb750da69 in g_random_int () from /usr/lib/libglib-2.0.so.0
#1  0xb74f0227 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0
#2  0xb750f3a4 in g_scanner_scope_remove_symbol () from /usr/lib/libglib-2.0.so.0
#3  0xb7126a2f in e_sexp_remove_symbol (f=0x827d890, scope=0, name=0xb71292dd "not")
    at e-sexp.c:1240
#4  0xb7126808 in e_sexp_add_function (f=0x827d890, scope=0, name=0xb71292dd "not",
    func=0xb70f71a0 <search_not>, data=0x82833b8) at e-sexp.c:1186
#5  0xb70f667c in camel_folder_search_construct (search=0x82833b8) at camel-folder-search.c:237
#6  0xb61a4171 in camel_imap_search_new (cachedir=0x1aad3 <Address 0x1aad3 out of bounds>)
    at camel-imap-search.c:165
#7  0xb619cc81 in camel_imap_folder_new (parent=0x8141b00, folder_name=0x826bf30 "sent-mail-2004",
    folder_dir=0x8144360 "/home/wheel/zanchey/.tinymail/mail/imap/adamd02@tartarus.uwa.edu.au/folders/sent-mail-2004", ex=0xb2fff3e4) at camel-imap-folder.c:275
#8  0xb61a898a in get_folder_offline (store=0x8141b00, folder_name=0x826bf30 "sent-mail-2004",
    flags=0, ex=0xb2fff3e4) at camel-imap-store.c:2054
#9  0xb61a81b1 in get_folder_online (store=0x8141b00, folder_name=0x826bf30 "sent-mail-2004",
    flags=0, ex=0xb2fff3e4) at camel-imap-store.c:1835
#10 0xb70f1c7a in disco_get_folder (store=0x8141b00, name=0x826bf30 "sent-mail-2004", flags=0,
    ex=0xb2fff3e4) at camel-disco-store.c:233
#11 0xb7115d0d in camel_store_get_folder (store=0x8141b00, folder_name=0x826bf30 "sent-mail-2004",
    flags=0, ex=0xb2fff3e4) at camel-store.c:260
#12 0xb74b26f4 in load_folder_no_lock (priv=0x82706e0) at tny-camel-folder.c:176
#13 0xb74b2cc0 in tny_camel_folder_refresh_async_thread (thr_user_data=0x8285e50)
    at tny-camel-folder.c:540
#14 0xb75195df in g_thread_create_full () from /usr/lib/libglib-2.0.so.0
#15 0xb74950bd in start_thread () from /lib/tls/libpthread.so.0
#16 0xb74298fe in clone () from /lib/tls/libc.so.6

Thread 1 (process 8745):
#0  0xb74c25d1 in _tny_gtk_header_list_iterator_travel_to_nth_nl (self=0x8278180, cur=0, nth=0)
    at tny-gtk-header-list-model.c:63
#1  0xb74c3202 in tny_gtk_header_list_model_get_iter (self=0x8155b58, iter=0xbfba519c,
    path=0xb5803810) at tny-gtk-header-list-model.c:199
#2  0xb7b82bf0 in gtk_tree_model_get_iter () from /usr/lib/libgtk-x11-2.0.so.0
#3  0xb7b889e7 in gtk_tree_model_sort_convert_iter_to_child_iter ()
   from /usr/lib/libgtk-x11-2.0.so.0
#4  0xb7b8b964 in gtk_tree_model_sort_new_with_model () from /usr/lib/libgtk-x11-2.0.so.0
#5  0xb7b82965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#6  0xb7baccd7 in gtk_tree_view_column_cell_set_cell_data () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb7ba645f in _gtk_tree_view_column_autosize () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb7ad1110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7606fc9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#10 0xb7608a0b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#11 0xb76194bf in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#12 0xb761a158 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#13 0xb761a529 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#14 0xb7bbacc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#15 0xb7acbecf in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#16 0xb794fe00 in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#17 0xb794ffaf in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#18 0xb7a3d107 in gtk_container_check_resize () from /usr/lib/libgtk-x11-2.0.so.0
#19 0xb74fa451 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#20 0xb74fbe2c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0xb74ff176 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#22 0xb74ff537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#23 0xb7acc141 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x0804aef4 in main (argc=1, argv=0xbfba5b84) at tny-main.c:130

Another crash, a slightly different backtrace. Thread 1 only displayed.

Thread 1 (process 1742):
#0  0xb6ba455f in ?? () from /usr/lib/libk5crypto.so.3
#1  0xb6044111 in ?? ()
#2  0xb70add8f in camel_message_info_ptr (mi=0xb6043aa0, id=1) at camel-folder-summary.c:2997
#3  0xb745febf in tny_camel_header_get_from (self=0x829c778) at tny-camel-header.c:366
#4  0xb7480b43 in tny_header_get_from (self=0x829c778) at tny-header.c:309
#5  0xb7473e49 in tny_gtk_header_list_model_get_value (self=0x8155b20, iter=0xbff54e8c, column=0,
    value=0xbff54f18) at tny-gtk-header-list-model.c:385
#6  0xb7b32965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#7  0xb7b3b981 in gtk_tree_model_sort_new_with_model () from /usr/lib/libgtk-x11-2.0.so.0
#8  0xb7b32965 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0
#9  0xb7b5ccd7 in gtk_tree_view_column_cell_set_cell_data () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7b562c3 in _gtk_tree_view_column_autosize () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb7a81110 in _gtk_marshal_BOOLEAN__BOXED () from /usr/lib/libgtk-x11-2.0.so.0
#12 0xb75b6fc9 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0
#13 0xb75b8a0b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#14 0xb75c94bf in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#15 0xb75ca158 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#16 0xb75ca529 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#17 0xb7b6acc4 in gtk_widget_get_default_style () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb7a7becf in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#19 0xb78ffe00 in gdk_window_is_viewable () from /usr/lib/libgdk-x11-2.0.so.0
#20 0xb78fffaf in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#21 0xb79ed107 in gtk_container_check_resize () from /usr/lib/libgtk-x11-2.0.so.0
#22 0xb74aa451 in g_list_remove_link () from /usr/lib/libglib-2.0.so.0
#23 0xb74abe2c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#24 0xb74af176 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#25 0xb74af537 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#26 0xb7a7c141 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x0804aef4 in main (argc=1, argv=0xbff55874) at tny-main.c:130

If it crashed in thread 1;

Thread 1 (process 8745): #0 0xb74c25d1 in _tny_gtk_header_list_iterator_travel_to_nth_nl (self=0x8278180, cur=0, nth=0)

at tny-gtk-header-list-model.c:63 #1 0xb74c3202 in tny_gtk_header_list_model_get_iter (self=0x8155b58, iter=0xbfba519c, path=0xb5803810) at tny-gtk-header-list-model.c:199

then that is a different issue. The other thread looks like the same issue. Did you have any messages on the console? Can you each time this happens, post both the console output, the gdb backtraces of all threads and the gdb console text (so that i can see which thread crashed).

Spam removal

test

Is it still possible to reproduce this problem?

Yes, it is still trivial to crash Tinymail, although I'm not sure if it's still in the same place. Unfortunately I am on exams at the moment, and haven't had time to work it out. I'll be able to send more details on or after November 13th.

This was most likely the problem described in ticket #13