|
Home > Archive > AOL Webserver > January 2007 > AOLserver crash related to ns_atclose and namespace commands
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
AOLserver crash related to ns_atclose and namespace commands
|
|
| Tom Jackson 2007-01-21, 7:11 pm |
| 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 " ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcd
efghijklmnop"
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/?fu...=1589968&group_
>id=3152
>
> and
>
> bug 1582671
> http://sourceforge.net/tracker/?fun...1582671&group_i
>d=10894
>
>
> Thanks,
> ~ Alex.
>
> On 11/1/06, Alex <alexsott@gmail.com> wrote:
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.
| |
| Tom Jackson 2007-01-22, 1:11 am |
| 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 " ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789abcd
efghijklmnop"
> 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:
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.
| |
| Tom Jackson 2007-01-22, 1:11 am |
| 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(inter
p), 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:
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> with the body of "SIGNOFF AOLSERVER" in the
> email message. You can leave the Subject: field of your email blank.
| |
| Brett Schwarz 2007-01-22, 7:11 am |
| That's funny actually...I just changed a bunch of these cases in a Tcl extension I help maintain, just earlier today. I happened upon this post that talks about it:
http://sourceforge.net/mailarchive/...&forum_id=43966
Might be worthwhile doing an audit of the rest of the aolserver code for these occurances.
--brett
----- Original Message ----
From: Tom Jackson <tom@RMADILO.COM>
To: AOLSERVER@LISTSERV.AOL.COM
Sent: Sunday, January 21, 2007 7:17:41 PM
Subject: Re: [AOLSERVER] AOLserver crash related to ns_atclose and namespace commands
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(inter
p), 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:
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to
> <listserv@listserv.aol.com> 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 <listserv@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
________________________________________
________________________________________
____
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
| |
| Tom Jackson 2007-01-22, 1:11 pm |
| On Sunday 21 January 2007 23:20, Brett Schwarz wrote:
> That's funny actually...I just changed a bunch of these cases in a Tcl
> extension I help maintain, just earlier today. I happened upon this post
> that talks about it:
> http://sourceforge.net/mailarchive/...212&forum_id=43
>966
>
> Might be worthwhile doing an audit of the rest of the aolserver code for
> these occurances.
I only found a few in the AOLserver code, I changed about half before I found
the one that stopped the bug.
I even changed one in the tcl codebase that uses this while checking if a
namespace exists.
I have a feeling that the bug shows up for some other reason. ns_atclose
stores scripts and uses a hash array. I'm guessing that two identical scripts
might appear as one at some point. This could change the reference count for
the object, somehow leading to the problem.
tom jackson
|
|
|
|
|