You are viewing a plain text version of this content. The canonical link for it is here.
Posted to websh-dev@tcl.apache.org by Ronnie Brunner <ro...@netcetera.ch> on 2002/03/05 20:36:11 UTC
Re: current status: core dump - GOT IT
> > Since I ran all tests w/o problem this afternoon, some of the
> > changes from David or me must have created a problem. Anyone else
> > with similar observations?
>
> Damn... they work for me. I will go back through and look at them
> all.
I tracked t down: the fix of checking the return value of remove in
requst.c line 212ff causes the dump because of the return TCL_ERROR.
It seems we don't properly clean up some memory in hat case.
The checking does not make sense anyway: not being able to remove a
tempfile is usually not a problem because it's not there in the first
place: remove is called for every filename that was generated using
[web::tempfile]. If the process removes it directly (or does not even
use it), we shouldn't really log an error.
However if we have a problem with the file system and/or permissions
on our file, we might want to check. -> check for errno != ENOENT
before logging (or some other flags), and do not return in any case
(just keep trying to remove the other files seems to be the proper
approach). David: can you look at this?
Ronnie
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: current status: core dump - GOT IT
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> > However if we have a problem with the file system and/or permissions
> > on our file, we might want to check. -> check for errno != ENOENT
> > before logging (or some other flags), and do not return in any case
> > (just keep trying to remove the other files seems to be the proper
> > approach). David: can you look at this?
>
> Ok, I'm curious... are you actually getting stuff in the error_log
> file? I don't see anything.
I still had crashes even w/o the return: the call to Tcl_PosixError
crashed, because when destroying the requestdata, interp == 0. -> I
changed that to Tcl_ErrnoMsg(Tcl_GetErrno()), which is independent of
the interpreter.
Why no logs? I also looked at this: we don't get any logs, when interp
is NULL, which it is in our case. It is not, when a slave interpreter
is deleted. However, even there, the interp is already marked as
deleted, which prevents access to assoc data in the log facility ->
even providing a valid interp pointer (instead of NULL) does not
create any logs. (So the statments are actually for nothing ;-). I
left them in anyway and fixed them so theoretically, they would report
properly what's happening.
Ronnie
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 Fax: +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: current status: core dump - GOT IT
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> > > Since I ran all tests w/o problem this afternoon, some of the
> > > changes from David or me must have created a problem. Anyone else
> > > with similar observations?
> >
> > Damn... they work for me. I will go back through and look at them
> > all.
>
> I tracked t down: the fix of checking the return value of remove in
> requst.c line 212ff causes the dump because of the return TCL_ERROR.
Ah, yeah... on second thought, the return isn't such a good idea.
> It seems we don't properly clean up some memory in hat case. The
> checking does not make sense anyway: not being able to remove a
> tempfile is usually not a problem because it's not there in the
> first place: remove is called for every filename that was generated
> using [web::tempfile]. If the process removes it directly (or does
> not even use it), we shouldn't really log an error.
> However if we have a problem with the file system and/or permissions
> on our file, we might want to check. -> check for errno != ENOENT
> before logging (or some other flags), and do not return in any case
> (just keep trying to remove the other files seems to be the proper
> approach). David: can you look at this?
Ok, I'm curious... are you actually getting stuff in the error_log
file? I don't see anything.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org