<<< Date Index >>>     <<< Thread Index >>>

Re: [Mutt] #3410: Mutt crashes when two instances open the same mailbox



Am 03.08.2010, 14:51 Uhr, schrieb Mutt:

#3410: Mutt crashes when two instances open the same mailbox
--------------------+-------------------------------------------------------
 Reporter:  vext01  |       Owner:  me
     Type:  defect  |      Status:  assigned
 Priority:  major   |   Milestone:
Component:  mutt    |     Version:
 Keywords:          |
--------------------+-------------------------------------------------------

Comment(by vext01):

 I have an alias for configuring mutt, which looks like this:
 configure_mutt='CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
 ./configure --prefix=/opt/mutt --with-sasl --enable-smtp --enable-imap
 --enable-hcache --with-ssl'

(Only skimming through this, so I may have missed an attachment:)

Can you post config.log so that developers can see what libraries exactly are getting picked up? There's still some magic underneath, particularly with the hcache stuff, although I believe it's unrelated.

 Although this could be a compiler bug, IIRC this happened before OpenBSD
 switch to GCC4 (which was only a few months back).

To figure if it's a GCC3 bug, make a backup copy of your /opt/mutt and recompile with GCC4 :)

 What is the best way to track the origin of that 0xdfdf...?

It's likely any of the free() calls given that malloc.conf is configured to spam freed memory regions with 0xdf (probably shorthand for dead flash, alonside the 0xd0 for doh...)

I'm not sure if it's practical to look at all free() calls though. Skilled debugger users might set conditional breakpoints, or perhaps figure where the relevant memory is allocated, set a breakpoint there, and then set watch- or tracepoints.

purify, valgrind, and similar real-time memory debuggers would be a bit more promising IMO. In need, try dmalloc or efence, or export MALLOC_CHECK_=2 on GNU libc systems - and be sure you can dump core.

--
Matthias Andree