Direct mapped interface JVM crash

[davidhoyt]

I left a message in google groups about this: https://groups.google.com/forum/?fromgroups=#!topic/jna-users/zgNl4mvf3Co

Please see the attachment in that message for an example illustrating the problem.

[twall]

Please re-test with 3.6. I don't see any issues under vista64 and jdk 1.6.

[davidhoyt]

Still doesn't work w/ 3.6 under win7 (64-bit) and jdk 1.7u15 (64-bit).

[davidhoyt]

Are you using the provided example project from the google groups message?

[twall]

Yes, that's the code I was using, although I tweaked it a bit to run standalone.

On May 13, 2013, at 11:39 AM, David Hoyt wrote:

Are you using the provided example project from the google groups message?

—
Reply to this email directly or view it on GitHub.

[davidhoyt]

Are you leaving the process running? I've tested this on 2 different machines w/ Java 1.6 and 1.7 and it crashes every time. IE pops open and then if you leave it for about 10 seconds, the java process crashes.

[twall]

For me, opens about 5 windows; stays open while the java process exits. Will try win7 when I get a chance.

On May 14, 2013, at 12:00 AM, David Hoyt wrote:

Are you leaving the process running? I've tested this on 2 different machines w/ Java 1.6 and 1.7 and it crashes every time. IE pops open and then if you leave it for about 10 seconds, the java process crashes.

—
Reply to this email directly or view it on GitHub.

[davidhoyt]

It should open only 1 window. Are we sure we're talking about the same thing? Unless you have IE configured somehow to open up multiple windows when it launches (multiple tabs is certainly possible)...perhaps these are saved sites from previous runs (like how Chrome will re-open all windows if you didn't exit cleanly the last time it ran)?

How do you recommend I debug this?

[twall]

I'll take a closer look when I get a chance (including using win7). I don't normally use IE at all, when it opened up it launched several instances trying to read a web page I worked on several years ago :)

On May 14, 2013, at 12:27 PM, David Hoyt wrote:

It should open only 1 window. Are we sure we're talking about the same thing? Unless you have IE configured somehow to open up multiple windows when it launches (multiple tabs is certainly possible)...perhaps these are saved sites from previous runs (like how Chrome will re-open all windows if you didn't exit cleanly the last time it ran)?

How do you recommend I debug this?

—
Reply to this email directly or view it on GitHub.

[davidhoyt]

Okay -- thanks so much for your time, help, and consideration. Please let me know if there's anything I can provide or help with.

[davidhoyt]

Minor update -- it crashed for me w/ a fresh install of vista64:

[twall]

I'm definitely seeing different behavior between the interface and direct-mapped version, but I haven't been able to pinpoint the error. I sometimes get "resource not available in image" and some others that make no sense to me.

For me the direct-mapped version launches and returns immediately (apparently the "crash" isn't caught).

Can you reproduce with a simpler x86-launched program?

On May 14, 2013, at 7:07 PM, David Hoyt wrote:

Minor update -- it crashed for me w/ a fresh install of vista64:

—
Reply to this email directly or view it on GitHub.

[davidhoyt]

Ah -- I think I added a 30-second sleep to ensure it didn't exit before it crashed.

I can reproduce it w/ every x86 program I launch. I've tried several.

Interestingly, I re-compiled the x86_64 version of the native lib using gcc, and then I use that instead of the stock one provided upstream (in the repo.). Mine was compiled w/ gcc 4.5.2. And it doesn't crash anymore.

Some other observations I've made...I removed the "throws LastErrorException" from CreateProcess() and it actually returns successful! However, the second I re-add the "throws LastErrorException" I get the same "resource not available in image" error. Presumably adding that statement induces an error somewhere b/t the actual native CreateProcess() call and whatever's used to detect and throw the exception. If I simply rely on the boolean returned by CreateProcess() to indicate success and then use Native.getLastError() (coupled w/ FormatMessage() to get the system error message), I can get things to behave as expected.

The code looks like:

final boolean success = CreateProcess(null, command_line, null, null, true, new DWORD(NORMAL_PRIORITY_CLASS | CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT), env_vars /* environment block */, null /* current dir */, startup_info, proc_info) != 0;
if (!success) {
  int error = Native.getLastError();
  throw new IllegalStateException("Unable to create process: [" + error + "] " + SystemMessageForErrorCode(error));
}

...

public static String SystemMessageForErrorCode(int error) {
  PointerByReference lpBuffer = new PointerByReference();

  int num_of_chars = FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_MAX_WIDTH_MASK, null, error, 0, lpBuffer, 80, null);
  if (num_of_chars <= 0)
    throw new IllegalStateException("Unable to determine the error message for error code [" + error + "]");

  Pointer ptr_buffer = lpBuffer.getValue();
  String message = new String(ptr_buffer.getCharArray(0, num_of_chars));

  LocalFree(ptr_buffer);

  return message;
}

(I'd actually appreciate any critique and suggestions for that SystemMessageForErrorCode() method).

Again all the above only works once I recompiled everything using my own environment/tools.

[twall]

That's useful. I think there may be several bits where things aren't quite appropriately cast/extended to fit in registers.

[twall]

There exists a Kernel32Utils.formatMessageFromLastErrorCode(int code), which is pretty much the same thing LastErrorException does on the native side.

[twall]

There's likely an error with the LastErrorException string generation; maybe the format function is what's causing the "resource not available" error. Thanks for helping pin it down.

[twall]

Fixed in 16d4db1. snprintf is broken on windows, and the LastErrorException was triggering a buffer overrun which would crash on win64.