Menu
▾
▴
naviserver-devel
|
From: Neophytos D. <k2...@ph...> - 2007-07-31 09:04:13
|
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
|
|
From: Maksym Z. <siq...@gm...> - 2021-09-25 16:10:48
|
Hello everyone, 2 latest commits are not letting me start naviserver. It just crashes without any log with message Fatal: received fatal signal 11. This one works fine: e11e014 Cheers. Maksym Zinchenko |
|
From: Gustaf N. <ne...@wu...> - 2021-09-25 22:51:56
|
On 25.09.21 18:10, Maksym Zinchenko wrote: > Hello everyone, 2 latest commits are not letting me start naviserver. sorry for the omission. tip version should be fixed now. I'll be back in Vienna on monday in case i have overseen something... -g |
|
From: Stephen D. <sd...@gm...> - 2007-07-31 10:48:05
|
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 <k2...@ph...> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Neophytos D. <k2...@ph...> - 2007-07-31 11:11:01
|
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 <k2...@ph...> 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
>> nav...@li...
>> 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
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
|
|
From: Neophytos D. <k2...@ph...> - 2007-08-01 07:58:04
|
Stephen Deasey wrote:
> 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 good news is that I managed to get init.tcl from 4.99.1 to work
(based on your suggestions below). The bad news is that init.tcl 4.99.2
fails whenever nstrace is used:
* For lazyloader=true, server initialization fails.
* For lazyloader=false, initialization seems ok but on first request I
get the usual problems mentioned in a previous thread (I had tried once
to debug those errors but it took me ages and it did not work out in the
end).
> 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.
I have thus removed nstrace.tcl and modified init.tcl from 4.99.1 by
adding the following snippet in the end of the file:
ns_ictl trace allocate ns_init
ns_ictl trace deallocate ns_cleanup
It seems to be working ok. The problem, however, is that I'm not sure if
anything else is still missing (I cannot trust it enough yet to deploy
it). I would prefer mostly if NS was distributed with an alternative
init.tcl (based on the 4.99.1) so that it works for all of us. We would
then just change the initfile parameter.
> 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?
Yes,this fails on the second page request (i.e., the dependent files are
served via a different thread and thus the 40 threads are consumed earlier).
> Try this:
>
> ns_section "ns/server/server1/module/nssock"
> ns_param writersize 0
> Does that prevent the crash?
For a while, but it still fails after a number of requests.
Would it be possible to have an alternative init.tcl (based on the one
from 4.99.1) that has all changes applied except nstrace as an interim
solution (until nstrace is updated as described in a previous message by
ZV)?
Let me know if I can be of any help with this.
Best wishes,
Neophytos
|
|
From: Zoran V. <zv...@ar...> - 2007-08-01 08:42:27
|
Am 01.08.2007 um 09:57 schrieb Neophytos Demetriou:
> I would prefer mostly if NS was distributed with an alternative
> init.tcl (based on the 4.99.1) so that it works for all of us. We
> would
> then just change the initfile parameter.
Ah... as I said, the interp inits are really ugly.
The 4.0 AS and 4.99.1 NS both use a crude and ugly
introspective script that runs against a initialized
interp and pull-out definitions of procedures, variables
and namespaces found there. All is stuffed in a large
"init" script and this script is applied to every new
Tcl interpreter. Idea was to improve the speed of interp
initialization. That was perhaps necessary 7 years ago
but I believe today it is of less importance.
This is UGLY.
I have modified that to use command traces and build the
script "on-the-fly" as the first Tcl interp is being initialized
but this obviously has some side effects, who knows where
(as this works very fine for us, strangely). I would not go
in much detail there as I think that even that is a UGLY
solution (rather complicated and error-prone, although with some
nice side-effects regarding memory footprints...).
The real solution is to use [ns_ictl trace]. I promised to do
that some time ago but I'm lagging behind... (eh, work, work)
We need to rewrite the Tcl startup so that for every Tcl module
file that gets sourced in the startup interpreter we do something
like:
ns_ictl trace allocate [list source module-file]
where the module-file is the file containing Tcl code to initialize
the interpreter. All of this is pulled from bin/init.tcl or wherever
you setup your virtual-server init script to be.
I cannot promise but I may try to see if this will work OK for you.
Unfortunately I can't make that before this weekend.
Cheers
Zoran
|
|
From: Neophytos D. <k2...@ph...> - 2007-08-01 09:12:04
|
Zoran, thank you very much for your message. Zoran Vasiljevic wrote: > I would not go > in much detail there as I think that even that is a UGLY > solution (rather complicated and error-prone, although with some > nice side-effects regarding memory footprints...). I would be happy if nstrace was working for me as well (I mean, I see the benefits) but, currently, the modified init.tcl file from 4.99.1 was the only thing that made things work fine for me with the latest versions of NS. > I cannot promise but I may try to see if this will work OK for you. > Unfortunately I can't make that before this weekend. I have no hard deadline. It would be nice, however, if it was ready in the next couple of weeks. If not, I can live with the modified init.tcl from 4.99.1 as long as someone can confirm that it is more or less ok (or if it's missing something obvious, just point it out). Best wishes, Neophytos |
|
From: Stephen D. <sd...@gm...> - 2007-08-01 10:29:20
|
On 8/1/07, Neophytos Demetriou <k2...@ph...> wrote: > > I have thus removed nstrace.tcl and modified init.tcl from 4.99.1 by > adding the following snippet in the end of the file: > > ns_ictl trace allocate ns_init > ns_ictl trace deallocate ns_cleanup > > It seems to be working ok. The problem here was an Ns_Set containing query variables, which is allocated by and belongs to the Ns_Conn code, is made available to an interp when you call ns_conn getform. After the connection, the query-set is freed by the Ns_Conn code but unless you call ns_set cleanup explicitly, a pointer to it remains in the interp and is reused for the next connection. Don't do that :-) Seems maybe a little fragile... Not sure if set-cleanup should be triggered from C code or not. I guess you really want to make sure that sets owned by other code always get cleaned up, whereas sets owned by Tcl usually get cleaned up, by the call to ns_set cleanup in init.tcl. |
|
From: Stephen D. <sd...@gm...> - 2007-08-01 10:31:04
|
On 8/1/07, Neophytos Demetriou <k2...@ph...> wrote: > > * For lazyloader=false, initialization seems ok but on first request I > get the usual problems mentioned in a previous thread (I had tried once > to debug those errors but it took me ages and it did not work out in the > end). Can you repost the errors you get? |
|
From: Neophytos D. <k2...@ph...> - 2007-08-02 17:06:39
|
Stephen Deasey wrote:
> On 8/1/07, Neophytos Demetriou <k2...@ph...> wrote:
>> * For lazyloader=false, initialization seems ok but on first request I
>> get the usual problems mentioned in a previous thread (I had tried once
>> to debug those errors but it took me ages and it did not work out in the
>> end).
>
>
> Can you repost the errors you get?
* For lazyloader=true, everything xotcl fails during init. For instance:
invalid command name "Class"
while executing
"Class ::xo::base::NodeLabelVisitor -parameter {
{nodeCount "0"}
}"
(file
"/web/service-phgt-0/packages/kernel/tcl/05-base/base-procs.tcl" line 4)
invoked from within
"source $__file "
* For lazyloader=false, server init mostly works:
Error: invalid command name
"::namespace123::Class444::namespace789::object555"
invalid command name "::namespace123::Class444::namespace789::object555"
while executing
"namespace origin $pn"
(procedure "_serializensp" line 14)
invoked from within
"_serializensp $n"
(procedure "nstrace::statescript" line 36)
invoked from within
"nstrace::statescript"
invoked from within
"if {$use_trace_inits} {
#
# ns_eval --
#
# Used to eval Tcl code which is then
# known in all threads.
#
proc ns_eval {..."
(file "/opt/naviserver-4.99.2/bin/init.tcl" line 355)
Please note that the modified init.tcl from 4.99.1 seems to be working
fine. I just need to go through the two versions (4.99.1 and 4.99.2) and
make sure that I'm not skipping anything important.
Having said this, if Zoran comes up with a generic solution to the
nstrace+xotcl problem I will be an even happier NS user :) but I guess
it should be fine for now.
Thanks again and best wishes,
Neophytos
|
|
From: Zoran V. <zv...@ar...> - 2007-08-02 17:25:18
|
Am 02.08.2007 um 19:05 schrieb Neophytos Demetriou: > Having said this, if Zoran comes up with a generic solution to the > nstrace+xotcl problem I will be an even happier NS user :) but I guess > it should be fine for now. Hey... the Xotcl loader MIGHT be busted with lazyloader option set. I would need to re-check that. Other (non-xotcl) stuff should work fine though. Cheers Zoran |
|
From: Neophytos D. <k2...@ph...> - 2007-08-02 18:28:28
|
Zoran Vasiljevic wrote: > Am 02.08.2007 um 19:05 schrieb Neophytos Demetriou: > >> Having said this, if Zoran comes up with a generic solution to the >> nstrace+xotcl problem I will be an even happier NS user :) but I guess >> it should be fine for now. > > Hey... the Xotcl loader MIGHT be busted with lazyloader option set. > I would need to re-check that. Other (non-xotcl) stuff > should work fine though. Zoran, just to make sure I got that right: xotcl does not work with the nstrace/lazyloader at all (true or false). That's the reason I'm using the modified init.tcl file from 4.99.1. Best wishes, Neophytos |
|
From: Zoran V. <zv...@ar...> - 2007-08-02 19:20:37
|
Am 02.08.2007 um 20:27 schrieb Neophytos Demetriou: > Zoran, just to make sure I got that right: xotcl does not work with > the > nstrace/lazyloader at all (true or false). That's the reason I'm using > the modified init.tcl file from 4.99.1. > Yes. The Xotcl loader might have some problems. But, anyways, let me fix that Tcl init stuff altogether, as this will make Xotcl loading also work again. Cheers Zoran |
|
From: Stephen D. <sd...@gm...> - 2007-08-02 19:30:24
|
On 8/2/07, Neophytos Demetriou <k2...@ph...> wrote: > Zoran Vasiljevic wrote: > > Am 02.08.2007 um 19:05 schrieb Neophytos Demetriou: > > > >> Having said this, if Zoran comes up with a generic solution to the > >> nstrace+xotcl problem I will be an even happier NS user :) but I guess > >> it should be fine for now. > > > > Hey... the Xotcl loader MIGHT be busted with lazyloader option set. > > I would need to re-check that. Other (non-xotcl) stuff > > should work fine though. > > Zoran, just to make sure I got that right: xotcl does not work with the > nstrace/lazyloader at all (true or false). That's the reason I'm using > the modified init.tcl file from 4.99.1. > I wonder if this is xotcl specific, or if xotcl just tickles the right (wrong) bit of code. Xotcl seems to use a lot of deeply namespaced commands, who's names are stored in variables... It would be really helpful if a minimal example of the error could be isolated in standard Tcl and dropped into a file: tests/testserver/modules/state.tcl Hard to write a test for it, but at least it will throw an error at startup when the tests are run and someone will see it. If it really is an xotcl-only error, I guess it can be package required in a catch or something? |
|
From: Neophytos D. <k2...@ph...> - 2007-08-02 19:42:56
|
>> Zoran, just to make sure I got that right: xotcl does not work with the >> nstrace/lazyloader at all (true or false). That's the reason I'm using >> the modified init.tcl file from 4.99.1. > > I wonder if this is xotcl specific, or if xotcl just tickles the right > (wrong) bit of code. Xotcl seems to use a lot of deeply namespaced > commands, who's names are stored in variables... Stephen, there is no need for deeply namespaced commands (that's just part of some code I wrote a couple of years back). > It would be really helpful if a minimal example of the error could be > isolated in standard Tcl and dropped into a file: > tests/testserver/modules/state.tcl > > Hard to write a test for it, but at least it will throw an error at > startup when the tests are run and someone will see it. If it really > is an xotcl-only error, I guess it can be package required in a catch > or something? The problem with lazyloader=false should be easier to overcome (i.e. serializing xotcl code + "ns_ictl trace allocate [list source module-file]"). The lazyloader=true case should be harder and IIRC Zoran already mentioned that it would require some changes on the xotcl-side to work. Still, getting lazyloader=false to work with xotcl is a first step. Best, Neophytos |
|
From: Stephen D. <sd...@gm...> - 2007-08-04 20:36:10
|
On 8/2/07, Neophytos Demetriou <k2...@ph...> wrote: > >> Zoran, just to make sure I got that right: xotcl does not work with the > >> nstrace/lazyloader at all (true or false). That's the reason I'm using > >> the modified init.tcl file from 4.99.1. > > > > I wonder if this is xotcl specific, or if xotcl just tickles the right > > (wrong) bit of code. Xotcl seems to use a lot of deeply namespaced > > commands, who's names are stored in variables... > > Stephen, there is no need for deeply namespaced commands (that's just > part of some code I wrote a couple of years back). > > > It would be really helpful if a minimal example of the error could be > > isolated in standard Tcl and dropped into a file: > > tests/testserver/modules/state.tcl > > > > Hard to write a test for it, but at least it will throw an error at > > startup when the tests are run and someone will see it. If it really > > is an xotcl-only error, I guess it can be package required in a catch > > or something? > > The problem with lazyloader=false should be easier to overcome (i.e. > serializing xotcl code + "ns_ictl trace allocate [list source > module-file]"). You'd be doing me a favor if you looked over these instructions for running tests I just put on the wiki and validated that they run a machine other than mine and are basically understandable: http://naviserver.sourceforge.net/wiki/index.php/Running_Tests Also, here's a start at testing the init sequence: http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tests/init.test?view=markup If anyone can think of any expectations they have of the initialisation code that isn't already covered, just add them onto the end. Also also, it's worth mentioning that the nsd/init.tcl file can be substituted for another one using the config parameter ns/server/$server/tcl:initfile. We do that in the test suite config just to make sure the fresh source gets used: http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tests/test.nscfg?view=markup#l_130 That should make it convenient to isolate differences between a complex installation and the basic upstream test environment. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X