perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2] t\apache\content_length_header access violation
Date Fri, 03 Dec 2004 14:58:16 GMT
Markus Wichitill wrote:
> Stas Bekman wrote:
>>> Markus Wichitill wrote:
>>>> When I run the full test suite of mod_perl 1.99_18-SVN on WinXP, 
>>>> while t\apache\content_length_header.t is executing, Windows pops up 
>>>> one of its access violation dialogs that lets me start the debugger. 
>>>> All tests incl. content_length_header continue to run ok in the 
>>>> background though, and only start failing when I click OK to dismiss 
>>>> the dialog, or stop when I click Cancel to open the debugger.
>>> I could've sworn that on Linux the tests ran through, but I now get 
>>> the same crash there, but at least the tests properly fail:
>> I don't seem to reproduce this problem with a very similar setup, [...]
>> Could you please trace when this problem started to appear?
> Rev 106913 makes the difference. Luckily, that was my first guess.
> "correct the config, A-T was placing
>   PerlInterpScope handler
> </IfDefine>
> on the top level which was affecting other tests"

But I can't see any relation. If you use the current svn and just add
  PerlInterpScope handler
in the <Location> block for this handler (after httpd.conf was created), 
does it make the problem go away?

I don't understand why I don't that problem. do you get it as a standalone 
or just in 'make test'. I'd guess the latter, since you also get errors like:

[Thu Dec 02 19:48:47 2004] [error] [client] 
Apache::RequestIO::read: (9) Bad file descriptor at /usr/src/modperl-2.0/t
/response/TestApache/ line 26

so it's most likely something else goes wrong when it hits this test. If 
that's the case could you t/SMOKE to find the problematic sequence?

>>>   @INC:
>>>     /usr/local/perl/lib
>>>     /usr/local/perl/lib
>>>     /usr/local/perl/lib
>>>     /usr/local/perl/lib
>> That's a peculiar @INC :)
> Apparently Perl's Configure can't fold the paths if they're the same. 
> Hasn't caused any problems so far, though. But then I usually eliminate 
> the duplicates in

You probably want to report that to p5p, this is definitely not correct.

> I've never liked how with Perl and Unix in general the paths are overly 
> complicated by default, just because someone out there might possibly 
> want to mix different versions and architectures and whatnot. Just think 
> of how many problems on the mailing lists are caused by different 
> library/module versions in parallel paths.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message