[Dovecot] Imap segfault on login with version 2.0.8 & 2.0.11

[Nick VonHollen]

I feel pretty dumb.

When I converted the config file, I somehow set vsz_limit to 1k.  The child process tries to load its core libraries, runs out of virtual memory, and is killed.  

We have a lot of limits set in the config file, and I've seen warnings for other limits, but not this one.

Hopefully, someone else sees this and doesn't do the same thing.  Would it make sense to raise some warnings for the vsz_limit  itself?  At least for some insanely low number like <= 1M?

Thanks,
Nick

"Nicholas VonHollen" <nickv at mailtrust.com> said:

> "Timo Sirainen" <tss at iki.fi> said:
> 
>> On 8.4.2011, at 0.17, Nicholas VonHollen wrote:
>>
>>> Thanks for helping me out.  It looks like no matter what I do, changing the
>>> executable line doesn't help.  I even changed it to "executable = /bin/false"
>>> and
>>> it still reports a segfault.  I verified the config with "dovecot -n", stopped
>>> using the "-c /etc/dovecot.conf", moved the conf file to the appropriate place,
>>> re-verified it, and I still can't affect it.  I assume the crash is happening
>>> post-fork, pre-exec, if there is custom code for launching child processes.
>>> Since strace 'fixes' the problem, I'll try to figure it out under gdb, but to be
>>> honest, my C debugging skills are very rusty.
>>
>> Ah, yes:
>>
>>> Apr  7 17:29:05 localhost dovecot: master: Error: service(imap): child 9690
>>> killed with signal 11 (core dumps disabled)
>>
>> It has "master:" prefix so it's pre-exec. But you got a core file earlier, right?
>> You should be able to get a usable gdb backtrace then with "gdb dovecot core".
>>
> 
> 
> GDB still complains "warning: core file may not match specified executable file."
> when using anything but /bin/false.  I tried using "gdb dovecot corefile" but got
> the same trace with nothing but _start.  Is it possible to crash post-exec and
> pre-main?  I'm not sure that makes sense, lol.  You can't really pass pointers to
> child processes, so maybe ld is somehow screwed up?  I can try it on a different
> OS with a similar RPM.
> 
> 
> 
> Nick VonHollen
> Rackspace Software Developer
> Desk: 540-443-2003 (internal 505-2003)
> Personal Cell: 757-710-7038
> 
> 
> 


Nick VonHollen
Rackspace Software Developer
Desk: 540-443-2003 (internal 505-2003)
Personal Cell: 757-710-7038