Re: [AOLSERVER] Question on two AOLserver tickets
On 5/29/09 1:27 PM, Jade Rubick wrote: Personally, even though I think many in the community don't like Dossy acting without community involvement, I'd rather see something done than nothing, as long as it isn't harming the project. I definitely understand that people dislike my approach. I also know that things get discussed to death and nothing actually happens as a result, too. I lean heavily to the one extreme (action, little discussion) which understandably bothers people. Unfortunately, it's the way I am; it's how I know how to get things done. I like to believe that nothing I do intentionally harms the project on a technical level. Perhaps the problem is that there is no formal structure for Aolserver, so nobody has the authority to act on behalf of the community. I agree, this is probably a huge defect in the structure of the AOLserver project's organization and management. Thanks for raising the issue. What if we had a simple voting application somewhere, and the members of this mailing list each got a vote? I am very, very worried about a pure democracy approach as it often produces the Bikeshed Effect [1]. [1] http://en.wikipedia.org/wiki/Color_of_the_bikeshed In short, a large number of individuals abstain from voting on complex issues where they feel it would be inappropriate for them to vote as they're not qualified to decide either way. This results in very skewed representation of votes on difficult matters. Similarly, a large number of individuals vote on the trivial issues, which gives disproportionate weight to them, artificially inflating their perceived importance. In cases where a majority of 2/3rd's or some other criteria is required, reasonably trivial decisions can be unnecessarily held up due to lack of consensus. I'd really like to create a structure that empowers and enables the top of the anecdotal Pyramid of Participation (1% creators, 9% contributors, 90% lurkers). Perhaps participants on this list can help by brainstorming suggestions for such? My thoughts on the matter: the US Presidential election system and many corporations operate in a way that I think tries to achieve this goal, using proxy voters (electoral college, board of directors) whose intent is to represent its constituents. While polling the popular vote is interesting, ultimately the electoral college votes and decides the President. Of course, I'm very likely heavily biased being an American, thinking this system is a good one - if (any of) you have alternative models to suggest, please describe them. -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
Hi Dossy, To be frank, the only reason why I keep using the Trac ticket tracker is that it's the one I found. Had I known that the sourceforge ticket tracker was the active one, I would have used that one instead. Begs to question though... why two ticket trackers? Anyway, thanks everyone for all the valuable information! On May 21, 1:22 am, Dossy Shiobara do...@panoptic.com wrote: On 5/20/09 11:11 AM, Jim Davidson wrote: Yup -- agreed. I was talking with Dossy who says the Trac stuff is generally out of date anyway, the definitive bug list is still on Sourceforge (definitive in it's the place, can't say how accurate the bug reports are). I would love to hear that the AOLserver community prefers Trac for ticket tracking over SourceForge's tracker and that everyone would be happy if I refreshed the Trac tickets with a current snapshot of SourceForge data, and we could shut down the SourceForge tracker once and for all ... But, I don't want to kick that hornet's nest again, so I'll let someone else do it this time. :-) -- Dossy Shiobara | do...@panoptic.com |http://dossy.org/ Panoptic Computer Network |http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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. -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
On 5/20/09 11:11 AM, Jim Davidson wrote: Yup -- agreed. I was talking with Dossy who says the Trac stuff is generally out of date anyway, the definitive bug list is still on Sourceforge (definitive in it's the place, can't say how accurate the bug reports are). I would love to hear that the AOLserver community prefers Trac for ticket tracking over SourceForge's tracker and that everyone would be happy if I refreshed the Trac tickets with a current snapshot of SourceForge data, and we could shut down the SourceForge tracker once and for all ... But, I don't want to kick that hornet's nest again, so I'll let someone else do it this time. :-) -- Dossy Shiobara | do...@panoptic.com | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
I also checked on the other ticket I mentioned on the commit logs and it seems that the ticket may have been addressed with aolserver 4.5 too... so I think it's looking like everything is resolved. On May 20, 11:11 pm, Jim Davidson jgdavid...@mac.com wrote: Yup -- agreed. I was talking with Dossy who says the Trac stuff is generally out of date anyway, the definitive bug list is still on Sourceforge (definitive in it's the place, can't say how accurate the bug reports are). -Jim On May 15, 2009, at 6:35 PM, Jack Schmidt wrote: I guess if it's thread safe now, the ticket should be closed with a reference to aolserver 4.5. 2009/5/16 Jim Davidson jgdavid...@mac.com Hi, I'm looking at the head code and it appears it's now safe -- the connection list is walked with a pool lock held and the request data (method, url) seem to be copied with a global reqlock mutex held. Jade: What version of AOLserver are you using? -Jim On May 15, 2009, at 10:06 AM, Tom Jackson wrote: One thing which would be nice is to put the Tcl API into a module which as to be loaded, and keep the C API available in the core. It is obviously more work, but the admin has to make a choice to load the Tcl API, which is more open to misuse. I did something like this for a few additional ns_conn options. Gustaf's idea is easier to pull off at least initially, but it shouldn't be tied to an unrelated option like debugging. I leave on debugging for low traffic servers and I can also turn it on/off on a per-namespace basis. tom jackson On Thu, 2009-05-14 at 15:48 -0700, Sep Ng wrote: How about having the proc enable only if debug settings are turned on on AOLserver? -- 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. -- 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. -- A scrum a day keeps the pigs at bay -- 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. -- 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. -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
Tom Jackson schrieb: On Thu, 2009-05-14 at 18:08 -0400, Jim Davidson wrote: Good idea. Maybe it would make sense to disable it by default with some config flag to enable? I was thinking the same, but I wasn't sure how many people actually use this command. i would even recommend to push this to a compile option. The (sub)command could be always available but return in installed versions an empty result. The docs could say that ... this (sub)command is intended for debugging/developing aolserver and is normally deactivated. In order to avtivate it, compile aolsever with flag XXX. Be aware that this (sub)command is not thread save and can kill the aolserver when used with multiple threads -gustaf neumann -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
One thing which would be nice is to put the Tcl API into a module which as to be loaded, and keep the C API available in the core. It is obviously more work, but the admin has to make a choice to load the Tcl API, which is more open to misuse. I did something like this for a few additional ns_conn options. Gustaf's idea is easier to pull off at least initially, but it shouldn't be tied to an unrelated option like debugging. I leave on debugging for low traffic servers and I can also turn it on/off on a per-namespace basis. tom jackson On Thu, 2009-05-14 at 15:48 -0700, Sep Ng wrote: How about having the proc enable only if debug settings are turned on on AOLserver? -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
Hi, I'm looking at the head code and it appears it's now safe -- the connection list is walked with a pool lock held and the request data (method, url) seem to be copied with a global reqlock mutex held. Jade: What version of AOLserver are you using? -Jim On May 15, 2009, at 10:06 AM, Tom Jackson wrote: One thing which would be nice is to put the Tcl API into a module which as to be loaded, and keep the C API available in the core. It is obviously more work, but the admin has to make a choice to load the Tcl API, which is more open to misuse. I did something like this for a few additional ns_conn options. Gustaf's idea is easier to pull off at least initially, but it shouldn't be tied to an unrelated option like debugging. I leave on debugging for low traffic servers and I can also turn it on/off on a per-namespace basis. tom jackson On Thu, 2009-05-14 at 15:48 -0700, Sep Ng wrote: How about having the proc enable only if debug settings are turned on on AOLserver? -- 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. -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
I guess if it's thread safe now, the ticket should be closed with a reference to aolserver 4.5. 2009/5/16 Jim Davidson jgdavid...@mac.com Hi, I'm looking at the head code and it appears it's now safe -- the connection list is walked with a pool lock held and the request data (method, url) seem to be copied with a global reqlock mutex held. Jade: What version of AOLserver are you using? -Jim On May 15, 2009, at 10:06 AM, Tom Jackson wrote: One thing which would be nice is to put the Tcl API into a module which as to be loaded, and keep the C API available in the core. It is obviously more work, but the admin has to make a choice to load the Tcl API, which is more open to misuse. I did something like this for a few additional ns_conn options. Gustaf's idea is easier to pull off at least initially, but it shouldn't be tied to an unrelated option like debugging. I leave on debugging for low traffic servers and I can also turn it on/off on a per-namespace basis. tom jackson On Thu, 2009-05-14 at 15:48 -0700, Sep Ng wrote: How about having the proc enable only if debug settings are turned on on AOLserver? -- 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. -- 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. -- A scrum a day keeps the pigs at bay -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
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/152 is 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 entryargument 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 B45FFC54 ? B739FFE0 ? ndler()+214 gsignal()+71 signal 6 ? B460110C ? B460118C ? abort()+265 call gsignal()6 ? B460152C ? 0 ? B7FC1E84 ? B4601550 ? B4601564 ? NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ? 30 ? 46 ? B7F565F0 ? B7FC2420 call B ? 33 ? 0 ? 7B ? 7B ? C ? AppendConn()+117 call B7F74E20 B4601AE8 ? C ? 51C5 ? 0 ? 1 ? B7E46FF4 ? NsConnArgProc()+61 call AppendConn() B4601AE8 ? 80B0C1C ? B7FB51A2 ? ? 228E24D8 ? 0 ? Ns_GetProcInfo()+16 call B4601AE8 ? CD298C0 ? 1 B4601A28 ? B7F33C33 ? B4DF4EA1 ? B7E46BA0 ? ThreadArgProc()+43 call B7F74410 B4601AE8 ? B7F8E9B6 ? CD298C0 ? B7F6337C ? CCF7A20 ? Ns_ThreadList()+207 call B4601AE8 ? B7F8E9B6 ? CD298C0 ? 0 ? 4A0935D9 ? B7FBB174 ? NsTclInfoObjCmd()+5 call B7F73B30 B4601AE8 ? B7F8917B ? 46 B7FBC080 ? B7FB34D3 ? 0 ? B4601AE4 ? TclEvalObjvInternal call EF0B1C0 ? CE907D0 ? 2 ? ()+819 EC701D8 ? B304D010 ? A7DBAE50 ? TclExecuteByteCode( call _init()+184 CE907D0 ? 2 ? EC701D8 ? 0 ? )+107130 ? 0 ? TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 0 ? 0 ? 0 ? 2 )B4602924 ? 34ECE ? TclObjInterpProc()+ call B7EBE8E0 CE907D0 ? ABF19440 ? 645120C4660 ? 1 ? B7F565F0 ? 18 ? TclEvalObjvInternal call ABF78CE8 ? CE907D0 ? 1 ? ()+819 EC701D4 ? B7F565F0 ? A7DBB540 ? TclExecuteByteCode( call _init()+184 CE907D0 ? 1 ? EC701D4 ? 0 ? )+107130 ? 0 ? TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 3 ? 3 ? B7F565F0 ? 2 )B4602924 ? 34EC2 ? TclObjInterpProc()+ call B7EBE8E0 CE907D0 ?
Re: [AOLSERVER] Question on two AOLserver tickets
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/152 is 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 entryargument 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 B45FFC54 ? B739FFE0 ? ndler()+214 gsignal()+71 signal 6 ? B460110C ? B460118C ? abort()+265 call gsignal()6 ? B460152C ? 0 ? B7FC1E84 ? B4601550 ? B4601564 ? NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ? 30 ? 46 ? B7F565F0 ? B7FC2420 call B ? 33 ? 0 ? 7B ? 7B ? C ? AppendConn()+117 call B7F74E20 B4601AE8 ? C ? 51C5 ? 0 ? 1 ? B7E46FF4 ? NsConnArgProc()+61 call AppendConn() B4601AE8 ? 80B0C1C ? B7FB51A2 ? ? 228E24D8 ? 0 ? Ns_GetProcInfo()+16 call B4601AE8 ? CD298C0 ? 1 B4601A28 ? B7F33C33 ? B4DF4EA1 ? B7E46BA0 ? ThreadArgProc()+43 call B7F74410 B4601AE8 ? B7F8E9B6 ? CD298C0 ? B7F6337C ? CCF7A20 ? Ns_ThreadList()+207 call B4601AE8 ? B7F8E9B6 ? CD298C0 ? 0 ? 4A0935D9 ? B7FBB174 ? NsTclInfoObjCmd()+5 call B7F73B30 B4601AE8 ? B7F8917B ? 46 B7FBC080 ? B7FB34D3 ? 0 ? B4601AE4 ? TclEvalObjvInternal call EF0B1C0 ? CE907D0 ? 2 ? ()+819 EC701D8 ? B304D010 ? A7DBAE50 ? TclExecuteByteCode( call _init()+184 CE907D0 ? 2 ? EC701D8 ? 0 ? )+107130 ? 0 ? TclCompEvalObj()+15 call TclExecuteByteCode( CE907D0 ? 0 ? 0 ? 0 ? 2 )
Re: [AOLSERVER] Question on two AOLserver tickets
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/152 is 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 entryargument 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 B45FFC54 ? B739FFE0 ? ndler()+214 gsignal()+71 signal 6 ? B460110C ? B460118C ? abort()+265 call gsignal()6 ? B460152C ? 0 ? B7FC1E84 ? B4601550 ? B4601564 ? NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ? 30 ? 46 ? B7F565F0 ? B7FC2420 call B ? 33 ? 0 ? 7B ? 7B ? C ? AppendConn()+117 call B7F74E20 B4601AE8 ? C ? 51C5 ? 0 ? 1 ? B7E46FF4 ? NsConnArgProc()+61 call AppendConn() B4601AE8 ? 80B0C1C ? B7FB51A2 ? ? 228E24D8 ? 0 ? Ns_GetProcInfo()+16 call B4601AE8 ? CD298C0 ? 1 B4601A28 ? B7F33C33 ? B4DF4EA1 ? B7E46BA0 ? ThreadArgProc()+43 call B7F74410 B4601AE8 ? B7F8E9B6 ? CD298C0 ? B7F6337C ? CCF7A20 ? Ns_ThreadList()+207 call B4601AE8 ? B7F8E9B6 ? CD298C0 ? 0 ? 4A0935D9 ? B7FBB174 ? NsTclInfoObjCmd()+5 call B7F73B30 B4601AE8 ? B7F8917B ? 46 B7FBC080 ? B7FB34D3 ? 0 ? B4601AE4 ? TclEvalObjvInternal call EF0B1C0 ? CE907D0 ? 2 ? ()+819 EC701D8 ? B304D010 ? A7DBAE50 ? TclExecuteByteCode( call _init()+184 CE907D0 ? 2 ? EC701D8 ? 0
Re: [AOLSERVER] Question on two AOLserver tickets
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/ 152 is 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 entryargument 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 B45FFC54 ? B739FFE0 ? ndler()+214 gsignal()+71 signal 6 ? B460110C ? B460118C ? abort()+265 call gsignal()6 ? B460152C ? 0 ? B7FC1E84 ? B4601550 ? B4601564 ? NsBlockSignals() call B7F749F0 3 ? B7FB9ED5 ? B ? 30 ? 46 ? B7F565F0 ? B7FC2420 call B ? 33 ? 0 ? 7B ? 7B ? C ? AppendConn()+117 call B7F74E20 B4601AE8 ? C ? 51C5 ? 0 ? 1 ? B7E46FF4 ? NsConnArgProc()+61 call AppendConn() B4601AE8 ? 80B0C1C ? B7FB51A2 ? ? 228E24D8 ? 0 ? Ns_GetProcInfo()+16 call B4601AE8 ? CD298C0 ? 1 B4601A28 ? B7F33C33 ? B4DF4EA1 ? B7E46BA0 ?
Re: [AOLSERVER] Question on two AOLserver tickets
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/152 is 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 ?
Re: [AOLSERVER] Question on two AOLserver tickets
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/152 is 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
B45FFC54 ?
B739FFE0 ?
ndler()+214
gsignal()+71 signal
6 ? B460110C ?
Re: [AOLSERVER] Question on two AOLserver tickets
On Thu, 2009-05-14 at 18:08 -0400, Jim Davidson wrote: Good idea. Maybe it would make sense to disable it by default with some config flag to enable? I was thinking the same, but I wasn't sure how many people actually use this command. This must be one of a very few commands that I have never used, so I'm far from informed on what it is used for. Sent from my iPhone Sent via a local network shared with an iTouch. tom jackson -- 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.
Re: [AOLSERVER] Question on two AOLserver tickets
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
