Stas Bekman wrote:
Max Maischein via RT wrote:
the Apache::Test Makefile.PL enters an infinite loop when it is
running without a connected terminal and can't find the path to
httpd. This is very bad for CPAN testers who maybe don't have a
httpd binary somewhere to be found, and where the testin
Geoff, why there is no thread pointer at this entry?
* per-server cleanups core dump or are otherwise ineffective
Apache->server->process->pconf->cleanup_register(sub { ... });
Report: geoff
could you please give me the info needed to reproduce the problem and I'll
try to fix it? Thanks.
-
Perrin Harkins wrote:
Stas Bekman said:
Did you have a chance to trying to port Apache::SizeLimit to mp2?
Not yet. I'm in Maine on vacation this week, but will look at it when I
get back.
ping
--
__
Stas BekmanJAm_pH
Hmm, I can't reproduce this problem anymore:
* pools that go out of scope:
perl -MApache2 -MAPR::Pool -MAPR::PerlIO -le ';
open my $fh, "<:APR", "/tmp/xxx", APR::Pool->new; print <$fh>'
APR::PerlIO::read: (9) Bad file descriptor at -e li
first of all, try to never allow passing temp pools,
[re-adding CC: dev]
Steve Hay wrote:
Stas Bekman wrote:
Guys, can you still reproduce the problem:
* on windows $pool->clean, followed by $pool->destroy breaks other tests
See test TestAPR::pool
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108547894817083&w=2
http://marc.theaimsgroup.co
Let's try another time to resolve that t/perl/ithreads.t. My problem is
reproducing the failure. I certainly know that it exists, but it's always
random and never on its own. And it's been awhile since I last got it.
What happens on win32? does it always fail? does it fail on its own? if so
cou
Stas Bekman <[EMAIL PROTECTED]> writes:
> So does that meant that the latest reincarnation of APR::Pool
> implementation has this problem fixed?
If you're talking about my APR::Pool patch, then no,
it didn't resolve this. The underlying apr_pool_t
will be destroyed by APR::Pool::DESTROY in your
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
So does that meant that the latest reincarnation of APR::Pool
implementation has this problem fixed?
If you're talking about my APR::Pool patch, then no,
it didn't resolve this. The underlying apr_pool_t
will be destroyed by APR::Pool:
Stas Bekman <[EMAIL PROTECTED]> writes:
> which patch are you talking about Joe, the one that was committed
Yes.
[...]
> Do you have any tests that clearly demonstrate the problem?
Guaranteeing a segfault may be tricky, but here are few command-line
examples that work consistently for me:
Joe Schaefer wrote:
Do you have any tests that clearly demonstrate the problem?
Guaranteeing a segfault may be tricky,
They don't quite segfault for me. How is your system different than mine?
See my t/REPORT at the end of this email
but here are few command-line
examples that work consistentl
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
>
>>>Do you have any tests that clearly demonstrate the problem?
>> Guaranteeing a segfault may be tricky,
>
> They don't quite segfault for me. How is your system different than mine?
The major differences:
I'm testing 64bit debian o
Joe Schaefer wrote:
They don't quite segfault for me. How is your system different than mine?
The major differences:
I'm testing 64bit debian on the trunk of all projects (httpd, apr, mp2)
against a fresh perl-5.8.x snapshot, and I enabled every debugging option
I could think of (--enable-pool-deb
Stas Bekman <[EMAIL PROTECTED]> writes:
> In any case I'm pretty sure that you've already thought about a
> great solution and you have an almost working patch. Don't say that
> you don't have one :)
The solution IMO, is to do what Apache::Request::Table::new does:
keep a reference to the APR::P
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
In any case I'm pretty sure that you've already thought about a
great solution and you have an almost working patch. Don't say that
you don't have one :)
The solution IMO, is to do what Apache::Request::Table::new does:
keep a reference
14 matches
Mail list logo
