Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Test-Simple CPAN distribution.

Report information
The Basics
Id: 22102
Status: resolved
Priority: 0/
Queue: Test-Simple

People
Owner: Nobody in particular
Requestors: rybskej [...] yahoo.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.33
Fixed in: (no value)



Subject: Test::Builder breaks on 'forks' CPAN module
When using Test::Builder with the CPAN distribution "forks" (http://search.cpan.org/~rybskej/forks-0.20/) on a non-threaded perl, a special ithreads "share" subroutine, conditionally defined by Test::Builder, is incorrectly loaded. This results in incorrect "Test output counter mismatch" warnings, as exemplified by running the following test script on a non-threaded perl with forks 0.20: http://search.cpan.org/src/RYBSKEJ/forks-0.20/t/forks03.t This problem is due to the following condition not being met (Test::Builder 0.33, line 18): # Load threads::shared when threads are turned on if( $] >= 5.008 && $Config{useithreads} && $INC{'threads.pm'}) { which then falls back to the following else case (Test::Builder 0.33, line 61): # 5.8.0's threads::shared is busted when threads are off. # We emulate it here. else { *share = sub { return $_[0] }; *lock = sub { 0 }; } This causes the working share and lock functions of forks (and forks::shared) to be incorrectly overloaded. The simplest and most portable solution to support the forks module would be to modify the original condition statement to the following: if( $] >= 5.006 && $INC{'threads.pm'}) { This change would have no negative affect (compilation performance or otherwise) to any applications or modules that use Test::Builder. I have included a patch containing this modification with this report.
Subject: test-builder_forks_patch.1
Download test-builder_forks_patch.1
application/octet-stream 470b

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #22102] Test::Builder breaks on 'forks' CPAN module
Date: Tue, 17 Oct 2006 17:26:02 -0700
To: bug-Test-Simple [...] rt.cpan.org
From: Michael G Schwern <schwern [...] gmail.com>
via RT wrote: Show quoted text
> This problem is due to the following condition not being met > (Test::Builder 0.33, line 18): > > # Load threads::shared when threads are turned on > if( $] >= 5.008 && $Config{useithreads} && $INC{'threads.pm'}) { > > which then falls back to the following else case (Test::Builder 0.33, > line 61): > > # 5.8.0's threads::shared is busted when threads are off. > # We emulate it here. > else { > *share = sub { return $_[0] }; > *lock = sub { 0 }; > } > > This causes the working share and lock functions of forks (and > forks::shared) to be incorrectly overloaded. > > The simplest and most portable solution to support the forks module > would be to modify the original condition statement to the following: > > if( $] >= 5.006 && $INC{'threads.pm'}) { > > This change would have no negative affect (compilation performance or > otherwise) to any applications or modules that use Test::Builder. I > have included a patch containing this modification with this report.
If I'm reading that correctly, if the user has threads turned on in 5.6 Test::Builder is going to try and use them. 5.8.0 is bad enough that I've already dropped threading support for it in 0.64_01. Lemme think out loud for a moment. The original intention of that code was to A) work around the bugs in 5.8.0's threads::shared, B) provide share() and lock() for Perls without threads::shared at all, C) avoid bugs in earlier perl's threading implementations. But I've always said Test::Builder should be as generic as possible and if you want to blow off your own foot go right ahead. So perhaps the code should allow the user to use threads if available and only the tests skip over threading tests for 5.8.0 and older.
Subject: Re: [rt.cpan.org #22102] Test::Builder breaks on 'forks' CPAN module
Date: Tue, 17 Oct 2006 19:44:50 -0700 (PDT)
To: bug-Test-Simple [...] rt.cpan.org
From: Eric Rybski <rybskej [...] yahoo.com>
--- Michael G Schwern via RT <bug-Test-Simple@rt.cpan.org> wrote: Show quoted text
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=22102 > > > If I'm reading that correctly, if the user has threads turned on in > 5.6 Test::Builder is going to try and use them. 5.8.0 is bad enough > that I've already dropped threading support for it in 0.64_01.
Well, perl 5.6 doesn't have support for native ithreads (threads.pm) and threads.pm from CPAN will refuse to install on perl 5.6 anyway, so this would likely not be an issue. I personally have found native threads.pm to be overally unreliable (both in memory and stability) when using it with a variety of critical CPAN modules (such as DBI). The goal of the forks module is to implement the ithreads interface in a way that is portable, stable, and efficient in memory use from perl 5.6 on up. My hope is that it will help give the ithreads interface a second chance for users that wish to use an accepted, standard threading API in perl. So my intention is not to complicate matters with your module's patches for buggy threads.pm releases, but allow users of the forks module (such as myself) to write thread-safe tests with your test module suite. Show quoted text
> > Lemme think out loud for a moment. > > The original intention of that code was to A) work around the bugs in > 5.8.0's threads::shared, B) > provide share() and lock() for Perls without threads::shared at all, > C) avoid bugs in earlier perl's threading implementations. >
Perhaps I ought to insure that forks.pm emulate _all_ elements of a standard threads.pm environment, including the $Config{useithreads}, to be as portable as possible with existing "thread-aware" modules. I'm evaluating having the next forks.pm release override Config.pm and set a runtime value $Config{useithreads} = 1; thus, the current "if" statement would work fine for users of perl 5.8 and forks.pm. I've already got this working in a pre-release and confirmed, with perl 5.8.7, that forks co-exists peacefully with an unmodified Test::Builder! That would only leave perl 5.6 users unable to use forks.pm with Test::Builder with threaded applications. In all practicality, this would represent so few users (if any), that it would likely not be worth modifying Test::Builder just for them. Show quoted text
> But I've always said Test::Builder should be as generic as possible > and if you want to blow off your own foot go right ahead. So perhaps > the code should allow the user to use threads if available and only > the tests skip over threading tests for 5.8.0 and older. >
Overall, it's up to your discretion whether a change to Test::Builder makes sense or not. Since I'm planning to make the aforementioned change to forks.pm to allow full "threaded" compatibility with current and older Test::Builder releases, the only remaining, potentially affected users would be perl 5.6 users writing threaded test programs with forks.pm and Thread::Builder. Thanks for the feedback, Eric
Even taking the Config{useithreads} check out, I still get the 'WHOA' messages from the forks.pm tests. I don't really understand the problem well enough to suggest another fix. Or are the WHOA messages because of the bug described in #19310?
Subject: Re: [rt.cpan.org #22102] Test::Builder breaks on 'forks' CPAN module
Date: Mon, 23 Jun 2008 08:52:17 -0400
To: bug-Test-Simple [...] rt.cpan.org
From: "Eric Rybski" <rybskej [...] yahoo.com>
WOAH messages are because of bug #19310, and are unrelated to this case. As of forks 0.21, as long as forks is loaded before any of the Test::* modules, forks insures that Perl's Config.pm useithreads flag returns a true value. This eliminates the "Test output counter mismatch" errors originally reported in this case. Note that it still may not be necessary to check whether $Config{useithreads} is enabled (as I believe that native threads.pm throws a terminal error if attempted to be loaded on a non-threaded Perl) since it's already checking whether "threads.pm" is in %INC. On Fri, Jun 20, 2008 at 3:32 PM, Hans Dieter Pearcey via RT < bug-Test-Simple@rt.cpan.org> wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=22102 > > > Even taking the Config{useithreads} check out, I still get the 'WHOA' > messages from the forks.pm tests. I don't really understand the problem > well enough to suggest another fix. > > Or are the WHOA messages because of the bug described in #19310? >
On Mon Jun 23 05:59:56 2008, rybskej@yahoo.com wrote: Show quoted text
> WOAH messages are because of bug #19310, and are unrelated to this case. > As of forks 0.21, as long as forks is loaded before any of the Test::* > modules, forks insures that Perl's Config.pm useithreads flag returns a true > value. This eliminates the "Test output counter mismatch" errors originally > reported in this case. > Note that it still may not be necessary to check whether > $Config{useithreads} is enabled (as I believe that native threads.pm throws > a terminal error if attempted to be loaded on a non-threaded Perl) since > it's already checking whether "threads.pm" is in %INC. > > > On Fri, Jun 20, 2008 at 3:32 PM, Hans Dieter Pearcey via RT < > bug-Test-Simple@rt.cpan.org> wrote: >
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=22102 > > > > > Even taking the Config{useithreads} check out, I still get the 'WHOA' > > messages from the forks.pm tests. I don't really understand the problem > > well enough to suggest another fix. > > > > Or are the WHOA messages because of the bug described in #19310? > >
Closing this ticket for now. If this is still a problem and needs to be addressed please submit an example test failure, and a new ticket on github.