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