Re: Signalled to death by 11 on imapd?
On Mon, 2 Jul 2001, 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. I had a similar problem, when upgrading from 2.0.12 to 2.0.14. Reverted to 2.0.12 (no time to debug now). .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED]
Signalled to death by 11 on imapd?
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. Thanks, Will 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
Re: Signalled to death by 11 on imapd?
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
Re: Signalled to death by 11 on imapd?
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 2868malloc.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=0xbb94, init=0x804ac30 _init, fini=0x80928ec _fini, rtld_fini=0x4000aea0 _dl_fini, stack_end=0xbb8c) 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 2763in 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=0xbb94, init=0x804ac30 _init, fini=0x80928ec _fini, rtld_fini=0x4000aea0 _dl_fini, stack_end=0xbb8c) 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
Re: signalled to death by 11?
ive seen so many reports about death by 11, if this error is removed from code, it should fix all this problems. ;)
Re[2]: signalled to death by 11?
Hey Seva, This could also be due to an overheating system. -- Kevin Friday, March 23, 2001, 11:48:29 AM, you wrote: SA This probably should be a FAQ item by now! One of the most SA common reasons for signal 11 (on Redhat systems) with cyrus SA is mismatch with the shared libraries. Often times it is the SA Berkeley db versions that come with the Redhat distribution SA coming in the way. SA You may want to do an ldd imapd, to check the libraries that SA the compiled version of your programs are picking, if they SA are not the same as the one that you built them with, then most SA likely, that is your problem. If the shared libraries look ok SA then you would have to deal with the logs and see if they have SA anything to offer and if they don't reveal anything, then you SA will probably have to deal with core itself by going into gdb SA and looking at the trace and see where it bombed! SA __ SA Seva SA Andreas Rogge wrote: --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
Re: signalled to death by 11?
Could you elaborate the reason for this observation. Why would an over heated system be discriminating imap server process and not the master process or for that matter any other process on the system? __ Seva Kevin J. Menard, Jr. wrote: Hey Seva, This could also be due to an overheating system. -- Kevin Friday, March 23, 2001, 11:48:29 AM, you wrote: SA This probably should be a FAQ item by now! One of the most SA common reasons for signal 11 (on Redhat systems) with cyrus SA is mismatch with the shared libraries. Often times it is the SA Berkeley db versions that come with the Redhat distribution SA coming in the way. SA You may want to do an ldd imapd, to check the libraries that SA the compiled version of your programs are picking, if they SA are not the same as the one that you built them with, then most SA likely, that is your problem. If the shared libraries look ok SA then you would have to deal with the logs and see if they have SA anything to offer and if they don't reveal anything, then you SA will probably have to deal with core itself by going into gdb SA and looking at the trace and see where it bombed! SA __ SA Seva SA Andreas Rogge wrote: --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
signalled to death by 11?
Hello, I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 I tried a search on the Web, but the closest I found was a reference to "signaled to death by 10" in the Cyrus "FAQ" (in quotes because I can't believe there are only four or five "frequently asked questions). Does anyone have any idea what this means? TIA. Cory
Re: signalled to death by 11?
--On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
Re: signalled to death by 11?
This probably should be a FAQ item by now! One of the most common reasons for signal 11 (on Redhat systems) with cyrus is mismatch with the shared libraries. Often times it is the Berkeley db versions that come with the Redhat distribution coming in the way. You may want to do an "ldd imapd", to check the libraries that the compiled version of your programs are picking, if they are not the same as the one that you built them with, then most likely, that is your problem. If the shared libraries look ok then you would have to deal with the logs and see if they have anything to offer and if they don't reveal anything, then you will probably have to deal with core itself by going into "gdb" and looking at the trace and see where it bombed! __ Seva Andreas Rogge wrote: --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
Re: signalled to death by 11?
There is something in the faq relative to DB versions/patches on signal to death by 10. 10 is a bus error 11 is a segmentation violation Both can be caused by dereferencing garbage pointers. You might check the faq relative to your DB version/patch. johnh... On Fri, 23 Mar 2001, Andreas Rogge wrote: Date: Fri, 23 Mar 2001 14:33:45 +0100 From: Andreas Rogge [EMAIL PROTECTED] To: Cory Waddingham [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: signalled to death by 11? --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
