Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cond_wait hang ups under MSWin32 #8793

Closed
p5pRT opened this issue Feb 22, 2007 · 56 comments
Closed

cond_wait hang ups under MSWin32 #8793

p5pRT opened this issue Feb 22, 2007 · 56 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 22, 2007

Migrated from rt.perl.org#41574 (status was 'resolved')

Searchable as RT41574$

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

From @jdhedden

Created by @jdhedden

There have been previous reports of this phenomenon on p5p.
It manifests itself most often with hung ups on t/cond.t in
the threads​::shared module. The attached script is the
relevant portion from that test script and illustrates the
problem.

The script starts a bunch of threads that do different
amounts of work, but are then restricted via a mutex to
finishing in 'numeric' order. The bug is that sometimes a
thread will not move off of the cond_wait call to check the
mutex value.

I tracked down the problem to the COND_WAIT macro in
lib/CORE/win32thread.h. The 'stuck' thread is waiting on
the WaitForSingleObject() call in that macro even though
some other thread has made the appropriate COND_BROADCAST
call. It's not apparent to me that there is any race
condition involved, and am inclined to conclude this may be
a bug in Windows. However, I can't be sure of all this.

Win 2K
ActivePerl 5.8.8 (build 819)
threads 1.58
threads-shared 1.07

Perl Info

Flags:
    category=core
    severity=high

Site configuration information for perl v5.8.8:

Configured by SYSTEM at Tue Aug 29 12:39:43 2006.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=MSWin32, osvers=5.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
-DHAVE_DES_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTOMIZE
-DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_READFIX -DHASATTRIBUTE -fno-strict-aliasing',
    optimize='-O2',
    cppflags='-DWIN32'
    ccversion='12.00.8804', gccversion='3.4.2 (mingw-special)',
gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8,
Off_t='__int64', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf 
-libpath:"C:\Perl\lib\CORE"  -machine:x86'
    libpth=\lib
    libs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32
-lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm
-lversion -lodbc32 -lodbccp32 -lmsvcrt
    perllibs=-lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32
-ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32
-lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lmsvcrt
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -L"C:\Perl\lib\CORE"'

Locally applied patches:
    ACTIVEPERL_LOCAL_PATCHES_ENTRY
    Iin_load_module moved for compatibility with build 806
    Avoid signal flag SA_RESTART for older versions of HP-UX
    PerlEx support in CGI::Carp
    Less verbose ExtUtils::Install and Pod::Find
    Patch for CAN-2005-0448 from Debian with modifications
    Rearrange @INC so that 'site' is searched before 'perl'
    Partly reverted 24733 to preserve binary compatibility
    28671 Define PERL_NO_DEV_RANDOM on Windows
    28376 Add error checks after execing PL_cshname or PL_sh_path
    28305 Pod::Html should not convert \"foo\" into ``foo''
    27736 Make perl_fini() run with Sun WorkShop compiler
    27619 Bug in Term::ReadKey being triggered by a bug in
Term::ReadLine
    27549 Move DynaLoader.o into libperl.so
    27528 win32_pclose() error exit doesn't unlock mutex
    27527 win32_async_check() can loop indefinitely
    27515 ignore directories when searching @INC
    27359 Fix -d:Foo=bar syntax
    27210 Fix quote typo in c2ph
    27203 Allow compiling swigged C++ code
    27200 Make stat() on Windows handle trailing slashes correctly
    27194 Get perl_fini() running on HP-UX again
    27133 Initialise lastparen in the regexp structure
    27034 Avoid \"Prototype mismatch\" warnings with autouse
    26970 Make Passive mode the default for Net::FTP
    26921 Avoid getprotobyname/number calls in IO::Socket::INET
    26897,26903 Make common IPPROTO_* constants always available
    26670 Make '-s' on the shebang line parse -foo=bar switches
    26536 INSTALLSCRIPT versus INSTALLDIRS
    26379 Fix alarm() for Windows 2003
    26087 Storable 0.1 compatibility
    25861 IO::File performace issue
    25084 long groups entry could cause memory exhaustion
    24699 ICMP_UNREACHABLE handling in Net::Ping


@INC for perl v5.8.8:
    C:/Perl/site/lib
    C:/Perl/lib
    .


Environment for perl v5.8.8:
    CYGWIN=server ntsec
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\Perl\bin;C:\dev-cpp\bin;C:\djgpp\bin;C:\Program
Files\nant-0.85\bin;C:\Program
Files\apache-ant-1.6.3\bin;C:\j2sdk1.4.2_08\bin;C:\Program
Files\WiX;C:\Program
Files\Documentum\Shared;C:\blp\API;C:\oracle\ora92\bin;C:\Program
Files\Oracle\jre\1.3.1\bin;C:\Program
Files\Oracle\jre\1.1.8\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\system32\WBEM;C:\Program
Files\cvsnt;C:\Program Files\QuickTime\QTSystem
    PERL_BADLANG (unset)
    SHELL (unset)


 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

From @jdhedden

bug.pl

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

From @jdhedden

Attached is a slightly better version of the
'hang up' script. It uses cond_timedwait, but
shows the same symptom.

Note​: The script doesn't hang every time, but
just run it a few times and it will. Also,
at what point it hangs is variable.

____________________________________________________________________________________
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
http​://advision.webevents.yahoo.com/mailbeta/features_spam.html

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

From @jdhedden

bug.pl

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

From @steve-m-hay

Jerry D. Hedden wrote​:

Attached is a slightly better version of the
'hang up' script. It uses cond_timedwait, but
shows the same symptom.

Note​: The script doesn't hang every time, but
just run it a few times and it will. Also,
at what point it hangs is variable.

I've run the script about 20 times or more and haven't seen it hang at
all yet. Twice I got a load of messages like this​:

4 FAILED - timed out - cond_broadcast not received
5 FAILED - timed out
6 FAILED - timed out
7 FAILED - timed out
8 FAILED - timed out
9 FAILED - timed out
...

but the program still exited without hanging.

My overnight smokes still hang every night, though (maint as well as
blead now that the latest threads changes have been integrated).

--


Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses​: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Feb 22, 2007

From @jdhedden

Jerry D. Hedden wrote​:

Attached is a slightly better version of the
'hang up' script. It uses cond_timedwait, but
shows the same symptom.

Note​: The script doesn't hang every time, but
just run it a few times and it will. Also,
at what point it hangs is variable.

Steve Hay wrote​:

I've run the script about 20 times or more and haven't
seen it hang at all yet. Twice I got a load of messages
like this​:

4 FAILED - timed out - cond_broadcast not received
5 FAILED - timed out
6 FAILED - timed out
7 FAILED - timed out
8 FAILED - timed out
9 FAILED - timed out
...

