incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Liviu Nicoara <nikko...@hates.ms>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Wed, 05 Sep 2012 01:15:23 GMT

On Sep 4, 2012, at 10:34 AM, Stefan Teleman wrote:

> On Tue, Sep 4, 2012 at 7:35 AM, Liviu Nicoara <nikkoara@hates.ms> wrote:
> 
>> By no means I am dismissing it. It is at the very least an issue of
>> efficiency. I will try an Intel C++ build on x86_64 at some point today.
>> What build type was that? I also notice that you have 4.2.1 in your path?
>> Are you building out of 4.2.1. tag? I built off 4.2.x branch which also has
>> support for custom timeouts (--soft-timeout) in rw_test.
> 
> Yes, this is 4.2.1 with all the Solaris  patches which can be applied
> on Linux. The environment is:
> 
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: Intel C++, __INTEL_COMPILER = 1210,
> __INTEL_COMPILER_BUILD_DATE = 20111011, __EDG_VERSION__ = 403
> # ENVIRONMENT: pentiumpro running linux-elf (Fedora release 17 (Beefy
> Miracle) (3.5.0-2.fc17.x86_64)) with glibc 2.15
> # FILE: 22.locale.numpunct.mt.cpp
> # COMPILED: Sep  4 2012, 09:11:36
> # COMMENT: thread safety
> ############################################################
> 
> # CLAUSE: lib.locale.numpunct
> 
> [ ... snip ... ]
> 
> With all the thread-safety Solaris patches for 1056 applied. The test
> runs to completion:
> 
> # NOTE (S2) (5 lines):
> # TEXT: executing "locale -a > /tmp/tmpfile-Cej8JU"
> # CLAUSE: lib.locale.numpunct
> # FILE: process.cpp
> # LINE: 276
> 
> # INFO (S1) (3 lines):
> # TEXT: testing std::numpunct<charT> with 8 threads, 200000 iterations
> each, in 32 locales { "C" "aa_DJ" "aa_DJ.iso88591" "aa_DJ.utf8"
> "aa_ER" "aa_ER@saaho" "aa_ER.utf8" "aa_ER.utf8@saaho" "aa_ET"
> "aa_ET.utf8" "af_ZA" "af_ZA.iso88591" "af_ZA.utf8" "am_ET"
> "am_ET.utf8" "an_ES" "an_ES.iso885915" "an_ES.utf8" "ar_AE"
> "ar_AE.iso88596" "ar_AE.utf8" "ar_BH" "ar_BH.iso88596" "ar_BH.utf8"
> "ar_DZ" "ar_DZ.iso88596" "ar_DZ.utf8" "ar_EG" "ar_EG.iso88596"
> "ar_EG.utf8" "ar_IN" "ar_IN.utf8" }
> # CLAUSE: lib.locale.numpunct
> 
> [ ... snip ... ]
> 
> # +-----------------------+----------+----------+----------+
> # | DIAGNOSTIC            |  ACTIVE  |   TOTAL  | INACTIVE |
> # +-----------------------+----------+----------+----------+
> # | (S1) INFO             |       11 |       11 |       0% |
> # | (S2) NOTE             |        1 |        1 |       0% |
> # | (S8) ERROR            |        0 |        3 |     100% |
> # | (S9) FATAL            |        0 |        1 |     100% |
> # +-----------------------+----------+----------+----------+
> real 2139.31
> user 2406.09
> sys 155.61
> [steleman@darthvader][/src/steleman/programming/stdcxx-intel/stdcxx-4.2.1-thread-safe/build/tests][09/04/2012
> 9:50:14][1300]>>
> 
> These tests running to completion (with the patches applied) are 100%
> reproducible on every single run, on Linux and Solaris (Intel and
> SPARC).

That is good, right?

> 
> The timings are the output of /usr/bin/time -p.
> 
> Yes, ~40 minutes wall clock run time for one test is quite a lot. But
> it runs to completion, with zero errors. And when taking into
> consideration that there are 8 threads with 200000 iterations, maybe
> it's not that much. FWIW, SELinux is also fully enabled in my
> environment.


Ok, so that clears (this build at least), maybe inefficient but runs to completion with no
crashes.


> 
> The timeouts can also be a symptom of race conditions/deadlocks or
> attempting to access invalid thread stacks, or partially written data.


I would look at timeouts from the standpoint of the progression of the run: if the run does
not progress at all, as in threads are deadlocked, then I would consider that a defect. If
the run progresses, it is a mere inefficiency, however bad.


> It's very platform specific. On Solaris SPARC (either 32-bit or
> 64-bit) I never get timeouts, I always get either SEGV or SIGBUS. On
> Intel it appears that timeouts are the prevailing symptom.

Could not get an Intel build off the ground on the account of the LIMITS.cpp test not running
to completion because of a possible compiler bug. I posted earlier an account of it. Do you
have a support account that allows posting bug reports for Intel's C++ compiler?


> 
> I am not sure what an explicit run timeout would add, except hiding
> the hang/deadlock/memory corruption problem behind a timeout.


The timeout option allowed me to run the program with a larger value, such that the alarm
would not trigger and allow the program to run to completion. Before enlarging the timeout
value, the individual tests would time out.

I did not have access to a Solaris box since I left Rogue Wave. Does Sun/Oracle have any program
that would allow one to test drive their compiler on a shared box somewhere? I vaguely remember
that HP had something like that a while ago.

Thanks!

Liviu
Mime
View raw message