coredumps on shutdown with separate virtual interps

[Karl Lehenbauer-6]

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@...
For additional commands, e-mail: rivet-dev-help@...

[David Welton-2]

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@...
For additional commands, e-mail: rivet-dev-help@...

[Massimo Manghi-2]

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@...
> For additional commands, e-mail: rivet-dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@...
For additional commands, e-mail: rivet-dev-help@...

[Karl Lehenbauer-6]

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@...
>> For additional commands, e-mail: rivet-dev-help@...
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@...
For additional commands, e-mail: rivet-dev-help@...

[Karl Lehenbauer-6]

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@...
> For additional commands, e-mail: rivet-dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@...
For additional commands, e-mail: rivet-dev-help@...