Re: svn commit: r649647 - /stdcxx/trunk/etc/config/windows/configure.wsf
From: Martin Sebor [mailto:[EMAIL PROTECTED] To: dev@stdcxx.apache.org Subject: Re: svn commit: r649647 - /stdcxx/trunk/etc/config/windows/configure.wsf > I'm getting ready to merge a few last minute changes from last > week to 4.2.x. I can't tell from the description of this change > if this fix is important for 4.2.1 or not. Farid? No. This change might be important for specific platforms, like Windows Mobile. Farid.
ABI test results with MSVC 8.0/Windows XP-64bit/12d
msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 limits DIFF 0 random_shuffle 0DIFF 21.string.io.stdcxx-250 ABRTNOUT 21.string.stdcxx-231 ABRTNOUT 22.locale.ctype.is331 0 22.locale.ctype.narrow 0 381 5 0 22.locale.num.put 96 24 22.locale.num.put.stdcxx-2 ABRTNOUT 27.basic.ios.copyfmt.stdcxx-766 ABRTNOUT 27.ostream.unformatted.stdcxx-626ABRTNOUT 27.ostream 2 0 2 0 27.streambuf.imbue.stdcxx-307ABRTNOUT 27.stringbuf.overflow.stdcxx-795 ABRTNOUT The results in 15d configuration and on icc 10.0 in 12d and 15d are the same. Farid.
RE: ABI test results with MSVC 8.0/Windows XP-64bit/12d
>-Original Message- >From: Farid Zaripov [mailto:[EMAIL PROTECTED] >Sent: Tuesday, April 22, 2008 5:27 AM >To: dev@stdcxx.apache.org >Subject: ABI test results with MSVC 8.0/Windows XP-64bit/12d > >msvc 8.0/WinXP-64bit/12d SRC: 4.2.0 4.2.0 4.2.1 4.2.1 > LIB: 4.2.0 4.2.1 4.2.0 4.2.1 >limits DIFF 0 >random_shuffle 0DIFF >21.string.io.stdcxx-250 ABRTNOUT >21.string.stdcxx-231 ABRTNOUT >22.locale.ctype.is331 0 >22.locale.ctype.narrow 0 381 5 0 >22.locale.num.put 96 24 >22.locale.num.put.stdcxx-2 ABRTNOUT >27.basic.ios.copyfmt.stdcxx-766 ABRTNOUT >27.ostream.unformatted.stdcxx-626ABRTNOUT >27.ostream 2 0 2 0 >27.streambuf.imbue.stdcxx-307ABRTNOUT >27.stringbuf.overflow.stdcxx-795 ABRTNOUT > > > The results in 15d configuration and on icc 10.0 in 12d and >15d are the same. > >Farid. > I'm curious what it means when nothing is shown in a cell. i.e. what were the results of the limits test for the last two configurations? >
Re: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp
I agree that the purpose of --verbose is to provide additional
informational detail about what's being tested, not to increase
the strictness of the test. Adding a new option to enable
expensive memory checks sounds like the right approach to me.
Martin
Travis Vitek wrote:
I managed to prematurely send that last message. Here is the completed response
Farid Zaripov wrote:
From: Travis Vitek [mailto:[EMAIL PROTECTED]
To: dev@stdcxx.apache.org
Subject: RE: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp
* tests/src/driver.cpp [_MSC_VER] (_rw_opt_verbose):
Turn on checking the memory at every allocation and
deallocation in verbose mode.
Perhaps this should be put into its own routine option. I
believe that this memory checking can slow things down quite
a bit, and I'd like to avoid that overhead when doing verbose
checking.
And how often you're doing verbose checking? :)
I actually use it occasionally to verify that any rw_assert() calls I add will
display correctly in verbose mode, but that isn't really the point.
I see that
the only difference between the verbose and non-verbose modes
is printing the description (diag_msgs[].desc) in diag messages.
The definition of verbose is 'to use more words than are necessary'. Typically
verbose mode for a program enables additional output but it doesn't change the
behavior of the program in other ways.
So I thought that --verbose option is used very rarely at this
time and the name of this option is corresponding to added
actions - verbose checking the using of the heap memory :)
Just because we don't use the option frequently isn't a good reason misuse it.
At home we don't use our fine china dinnerware more than once a year, but I
wouldn't dare use the gravy boat as an oil pan.
(_rw_opt_compat): Disable MSVC debug popup's in compat mode.
According to some conversation we had with Martin last week,
this should have been enabled all the time. If this is the case,
maybe this code should be moved to rw_vtest() to make that happen?
Why? Personally I found the debug MSVC popups very useful in
debugging.You can't miss the debug message because you have to
press some button in message box to close it.
Oh, I agree. They make it difficult to not notice a failure, especially when
running the tests from the command line.
And you need press the only one button ("Retry") to launch and
attach the debugger and see the source file on failing line with
call stack. If they are will be disabled all the time, you will
need scan the program output for the debug messages and then
wast some time to find the failing line in source code...
Well, now I have two more problems with this change. First this change disables
the window for CRT errors only. It should probably do the same for the gpfault
error box via a call to SetErrorMode(). Second, it sends the messages only to
the debugger output window. I think we should be sending them stderr also so
that we can see the messages in the output spew. Otherwise it would be _very_
easy to overlook these types of errors.
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
_CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE | _CRTDBG_MODE_DEBUG);
_CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDERR );
Of course we can enable these popups by adding a new program
option, but I launching the tests from IDE most of time and
it's not convinient to specify the program options manually
for every test (but I found that I can use the RWSTD_TESTOPTS
environment variable for this :) ).
If you're launching an individual test from the IDE with F5 or CTRL+F5 you
would have to specify the --compat command line option (or the hypothetical
--no-popups option) somewhere to disable the CRT error dialog, so this should
not be a problem. The CRT error dialogs should continue appear as it always has
in this situation.
If you are using the runtests project from within the IDE, I believe that it
sets the --compat flag automatically for each executable that is ran from
runall.wsh. So you would not see the CRT error messages and you would need to
find a way to disable the command line option then.
So what I'm saying here is that we should consider adding a new option
--no-popups that calls _CrtSetReportMode(), _CrtSetReportFile() and
SetDebugMode(). That option should probably be passed to the exec utility to
pass on to each test when running the nightly builds. Adding this option should
have no impact on the behavior you experience when running tests from the IDE
today.
Travis
Re: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp
Farid Zaripov wrote:
From: Travis Vitek [mailto:[EMAIL PROTECTED]
To: dev@stdcxx.apache.org
Subject: RE: svn commit: r648128 - /stdcxx/trunk/tests/src/driver.cpp
* tests/src/driver.cpp [_MSC_VER] (_rw_opt_verbose):
Turn on checking the memory at every allocation and
deallocation in verbose mode.
Perhaps this should be put into its own routine option. I believe that
this memory checking can slow things down quite a bit, and I'd like to
avoid that overhead when doing verbose checking.
And how often you're doing verbose checking? :) I see that the only
difference between the
verbose and non-verbose modes is printing the description (diag_msgs[].desc) in
diag messages.
So I thought that --verbose option is used very rarely at this time and the
name of this option
is corresponding to added actions - verbose checking the using of the heap
memory :)
(_rw_opt_compat): Disable MSVC debug popup's in compat mode.
According to some conversation we had with Martin last week, this should
have been enabled all the time. If this is the case, maybe this code
should be moved to rw_vtest() to make that happen?
Why? Personally I found the debug MSVC popups very useful in debugging. You
can't miss
the debug message because you have to press some button in message box to close
it.
And you need press the only one button ("Retry") to launch and attach the
debugger and see
the source file on failing line with call stack. If they are will be disabled
all the time, you will
need scan the program output for the debug messages and then wast some time to
find the
failing line in source code... Of course we can enable these popups by adding a
new program
option, but I launching the tests from IDE most of time and it's not convinient
to specify the
program options manually for every test (but I found that I can use the
RWSTD_TESTOPTS
environment variable for this :) ).
IMO, there are at least three distinct use cases when it comes
to debugging tests on Windows:
1. running the test in the debugger
2. running the test on the command line
3. running the test in batch mode
I can see how having the debugger stop with a pop-up window at
the point of an error would be useful in the IDE. The function
IsDebuggerPresent() can be used to detect if a program runs in
a debugger and automatically enable the pop-ups if they are
otherwise disabled.
http://msdn2.microsoft.com/en-us/library/ms680345.aspx
I'm less sure the pop-ups are necessarily always useful when
running the test on the command line, although I agree that
there certainly are situations when it is convenient.
Finally, in batch mode we definitely don't want any interactive
pop-ups.
So in my mind the question comes down to: do we want the pop-ups
on in (2) by default or off? If the latter, why not turn them off
unconditionally and add a new option to enable them?
Martin
Regression tests file structure
Not that it really matters but I noticed lots of rather small programs for the regression tests. Couldn't these be consolidated into fewer source files, by component perhaps, with a function for each individual regression test? Just a thought. Brad.
Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, April 21, 2008 10:50 AM
To: dev@stdcxx.apache.org
Subject: Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
Eric Lemings wrote:
-Original Message-
From: Eric Lemings
Sent: Monday, April 21, 2008 9:43 AM
To: Martin Sebor; Travis Vitek
Subject: RE: //stdcxx/trunk/tests/localization/22_synopsis.cpp
...
I'm testing with gcc on Linux and this is not defined which
in turn leads to compile errors.
And where is get_locale_category()? I can't find it anywhere.
See the %{Lc} directive to rw_printf(). Here are some use cases:
http://fisheye6.cenqua.com/browse/stdcxx/trunk/tests/self/0.pr
intf.cpp?r=trunk#l1061
Martin
What is/was the 2nd boolean parameter to get_locale_category() and
does it have any bearing on the %{Lc} directive?
I don't remember off the top of my head. Why don't you look
at the implementation of the function in the old driver:
http://tinyurl.com/3ozfpb
Martin
RE: //stdcxx/trunk/tests/localization/22_synopsis.cpp
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 22, 2008 9:25 AM
> To: dev@stdcxx.apache.org
> Subject: Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
>
> Eric Lemings wrote:
> >
> >
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, April 21, 2008 10:50 AM
> >> To: dev@stdcxx.apache.org
> >> Subject: Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
> >>
> >> Eric Lemings wrote:
> >>>
> >>>
> -Original Message-
> From: Eric Lemings
> Sent: Monday, April 21, 2008 9:43 AM
> To: Martin Sebor; Travis Vitek
> Subject: RE: //stdcxx/trunk/tests/localization/22_synopsis.cpp
>
>
>
> > ...
> I'm testing with gcc on Linux and this is not defined which
> in turn leads to compile errors.
> >>> And where is get_locale_category()? I can't find it anywhere.
> >> See the %{Lc} directive to rw_printf(). Here are some use cases:
> >> http://fisheye6.cenqua.com/browse/stdcxx/trunk/tests/self/0.pr
> >> intf.cpp?r=trunk#l1061
> >>
> >> Martin
> >
> > What is/was the 2nd boolean parameter to get_locale_category() and
> > does it have any bearing on the %{Lc} directive?
>
> I don't remember off the top of my head. Why don't you look
> at the implementation of the function in the old driver:
>http://tinyurl.com/3ozfpb
>
Ah, it does have bearing on the output. Is there a formatting directive
in the test driver that differentiates "std::locale::monetary" from
"LC_MONETARY" for example?
Brad.
Re: svn commit: r649646 - in /stdcxx/trunk/include: loc/_ctype.h rw/_defs.h
Eric Lemings wrote:
This _RWSTD_UWCHAR_INT_T type macro is added just to silence
compiler warnings?
Not just for that, but that is what it's being used for so far.
Is `unsigned wchar_t` a legitimate type?
No, but there is a notion of an "underlying integer type" for
wchar_t which is an integer type other than wchar_t with the
same size, alignment requirement, and signedness as wchar_t.
The new _RWSTD_UWCHAR_INT_T type is an unsigned form of this
underlying integer type.
Just wondering if they might not be a slightly more elegant
solution...
I couldn't think of one but if you have an idea for how to
do this better I'd be interested in hearing it.
Martin
Brad.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, April 18, 2008 12:31 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r649646 - in /stdcxx/trunk/include:
loc/_ctype.h rw/_defs.h
Author: faridz
Date: Fri Apr 18 11:30:47 2008
New Revision: 649646
URL: http://svn.apache.org/viewvc?rev=649646&view=rev
Log:
2008-04-18 Farid Zaripov <[EMAIL PROTECTED]>
* include/rw/_defs.h: #define new general purpose
config macro _RWSTD_UWCHAR_INT_T.
* include/loc/_ctype.h (narrow): Cast __c to
_RWSTD_UWCHAR_INT_T to avoid warnings
about signed/unsigned comparisons.
Modified:
stdcxx/trunk/include/loc/_ctype.h
stdcxx/trunk/include/rw/_defs.h
Modified: stdcxx/trunk/include/loc/_ctype.h
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/loc/_ctype.h
?rev=649646&r1=649645&r2=649646&view=diff
==
--- stdcxx/trunk/include/loc/_ctype.h (original)
+++ stdcxx/trunk/include/loc/_ctype.h Fri Apr 18 11:30:47 2008
@@ -541,21 +541,20 @@
inline char
ctype::narrow (char_type __c, char __dfault) const
{
+const _RWSTD_SIZE_T __inx = _RWSTD_STATIC_CAST
(_RWSTD_UWCHAR_INT_T, __c);
+
// optimize away all but the first call to the virtual do_widen()
-if ( 0 <= __c
-&& __c < sizeof _C_narrow_tab / sizeof *_C_narrow_tab
-&& _C_narrow_tab [__c])
-return _C_narrow_tab [__c];
+if ( __inx < sizeof _C_narrow_tab / sizeof *_C_narrow_tab
+&& _C_narrow_tab [__inx])
+return _C_narrow_tab [__inx];
// template argument provided to work around an HP aCC
bug (PR #27087)
ctype* const __self = _RWSTD_CONST_CAST
(ctype*, this);
const char __ch = do_narrow (__c, __dfault);
-if ( 0 <= __c
-&& __c < sizeof _C_narrow_tab / sizeof *_C_narrow_tab
-&& __ch != __dfault)
-__self->_C_narrow_tab [__c] = __ch;
+if (__inx < sizeof _C_narrow_tab / sizeof *_C_narrow_tab
&& __ch != __dfault)
+__self->_C_narrow_tab [__inx] = __ch;
return __ch;
}
Modified: stdcxx/trunk/include/rw/_defs.h
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/rw/_defs.h?r
ev=649646&r1=649645&r2=649646&view=diff
==
--- stdcxx/trunk/include/rw/_defs.h (original)
+++ stdcxx/trunk/include/rw/_defs.h Fri Apr 18 11:30:47 2008
@@ -1269,6 +1269,20 @@
#endif // _RWSTD_SSIZE_T
+// _RWSTD_UWCHAR_INT_T is "unsigned wchar_t"
+#ifndef _RWSTD_UWCHAR_INT_T
+# if _RWSTD_CHAR_SIZE == _RWSTD_WCHAR_SIZE
+#define _RWSTD_UWCHAR_INT_T unsigned char
+# elif _RWSTD_SHRT_SIZE == _RWSTD_WCHAR_SIZE
+#define _RWSTD_UWCHAR_INT_T unsigned short
+# elif _RWSTD_INT_SIZE == _RWSTD_WCHAR_SIZE
+#define _RWSTD_UWCHAR_INT_T unsigned int
+# else
+#define _RWSTD_UWCHAR_INT_T _RWSTD_SIZE_T
+# endif
+#endif // _RWSTD_UWCHAR_INT_T
+
+
#if defined(SNI)
# define _RWSTD_USING_SNI(name) _USING(__SNI::name)
# if defined(_RWSTD_STRICT_ANSI)
Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 22, 2008 9:25 AM
To: dev@stdcxx.apache.org
Subject: Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
Eric Lemings wrote:
-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Monday, April 21, 2008 10:50 AM
To: dev@stdcxx.apache.org
Subject: Re: //stdcxx/trunk/tests/localization/22_synopsis.cpp
Eric Lemings wrote:
-Original Message-
From: Eric Lemings
Sent: Monday, April 21, 2008 9:43 AM
To: Martin Sebor; Travis Vitek
Subject: RE: //stdcxx/trunk/tests/localization/22_synopsis.cpp
...
I'm testing with gcc on Linux and this is not defined which
in turn leads to compile errors.
And where is get_locale_category()? I can't find it anywhere.
See the %{Lc} directive to rw_printf(). Here are some use cases:
http://fisheye6.cenqua.com/browse/stdcxx/trunk/tests/self/0.pr
intf.cpp?r=trunk#l1061
Martin
What is/was the 2nd boolean parameter to get_locale_category() and
does it have any bearing on the %{Lc} directive?
I don't remember off the top of my head. Why don't you look
at the implementation of the function in the old driver:
http://tinyurl.com/3ozfpb
Ah, it does have bearing on the output. Is there a formatting directive
in the test driver that differentiates "std::locale::monetary" from
"LC_MONETARY" for example?
There's no need for that. The LC_XXX macros are guaranteed
to be distinct from the C++ locale category constants. See
the test for some use cases:
http://fisheye6.cenqua.com/browse/stdcxx/trunk/tests/self/0.printf.cpp?r=trunk#l1061
Martin
AIB test results with XLC++-8.0/AIX 5.3
These tests may have binary compatibility issues... 22.locale.codecvt.length 22.locale.ctype.scan 22.locale.num.put I'm also concerned with this test because it does not fail in nightly builds... 22.locale.messages.mt Travis aix-5.3-vacpp-8.0 SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 0.printfSEGV SEGV A1 A1 0.process SEGV SEGV 0 0 18.setjmpHUPHUP A1 A1 18.support.rtti N/AN/A A7 A7 21.cwcharA11A11 A5 A5 21.string.assignA360 A360A60A60 21.string.insertA840 A840 A180 A180 21.string.replace A1060 A1060 A240 A240 22.locale.codecvt.length 0 ABRT 0 0 22.locale.codecvt.outN/AN/A SEGV SEGV 22.locale.codecvt.stdcxx-435 N/AN/A ABRT NOUT 22.locale.ctype.scan HUP ABRT 0 0 22.locale.messages HUP A106HUP 0 22.locale.messages.mt SEGV SEGV SEGV SEGV 22.locale.money.get A20A20A20A20 22.locale.num.getA96A96A96A96 22.locale.num.put 0A24A26 0 22.locale.num.put.stdcxx-2 N/AN/A ABRT NOUT 22.locale.time.get A46A46 SEGV SEGV 23.deque.special A1536 A1536 0 0 23.vector.bool.stdcxx-235 ABRT ABRT NOUT NOUT 25.heap A31A31 0 0 25.partial.sortA2603 A2603 0 0 25.random.shuffle A1 A1 0 0 26.class.gslice A162 A162 A162 A162 26.valarray.cassign0 0 COMP COMP 27.basic.ios.copyfmt.stdcxx-766 N/AN/A ABRT NOUT 27.ostreamA2 A2 0 0 8.cstdint A3 A3 0 0
Re: AIB test results with XLC++-8.0/AIX 5.3
FWIW, now that we've spent a bunch of time putting the data together by hand, there might be an relatively painless way of [semi] automating it. See my comment on the issue below: http://issues.apache.org/jira/browse/STDCXX-731 Travis Vitek wrote: These tests may have binary compatibility issues... 22.locale.codecvt.length 22.locale.ctype.scan 22.locale.num.put I'm also concerned with this test because it does not fail in nightly builds... 22.locale.messages.mt Travis aix-5.3-vacpp-8.0 SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 0.printfSEGV SEGV A1 A1 0.process SEGV SEGV 0 0 18.setjmpHUPHUP A1 A1 18.support.rtti N/AN/A A7 A7 21.cwcharA11A11 A5 A5 21.string.assignA360 A360A60A60 21.string.insertA840 A840 A180 A180 21.string.replace A1060 A1060 A240 A240 22.locale.codecvt.length 0 ABRT 0 0 22.locale.codecvt.outN/AN/A SEGV SEGV 22.locale.codecvt.stdcxx-435 N/AN/A ABRT NOUT 22.locale.ctype.scan HUP ABRT 0 0 22.locale.messages HUP A106HUP 0 22.locale.messages.mt SEGV SEGV SEGV SEGV 22.locale.money.get A20A20A20A20 22.locale.num.getA96A96A96A96 22.locale.num.put 0A24A26 0 22.locale.num.put.stdcxx-2 N/AN/A ABRT NOUT 22.locale.time.get A46A46 SEGV SEGV 23.deque.special A1536 A1536 0 0 23.vector.bool.stdcxx-235 ABRT ABRT NOUT NOUT 25.heap A31A31 0 0 25.partial.sortA2603 A2603 0 0 25.random.shuffle A1 A1 0 0 26.class.gslice A162 A162 A162 A162 26.valarray.cassign0 0 COMP COMP 27.basic.ios.copyfmt.stdcxx-766 N/AN/A ABRT NOUT 27.ostreamA2 A2 0 0 8.cstdint A3 A3 0 0
ABI test results with GCC-4.1.1/SunOS 5.10
Areas of concern... 22.locale.num.put 27.filebuf.codecvt sunos-5.10-gcc-4.1.1 4.2.0 4.2.0 4.2.1 4.2.1 4.2.0 4.2.1 4.2.0 4.2.1 0.printf BUS BUS FORMAT FORMAT 18.csetjmp HUP HUP 0 0 18.limits.trapsA13 A13 0 0 18.numeric.special.float N/A N/A A5 A5 18.numeric.special.int N/A N/A A13 A13 18.setjmp HUP HUP A1 A1 21.cwchar A12 A12 A5 A5 21.string.append A560A560 0 0 21.string.assign A360A360 A60 A60 21.string.insert A840A840A180A180 21.string.io.stdcxx-250N/A N/AABRTNOUT 21.string.replaceA1060 A1060A240A240 21.string.stdcxx-231 N/A N/AABRTNOUT 22.locale.codecvt.stdcxx-435 N/A N/AABRTNOUT 22.locale.ctype A310A310 0 0 22.locale.ctype.is A80 A80 0 0 22.locale.ctype.narrowA230A230 0 0 22.locale.messagesSEGV 0SEGV 0 22.locale.money.getA16 A16 A16 A16 22.locale.num.get A96 A96 A96 A96 22.locale.num.put0 A28 A26 A4 22.locale.num.put.stdcxx-2 N/A N/AABRTNOUT 22.locale.stdcxx-554 BUS BUSNOUTNOUT 22.locale.time.get A46 A46 A46 A46 23.deque.special A15361536 0 0 23.vector.bool.stdcxx-235 ABRTABRTNOUTNOUT 25.libc A4 A4 A4 A4 25.random.shuffle A1 A1 0 0 26.class.gslice A162A162A162A162 26.valarray.cassign 0 0COMPCOMP 27.filebuf.codecvt 0 9 0 0 27.filebuf.members.stdcxx-308 N/A N/AABRTNOUT 27.ostream A2 0 A2 0 27.ostream.unformatted.stdcxx-626 N/A N/AABRTNOUT 27.stringbuf.overflow.stdcxx-795 N/A N/AABRTNOUT
22.locale.codecvt.length on AIX (was: Re: AIB test results with XLC++-8.0/AIX 5.3)
Travis Vitek wrote:
These tests may have binary compatibility issues...
22.locale.codecvt.length
I see some unexpected output with this test when I compile
it with XLC++ 9.0 in 15d. First, note the "Error: bad_alloc:
out of memory" I think it might actually be coming out of
the localedef utility. But then the test seems to hang:
$ TOPDIR=~/stdcxx-4.2.x ./22.locale.codecvt.length
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.codecvt.length.cpp
# COMPILED: Apr 22 2008, 12:15:12
# COMMENT:
# CLAUSE: lib.locale.codecvt.virtuals
# NOTE (S2) (5 lines):
# TEXT: executing "rm -rf /tmp/tmpfile-elUaaa"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
# NOTE (S2) (5 lines):
# TEXT: executing "mkdir /tmp/tmpfile-elUaaa"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
# INFO (S1) (3 lines):
# TEXT: std::codecvt::length (state_type&, const
extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt_byname::length (state_type&,
const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt::length (state_type&,
const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt_byname::length
(state_type&, const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [algorithmic encoding]
# CLAUSE: lib.locale.codecvt.virtuals
# NOTE (S2) (5 lines):
# TEXT: executing "../bin/localedef -w701 -w702 -w706 -c -f
/tmp/tmpfile-elUaaa/charmap -i /tmp/tmpfile-elUaaa/source
/tmp/tmpfile-elUaaa/mb_cur_max-9"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
Error: bad_alloc: out of memory
# ERROR (S8) (5 lines):
# TEXT: the command "../bin/localedef -w701 -w702 -w706 -c -f
/tmp/tmpfile-elUaaa/charmap -i /tmp/tmpfile-elUaaa/source
/tmp/tmpfile-elUaaa/mb_cur_max-9" exited with status 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 306
# ERROR (S8) (4 lines):
# TEXT: failed to create a locale database
# CLAUSE: lib.locale.codecvt.virtuals
# LINE: 368
# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-ftUaab"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
When I run it in the debugger, I don't get the bad_alloc and
the test runs to completion with this output:
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "Zh_CN" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "Zh_CN.GB18030" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "zh_TW" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "zh_TW.IBM-eucTW"
with MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [libc-based encoding, single-byte
characters]
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [libc-based encoding, MB_CUR_MAX =
3, multi-byte characters: "\x01", "\xc2\x80", "\xe0\xa0\x80"]
# CLAUSE: lib.locale.codecvt.virtuals
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |9 |9 | 0% |
# | (S2) NOTE |8 | 612 | 98% |
# | (S5) WARNING |0 |2 | 100% |
# | (S7) ASSERTION|0 | 382 | 100% |
# | (S8) ERROR|0 |5 | 100% |
# +---+--+--+--+
/amd/devco/sebor/stdcxx-4.2.x/tests/src/driver.cpp:1528: rw_note():
warning: test finished, cannot call
execution completed
22.locale.ctype.scan
22.locale.num.put
I'm also concerned with this test because it does not fail in nightly
builds...
22.locale.messages.mt
Travis
aix-5.3-vacpp-8.0 SRC: 4.2.0 4.2.0 4.2.1 4.2.1
LIB: 4.2.0 4.2.1 4.2.0 4.2.1
0.printfSEGV SEGV A1 A1
0.process SEGV SEGV 0 0
18.setjmpHUPHUP A1 A1
18.support.rtti N/AN/A A7 A7
21.cwcharA11A11 A5 A5
21.string.assignA360
Re: 22.locale.codecvt.length on AIX
Martin Sebor wrote:
Travis Vitek wrote:
These tests may have binary compatibility issues...
22.locale.codecvt.length
I see some unexpected output with this test when I compile
it with XLC++ 9.0 in 15d.
Even more strange, it looks like the test passes in nightly
builds on AIX...
First, note the "Error: bad_alloc:
out of memory" I think it might actually be coming out of
the localedef utility. But then the test seems to hang:
$ TOPDIR=~/stdcxx-4.2.x ./22.locale.codecvt.length
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.codecvt.length.cpp
# COMPILED: Apr 22 2008, 12:15:12
# COMMENT:
# CLAUSE: lib.locale.codecvt.virtuals
# NOTE (S2) (5 lines):
# TEXT: executing "rm -rf /tmp/tmpfile-elUaaa"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
# NOTE (S2) (5 lines):
# TEXT: executing "mkdir /tmp/tmpfile-elUaaa"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
# INFO (S1) (3 lines):
# TEXT: std::codecvt::length (state_type&, const
extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt_byname::length (state_type&,
const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt::length (state_type&,
const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt_byname::length
(state_type&, const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [algorithmic encoding]
# CLAUSE: lib.locale.codecvt.virtuals
# NOTE (S2) (5 lines):
# TEXT: executing "../bin/localedef -w701 -w702 -w706 -c -f
/tmp/tmpfile-elUaaa/charmap -i /tmp/tmpfile-elUaaa/source
/tmp/tmpfile-elUaaa/mb_cur_max-9"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
Error: bad_alloc: out of memory
# ERROR (S8) (5 lines):
# TEXT: the command "../bin/localedef -w701 -w702 -w706 -c -f
/tmp/tmpfile-elUaaa/charmap -i /tmp/tmpfile-elUaaa/source
/tmp/tmpfile-elUaaa/mb_cur_max-9" exited with status 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 306
# ERROR (S8) (4 lines):
# TEXT: failed to create a locale database
# CLAUSE: lib.locale.codecvt.virtuals
# LINE: 368
# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-ftUaab"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
When I run it in the debugger, I don't get the bad_alloc and
the test runs to completion with this output:
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "Zh_CN" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "Zh_CN.GB18030" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "zh_TW" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "zh_TW.IBM-eucTW"
with MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [libc-based encoding, single-byte
characters]
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [libc-based encoding, MB_CUR_MAX =
3, multi-byte characters: "\x01", "\xc2\x80", "\xe0\xa0\x80"]
# CLAUSE: lib.locale.codecvt.virtuals
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |9 |9 | 0% |
# | (S2) NOTE |8 | 612 | 98% |
# | (S5) WARNING |0 |2 | 100% |
# | (S7) ASSERTION|0 | 382 | 100% |
# | (S8) ERROR|0 |5 | 100% |
# +---+--+--+--+
/amd/devco/sebor/stdcxx-4.2.x/tests/src/driver.cpp:1528: rw_note():
warning: test finished, cannot call
execution completed
22.locale.ctype.scan
22.locale.num.put
I'm also concerned with this test because it does not fail in nightly
builds...
22.locale.messages.mt
Travis
aix-5.3-vacpp-8.0 SRC: 4.2.0 4.2.0 4.2.1 4.2.1
LIB: 4.2.0 4.2.1 4.2.0 4.2.1
0.printfSEGV SEGV A1 A1
0.process SEGV SEGV 0 0
18.setjmpHUPHUP A1 A1
18.support.rtti N/AN/A A7
22.locale.ctype.scan on AIX (was: Re: AIB test results with XLC++-8.0/AIX 5.3)
Travis Vitek wrote: These tests may have binary compatibility issues... 22.locale.codecvt.length 22.locale.ctype.scan I'm seeing similar things to 22.locale.codecvt.length so I can't tell what's up here or even if the system is stable... 22.locale.num.put I suspect the differences might be due to STDCXX-763. I'm also concerned with this test because it does not fail in nightly builds... 22.locale.messages.mt Here's the stack trace I get (with 4.2.1): $ dbx 22.locale.messages.mt Type 'help' for help. [using memory image in core] reading symbolic information ... Segmentation fault in ti_wfilebuf.in(char*&,const char*,const char*,const char*&,wchar_t*,wchar_t*,wchar_t*&) const at line 355 in file "/amd/devco/sebor/stdcxx-4.2.x/include/loc/_codecvt.h" ($t12) 355 return do_in (__state, __from, __from_end, __from_next, (dbx) where ti_wfilebuf.in(char*&,const char*,const char*,const char*&,wchar_t*,wchar_t*,wchar_t*&) const(0x8400607c, 0x202969ac, 0x2025c658, 0x2025c672, 0x2029699c, 0x2024b794, 0x2024b7c8, 0x202969a8), line 355 in "_codecvt.h" unnamed block in do_get(int,int,int,const std::basic_string,std::allocator >&) const(this = 0x201e8ed0, __classReturn = &(...), __cat = 1, __set = 4, __msgid = 4, __dfault = &(...)), line 103 in "_messages.cc" do_get(int,int,int,const std::basic_string,std::allocator >&) const(this = 0x201e8ed0, __classReturn = &(...), __cat = 1, __set = 4, __msgid = 4, __dfault = &(...)), line 103 in "_messages.cc" std::messages::get(int,int,int,const std::basic_string,std::allocator >&) const(this = 0x201e8ed0, __classReturn = &(...), __c = 1, __set = 4, __msgid = 4, __df = &(...)), line 94 in "_messages.h" 22.locale.messages.mt.void test_get(const std::messages&,int,int,int,const std::basic_string,std::allocator >&)(msgs = &(...), cat = 1, set = 4, msgid = 4, dflt = &(...)), line 153 in "22.locale.messages.mt.cpp" unnamed block in thread_func(void*)( = 0x2ff225c8), line 201 in "22.locale.messages.mt.cpp" thread_func(void*)( = 0x2ff225c8), line 201 in "22.locale.messages.mt.cpp" _pthread_body(??) at 0xd0111640 (dbx) print *this warning: Unable to access address 0x8400607c from core __rw_synchronized:(_C_mutex = __rw_mutex_base:(_C_mutex = (__mt_word = (-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1))) )) __rw_facet:(_C_name = warning: Unable to access address 0x from core (invalid char ptr (0x)), _C_buf = warning: Unable to access address 0x from core (invalid char ptr (0x)), _C_impdata = 0x, _C_impsize = 4294967295, _C_type = __rw_facet::_C_invalid, _C_ref = 4294967295, _C_pid = 0x) codecvt_base:) () (dbx) Travis aix-5.3-vacpp-8.0 SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 0.printfSEGV SEGV A1 A1 0.process SEGV SEGV 0 0 18.setjmpHUPHUP A1 A1 18.support.rtti N/AN/A A7 A7 21.cwcharA11A11 A5 A5 21.string.assignA360 A360A60A60 21.string.insertA840 A840 A180 A180 21.string.replace A1060 A1060 A240 A240 22.locale.codecvt.length 0 ABRT 0 0 22.locale.codecvt.outN/AN/A SEGV SEGV 22.locale.codecvt.stdcxx-435 N/AN/A ABRT NOUT 22.locale.ctype.scan HUP ABRT 0 0 22.locale.messages HUP A106HUP 0 22.locale.messages.mt SEGV SEGV SEGV SEGV 22.locale.money.get A20A20A20A20 22.locale.num.getA96A96A96A96 22.locale.num.put 0A24A26 0 22.locale.num.put.stdcxx-2 N/AN/A ABRT NOUT 22.locale.time.get A46A46 SEGV SEGV 23.deque.special A1536 A1536 0 0 23.vector.bool.stdcxx-235 ABRT ABRT NOUT NOUT 25.heap A31A31 0 0 25.partial.sortA2603 A2603 0 0 25.random.shuffle A1 A1 0 0 26.class.gslice A162 A162 A162 A162 26.valarray.cassign0 0 COMP COMP 27.basic.ios.copyfmt.stdcxx-766 N/AN/A ABRT NOUT 27.ostreamA2 A2 0 0 8.cstdint A3 A3 0 0
SIGSEGV in 22.locale.messages.mt on AIX (was: Re: AIB test results with XLC++-8.0/AIX 5.3)
Travis Vitek wrote: These tests may have binary compatibility issues... 22.locale.codecvt.length 22.locale.ctype.scan 22.locale.num.put I'm also concerned with this test because it does not fail in nightly builds... 22.locale.messages.mt I've been experimenting with this test in an effort to find under what conditions the SIGSEGV can be reliably reproduced. It seems as though the likelihood of it running successfully to completion increases as the number of threads decreases below the number of processors. For example, with just two threads running (on an 8 CPU box), the test hasn't failed in nearly 40 executions. But with the number of threads in excess of the number of processors I can pretty reliably cause the test to fail with the error below: /amd/devco/sebor/stdcxx-4.2.x/include/loc/_locale.h:364: __rw::__rw_get_std_facet: Assertion '0 != __pfacets' failed. This suggests a thread safety bug in the library... What's even more concerning than the bug itself is that we run all our thread safety tests with the same number of threads as there are processors on each server. If other hardware behaves similarly to PowerPC, we might need to bump up this number (and discover a whole bunch more problems...) Martin Travis aix-5.3-vacpp-8.0 SRC: 4.2.0 4.2.0 4.2.1 4.2.1 LIB: 4.2.0 4.2.1 4.2.0 4.2.1 0.printfSEGV SEGV A1 A1 0.process SEGV SEGV 0 0 18.setjmpHUPHUP A1 A1 18.support.rtti N/AN/A A7 A7 21.cwcharA11A11 A5 A5 21.string.assignA360 A360A60A60 21.string.insertA840 A840 A180 A180 21.string.replace A1060 A1060 A240 A240 22.locale.codecvt.length 0 ABRT 0 0 22.locale.codecvt.outN/AN/A SEGV SEGV 22.locale.codecvt.stdcxx-435 N/AN/A ABRT NOUT 22.locale.ctype.scan HUP ABRT 0 0 22.locale.messages HUP A106HUP 0 22.locale.messages.mt SEGV SEGV SEGV SEGV 22.locale.money.get A20A20A20A20 22.locale.num.getA96A96A96A96 22.locale.num.put 0A24A26 0 22.locale.num.put.stdcxx-2 N/AN/A ABRT NOUT 22.locale.time.get A46A46 SEGV SEGV 23.deque.special A1536 A1536 0 0 23.vector.bool.stdcxx-235 ABRT ABRT NOUT NOUT 25.heap A31A31 0 0 25.partial.sortA2603 A2603 0 0 25.random.shuffle A1 A1 0 0 26.class.gslice A162 A162 A162 A162 26.valarray.cassign0 0 COMP COMP 27.basic.ios.copyfmt.stdcxx-766 N/AN/A ABRT NOUT 27.ostreamA2 A2 0 0 8.cstdint A3 A3 0 0
Re: 22.locale.codecvt.length on AIX
Btw., the test attempts to create a locale from a generated charmap
file. The charmap file defines mb_cur_max to be 9 which is pretty
much guaranteed to exceed the value of MB_LEN_MAX (on AIX it's 4).
Unless the localedef utility is careful about buffer overflow it
might easily corrupt memory. I just corrected one potential problem
in this area pointed out in STDCXX-753 but I'm not sure that was
the only one. One way confirm the hypothesis that the excessively
long multibyte characters are causing trouble on AIX would be to
reduce their length and re-run the test.
http://issues.apache.org/jira/browse/STDCXX-753
Martin Sebor wrote:
Martin Sebor wrote:
Travis Vitek wrote:
These tests may have binary compatibility issues...
22.locale.codecvt.length
I see some unexpected output with this test when I compile
it with XLC++ 9.0 in 15d.
Even more strange, it looks like the test passes in nightly
builds on AIX...
First, note the "Error: bad_alloc:
out of memory" I think it might actually be coming out of
the localedef utility. But then the test seems to hang:
$ TOPDIR=~/stdcxx-4.2.x ./22.locale.codecvt.length
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: IBM VisualAge C++, __IBMCPP__ = 900
# ENVIRONMENT: powerpc running aix-5.3
# FILE: 22.locale.codecvt.length.cpp
# COMPILED: Apr 22 2008, 12:15:12
# COMMENT:
# CLAUSE: lib.locale.codecvt.virtuals
# NOTE (S2) (5 lines):
# TEXT: executing "rm -rf /tmp/tmpfile-elUaaa"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
# NOTE (S2) (5 lines):
# TEXT: executing "mkdir /tmp/tmpfile-elUaaa"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
# INFO (S1) (3 lines):
# TEXT: std::codecvt::length (state_type&,
const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt_byname::length
(state_type&, const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt::length (state_type&,
const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: std::codecvt_byname::length
(state_type&, const extern_type*, const extern_type*, size_t)
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [algorithmic encoding]
# CLAUSE: lib.locale.codecvt.virtuals
# NOTE (S2) (5 lines):
# TEXT: executing "../bin/localedef -w701 -w702 -w706 -c -f
/tmp/tmpfile-elUaaa/charmap -i /tmp/tmpfile-elUaaa/source
/tmp/tmpfile-elUaaa/mb_cur_max-9"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
Error: bad_alloc: out of memory
# ERROR (S8) (5 lines):
# TEXT: the command "../bin/localedef -w701 -w702 -w706 -c -f
/tmp/tmpfile-elUaaa/charmap -i /tmp/tmpfile-elUaaa/source
/tmp/tmpfile-elUaaa/mb_cur_max-9" exited with status 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 306
# ERROR (S8) (4 lines):
# TEXT: failed to create a locale database
# CLAUSE: lib.locale.codecvt.virtuals
# LINE: 368
# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-ftUaab"
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: process.cpp
# LINE: 276
When I run it in the debugger, I don't get the bad_alloc and
the test runs to completion with this output:
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "Zh_CN" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "Zh_CN.GB18030"
with MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "zh_TW" with
MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# NOTE (S2) (5 lines):
# TEXT: failed to find 3-byte characters in locale "zh_TW.IBM-eucTW"
with MB_CUR_MAX = 4
# CLAUSE: lib.locale.codecvt.virtuals
# FILE: locale.cpp
# LINE: 631
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [libc-based encoding, single-byte
characters]
# CLAUSE: lib.locale.codecvt.virtuals
# INFO (S1) (3 lines):
# TEXT: locale ("[EMAIL PROTECTED]") [libc-based encoding, MB_CUR_MAX =
3, multi-byte characters: "\x01", "\xc2\x80", "\xe0\xa0\x80"]
# CLAUSE: lib.locale.codecvt.virtuals
# +---+--+--+--+
# | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |9 |9 | 0% |
# | (S2) NOTE |8 | 612 | 98% |
# | (S5) WARNING |0 |2 | 100% |
# | (S7) ASSERTION|0 | 382 | 100% |
# | (S8) ERROR|0 |5 | 100% |
# +---+--+--+
Binary compatibility test results for Sun C++ 5.8 on Solaris 8 and 10 platforms
http://people.apache.org/~elemings/compat-test-results/ The diff files summarize the differences between the baseline tests (i.e. matching lib and test versions) and the compat tests (i.e. different lib and test versions) respectively. chess is a Solaris 10 machine. antlia is a Solaris 8 machine. All in all, no real big problems that I see. Brad.
Re: Binary compatibility test results for Sun C++ 5.8 on Solaris 8 and 10 platforms
Eric Lemings wrote: http://people.apache.org/~elemings/compat-test-results/ The diff files summarize the differences between the baseline tests (i.e. matching lib and test versions) and the compat tests (i.e. different lib and test versions) respectively. chess is a Solaris 10 machine. antlia is a Solaris 8 machine. All in all, no real big problems that I see. I'm afraid I don't understand the output. Which is the result of running 4.2.0 tests with 4.2.1 lib, and which is the result of running 4.2.1 tests with 4.2.0 library? See, for example, Travis' post: http://www.mail-archive.com/dev@stdcxx.apache.org/msg00637.html Martin
status of 4.2.1 issues in progress
I will be deferring all unresolved 4.2.1 issues scheduled until 4.2.2. Before I do, there are a few issues In Progress (and some effectively in the same state even though they aren't marked as such) that I'd appreciate if people assignees could resolve or update (Stop Progress) as appropriate so I don't accidentally end up deferring issues that have been fixed. Thanks Martin
