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-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
