You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Karl Lehenbauer <ka...@gmail.com> on 2009/05/06 16:42:43 UTC
coredumps on shutdown with separate virtual interps
Separate virtual interpreters are amazingly cool. Using them,
fiddling with auto_path, and using git we're able to give each
developer their own Rivet interpreters with a private library path
that gets searched first, their own webpages, and so forth. It's great.
But we're having a problem that when we do an apachectl stop all of
the children that have served webpages dump core. The problem is that
outputproc is getting called by the flush activities triggered by the
call to Tcl_Finalize() as part of the shutdown. There isn't really a
request structure so it quickly dereferences a null pointer and that
triggers a coredump.
Doing some debugging, I've determined that the Tcl channel that Rivet
maps to Apache's ap_rwrite and such, its close routine is getting
called prior to the attempt to flush this data.
What's weird is that the data that it's trying to write is the same as
the last webpage the child generated.
I'm continuing to investigate because I want to know why it's
happening, although it's also reasonable to make the closeproc set a
"closed" flag that the outputproc would honor. The outputproc could
also very easily detect that the request structure isn't real, but the
big question is why is it getting called in the first place.
I mention it here in the hopes that someone will have a flash of
insight and/or knows the answer.
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: coredumps on shutdown with separate virtual interps
Posted by Karl Lehenbauer <ka...@gmail.com>.
Correct. It is fixed and we're using separate virtual interpreters to
give each developer their own webroot and packages. It's all
integrated with git and we're really digging it.
On May 7, 2009, at 4:31 PM, David Welton wrote:
> Looks like you found a solution, according to the commit logs?
>
> --
> David N. Welton
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/
> Sent from Padova, PD, Italy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: coredumps on shutdown with separate virtual interps
Posted by David Welton <da...@dedasys.com>.
Looks like you found a solution, according to the commit logs?
--
David N. Welton
http://www.welton.it/davidw/
http://www.dedasys.com/
Sent from Padova, PD, Italy
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: coredumps on shutdown with separate virtual interps
Posted by Karl Lehenbauer <ka...@gmail.com>.
Massimo,
Apology accepted and no worries. What was hard about it was trying to
debug the channel driver malfunction that was innocent but was
implicated as a coincidence of trying to execute something while
tearing down an interpreter that was already being torn down.
The bug itself was actually pretty cool, and I learned a lot about
Rivet while debugging it, so I didn't feel like the time was wasted.
Karl
On May 8, 2009, at 10:30 AM, Massimo Manghi wrote:
> I read the log of your last commit and it looks like I introduced
> this bug because I missed the implications of having the SVI
> switch turned on. I apologize.
>
> -- Massimo
>
> Karl Lehenbauer wrote:
>> Separate virtual interpreters are amazingly cool. Using them,
>> fiddling with auto_path, and using git we're able to give each
>> developer their own Rivet interpreters with a private library path
>> that gets searched first, their own webpages, and so forth. It's
>> great.
>>
>> But we're having a problem that when we do an apachectl stop all of
>> the children that have served webpages dump core. The problem is
>> that outputproc is getting called by the flush activities triggered
>> by the call to Tcl_Finalize() as part of the shutdown. There
>> isn't really a request structure so it quickly dereferences a null
>> pointer and that triggers a coredump.
>>
>> Doing some debugging, I've determined that the Tcl channel that
>> Rivet maps to Apache's ap_rwrite and such, its close routine is
>> getting called prior to the attempt to flush this data.
>>
>> What's weird is that the data that it's trying to write is the same
>> as the last webpage the child generated.
>>
>> I'm continuing to investigate because I want to know why it's
>> happening, although it's also reasonable to make the closeproc set
>> a "closed" flag that the outputproc would honor. The outputproc
>> could also very easily detect that the request structure isn't
>> real, but the big question is why is it getting called in the first
>> place.
>>
>> I mention it here in the hopes that someone will have a flash of
>> insight and/or knows the answer.
>>
>> Karl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
>> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: coredumps on shutdown with separate virtual interps
Posted by Massimo Manghi <ma...@unipr.it>.
I read the log of your last commit and it looks like I introduced
this bug because I missed the implications of having the SVI
switch turned on. I apologize.
-- Massimo
Karl Lehenbauer wrote:
> Separate virtual interpreters are amazingly cool. Using them,
> fiddling with auto_path, and using git we're able to give each
> developer their own Rivet interpreters with a private library path
> that gets searched first, their own webpages, and so forth. It's great.
>
> But we're having a problem that when we do an apachectl stop all of
> the children that have served webpages dump core. The problem is that
> outputproc is getting called by the flush activities triggered by the
> call to Tcl_Finalize() as part of the shutdown. There isn't really a
> request structure so it quickly dereferences a null pointer and that
> triggers a coredump.
>
> Doing some debugging, I've determined that the Tcl channel that Rivet
> maps to Apache's ap_rwrite and such, its close routine is getting
> called prior to the attempt to flush this data.
>
> What's weird is that the data that it's trying to write is the same as
> the last webpage the child generated.
>
> I'm continuing to investigate because I want to know why it's
> happening, although it's also reasonable to make the closeproc set a
> "closed" flag that the outputproc would honor. The outputproc could
> also very easily detect that the request structure isn't real, but the
> big question is why is it getting called in the first place.
>
> I mention it here in the hopes that someone will have a flash of
> insight and/or knows the answer.
>
> Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org