STDCXX examples fails and reasons [MSVC]
The list of the fails and reasons here: http://people.apache.org/~faridz/examples.html I think that OUTPUT status is not a fail (and examples with that status are not counted as failed in unix-like platforms, but they are counted as failed on Windows platform except cygwin). I've fixed the fail reasons of the messages example: http://svn.apache.org/viewvc?view=revrev=549546 http://svn.apache.org/viewvc?view=revrev=549550 Farid.
Re: STDCXX examples fails and reasons [MSVC]
Farid Zaripov wrote: The list of the fails and reasons here: http://people.apache.org/~faridz/examples.html Thanks! I think that OUTPUT status is not a fail (and examples with that status are not counted as failed in unix-like platforms, but they are counted as failed on Windows platform except cygwin). Oh. We need to fix that. The OUTPUT state is just a note that there is no reference output to compare the actual output against. The examples that have no reference output file are designed to produce platform-specific output. We should try to limit such examples as much as possible but in some cases (such as limits.cpp) it's not entirely possible. I've fixed the fail reasons of the messages example: http://svn.apache.org/viewvc?view=revrev=549546 http://svn.apache.org/viewvc?view=revrev=549550 Great! For the rest, we should open issues in Jira so we don't forget to get back to them. limits.cpp should produce the qnan for Quiet NAN and snan for Signaling NAN on all platforms. (We already have an issue for rwexcept: STDCXX-293). time_get looks like a bug (or lack of functionality) in our library, and time_put like a bug in our infrastructure (I assume the example assumes a certain time zone and it's being run in another). The latter could (should?) be fixed by setting the TZ environment variable time zone to the expected zone before invoking this example. codecvt1 should probably be disabled for now (until we figure out how to get it to work) and it should also be renamed to something more descriptive. Testing three hardwired encodings doesn't seem like a good idea for a simple example, so maybe we could split it up into codecvt-sjis.cpp, codecvt-eucjp, and codecvt-utf8.cpp. Let me know your thoughts. Martin
[jira] Commented: (STDCXX-353) [Cygwin] localedef errors: UCS value of symbolic character out of range
[ https://issues.apache.org/jira/browse/STDCXX-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506980 ] Martin Sebor commented on STDCXX-353: - So it sounds like the original issue is resolved and can be closed and we should open a new one for the errors you discovered. [Cygwin] localedef errors: UCS value of symbolic character out of range --- Key: STDCXX-353 URL: https://issues.apache.org/jira/browse/STDCXX-353 Project: C++ Standard Library Issue Type: Bug Components: Locales Affects Versions: 4.1.3 Environment: Cygwin Reporter: Mark Brown Assignee: Farid Zaripov On Cygwin, locale successfully builds all locales except zh_CN.GB18030 and zh_TW.EUC-TW: $ nice make -C../bin locales -k make: Entering directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/GB18030 -i /home/mbrown/stdcxx/etc/nls/src/zh_CN /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_CN.GB18030 Error 315: UCS value 66304 of symbolic character U00010300 out of range. make: *** [zh_CN.GB18030] Error 4 ./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/EUC-TW -i /home/mbrown/stdcxx/etc/nls/src/zh_TW /home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_TW.EUC-TW Error 315: UCS value 131083 of symbolic character U0002000B out of range. make: *** [zh_TW.EUC-TW] Error 4 make: Target `locales' not remade because of errors. make: Leaving directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-293) __rw::__rw_throw(): operator delete[] called without corresponding operator new[] call
[
https://issues.apache.org/jira/browse/STDCXX-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov reassigned STDCXX-293:
Assignee: Farid Zaripov
__rw::__rw_throw(): operator delete[] called without corresponding operator
new[] call
--
Key: STDCXX-293
URL: https://issues.apache.org/jira/browse/STDCXX-293
Project: C++ Standard Library
Issue Type: Bug
Components: 18. Language Support, 19. Diagnostics
Affects Versions: 4.1.3
Environment: All
Reporter: Farid Zaripov
Assignee: Farid Zaripov
The test below fails:
---
#include cstddef // for std::size_t
#include assert.h // for assert
#include rw/_error.h // for __rw_throw_proc,
_RWSTD_ERROR_LOCALE_BAD_CAT
void* operator new[] (std::size_t)
{
assert (!operator new[] unexpectedly called);
return 0;
}
void operator delete[] (void*)
{
assert (!operator delete[] called without operator new[]);
}
int main ()
{
__rw::__rw_throw (_RWSTD_ERROR_LOCALE_BAD_CAT + 1, __FILE__, main);
return 0;
}
---
Assertion failed: !operator delete[] called without operator new[], file
.\tes
t.cpp, line 13
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
---
The details are here:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200609.mbox/[EMAIL
PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-452) std::numpunct not thread safe
std::numpunct not thread safe
-
Key: STDCXX-452
URL: https://issues.apache.org/jira/browse/STDCXX-452
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.2
Environment: all
Reporter: Martin Sebor
Priority: Blocker
Attachments: 22.locale.numpunct.mt.html
The 22.locale.numpunct.mt thread safety tests aborts at runtime indicating that
there is a thread safety issue in the locale implementation. Running the test
through the Intel Thread Checker reveals possible causes of the problem.
$ tcheck_cl -v make 22.locale.numpunct.mt tcheck_cl -f html -o
22.locale.numpunct.mt ./22.locale.numpunct.mt --nthreads=2 --nloops=1000
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
make: `22.locale.numpunct.mt' is up to date.
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Running: /build/sebor/stdcxx-icc-9.1_049-15S/tests/22.locale.numpunct.mt
--nthreads=2 --nloops=1000
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: Intel C++, __INTEL_COMPILER = 910, __INTEL_COMPILER_BUILD_DATE =
20070320, __EDG_VERSION__ = 306
# ENVIRONMENT: x86_64/LP64 running linux-elf 2.4.20 with glibc 2.3
# FILE: 22.locale.numpunct.mt.cpp
# COMPILED: Jun 13 2007, 14:05:31
# COMMENT: thread safety
# CLAUSE: lib.locale.numpunct
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-FZLyTh
# CLAUSE: lib.locale.numpunct
# FILE: process.cpp
# LINE: 274
# INFO (S1) (3 lines):
# TEXT: testing std::numpunctcharT with 2 threads, 1000 iterations each, in
locales { aa_DJ aa_DJ.iso88591 aa_DJ.utf8 aa_ER [EMAIL PROTECTED]
aa_ER.utf8 [EMAIL PROTECTED] 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 ar_IQ }
# CLAUSE: lib.locale.numpunct
# INFO (S1) (3 lines):
# TEXT: exercising std::numpunctchar
# CLAUSE: lib.locale.numpunct
/amd/devco/sebor/stdcxx/tests/localization/22.locale.numpunct.mt.cpp:128: void
*thread_func(void *): Assertion '0 == rw_strncmp (fn.c_str (),
data-falsename_)' failed.
/build/sebor/stdcxx-icc-9.1_049-15S/tests/./22.locale.numpunct.mt[0x8ad9fc]
Application finished
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-452) std::numpunct not thread safe
[
https://issues.apache.org/jira/browse/STDCXX-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-452:
Affects Version/s: 4.1.3
std::numpunct not thread safe
-
Key: STDCXX-452
URL: https://issues.apache.org/jira/browse/STDCXX-452
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.3, 4.1.2
Environment: all
Reporter: Martin Sebor
Priority: Blocker
Attachments: 22.locale.numpunct.mt.html
The 22.locale.numpunct.mt thread safety tests aborts at runtime indicating
that there is a thread safety issue in the locale implementation. Running the
test through the Intel Thread Checker reveals possible causes of the problem.
$ tcheck_cl -v make 22.locale.numpunct.mt tcheck_cl -f html -o
22.locale.numpunct.mt ./22.locale.numpunct.mt --nthreads=2 --nloops=1000
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
make: `22.locale.numpunct.mt' is up to date.
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Running: /build/sebor/stdcxx-icc-9.1_049-15S/tests/22.locale.numpunct.mt
--nthreads=2 --nloops=1000
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: Intel C++, __INTEL_COMPILER = 910, __INTEL_COMPILER_BUILD_DATE =
20070320, __EDG_VERSION__ = 306
# ENVIRONMENT: x86_64/LP64 running linux-elf 2.4.20 with glibc 2.3
# FILE: 22.locale.numpunct.mt.cpp
# COMPILED: Jun 13 2007, 14:05:31
# COMMENT: thread safety
# CLAUSE: lib.locale.numpunct
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-FZLyTh
# CLAUSE: lib.locale.numpunct
# FILE: process.cpp
# LINE: 274
# INFO (S1) (3 lines):
# TEXT: testing std::numpunctcharT with 2 threads, 1000 iterations each, in
locales { aa_DJ aa_DJ.iso88591 aa_DJ.utf8 aa_ER [EMAIL PROTECTED]
aa_ER.utf8 [EMAIL PROTECTED] 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 ar_IQ }
# CLAUSE: lib.locale.numpunct
# INFO (S1) (3 lines):
# TEXT: exercising std::numpunctchar
# CLAUSE: lib.locale.numpunct
/amd/devco/sebor/stdcxx/tests/localization/22.locale.numpunct.mt.cpp:128:
void *thread_func(void *): Assertion '0 == rw_strncmp (fn.c_str (),
data-falsename_)' failed.
/build/sebor/stdcxx-icc-9.1_049-15S/tests/./22.locale.numpunct.mt[0x8ad9fc]
Application finished
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-453) std::moneypunct not thread safe
std::moneypunct not thread safe
---
Key: STDCXX-453
URL: https://issues.apache.org/jira/browse/STDCXX-453
Project: C++ Standard Library
Issue Type: Bug
Components: 22. Localization
Affects Versions: 4.1.3
Reporter: Martin Sebor
Priority: Critical
Attachments: 22.locale.moneypunct.mt.html
The 22.locale.moneypunct.mt thread safety tests aborts at runtime indicating
that there is a thread safety issue in the locale implementation. Running the
test through the Intel Thread Checker reveals possible causes of the problem.
$ tcheck_cl -v make 22.locale.moneypunct.mt tcheck_cl -f html -o
22.locale.moneypunct.mt ./22.locale.moneypunct.mt --nthreads=2 --nloops=1000
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
icc -cxxlib-nostd -g -w1 -I/amd/devco/sebor/stdcxx/include/ansi
-D_RWSTDDEBUG -D_REENTRANT -I/amd/devco/sebor/stdcxx/include
-I/build/sebor/stdcxx-icc-9.1_049-15S/include
-I/amd/devco/sebor/stdcxx/tests/include
-L/build/sebor/stdcxx-icc-9.1_049-15S/rwtest -lrwtest15S -cxxlib-nostd
-lpthread -L/build/sebor/stdcxx-icc-9.1_049-15S/lib
/amd/devco/sebor/stdcxx/tests/localization/22.locale.moneypunct.mt.cpp
/build/sebor/stdcxx-icc-9.1_049-15S/lib/libstd15S.a
/build/sebor/stdcxx-icc-9.1_049-15S/rwtest/librwtest15S.a -lstd15S -lcxaguard
-lsupc++ -lm -o 22.locale.moneypunct.mt
Intel(R) Thread Checker 3.1 command line instrumentation driver (24400)
Copyright (c) 2007 Intel Corporation. All rights reserved.
Building project
Instrumenting
11% 22.locale.moneypunct.mt ( All Functions
):
.
33% libc-2.3.4.so ( Minimal ):
44% libcxaguard.so.5 ( Minimal ):..
55% libdl-2.3.4.so ( Minimal ):..
66% libgcc_s-3.4.6-20060404.so.1 ( Minimal ):..
77% libimf.so ( Minimal ):
88% libm-2.3.4.so ( Minimal ):..
100% libpthread-2.3.4.so ( Minimal ):..
Running: /build/sebor/stdcxx-icc-9.1_049-15S/tests/22.locale.moneypunct.mt
--nthreads=2 --nloops=1000
# INFO (S1) (10 lines):
# TEXT:
# COMPILER: Intel C++, __INTEL_COMPILER = 910, __INTEL_COMPILER_BUILD_DATE =
20070320, __EDG_VERSION__ = 306
# ENVIRONMENT: x86_64/LP64 running linux-elf 2.4.20 with glibc 2.3
# FILE: 22.locale.moneypunct.mt.cpp
# COMPILED: Jun 13 2007, 14:05:31
# COMMENT: thread safety
# CLAUSE: lib.locale.moneypunct
# NOTE (S2) (5 lines):
# TEXT: executing locale -a /tmp/tmpfile-EUSjge
# CLAUSE: lib.locale.moneypunct
# FILE: process.cpp
# LINE: 274
# INFO (S1) (3 lines):
# TEXT: testing std::moneypunctcharT with 2 threads, 1000 iterations each, in
locales { aa_DJ aa_DJ.iso88591 aa_DJ.utf8 aa_ER [EMAIL PROTECTED]
aa_ER.utf8 [EMAIL PROTECTED] 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 ar_IQ }
# CLAUSE: lib.locale.moneypunct
# INFO (S1) (3 lines):
# TEXT: exercising std::moneypunctchar
# CLAUSE: lib.locale.moneypunct
/amd/devco/sebor/stdcxx/tests/localization/22.locale.moneypunct.mt.cpp:167:
void *thread_func(void *): Assertion 'fd == data-frac_digits_' failed.
/amd/devco/sebor/stdcxx/tests/localization/22.locale.moneypunct.mt.cpp:167:
void *thread_func(void *): Assertion 'fd == data-frac_digits_' failed.
/build/sebor/stdcxx-icc-9.1_049-15S/tests/./22.locale.moneypunct.mt[0x/build/sebor/stdcxx-icc-9.1_049-15S/tests/./22.locale.moneypunct.mt[0x8b9470]
8b9470]
Application finished
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
STDCXX progress to graduation
[How's that for optimism? please not corrected stdcxx-dev list address] I'm including general in this thread to give the incubator community some small insight into stdcxx's efforts and next steps to graduate. As far as I can see there are no remaining obstacles. http://incubator.apache.org/stdcxx/ is of a caliber higher than expected in open source efforts, the new steady contributors are recognized quickly with commit access (and later then with 'PMC membership' in the form of their PPMC), and diversity is increasing (we wish it were broader, but I suspect this project with the visibility of full ASF status will attract additional committers who might have been hedging their bets on whether or not the project would survive incubation.) It's survived, the community appears healthy - most code-discussion occurs in the actual jira incidents that the discussion applies to, and things are as quiet as expected for a mature implementation of a reference standard. Even issues raised by board/IPMC have been addressed quickly and sufficiently. (The issue with two-classes of CTR and RTC committers is resolved, while The Committers in italics do not have a signed Contributor License Agreement on file. comment does not and will not become applicable, and can be removed the next time that file is touched.) If anyone has concerns about stdcxx's graduation, please share them with the [EMAIL PROTECTED] community. Bill
RE: STDCXX progress to graduation
William A. Rowe, Jr. wrote: diversity is increasing (we wish it were broader, but I suspect this project with the visibility of full ASF status will attract additional committers who might have been hedging their bets on whether or not the project would survive incubation.) What effect do you believe GPLv3 will have, now that the FSF is acknowledging that GPL projects may freely take advantage of Apache Licensed code? things are as quiet as expected for a mature implementation of a reference standard. Any concern that because of the maturity, it could stagnate and lose community? --- Noel
Re: svn commit: r549586 - /incubator/stdcxx/trunk/src/exception.cpp
Hi Farid, As you astutely observed in a previous discussion of the issue (at the link below), __rw_free_what_buf() should be extern _RWSTD_EXPORT, to be accessible by user in overridden __rw_throw_proc() otherwise there will be no way for users to avoid a leak in their replacement __rw_throw_proc(). http://www.mail-archive.com/stdcxx-dev@incubator.apache.org/msg02192.html Also, while it's too late to fix it for this commit, the ChangeLog entry is missing a reference to the Jira issue number it resolves. Please remember to include it future changes, especially those to the library. Thanks Martin [EMAIL PROTECTED] wrote: Author: faridz Date: Thu Jun 21 11:51:41 2007 New Revision: 549586 URL: http://svn.apache.org/viewvc?view=revrev=549586 Log: 2007-06-21 Farid Zaripov [EMAIL PROTECTED] * exception.cpp (__rw_throw): Don't delete allocated what string because of __rw_throw_proc() takes ownership and must delete what string. Modified: incubator/stdcxx/trunk/src/exception.cpp Modified: incubator/stdcxx/trunk/src/exception.cpp URL: http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/exception.cpp?view=diffrev=549586r1=549585r2=549586 == --- incubator/stdcxx/trunk/src/exception.cpp (original) +++ incubator/stdcxx/trunk/src/exception.cpp Thu Jun 21 11:51:41 2007 @@ -827,9 +827,6 @@ // throw_proc takes ownership of allocated string __rw_throw_proc (id, what); - -// if throw_proc returns, delete allocated what string -__rw_free_what_buf (what); } }
Re: STDCXX progress to graduation
Noel J. Bergman wrote: William A. Rowe, Jr. wrote: diversity is increasing (we wish it were broader, but I suspect this project with the visibility of full ASF status will attract additional committers who might have been hedging their bets on whether or not the project would survive incubation.) What effect do you believe GPLv3 will have, now that the FSF is acknowledging that GPL projects may freely take advantage of Apache Licensed code? I suspect most GPL authors already felt quite free to combine and ship AL code in their GPL developer toolchains, when useful. Most J2 stacks haven't bothered to replace every .jar, they consume AL libraries when it suits their purpose. It would be really cool to see some of the FLOSS C++ groups to both consume and contribute to stdcxx, we'll see what happens. As far as other packagers blending proprietary and open source solutions, the very nature of an 'incubating' ASF project says we don't yet give it our full confidence, so a packager is behind the curve to rely on any project until it's graduated. We'll learn what the real delta is some year after stdcxx has graduated. things are as quiet as expected for a mature implementation of a reference standard. Any concern that because of the maturity, it could stagnate and lose community? Not at this time. Because it is widely deployed, there will be a long term demand. Because it's transparent to the developer, and in debugging their apps they can drill right into flaws within stdcxx, I suspect we will see bug feedback folks turn patchers turn contributors turn project members for years, as long as C++ is a widely adopted language. Bill
Re: svn commit: r548112 - /incubator/stdcxx/trunk/tests/support/18.exception.cpp
Farid Zaripov wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 12:11 AM To: [EMAIL PROTECTED] Subject: svn commit: r548112 - /incubator/stdcxx/trunk/tests/support/18.exception.cpp Author: sebor Date: Sun Jun 17 14:10:51 2007 New Revision: 548112 [...] The test fails to compile on MSVC after that patch. The proposed patch below: Darn! The #else branch is of course wrong. It should have been what you said. Sorry about that. Passing SIGABRT as the second argument to sigsetjmp() doesn't make sense since it's treated as just a Boolean flag so I also agree with that change. I see I messed up in all kinds of ways here... Martin Index: 18.exception.cpp === --- 18.exception.cpp(revision 549121) +++ 18.exception.cpp(working copy) @@ -57,14 +57,18 @@ # include setjmp.h// for siglongjmp(), sigsetjmp() # define RW_JMP_BUF jmp_buf -# define RW_SETJMP(env) sigsetjmp (env, SIGABRT) +# define RW_SETJMP(env) sigsetjmp (env, 0) # define RW_LONGJMP(env, val) siglongjmp (env, val) #else // if !defined (_RWSTD_OS_LINUX) # include csetjmp// for longjmp(), setjmp() # define RW_JMP_BUF std::jmp_buf -# define RW_SETJMP(env) std::sigsetjmp (env, SIGABRT) -# define RW_LONGJMP(env, val) std::siglongjmp (env, val) +# ifdef setjmp +#define RW_SETJMP(env) setjmp (env) +# else +#define RW_SETJMP(env) std::setjmp (env) +# endif +# define RW_LONGJMP(env, val) std::longjmp (env, val) #endif // _RWSTD_OS_LINUX /*** ***/ #ifdef setjmp is needed because of setjmp defined as macro on MSVC. Or even better would be #include setjmp.h instead of csetjmp and don't use the namespace std. Farid.
Re: Windows build error(s)
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Saturday, June 16, 2007 7:44 PM To: stdcxx-dev@incubator.apache.org Subject: Windows build error(s) Looks like we're having some problems in Intel C++ builds on Windows (see the error below). Farid, do you know about this? [...] ### Building solution / Creating HTML log Solution build script Checking arguments... Loading solution... D:\bman5\builds\33687223\source-buildspace\etc\config\windows\ build.wsf(226, 10) (null): Call was rejected by callee. I've found how to handle this error here: http://msdn2.microsoft.com/en-us/library/ms228772(vs.80).aspx Unfortunately, jscript don't present the possibility to install COM message filter, so I've just perform the call in a loop with sleep: http://svn.apache.org/viewvc?view=revrev=548682 This looks like an infinite loop. It might fix the problem with the build but I worry that it could cause trouble under some other error conditions. The MSDN fix also looks quite different (not to mention much more complicated). Isn't there some middle ground between the two approaches? E.g., could we loop only a limited number of times and only when the error was caused by the timing issue discussed on the MSDN page (if we can reliably detect it)? Martin
Re: svn commit: r548112 - /incubator/stdcxx/trunk/tests/support/18.exception.cpp
Since this was my mess I decided to go ahead and apply your patch: http://svn.apache.org/viewvc?view=revrev=549653. Thanks! Martin Martin Sebor wrote: Farid Zaripov wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 18, 2007 12:11 AM To: [EMAIL PROTECTED] Subject: svn commit: r548112 - /incubator/stdcxx/trunk/tests/support/18.exception.cpp Author: sebor Date: Sun Jun 17 14:10:51 2007 New Revision: 548112 [...] The test fails to compile on MSVC after that patch. The proposed patch below: Darn! The #else branch is of course wrong. It should have been what you said. Sorry about that. Passing SIGABRT as the second argument to sigsetjmp() doesn't make sense since it's treated as just a Boolean flag so I also agree with that change. I see I messed up in all kinds of ways here... Martin Index: 18.exception.cpp === --- 18.exception.cpp(revision 549121) +++ 18.exception.cpp(working copy) @@ -57,14 +57,18 @@ # include setjmp.h// for siglongjmp(), sigsetjmp() # define RW_JMP_BUF jmp_buf -# define RW_SETJMP(env) sigsetjmp (env, SIGABRT) +# define RW_SETJMP(env) sigsetjmp (env, 0) # define RW_LONGJMP(env, val) siglongjmp (env, val) #else // if !defined (_RWSTD_OS_LINUX) # include csetjmp// for longjmp(), setjmp() # define RW_JMP_BUF std::jmp_buf -# define RW_SETJMP(env) std::sigsetjmp (env, SIGABRT) -# define RW_LONGJMP(env, val) std::siglongjmp (env, val) +# ifdef setjmp +#define RW_SETJMP(env) setjmp (env) +# else +#define RW_SETJMP(env) std::setjmp (env) +# endif +# define RW_LONGJMP(env, val) std::longjmp (env, val) #endif // _RWSTD_OS_LINUX /*** ***/ #ifdef setjmp is needed because of setjmp defined as macro on MSVC. Or even better would be #include setjmp.h instead of csetjmp and don't use the namespace std. Farid.