but the program still exited without hanging.

Oh, stupid me! I should have changed my terminology. The
original script will hang - forcing you to terminate it with
^C. The 'new' script doesn't hang because of the timeout,
but that it still shows that the cond_broadcast is being
missed. Sorry for the confusion.

My overnight smokes still hang every night, though (maint
as well as blead now that the latest threads changes have
been integrated).

Yes, this bug report directly relates to this.

____________________________________________________________________________________
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http​://farechase.yahoo.com/promo-generic-14795097

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2007

From @demerphq

On 2/22/07, Jerry D. Hedden <jdhedden@​yahoo.com> wrote​:

Jerry D. Hedden wrote​:

Attached is a slightly better version of the
'hang up' script. It uses cond_timedwait, but
shows the same symptom.

Note​: The script doesn't hang every time, but
just run it a few times and it will. Also,
at what point it hangs is variable.

Steve Hay wrote​:

I've run the script about 20 times or more and haven't
seen it hang at all yet. Twice I got a load of messages
like this​:

4 FAILED - timed out - cond_broadcast not received
5 FAILED - timed out
6 FAILED - timed out
7 FAILED - timed out
8 FAILED - timed out
9 FAILED - timed out
...

but the program still exited without hanging.

Oh, stupid me! I should have changed my terminology. The
original script will hang - forcing you to terminate it with
^C. The 'new' script doesn't hang because of the timeout,
but that it still shows that the cond_broadcast is being
missed. Sorry for the confusion.

Can we not at least change the cond.t test so it uses something more
like your bug.pl?

At least then smoke wouldnt hang. Which would be a good thing in of itself.

My overnight smokes still hang every night, though (maint
as well as blead now that the latest threads changes have
been integrated).

Yes, this bug report directly relates to this.

Im trying to investigate this. I had a look at the MSDN documentation
for WaitForSingleObject() and it does mention issues with deadlocking,
however when i recoded things to use MsgWaitForMultipleObjects as
suggested I saw no change in behaviour.

When i attach the VC debugger to the hung process i see

"The process appears to deadlocked (or is not running any user-mode
code). All threads have been stopped."

With the following stack for the main thread​:

  NTDLL.DLL!77f88f13()
  KERNEL32.DLL!7c57b3e9()

perl59.dll!Perl_pp_entersub(interpreter * my_perl=0x01a423ec) Line
2834 + 0x10 C
  perl59.dll!Perl_runops_debug(interpreter * my_perl=0x01a423ec) Line
1921 + 0xd C
  perl59.dll!S_run_body(interpreter * my_perl=0x01a423ec, long
oldscope=1) Line 2431 + 0xd C
  perl59.dll!perl_run(interpreter * my_perl=0x01a423ec) Line 2349 + 0xd C
  perl59.dll!RunPerl(int argc=2, char * * argv=0x015d4df0, char * *
env=0x015d28c8) Line 266 + 0x9 C++
  perl.exe!main(int argc=2, char * * argv=0x015d4df0, char * *
env=0x015d33c0) Line 23 + 0x12 C
  perl.exe!mainCRTStartup() Line 400 + 0xe C
  KERNEL32.DLL!7c5989a5()

The relevent code is​:

Code from pp_hot.c Line 2832​:
  /* Do we need to open block here? XXXX */
  if (CvXSUB(cv)) /* XXX this is supposed to be true */
  (void)(*CvXSUB(cv))(aTHX_ cv);

The micosoft article is here​: http​://support.microsoft.com/kb/175332

Cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2007

From @demerphq

On 4/9/07, Jerry D. Hedden <jdhedden@​cpan.org> wrote​:

Yves wrote​:

I had a look at the MSDN documentation for
WaitForSingleObject() and it does mention issues with
deadlocking,

The micosoft article is here​:
http​://support.microsoft.com/kb/175332

Can we not at least change the cond.t test so it uses
something more like your bug.pl?

At least then smoke wouldnt hang. Which would be a good
thing in of itself.

Jerry D. Hedden wrote​:

Good idea. I'll work on it.

The troublesome code is labeled 'Stress test' in
threads/shared/t/cond.t. Since the problem seems to lie
with Win32, and not in threads/threads.xs or
threads/shared/shared.xs, should this test be moved under
perl-current/t?

Say in a new file called perl-current/t/op/shared.t?

To me it doesnt make sense to do so.

It is testing functionality specific to threads​::shared isnt it?

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Personally I dont think so. We should just make it not hang the smokes.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2007

From @jdhedden

Yves wrote​:

I had a look at the MSDN documentation for
WaitForSingleObject() and it does mention issues with
deadlocking,

The micosoft article is here​:
http​://support.microsoft.com/kb/175332

Can we not at least change the cond.t test so it uses
something more like your bug.pl?

At least then smoke wouldnt hang. Which would be a good
thing in of itself.

Jerry D. Hedden wrote​:

Good idea. I'll work on it.

The troublesome code is labeled 'Stress test' in
threads/shared/t/cond.t. Since the problem seems to lie
with Win32, and not in threads/threads.xs or
threads/shared/shared.xs, should this test be moved under
perl-current/t?

Say in a new file called perl-current/t/op/shared.t?

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2007

From @jdhedden

Can we not at least change the cond.t test so it uses
something more like your bug.pl?

At least then smoke wouldnt hang. Which would be a good
thing in of itself.

Good idea. I'll work on it.

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2007

From @jandubois

On Mon, 09 Apr 2007, demerphq wrote​:

On 2/22/07, Jerry D. Hedden <jdhedden@​yahoo.com> wrote​:

Jerry D. Hedden wrote​:

Attached is a slightly better version of the 'hang up' script. It
uses cond_timedwait, but shows the same symptom.

I've tried the revised bug.pl with the latest bleadperl, both on
a dual-processor Windows 2000 box in 32-bit mode and a single-processor
Windows 2003 box in 64-bit mode, and I cannot get it to hang on either
configuration.

Is there something special I need to do to get it to hang?

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2007

From @steve-m-hay

Jan Dubois wrote​:

On Mon, 09 Apr 2007, demerphq wrote​:

On 2/22/07, Jerry D. Hedden <jdhedden@​yahoo.com> wrote​:

Jerry D. Hedden wrote​:

Attached is a slightly better version of the 'hang up' script. It
uses cond_timedwait, but shows the same symptom.

I've tried the revised bug.pl with the latest bleadperl, both on
a dual-processor Windows 2000 box in 32-bit mode and a single-processor
Windows 2003 box in 64-bit mode, and I cannot get it to hang on either
configuration.

Is there something special I need to do to get it to hang?

I also didn't see it hang, but as Jerry pointed out it isn't supposed to
any more​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-02/msg00847.html

