Dear Stephen,
Thank you very much for your message.
Stephen Deasey wrote:
> You're using cvs HEAD, right? (Last change was 8 days ago).
Yes, I'm using CVS HEAD.
I have to head out of the office/town for the next few hours but I plan
to work on it again when I'm back. I'll post a reply to your message, in
detail, this evening.
Thanks again.
Best wishes,
Neophytos
> 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
-------------------------------------------------------------------------
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
