Claws Mail Bugzilla – Bug 209
crash when processing in folder
Last modified: 2003-07-08 15:08:04
You need to log in before you can comment on or make changes to this bug.
I have a folder set up to automatically process messages to sent spam reports to spamcop.net. The processing rules are: ~from matchcase "Fred.Marton@uni-bayreuth.de" forward_as_attachment 1 submit.LGCkJ0yqUjD6pfUS@spam.spamcop.net" all delete and I have copies of sent mesaages kept in this folder, which are then deleted. This processing worked fine before and it was all right for the first three messages today, but it crashes repeately on number four (I can send that message on if necessary). Crash log: Sylpheed version 0.9.0claws75 GTK+ version 1.2.10 Features: gdk-pixbuf IPv6 libcompface GPGME OpenSSL LDAP JPilot GNU/aspell Operating system: Linux 2.4.16-4GB (i686) C Library: GNU libc 2.2.2 -- [New Thread 1024 (LWP 25810)] 0x4025b299 in wait4 () from /lib/libc.so.6 #0 0x4025b299 in wait4 () from /lib/libc.so.6 #1 0x402c92e8 in __DTOR_END__ () from /lib/libc.so.6 #2 0x0815d841 in crash_handler (sig=0) at crash.c:540 #3 0x4060de9d in pthread_sighandler () from /lib/libpthread.so.0 #4 <signal handler called> #5 0x4022a633 in strcmp () from /lib/libc.so.6 #6 0x0809d0c2 in procmsg_send_message_queue ( file=0x8680d90 "/home/fred/Mail/queue/6") at procmsg.c:1155 #7 0x080a77e9 in compose_send (compose=0x85e1618) at compose.c:2978 #8 0x08148ff1 in filteringaction_apply (action=0x85e1618, info=0x82feef0) at filtering.c:252 #9 0x08149111 in filtering_apply_rule (filtering=0x82feef0, info=0xfffffe00) at filtering.c:298 #10 0x08149202 in filter_msginfo (filtering_list=0x830efa8, info=0x8279470) at filtering.c:338 #11 0x0809abc1 in folder_item_apply_processing (item=0x85e1618) at folder.c:2799 #12 0x08096661 in folder_item_open (item=0x82feef0) at folder.c:991 #13 0x080772a7 in folderview_selected (ctree=0x829b1d0, row=0x860d6f8, column=-1, folderview=0x82feef0) at folderview.c:1669 #14 0x4036a9bc in gtk_marshal_NONE__POINTER_INT () from /usr/lib/libgtk-1.2.so.0 #15 0x4039c878 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0 #16 0x4039bbef in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0 #17 0x40399b47 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 #18 0x4033028d in gtk_ctree_select () from /usr/lib/libgtk-1.2.so.0 #19 0x4032db63 in real_unselect_all () from /usr/lib/libgtk-1.2.so.0 #20 0x403138f4 in gtk_clist_unselect_all () from /usr/lib/libgtk-1.2.so.0 #21 0x0816944e in select_row (sctree=0x829b1d0, row=22, col=0, state=136950224) at gtksctree.c:233 #22 0x08169812 in gtk_sctree_button_press (widget=0x829b1d0, event=0x830b558) at gtksctree.c:315 #23 0x4036a4ef in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0 #24 0x4039bc2d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0 #25 0x40399b47 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0 #26 0x403d2d1c in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0 #27 0x4036a425 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0 #28 0x4036946f in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0 #29 0x4041dd74 in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0 #30 0x405efb86 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #31 0x405f01b3 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #32 0x405f037c in g_main_run () from /usr/lib/libglib-1.2.so.0 #33 0x40368d2c in gtk_main () from /usr/lib/libgtk-1.2.so.0 #34 0x0806db6f in main (argc=1, argv=0xbfffee74) at main.c:359 #35 0x401cec5f in __libc_start_main () from /lib/libc.so.6
attach the message to #172, or send it to me. thanks. *** This bug has been marked as a duplicate of 172 ***
Created an attachment (id=74) [details] forwarding message that causes SC to crash Yes, it definitely seems to be this message. I deleted it and then the processing on the folder ran withoput a hitch.
Hrm; not a duplicate at all. The message has an invalid message id, which sylpheed (correctly) resets to zero in procheader.c (c. procheader_parse_stream()). If such a message is forwarded, the FMID queue header is (also correctly) truncated, but the code which matches a queued message with its referrer, doesn't check for an empty (NULL) message id. Fix will be checked in in a few minutes or so. Thanks.
fixed in 0.9.0claws90