[jira] [Commented] (XERCESC-2152) Wrong value for XERCES_SIZE_T in XercesIntTypes.cmake
[ https://issues.apache.org/jira/browse/XERCESC-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610182#comment-16610182 ] Volo Zyko commented on XERCESC-2152: Another note: yesterday I've encountered more legitimate case when I got {{XERCES_SIZE_T=unsigned long}}. Again when cross compiling for iOS. If I pass to cmake {{"-DCMAKE_CXX_FLAGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk -arch armv7 -arch arm64 -miphoneos-version-min=10.0"}} then {{SIZEOF_SIZE_T}} in XercesIntTypes.cmake is {{0}}. I think this happens because on armv7 {{sizeof(size_t) == 4}} and on arm64 {{sizeof(size_t) == 8}} and cmake gets confused. So, is this really necessary detecting types' sizes (for other types too) at build configuration time? Probably more important is to check whether a given type is present on the target platform but checking for its size should be done at compile time, I think. > Wrong value for XERCES_SIZE_T in XercesIntTypes.cmake > - > > Key: XERCESC-2152 > URL: https://issues.apache.org/jira/browse/XERCESC-2152 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.1 >Reporter: Volo Zyko >Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.2 > > > In the line {{set(XERCES_SIZE_T unsigned long)}} the value should be quoted, > otherwise cmake incorrectly inserts it as {{#define XERCES_SIZE_T > unsigned;long}} to InstalXerces_autoconf_config.hpp -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2153) Tests can fail on Windows when run in parallel
Roger Leigh created XERCESC-2153: Summary: Tests can fail on Windows when run in parallel Key: XERCESC-2153 URL: https://issues.apache.org/jira/browse/XERCESC-2153 Project: Xerces-C++ Issue Type: Improvement Components: Samples/Tests Affects Versions: 3.2.1 Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 prerelease. Reporter: Roger Leigh Assignee: Roger Leigh Tests always pass when run serially, so I don't see this as a blocker for 3.2.2 unless it's indicative of a very long-standing problem internally in Xerces rather than that the tests were not originally written with parallel execution in mind. When running "ctest -jn" to run tests in parallel, tests can randomly fail. Looks like an interaction between tests when run at the same time. Some resource contention? The following is a reduced testcase, where I've found two tests which interact badly (there may be others). Both are using personal.xml as input. {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}} {{Test project D:/xerces-c-3.2.2/b}} {{ Start 66: DOMPrint3}} {{ Start 70: StdInParse2}} {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}} {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 sec}}{{The following tests FAILED:}} {{ 66 - DOMPrint3 (Failed)}} {{Errors while running CTest}} I can't reproduce on Linux, so it may well be Windows-specific due to file locking preventing multiple readers of a file? Is it due to one process having it held open on stdin while the other tries to open it. Running multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not result in failure. But when the two are combined, it's always DOMPrint that fails; is it the open mode being used? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Making a 3.2.2 release
On 11/09/18 00:17, Cantor, Scott wrote: Didn't get to it until tonight. https://dist.apache.org/repos/dist/dev/xerces/c/3/sources/ If that looks good, I'll call for a vote tomorrow. I found a missing file which wasn't included in EXTRA_DIST, which broke building on Windows from the release zip (version.rc.cmake.in). I've included it, tested locally with VS2017, and commited to SVN. If you could recreate the dev release files, I'll retest again. Regards, Roger - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2153) Tests can fail on Windows when run in parallel
[ https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610530#comment-16610530 ] Roger Leigh commented on XERCESC-2153: -- Putting some debug messages in WindowsFileMgr::fileOpen (called from BinFileInputStream from LocalFileInputSource), shows that the HRESULT is 0x80070020 (sharing violation) which meets the hypothesis above. The input file on stdin must be opened without FILE_SHARE_WRITE. This isn't a bug in Xerces-C++, it's due to the way the CMake execute_process function sets up pipes for STDIN with read and write access. I have created a ticket for that here which contains more details: https://gitlab.kitware.com/cmake/cmake/issues/18359 > Tests can fail on Windows when run in parallel > -- > > Key: XERCESC-2153 > URL: https://issues.apache.org/jira/browse/XERCESC-2153 > Project: Xerces-C++ > Issue Type: Improvement > Components: Samples/Tests >Affects Versions: 3.2.1 > Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 > prerelease. >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Minor > Labels: test-fail, windows > > Tests always pass when run serially, so I don't see this as a blocker for > 3.2.2 unless it's indicative of a very long-standing problem internally in > Xerces rather than that the tests were not originally written with parallel > execution in mind. > When running "ctest -jn" to run tests in parallel, tests can randomly fail. > Looks like an interaction between tests when run at the same time. Some > resource contention? > The following is a reduced testcase, where I've found two tests which > interact badly (there may be others). Both are using personal.xml as input. > {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}} > {{Test project D:/xerces-c-3.2.2/b}} > {{ Start 66: DOMPrint3}} > {{ Start 70: StdInParse2}} > {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}} > {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% > tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 > sec}}{{The following tests FAILED:}} > {{ 66 - DOMPrint3 (Failed)}} > {{Errors while running CTest}} > I can't reproduce on Linux, so it may well be Windows-specific due to file > locking preventing multiple readers of a file? Is it due to one process > having it held open on stdin while the other tries to open it. Running > multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not > result in failure. But when the two are combined, it's always DOMPrint that > fails; is it the open mode being used? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2153) Tests can fail on Windows when run in parallel
[ https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2153: - Issue Type: Wish (was: Improvement) > Tests can fail on Windows when run in parallel > -- > > Key: XERCESC-2153 > URL: https://issues.apache.org/jira/browse/XERCESC-2153 > Project: Xerces-C++ > Issue Type: Wish > Components: Samples/Tests >Affects Versions: 3.2.1 > Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 > prerelease. >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Minor > Labels: test-fail, windows > > Tests always pass when run serially, so I don't see this as a blocker for > 3.2.2 unless it's indicative of a very long-standing problem internally in > Xerces rather than that the tests were not originally written with parallel > execution in mind. > When running "ctest -jn" to run tests in parallel, tests can randomly fail. > Looks like an interaction between tests when run at the same time. Some > resource contention? > The following is a reduced testcase, where I've found two tests which > interact badly (there may be others). Both are using personal.xml as input. > {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}} > {{Test project D:/xerces-c-3.2.2/b}} > {{ Start 66: DOMPrint3}} > {{ Start 70: StdInParse2}} > {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}} > {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% > tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 > sec}}{{The following tests FAILED:}} > {{ 66 - DOMPrint3 (Failed)}} > {{Errors while running CTest}} > I can't reproduce on Linux, so it may well be Windows-specific due to file > locking preventing multiple readers of a file? Is it due to one process > having it held open on stdin while the other tries to open it. Running > multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not > result in failure. But when the two are combined, it's always DOMPrint that > fails; is it the open mode being used? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Making a 3.2.2 release
I've uploaded an RC2 build (named appropriately this time) for eval, same spot. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Speakers needed for Apache DC Roadshow
We need your help to make the Apache Washington DC Roadshow on Dec 4th a success. What do we need most? Speakers! We're bringing a unique DC flavor to this event by mixing Open Source Software with talks about Apache projects as well as OSS CyberSecurity, OSS in Government and and OSS Career advice. Please take a look at: http://www.apachecon.com/usroadshow18/ (Note: You are receiving this message because you are subscribed to one or more mailing lists at The Apache Software Foundation.) Rich, for the ApacheCon Planners -- rbo...@apache.org http://apachecon.com @ApacheCon - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2153) Tests can fail on Windows when run in parallel
[ https://issues.apache.org/jira/browse/XERCESC-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh closed XERCESC-2153. Resolution: Fixed Fix Version/s: 3.2.2 Fixed in SVN r1840586. Running StdIn tests serially avoids contention with other tests sharing the same input files. All the other tests can be run in parallel. > Tests can fail on Windows when run in parallel > -- > > Key: XERCESC-2153 > URL: https://issues.apache.org/jira/browse/XERCESC-2153 > Project: Xerces-C++ > Issue Type: Wish > Components: Samples/Tests >Affects Versions: 3.2.1 > Environment: Windows 10 x64 with VS2017 x64 build of Xerces-C++ 3.2.2 > prerelease. >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Minor > Labels: test-fail, windows > Fix For: 3.2.2 > > > Tests always pass when run serially, so I don't see this as a blocker for > 3.2.2 unless it's indicative of a very long-standing problem internally in > Xerces rather than that the tests were not originally written with parallel > execution in mind. > When running "ctest -jn" to run tests in parallel, tests can randomly fail. > Looks like an interaction between tests when run at the same time. Some > resource contention? > The following is a reduced testcase, where I've found two tests which > interact badly (there may be others). Both are using personal.xml as input. > {{D:\xerces-c-3.2.2\b>ctest -C Release -j 4 -R "DOMPrint3|StdInParse2"}} > {{Test project D:/xerces-c-3.2.2/b}} > {{ Start 66: DOMPrint3}} > {{ Start 70: StdInParse2}} > {{1/2 Test #66: DOMPrint3 ***Failed 0.07 sec}} > {{2/2 Test #70: StdInParse2 .. Passed 0.08 sec}}{{50% > tests passed, 1 tests failed out of 2}}{{Total Test time (real) = 0.11 > sec}}{{The following tests FAILED:}} > {{ 66 - DOMPrint3 (Failed)}} > {{Errors while running CTest}} > I can't reproduce on Linux, so it may well be Windows-specific due to file > locking preventing multiple readers of a file? Is it due to one process > having it held open on stdin while the other tries to open it. Running > multiple StdInParse[123] tests or multiple DOMPrint[123] tests does not > result in failure. But when the two are combined, it's always DOMPrint that > fails; is it the open mode being used? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Making a 3.2.2 release
On 11/09/18 15:38, Cantor, Scott wrote: I've uploaded an RC2 build (named appropriately this time) for eval, same spot. Thanks. I've given this one a test on Windows, and it's now building fine. I've also now been able to fix XERCESC-2153 which was minor but annoying. If you could possibly make an RC3 with this included, that should be the last thing from me for the release, and it should be ready to go. Thanks, Roger - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Making a 3.2.2 release
RC3 is now up. I'll wait a bit for any final checks and then call a vote. -- Scott
Re: Making a 3.2.2 release
On 11/09/18 17:26, Cantor, Scott wrote: RC3 is now up. I'll wait a bit for any final checks and then call a vote. Thanks. I've tested these with: Linux (Ubuntu 18.04) autotools / make (pass) cmake / make (pass) cmake / ninja(pass) Windows (10 x64, VS2017) cmake / ninja debug (pass) cmake / msbuild release (pass) cmake / msbuild debug (pass) Where a pass is building and passing all the tests. Tests also run in parallel across the board with no problems. All GPG signatures are OK as well. No problems seen on my side, so I think this rc3 is fine. Regards, Roger - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org