1

I have a problem with a Java (Eclipse RCP) application running on Window 64bit (The problem does not occur if the application runs with a 32bit JVM)

The problem also does not occur if the application is running in the debugger.

In the application debug output is made with System.err.print(...). If the application then does not run under debugger control, then the UI thread just randomly freezes.

I attached to the process with GDB and saw that the process hangs in the call of ZwWriteFile.

(gdb) where
#0  0x000000007745bdba in ntdll!ZwWriteFile () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#1  0x000007fefd3a1b3b in WriteFile () from /cygdrive/c/windows/system32/KERNELBASE.dll
#2  0x0000000077311f66 in WriteFile () from /cygdrive/c/windows/system32/kernel32.dll
#3  0x000000006651cb65 in java!handleRead () from /cygdrive/d/Programme/Razorcat/Shared/1.3/JRE_1.8/bin/java.dll
#4  0x000000006651c31e in java!JNI_OnLoad () from /cygdrive/d/Programme/Razorcat/Shared/1.3/JRE_1.8/bin/java.dll
#5  0x0000000066512dc9 in java!Java_java_io_FileOutputStream_writeBytes () from /cygdrive/d/Programme/Razorcat/Shared/1.3/JRE_1.8/bin/java.dll

(gdb) disass
Dump of assembler code for function ntdll!ZwWriteFile:
   0x000000007745bdb0 <+0>:     mov    %rcx,%r10
   0x000000007745bdb3 <+3>:     mov    $0x5,%eax
   0x000000007745bdb8 <+8>:     syscall
=> 0x000000007745bdba <+10>:    retq
   0x000000007745bdbb <+11>:    nopl   0x0(%rax,%rax,1)

Has anyone ever had such a problem? Is there a way (kernel debugger?) to investigate this problem more closely.

Below is the function (io_util_md.c) that calls the WriteFile Windows API function. Could be that Windows has a problem with overlapped IO at pseudo handles. (I guess the process has no standard handles when not running in the debugger)

static jint writeInternal(FD fd, const void *buf, jint len, jboolean append)
{
    BOOL result = 0;
    DWORD written = 0;
    HANDLE h = (HANDLE)fd;
    if (h != INVALID_HANDLE_VALUE) {
        OVERLAPPED ov;
        LPOVERLAPPED lpOv;
        if (append == JNI_TRUE) {
            ov.offset = (DWORD)0xFFFFFFFF;
            ov.OffsetHigh = (DWORD)0xFFFFFFFF;
            ov.hEvent = NULL;
            lpOv = &ov;
        } else {
            lpOv = NULL;
        }
        result = WriteFile(h, /* File handle to write */
                           buf, /* pointers to the buffers */
                           len, /* number of bytes to write */
                           &written, /* receives number of bytes written */
                           lpOv); /* overlapped struct */
    }
    if ((h == INVALID_HANDLE_VALUE) ||| (result == 0)) {
        return -1;
    }
    return (jint)written;
}
Der Appit
  • 329
  • 1
  • 2
  • 4
  • i almost sure that `ZwWriteFile` write to synchronous named pipe with not large enough (compare with write size) internal buffer - in this case write operation will block until the data is read from the pipe. so here question - why nobody read from another pipe side. way investigate this under debugger (not need kernel) of course exist. windows have no any problems with io. also in your case you have **not** overlapped io - this is never block. *I guess the process has no standard handles when not running in the debugger* - this is false. wrong guess – RbMm Mar 19 '18 at 13:55
  • Why do you think stdout/stderr are NamedPipes when starting a Windows application with GUI? Who should be the reader at the other end of the pipe? – Der Appit Mar 19 '18 at 14:43
  • because block on write - very strong feature of synchronous named pipe. however of course need look under debugger for say exactly. also here we definitely have not overlapped io (because overlapped io not block and always return immediately). – RbMm Mar 19 '18 at 14:56
  • *Who should be the reader at the other end of the pipe?* - usually parent process :) of course need look concrete case under debugger or have how minimum more info. anyway i almost on 100% sure that this is write to named pipe – RbMm Mar 19 '18 at 14:59

0 Answers0