VC++ 2005 beta1 fails with pthreads benchmark tests

"Doug Harrison [MVP]" wrote
> On Tue, 19 Apr 2005 15:34:05 +0200, um wrote:
> 
>
> David was correct in his reply to you. Absent documentation to the
> contrary, standard library functions are free to set errno to non-zero
> values. Thus, your assert is based on the faulty expectation that perror
> preserves errno (which you assume equals EAGAIN) or sets it to EAGAIN
> itself.

Please see my followup to his posting. Even after changing it
the error still remains.
And: how do you explain the fact that compilers other than VC++2005
don't generate any error, incl. MS VC++6 and GNU ?
FYI: there are 122 test programs in total. All tests are passed with
the other compilers (incl. VC++6), except that VC++2005 fails with 26 of the
m.
Any thoughts on what might be the reason for such behaviour
between VC++6 and VC++2005 ?

>In addition, you originally posted:
>
> void *
> thr(void * arg)
> {
>   sem_t s;
>   int result;
>
>   assert(sem_init(&s, PTHREAD_PROCESS_PRIVATE, 0) == 0);
>
>   assert((result = sem_trywait(&s)) == -1);
>
>   if ( result == -1 )
>
> <snip>
>
> That's just wrong, because nothing initializes s and result when NDEBUG is
> defined, i.e. in a release build. You must never put code that is part of
> your program's logic in asserts. You need to rethink your error handling
> strategy.

Right, but: these are a set of standard test programs to be run only
in debug mode. They are compiled AND executed collectively via a make file.
They are not intended to be used otherwise. They test whether
the library does function as expected on the given platform.
They are part of the pthreads distribution, not mine.

um wrote:
> When the POSIX pthreads library for w32 release 2-2-0
> (http://sources.redhat.com/pthreads-win32/) is compiled with VC++6
> then it compiles and passes all the benchmark tests in the
> subdirectory "tests". Also, VC++ 2005 beta 1 compiles the tests fine,
> but here the following
> tests fail in execution:
>
> #   semaphore1.pass \
> #   condvar2.pass \
> #   condvar2_1.pass  \
> #   mutex8.pass \
> #   mutex8n.pass \
> #   mutex8e.pass \
> #   mutex8r.pass  \
> #   condvar3.pass  \
> #   condvar3_1.pass  \
> #   condvar3_2.pass \
> #   condvar3_3.pass  \
> #   condvar4.pass  \
> #   condvar5.pass  \
> #   condvar6.pass  \
> #   condvar7.pass  \
> #   condvar8.pass  \
> #   condvar9.pass  \
> #   rwlock7.pass  \
> #   rwlock8.pass  \
> #   rwlock2_t.pass  \
> #   rwlock3_t.pass \
> #   rwlock4_t.pass  \
> #   rwlock5_t.pass  \
> #   rwlock6_t.pass  \
> #   rwlock6_t2.pass  \
> #   spin4.pass  \
>
> Why are there such differences in execution of the generated code
> between VC++6 and VC++2005 ? Is this due to bugs in the beta1,
> or is this the result of general differences between the two products?
> Are there any compiler/linker switches for backwards "compatibility"
> to VC++6?

Can you post a link to the PThreads distribution you're using?

Despite all the heat, you've posted nothing to indicate that these failures
are due to VC 2005 problems - it's as likely that the tests in fact rely on
undefined behavior and failing is equally correct as an outcome as success
would be.

That said, provide a link to exactly what you're testing so that others can
try to replicate your results and actually do the work of figuring out _why_
the results are different rather than merely stating that they are.

-cd

On Wed, 20 Apr 2005 06:18:20 +0200, um wrote:

> Please see my followup to his posting. Even after changing it
> the error still remains.
> And: how do you explain the fact that compilers other than VC++2005
> don't generate any error, incl. MS VC++6 and GNU ?
> FYI: there are 122 test programs in total. All tests are passed with
> the other compilers (incl. VC++6), except that VC++2005 fails with 26 of t
hem.
> Any thoughts on what might be the reason for such behaviour
> between VC++6 and VC++2005 ?

I dunno; I'd want to look into sem_trywait, because apparently it's
expected to set errno to EAGAIN in this program. The perror output tells
you that errno is actually zero following this call:

thread: sem_trywait 1: expected error: No error

The "No error" bit is errno translated to text, which perror tacks on to
the end of the string passed to it. In addition to checking sem_trywait,
I'd want to look at assert; AFAIK, it needn't preserve errno (but that's
admittedly grasping at straws).

> Right, but: these are a set of standard test programs to be run only
> in debug mode. They are compiled AND executed collectively via a make file
.
> They are not intended to be used otherwise. They test whether
> the library does function as expected on the given platform.
> They are part of the pthreads distribution, not mine.

Gotcha. Anybody who knows C has got to hate that sort of "assert" abuse,
though. And the code's expectations for perror are simply wrong. If you
feel like it, you might want to send a correction to the actual author.

--
Doug Harrison
Microsoft MVP - Visual C++

"Carl Daniel [VC++ MVP]" wrote
> um wrote: 
.... 
>
> Can you post a link to the PThreads distribution you're using?

Sure,
[url]ftp://sources.redhat.com/pub/pthreads-win32/pthreads-w32-2-2-0-release.tar.gz[/url
]


> Despite all the heat, you've posted nothing to indicate that these failure
s
> are due to VC 2005 problems - it's as likely that the tests in fact rely o
n
> undefined behavior and failing is equally correct as an outcome as success
> would be.
>
> That said, provide a link to exactly what you're testing so that others ca
n
> try to replicate your results and actually do the work of figuring out _wh
y_
> the results are different rather than merely stating that they are.

Yes, that would be nice to find out what the reason is.

um wrote:
> "Carl Daniel [VC++ MVP]" wrote 
>
> Sure,
> ftp://sources.redhat.com/pub/pthrea...-release.tar.gz[/col
or]

