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&grou
> >p_ id=3152
> >
> > and
> >
> > bug 1582671
> > http://sourceforge.net/tracker/?func=detail&atid=110894&aid=1582671&group
> >_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.

Reply via email to