thr3ads.net - dovecot - 2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)" [Sep 2016]

If this information is useful, please help other people find it:
Share via:

Piper Andreas

2016-Sep-01 05:03 UTC

2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

Hi Jake,

thanks for fixing this. I have installed now the newly built package on
my production system and will report, if any more core dumps occur.

Regards,
Andreas

Am 31.08.2016 um 20:19 schrieb Jake Goerzen:> Hi Andreas & Timo,
> 
> 
>   I've found out what is causing the incorrect hash in the built
> packages.  Our build system use here at OpenCSW has internal git
> patching capability.  I disabled it and rebuild again.  This time all
> architectures and memory model's are reporting the correct git-commit
> hash 7be1766.  Thank you Andreas for noticing and reporting this.
> 
> 
> regards,
> 
> Jake
> 
> 
> On 08/31/2016 06:17 AM, Piper Andreas wrote:
>> Hello Timo,
>>
>> from the maintainer of the OpenCSW package I got the below answer.
>>
>> As the newly build package yields another different commit hash (which
I
>> cannot find on GitHub too), I would ask, if you are sure that the
commit
>> hash-output in 'doveconf -n' is generated correctly?
>>
>> The headline of 'doveconf -n' with the newly build package is
>> # 2.2.25 (68082dc): /etc/opt/csw/dovecot/dovecot.conf
>>
>> Many thanks for your help,
>> Andreas
>>
>> -------- Weitergeleitete Nachricht --------
>> Betreff: Re: OpenCSW question about package CSWdovecot
>> Datum: Tue, 30 Aug 2016 08:56:44 -0700
>> Von: jgoerzen <jgoerzen at opencsw.org>
>> An: piper at hrz.uni-marburg.de
>>
>> Hello Andreas,
>>
>>
>>     The OpenCSW dovecot package was built using the 2.2.25 version
>> release tarball.  No code changes or patches have been applied. I'm
not
>> sure what happened.  I will respin new packages and then check to see
if
>> the git-commit hash is correct.  When the packages are done building
>> I'll put them in the experimental catalog:
>>
>>
>> http://buildfarm.opencsw.org/experimental.html#jgoerzen
>>
>>
>> Thanks,
>>
>> Jake
>>
>>
>>
>>
>>
>>
>>
>> On 08/29/2016 11:59 PM, piper at hrz.uni-marburg.de wrote:
>>> Hello,
>>>
>>> with your newest dovecot-package 2.2.25,REV=2016.07.01, I sometimes
>>> get core-dumps as documented in my bug-report at the
>>> dovecot-mailing-list:
>>> http://dovecot.org/list/dovecot/2016-August/105321.html
>>> In reaction to my bug-report, Timo Sirainen asks, which git-commit
of
>>> the dovecot-sources was used for this package:
>>> http://dovecot.org/list/dovecot/2016-August/105332.html
>>>
>>> Could you shed some light on this?
>>>
>>> Thanks a lot,
>>> Andreas
>>
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5176 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20160901/bf1a39be/attachment.p7s>

Piper Andreas

2016-Sep-01 11:20 UTC

head link

2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

Hello Timo,

with the newly build CSW-package the crashes still occur, today already
twice within two hours. The log shows always the same:

Sep  1 11:50:13 surz113 dovecot: [ID 583609 mail.crit] imap(user):
Panic: file imap-client.c: line 837 (client_check_command_hangs):
assertion failed: (client->io != NULL)
Sep  1 11:50:13 surz113 dovecot: [ID 583609 mail.error] imap(user):
Error: Raw backtrace: 0xffff80ffb633d88d -> 0xffff80ffb636ae82 ->
0x41eba0 -> 0x41ecf3 -> 0xffff80ffb635d248 -> 0xffff80ffb6350d2f ->
0xffff80ffb63519e0 -> 0xffff80ffb6350dce -> 0xffff80ffb6350f90 ->
0xffff80ffb62e3ebb -> 0x42f169 -> 0x41292c
Sep  1 11:50:13 surz113 dovecot: [ID 583609 mail.crit] imap(user):
Fatal: master: service(imap): child 11227 killed with signal 6 (core not
dumped - set service imap { drop_priv_before_exec=yes })

This happens with different users, the last one with a relatively small
mailbox of 600MB.

doveconf -n is attached.

Dovecot 2.2.25
OS: Solaris 11 (SunOS 5.11 11.3 i86pc i386 i86pc)
Virtualization: VMware
Filesystem: ZFS
active users: ~4000

The system was transferred at beginning of last week from an old
SPARC-station with Solaris 10 running dovecot-2.2.15 to this virtualized
platform under VMware. The mailboxes (maildir-format) were transferred
without change by switching the storage-hardware to the new server. I
had to remove all dovecot.index*-files for errors of "CPU Architecture
changed", but after doing this all seemed to work ok except for these
occasional crashes.

If you need more information, please let me know.

