From: Gustaf N. <ne...@wu...> - 2016-10-21 07:33:44
|
Dear Wolfgang, I found an explanation: probably you have indeed no legacy defer callbacks registered, but NaviServer does an UpdateInterp() even when no defer callbacks were executed, which might have changed the state. During UpdateInterp() it probably re-evaluates the "namespace eval ::WS::Utils {...}", which complains, since tdom rejects to reset "its" variable. I wonder, whether this is the only place, where the interaction between tclws & tdom & interp updates can cause complaints. Anyhow, the change [1] omits the update of the interpreter, when nothing could have been changed by the defer callbacks. It should be as well performance-wise better. Hope this helps -g https://bitbucket.org/naviserver/naviserver/commits/526312b7ac23f734f0002d3d1514025dfb4ea36e Am 21.10.16 um 07:59 schrieb Wolfgang Winkler: > We are using > > ns_param nssock ${bindir}/nssock.so > ns_param nslog ${bindir}/nslog.so > ns_param nsdb ${bindir}/nsdb.so > ns_param nscp ${bindir}/nscp.so > ns_param nsproxy ${bindir}/nsproxy.so > > ns_param postgres "${bindir}/nsdbpg.so" > > I tried to uncomment them, but the error is still there. > > I've grepped through all our sources but did not find a call to > Ns_TclRegisterDeferred, ns_ictl cleanup or ns_cleanup. > > > Am 2016-10-20 um 17:18 schrieb Gustaf Neumann: >> sure. but the point is, this call does on usual installations >> nothing, .... unless someone registers a function with >> Ns_TclRegisterDeferred(). >> What modules are you loading? >> -g >> >> Am 20.10.16 um 16:53 schrieb Wolfgang Winkler: >>> ns_ictl cleanup is called from ns_cleanup in >>> naviserver/bin/init.tcl. When I remove the call, the error goes way. >>> These are the relevant calls: >>> >>> >>> ns_ictl trace deallocate ns_cleanup >>> >>> 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. >>> } >>> >>> regards, >>> >>> Wolfgang >>> >>> Am 2016-10-20 um 16:26 schrieb Gustaf Neumann: >>>> Hmm, it looks to me, as if this error is triggered not from the >>>> startup, but from the shutdown. >>>> >>>> The backtrace shows, that "ns_ictl cleanup" is causing this, which >>>> in turn calls the callbacks registered with >>>> Ns_TclRegisterDeferred(), which is a deprecated function (since >>>> many years). Ns_TclRegisterDeferred() is nowhere called within >>>> NaviServer, so it looks to me that you might have c-based module in >>>> use, which calls this function.... is this correct? >>>> >>>> Aside form the strange situation around "ns_ictl cleanup", the >>>> error was probably triggered in earlier versions of NaviServer as >>>> well, but in some newer versions of NaviServer, error conditions, >>>> which were silently swallowed before, are now reported back to the >>>> user. >>>> >>>> The message "var is read-only" is actually generated by tDOM. It >>>> might be the case, that the function registered via >>>> Ns_TclRegisterDeferred() either sources Utilities.tcl (from tclws), >>>> or it might re-evaluate the blueprint during shutdown; both is >>>> probably not wanted. >>>> >>>> Hope this helps >>>> -g >>>> >>>> Am 20.10.16 um 10:25 schrieb Wolfgang Winkler: >>>>> >>>>> Hi! >>>>> >>>>> We are using webservices for tcl (tclws) with naviserver. For >>>>> naviserver version 4.99.7 we sometimes get the following error >>>>> message: >>>>> >>>>> Error: can't set "xsltSchemaDom": var is read-only >>>>> var is read-only >>>>> (write trace on "xsltSchemaDom") >>>>> invoked from within >>>>> "variable xsltSchemaDom domDoc0xa7c640" >>>>> (in namespace eval "::WS::Utils" script line 3) >>>>> invoked from within >>>>> "namespace eval ::WS::Utils { >>>>> variable currentNs {} >>>>> variable xsltSchemaDom domDoc0xa7c640 >>>>> variable standardAttributes { >>>>> baseType >>>>> comme..." >>>>> invoked from within >>>>> "ns_ictl cleanup" >>>>> (procedure "ns_cleanup" line 6) >>>>> invoked from within >>>>> "ns_cleanup" >>>>> while executing callback >>>>> ns:tcltrace ns_cleanup >>>>> (context: trace proc) >>>>> >>>>> With version 4.99.13 we get his error on every startup. It seems >>>>> to be connected to thread creation. Has anybody any idea how to >>>>> prevent this error? >>>>> >>>>> regards, >>>>> >>>>> Wolfgang >>>>> >>>>> >>>>> -- >>>>> >>>>> *Wolfgang Winkler* >>>>> Geschäftsführung >>>>> wol...@di... >>>>> mobil +43.699.19971172 >>>>> >>>>> dc:*büro* >>>>> digital concepts Novak Winkler OG >>>>> Software & Design >>>>> Landstraße 68, 5. Stock, 4020 Linz >>>>> www.digital-concepts.com <http://www.digital-concepts.com> >>>>> tel +43.732.997117.72 >>>>> tel +43.699.1997117.2 >>>>> >>>>> Firmenbuchnummer: 192003h >>>>> Firmenbuchgericht: Landesgericht Linz >>>>> >>>>> >>>> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org!http://sdm.link/slashdot >> >> >> _______________________________________________ >> naviserver-devel mailing list >> nav...@li... >> https://lists.sourceforge.net/lists/listinfo/naviserver-devel > > > -- > > *Wolfgang Winkler* > Geschäftsführung > wol...@di... > mobil +43.699.19971172 > > dc:*büro* > digital concepts Novak Winkler OG > Software & Design > Landstraße 68, 5. Stock, 4020 Linz > www.digital-concepts.com <http://www.digital-concepts.com> > tel +43.732.997117.72 > tel +43.699.1997117.2 > > Firmenbuchnummer: 192003h > Firmenbuchgericht: Landesgericht Linz > > > |