Bug#807038: Perl 5.22.1-RC3 is now available!

[Steve Hay]

On 4 December 2015 at 12:42, Niko Tyni  wrote:
> On Wed, Dec 02, 2015 at 10:17:44PM +0000, Steve Hay via perl5-porters wrote:
>
>> ***Please, please, please*** test your code against perl-5.22.1-RC3.
>> This is your last chance to point out any critical regressions before
>> v5.22.1 ships "for real," and we'd rather fix things for v5.22.1 than
>> for v5.22.2!
>
> Hi, we're seeing t/op/sprintf2.t failures on Debian powerpc and ppc64.
>
>  
> https://buildd.debian.org/status/fetch.php?pkg=perl&arch=powerpc&ver=5.22.1~rc3-1&stamp=1449230321
>  
> https://buildd.debian.org/status/fetch.php?pkg=perl&arch=ppc64&ver=5.22.1~rc3-1&stamp=1449231009
>
> I've reproduced these with the pristine 5.22.1-RC3 (no Debian
> modifications) and just './Configure -des'.

For the record, this should now be fixed in maint-5.22 by

http://perl5.git.perl.org/perl.git/commit/a0a02d15d36b673efaac1e8c47f5cbb17dbffe0d
http://perl5.git.perl.org/perl.git/commit/51b08a51ddedbde437e8f79b55ab9f6313b0c58a

and will shortly appear in an RC4. Thanks for testing.

Bug#777935: mod_perl2, MP_INLINE and gcc 5

[Steve Hay]

On 17 June 2015 at 19:57, Niko Tyni  wrote:
> On Wed, Jun 17, 2015 at 08:27:28PM +0300, Niko Tyni wrote:
>
>> mod_perl2 (up to and including 2.0.9-RC3) fails to build with GCC 5,
>> because the default inline semantics have changed from GNU89 to C99 and
>> require changes in mod_perl source.
>
> Ah, reading my own references properly, it looks like it might be a
> bit more complicated than that, and probably only happens when apr and
> mod_perl are compiled with different inline semantics. Is that correct?
>
> Sorry for the confusion. I still think a note somewhere could help...

I was just about to roll the release this evening when I saw this. A
minor README update surely doesn't warrant a new RC so I'm prepared to
slip the note in now. Is the wording still accurate, given that the
situation is more complicated than you first thought?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#765174: [PATCH] Don't call modperl_threaded_mpm() et al. from XS code

[Steve Hay]

On 15 October 2014 09:20, Niko Tyni  wrote:
> r594345 (and later r1241983 and r1245916, all merged into trunk with
> r1602105) modified modperl_trace() to call functions that are provided
> by mod_perl.c. However, the same code is compiled into the APR XS module
> without mod_perl.o linkage, so we end up with missing symbols in APR.so.
>
> % objdump -T blib/arch/auto/APR/APR.so|grep UND|grep modperl
>   D  *UND*    
> modperl_is_running
>   D  *UND*    
> modperl_threaded_mpm
>   D  *UND*    
> modperl_threads_started
>
> For the most part these missing symbols don't matter when modperl_trace()
> doesn't actually get called, but CPAN modules like Apache-Gallery that
> use APR and run their suites with PERL_DL_NONLAZY=1 now fail their tests
> because of this.
>
> Guard the problematic invocations with #ifndef MP_IN_XS, which is
> defined for the XS module builds.
>
> Bug-Debian: https://bugs.debian.org/765174
> ---
>  src/modules/perl/modperl_common_log.c | 2 ++
>  1 file changed, 2 insertions(+)
>

Thanks, committed in revision 1632172.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697682: libapache2-mod-perl2: Intermittent FTBFS: t/apache/read3.t failure

[Steve Hay]

