You're using cvs HEAD, right? (Last change was 8 days ago).
But you're using nsd/init.tcl from 4.99.1? There's been quite a few
changes here. I don't think the current version forces you to use
nstrace. But if there are specific problems with the way
initialisation is happening, let us know.
The current version, for example, calls ns_set cleanup as an interp
trace. It should never be necessary to call this yourself.
% join [ns_ictl gettraces deallocate] \n
ns:tcltrace ns_cleanup
nsdb:releasehandles a:(nil)
nsproxy:cleanup a:(nil)
ns_cleanup looks like this:
proc ns_cleanup {} {
ns_cleanupchans; # Close files
ns_cleanupvars; # Destroy global variables
ns_set cleanup; # Destroy non-shared sets
ns_http cleanup; # Abort any http requests
ns_ictl cleanup; # Run depreciated 1-shot Ns_TclRegisterDefer's.
}
'deallocate' traces get run when some C code is finished running some
Tcl code in an interp. Interps are cached per-thread. So we can see
from above that set's are per-interp and the interp is cleaned after
each request.
More here:
http://www.crystalballinc.com/vlad/software/naviserver/files/mann/ns_ictl.html
Anyway, regardless of all that it still shouldn't crash :-)
This works for me (no xotcl):
$ ./config --prefix=/tmp/ns --enable-symbols --with-tcl=...
$ make install
$ make gdbruntest
% ns_eval {{proc ::defaultRequestHandler {args} {
ns_return 200 text/plain yo
ns_set cleanup
return
}}}
% ns_register_proc GET /* ::defaultRequestHandler
% time {nstest_http -getbody 1 GET /} 1000
Do any of the tests fail for you? Run: make test.
If you build with --enable-symbols you'll be able to run 'info locals'
and 'backtrace' in gdb and get some more information.
Try this:
ns_section "ns/server/server1/module/nssock"
ns_param keepwait 0
Does it crash immediately (or sooner) than num-threads-requests?
Try this:
ns_section "ns/server/server1/module/nssock"
ns_param writersize 0
Does that prevent the crash?
On 7/31/07, Neophytos Demetriou <[EMAIL PROTECTED]> wrote:
> Here is the data I have at the moment:
>
> * Server crashes every 40 page requests
> (times 39 dependent files, i.e. js, css, ajax, etc)
>
> * Only one thread per page request is used (background delivery
> mechanism). Hence, the number 40 matches the allowable
> maxthreads/minthreads (see configuration below).
>
> * Crashes with/without zippy allocator.
>
> * Crashes with/without HackContentEncoding.
>
> * gdb output:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 49156 (LWP 29203)]
> 0xb7f433cc in Ns_SetFindCmp () from
> /opt/naviserver-4.99.2/lib/libnsd.so
>
> (gdb) continue
> Continuing.
>
> Program received signal SIGABRT, Aborted.
> 0xb7d30c51 in kill () from /lib/libc.so.6
>
> * However, the Ns_SetFindCmp code does not seem to be the culprit.
>
> * Request handler is as follows:
>
> proc ::defaultRequestHandler {args} {
> set o [::xo::RequestHandler new]
> $o respond
> $o destroy
> #ns_set cleanup
> return
> }
>
> foreach method {GET HEAD POST} {
> ns_register_proc $method / ::defaultRequestHandler
> }
>
> * If you uncomment the "ns_set cleanup" line, no fatal signal is
> received. However, a server error occurs at the threshold (40 requests
> times 39 dependent files) due to the fact that the form-conn ns_set is
> not found (I haven't checked how NS uses sets per thread (my guess is
> that it creates a persistent ns_set per thread).
>
> * NS configuration synopsis:
> - 4.99.1 init.tcl (see previous thread, i.e. xotcl)
> - without nstrace
> - progressminsize/uploadsize 10000 bytes
> - 4 spooler writer/reader
> - MaxThreads 40
> - MinThreads 40
> - MaxConnections 120
> - MaxDropped 0
>
>
> I plan to investigate this further in the following days. If you have
> any suggestions/comments/help please do not hesitate to post (or contact
> me).
>
> Best wishes,
> Neophytos
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
