Currently there is another issue. Events from plugin don't arrive to forked jvm. I have placed more logs. We will run the ITs again with Michael tomorrow. I open to check logs in the morning and in the evening. The Version 2.19.1 has these issues as well. So it is not a regression. We have to continue with release of surefire because the Ubuntu tests pass same as it was with previous versions. The other build process based on Jenkinsfile is different story where only some text is not found in logs. I will have a look, but still this does not mean that we have to stop cut release new version of Surefire. The users are sending me emails one by one and they are getting really nervous. So we have to make a release and later we will finish fix for FreeBSD. I am still facing native problem with reliably streaming data over standard output streams with subprocess. We with Kristian Roselvold were thinking of introducing extensions for Surefire in Version 3.0. It seems we will do it in 2.x but not in this version because we are already running one year without release.
On Sun, Feb 19, 2017 at 10:23 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Especially as we know the forked money should *exit before* the main > process, so we should be able to flush the ACK... > > The timeout would just be a fallback to prevent zombies > > On Sun 19 Feb 2017 at 21:09, Michael Osipov <micha...@apache.org> wrote: > > > I made this proposal to Tibor too. The forked VM sends the Z, waits for > > an ACK and then exits. This should be idiot proof. > > > > Am 2017-02-19 um 22:04 schrieb Stephen Connolly: > > > Can we invert the sequence? > > > > > > The forked process sends a Z > > > > > > Then the controller sends back an ACK of some sort. If the forked > process > > > hasn't received the ACK say 5s after sending the Z is just says screw > it > > > and does an exit? > > > On Sun 19 Feb 2017 at 20:34, Christian Schulte <c...@schulte.it> wrote: > > > > > >> Am 19.02.2017 um 21:10 schrieb Michael Osipov: > > >>> Am 2017-02-19 um 19:54 schrieb Christian Schulte: > > >>>> Am 02/19/17 um 19:52 schrieb Christian Schulte: > > >>>>> Am 02/19/17 um 19:47 schrieb Christian Schulte: > > >>>>>> Am 02/19/17 um 13:06 schrieb Michael Osipov: > > >>>>>>> Socket give you, of course, a lot of control, but they also > impose > > an > > >>>>>>> overhead compares to named pipes (mkfifo, CreateNamePipe). > > >>>>>>> > > >>>>>>> I think our biggest problem is that stdout is subject to > buffering > > >>>>>>> issues and in case if System#exit() status Z is the buffer, never > > >>>>>>> written out. > > >>>>>>> Surefire thinks that the crashed. > > >>>>>> > > >>>>>> Not sure I understand the issue at hand completely. If the code > > >> calling > > >>>>>> "exit" is in Surefire and the code consuming the stdout/stderr > > streams > > >>>>>> also is in Surefire, there is a solution to this. Can we just > close > > >> the > > >>>>>> stdio streams before calling exit? Would that be possible? Just > add > > >>>>>> System.out.close(), System.err.close() and System.in.close() > before > > >> the > > >>>>>> call to System.exit(). This could solve it. Will look up posix > > >>>>>> documentation on this now. We maybe are just running into an issue > > >> where > > >>>>>> the BSDs get it right and others are not strictly posix compliant. > > >>>>>> Getting someone to test this on OSX would be interesting (kernel > or > > >>>>>> userland issue). This could even be a bug in the VM (not platform > > >>>>>> independent). > > >>>>>> > > >>>>>> Regards, > > >>>>>> > > >>>>> > > >>>>> Quoting from here: > > >>>>> > > >>>>> <http://man.openbsd.org/OpenBSD-current/man3/stdio.3> > > >>>>> > > >>>>> "A file is disassociated from a stream by “closing” it. Output > > streams > > >>>>> are flushed (any unwritten buffer contents are transferred to the > > host > > >>>>> environment) before the stream is disassociated from the file." > > >>>>> > > >>>>> BUGs section has a hint about buffering as well. > > >>>>> > > >>>>> Regards, > > >>>>> > > >>>> > > >>>> Well. It's mentioned there explicitly: > > >>>> > > >>>> "If the main function returns to its original caller, or the exit(3) > > >>>> function is called, all open files are closed (hence all output > > streams > > >>>> are flushed) before program termination. Other methods of program > > >>>> termination may not close files properly and hence buffered output > may > > >>>> be lost. In particular, _exit(2) does not flush stdio files. Neither > > >>>> does an exit due to a signal. Buffers are flushed by abort(3), as > > >>>> required by POSIX, although in previous implementations they were > > not." > > >>> > > >>> This is the same content as for FreeBSD and I think this is likely > the > > >>> case here. BSDs strictly adhere to the standards, other > implementations > > >>> like GNU/Linux might be sloppier. > > >>> > > >>> Using stderr could be a solution. At best, we would have > setbuf(STDOUT, > > >>> NULL) from without Java, but this requires native code :-( > > >> > > >> The buffering of System.in/out/err is controlled solely by the OS and > > >> the VM does not do anything to make this behave consistently across > > >> OSes? The VM isn't platform independent in that area then. If you can > > >> present a native solution on how to make the VM more platform > > >> independent in that area, time to file a bug against the JDK > > >> <https://bugs.openjdk.java.net>, IMHO. Does not solve our issue now, > > >> though. Means we need to find a solution for Surefire which is > neither a > > >> hack nor a workaround which will hit us again in the future. Maybe > > >> System.in/out/err cannot be used reliably for what we are using it > for. > > >> > > >> Regards, > > >> -- > > >> Christian > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > >> > > >> -- > > > Sent from my phone > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- > Sent from my phone > -- Cheers Tibor