On 5 September 2014 20:06, Niko Tyni  wrote:
> On Wed, Aug 13, 2014 at 11:47:58AM +0300, Niko Tyni wrote:
>> On Wed, Aug 13, 2014 at 09:12:11AM +0100, Steve Hay wrote:
>>
>> > Thanks for the patch. I haven't seen this failure myself on Windows,
>> > but the patch certainly doesn't seem to break anything. I'm a little
>> > uneasy about it, though. It seems odd to structure read3.pm
>> > differently to read2.pm and read4.pm, which still have a plan emitted
>> > before the first read().
>> >
>> > Why does read3.pm deadlock but read2.pm and read4.pm don't? If it's
>> > just luck then perhaps read2.pm and read4.pm should be changed
>> > similarly?
>>
>> It only happens with read3 because the POSTed string in that test is
>> very much larger than the other ones. LWP::Protocol::http sends the
>> whole POST request in one write() unless it's over eight kilobytes long
>> (see lib/LWP/Protocol/http.pm in libwww-perl_6.08 line 276.)
>
> I've updated the attached patch to change read2 too. read4 is quite
> different though, as it reads just a few bytes at a time, so I think
> it's OK to leave it as is.
>
>> > Maybe a comment in the code would be good too, since the structure of
>> > most test files is to get the plan out early. Otherwise there is scope
>> > for re-introducing the bug in the future since it isn't obvious that
>> > the placement of the plan is important.
>
> Done as well.
>

Thanks, applied in revision 1624218.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#756989: t/apr-ext failures at gcc -O0

[Steve Hay]

On 13 August 2014 09:16, Steve Hay  wrote:
> On 7 August 2014 12:50, Niko Tyni  wrote:
>> I'm attaching a patch that modifies the Makefile.PL files accordingly.
>> I expect there are other ways to accomplish the same thing too.
>>
>> This is also https://bugs.debian.org/756989 (cc'd).
>> --
>
> Thanks, I will apply this later today after more testing.

Now applied in revision 1617722.


>
> I think the same trick in xs/APR/aprext will also save modperl_dummy.c
> from needing to include a dummy perl_module too :-) I.e.
> http://svn.apache.org/viewvc?view=revision&revision=1502392 can
> largely be undone, with the appropriate MP_IN_XS magic in aprext's
> Makefile.PL too (and it looks like APR/Const also needs it). (The
> dummy file is still needed for other symbols too, though -- see
> http://svn.apache.org/viewvc?view=revision&revision=1538006. I don't
> know of any other way around that, though.)

And also now done in revision 1617727.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#754901: [PATCH] Fix invalid code that breaks with GCC 4.9 -ftree-dse optimization

[Steve Hay]

On 10 August 2014 21:16, Niko Tyni  wrote:
> This fixes SIGSEGVs at the start of the test suite when built with
> GCC-4.9 at -O2 (which includes -ftree-dse).
>

Thanks for the patch. Now applied in revision 1617680.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#756989: t/apr-ext failures at gcc -O0

[Steve Hay]

On 7 August 2014 12:50, Niko Tyni  wrote:
> Hi,
>
> we're seeing t/apr-ext failures when building without optimization on
> current Debian unstable (Apache 2.4.10, Perl 5.18.2).
>
> It looks like APR.so can only be loaded from inside mod_perl:
>
>  % perl -Iblib/lib -Iblib/arch -MAPR -e1
>  Can't load 'blib/arch/auto/APR/APR.so' for module APR: 
> blib/arch/auto/APR/APR.so: undefined symbol: perl_module
> at /usr/lib/perl/5.18/DynaLoader.pm line 184.
>   at -e line 0.
>  Compilation failed in require.
>  BEGIN failed--compilation aborted.

Yes, I think that's correct/normal.


>
> The problem comes from src/modules/perl/modperl_apache_includes.h:
>
>  #if !defined(MP_IN_XS) && AP_MODULE_MAGIC_AT_LEAST(20100606, 0)
>  APLOG_USE_MODULE(perl);
>  #endif
>
> where APLOG_USE_MODULE(perl) expands via /usr/include/apache2/http_config.h to
>
>  extern module perl_module; static int * const aplog_module_index = 
> &(perl_module.module_index);
>
> At -O2, this is optimized away when it's not used, but -O0 keeps it.
>
> The MP_IN_XS guard looks promising; defining that for the APR (and
> APR/PerlIO) build seems to help.  I was able to get the test suite pass
> at both -O0 and -O2 with the attached patch.
>
> It seems possible that other parts of xs/ are affected too but aren't
> exercised by the test suite.
>
> The history of MP_IN_XS usage is just
>
>  http://svn.apache.org/viewvc?view=revision&revision=1410295
>  http://svn.apache.org/viewvc?view=revision&revision=68792
>
> but it looks like a "correct" solution to me. Does that make sense?
>
> I'm attaching a patch that modifies the Makefile.PL files accordingly.
> I expect there are other ways to accomplish the same thing too.
>
> This is also https://bugs.debian.org/756989 (cc'd).
> --

