[jira] Created: (STDCXX-467) [Intel Thread Checker 3.1] bogus data race after pthread_once()
[Intel Thread Checker 3.1] bogus data race after pthread_once()
---
Key: STDCXX-467
URL: https://issues.apache.org/jira/browse/STDCXX-467
Project: C++ Standard Library
Issue Type: Bug
Components: External
Environment: Intel Thread Checker 3.1 with Intel C++ 9.1.049 on Red
Hat Enterprise Linux AS release 4 (Nahant Update 4)
Reporter: Martin Sebor
Running the program below through the thread checker gives the Wrtite->Read
data race error shown in the output:
$ cat t.c && icc -V t.c -pthread && tcheck_cl -v a.out
#include
static int flag;
static void init () { flag = 1; }
static pthread_once_t flag_init;
static int foo () {
pthread_once (&flag_init, init);
return flag;
}
static void* thr_func (void *a) {
int i;
int n = 0;
for (i = 0; i != 100; ++i)
n += foo ();
return (void*)n;
}
int main () {
pthread_t pid [2];
int i;
for (i = 0; i != sizeof pid / sizeof *pid; ++i)
pthread_create (pid + i, 0, thr_func, 0);
for (i = 0; i != sizeof pid / sizeof *pid; ++i)
pthread_join (pid [i], 0);
}
Intel(R) C Compiler for Intel(R) EM64T-based applications, Version 9.1Build
20070320 Package ID: l_cc_c_9.1.049
Copyright (C) 1985-2007 Intel Corporation. All rights reserved.
Edison Design Group C/C++ Front End, version 3.6 (Mar 22 2007 02:18:08)
Copyright 1988-2005 Edison Design Group, Inc.
GNU ld version 2.15.92.0.2 20040927
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Instrumenting
14% a.out ( All Functions ):..
Running: /build/sebor/stdcxx-icc-9.1_049-15S/tests/a.out
Application finished
___
|ID|Short Des|Sever|Co|Contex|Description |1st Ac|2nd Acc|
| |cription |ity |un|t[Best| |cess[B|ess[Bes|
| | |Name |t |] | |est] |t] |
___
|1 |Write -> |Error|10|[a.out|Memory read at [a.out, 0x7b9]|[a.out|[a.out,|
| |Read | |0 |, |conflicts with a prior memory|, |0x7b9] |
| |data-race| | |0x79a]|write at [a.out, 0x7d0] (flow|0x7d0]| |
| | | | | |dependence) | | |
___
|2 |Thread te|Infor|1 |WholeP|Thread termination at [a.out,|[a.out|[a.out,|
| |rmination|matio| |rogram|0x762] - includes stack |, |0x762] |
| | |n| |1 |allocation of 10.004 MB and use |0x762]| |
| | | | | |of 5.047 KB | | |
___
|3 |Thread te|Infor|1 |WholeP|Thread termination at [a.out,|[a.out|[a.out,|
| |rmination|matio| |rogram|0x762] - includes stack |, |0x762] |
| | |n| |2 |allocation of 10.004 MB and use |0x762]| |
| | | | | |of 4.984 KB | | |
___
|4 |Thread te|Infor|1 |WholeP|Thread termination at [a.out,|[a.out|[a.out,|
| |rmination|matio| |rogram|0x728] - includes stack |, |0x728] |
| | |n| |3 |allocation of 10 MB and use of |0x728]| |
| | | | | |1.984 KB | | |
___
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: MSVC8 CRT "Secure Template Overloads" feature and stdcxx
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, July 02, 2007 10:50 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: MSVC8 CRT "Secure Template Overloads" feature and stdcxx > > >> On gcc 3.4.4/Cygwin the va_list type is not defined in stdio.h. > > > > Right. The C standard requires that be #included before > > calling vsnprintf(). To do what you want you'd need to find a way > > (ideally a general mechanism) to also #include in these > > tests. > > So what's the status of this improvement? I didn't mean to > shoot it down completely, just point out the problem with it > on other platforms. Since this is an MSVC-specific feature it > wouldn't be completely inappropriate to devise an > MSVC-specific solution for it. We can extend headers.inc with additional data on headers and types, i.e.: # list of headers hdrs="assert ctype errno float iso646 limits locale math setjmp signal \ stdarg stddef stdio stdlib string time wchar wctype new typeinfo" hdrs="$hdrs ieeefp.h pthread.h" # list of types in header stdarg_h="va_list" stddef_h="size_t ptrdiff_t" And then search and #include header which define the type, used in function call. Farid.
RE: Intel C++ build issues on Windows
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, July 03, 2007 7:08 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: Intel C++ build issues on Windows > > > There are 3 types of popup's: > > 1) Dr.Watson window, appear on access violation or unhandled > > exception; > > 2) CRT asserts ; > > 3) Parameter validattion handler popup's. > > > > The 1) prevented in exec utility (SetErrorMode()). The 2) and 3) > > might be prevented by installing report hook and invalid parameter > > handler: > > > > > http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03761.h > > tm > > l > > Gotcha! I see I still owe you a response to your feedback in > that thread. The solution in 2) and 3) will only take care of > these popups in tests and not in examples or config tests (or > locales?) Yes. > We'll also need a solution for those executables > (but we can worry about that once we're done enhancing the > test driver). We can install the similar handlers in each example, but I don't see any 2) of 3) popups in examples at the moment. Farid.
RE: STDCXX tests fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Monday, July 02, 2007 8:23 PM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STDCXX tests fails and reasons [MSVC] > > >> Jira for the "bug in rw_match(&char, &char, 1)." > > But is that really a bug in rw_match()? It looks to me > more like a design limitation than a bug. In the case of the > wchar_t* and UserChar* overloads of rw_match() there should > be a simple solution: make sure the first (char*) argument > has enough elements (it should be easy to guarantee that > since the argument is the hardcoded string we match against). > And changing the char* overload to behave the same as the > other two, i.e., to only do the expansion on the first > argument and not on the second should fix that case, no? The problem is in that rw_match() used to compare single characters. There no problem in compare one character NUL-terminated string (i.e. "b" or "[EMAIL PROTECTED]"). We should not use rw_match() to compare single characters. Farid.
RE: svn commit: r550837 - /incubator/stdcxx/trunk/include/rw/_iosbase.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, July 03, 2007 7:17 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: svn commit: r550837 - > /incubator/stdcxx/trunk/include/rw/_iosbase.h > > [EMAIL PROTECTED] wrote: > > Author: faridz > > Date: Tue Jun 26 09:01:18 2007 > > New Revision: 550837 > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=550837 > > Log: > > 2007-06-26 Farid Zaripov <[EMAIL PROTECTED]> > > > > * _iosbase.h: Fixed references to standard. > > Thanks for correcting these. FWIW, I think the best way to > deal with these references going forward will be to remove > them all since some or possibly even many of the clause > numbers are likely to change in the next standard. Plus, I > don't even find them very helpful -- do you? I used this reference when I investigated the access violation problem in 22.locale.num.put.mt.cpp test: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03781.htm l Farid.
RE: STDCXX examples fails and reasons [MSVC]
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, July 03, 2007 7:38 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: STDCXX examples fails and reasons [MSVC] > > > I have updated the windows build infrastructure to set TZ > > environment variable before run examples. The proposed > similar changes > > in unix infrastructure below, but I'm not sure that is correct: > > Why not? :) Because in windows infrastructure the TZ environment variable is set for all examples only, but my patch in unix infrastructure sets TZ variable for tests also. > If you're not sure it's portable check out the TZ > section in POSIX: > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html > > Any of MST7, MST07, MST+7, and MST+07 should work. If it > works on the platforms you have access to (Linux and HP-UX) I > say check it in and keep an eye out on failures for a few > days to make sure it works everywhere else. Farid.
RE: 21.string.rfind.cpp test fail reason
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Tuesday, July 03, 2007 7:02 AM > To: stdcxx-dev@incubator.apache.org > Subject: Re: 21.string.rfind.cpp test fail reason > > > The test deals with exceptions (the all exceptions are catched). > > I mean that concrete test line not expected any exception > and issues > > rw_error() when length_error() catched. > > I don't see any calls to rw_error() in 21.string.rfind.cpp > but you probably meant rw_assert(). Yes, I mean rw_assert(). Sorry. > rfind() is not required > to and shouldn't throw under any conditions. There's no > efficient way for all the overloads of rfind() to throw > consistently under the same conditions so it should just > return npos instead. We need a Jira issue to track this change. http://issues.apache.org/jira/browse/STDCXX-466 Farid.
[jira] Created: (STDCXX-466) basic_string<>::rfind() throws length_error(), but should return npos
basic_string<>::rfind() throws length_error(), but should return npos - Key: STDCXX-466 URL: https://issues.apache.org/jira/browse/STDCXX-466 Project: C++ Standard Library Issue Type: Bug Components: 21. Strings Affects Versions: 4.2 Environment: All Reporter: Farid Zaripov The details are here: http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg03795.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