Thanks for any help,
Andreas
> Hi Jake,
> 
> thanks for fixing this. I have installed now the newly built package on
> my production system and will report, if any more core dumps occur.
> 
> Regards,
> Andreas
> -------------- next part --------------
# 2.2.25 (7be1766): /etc/opt/csw/dovecot/dovecot.conf
# OS: SunOS 5.11 i86pc  
auth_cache_negative_ttl = 0
auth_cache_size = 10 M
auth_master_user_separator = *
auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_
auth_username_format = %u
auth_worker_max_count = 1024
base_dir = /var/run/dovecot/
default_vsz_limit = 2 G
first_valid_gid = 30000
first_valid_uid = 30000
mail_location = maildir:%h/.maildir
mail_plugins = " mail_log notify"
mail_privileged_group = mail
namespace {
  hidden = no
  inbox = yes
  list = yes
  location = maildir:%h/.maildir
  prefix = 
  separator = /
  subscriptions = yes
  type = private
}
namespace inbox {
  hidden = yes
  inbox = no
  list = no
  location = maildir:%h/.maildir
  prefix = mail/
  separator = /
  subscriptions = no
  type = private
}
passdb {
  args = /etc/dovecot.deny
  deny = yes
  driver = passwd-file
}
passdb {
  args = /etc/opt/csw/dovecot/private/passwd.masterusers
  driver = passwd-file
  master = yes
}
passdb {
  args = blocking=yes cache_key=%u%s *
  driver = pam
}
pop3_uidl_format = %08Xv%08Xu
postmaster_address = postmaster at staff.uni-marburg.de
protocols = imap pop3
service auth-worker {
  user = $default_internal_user
}
service auth {
  client_limit = 6000
}
service imap-login {
  process_min_avail = 64
  service_count = 0
}
service imap {
  process_limit = 6000
}
ssl_cert = </etc/opt/csw/ssl/certs/imap.staff.uni-marburg.de.pem
ssl_key = </etc/opt/csw/ssl/private/imap.staff.uni-marburg.de.key
userdb {
  driver = passwd
}
protocol imap {
  mail_max_userip_connections = 25
  ssl_cert = </etc/opt/csw/ssl/certs/imap.staff.uni-marburg.de.pem
  ssl_key = </etc/opt/csw/ssl/private/imap.staff.uni-marburg.de.key
}
protocol pop3 {
  ssl_cert = </etc/opt/csw/ssl/certs/pop.staff.uni-marburg.de.pem
  ssl_key = </etc/opt/csw/ssl/private/pop.staff.uni-marburg.de.key
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5176 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20160901/918cf409/attachment-0001.p7s>

Aki Tuomi

2016-Sep-01 12:17 UTC

head link

2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

On 01.09.2016 14:20, Piper Andreas wrote:> Hello Timo,
>
> with the newly build CSW-package the crashes still occur, today already
> twice within two hours. The log shows always the same:
>
> Sep  1 11:50:13 surz113 dovecot: [ID 583609 mail.crit] imap(user):
> Panic: file imap-client.c: line 837 (client_check_command_hangs):
> assertion failed: (client->io != NULL)
> Sep  1 11:50:13 surz113 dovecot: [ID 583609 mail.error] imap(user):
> Error: Raw backtrace: 0xffff80ffb633d88d -> 0xffff80ffb636ae82 ->
> 0x41eba0 -> 0x41ecf3 -> 0xffff80ffb635d248 -> 0xffff80ffb6350d2f
->
> 0xffff80ffb63519e0 -> 0xffff80ffb6350dce -> 0xffff80ffb6350f90 ->
> 0xffff80ffb62e3ebb -> 0x42f169 -> 0x41292c
> Sep  1 11:50:13 surz113 dovecot: [ID 583609 mail.crit] imap(user):
> Fatal: master: service(imap): child 11227 killed with signal 6 (core not
> dumped - set service imap { drop_priv_before_exec=yes })
>
> This happens with different users, the last one with a relatively small
> mailbox of 600MB.
>
> doveconf -n is attached.
>
> Dovecot 2.2.25
> OS: Solaris 11 (SunOS 5.11 11.3 i86pc i386 i86pc)
> Virtualization: VMware
> Filesystem: ZFS
> active users: ~4000
>
> The system was transferred at beginning of last week from an old
> SPARC-station with Solaris 10 running dovecot-2.2.15 to this virtualized
> platform under VMware. The mailboxes (maildir-format) were transferred
> without change by switching the storage-hardware to the new server. I
> had to remove all dovecot.index*-files for errors of "CPU Architecture
> changed", but after doing this all seemed to work ok except for these
> occasional crashes.
>
> If you need more information, please let me know.
>
> Thanks for any help,
> Andreas
>
>> Hi Jake,
>>
>> thanks for fixing this. I have installed now the newly built package on
>> my production system and will report, if any more core dumps occur.
>>
>> Regards,
>> Andreas
>>
Hi!

Is it possible for you test out a small patch (attached) to see if it
fixes this issue?

Aki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.diff
Type: text/x-patch
Size: 569 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20160901/c229a18d/attachment.bin>

Apparently Analagous Threads

Search for more apparently analagous threads

dovecot - Sep 2016 - 2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

2.2.25 dumps core with "Panic: file imap-client.c: line 837 (client_check_command_hangs): assertion failed: (client->io != NULL)"

Apparently Analagous Threads