--

@p5pRT
Copy link
Author

p5pRT commented Apr 10, 2007

From @jandubois

On Tue, 10 Apr 2007, Steve Hay wrote​:

Jan Dubois wrote​:

I've tried the revised bug.pl with the latest bleadperl, both on a
dual-processor Windows 2000 box in 32-bit mode and a single-processor
Windows 2003 box in 64-bit mode, and I cannot get it to hang on
either configuration.

Is there something special I need to do to get it to hang?

I also didn't see it hang, but as Jerry pointed out it isn't supposed
to any more​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-02/msg00847.html

Well, I didn't see it fail on those systems (2000, 2003) either.

But I can now reproduce the failure on a Windows XP system. I'll try
to add some tracing to see if this adds any insight.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2007

From @jandubois

On Tue, 10 Apr 2007, Steve Hay wrote​:

Jan Dubois wrote​:

On Mon, 09 Apr 2007, demerphq wrote​:

On 2/22/07, Jerry D. Hedden <jdhedden@​yahoo.com> wrote​:

Jerry D. Hedden wrote​:

Attached is a slightly better version of the 'hang up' script. It
uses cond_timedwait, but shows the same symptom.

I've tried the revised bug.pl with the latest bleadperl, both on a
dual-processor Windows 2000 box in 32-bit mode and a single-processor
Windows 2003 box in 64-bit mode, and I cannot get it to hang on
either configuration.

Is there something special I need to do to get it to hang?

I also didn't see it hang, but as Jerry pointed out it isn't supposed
to any more​:

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-02/msg00847.html

I did add a bit of logging to all the COND_xxx() calls, but I'm too tired
right now to actually analyze it. I've attached the output in case someone
else wants to give it a try. The format is basically

  line-no timestamp [process-id] [thread-id] message

The big number at the end is the address of the semaphore.

Let me know if it would help to log anything else.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Apr 11, 2007

From @jandubois

fail.log

@p5pRT
Copy link
Author

p5pRT commented Apr 13, 2007

From @demerphq

On 4/9/07, demerphq <demerphq@​gmail.com> wrote​:

On 4/9/07, Jerry D. Hedden <jdhedden@​cpan.org> wrote​:

[snip]

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Personally I dont think so. We should just make it not hang the smokes.

Mea-culpa, im wrong. We /should/ todo it, although maybe only under
smoke testing.
cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 13, 2007

From @jdhedden

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​:

Personally I dont think so. We should just make it not hang the smokes.

Yves reconsidered​:

Mea-culpa, im wrong. We /should/ todo it, although maybe only under
smoke testing.

How do you distinguish when smoke testing is going on?

@p5pRT
Copy link
Author

p5pRT commented Apr 14, 2007

From @demerphq

On 4/14/07, Jerry D. Hedden <jdhedden@​cpan.org> wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​:

Personally I dont think so. We should just make it not hang the smokes.

Yves reconsidered​:

Mea-culpa, im wrong. We /should/ todo it, although maybe only under
smoke testing.

How do you distinguish when smoke testing is going on?

Well, I dont see any. I guess it doesnt matter. Use an environment
variable. Something like WIN32_SMOKE_SKIP_THREADS or something. People
who need it can set it up in a wrapper script.

cheers
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 16, 2007

From @jdhedden

Jan Dubois wrote​:

I did add a bit of logging to all the COND_xxx() calls, but I'm too tired
right now to actually analyze it. I've attached the output in case someone
else wants to give it a try.

I traced out the following​:

line
9 thr 1 acquires lock
20 thr 1 sends broadcast (ignored - no one listening)
26 thr 3 acquires lock
111 thr 3 enters cond_timedwait
127 thr 6 acquires lock
130 thr 6 enters cond_timedwait
134 thr 2 acquires lock
140 thr 2 sends broadcast

other threads go into timed wait

465 thr 3 times out
497 thr 6 times out

This shows that the OS failed to wake up either thr 3 or 6 when thr 2
sent its broadcast. As to why this is happening, I can't tell from
the log.

@p5pRT
Copy link
Author

p5pRT commented Apr 16, 2007

From @jdhedden

Jerry D. Hedden wrote​:

How do you distinguish when smoke testing is going on?

Yves wrote​:

Well, I dont see any. I guess it doesnt matter. Use an environment
variable. Something like WIN32_SMOKE_SKIP_THREADS or something. People
who need it can set it up in a wrapper script.

How about the following?

  # Gather thread results
  for (1..$cnt) {
  my $rc = $threads[$_]->join() || 'Thread failed';
- ok($_, ($rc eq 'okay'), $rc);
+ ok($_, ($rc eq 'okay'), (($ENV{'WIN32_SMOKE'}) ? '# TODO ' :
'') . $rc);
  }

  $Base += $cnt;

So if WIN32_SMOKE is true in the environment, the tests get flagged as TODO.

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From @jdhedden

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From @jdhedden

shared.patch
diff -ruN perl-current/ext/threads/shared/Changes perl-patch/ext/threads/shared/Changes
--- perl-current/ext/threads/shared/Changes	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/Changes	2007-04-17 11:36:22.000000000 -0400
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO if $ENV{'WIN32_SMOKE'} is true
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
diff -ruN perl-current/ext/threads/shared/shared.pm perl-patch/ext/threads/shared/shared.pm
--- perl-current/ext/threads/shared/shared.pm	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/shared.pm	2007-04-17 11:36:22.000000000 -0400
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
diff -ruN perl-current/ext/threads/shared/t/stress.t perl-patch/ext/threads/shared/t/stress.t
--- perl-current/ext/threads/shared/t/stress.t	2007-04-10 05:49:32.000000000 -0400
+++ perl-patch/ext/threads/shared/t/stress.t	2007-04-17 11:36:22.000000000 -0400
@@ -96,7 +96,7 @@
     # Gather thread results
     for (1..$cnt) {
         my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        ok($_, ($rc eq 'okay'), (($ENV{'WIN32_SMOKE'}) ? '# TODO ' : '') . $rc);
     }
 
     $Base += $cnt;

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From @steve-m-hay

Jerry D. Hedden wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

--

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From @jdhedden

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Jerry D. Hedden wrote​:

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

Steve Hay wrote​:

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

Okay. Then is the concensus that it should just be based on
'$^O eq MSWin32'?

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From @jdhedden

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Jerry D. Hedden wrote​:

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

Steve Hay wrote​:

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

Jerry D. Hedden wrote​:

Okay. Then is the concensus that it should just be based on
'$^O eq MSWin32'?

Attached patch does this.

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From @jdhedden

