On 2002.11.05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote: > > Do you have any home-brewn C-level extensions loaded? > Or, better yet, what extensions do you have loaded?
Nope. The only thing that's loaded is nssock. No nslog even! It's a series of Tcl proc's, some of which get registered as ns_register_proc to handle HTTP requests, one that gets scheduled using ns_schedule_proc, and others that get called by those procs. Extensive use of nsv's to persist memory in the running nsd, and the ns_schedule_proc'ed periodically goes through the memory stored in nsv's and persists it to disk and nsv_unset's things. > The problem is *probably* somewhere in thread-exit. > You say, you kick a thread or two with ns_schedule_proc? > There might be something bad happening during teardown. > It would be interesting to know wether the same (core) > happens when/if you (can) schedule a proc w/o extra thread > (i.e. w/o -thread option)? Since this is a production system, and this error only occured once so far, I'm not inclined to go "tinkering" with it. I've never been able to get this problem to occur in the dev. environment even under load, so I'm perplexed. I'm going to be keeping an eye on it. Hopefully if this happens again, it'll drop a core file -- previously, the directory I started nsd from was owned by root and not writable by the user nsd was -u'ed to run as. I've changed that, so hopefully I'll get a corefile next time. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.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)
