I?m seeing core dumps from Dovecot?s imap process (around 1/day currently) from client_check_command_hangs(). Dovecot 2.2.24 OS: Solaris 10 CPU: x86 Filesystem: Local ZFS Most crashes are associated with one user (with 25GB of mail in his mailboxes) but some (two) are also associated with other user with ?just? 10GB mail. Please find enclosed various log files/traces. Let me know if there is something else I might be able to provide that might give more insight into this. The output is from one of the ?25GB?-user crashes. He is able to access mail normally most of the time though so the client recovers and he hasn?t reported this issue to us. ? [L?.U] SysAdmin KITVS-IFM & ITI-NET IT.LiU.SE +46-13-28 2786 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cores.txt URL: <http://dovecot.org/pipermail/dovecot/attachments/20160608/6fc56981/attachment-0004.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dbx.txt URL: <http://dovecot.org/pipermail/dovecot/attachments/20160608/6fc56981/attachment-0005.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dovecot-n.txt URL: <http://dovecot.org/pipermail/dovecot/attachments/20160608/6fc56981/attachment-0006.txt> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pstack.txt URL: <http://dovecot.org/pipermail/dovecot/attachments/20160608/6fc56981/attachment-0007.txt>
On 08 Jun 2016, at 12:23, Peter Eriksson <peter at ifm.liu.se> wrote:> > I?m seeing core dumps from Dovecot?s imap process (around 1/day currently) from client_check_command_hangs(). > > Dovecot 2.2.24 > OS: Solaris 10 > CPU: x86 > Filesystem: Local ZFS > > Most crashes are associated with one user (with 25GB of mail in his mailboxes) but some (two) are also associated with other user with ?just? 10GB mail. > > Please find enclosed various log files/traces. Let me know if there is something else I might be able to provide that might give more insight into this.Could you also print in dbx: print *client->command_queue print *client->command_queue->next print *client->command_queue->next->next print *client->command_queue->next->next->next ..etc until it stops working Looks like there is still some bug with command pipelining.