shared.patch
diff -ruN perl-current/ext/threads/shared/Changes perl-patch/ext/threads/shared/Changes
--- perl-current/ext/threads/shared/Changes	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/Changes	2007-04-17 12:29:10.000000000 -0400
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO under MSWin32
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
diff -ruN perl-current/ext/threads/shared/shared.pm perl-patch/ext/threads/shared/shared.pm
--- perl-current/ext/threads/shared/shared.pm	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/shared.pm	2007-04-17 12:29:10.000000000 -0400
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
diff -ruN perl-current/ext/threads/shared/t/stress.t perl-patch/ext/threads/shared/t/stress.t
--- perl-current/ext/threads/shared/t/stress.t	2007-04-10 05:49:32.000000000 -0400
+++ perl-patch/ext/threads/shared/t/stress.t	2007-04-17 12:29:10.000000000 -0400
@@ -96,7 +96,7 @@
     # Gather thread results
     for (1..$cnt) {
         my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        ok($_, ($rc eq 'okay'), (($^O eq 'MSWin32') ? '# TODO ' : '') . $rc);
     }
 
     $Base += $cnt;

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @demerphq

On 4/17/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Jerry D. Hedden wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

My feeling is that we should assertively test as much as we can, and
since the test is known not to fail from the command line on Win32 I
dont think it should be TODO in that case.

If it starts failing then its not a matter of "same-old, same-old" but
an indication things have gotten worse and we/I really should know
about it.

OTOH, sending in FAIL every time for smoking because of a well known
issue IMO deracts from the value of having smokes at all.

Maybe smoke itself should have some facilities to handle this. Maybe a
status line of "SUCCESS (with expected failures)" or something like
that.

Anyway, if the ENV var being checked is less smoke specific in name
then it doesnt matter. Ill just set up my smoke batch files to set the
var whatever it is.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

demerphq wrote​:

On 4/17/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Jerry D. Hedden wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

My feeling is that we should assertively test as much as we can, and
since the test is known not to fail from the command line on Win32 I
dont think it should be TODO in that case.

I agree with your comments about handling tests that fail under
Test-Smoke but not interactively, but this is not such a case for me (at
least)​: I just tried manually running the test half a dozen times and
here's the results​:

Failed 29-50
OK
Failed 38-50
OK
Failed 36-50
Failed 36-50

With this level of failure, even interactively, I think the test should
be marked TODO.

Are you saying that you don't see any failures if you repeatedly run the
test interactively?

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @demerphq

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

demerphq wrote​:

On 4/17/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Jerry D. Hedden wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

My feeling is that we should assertively test as much as we can, and
since the test is known not to fail from the command line on Win32 I
dont think it should be TODO in that case.

I agree with your comments about handling tests that fail under
Test-Smoke but not interactively, but this is not such a case for me (at
least)​: I just tried manually running the test half a dozen times and
here's the results​:

Failed 29-50
OK
Failed 38-50
OK
Failed 36-50
Failed 36-50

With this level of failure, even interactively, I think the test should
be marked TODO.

Are you saying that you don't see any failures if you repeatedly run the
test interactively?

I have never seen the stress test fail from a command line. Never.

BUT, I havent tried running it over and over either.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

demerphq wrote​:

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

demerphq wrote​:

On 4/17/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Jerry D. Hedden wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

My feeling is that we should assertively test as much as we can, and
since the test is known not to fail from the command line on Win32 I
dont think it should be TODO in that case.

I agree with your comments about handling tests that fail under
Test-Smoke but not interactively, but this is not such a case for me (at
least)​: I just tried manually running the test half a dozen times and
here's the results​:

Failed 29-50
OK
Failed 38-50
OK
Failed 36-50
Failed 36-50

With this level of failure, even interactively, I think the test should
be marked TODO.

Are you saying that you don't see any failures if you repeatedly run the
test interactively?

I have never seen the stress test fail from a command line. Never.

BUT, I havent tried running it over and over either.

Weird. I only ran it over and over to see with what sort of frequency it
fails, but I've often seen it fail when running the whole "nmake test"
test suite interactively.

So we're agreed that we don't want FAIL reports from Test-Smoke over
this issue, but we're not sure what's best for interactive users​: either
some users are going to get TODO tests unexpectedly passing, or else
other users are going to get normal tests unexpectedly failing.

I would say that an unexpected pass is less worrying that an unexpected
failure, so I'd still choose to make the test TODO, but I admit I'm
biased ;-)

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @demerphq

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

demerphq wrote​:

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

demerphq wrote​:

On 4/17/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Jerry D. Hedden wrote​:

Jerry D. Hedden wrote​:

Also, should the test be skipped/TODOed under Win32 until
the problem is fixed?

Yves wrote​::

We should todo it, although maybe only under smoke testing.

Use an environment variable. Something like
WIN32_SMOKE_SKIP_THREADS or something. People who need it
can set it up in a wrapper script.

Patch attached. If $ENV{'WIN32_SMOKE'} is true, then the
offending tests will be set TODO.

I'm not sure that it makes sense to only mark a test as TODO when run
under Test-Smoke.

Surely any test that is known to fail should be marked as TODO
regardless of how the test is being run.

My feeling is that we should assertively test as much as we can, and
since the test is known not to fail from the command line on Win32 I
dont think it should be TODO in that case.

I agree with your comments about handling tests that fail under
Test-Smoke but not interactively, but this is not such a case for me (at
least)​: I just tried manually running the test half a dozen times and
here's the results​:

Failed 29-50
OK
Failed 38-50
OK
Failed 36-50
Failed 36-50

With this level of failure, even interactively, I think the test should
be marked TODO.

Are you saying that you don't see any failures if you repeatedly run the
test interactively?

I have never seen the stress test fail from a command line. Never.

BUT, I havent tried running it over and over either.

Weird. I only ran it over and over to see with what sort of frequency it
fails, but I've often seen it fail when running the whole "nmake test"
test suite interactively.

So we're agreed that we don't want FAIL reports from Test-Smoke over
this issue, but we're not sure what's best for interactive users​: either
some users are going to get TODO tests unexpectedly passing, or else
other users are going to get normal tests unexpectedly failing.

I would say that an unexpected pass is less worrying that an unexpected
failure, so I'd still choose to make the test TODO, but I admit I'm
biased ;-)

That you see errors on the command line invalidates my original
argument, so I agree, it should be TODO always.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

Yves wrote​:

That you see errors on the command line invalidates my original
argument, so I agree, it should be TODO always.

So we have a consensus. The attached patch makes the test TODO under MSWin32.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

