Signal 11 is a segmentation fault (man signal.h). From http://en.wikipedia.org/wiki/SIGSEGV:
*Computer programs may throw SIGSEGV for improper memory handling (see segmentation fault). The operating system may inform the application of the nature of the error using the signal stack, which developers can use to debug their programs or handle errors.* * * *The default action for a program upon receiving SIGSEGV is abnormal termination. This action will end the process, but may generate a core file to aid debugging, or perform some other platform-dependent action. For example, Linux systems using the grsecurity patch may log SIGSEGV signals in order to monitor for possible intrusion attempts using buffer overflows.* * * *SIGSEGV can be caught; that is, applications can request what action they want to occur in place of the default. Examples of such action might be ignoring it, calling a function, or restoring the default action. In some circumstances, ignoring SIGSEGV results in undefined behavior.[2]* * * *An example of an application that might handle SIGSEGV is a debugger, which might check the signal stack and inform the developer of what happened, and where the program terminated.* * * *SIGSEGV is usually generated by the operating system, but users with appropriate permissions can use the kill system call or kill command (a userland program, or sometimes a shell builtin) to send the signal to a process at will.* If you have all the logs up to the crash, look in those logs for the user, RPC Queue, RPC ID, and Thread Id in the logs. The log lines will contain those identifiers. Thread Id: 8759 RPC Id: 460531 RPC Queue: 390635 Client: User dan.henry from Mid-tier (protocol 18) at IP address 10.161.64.162 You should be able to tell the OS to generate a core file when the process exits with this signal. If you can get a core file, you can look at the stack trace to get a better idea of the cause of the segmentation fault. Working with support in the past, I was informed that exhausting the stack can result in a SIGSEGV. The max stack size is typically controlled by user limits (man ulimit). $ ulimit -s 8192 $ ulimit -Hs unlimited Those numbers are in kilobytes. Axton Grams On Wed, Mar 7, 2012 at 8:29 AM, Mike Worts <[email protected]> wrote: > ** > > Hi all, > > We just had this error message on our AR Server and I have a few question > about it if anyone can help please. > > 1. Is this a memory error that has caused arserverd to crash as I cannot > find any core dumps? > 2. Is Signal 11 an application generated error, on an AIX error? > 3. What is the relevance of the Form:TMS:Task value > 4. We had API/FILTER/SQL logging on at the time, what should I be looking > for to point me to the cause? > > Wed Mar 7 13:09:18 2012: AR System server terminated when a > signal/exception was received by the server (ARNOTE 20) > Signal: 11 > Thread Id: 8759 > Version: 7.6.04 SP1 201104191058 Apr 27 2011 20:10:00 > ServerName: > Database: SQL -- Oracle > Hardware: 00F6282E4C00 > OS: AIX 6.1 > RPC Id: 460531 > RPC Call: 73 (GLEWF) > RPC Queue: 390635 > Client: User dan.henry from Mid-tier (protocol 18) at IP address > 10.161.64.162 > Form: TMS:Task > Logging On: Alert API Escalation Filter SQL User FTIndexer Thread > ServerGroup > Stacks: > Stacks: > I have discussed this with BMC and one possible cause is our > Filter-Max-Stack is set to '10000'. They have asked us to reduce it to '25'. > does anyone know if it will have an adverse effect on ITSM (I assume 25 is > the recommended settings). > > AIX 6.1 > ITSM 7.6.04 SP1 > AR 7.6.04 SP1 > Oracle 11g > > Thanks, > > Mike Worts. > > This email, its content and any files transmitted with it are for the > personal attention of the addressee only, any other usage or access is > unauthorised. It may contain information which could be confidential or > privileged. If you are not the intended addressee you may not copy, > disclose, circulate or use it. > > If you have received this email in error, please destroy it and notify the > sender by email. Any representations or commitments expressed in this email > are subject to contract. > > Although we use reasonable endeavours to virus scan all sent emails, it is > the responsibility of the recipient to ensure that they are virus free and > we advise you to carry out your own virus check before opening any > attachments. We cannot accept liability for any damage sustained as a result > of software viruses. We reserve the right to monitor email communications > through our networks. > > Arqiva Limited. Registered office: Crawley Court, Winchester, Hampshire SO21 > 2QA United Kingdom Registered in England and Wales number 2487597 > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