I see that there's a 2.3.0 release that's a few days newer than the 2.2.0.
Have you tried that release as well?  (I'd hate to spend time investigating
something in 2.2.0 only to find it was fixed a w later in 2.3.0...)

-cd

"um" <dont_email@nospam.org> wrote in message
news:OZWW29VRFHA.2132@TK2MSFTNGP14.phx.gbl...

> And: how do you explain the fact that compilers other than VC++2005
> don't generate any error, incl. MS VC++6 and GNU ?

You seriously need an explanation of why code that invokes undefined
behavior might work differently on different compilers?

DS

"Carl Daniel [VC++ MVP]" wrote
> um wrote: 
>
> I see that there's a 2.3.0 release that's a few days newer than the 2.2.0.
> Have you tried that release as well?  (I'd hate to spend time investigatin
g
> something in 2.2.0 only to find it was fixed a w later in 2.3.0...)

I've just tested the latest version too. Same results. That is: VC++2005 fai
ls
passing some of the tests, all other compilers tested (VC++6 and GNU) do
pass them all.

"David Schwartz" wrote
>
> "um" wrote
> 
>
>     You seriously need an explanation of why code that invokes undefined
> behavior might work differently on different compilers?

Sorry, if you had read the postings a little bit carefully you would have
seen that even after changing the source code the error remains.
The result we gained from these tests and the discussion so far is:

1) perror() in VC++2005 seems to change the errno variable.
2) Maybe b/c of point 1 VC++2005 behaves differently than VC++6.
3) Independent of point 1 the error remains in VC++2005.
4) Also the latest release (2-3-0) of the pthreads library fails in VC++2005
.
5) The other compilers tested (VC++6 and GNU) do pass the tests, only VC++20
05 fails.

As I wrote, these test programs are part of the pthreads distribution, ie. n
ot my
code. They are intended for debug build only, therefore it does not harm to 
have the
code embedded in asserts. True, in release build it is harmful and then one 
definitely
has to avoid it since then the code would not be executed of course.

But, for sake of brevity I'll change the asserts so that these cover only th
e
result, not any code. I'll start with the first of the failing test programs
(semaphore1.c). I'll also take the latest release (2-3-0) of pthreads.

On Thu, 21 Apr 2005 12:09:56 +0200, um wrote:

> seen that even after changing the source code the error remains.
> The result we gained from these tests and the discussion so far is:
>
> 1) perror() in VC++2005 seems to change the errno variable.

No, that was just a possibility. It may or may not be true, but in any
case, it isn't your problem. As I noted earlier:

*****
I dunno; I'd want to look into sem_trywait, because apparently it's
expected to set errno to EAGAIN in this program. The perror output tells
you that errno is actually zero following this call:

thread: sem_trywait 1: expected error: No error

The "No error" bit is errno translated to text, which perror tacks on to
the end of the string passed to it. In addition to checking sem_trywait,
I'd want to look at assert; AFAIK, it needn't preserve errno (but that's
admittedly grasping at straws).
*****

So you see, perror is either totally broken or it's finding errno to be
zero, pointing to a problem elsewhere. My money's on the latter.

> 2) Maybe b/c of point 1 VC++2005 behaves differently than VC++6.
> 3) Independent of point 1 the error remains in VC++2005.
> 4) Also the latest release (2-3-0) of the pthreads library fails in VC++20
05.
> 5) The other compilers tested (VC++6 and GNU) do pass the tests, only VC++2005 fai
ls.

6) The pthreads test library excerpt posted here suffers from a bad
assumption concerning errno and some truly horrid assert abuse. Hopefully,
sem_trywait was written in a more correct fashion, but that's where you
need to look for the problem.

--
Doug Harrison
Microsoft MVP - Visual C++

um wrote:
> "Carl Daniel [VC++ MVP]" wrote 
>
> I've just tested the latest version too. Same results. That is:
> VC++2005 fails passing some of the tests, all other compilers tested
> (VC++6 and GNU) do
> pass them all.

OK thanks.  I just got my VC 2005 beta 2 installation up and running, so
I'll give the 2.3.0 build a try and see what I can discover.

-cd