* Some tests fail in VC++2005 @ 2005-04-21 14:05 Uenal Mutlu 2005-04-22 5:46 ` Ross Johnson 0 siblings, 1 reply; 6+ messages in thread From: Uenal Mutlu @ 2005-04-21 14:05 UTC (permalink / raw) To: pthreads-win32 I've tried the latest 2 pthreads releases with MS compilers. VC++6 passes all tests, but VC++2005 fails with about 26 of the test programs (tested only in beta 1, beta 2 is out since last monday or so but I don't have it yet). The first one of the failing test programs is semaphore1.c, line 89: nmake clean VC ... ... Running VC test: mutex1r.exe ...... Passed cl /D__CLEANUP_C /O2 /Ob0 /W3 /WX /MD /nologo /Yd /Zi -I. semaphore1.c /Fesemaphore1.exe /link /INCREMENTAL:NO pthreadVC2.lib ws2_32.lib cl : Command line warning D9035 : option 'Yd' has been deprecated and will be removed in a future release semaphore1.c ... Running VC test: semaphore1.exe thread: sem_trywait 1: expected error: No error Assertion failed: (errno == EAGAIN), file semaphore1.c, line 89 NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1' Stop. NMAKE : fatal error U1077: 'nmake' : return code '0x2' Stop. Below is the function from semaphore1.c where the error occurs. It is the line assert(errno == EAGAIN); I wonder where errno gets set to this value. Is it done in sem_trywait() or maybe in perror()? And frankly I don't understand how the below code works at all because that branch is entered only if result is -1. The funny thing here (for me) is that then the program should stop in the previous assert(), but this isn't happening! Then I wonder how and why the if condition becomes true... 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 ) { perror("thread: sem_trywait 1: expected error"); // No error assert(errno == EAGAIN); } ... I have posted this issue also in news://news.microsoft.com/microsoft.public.dotnet.languages.vc under the subject "VC++ 2005 beta1 fails with pthreads benchmark tests" but the MS guys say the code is broken. Maybe someone could clarify this. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some tests fail in VC++2005 2005-04-21 14:05 Some tests fail in VC++2005 Uenal Mutlu @ 2005-04-22 5:46 ` Ross Johnson 2005-04-22 7:34 ` Steve Croall 0 siblings, 1 reply; 6+ messages in thread From: Ross Johnson @ 2005-04-22 5:46 UTC (permalink / raw) To: Pthreads-Win32 list On Thu, 2005-04-21 at 16:07 +0200, Uenal Mutlu wrote: > I've tried the latest 2 pthreads releases with MS compilers. > VC++6 passes all tests, but VC++2005 fails with about 26 of the > test programs (tested only in beta 1, beta 2 is out since last monday > or so but I don't have it yet). > The first one of the failing test programs is semaphore1.c, line 89: > > nmake clean VC > ... > ... Running VC test: mutex1r.exe > ...... Passed > cl /D__CLEANUP_C /O2 /Ob0 /W3 /WX /MD /nologo /Yd /Zi -I. semaphore1.c /Fesemaphore1.exe /link /INCREMENTAL:NO pthreadVC2.lib > ws2_32.lib > cl : Command line warning D9035 : option 'Yd' has been deprecated and will be removed in a future release > semaphore1.c > ... Running VC test: semaphore1.exe > thread: sem_trywait 1: expected error: No error > Assertion failed: (errno == EAGAIN), file semaphore1.c, line 89 > NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1' > Stop. > NMAKE : fatal error U1077: 'nmake' : return code '0x2' > Stop. > Strange. It was previously reported that all tests passed with VC++ 2005 beta: http://sources.redhat.com/ml/pthreads-win32/2005/msg00035.html Also reported as passing using VC++ 8.0 and VS .NET 2003. > Below is the function from semaphore1.c where the error occurs. > It is the line > assert(errno == EAGAIN); > I wonder where errno gets set to this value. > Is it done in sem_trywait() or maybe in perror()? > And frankly I don't understand how the below code works at all > because that branch is entered only if result is -1. The funny > thing here (for me) is that then the program should stop in the > previous assert(), but this isn't happening! Then I wonder how > and why the if condition becomes true... > [See my comments later re perror.] The test is expecting EAGAIN to be set by sem_trywait(). Since the semaphore was initialised to 0, sem_trywait should return EAGAIN to indicate that it would have had to wait. But the output is saying that after sem_trywait returns -1, errno is 0 ('no error'). So it seems as if errno may not be correctly defined in pthread.h and is conflicting with how it's supposed to work with VC+ +2005 - and is not thread-safe as a result. Usually errno is defined as: #define errno *errno() where errno() is a function that returns a pointer to a thread-specific errno location. I don't have access to VC++2005 so won't be able to fix this and test that it works afterwards. If you (or anyone else can) it would sure help. I have a similar problem with the Borland and Watcom compilers, and I just can't figure out what I need to do to fix it. > 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 ) > { > perror("thread: sem_trywait 1: expected error"); // No error > assert(errno == EAGAIN); > } > ... > > I have posted this issue also in > news://news.microsoft.com/microsoft.public.dotnet.languages.vc > under the subject "VC++ 2005 beta1 fails with pthreads benchmark tests" > but the MS guys say the code is broken. Maybe someone could clarify this. > Hmmm, my Googling just now hit on this discussion between UM (you?) and someone else. Is this the same discussion as the news link you gave: http://www.codecomments.com/forum292/message465116-2.html Apart from the unhelpful and highly defensive/diversionary comments from the other guy about assert abuse etc., I agree that errno should probably not be read again after the perror call. The standard doesn't say that perror should preserve errno - only that perror doesn't return a value and that no errors are defined for it. I'll change the tests. By the way, here's some code from the MSDN perror web page: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vclib/html/_crt_perror.2c_._wperror.asp Note that it expects errno to be preserved through the perror() call too. // crt_perror.c /* This program attempts to open a file named * NOSUCHF.ILE. Because this file probably doesn't exist, * an error message is displayed. The same message is * created using perror, strerror, and _strerror. */ #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> #include <io.h> #include <stdlib.h> #include <stdio.h> #include <string.h> int main( void ) { int fh; if( (fh = _open( "NOSUCHF.ILE", _O_RDONLY )) == -1 ) { /* Three ways to create error message: */ perror( "perror says open failed" ); printf( "strerror says open failed: %s\n", strerror( errno ) ); printf( _strerror( "_strerror says open failed" ) ); } else { printf( "open succeeded on input file\n" ); _close( fh ); } } Ross ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some tests fail in VC++2005 2005-04-22 5:46 ` Ross Johnson @ 2005-04-22 7:34 ` Steve Croall 2005-04-25 0:20 ` Ross Johnson 0 siblings, 1 reply; 6+ messages in thread From: Steve Croall @ 2005-04-22 7:34 UTC (permalink / raw) To: Pthreads-Win32 list If I have time I will download VC++2005 from MSDN and see what the problem is. If there is one :) After using Microsoft's COM+ event system it wouldn't surprise me if there are problems :) Steve. Ross Johnson wrote: > On Thu, 2005-04-21 at 16:07 +0200, Uenal Mutlu wrote: > >>I've tried the latest 2 pthreads releases with MS compilers. >>VC++6 passes all tests, but VC++2005 fails with about 26 of the >>test programs (tested only in beta 1, beta 2 is out since last monday >>or so but I don't have it yet). >>The first one of the failing test programs is semaphore1.c, line 89: >> >>nmake clean VC >>... >>... Running VC test: mutex1r.exe >>...... Passed >>cl /D__CLEANUP_C /O2 /Ob0 /W3 /WX /MD /nologo /Yd /Zi -I. semaphore1.c /Fesemaphore1.exe /link /INCREMENTAL:NO pthreadVC2.lib >>ws2_32.lib >>cl : Command line warning D9035 : option 'Yd' has been deprecated and will be removed in a future release >>semaphore1.c >>... Running VC test: semaphore1.exe >>thread: sem_trywait 1: expected error: No error >>Assertion failed: (errno == EAGAIN), file semaphore1.c, line 89 >>NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1' >>Stop. >>NMAKE : fatal error U1077: 'nmake' : return code '0x2' >>Stop. >> > > > Strange. It was previously reported that all tests passed with VC++ 2005 > beta: > http://sources.redhat.com/ml/pthreads-win32/2005/msg00035.html > > Also reported as passing using VC++ 8.0 and VS .NET 2003. > > >>Below is the function from semaphore1.c where the error occurs. >>It is the line >> assert(errno == EAGAIN); >>I wonder where errno gets set to this value. >>Is it done in sem_trywait() or maybe in perror()? >>And frankly I don't understand how the below code works at all >>because that branch is entered only if result is -1. The funny >>thing here (for me) is that then the program should stop in the >>previous assert(), but this isn't happening! Then I wonder how >>and why the if condition becomes true... >> > > > [See my comments later re perror.] > > The test is expecting EAGAIN to be set by sem_trywait(). Since the > semaphore was initialised to 0, sem_trywait should return EAGAIN to > indicate that it would have had to wait. > > But the output is saying that after sem_trywait returns -1, errno is 0 > ('no error'). So it seems as if errno may not be correctly defined in > pthread.h and is conflicting with how it's supposed to work with VC+ > +2005 - and is not thread-safe as a result. > > Usually errno is defined as: > > #define errno *errno() > > where errno() is a function that returns a pointer to a thread-specific > errno location. > > I don't have access to VC++2005 so won't be able to fix this and test > that it works afterwards. If you (or anyone else can) it would sure > help. I have a similar problem with the Borland and Watcom compilers, > and I just can't figure out what I need to do to fix it. > > >>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 ) >> { >> perror("thread: sem_trywait 1: expected error"); // No error >> assert(errno == EAGAIN); >> } >>... >> >>I have posted this issue also in >>news://news.microsoft.com/microsoft.public.dotnet.languages.vc >>under the subject "VC++ 2005 beta1 fails with pthreads benchmark tests" >>but the MS guys say the code is broken. Maybe someone could clarify this. >> > > > Hmmm, my Googling just now hit on this discussion between UM (you?) and > someone else. Is this the same discussion as the news link you gave: > http://www.codecomments.com/forum292/message465116-2.html > > Apart from the unhelpful and highly defensive/diversionary comments from > the other guy about assert abuse etc., I agree that errno should > probably not be read again after the perror call. The standard doesn't > say that perror should preserve errno - only that perror doesn't return > a value and that no errors are defined for it. I'll change the tests. > > By the way, here's some code from the MSDN perror web page: > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/vclib/html/_crt_perror.2c_._wperror.asp > > Note that it expects errno to be preserved through the perror() call > too. > > // crt_perror.c > /* This program attempts to open a file named > * NOSUCHF.ILE. Because this file probably doesn't exist, > * an error message is displayed. The same message is > * created using perror, strerror, and _strerror. > */ > > #include <fcntl.h> > #include <sys/types.h> > #include <sys/stat.h> > #include <io.h> > #include <stdlib.h> > #include <stdio.h> > #include <string.h> > > int main( void ) > { > int fh; > > if( (fh = _open( "NOSUCHF.ILE", _O_RDONLY )) == -1 ) > { > /* Three ways to create error message: */ > perror( "perror says open failed" ); > printf( "strerror says open failed: %s\n", strerror( errno ) ); > printf( _strerror( "_strerror says open failed" ) ); > } > else > { > printf( "open succeeded on input file\n" ); > _close( fh ); > } > } > > Ross > > > > -- J. Senior Software Engineer, Tibco Software Ltd. T. +44 (0) 1792 360773 M. +44 (0) 7788 971394 E. scroall@tibco.com W. www.tibco.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some tests fail in VC++2005 2005-04-22 7:34 ` Steve Croall @ 2005-04-25 0:20 ` Ross Johnson 2005-04-25 2:33 ` Will Bryant 0 siblings, 1 reply; 6+ messages in thread From: Ross Johnson @ 2005-04-25 0:20 UTC (permalink / raw) To: Pthreads-Win32 list Hi, Anything you can find out (confirmation it works/doesn't work, or a fix if necessary) would be very much appreciated. After I sent my response below I realised my recollection was wrong. The symptoms are identical to what I found with the Borland build, but the problem isn't that errno is apparently not thread-safe, but kind of not dll-safe, if that makes sense. That is, for some reason, the location that the routines in the dll are using for errno is different to what the [test] app is using. In the Borland case I confirmed this by printing the location pointers, and is obviously fixable, but I couldn't find any information on what might cause the errno() routine to return different locations for the same thread depending on whether the call was inside or outside of the dll. Regards. Ross On Fri, 2005-04-22 at 08:34 +0100, Steve Croall wrote: > If I have time I will download VC++2005 from MSDN and see what the > problem is. If there is one :) > > After using Microsoft's COM+ event system it wouldn't surprise me if > there are problems :) > > Steve. > > Ross Johnson wrote: > > On Thu, 2005-04-21 at 16:07 +0200, Uenal Mutlu wrote: > > > >>I've tried the latest 2 pthreads releases with MS compilers. > >>VC++6 passes all tests, but VC++2005 fails with about 26 of the > >>test programs (tested only in beta 1, beta 2 is out since last monday > >>or so but I don't have it yet). > >>The first one of the failing test programs is semaphore1.c, line 89: > >> > >>nmake clean VC > >>... > >>... Running VC test: mutex1r.exe > >>...... Passed > >>cl /D__CLEANUP_C /O2 /Ob0 /W3 /WX /MD /nologo /Yd /Zi -I. semaphore1.c /Fesemaphore1.exe /link /INCREMENTAL:NO pthreadVC2.lib > >>ws2_32.lib > >>cl : Command line warning D9035 : option 'Yd' has been deprecated and will be removed in a future release > >>semaphore1.c > >>... Running VC test: semaphore1.exe > >>thread: sem_trywait 1: expected error: No error > >>Assertion failed: (errno == EAGAIN), file semaphore1.c, line 89 > >>NMAKE : fatal error U1077: '.\semaphore1.exe' : return code '0x1' > >>Stop. > >>NMAKE : fatal error U1077: 'nmake' : return code '0x2' > >>Stop. > >> > > > > > > Strange. It was previously reported that all tests passed with VC++ 2005 > > beta: > > http://sources.redhat.com/ml/pthreads-win32/2005/msg00035.html > > > > Also reported as passing using VC++ 8.0 and VS .NET 2003. > > > > > >>Below is the function from semaphore1.c where the error occurs. > >>It is the line > >> assert(errno == EAGAIN); > >>I wonder where errno gets set to this value. > >>Is it done in sem_trywait() or maybe in perror()? > >>And frankly I don't understand how the below code works at all > >>because that branch is entered only if result is -1. The funny > >>thing here (for me) is that then the program should stop in the > >>previous assert(), but this isn't happening! Then I wonder how > >>and why the if condition becomes true... > >> > > > > > > [See my comments later re perror.] > > > > The test is expecting EAGAIN to be set by sem_trywait(). Since the > > semaphore was initialised to 0, sem_trywait should return EAGAIN to > > indicate that it would have had to wait. > > > > But the output is saying that after sem_trywait returns -1, errno is 0 > > ('no error'). So it seems as if errno may not be correctly defined in > > pthread.h and is conflicting with how it's supposed to work with VC+ > > +2005 - and is not thread-safe as a result. > > > > Usually errno is defined as: > > > > #define errno *errno() > > > > where errno() is a function that returns a pointer to a thread-specific > > errno location. > > > > I don't have access to VC++2005 so won't be able to fix this and test > > that it works afterwards. If you (or anyone else can) it would sure > > help. I have a similar problem with the Borland and Watcom compilers, > > and I just can't figure out what I need to do to fix it. > > > > > >>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 ) > >> { > >> perror("thread: sem_trywait 1: expected error"); // No error > >> assert(errno == EAGAIN); > >> } > >>... > >> > >>I have posted this issue also in > >>news://news.microsoft.com/microsoft.public.dotnet.languages.vc > >>under the subject "VC++ 2005 beta1 fails with pthreads benchmark tests" > >>but the MS guys say the code is broken. Maybe someone could clarify this. > >> > > > > > > Hmmm, my Googling just now hit on this discussion between UM (you?) and > > someone else. Is this the same discussion as the news link you gave: > > http://www.codecomments.com/forum292/message465116-2.html > > > > Apart from the unhelpful and highly defensive/diversionary comments from > > the other guy about assert abuse etc., I agree that errno should > > probably not be read again after the perror call. The standard doesn't > > say that perror should preserve errno - only that perror doesn't return > > a value and that no errors are defined for it. I'll change the tests. > > > > By the way, here's some code from the MSDN perror web page: > > http://msdn.microsoft.com/library/default.asp?url=/library/en- > > us/vclib/html/_crt_perror.2c_._wperror.asp > > > > Note that it expects errno to be preserved through the perror() call > > too. > > > > // crt_perror.c > > /* This program attempts to open a file named > > * NOSUCHF.ILE. Because this file probably doesn't exist, > > * an error message is displayed. The same message is > > * created using perror, strerror, and _strerror. > > */ > > > > #include <fcntl.h> > > #include <sys/types.h> > > #include <sys/stat.h> > > #include <io.h> > > #include <stdlib.h> > > #include <stdio.h> > > #include <string.h> > > > > int main( void ) > > { > > int fh; > > > > if( (fh = _open( "NOSUCHF.ILE", _O_RDONLY )) == -1 ) > > { > > /* Three ways to create error message: */ > > perror( "perror says open failed" ); > > printf( "strerror says open failed: %s\n", strerror( errno ) ); > > printf( _strerror( "_strerror says open failed" ) ); > > } > > else > > { > > printf( "open succeeded on input file\n" ); > > _close( fh ); > > } > > } > > > > Ross > > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some tests fail in VC++2005 2005-04-25 0:20 ` Ross Johnson @ 2005-04-25 2:33 ` Will Bryant 2005-04-26 2:34 ` Ross Johnson 0 siblings, 1 reply; 6+ messages in thread From: Will Bryant @ 2005-04-25 2:33 UTC (permalink / raw) To: pthreads-win32 Ross Johnson wrote: >[snip] In the Borland case I confirmed this by >printing the location pointers, and is obviously fixable, but I couldn't >find any information on what might cause the errno() routine to return >different locations for the same thread depending on whether the call >was inside or outside of the dll. > > Were you compiling both with the same RTL option(s)? I vaguely remember finding some issue like that from my Borland days. -- Will Bryant Systems Architect, eCOSM Limited Mobile +64 21 655 443 http://www.ecosm.com/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Some tests fail in VC++2005 2005-04-25 2:33 ` Will Bryant @ 2005-04-26 2:34 ` Ross Johnson 0 siblings, 0 replies; 6+ messages in thread From: Ross Johnson @ 2005-04-26 2:34 UTC (permalink / raw) To: Will Bryant; +Cc: Pthreads-Win32 list On Mon, 2005-04-25 at 14:31 +1200, Will Bryant wrote: > Ross Johnson wrote: > > >[snip] In the Borland case I confirmed this by > >printing the location pointers, and is obviously fixable, but I couldn't > >find any information on what might cause the errno() routine to return > >different locations for the same thread depending on whether the call > >was inside or outside of the dll. > > > > > Were you compiling both with the same RTL option(s)? No. Oops. I was using cw32mt.lib (static lib) for the dll, and nothing specified for the test apps. I'm now using cw32mti.lib (import lib for cw32mt.dll) for both dll and test apps. Now errno is ok, but I'm getting memory read exceptions on some tests, but that will have to wait for another time. Thanks. Ross ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-04-26 2:34 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-04-21 14:05 Some tests fail in VC++2005 Uenal Mutlu 2005-04-22 5:46 ` Ross Johnson 2005-04-22 7:34 ` Steve Croall 2005-04-25 0:20 ` Ross Johnson 2005-04-25 2:33 ` Will Bryant 2005-04-26 2:34 ` Ross Johnson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).