I found the following change fixes the bug: in nsd/tclresp.c, line 840:
static int Result(Tcl_Interp *interp, int result) { /* Tcl_SetBooleanObj(Tcl_GetObjResult(interp), result == NS_OK ? 1 : 0); */ Tcl_SetObjResult(interp, Tcl_NewBooleanObj((result == NS_OK ? 1 : 0))); return TCL_OK; } I'll commit the change. tom jackson On Sunday 21 January 2007 17:06, Tom Jackson wrote: > Okay, some more info on this. > > ns_atclose has been changed in some strange ways. > > First it now requires that you are in an open connection to invoke > ns_atclose. > > ns_atclose used to execute in scheduled procs, which makes sense so that > you can use one method to clean up stuff in case of errors. > > It is easy to re-enable adding ns_atclose to scheduled procs by removing a > few lines of code. Now I can call ns_atclose everywhere, but in scheduled > procs, the cleanup scripts don't run. > > Question is: why the (silent) change, and > is there something to replace this? > > The old description of the command is here: > <http://rmadilo.com/files/nsapi/ns_atclose.html> > > I still haven't figured out where exactly the crash is coming from, but _it > is not in the NsAtCloseObjCmd or NsRunAtClose... code. > > tom jackson > > On Sunday 21 January 2007 11:24, Tom Jackson wrote: > > I have been getting some crashes in AOLserver (current cvs version). > > AOLserver doesn't exit, but prints the following and stops responding: > > > > 'Tcl_SetBooleanObj called with shared object' > > > > Here is a tcl page which exposes the behavior: > > > > ----------- > > # Script to expose bug with ns_atclose/namespace commands > > set store "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcdefghijklmnop" > > namespace eval ::bug { } > > > > # Commenting out this line leads to bug: 'Tcl_SetBooleanObj called with > > shared object' > > #namespace eval ::bug::$store { } > > > > proc ::bug::atClose { store } { > > ns_log Debug "checking if namespace ::bug::$store exists" > > if {[namespace exists ::bug::${store}]} { > > ns_log Debug "Deleting namespace ::bug::$store" > > namespace delete ::bug::${store} > > #log Notice "Closed store (memory delete) $store" > > return $store > > } else { > > ns_log Debug "namespace ::bug::$store does not exist" > > } > > > > } > > > > # Comment out one of these and things work fine: > > ns_atclose ::bug::atClose $store > > #ns_atclose ::bug::atClose $store > > > > > > ns_return 200 text/plain "ns_atclose bug" > > > > ----------------- > > > > The bug doesn't show up under all conditions. If the namespace exists, or > > had existed and was deleted, things work as expected. Also, even if the > > namespace never existed, if ns_atclose is only called once, things work > > as expected. > > > > However, if the namespace to be deleted never existed, and ns_atclose is > > called twice with the same args, none of the ns_log Debug statements > > print, and the crash occurs. (But the page is returned) > > > > Not sure what is the cause. > > > > tom jackson > > > > On Friday 03 November 2006 10:31, Alex wrote: > > > Oh, well > > > > > > so I guess it was too early to celebrate. Now I am getting the same > > > crashes again, even without "exit" command in the tcl code executed in > > > thread. > > > > > > Seems to me that the same problem now discussed in > > > bug 1589968 > > > https://sourceforge.net/tracker/?func=detail&atid=103152&aid=1589968&gr > > >ou p_ id=3152 > > > > > > and > > > > > > bug 1582671 > > > http://sourceforge.net/tracker/?func=detail&atid=110894&aid=1582671&gro > > >up _i d=10894 > > > > > > > > > Thanks, > > > ~ Alex. > > > > > > On 11/1/06, Alex <[EMAIL PROTECTED]> wrote: > > > > Zoran, Jim > > > > > > > > thanks very much for suggestions! > > > > I think I figured it out. > > > > The code which was executing in the thread concluded with "exit" tcl > > > > command. I got it replaced with "return" and it seems not to be > > > > crashing anymore. > > > > > > > > However, it would be probably a good idea to disable/rename "exit" > > > > for the code executed in threads created by ns_thread. Not sure if > > > > this shall be submitted as an "enhancement"-level bug. > > > > > > > > Thanks, > > > > ~ Alex. > > > > > > > > On 11/1/06, Alex <[EMAIL PROTECTED]> wrote: > > > > > Jim, > > > > > > > > > > I tried in on the command line, seems to be my case :) > > > > > > > > > > However, I run aolserver on debian, via /etc/init.d/aolserver, > > > > > Which basically invokes /usr/lib/aolserver4/bin/nsd. > > > > > How do I make it use nstclsh instead of tclsh ? > > > > > I don't see any options for that. > > > > > > > > > > Thanks, > > > > > ~ Alex. > > > > > > > > > > On 11/1/06, Jim Davidson <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > > > > > > > I think this is related to the comment I added to the RELEASE > > > > > > notes: > > > > > > > > > > > > * Loading libnsd into a tclsh and then creating new threads with > > > > > > the ns_thread command will result in a crash when those threads > > > > > > exit. The issues has to do with finalization of the async-cancel > > > > > > context used to support the new "ns_ictl cancel" feature. This > > > > > > bug is not present when using the "nstclsh" binary. > > > > > > > > > > > > > > > > > > The issue above, where Tcl is initialized before AOLserver by > > > > > > loading libnsd into tclsh, results in Tcl thread local storage > > > > > > being finalized before AOLserver's context which includes a > > > > > > pointer to an async handler. > > > > > > > > > > > > Now, that's not what you're doing here but perhaps TclX is having > > > > > > the same effect. I haven't looked at TclX for sometime so I > > > > > > can't recall what it would be using an async handler for -- > > > > > > perhaps you could dig through the code and comment it out as the > > > > > > async handler stuff was really designed for Unix signal-related > > > > > > things which aren't common in multi-threaded AOLserver. > > > > > > > > > > > > Alternatively, Tcl could be fixed to avoid freeing itself before > > > > > > AOLserver or any other extension. Unfortunately, that could be a > > > > > > big job -- the Tcl core is already riddled with a lot of code to > > > > > > try to manage the order of finalization. > > > > > > > > > > > > -Jim > > > > > > > > > > > > On Nov 1, 2006, at 5:35 PM, Zoran Vasiljevic wrote: > > > > > > > On 01.11.2006, at 23:27, Alex wrote: > > > > > > >> Hi, > > > > > > >> > > > > > > >> I am getting yet another crash in AOLServer 4.5.0. > > > > > > >> This time it crashes after exiting from threads started with > > > > > > >> "ns_thread begin" or "ns_thread begindetached". > > > > > > >> > > > > > > >> Any Suggestions? > > > > > > >> > > > > > > >> Thanks, > > > > > > >> ~ Alex. > > > > > > >> > > > > > > >> Program received signal SIGSEGV, Segmentation fault. > > > > > > >> [Switching to Thread 1086359904 (LWP 19612)] > > > > > > >> 0x00002aaaaae6c2a7 in Tcl_AsyncDelete (async=0x54e6c0) at > > > > > > >> /srv/DIST/tcl8.4.13/unix/../generic/tclAsync.c:297 > > > > > > >> 297 while (prevPtr->nextPtr != asyncPtr) { > > > > > > >> (gdb) back > > > > > > >> #0 0x00002aaaaae6c2a7 in Tcl_AsyncDelete (async=0x54e6c0) at > > > > > > >> /srv/DIST/tcl8.4.13/unix/../generic/tclAsync.c:297 > > > > > > >> #1 0x00002aaaad48190e in TclX_SelectInit () from /usr/lib/ > > > > > > >> libtclx8.4.so.1 > > > > > > > > > > > > > > I'm not sure TclX is thread-safe... > > > > > > > > > > > > > > Cheers > > > > > > > Zoran > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > AOLserver - http://www.aolserver.com/ > > > > > > > > > > > > > > To Remove yourself from this list, simply send an email to > > > > > > > <[EMAIL PROTECTED]> with the > > > > > > > body of "SIGNOFF AOLSERVER" in the email message. You can leave > > > > > > > the Subject: field of your email blank. > > > > > > > > > > > > -- > > > > > > AOLserver - http://www.aolserver.com/ > > > > > > > > > > > > To Remove yourself from this list, simply send an email to > > > > > > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" > > > > > > in the email message. You can leave the Subject: field of your > > > > > > email blank. > > > > > > -- > > > AOLserver - http://www.aolserver.com/ > > > > > > To Remove yourself from this list, simply send an email to > > > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the > > > email message. You can leave the Subject: field of your email blank. > > > > -- > > AOLserver - http://www.aolserver.com/ > > > > To Remove yourself from this list, simply send an email to > > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the > > email message. You can leave the Subject: field of your email blank. > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the > email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.