incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Heimlich, a.k.a. hajma" <tropikha...@gmail.com>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Wed, 05 Sep 2012 21:35:48 GMT
2012/9/5 Stefan Teleman <stefan.teleman@gmail.com>:
> On Tue, Sep 4, 2012 at 9:15 PM, Liviu Nicoara <nikkoara@hates.ms> wrote:
>
>> That is good, right?
>
> Yes, it is good. :-)
>
>
>> 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?
>
> Oh, yes I remember that now, it happened to me too. I worked around it
> by copying the LIMITS executable from a gcc build.
>
> I don't have a support contract with Intel - I'm using the free
> compilers at home. I'm guessing Intel must have an open forum for
> Intel developers using their compilers, so that might be a way to
> report the bug. But I haven't looked for it.
>
>
>
>> 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.
>
> I know Sun had such a program. Oracle I don't really know but my
> educated guess is "not a chance". ;-)

Gold and above members of the oracle parter network can* get access to
a lab running various Oracle HW and SW.
For regular persons Stefan's answer applies 100%.

However there's nothing stopping you from downloading Solaris 11 iso
or a virtualbox image from
http://www.oracle.com/technetwork/server-storage/solaris11/downloads/index.html
installing it in a virtualization solution of your choice (virtualbox
works best for me) and installing Studio from
http://www.oracle.com/technetwork/server-storage/solarisstudio/downloads/index.html

As long as the installation is used for sw development and not for
production use you do not need to pay Oracle a dime, you just won't
get any updates/patches. (check the licenses fo details, I'm no
lawyer)

P.

* this was announced in April, I have no idea about the current status

>
> One way of testing with SunPro is to download the free version of
> SunPro from Oracle, and use it on Linux (yes, SunPro exists for Linux
> as well). It works very well on OpenSUSE and Ubuntu (tested and used
> on both myself, debugged stdcxx on OpenSUSE with SunPro 12.2. Doesn't
> work at all on Fedora 17 because of the TLS glibc bug (however it used
> to on earlier Fedora releases).
>
> And now for the latest about 1056:
>
> I managed (after many, MANY tries) to get a run of
> 22.locale.numpunct.mt on Solaris SPARC 32-bit build (at work), and
> without the thread-safety patches applied, and I hit the jackpot:
>
> # INFO (S1) (10 lines):
> # TEXT:
> # COMPILER: SunPro, __SUNPRO_CC = 0x5100
> # ENVIRONMENT: sparc-v8 running sunos-5.11
> # FILE: 22.locale.numpunct.mt.cpp
> # COMPILED: Sep  4 2012, 16:10:03
> # COMMENT: thread safety
> ############################################################
>
> # CLAUSE: lib.locale.numpunct
>
> # NOTE (S2) (5 lines):
> # TEXT: executing "/usr/bin/locale -a > /var/tmp/tmpfile-MWa4bQ"
> # CLAUSE: lib.locale.numpunct
> # FILE: process.cpp
> # LINE: 276
>
> # INFO (S1) (3 lines):
> # TEXT: testing std::numpunct<charT> with 4 threads, 1000 iterations
> each, in 32 locales { "C" "POSIX" "af_ZA.UTF-8" "ar_AE.UTF-8"
> "ar_BH.UTF-8" "ar_DZ.UTF-8" "ar_EG.ISO8859-6" "ar_EG.UTF-8"
> "ar_IQ.UTF-8" "ar_JO.UTF-8" "ar_KW.UTF-8" "ar_LY.UTF-8" "ar_MA.UTF-8"
> "ar_OM.UTF-8" "ar_QA.UTF-8" "ar_SA.UTF-8" "ar_TN.UTF-8" "ar_YE.UTF-8"
> "as_IN.UTF-8" "az_AZ.UTF-8" "be_BY.UTF-8" "bg_BG.ISO8859-5"
> "bg_BG.UTF-8" "bn_IN.UTF-8" "bs_BA.ISO8859-2" "bs_BA.UTF-8"
> "ca_ES.ISO8859-1" "ca_ES.ISO8859-15" "ca_ES.UTF-8" "cs_CZ.ISO8859-2"
> "cs_CZ.UTF-8" "cs_CZ.UTF-8@euro" }
> # CLAUSE: lib.locale.numpunct
>
> [ ... snip ... ]
>
> # INFO (S1) (4 lines):
> # TEXT: creating a thread pool with 4 threads
> # CLAUSE: lib.locale.numpunct
> # LINE: 548
>
> Abort (core dump)
>
> /builds/steleman/userland-stdcxx-upstream-thread-safety/components/stdcxx/stdcxx-4.2.1/tests/localization/22.locale.numpunct.mt.cpp:140:
> Assertion '0 == rw_strncmp (grp.c_str (), data.grouping_.c_str ())'
> failed.
> /builds/steleman/userland-stdcxx-upstream-thread-safety/components/stdcxx/stdcxx-4.2.1/build/lib/libstdcxx4.so.4.2.1'__1cE__rwQ__rw_assert_fail6Fpkc2i2_v_+0x78
> [0xff249af8]
> /builds/steleman/userland-stdcxx-upstream-thread-safety/components/stdcxx/stdcxx-4.2.1/build/tests/22.locale.numpunct.mt'thread_func+0x500
> [0x1b050]
> /lib/libc.so.1'_lwp_start+0x0 [0xf7b553f0]
>
> Bingo!
>
> At line 140 in 22.locale.numpunct.mt.cpp, we see:
>
>  RW_ASSERT (0 == rw_strncmp (grp.c_str (),
>                                         data.grouping_.c_str ()));
>
> What this means:
>
> Between the time std::string grp was initialized at line 133:
>
> const std::string grp = np.grouping ();
>
> and the time we hit line 140 (the RW_ASSERT), another thread modified
> the std::string _C_grouping member of class
>
> template <class _CharT> class numpunct : public _RW::__rw_facet.
>
> And because this is the non-patched version of _numpunct.h, the
> variable std::string grp did not really return a deep copy of
> _C_grouping, but a shared handle to its underlying _CharT buffer. Nor
> was the initialization of _C_grouping mutex-protected inside the
> member function
>
> template <class _CharT>
> inline string numpunct<_CharT>::grouping () const.
>
> This shared buffer was subsequently modified by another thread, in
> another locale, while this thread was convinced, all along, that it
> was holding a deep copy of the variable std::string grp, in the locale
> it wanted. Hence, the assertion on the strcmp(3C) mismatch.
>
> --Stefan
>
> --
> Stefan Teleman
> KDE e.V.
> stefan.teleman@gmail.com

Mime
View raw message