Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Devel-Cover CPAN distribution.

Report information
The Basics
Id: 42532
Status: open
Priority: 0/
Queue: Devel-Cover

People
Owner: Nobody in particular
Requestors: markhamnr [...] bigfoot.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 0.63
  • 0.64
Fixed in: (no value)



Subject: calling Devel::Cover::report on exec()
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Charset: utf8
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1232387026-29719-239"
Content-Length: 0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Length: 748
Download (untitled) / with headers
text/plain 748b
It may be a matter of opinion whether this is actually a bug... Starting with version 0.63, Devel::Cover calls Devel::Cover::report automatically when a process does an exec. (See line 1135 of Cover.xs version 0.63.) This means that information about coverage will appear in the process's standard output. Because of this, it's easy to construct code that runs differently under Devel::Cover than on its own; I attach an example. (The real problem, of course, is unit tests that pass when run normally but fail under Devel::Cover.) I infer that this behavior is deliberate, so maybe it doesn't constitute a bug, but I would prefer if it were removed or at least made optional. Maybe I could: use Devel::Cover 'silent' or something similar?
Subject: test.pl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1232387026-29719-238"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Charset: utf8
Content-Length: 0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: iso-8859-1
Content-Length: 0
Content-Type: text/x-perl; name="test.pl"
Content-Disposition: inline; filename="test.pl"
Content-Transfer-Encoding: binary
Content-Length: 368
Download test.pl
text/x-perl 368b
#! /usr/bin/perl use strict; use warnings; use IO::Pipe; my $pipe = new IO::Pipe; defined(my $pid = fork) or die $!; if ($pid) { $pipe->reader; print "Output is: ***\n"; print '* ', $_ for <$pipe>; print "***\n"; close $pipe or die $!; waitpid $pid, 0; } else { $pipe->writer; open STDOUT, '>&', $pipe or die $!; exec 'date'; }
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-16542-1353269269-729.42532-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1250
Download (untitled) / with headers
text/plain 1.2k
On 2009-01-19 12:43:50, markhamnr wrote: Show quoted text
> It may be a matter of opinion whether this is actually a bug... > > Starting with version 0.63, Devel::Cover calls Devel::Cover::report > automatically when a process does an exec. (See line 1135 of Cover.xs > version 0.63.) This means that information about coverage will appear > in the process's standard output. Because of this, it's easy to > construct code that runs differently under Devel::Cover than on its own; > I attach an example. (The real problem, of course, is unit tests that > pass when run normally but fail under Devel::Cover.) > > I infer that this behavior is deliberate, so maybe it doesn't constitute > a bug, but I would prefer if it were removed or at least made optional. > Maybe I could: > > use Devel::Cover 'silent' > > or something similar?
I think this *is* a bug. Devel::Cover shouldn't disturb pipes and forks. My suggestion: on Devel::Cover load time, remember the pid of the process. At the end do the reporting only if ($$ == $remembered_pid). (A similar technique is used in Perl/Tk --- the parent pid is remembered and is accessible through the function Tk::IsParentProcess(), so subsystems may behave differently for child processes) Regards, Slaven


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.