shared.patch
diff -ruN perl-current/ext/threads/shared/Changes perl-patch/ext/threads/shared/Changes
--- perl-current/ext/threads/shared/Changes	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/Changes	2007-04-17 12:29:10.000000000 -0400
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO under MSWin32
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
diff -ruN perl-current/ext/threads/shared/shared.pm perl-patch/ext/threads/shared/shared.pm
--- perl-current/ext/threads/shared/shared.pm	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/shared.pm	2007-04-17 12:29:10.000000000 -0400
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
diff -ruN perl-current/ext/threads/shared/t/stress.t perl-patch/ext/threads/shared/t/stress.t
--- perl-current/ext/threads/shared/t/stress.t	2007-04-10 05:49:32.000000000 -0400
+++ perl-patch/ext/threads/shared/t/stress.t	2007-04-17 12:29:10.000000000 -0400
@@ -96,7 +96,7 @@
     # Gather thread results
     for (1..$cnt) {
         my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        ok($_, ($rc eq 'okay'), (($^O eq 'MSWin32') ? '# TODO ' : '') . $rc);
     }
 
     $Base += $cnt;

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

Jerry D. Hedden wrote​:

Yves wrote​:

That you see errors on the command line invalidates my original
argument, so I agree, it should be TODO always.

So we have a consensus. The attached patch makes the test TODO under
MSWin32.

Is the patch correct? I'm a bit rusty on the mechanics of TODO tests at
the moment, but just running stress.t with your patch in place I get
output like the following. The failing case just says "FAILED tests
24-50" and makes no mention that this was expected, and the successful
case just says "All tests successful" and doesn't mention that this is
unexpected.

C​:\p5p\bleadperl\t>..\perl harness -v ..\ext\threads\shared\t\stress.t
../ext/threads/shared/t/stress....1..50
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
not ok 24
# Failed test at line 99
# Reason​: # TODO timed out - cond_broadcast not received
not ok 25
# Failed test at line 99
# Reason​: # TODO timed out
not ok 26
# Failed test at line 99
# Reason​: # TODO timed out
not ok 27
# Failed test at line 99
# Reason​: # TODO timed out
not ok 28
# Failed test at line 99
# Reason​: # TODO timed out
not ok 29
# Failed test at line 99
# Reason​: # TODO timed out
not ok 30
# Failed test at line 99
# Reason​: # TODO timed out
not ok 31
# Failed test at line 99
# Reason​: # TODO timed out
not ok 32
# Failed test at line 99
# Reason​: # TODO timed out
not ok 33
# Failed test at line 99
# Reason​: # TODO timed out
not ok 34
# Failed test at line 99
# Reason​: # TODO timed out
not ok 35
# Failed test at line 99
# Reason​: # TODO timed out
not ok 36
# Failed test at line 99
# Reason​: # TODO timed out
not ok 37
# Failed test at line 99
# Reason​: # TODO timed out
not ok 38
# Failed test at line 99
# Reason​: # TODO timed out
not ok 39
# Failed test at line 99
# Reason​: # TODO timed out
not ok 40
# Failed test at line 99
# Reason​: # TODO timed out
not ok 41
# Failed test at line 99
# Reason​: # TODO timed out
not ok 42
# Failed test at line 99
# Reason​: # TODO timed out
not ok 43
# Failed test at line 99
# Reason​: # TODO timed out
not ok 44
# Failed test at line 99
# Reason​: # TODO timed out
not ok 45
# Failed test at line 99
# Reason​: # TODO timed out
not ok 46
# Failed test at line 99
# Reason​: # TODO timed out
not ok 47
# Failed test at line 99
# Reason​: # TODO timed out
not ok 48
# Failed test at line 99
# Reason​: # TODO timed out
not ok 49
# Failed test at line 99
# Reason​: # TODO timed out
not ok 50
# Failed test at line 99
# Reason​: # TODO timed out
FAILED tests 24-50
  Failed 27/50 tests, 46.00% okay
Failed Test Stat Wstat Total Fail List of Failed


../ext/threads/shared/t/stress.t 50 27 24-50
Failed 1/1 test scripts. 27/50 subtests failed.
Files=1, Tests=50, 35 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Failed 1/1 test programs. 27/50 subtests failed.

C​:\p5p\bleadperl\t>..\perl harness -v ..\ext\threads\shared\t\stress.t
../ext/threads/shared/t/stress....1..50
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39
ok 40
ok 41
ok 42
ok 43
ok 44
ok 45
ok 46
ok 47
ok 48
ok 49
ok 50
ok 5734 ms
All tests successful.
Files=1, Tests=50, 6 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @rgs

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

not ok 24
# Failed test at line 99
# Reason​: # TODO timed out - cond_broadcast not received

"# TODO" should appear on the same line than "not ok".

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

Is the patch correct?

Ugh. My fault. I forgot that the test suite uses its own 'ok'
functions. I modified accordingly (and actually tested it :). New
patch attached. Please try this one. Thanks.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

