How about having the proc enable only if debug settings are turned on on AOLserver?
On May 15, 6:08 am, Jim Davidson <jgdavid...@mac.com> wrote: > Good idea. Maybe it would make sense to disable it by default with > some config flag to enable? > Jim > > Sent from my iPhone > > On May 14, 2009, at 4:49 PM, Tom Jackson <t...@rmadilo.com> wrote: > > > Maybe calling the API should result in a ns_log Warning to indicate a > > potential crash. > > > tom jackson > > > On Thu, 2009-05-14 at 13:26 -0700, Jade Rubick wrote: > >> I'm just happy we figured it out. > > >> We were using this call: > > >> set connections [ns_server active] > > >> But it wasn't in a scheduled proc, so I just moved it behind a > >> password protection section, and put a warning around it. We seldom > >> (never) used that page anyway. I think a bot may have found it or > >> something. > > >> Jade > > >> Jade Rubick > > >> Director of Development > >> TRUiST > > >> 120 Wall Street, 4th Floor > > >> New York, NY 10005 USA > > >> jrub...@truist.com > >> +1 503 285 4963 > >> +1 707 671 1333 fax > > >>www.truist.com > > >> The information contained in this email/document is confidential and > >> may be legally privileged. Access to this email/document by anyone > >> other than the intended recipient(s) is unauthorized. If you are not > >> an intended recipient, any disclosure, copying, distribution, or any > >> action taken or omitted to be taken in reliance to it, is prohibited. > > >> On May 14, 2009, at 12:33 PM, Jim Davidson wrote: > > >>> Yup -- should really have been documented better -- sorry about > >>> that. > > >>> Anyway, what is the monitoring attempting to dig up? There may some > >>> other safe ways to get the same. > > >>> -Jim > > >>> On May 14, 2009, at 2:04 PM, Jade Rubick wrote: > > >>>> Ironically, we have some monitoring code that does use that > >>>> functionality. > > >>>> So our monitoring is killing our servers. Nice! > > >>>> I'm removing that code now. > > >>>> Jade Rubick > >>>> Director of Development > >>>> TRUiST > >>>> 120 Wall Street, 4th Floor > >>>> New York, NY USA > >>>> jrub...@truist.com > >>>> +1 503 285 4963 > >>>> +1 707 671 1333 fax > > >>>>www.truist.com > > >>>> The information contained in this email/document is confidential > >>>> and may be legally privileged. Access to this mail/document by > >>>> anyone other than the intended recipient(s) is unauthorized. If > >>>> you are not an intended recipient, any disclosure, copying, > >>>> distribution, or any action taken or omitted to be taken in > >>>> reliance to it, is prohibited. > > >>>> On Thu, May 14, 2009 at 10:19 AM, Jim Davidson > >>>> <jgdavid...@mac.com> wrote: > >>>> Hi, > > >>>> Do you have some sort of background job that calls > >>>> "ns_server active" (or similar) regularly? That could > >>>> lead to random crashes. The description in > >>>> http://dev.aolserver.com/trac/ticket/152is accurate: The > >>>> code, by design, is not strictly safe as it's assumed to > >>>> only be used interactively and occasionally as part of > >>>> debugging and performance monitoring/optimization. > > >>>> To make it safe would require adding mutex locks around > >>>> areas that are assumed read-only and/or single-threaded > >>>> which could possibly lead to lock contention. I can't say > >>>> it those assumptions have ever been proven true or false > >>>> but that was my thinking when the code was first written. > > >>>> -Jim > > >>>> On May 14, 2009, at 4:16 AM, Sep Ng wrote: > > >>>> Hi, > > >>>> I'm trying to debug an AOLserver crash and the > >>>> point of crash seems to > >>>> be AppendConn in NS_GetProcInfo... I will post the > >>>> stack trace after > >>>> just for reference. > > >>>> Looking through the ticket tracker on AOLserver, I > >>>> found two tickets > >>>> of particular interest: > > >>>> http://dev.aolserver.com/trac/ticket/325 > >>>> --> My question with this ticket is was it ever > >>>> resolved? > > >>>> and the second ticket: > > >>>> http://dev.aolserver.com/trac/ticket/152 > >>>> --> This problem should only happen if the command > >>>> ns_server was > >>>> called in a multi-threaded environment, right? > > >>>> Here is the call stack trace I'm working with. > >>>> I'm more interested in > >>>> Ticket #325 as it may be related to my problem. > > >>>> ----- Call Stack Trace ----- > >>>> calling call entry > >>>> argument values in > >>>> hex > >>>> location type point > >>>> (? means dubious > >>>> value) > >>>> -------------------- -------- -------------------- > >>>> ---------------------------- > >>>> kpedbg_dmp_stack()+ call B5B81884 > >>>> B45FFB74 ? 0 ? > >>>> 219 > >>>> kpeDbgCrash()+72 call B5B75E14 > >>>> 0 ? 5 ? 0 ? > >>>> 80BD810 ? > > >>>> B45FFC08 ? > >>>> B45FFBF0 ? > >>>> kpeDbgSignalHandler call B5B867B4 > >>>> 0 ? 5 ? B72A331C ? > >>>> 2 ? 4 ? > >>>> ()+107 > >>>> 5F ? 4 ? B4600C5D ? > >>>> skgesig_sigactionHa call 00000000 > >>>> B45FFC54 ? > >>>> B739FFE0 ? > >>>> ndler()+214 > >>>> gsignal()+71 signal 00000000 > >>>> 6 ? B460110C ? > >>>> B460118C ? > >>>> abort()+265 call gsignal() > >>>> 6 ? B460152C ? 0 ? > >>>> B7FC1E84 ? > > >>>> B4601550 ? > >>>> B4601564 ? > >>>> NsBlockSignals() call B7F749F0 > >>>> 3 ? B7FB9ED5 ? B ? > >>>> 30 ? 46 ? > > >>>> B7F565F0 ? > >>>> B7FC2420 call 00000000 > >>>> B ? 33 ? 0 ? 7B ? > >>>> 7B ? C ? > >>>> AppendConn()+117 call B7F74E20 > >>>> B4601AE8 ? C ? > >>>> 51C5 ? 0 ? 1 ? > > >>>> B7E46FF4 ? > >>>> NsConnArgProc()+61 call AppendConn() > >>>> B4601AE8 ? > >>>> 80B0C1C ? > > >>>> B7FB51A2 ? > >>>> FFFFFFFF ? > > >>>> 228E24D8 ? 0 ? > >>>> Ns_GetProcInfo()+16 call 00000000 > >>>> B4601AE8 ? > >>>> CD298C0 ? > >>>> 1 > >>>> B4601A28 ? > >>>> B7F33C33 ? > > >>>> B4DF4EA1 ? > >>>> B7E46BA0 ? > >>>> ThreadArgProc()+43 call B7F74410 > >>>> B4601AE8 ? > >>>> B7F8E9B6 ? > > >>>> CD298C0 ? > >>>> B7F6337C ? > > >>>> CCF7A20 ? > >>>> Ns_ThreadList()+207 call 00000000 > >>>> B4601AE8 ? > >>>> B7F8E9B6 ? > > >>>> CD298C0 ? 0 ? > >>>> 4A0935D9 ? > > >>>> B7FBB174 ? > >>>> NsTclInfoObjCmd()+5 call B7F73B30 > >>>> B4601AE8 ? > >>>> B7F8917B ? > >>>> 46 > >>>> B7FBC080 ? > >>>> B7FB34D3 ? 0 ? > > >>>> B4601AE4 ? > >>>> TclEvalObjvInternal call 00000000 > >>>> EF0B1C0 ? CE907D0 ? > >>>> 2 ? > >>>> ()+819 > >>>> EC701D8 ? > >>>> B304D010 ? > > >>>> A7DBAE50 ? > >>>> TclExecuteByteCode( call _init()+184 > >>>> CE907D0 ? 2 ? > >>>> EC701D8 ? 0 ? > >>>> )+10713 > >>>> 0 ? 0 ? > >>>> TclCompEvalObj()+15 call > >>>> TclExecuteByteCode( CE907D0 ? 0 ? 0 ? > >>>> 0 ? > >>>> 2 ) > >>>> B4602924 ? 34ECE ? > >>>> TclObjInterpProc()+ call B7EBE8E0 > >>>> CE907D0 ? > >>>> ABF19440 ? > >>>> 645 > >>>> 120C4660 ? 1 ? > >>>> B7F565F0 ? > > >>>> 18 ? > >>>> TclEvalObjvInternal call 00000000 > >>>> ABF78CE8 ? > >>>> CE907D0 ? 1 ? > >>>> ()+819 > >>>> EC701D4 ? > >>>> B7F565F0 ? > > >>>> A7DBB540 ? > >>>> TclExecuteByteCode( call _init()+184 > >>>> CE907D0 ? 1 ? > >>>> EC701D4 ? 0 ? > >>>> )+10713 > >>>> 0 ? 0 ? > >>>> TclCompEvalObj()+15 call > >>>> TclExecuteByteCode( CE907D0 ? 3 ? 3 ? > >>>> B7F565F0 ? > >>>> 2 ) > >>>> B4602924 ? 34EC2 ? > >>>> TclObjInterpProc()+ call B7EBE8E0 > >>>> CE907D0 ? > >>>> ABF19320 ? > >>>> 645 > >>>> 120C4260 ? 1 ? > >>>> 100 ? 100 ? > >>>> TclEvalObjvInternal call 00000000 > >>>> ABF76E28 ? > >>>> CE907D0 ? 2 ? > >>>> ()+819 > >>>> EC701CC ? > >>>> B7F565F0 ? > > >>>> A7DBAE50 ? > >>>> TclExecuteByteCode( call _init()+184 > >>>> CE907D0 ? 2 ? > >>>> EC701CC ? 0 ? > >>>> )+10713 > >>>> 0 ? 0 ? > >>>> TclCompEvalObj()+15 call > >>>> TclExecuteByteCode( CE907D0 ? 0 ? > >>>> B7F2F0AB ? > >>>> 2 ) > > ... > > read more ยป -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <lists...@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
