Slim process dies without any error in log with FitNesse 20161106

[fhoeben]

I have a test, using Slim, which works with the previous version of 20160618. It also works with version 20161106 if I run it via jUnit using FitNesseRunner with Slim in-process. It does not work when started from the wiki (separate Java process for Slim), on Windows 7.

I just get a message that the communication with the Slim process was lost, and in the execution log I see no indication of what went wrong. The Slim process just seems to die, without any error output.
A part of the test is executed, the SuiteSetUp and SetUp, but Slim dies on the real test page.
I've placed logging (to standard error) in my fixture code and I see that in the output of my SetUp pages, but the constructor of the fixture of the first (script) table never seems to be called. So I assume something happens in the code between the wiki and the Slim process before my fixture is even created.

I have no clue what the cause is, but processes stopping without any indication of what went wrong are very annoying....

[fhoeben]

It turns out there was 'something' in the execution log. I found that the slim process died with exit code 98. Which I tracked in the source to mean that an exception occurred. Unfortunately the logging of the exception did not work (as I did not see that in the execution log).

When I configure the connection to the slim process to be done on a random free port (i.e. I added !define slim.port {0} to the root of my suite, where I also configure the test system to be slim). The test works again.

My conclusion is that something is going wrong with the 'pipe based' connection between FitNesse and Slim. And logging on exception at the level does not end up in the execution log.

[amolenaar]

Can we replay this scenario?

[fhoeben]

I haven't been able to make a short sample that shows the problem. I have encountered the problem in multiple test sets in my current projects. All tests only show the problem on Windows 7 when started from the wiki (i.e. not when run on a build server using the jUnit runner on Linux).
The problem goes away on downgrade of FitNesse or when I set the slim.port variable.

[fhoeben]

I just checked #995 is the same problem as this issue. Adding the !define slim.port {0} also fixed the problem with the euro symbol

[fhoeben]

On Windows 7, IBM JVM 7 64bit, or JRE 8 bundled with IntelliJ 2016.3, http://localhost:8001/FitNesse.SuiteAcceptanceTests.SuiteSlimTests.MultiByteCharsInSlim shows this problem.

Adding !define slim.port {0} to .FitNesse.SuiteAcceptanceTests.SuiteSlimTests fixes the problem and makes the test green.

[keetron]

Gonna do that right away on Saturday night so I wont have to remember until Monday...

[fhoeben]

I believe the problem comes from the new 'default usage of console input/output' to communicate between wiki and Slim. On Windows the console does not support Unicode, at least not by default (see for instance http://stackoverflow.com/questions/20386335/printing-out-unicode-from-java-code-issue-in-windows-console).
Maybe Slim should only use console on non-windows platforms (e.g. check via System.getProperty("os.name") or use Apache Commons' SystemUtils.IS_OS_WINDOWS), or wrap ome print writer/reader with explicit encoding around the console streams.

[amolenaar]

The Stackoverflow item suggested adding explicit encoding (in our case that would be UTF-8). The current implementation does not force file encoding on both ends. As an alternative we an URL-encode the whole lot.

I would prefer that over using a socket on windows and a pipe on unix.

[fhoeben]

Grr, unable to reproduce the problem on Windows 10. The multibyte test does cause stack traces in the console (when run from Edge), but the connection to Slim is not lost.

WARNING: Socket Exception at: 1480847312347 [Software caused connection abort: socket write error]
java.net.SocketException: Software caused connection abort: socket write error
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(Unknown Source)
        at java.net.SocketOutputStream.write(Unknown Source)
        at fitnesse.FitNesseExpediter.send(FitNesseExpediter.java:70)
        at fitnesse.http.ChunkedResponse.closeTrailer(ChunkedResponse.java:75)
        at fitnesse.http.ChunkedResponse.close(ChunkedResponse.java:82)
        at fitnesse.responders.run.SuiteResponder.closeHtmlResponse(SuiteResponder.java:362)
        at fitnesse.responders.run.SuiteResponder.doSending(SuiteResponder.java:125)
        at fitnesse.responders.ChunkingResponder.startSending(ChunkingResponder.java:74)
        at fitnesse.http.ChunkedResponse.sendTo(ChunkedResponse.java:27)
        at fitnesse.FitNesseExpediter.sendResponse(FitNesseExpediter.java:93)
        at fitnesse.FitNesseExpediter.run(FitNesseExpediter.java:59)
        at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.util.concurrent.FutureTask.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

Using the FitNesse version with my pull requests does not show the stack trace....