shared.patch
diff -ruN perl-current/ext/threads/shared/Changes perl-patch/ext/threads/shared/Changes
--- perl-current/ext/threads/shared/Changes	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/Changes	2007-04-18 08:02:26.000000000 -0400
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO under MSWin32
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
diff -ruN perl-current/ext/threads/shared/shared.pm perl-patch/ext/threads/shared/shared.pm
--- perl-current/ext/threads/shared/shared.pm	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/shared.pm	2007-04-18 08:02:26.000000000 -0400
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
diff -ruN perl-current/ext/threads/shared/t/stress.t perl-patch/ext/threads/shared/t/stress.t
--- perl-current/ext/threads/shared/t/stress.t	2007-04-10 05:49:32.000000000 -0400
+++ perl-patch/ext/threads/shared/t/stress.t	2007-04-18 08:02:26.000000000 -0400
@@ -23,6 +23,8 @@
     # You have to do it this way or VMS will get confused.
     if ($ok) {
         print("ok $id\n");
+    } elsif ($why =~ /TODO/) {
+        print ("not ok $id $why\n");
     } else {
         print ("not ok $id\n");
         printf("# Failed test at line %d\n", (caller)[2]);
@@ -96,7 +98,7 @@
     # Gather thread results
     for (1..$cnt) {
         my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        ok($_, ($rc eq 'okay'), (($^O eq 'MSWin32') ? '# TODO ' : '') . $rc);
     }
 
     $Base += $cnt;

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

Jerry D. Hedden wrote​:

Is the patch correct?

Ugh. My fault. I forgot that the test suite uses its own 'ok'
functions. I modified accordingly (and actually tested it :). New
patch attached. Please try this one. Thanks.

That's better in that failures are now seen as "TODO" and hence not a
real problem​:

...
ok 25
ok 26
ok 27
ok 28
ok 29
not ok 30 # TODO timed out - cond_broadcast not received
not ok 31 # TODO timed out
not ok 32 # TODO timed out
not ok 33 # TODO timed out
not ok 34 # TODO timed out
not ok 35 # TODO timed out
...
ok 33328 ms
All tests successful.

but on the occasions that things happen to succeed I get the same as
before--a series of "ok"s followed by "All tests successful". There's no
message about tests unexpectedly passing which I had, er, expected to see.

I guess this is because of the way that stress.t has rolled its own test
result outputting rather than using Test​::More's TODO​: {} blocks.

Yves might see this as a Good Thing since it means that he won't see any
pesky messages about unexpected successes all the time, but it also
means that if the underlying problem ever gets fixed then I (or anyone
else) won't suddenly start getting unexpected successes so nobody will
necessarily remember to remove the "TODO" status from the tests.

Do you feel inclined to rework the script to use Test​::More or whatever
it takes for the more regular "TODO" business, or shall I just apply
this as it is?

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

Steve Hay wrote​:

Do you feel inclined to rework the script to use Test​::More or whatever
it takes for the more regular "TODO" business, or shall I just apply
this as it is?

There are interactions with Test​::More and threads which may have been
why it wasn't used in the first place. I don't think it's worthwhile
to re-engineer things just for this. Hopefully, someone like Jan will
fix the underlying bug soon.

BTW, I've updated the patch once more to include a comment referencing
the bug report. Attached.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

shared.patch
diff -ruN perl-current/ext/threads/shared/Changes perl-patch/ext/threads/shared/Changes
--- perl-current/ext/threads/shared/Changes	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/Changes	2007-04-18 09:33:28.000000000 -0400
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO under MSWin32
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
diff -ruN perl-current/ext/threads/shared/shared.pm perl-patch/ext/threads/shared/shared.pm
--- perl-current/ext/threads/shared/shared.pm	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/shared.pm	2007-04-18 09:33:28.000000000 -0400
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
diff -ruN perl-current/ext/threads/shared/t/stress.t perl-patch/ext/threads/shared/t/stress.t
--- perl-current/ext/threads/shared/t/stress.t	2007-04-10 05:49:32.000000000 -0400
+++ perl-patch/ext/threads/shared/t/stress.t	2007-04-18 09:33:28.000000000 -0400
@@ -23,6 +23,8 @@
     # You have to do it this way or VMS will get confused.
     if ($ok) {
         print("ok $id\n");
+    } elsif ($why =~ /TODO/) {
+        print ("not ok $id $why\n");
     } else {
         print ("not ok $id\n");
         printf("# Failed test at line %d\n", (caller)[2]);
@@ -96,7 +98,9 @@
     # Gather thread results
     for (1..$cnt) {
         my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        # Test is TODO under MSWin32 due to bug #41574
+        #   http://rt.perl.org/rt3/Public/Bug/Display.html?id=41574
+        ok($_, ($rc eq 'okay'), (($^O eq 'MSWin32') ? '# TODO ' : '') . $rc);
     }
 
     $Base += $cnt;

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

Rafael Garcia-Suarez wrote​:

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

but on the occasions that things happen to succeed I get the same as
before--a series of "ok"s followed by "All tests successful". There's no
message about tests unexpectedly passing which I had, er, expected to
see.

This "unexpectedly succeeded" message comes from Test​::Harness, so you
need to use t/harness to see it.

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case where
they have failed?...

C​:\p5p\bleadperl\t>..\perl harness -v ..\ext\threads\shared\t\stress.t
../ext/threads/shared/t/stress....1..50
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14
ok 15
ok 16
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22
ok 23
ok 24
ok 25
ok 26
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32
ok 33
ok 34
ok 35
ok 36
ok 37
ok 38
ok 39
ok 40
ok 41
ok 42
ok 43
ok 44
ok 45
ok 46
ok 47
ok 48
ok 49
ok 50
ok 5906 ms
All tests successful.
Files=1, Tests=50, 6 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)

(Just checking if you were aware of
that) That why the following seems unlikely​:

I guess this is because of the way that stress.t has rolled its own test
result outputting rather than using Test​::More's TODO​: {} blocks.

I don't see what's unlikely about that.

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @rgs

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

but on the occasions that things happen to succeed I get the same as
before--a series of "ok"s followed by "All tests successful". There's no
message about tests unexpectedly passing which I had, er, expected to see.

This "unexpectedly succeeded" message comes from Test​::Harness, so you
need to use t/harness to see it. (Just checking if you were aware of
that) That why the following seems unlikely​:

I guess this is because of the way that stress.t has rolled its own test
result outputting rather than using Test​::More's TODO​: {} blocks.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @rgs

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case where
they have failed?...

Ah, yes, I now see what you mean, sorry. Yes, the output for passing
todo tests should indeed be "ok number # TODO"...

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

Rafael Garcia-Suarez wrote​:

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case where
they have failed?...

Ah, yes, I now see what you mean, sorry. Yes, the output for passing
todo tests should indeed be "ok number # TODO"...

So is the attached OK with you, Jerry?

This gives me output like this when all is well​:

ok 1 # TODO - Unreliable on MSWin32
ok 2 # TODO - Unreliable on MSWin32
ok 3 # TODO - Unreliable on MSWin32
ok 4 # TODO - Unreliable on MSWin32
ok 5 # TODO - Unreliable on MSWin32
...
ok 5734 ms
  50/50 unexpectedly succeeded
TODO PASSED tests 1-50
All tests successful (50 subtests UNEXPECTEDLY SUCCEEDED).

or like this when things go wrong​:

...
ok 12 # TODO - Unreliable on MSWin32
ok 13 # TODO - Unreliable on MSWin32
not ok 14 # TODO - Unreliable on MSWin32
# Failed test at line 103
# Reason​: timed out - cond_broadcast not received
not ok 15 # TODO - Unreliable on MSWin32
# Failed test at line 103
# Reason​: timed out
not ok 16 # TODO - Unreliable on MSWin32
# Failed test at line 103
# Reason​: timed out
not ok 17 # TODO - Unreliable on MSWin32
# Failed test at line 103
# Reason​: timed out
ok 34812 ms
  13/50 unexpectedly succeeded
TODO PASSED tests 1-13
All tests successful (13 subtests UNEXPECTEDLY SUCCEEDED).

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

shared.patch
==== //depot/perl/ext/threads/shared/Changes#6 - c:\p5p\bleadperl\ext\threads\shared\Changes ====
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO under MSWin32
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
==== //depot/perl/ext/threads/shared/shared.pm#48 - c:\p5p\bleadperl\ext\threads\shared\shared.pm ====
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
==== //depot/perl/ext/threads/shared/t/stress.t#2 - c:\p5p\bleadperl\ext\threads\shared\t\stress.t ====
@@ -17,8 +17,9 @@
 
 my $Base = 0;
 sub ok {
-    my ($id, $ok, $why) = @_;
+    my ($id, $ok, $why, $todo) = @_;
     $id += $Base;
+    $id .= ' # TODO - Unreliable on MSWin32' if $todo;
 
     # You have to do it this way or VMS will get confused.
     if ($ok) {
@@ -47,10 +48,6 @@
 # Launches a bunch of threads which are then
 # restricted to finishing in numerical order
 #
-# Frequently fails under MSWin32 due to deadlocking bug in Windows
-#   http://rt.perl.org/rt3/Public/Bug/Display.html?id=41574
-#   http://support.microsoft.com/kb/175332
-#
 #####
 {
     my $cnt = 50;
@@ -96,7 +93,11 @@
     # Gather thread results
     for (1..$cnt) {
         my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        # Frequently fails under MSWin32 due to deadlocking bug in Windows
+        # hence test is TODO under MSWin32
+        #   http://rt.perl.org/rt3/Public/Bug/Display.html?id=41574
+        #   http://support.microsoft.com/kb/175332
+        ok($_, ($rc eq 'okay'), $rc, ($^O eq 'MSWin32'));
     }
 
     $Base += $cnt;

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

So is the attached OK with you, Jerry?
Looks fine to me.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @demerphq

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Rafael Garcia-Suarez wrote​:

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case where
they have failed?...

Ah, yes, I now see what you mean, sorry. Yes, the output for passing
todo tests should indeed be "ok number # TODO"...

So is the attached OK with you, Jerry?

This gives me output like this when all is well​:

ok 1 # TODO - Unreliable on MSWin32
ok 2 # TODO - Unreliable on MSWin32
ok 3 # TODO - Unreliable on MSWin32
ok 4 # TODO - Unreliable on MSWin32
ok 5 # TODO - Unreliable on MSWin32
...
ok 5734 ms
50/50 unexpectedly succeeded
TODO PASSED tests 1-50
All tests successful (50 subtests UNEXPECTEDLY SUCCEEDED).
[...]
or like this when things go wrong​:
[...]
All tests successful (13 subtests UNEXPECTEDLY SUCCEEDED).

IMO that will just mask /other/ unexpectedly passing tests behind line
noise. Is it possible to redo things so it return only a pass/fail?

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @steve-m-hay

demerphq wrote​:

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Rafael Garcia-Suarez wrote​:

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case where
they have failed?...

Ah, yes, I now see what you mean, sorry. Yes, the output for passing
todo tests should indeed be "ok number # TODO"...

So is the attached OK with you, Jerry?

This gives me output like this when all is well​:

ok 1 # TODO - Unreliable on MSWin32
ok 2 # TODO - Unreliable on MSWin32
ok 3 # TODO - Unreliable on MSWin32
ok 4 # TODO - Unreliable on MSWin32
ok 5 # TODO - Unreliable on MSWin32
...
ok 5734 ms
50/50 unexpectedly succeeded
TODO PASSED tests 1-50
All tests successful (50 subtests UNEXPECTEDLY SUCCEEDED).
[...]
or like this when things go wrong​:
[...]
All tests successful (13 subtests UNEXPECTEDLY SUCCEEDED).

IMO that will just mask /other/ unexpectedly passing tests behind line
noise. Is it possible to redo things so it return only a pass/fail?

I'm not sure I understand your question.

The output is now just standard Test-Harness output and behaves like any
other TODO tests do. How can that be wrong?

What output are you suggesting you'd like to see?

--

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @demerphq

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

demerphq wrote​:

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Rafael Garcia-Suarez wrote​:

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case where
they have failed?...

Ah, yes, I now see what you mean, sorry. Yes, the output for passing
todo tests should indeed be "ok number # TODO"...

So is the attached OK with you, Jerry?

This gives me output like this when all is well​:

ok 1 # TODO - Unreliable on MSWin32
ok 2 # TODO - Unreliable on MSWin32
ok 3 # TODO - Unreliable on MSWin32
ok 4 # TODO - Unreliable on MSWin32
ok 5 # TODO - Unreliable on MSWin32
...
ok 5734 ms
50/50 unexpectedly succeeded
TODO PASSED tests 1-50
All tests successful (50 subtests UNEXPECTEDLY SUCCEEDED).
[...]
or like this when things go wrong​:
[...]
All tests successful (13 subtests UNEXPECTEDLY SUCCEEDED).

IMO that will just mask /other/ unexpectedly passing tests behind line
noise. Is it possible to redo things so it return only a pass/fail?

I'm not sure I understand your question.

The output is now just standard Test-Harness output and behaves like any
other TODO tests do. How can that be wrong?

What output are you suggesting you'd like to see?

Currently we have 50 events (for a lack of a better term) that must
occur, and each one is given its own test. But really all we care
about is whether any of the 50 failed. So what i think is that the
following part of stress.t should be changed.

  # Gather thread results
  for (1..$cnt) {
  my $rc = $threads[$_]->join() || 'Thread failed';
  ok($_, ($rc eq 'okay'), $rc);
  }

Instead it should say something like

  # Gather thread results
  my @​failed;
  for (1..$cnt) {
  my $rc = $threads[$_]->join() || 'Thread failed';
  push @​failed,$_ if $rc ne 'okay';
  }
  ok(1,!@​failed,"No threads failed");
  print "# Failed threads​: @​failed\n" if @​failed;

That way we dont see 13 unexpected passes one day, and 15 the next,
and 20 the next. It either passes or fails as a whole. Which will mean
that the unexpected success number will be mostly useful, as compared
to being pretty much a random number.

I realize that this means we are doing part of harness'ess job, but
still, in this case i think its called for.

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

Yves wrote​:

Instead it should say something like

\# Gather thread results
my @&#8203;failed;
for \(1\.\.$cnt\) \{
    my $rc = $threads\[$\_\]\->join\(\) || 'Thread failed';
    push @&#8203;failed\,$\_ if $rc ne 'okay';
\}
ok\(1\,\!@&#8203;failed\,"No threads failed"\);
print "\# Failed threads&#8203;: @&#8203;failed\\n" if @&#8203;failed;

Let me work on this. You have a point, but it also needs to handle
cases other than timeouts (the 'Thread failed' message).

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

With the attached patch, there is only 1 test.

If something 'funky' happens (e.g., a thread fails to run), then the test fails.

Under MSWin32...
  If there are timeouts, the result is​:
not ok 1 # TODO - not reliable under MSWin32 - ? threads timed out

  If there are no timeouts, the result is​:
ok 1 # TODO - not reliable under MSWin32

If not under MSWin32, if there are timeouts, the test fails. Otherwise, okay.

That may be overkill, but I hope it covers all the bases.

@p5pRT
Copy link
Author

p5pRT commented Apr 18, 2007

From @jdhedden

shared.patch
diff -ruN perl-current/ext/threads/shared/Changes perl-patch/ext/threads/shared/Changes
--- perl-current/ext/threads/shared/Changes	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/Changes	2007-04-18 14:23:14.000000000 -0400
@@ -1,5 +1,8 @@
 Revision history for Perl extension threads::shared.
 
+-
+	- Modify stress test to be TODO under MSWin32
+
 1.09 Mon Apr  9 16:49:30 EDT 2007
 	- Modify stress test to not hang under MSWin32
 	- Fix casting issue under MSWin32
diff -ruN perl-current/ext/threads/shared/shared.pm perl-patch/ext/threads/shared/shared.pm
--- perl-current/ext/threads/shared/shared.pm	2007-04-10 05:43:12.000000000 -0400
+++ perl-patch/ext/threads/shared/shared.pm	2007-04-18 14:23:14.000000000 -0400
@@ -5,7 +5,7 @@
 use strict;
 use warnings;
 
-our $VERSION = '1.09';
+our $VERSION = '1.09_01';
 my $XS_VERSION = $VERSION;
 $VERSION = eval $VERSION;
 
@@ -85,7 +85,7 @@
   $var = $shared_ref_value;
   $var = share($simple_unshared_ref_value);
 
-  my($scalar, @array, %hash);
+  my ($scalar, @array, %hash);
   share($scalar);
   share(@array);
   share(%hash);
diff -ruN perl-current/ext/threads/shared/t/stress.t perl-patch/ext/threads/shared/t/stress.t
--- perl-current/ext/threads/shared/t/stress.t	2007-04-10 05:49:32.000000000 -0400
+++ perl-patch/ext/threads/shared/t/stress.t	2007-04-18 14:23:14.000000000 -0400
@@ -15,26 +15,9 @@
 
 use ExtUtils::testlib;
 
-my $Base = 0;
-sub ok {
-    my ($id, $ok, $why) = @_;
-    $id += $Base;
-
-    # You have to do it this way or VMS will get confused.
-    if ($ok) {
-        print("ok $id\n");
-    } else {
-        print ("not ok $id\n");
-        printf("# Failed test at line %d\n", (caller)[2]);
-        print ("#   Reason: $why\n");
-    }
-
-    return ($ok);
-}
-
 BEGIN {
     $| = 1;
-    print("1..50\n");   ### Number of tests that will be run ###
+    print("1..1\n");   ### Number of tests that will be run ###
 };
 
 use threads;
@@ -47,10 +30,6 @@
 # Launches a bunch of threads which are then
 # restricted to finishing in numerical order
 #
-# Frequently fails under MSWin32 due to deadlocking bug in Windows
-#   http://rt.perl.org/rt3/Public/Bug/Display.html?id=41574
-#   http://support.microsoft.com/kb/175332
-#
 #####
 {
     my $cnt = 50;
@@ -94,12 +73,44 @@
     }
 
     # Gather thread results
+    my ($okay, $failures, $timeouts, $unknown) = (0, 0, 0, 0);
     for (1..$cnt) {
-        my $rc = $threads[$_]->join() || 'Thread failed';
-        ok($_, ($rc eq 'okay'), $rc);
+        my $rc = $threads[$_]->join();
+        if (! $rc) {
+            $failures++;
+        } elsif ($rc =~ /^timed out/) {
+            $timeouts++;
+        } elsif ($rc eq 'okay') {
+            $okay++;
+        } else {
+            $unknown++;
+            print("# Unknown error: $rc\n");
+        }
     }
 
-    $Base += $cnt;
+    if ($failures || $unknown || (($okay + $timeouts) != $cnt)) {
+        print('not ok 1');
+        my $too_few = $cnt - ($okay + $failures + $timeouts + $unknown);
+        print(" - $too_few too few threads reported") if $too_few;
+        print(" - $failures threads failed")          if $failures;
+        print(" - $unknown unknown errors")           if $unknown;
+        print(" - $timeouts threads timed out")       if $timeouts;
+        print("\n");
+
+    } elsif ($timeouts) {
+        # Frequently fails under MSWin32 due to deadlocking bug in Windows
+        # hence test is TODO under MSWin32
+        #   http://rt.perl.org/rt3/Public/Bug/Display.html?id=41574
+        #   http://support.microsoft.com/kb/175332
+        print('not ok 1');
+        print(' # TODO - not reliable under MSWin32') if ($^O eq 'MSWin32');
+        print(" - $timeouts threads timed out\n");
+
+    } else {
+        print('ok 1');
+        print(' # TODO - not reliable under MSWin32') if ($^O eq 'MSWin32');
+        print("\n");
+    }
 }
 
 # EOF

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2007

From @steve-m-hay

demerphq wrote​:

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

demerphq wrote​:

On 4/18/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

Rafael Garcia-Suarez wrote​:

On 18/04/07, Steve Hay <steve.hay@​uk.radan.com> wrote​:

I'm using t/harness, but how can that possibly know to output the
"unexpected success" message when nothing in Jerry's patch has done
anything to suggest that the tests are "todo" except in the case
where
they have failed?...

Ah, yes, I now see what you mean, sorry. Yes, the output for passing
todo tests should indeed be "ok number # TODO"...

So is the attached OK with you, Jerry?

This gives me output like this when all is well​:

ok 1 # TODO - Unreliable on MSWin32
ok 2 # TODO - Unreliable on MSWin32
ok 3 # TODO - Unreliable on MSWin32
ok 4 # TODO - Unreliable on MSWin32
ok 5 # TODO - Unreliable on MSWin32
...
ok 5734 ms
50/50 unexpectedly succeeded
TODO PASSED tests 1-50
All tests successful (50 subtests UNEXPECTEDLY SUCCEEDED).
[...]
or like this when things go wrong​:
[...]
All tests successful (13 subtests UNEXPECTEDLY SUCCEEDED).

IMO that will just mask /other/ unexpectedly passing tests behind line
noise. Is it possible to redo things so it return only a pass/fail?

I'm not sure I understand your question.

The output is now just standard Test-Harness output and behaves like any
other TODO tests do. How can that be wrong?

What output are you suggesting you'd like to see?

Currently we have 50 events (for a lack of a better term) that must
occur, and each one is given its own test. But really all we care
about is whether any of the 50 failed.

Ah yes, good point! I understand now.

--

@p5pRT
Copy link
Author

p5pRT commented Apr 19, 2007

From @steve-m-hay

Jerry D. Hedden wrote​:

With the attached patch, there is only 1 test.

Thanks, applied as #30978.

--

@p5pRT
Copy link
Author

p5pRT commented Nov 14, 2008

@smpeters - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant