@Michael-O The issue(two errors in ForkModeIT) with commit e0bcffd05bb04001f97bf752de56bca7137da3e2 is caused by duplicate properties but it is not cause of that commit. I have found the root cause (reuseForks duplicates): -DforkMode=perthread *-DreuseForks=false -DreuseForks=true* -DthreadCount=1 I have the same tests failed as you had:
Failed tests: testForkModeOncePerThreadSingleThread(org.apache.maven.surefire.its.ForkModeIT): pid 1 didn't match pid 2 expected:<[19220]@SK-ZA-04278 testVal...> but was:<[23028]@SK-ZA-04278 testVal...> testForkModeOncePerThreadTwoThreads(org.apache.maven.surefire.its.ForkModeIT): number of different pids is not as expected expected:<2> but was:<3> We already prevented from this issue in the branch https://github.com/apache/maven-surefire/commits/SUREFIRE_SYSPROP_DUPLICATES but of course the old commits, like e0bcffd05, do not have this fix and therefore this issue come up. I will remove duplicates with system property "testNgVersion" in 17 POMs of our tests in the branch. On Thu, Feb 23, 2017 at 7:20 PM, Michael Osipov <micha...@apache.org> wrote: > So guys, > > I took a different approach to provide Tibor more information about the > failures. First of all, I added another platform for the test which is > exotic: HP-UX 11.31. The VM comes directly from HPE which is a repackaged > Oracle JVM. > > I started Git bisect and discovered some broken commits, e.g., > 9dd4074e83c0edae5e2050f66e9cadfdba40fe01 where less tests previously > fail, but doing a git revert of the offending commit does not resolve the > issue. After that I started a manual bisect going binary through commits > where I found that last known good commit > 502d18442113b4c6c72630dca5842e1eb287b8b0 > has a lower number of failures while the next commit > e0bcffd05bb04001f97bf752de56bca7137da3e2 introduced a regression from my > point of view, Tibor has a different opinion. > Going deeper I have compared the same debug logs between FreeBSD and HP-UX > and noticed that the consumer from the plugin is too greedy and declares > the forked VM as dead. I consider this as race conditions as well as stdio > issues not solvable w/o native code (I might be wrong). > > For those who would like to take a closer look at the results, see again > here: > > http://home.apache.org/~michaelo/ > >> maven-surefire-2.19.2-experimental.tar.gz >> maven-surefire-308d941c9b6ebb695aba9630f81fc5b400f21322-all-ITs.tar.gz >> maven-surefire-502d18442113b4c6c72630dca5842e1eb287b8b0.tar.gz >> maven-surefire-502d18442113b4c6c72630dca5842e1eb287b8b0-all-ITs.tar.gz >> maven-surefire-502d18442113b4c6c72630dca5842e1eb287b8b0-all- >> ITs-hp-ux.tar.gz >> maven-surefire-e0bcffd05bb04001f97bf752de56bca7137da3e2.tar.gz >> maven-surefire-e0bcffd05bb04001f97bf752de56bca7137da3e2-all-ITs.tar.gz >> maven-surefire-e0bcffd05bb04001f97bf752de56bca7137da3e2-all- >> ITs-hp-ux.tar.gz >> > > I consider several commits between Surefire 2.19.1 and master > broken/regressions. > > Tibor, feel free to add your comments and findings for everyone. Your > analysis is better than mine since your know the code better than I do. > > Michael > > PS: All build done with Maven master. I will switch to 3.5.0-alpha-1. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Cheers Tibor
