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

Re: [Mutt] #2958: mutt-1.5.16: mutt crash at start when enabling



#2958: mutt-1.5.16: mutt crash at start when enabling header caching in nsf
directory with a (non-root) install

Comment (by ):

 {{{
 Hi all:
         I spent a large amount of time trying to get over the crashing
 bug, with no success. The same segfault appears in the latest 1.5.17.
 However, I did get it to work on the said debian login server,
 amazingly, by compiling mutt on my laptop running an also ancient ubuntu
 5.04, and copy the binary mutt and mutt-lock to my $HOME/bin directory.
 I'm kind of amazed that it works, because the said remote machines is
 running an even more ancient debian 3.1(sarge), with differences in
 libraries.
         Still, this does not help to resolve the crashing issue. Even
 though I got my kind sys admin to all sorts of database libraries and
 headers, and I stripped away all sorts of unused options in ./configure,
 the resulting binary inevitably segfault immediate at start when I
 enable "header_cache=.." option, even if I deleted all the previously
 stored header caches.
         That's how far I got.
                                                                 Jiang

 On Mon, Sep 17, 2007 at 06:30:07AM -0400, Jiang Qian wrote:
 > On Mon, Sep 17, 2007 at 10:06:57AM -0000, Mutt wrote:
 > > #2958: mutt-1.5.16: mutt crash at start when enabling header caching
 in nsf
 > > directory with a (non-root) install
 > >
 > > Comment (by Rocco Rutte):
 > >
 > >  {{{
 > >  Hi,
 > >
 > >  * Mutt [07-09-17 09:36:58 -0000] wrote:
 > >
 > >  > >  Can you please find out with what database library you've
 compiled
 > >  mutt
 > >  > >  with (run 'ldd `which mutt´')?
 > >
 > >  > For remote machine(on which mutt crashes):
 > >
 > >  [...]
 > >  >         libdb-4.3.so => /usr/lib/libdb-4.3.so (0x401a0000)
 > >
 > >  > For local machine(where mutt is fine):
 > >
 > >  [...]
 > >  >         libdb-4.2.so => /usr/lib/libdb-4.2.so (0xa7d4c000)
 > >
 > >  Ok, so BDB on both systems. It would be really useful in tracking the
 > >  issue down if you could provide a backtrace with gdb of a crashed
 mutt.
 > >  In addition, if you have time and resources, it would be nice to see
 if
 > >  mutt with gdbm or qdbm works on the remote machine.
 > I used gdb to trace it. It says:
 > Program received signal SIGSEGV, Segmentation fault.
 > 0x402e39ca in funlockfile () from /lib/libc.so.6
 > So maybe this has something to do with locking. Now I recall that in
 > order to install mutt as non-root in the remote machine, I have to use
 > the option
 > --disable-external-dotlock
 > Otherwise I kept getting complaints about cannot install certain
 > things(flock? muttlock?) as non-root.
 > By contrast, on local machines that works, I have  --enable-flock.
 >
 > BTW, it's nice that the newest mutt have smtp capability, but one thing
 > I missed from the days I use ssmtp as agent is that mutt doesn't seem to
 > have an option to leave a log for smtp transactions, unless I get a
 > terse notice when things doesn't work. It'll be nice if an option is
 > given for smtp mail logs.
 > Thanks again.
 > Jiang
 > >
 > >  I don't really think it's IMAP related if another mutt installation
 can
 > >  handle the imaps folder (given that both mutt versions are
 identical).
 > >
 > >     bye, Rocco
 > >  }}}
 > >
 > > --
 > > Ticket URL: <http://dev.mutt.org/trac/ticket/2958#comment:>
 > >
 }}}

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2958#comment:>