Joe Orton wrote:
On Fri, Oct 08, 2004 at 10:27:23AM -0400, Stas Bekman wrote:
Joe Orton wrote:
On Fri, Oct 08, 2004 at 10:08:21AM -0400, Stas Bekman wrote:
And it'd be nice for the failing test to run t/REPORT and include it in
the output. W/o it we know almost nothing about what perl and apache
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
Anti-Example 1: parent interpreter compiles the anon-sub, which
interpreter are you going to stick to that anon-sub?
A: As I stated, I expect the intepreter which invoke
Philippe M. Chiasson wrote:
Happened onto the cute Devel::GDB module and quickly wiped out a patch
to make
t/REPORT attempt to automatically generate back traces for core files it
finds in t/
Any interest in this ?
Excellent!
Though I doubt that anybody will have this optional module installed.
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > So on to the next question- when does the
> > parent interpreter have to deal with such anon-subs? Certainly
> > during server config, when it encounters things like
> > PerlResponseHandler 'sub { print "foo\n"; return O
Joe Schaefer wrote:
[...]
That's correct (in the case of threaded mpm), but again the problem exists
before the first clone is done, since it's quite possible that the parent
interpreter is the one that compiles the perl code with anon sub, in
which case you can't attach the parent perl interpreter
OK, finally I've found which changes have triggered the segfault. There
were actually two triggers
1) On Sept 23: the move of 3 tests to vhosts [1]
2) On Sept 26: the change of the Taint mode [2]
both patches are reversed (i.e. these are the patches against the current
cvs that make the segfault
Philippe M. Chiasson wrote:
For some reason, your output doesn't match mine. for me the difference
between 22nd and 23 starts from 3428 [1] and goes into the next day,
which is not included in your output:
[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
I've apparently been bitten
Philippe M. Chiasson wrote:
Kristian Elof Sørensen wrote:
Also worth a shot is to try 'gmake' instead of 'make'
Thanks for the suggestion, however there is no gmake on OpenBSD since
gnu make is the standard make on OpenBSD.
On my OpenBSD 3.5 box, I seem to have both:
[EMAIL PROTECTED] root]#
