You will note my earlier post about the fact that a Get Multiple Entries sometimes returned a field id of 0 with a value of NULL for a display only field set (only sometimes) by a Get filter on the TMS:Task form. I was seeing this behaviour on ITSM 7.6 or ARS 7.5.
Is the SIGSEGV a manifestation of the underlying code problem? I am now having to check all returns from the API for completeness and generating NULL values for incomplete records. This is the only form that I have seen this happen on, so it seems like an excessive overhead to correct a behaviour problem in the API. There has been very little response to my earlier post - other than to "contact support" - for what may be a significant code problem. See if you can isolate and repeat the problem. You're only hope for a SIGSEGV is that a fix is supplied or perhaps by changing your logic you do not hit the area of bad code. Perhaps, a fix to the Get Fields filter to set the DO field to NULL if the associated enum field is also NULL may be a work-around. (If indeed your problem is related to the same thing that I saw). Cheers Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mike Worts Sent: March-07-12 18:01 To: [email protected] Subject: Re: Signal 11 error They are recommending a Filter-Max-Stack of 25 since our Filter Levels are not exceeding 14 (based on output of workflow log files), so, I am not sure if this will resolve the Signal 11 problem. Our ulimit settings are as follows: time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 4194304 memory(kbytes) 32768 coredump(blocks) 2097151 nofiles(descriptors) 2000 threads(per process) unlimited processes(per user) unlimited Mike. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Grooms, Frederick W Sent: 07 March 2012 15:25 To: [email protected] Subject: Re: Signal 11 error Is it the Maximum Filters for an Operation that is at 10000 or Max Stack of Filters they want changed? Both are at the top of the Advanced tab in the Server Information of the AR System Administration Console. The ar.conf entries are (From the 7.6.04 doc) Filter-Max-Stack Maximum number of recursion levels allowed for an operation. The data modification performed by an AR_FILTER_ACTION_FIELDP filter action might trigger a second set, or level, of filters, one of which might trigger a third level of filters and so on. This option limits the number of times such recursion can happen, preventing the server crash that would occur if the recursion continued indefinitely. The default value is 25. Filter-Max-Total Maximum number of filters that the server executes for a given operation. The default value is 10000. Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe Martin D'Souza Sent: Wednesday, March 07, 2012 8:47 AM To: [email protected] Subject: Re: Signal 11 error ** Mike, They are probably on the wrong track. 25 used to be the recommended max a few versions ago. 10000 on the current version and recommended configurations, is not a very high number. Is there anything written to the System or Application Event log at the time of that error? Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mike Worts Sent: Wednesday, March 07, 2012 8:29 AM To: [email protected] Subject: Signal 11 error ** 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. ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" 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 ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.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"