Thanks, I will apply this later today after more testing.

I think the same trick in xs/APR/aprext will also save modperl_dummy.c
from needing to include a dummy perl_module too :-) I.e.
http://svn.apache.org/viewvc?view=revision&revision=1502392 can
largely be undone, with the appropriate MP_IN_XS magic in aprext's
Makefile.PL too (and it looks like APR/Const also needs it). (The
dummy file is still needed for other symbols too, though -- see
http://svn.apache.org/viewvc?view=revision&revision=1538006. I don't
know of any other way around that, though.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697682: libapache2-mod-perl2: Intermittent FTBFS: t/apache/read3.t failure

[Steve Hay]

On 9 August 2014 11:41, Niko Tyni  wrote:
> tag 697682 = patch
> thanks
>
> On Thu, Aug 07, 2014 at 04:32:08PM +0300, Niko Tyni wrote:
>> On Sat, Mar 30, 2013 at 03:26:55PM +, Dominic Hargreaves wrote:
>
>> > This doesn't seem to be limited to s390; I've seen it in on i386 during
>> > perl 5.16 rebuilds.
>>
>> As a data point, t/apache/read3.t fails for me consistently on the
>> kfreebsd-{i386,amd64} porter boxes (fischer and falla) but interestingly
>> not on the kfreebsd buildds.
>>
>> The test is getting an internal server error, with this in the
>> error log:
>>
>>   [Thu Aug 07 13:30:28.768239 2014] [perl:error] [pid 81995:tid 34593212160] 
>> [client 127.0.0.1:12832] Apache2::RequestIO::read: (70007) The timeout 
>> specified has expired at 
>> /home/ntyni/libapache2-mod-perl2-2.0.8+httpd24-r1449661/t/response/TestApache/read3.pm
>>  line 30
>
> As this was fully reproducible on the Debian/kFreeBSD boxes, I spent
> some time debugging it.
>
[...]
>
> I'm unsure if there's a fault with the client (it gets an FD that's
> ready for writing from the first select() call but ignores it, calls
> select() again and blocks because the server has already called poll()
> on the same descriptor), but the deadlock can be fixed/worked around by
> making the server not send a response before the full POST request has
> been read. See the attached patch, which fixes this completely for me.
>
> I can also reproduce the issue on amd64 by running the test in a loop and
> putting some load on the host. The patch makes it go away there too.
>
> Cc'ing the modperl dev list. Please consider applying the patch.

Thanks for the patch. I haven't seen this failure myself on Windows,
but the patch certainly doesn't seem to break anything. I'm a little
uneasy about it, though. It seems odd to structure read3.pm
differently to read2.pm and read4.pm, which still have a plan emitted
before the first read().

Why does read3.pm deadlock but read2.pm and read4.pm don't? If it's
just luck then perhaps read2.pm and read4.pm should be changed
similarly?

Maybe a comment in the code would be good too, since the structure of
most test files is to get the plan out early. Otherwise there is scope
for re-introducing the bug in the future since it isn't obvious that
the placement of the plan is important.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702821: perl/hash_attack.t fails with 5.10.1 + CVE-2013-1667 fix

[Steve Hay]

Steve Hay wrote on 2013-03-14:
> Niko Tyni wrote on 2013-03-13:
>> On Wed, Mar 13, 2013 at 09:13:15AM -0000, Steve Hay wrote:
>>> Dominic Hargreaves wrote on 2013-03-12:
>> 
>>>> When trying to fix this issue in Debian stable, I found that the
>>>> patch at
>>>> 
>>>> http://svn.apache.org/viewvc?view=revision&revision=1455340
>>>> 
>>>> does not stop the test failing when applied to 2.0.4 (as currently
>>>> found in Debian stable) and built against the current perl package
>>>> in Debian stable (5.10 + the rehashing fix).
>> 
>>> I haven't looked at the Debian package, or tried anything with
>>> mod_perl-2.0.4, but I've just checked out origin/maint-5.10 from
>>> the Perl git repo (in fact, I took the snapshot at
>>> 
>>> 
>>>
http://perl5.git.perl.org/perl.git/snapshot/f14269908e5f8b4cab4b55643d
>>> 7d d9de577e7918.tar.gz) and tried that with Apache 2.2.22 and
mod_perl
>>> from trunk and the tests all pass for me... (This is on Windows 7
x64
>>> with VC++ 2010.)
>> 
>> Thanks for checking.
>> 
>> FWIW, I can reproduce the failure with the Debian perl 5.10.1 package
>> and mod_perl2 2.0.7 with just the above test fix. So it doesn't seem
to
>> be a Debian change that breaks it. Maybe -Dusethreads or something
like
>> that.
>> 
>> I'll keep looking and send an update when I know more.
> 
> 
> The perl I built and tested with was made with ithreads enabled.
> 
> There is an alternative patch to fix this test, submitted to
> mod_perl's rt.cpan.org queue after I'd applied the patch from the
> perl5-security queue on rt.perl.org:
> 
> https://rt.cpan.org/Ticket/Display.html?id=83916
> 
> I haven't tried it myself yet, but is that any better for you?

Zefram has now come up with an even better patch (on the same RT
ticket), after reproducing the Debian 5.10.1 failure himself.

Please take a look (I've also attached it here for your convenience) and
let me know whether this works for you. If so then I hope to apply it to
SVN over the weekend.


hattack_synthesis.patch
Description: hattack_synthesis.patch

Bug#702821: perl/hash_attack.t fails with 5.10.1 + CVE-2013-1667 fix

[Steve Hay]

Niko Tyni wrote on 2013-03-13:
> On Wed, Mar 13, 2013 at 09:13:15AM -0000, Steve Hay wrote:
>> Dominic Hargreaves wrote on 2013-03-12:
> 
>>> When trying to fix this issue in Debian stable, I found that the
patch
>>> at
>>> 
>>> http://svn.apache.org/viewvc?view=revision&revision=1455340
>>> 
>>> does not stop the test failing when applied to 2.0.4 (as currently
>>> found in Debian stable) and built against the current perl package
>>> in Debian stable (5.10 + the rehashing fix).
> 
>> I haven't looked at the Debian package, or tried anything with
>> mod_perl-2.0.4, but I've just checked out origin/maint-5.10 from the
>> Perl git repo (in fact, I took the snapshot at
>> 
>>
http://perl5.git.perl.org/perl.git/snapshot/f14269908e5f8b4cab4b55643d
>> 7d d9de577e7918.tar.gz) and tried that with Apache 2.2.22 and
mod_perl
>> from trunk and the tests all pass for me... (This is on Windows 7 x64
>> with VC++ 2010.)
> 
> Thanks for checking.
> 
> FWIW, I can reproduce the failure with the Debian perl 5.10.1 package
> and mod_perl2 2.0.7 with just the above test fix. So it doesn't seem
to
> be a Debian change that breaks it. Maybe -Dusethreads or something
like
> that.
> 
> I'll keep looking and send an update when I know more.


The perl I built and tested with was made with ithreads enabled.

There is an alternative patch to fix this test, submitted to mod_perl's
rt.cpan.org queue after I'd applied the patch from the perl5-security
queue on rt.perl.org:

https://rt.cpan.org/Ticket/Display.html?id=83916

I haven't tried it myself yet, but is that any better for you?


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702821: perl/hash_attack.t fails with 5.10.1 + CVE-2013-1667 fix

[Steve Hay]

Dominic Hargreaves wrote on 2013-03-12:
> Hello,
> 
> When trying to fix this issue in Debian stable, I found that the patch
at
> 
> http://svn.apache.org/viewvc?view=revision&revision=1455340
> 
> does not stop the test failing when applied to 2.0.4 (as currently
> found in Debian stable) and built against the current perl package in
> Debian stable (5.10 + the rehashing fix). t/logs/error_log simply
says:
> 
> [Tue Mar 12 21:09:23 2013] [error] [client 127.0.0.1] Failed to mount
> the hash collision attack at
/home/dom/working/pkg-perl/git/libapache2-
> mod-perl2/t/response/TestPerl/hash_attack.pm line 112,

> line 1.\n
> 
> This is the change:
> 
> http://perl5.git.perl.org/perl.git/commitdiff/f14269908e5f8b4cab4b5564
3
> d7dd9de577e7918
> 
> which differs a bit from that applied to 5.14:
> 
> http://perl5.git.perl.org/perl.git/commitdiff/d59e31fc729d8a39a774f03b
c
> 6bc457029a7aef2
> 
> although interestingly both test changes are identical.
> 
> Help to pin down this difference in behaviour would be appreciated.
> 
> The source for the package in question is at
> 
> http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libapache2-mod-
> perl2.git;a=shortlog;h=refs/heads/dom/squeeze-702821
> 
> Thanks,
> Dominic.
>


I haven't looked at the Debian package, or tried anything with
mod_perl-2.0.4, but I've just checked out origin/maint-5.10 from the
Perl git repo (in fact, I took the snapshot at
http://perl5.git.perl.org/perl.git/snapshot/f14269908e5f8b4cab4b55643d7d
d9de577e7918.tar.gz) and tried that with Apache 2.2.22 and mod_perl from
trunk and the tests all pass for me... (This is on Windows 7 x64 with
VC++ 2010.)


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#650675: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

[Steve Hay]

I'm afraid the details are not clear to me either, but I have tried the two 
patches out (after correcting an instance of code-before-declaration which VC++ 
doesn't accept in C files) and I find that (with the LimitExcept change 
reverted as per current svn Trunk) they make no visible difference to my setup: 
I don't see the "free unreferenced scalar" errors in the log file after running 
the tests with or without the patches, but I do still get an "Out of memory!" 
crash mid-way through the test suite either way :-(


-Original Message-
From: Fred Moyer [mailto:f...@redhotpenguin.com] 
Sent: 11 February 2012 17:50
To: Niko Tyni
Cc: d...@perl.apache.org; 650...@bugs.debian.org
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Fri, Feb 10, 2012 at 10:51 PM, Niko Tyni  wrote:
> Hi Fred (and hopefully the list),

Looks like it made it through.  Suggest inlining your patches next time instead 
of using attachments, sometimes the list code may filter on those.
>
> as seen in , we're seeing numerous 
> lines of
>  Attempt to free unreferenced scalar: SV 0x7f9c0c347490, Perl interpreter: 
> 0x7f9c0c1a2dd0 during global destruction.
> on Debian unstable with 2.0.5 and Perl 5.14.2. I've been trying to get 
> patches through to the mod-perl dev list with no success; there seems 
> to be something broken with the list moderation. (I'd be happy to 
> provide message-ids and the like if somebody is interested, and they 
> can also be found in the bug log.)


I looked through the patches and grok the syntax, but the finer details aren't 
clear to me yet.  Maybe some of the other devs
(gozer,steve,torsten) can comment on them.  I'll hold rc2 for a few days to 
give them a chance to respond.


> I've verified that those still get emitted with 2.0.6 RC1. The test 
> suite passes, but
>  % grep unreferenced t/logs/error_log|wc -l
>  30

Can you post some of that error log which shows the error?


> This seems related to -Dusethreads and started with 5.13.6 or so; 
> please see
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650675#50
> for the full analysis including the perl change that broke this.
>
> Could you please consider these patches for 2.0.6, or let me know if 
> I've got it all wrong.

Thanks for the contribution.  Anyone else here see those errors previously, or 
can reproduce them now?

>
> Thanks for your work,
> --
> Niko Tyni   nt...@debian.org

-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional 
commands, e-mail: dev-h...@perl.apache.org




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#480997: podlators 2.1.2 released

[Steve Hay]

Russ Allbery wrote:
> This release fixes another bug (with S<>) in UTF-8 output from
> Pod::Man, uses the standard .SS macro for subsections, and fixes a
> variety of spelling and markup errors in all the documentation thanks
> to a new test. 

Thanks, upgraded in #34153.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]