RE: 4.2.0 merge today
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 26, 2007 8:04 PM To: stdcxx-dev@incubator.apache.org Subject: 4.2.0 merge today The one problematic platform that might need some attention is Intel Intel C++ 9.1 on Windows 2000/x86. A 12d build fails with this error: Linking...(Intel C++ Environment) xilink: executing 'link' Creating library D:\bman5\builds\33762791\source-buildspace\build\icc-9.1\12d\l ib\libstd12d.lib and object D:\bman5\builds\33762791\source-buildspace\build\icc-9.1\12d\l ib\libstd12d.exp wctype.obj : fatal error LNK1103: debugging information corrupt; recompile module Here's the log: http://people.apache.org/~sebor/stdcxx/results/Windows_2000-ic l-32b-9.1-12d-win32-log.gz.txt Farid, can you reproduce this in your environment? The problem not reproduced at my workstation. Farid.
Re: svn commit: r551156 - /incubator/stdcxx/trunk/tests/src/thread.cpp
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Wed Jun 27 06:17:27 2007
New Revision: 551156
URL: http://svn.apache.org/viewvc?view=revrev=551156
Log:
2007-06-27 Farid Zaripov [EMAIL PROTECTED]
* thread.cpp (rw_get_cpus) [_WIN32]: Added Windows version of the
function.
Cool, thanks! Eventually, I'd like to do it this way (i.e.,
programmatically as opposed to using the shell) on all
platforms.
Martin
Modified:
incubator/stdcxx/trunk/tests/src/thread.cpp
Modified: incubator/stdcxx/trunk/tests/src/thread.cpp
URL:
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/tests/src/thread.cpp?view=diffrev=551156r1=551155r2=551156
==
--- incubator/stdcxx/trunk/tests/src/thread.cpp (original)
+++ incubator/stdcxx/trunk/tests/src/thread.cpp Wed Jun 27 06:17:27 2007
@@ -31,11 +31,12 @@
#include rw_thread.h
#include stddef.h // for size_t
-#include stdio.h // for FILE, fscanf(), popen()
#include string.h // for memset()
-#ifdef _WIN32
-# define popen(name, mode) _popen(name, mode)
+#ifndef _WIN32
+# include stdio.h // for FILE, fscanf(), popen()
+#else// _WIN32
+# include windows.h// for GetSystemInfo()
#endif // _WIN32
/**/
@@ -380,45 +381,44 @@
_TEST_EXPORT int
rw_get_cpus ()
{
+#ifndef _WIN32
+
const char* const cmd = {
// shell command(s) to obtain the number of processors
-#ifdef _RWSTD_OS_AIX
+# ifdef _RWSTD_OS_AIX
// AIX: /etc/lsdev -Cc processor | wc -l
/etc/lsdev -Cc processor | /usr/bin/wc -l
-#elif defined (_RWSTD_OS_LINUX)
+# elif defined (_RWSTD_OS_LINUX)
// Linux: cat /proc/cpuinfo | grep processor | wc -l
/usr/bin/cat /proc/cpuinfo
| /usr/bin/grep processor
| /usr/bin/wc -l
-#elif defined (_RWSTD_OS_FREEBSD)
+# elif defined (_RWSTD_OS_FREEBSD)
// FreeBSD: /sbin/sysctl -n hw.ncpu
/sbin/sysctl -n hw.ncpu
-#elif defined (_RWSTD_OS_HP_UX)
+# elif defined (_RWSTD_OS_HP_UX)
// HP-UX: /etc/ioscan -k -C processor | grep processor | wc -l
/etc/ioscan -k -C processor
| /usr/bin/grep processor
| /usr/bin/wc -l
-#elif defined (_RWSTD_OS_IRIX64)
+# elif defined (_RWSTD_OS_IRIX64)
// IRIX: hinv | /usr/bin/grep ^[1-9][0-9]* .* Processor
/sbin/hinv
| /usr/bin/grep \^[1-9][0-9]* .* Processor\
-#elif defined (_RWSTD_OS_OSF1)
+# elif defined (_RWSTD_OS_OSF1)
// Tru64 UNIX: /usr/sbin/psrinfo | grep online | wc -l
/usr/sbin/psrinfo
| /usr/bin/grep on[-]*line
| /usr/bin wc -l
-#elif defined (_RWSTD_OS_SUNOS)
+# elif defined (_RWSTD_OS_SUNOS)
// Solaris: /usr/bin/mpstat | wc -l
/usr/bin/mpstat
| /usr/bin/grep -v \^CPU\
| /usr/bin/wc -l
-#elif defined (_RWSTD_OS_WINDOWS)
-// Windows: ???
-0
-#else
+# else
0
-#endif
+# endif
};
@@ -441,6 +441,14 @@
}
return ncpus;
+
+#else// _WIN32
+
+SYSTEM_INFO info;
+GetSystemInfo (info);
+return int (info.dwNumberOfProcessors);
+
+#endif // _WIN32
}
/**/
RE: status of thread safety tests
-Original Message-
From: [EMAIL PROTECTED]
Sent: Tue, 26 Jun 2007 18:57:44 +0300
To: stdcxx-dev@incubator.apache.org
Subject: RE: status of thread safety tests
-Original Message-
From: Mark Brown [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 26, 2007 5:06 PM
To: stdcxx-dev@incubator.apache.org
Subject: RE: status of thread safety tests
22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6)
even with a single thread. Here's the output of gdb:
The same trouble on MSVC. And I found the problem.
struct Ios: std::ios {
} io;
Here should be defined ctor invoking ios_base::init() according to
27.4.2.7 p1: Ios () { this-init (0); }
The same bug present in 22.locale.money.put.mt and
22.locale.time.put.mt tests.
Fixed thus: http://svn.apache.org/viewvc?view=revrev=550833
Hi Farid,
This change appears to have cleared up the original issue. However, with
multiple threads the test now sometimes crashes with the following error:
terminate called after throwing an instance of 'std::runtime_error'
what(): /home/mbrown/stdcxx/src/setlocale.cpp:130:
__rw::__rw_setlocale::__rw_setlocale(const char*, int, int): bad locale name:
PY
The name of the locale varies and is sometimes garbage so it might be caused by
some memory corruption.
-- Mark
I'm not sure if this patch resolves the STDCXX-450 issue.
Farid.
GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music
online!
Visit http://www.inbox.com/storage to find out more!
Re: status of thread safety tests
Farid Zaripov wrote:
-Original Message-
From: Mark Brown [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 26, 2007 5:06 PM
To: stdcxx-dev@incubator.apache.org
Subject: RE: status of thread safety tests
22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6)
even with a single thread. Here's the output of gdb:
The same trouble on MSVC. And I found the problem.
struct Ios: std::ios {
} io;
Here should be defined ctor invoking ios_base::init() according to
27.4.2.7 p1: Ios () { this-init (0); }
Good catch! I'll need to look into why it didn't fail before (it should
so we don't miss it in the future).
The same bug present in 22.locale.money.put.mt and
22.locale.time.put.mt tests.
Fixed thus: http://svn.apache.org/viewvc?view=revrev=550833
Thanks!
I'm not sure if this patch resolves the STDCXX-450 issue.
We'll know more after we've run it through the thread checker. Btw.,
it seems like it could be a useful tool. You might want to download
it and experiment with it.
Martin
RE: status of thread safety tests
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Wednesday, June 27, 2007 6:22 PM To: stdcxx-dev@incubator.apache.org Subject: Re: status of thread safety tests [...] I'm not sure if this patch resolves the STDCXX-450 issue. We'll know more after we've run it through the thread checker. Btw., it seems like it could be a useful tool. You might want to download it and experiment with it. I have started downloading the Windows evaluation version (30 days evaluation period). Farid.
STDCXX tests fails and reasons [MSVC]
The list of the fails and reasons (which I've checked at the moment) is here: http://people.apache.org/~faridz/test_status.html I have question on test 27.stringbuf.virtuals. There in basic_stringbuf::xsputn() the first parameter passed pointer to the internal basic_stringbuf buffer (basic_stringbuf::pbase()). And if size of the internal buffer is not enough to receive requested number of characters, reallocation occurred and then the previous buffer (deallocated at this moment) used as source characters. Is this valid operation (I mean to pass the internal basic_stringbuf buffer in basic_stringbuf::sputn())? Btw the Dinkumware STL has the similar problem. Another problem in that test is difference between char_traitschar::eof() == int(-1) and char_traitswchar_t::eof() == int (65536). The basic_stringbuf::pbackfail() test (line 637) expected EOF == -1 and issues rw_error() diagnostic on whar_t tests. Farid.
21.string.rfind.cpp test fail reason
The problem in 21.string.rfind.cpp test is invoking string::rfind(const value_type* ptr, size_type off = npos, size_type count) with count == string::max_size() + 1 (21.string.rfind.cpp lines 413-416). The method throws length_error() exception (line 756 file string.cc) but test not expected any exceptions. Farid.
