Mem corruption due to race? (Was: [BUG] : crash (perhaps gpg related))
- From: Albrecht Dreß <albrecht dress arcor de>
- To: manu <eallaud yahoo fr>
- Cc: Balsa-Liste <balsa-list gnome org>
- Subject: Mem corruption due to race? (Was: [BUG] : crash (perhaps gpg related))
- Date: Tue, 9 Dec 2003 19:39:24 +0100
Am 08.12.03 15:28 schrieb(en) manu:
> (balsa:2121): Gtk-CRITICAL **: file ../../gtk/gtktextbuffer.c: line 543
> (gtk_text_buffer_emit_insert): assertion `g_utf8_validate (text, len,
> NULL)' failed
> though I'm not sure it is realted to the crash.
> I was only able to have this bt which does not look really helpful :
> Program received signal SIGSEGV, Segmentation fault.
> 0x4129e689 in __after_morecore_hook () from /lib/i686/libc.so.6
> (gdb) bt
> #0 0x4129e689 in __after_morecore_hook () from /lib/i686/libc.so.6
> #1 0x40c4f54c in gtk_rc_scanner_new () from /usr/lib/libgtk-x11-2.0.
I also had some crashes, and I also did not send them to bugzilla as they
are completely irreproducible. Yesterday I managed to crash balsa by
fastly clicking over the new messages in the inbox (mbox file), deleting
most of them (I have the "remove immediately" option checked).
Before the crash, I got a completely broken display in the mail body
window, showing inter alia some header lines and a body part from an other
message (not the one of which the headers were shown). This might be an
indication of a memory corruption (due to deleting messages?), probabely
caused by a race condition.
If you saw the same effect (which I guess is the case here), this might be
the cause for the utf8 error above. I must admit that I can not really
imagine how this is caused by gpg support. For signed messages, I just
take the mailbox stream, analyse it, and create some data structures
(RFC3156) or manipulate the text buffer directly (RFC2440), which is only
freed when the message is destroyed. IMHO, if there was a serious mem
alloc/free problem, it should crash more frequently, but of course I might
be wrong there.
For encrypted messages, the decrypted message is copied into a separate
temp stream, but this also seems to work. Hmmm...
> Hope someone can understand that.
Maybe the people who wrote the code to handle mbox files, in particular
moving/deleting messages, can tell a little more about that? I never had
problems at work where everything is imap...
Albrecht Dreß - Johanna-Kirchner-Straße 13 - D-53123 Bonn (Germany)
Phone (+49) 228 6199571 - mailto:firstname.lastname@example.org
] [Thread Prev