Ken,
Here's what I did, and got. I'm not much of one for using debuggers, so I'm
not 100% sure I did what was needed. If there's anything more I can do to
help, I'll be glad to do so. (I've got several cores available, too. :)
This GDB was configured as "i386-redhat-linux".
(gdb) file /usr/cyrus/bin/imapd
Reading symbols from /usr/cyrus/bin/imapd...done.
(gdb) core-file /var/spool/imap/w/user/whardeman/core
Core was generated by `imapd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libsasl.so.7...done.
Reading symbols from /usr/local/db3/lib/libdb-3.2.so...done.
Reading symbols from /usr/local/ssl/lib/libssl.so.0.9.6...done.
Reading symbols from /usr/local/ssl/lib/libcrypto.so.0.9.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /usr/lib/sasl/libcrammd5.so...done.
Reading symbols from /usr/lib/sasl/libdigestmd5.so...done.
Reading symbols from /usr/lib/sasl/libplain.so...done.
Reading symbols from /usr/lib/sasl/liblogin.so...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /lib/libnss_nisplus.so.2...done.
Reading symbols from /lib/libnss_nis.so.2...done.
#0 chunk_alloc (ar_ptr=0x40341d40, nb=128) at malloc.c:2868
2868 malloc.c: No such file or directory.
(gdb) bt
#0 chunk_alloc (ar_ptr=0x40341d40, nb=128) at malloc.c:2868
#1 0x402ac5ae in __libc_malloc (bytes=124) at malloc.c:2696
#2 0x400aeeff in __os_malloc () from /usr/local/db3/lib/libdb-3.2.so
#3 0x400aee50 in __os_calloc () from /usr/local/db3/lib/libdb-3.2.so
#4 0x400b9f27 in __qam_db_create () from /usr/local/db3/lib/libdb-3.2.so
#5 0x4006fcf9 in __db_init () from /usr/local/db3/lib/libdb-3.2.so
#6 0x4006f94d in db_create () from /usr/local/db3/lib/libdb-3.2.so
#7 0x40022805 in berkeleydb_open () from /usr/lib/libsasl.so.7
#8 0x40022afe in getsecret () from /usr/lib/libsasl.so.7
#9 0x40016335 in server_continue_step () from /usr/lib/sasl/libcrammd5.so
#10 0x4001f6cb in sasl_server_step () from /usr/lib/libsasl.so.7
#11 0x8051381 in cmd_authenticate ()
#12 0x804e4f1 in cmdloop ()
#13 0x804dd3a in service_main ()
#14 0x804c329 in main ()
#15 0x4026b9cb in __libc_start_main (main=0x804bc18 <main>, argc=1,
argv=0xbffffb94, init=0x804ac30 <_init>,
fini=0x80928ec <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xbffffb8c)
at ../sysdeps/generic/libc-start.c:92
(gdb) core-file /var/spool/imap/v/user/vmatal/core
Core was generated by `imapd'.
Program terminated with signal 11, Segmentation fault.
#0 0x402ac6e9 in chunk_alloc (ar_ptr=0x40341d40, nb=96) at malloc.c:2763
2763 in malloc.c
(gdb) bt
#0 0x402ac6e9 in chunk_alloc (ar_ptr=0x40341d40, nb=96) at malloc.c:2763
#1 0x402ac5ae in __libc_malloc (bytes=92) at malloc.c:2696
#2 0x808abdf in xmalloc ()
#3 0x808cb38 in auth_newstate ()
#4 0x804d5bb in mysasl_authproc ()
#5 0x4001f31e in do_authorization () from /usr/lib/libsasl.so.7
#6 0x4001f6d9 in sasl_server_step () from /usr/lib/libsasl.so.7
#7 0x8051381 in cmd_authenticate ()
#8 0x804e4f1 in cmdloop ()
#9 0x804dd3a in service_main ()
#10 0x804c329 in main ()
#11 0x4026b9cb in __libc_start_main (main=0x804bc18 <main>, argc=1,
argv=0xbffffb94, init=0x804ac30 <_init>,
fini=0x80928ec <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xbffffb8c)
at ../sysdeps/generic/libc-start.c:92
I've included 2 bt's from 2 different cores, just to give a second
reference point.
Thanks for the help,
Will
--On Monday, 02 July, 2001 21:18 -0400 Ken Murchison <[EMAIL PROTECTED]> wrote:
>
>
> "William K. Hardeman" wrote:
>>
>> Howdy all,
>>
>> Has anyone found a solution or workaround to the 'signalled to death by
>> 11' issue with imapd processes? This seems to occur randomly for us,
>> although more frequently when using a webmail interface than with
>> mulberry or outlook 2000. I did a gdb core-file on one of the cores
>> produced, but all I knew that it told me was that the process had seg
>> faulted.
>
> If you still have the core file (and associated executable) can you do a
> backtrace (bt) in gdb?
>
> Ken
> --
> Kenneth Murchison Oceana Matrix Ltd.
> Software Engineer 21 Princeton Place
> 716-662-8973 x26 Orchard Park, NY 14127
> --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
>
----------------------------------------------------------------------------
William K. Hardeman
[EMAIL PROTECTED]
http://www.wkh.org
Always listen to experts. They'll tell you what can't be done and why. Then
do it.
--Robert A. Heinlein
