[Dovecot] Still crashing with test-80

[Jeff A. Earickson]

Matt,
Having gone thru this recently with the test80 assert crash, it really
helps if you compile dovecot with gcc and "-g -O" for the compiler
options.  This gets symbol debug information into the core dump.
Yes, gcc will optimize and give symbol table info too.

I went thru a procedure of getting gcc and gdb updated to 4.0.1 and
6.3 on my system, before rebuilding dovecot.

When I actually did a debug of the core dump, I had the dovecot source
code open in a second window so I could at least query on relevant
variables and hopefully provide Timo with some useful variable settings
at the time of the crash.  I must have done something right, because
Timo got the crash fixed in one patch!

Jeff Earickson
Colby College

On Thu, 18 Aug 2005, Timo Sirainen wrote:

> Date: Thu, 18 Aug 2005 20:44:31 +0300
> From: Timo Sirainen <tss at iki.fi>
> To: Matt Juszczak <matt at atopia.net>
> Cc: dovecot at dovecot.org
> Subject: Re: [Dovecot] Still crashing with test-80
> 
> On 18.8.2005, at 20:23, Matt Juszczak wrote:
>
>> pid 91923 (pop3), uid 25039: exited on signal 6
>
> What about the error message why it dies? Dovecot writes to logs the reason 
> why it kills itself when it dies with signal 6.
>
> Debugging these require that you get a core dump to the user's home directory 
> (Dovecot logs show what user's process crashed). Setting 
> mail_drop_priv_before_exec = yes in config file hopefully does that. Then 
> you'll need to get a backtrace from it against pop3 binary.
>
>> pid 653 (dovecot-auth), uid 0: exited on signal 6 (core dumped)
>
> Also dovecot-auth writes the reason why it crashes to log file.
>
>> orion# gdb /usr/local/libexec/dovecot/imap dovecot-auth.core
>
> Sorry, wrong again :) dovecot-auth binary against dovecot-auth.core file. 
> pop3 binary against core files created by pop3.
>
> Also your previous backtrace for dovecot-auth was somewhat broken too.. 
> Probably because the binaries were stripped. Did you use some binary package 
> or compile by hand? Those backtraces would be a lot better if the debugging 
> info wasn't stripped away..
>