With anon-subs we need cover three cases of anon-subs:
$r->push_handlers(PerlTransHandler => sub { });
$r->push_handlers(PerlTransHandler => eval 'sub { }');
PerlTransHandler 'sub { ... }' # httpd.conf
Store the CODE refs in a special hash %ModPerl::__Subs::subs and store
the key na
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
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
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
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:
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
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 invokes
Stas Bekman wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apac
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
Obviously I don't see why that is so. In fact, I see that it is
already implemented in parts of mod_perl, for instance when
registering a pool-cleanup callback:
$sp->cleanup_register(sub { print @{ $_[0] ||
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > Obviously I don't see why that is so. In fact, I see that it is
> > already implemented in parts of mod_perl, for instance when
> > registering a pool-cleanup callback:
> > $sp->cleanup_register(sub { print @{ $_[0] || [
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
I'm still of the opinion that the best way to resolve this problem is to
ensure the same interpreter always runs whatever extra hooks it creates (eg
pool cleanups, filters/handlers added, etc.).
That will be on
Stas Bekman wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apac
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > I'm still of the opinion that the best way to resolve this problem is to
> > ensure the same interpreter always runs whatever extra hooks it creates (eg
> > pool cleanups, filters/handlers added, etc.).
>
> That will be onl
Joe Schaefer wrote:
[...]
Thanks Stas for the clear explanation. Although I don't fully
understand how the interpreter pools operate yet,
Feel free to ask additional questions, Joe. I have explained that several
times on the modperl list, but never had a chance to throughly document
that. One da
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/20
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/2004-09-22+23/
That's
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/2004-09-22+23/
--
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guid
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> >>#ifdef USE_ITHREADS
> >> /* XXX: perhaps we can optimize this further. At the moment when
> >> * perl w/ ithreads is used, we always deparse the anon subs
> >> * before storing them and then eval them each time they a
I believe I have finally found what is going on, somewhat.
Seems that calling Perl_load_module(aTHX_, flags, SV *name, SV *version, ...)
should be safe, but it seems something is strange in how it's dealing with
va_arg arguments.
I've found that this patch seems to get rid of that segfault on my se
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
mod_perl is trying to deparse the anonymous sub, and it needs
B::Deparse for that. (I'm still trying to grok the necessity/safety
of the deparse.)
Right, that makes more sense. The necessity is explained in
mo
Philippe M. Chiasson wrote:
It's probably the same, it tries to load B::Deparse. I've recently
added a few tests which were exercising that feature (there was a bug
earlier in it). See t/hooks/TestHooks/inlined_handlers.pm if you
remove that test, the problem disappears?
It definetely seems lik
Stas Bekman wrote:
Joe Orton wrote:
On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
modperl-2.0 'make test' running under worker mpm (linux) always fails in
t/filter/both_str_req_add.t and dumps core:
[...]
I get the same trace as you then with worker. That's so much easier!!!
Befor
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > mod_perl is trying to deparse the anonymous sub, and it needs
> > B::Deparse for that. (I'm still trying to grok the necessity/safety
> > of the deparse.)
>
> Right, that makes more sense. The necessity is explained in
> m
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
segfaults for me in the test suite. Running the server under gdb
indicates the segfault is happening during loading of B::Deparse on
this line in the test-
$r->add_output_filter("out_filter");
And if you add it at the startup, i
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> > segfaults for me in the test suite. Running the server under gdb
> > indicates the segfault is happening during loading of B::Deparse on
> > this line in the test-
> > $r->add_output_filter("out_filter");
>
> And if you add it at the startu
Joe Orton wrote:
On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
modperl-2.0 'make test' running under worker mpm (linux) always fails in
t/filter/both_str_req_add.t and dumps core:
That started failing for me on October 2nd with mod_perl HEAD against
tip-of-2.0 on amd64 with the att
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
modperl-2.0 'make test' running under worker mpm (linux) always fails in
t/filter/both_str_req_add.t and dumps core:
Why does that test fail all by itself, using this patch?
Index: t/filter/TestFilter/both_str_req_add.pm
On Mon, Oct 04, 2004 at 10:03:51AM +0100, Joe Orton wrote:
> On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
> > modperl-2.0 'make test' running under worker mpm (linux) always fails in
> > t/filter/both_str_req_add.t and dumps core:
>
> That started failing for me on October 2nd wit
On Sun, Oct 03, 2004 at 07:21:12PM -0400, Stas Bekman wrote:
> modperl-2.0 'make test' running under worker mpm (linux) always fails in
> t/filter/both_str_req_add.t and dumps core:
That started failing for me on October 2nd with mod_perl HEAD against
tip-of-2.0 on amd64 with the attached backtra
Stas Bekman <[EMAIL PROTECTED]> writes:
> modperl-2.0 'make test' running under worker mpm (linux) always fails in
> t/filter/both_str_req_add.t and dumps core:
Why does that test fail all by itself, using this patch?
Index: t/filter/TestFilter/both_str_req_add.pm
===
Stas Bekman wrote:
Cliff Woolley wrote:
On Sun, 3 Oct 2004, Stas Bekman wrote:
modperl-2.0 'make test' running under worker mpm (linux) always fails in
t/filter/both_str_req_add.t and dumps core:
#0 0xe410 in ?? ()
(gdb) bt
#0 0xe410 in ?? ()
#1 0xbfffeff8 in ?? ()
#2 0x0001 in ??
Cliff Woolley wrote:
On Sun, 3 Oct 2004, Stas Bekman wrote:
modperl-2.0 'make test' running under worker mpm (linux) always fails in
t/filter/both_str_req_add.t and dumps core:
#0 0xe410 in ?? ()
(gdb) bt
#0 0xe410 in ?? ()
#1 0xbfffeff8 in ?? ()
#2 0x0001 in ?? ()
#3 0xbfffeff7 i
33 matches
Mail list logo
