Issue Details (XML | Word | Printable)

Key: JNA-99
Type: Bug Bug
Status: Open Open
Priority: Blocker Blocker
Assignee: jna-issues
Reporter: jarekf
Votes: 1
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
jna

JNA crash in CallbackReference.createNativeCallback()

Created: 04/Jan/09 02:07 PM   Updated: 07/Feb/11 05:14 AM
Component/s: native
Affects Version/s: None
Fix Version/s: not determined

Time Tracking:
Not Specified

Environment:

Operating System: Windows XP
Platform: PC


Issuezilla Id: 99
Tags:
Participants: jarekf, jna-issues and twalljava


 Description  « Hide

It crashes on each start. Below is the stack trace:

#

  1. An unexpected error has been detected by HotSpot Virtual Machine:
    #
  2. EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c911e58, pid=5832, tid=4164
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.5.0_12-b04 mixed mode)
  4. Problematic frame:
  5. C [ntdll.dll+0x11e58]
    #

--------------- T H R E A D ---------------

Current thread (0x00b55dd0): JavaThread "main" [_thread_in_native, id=4164]

siginfo: ExceptionCode=0xc0000005, reading address 0x00000000

Registers:
EAX=0x3ba0b700, EBX=0x00b50000, ECX=0x00000000, EDX=0x3ba0b708
ESP=0x0012e6fc, EBP=0x0012e708, ESI=0x3ba0b6f8, EDI=0x3ba74000
EIP=0x7c911e58, EFLAGS=0x00010246

Top of Stack: (sp=0x0012e6fc)
0x0012e6fc: 00b50000 00000001 00b50004 0012e740
0x0012e70c: 7c918251 00000000 3ba74000 0012e734
0x0012e71c: 00000000 000000a7 00000000 00b50000
0x0012e72c: 0012e804 00db75c0 00000200 3b9f0000
0x0012e73c: 00000000 0012e970 7c911c76 03b50000
0x0012e74c: 00000538 00b55dd0 0000052c 33a0e250
0x0012e75c: 00b55dd0 0012e74c 0012f1cc 0012f1cc
0x0012e76c: 6d76d9a2 6d777a60 ffffffff 0012e848

Instructions: (pc=0x7c911e58)
0x7c911e48: 85 97 7a 03 00 8b 4e 0c 8d 46 08 8b 10 89 4d 08
0x7c911e58: 8b 09 3b 4a 04 89 55 0c 0f 85 9d 00 00 00 3b c8

Stack: [0x00030000,0x00130000), sp=0x0012e6fc, free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ntdll.dll+0x11e58]
C [ntdll.dll+0x18251]
C [ntdll.dll+0x11c76]
C [MSVCRT.dll+0x1c3c9]
C [MSVCRT.dll+0x1c3e7]
C [MSVCRT.dll+0x1c42e]
C [jna11294.tmp+0x86ad]
C [jna11294.tmp+0x28c4]
j
com.sun.jna.CallbackReference.createNativeCallback(Lcom/sun/jna/CallbackProxy;Ljava/lang/reflect/Method;[Ljava/lang/Class;Ljava/lang/Class;I)Lcom/sun/jna/Pointer;+0
j com.sun.jna.CallbackReference.<init>(Lcom/sun/jna/Callback;I)V+315
j
com.sun.jna.CallbackReference.getFunctionPointer(Lcom/sun/jna/Callback;)Lcom/sun/jna/Pointer;+75
j
com.sun.jna.Function.convertArgument([Ljava/lang/Object;ILjava/lang/reflect/Method;Lcom/sun/jna/TypeMapper;)Ljava/lang/Object;+202
J
com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;
v ~RuntimeStub::alignment_frame_return Runtime1 stub
j
com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+344
j
$Proxy0.EnumChildWindows(Lcom/sun/jna/examples/win32/W32API$HWND;Lcom/sun/jna/examples/win32/User32$WNDENUMPROC;Lcom/sun/jna/Pointer;)Z+24
j
com.proatech.jna.JNATools.getWindowInfo(Lcom/proatech/jna/JNATools$HwndWindow;)V+212
j
com.proatech.jna.JNATools.findHwndWindowByTitle(Ljava/lang/String;)Lcom/proatech/jna/JNATools$HwndWindow;+41
j com.proatech.bioera.elements14.impl.ApplicationPlayer.findApplication()V+16
j com.proatech.bioera.elements14.impl.ApplicationPlayer.start()V+16



twalljava added a comment - 04/Jan/09 05:27 PM

Please provide a standalone test case which exhibits this behavior.


jarekf added a comment - 04/Jan/09 05:51 PM

I can't provide a simple test case. This application has been working for months
and it started act like that just recently. When I was creating the bug report I
could repeat it each time, now it is occasional only. But I can still reproduce
it after a few attempts. If you want me to turn on some debugging and send you
log file I will be happy to do so.


twalljava added a comment - 04/Jan/09 06:43 PM

Including as much of the surrounding context would help (i.e. your callback
implementation and any of your code around this particular invocation.

It would be helpful to know the arguments passed in to the failing function and
how those compare to a successful call (from as close in the stack to the fault
as you can manage). Determine what's different between a successful call and a
failing one.


jarekf added a comment - 04/Jan/09 07:37 PM

I printed on console parameters passed to the function, they seem to be the same
in both cases (successful and failing), there are a lot of successful calls to
the same function before it finally fails.

The function which fails has this description:

boolean EnumChildWindows(HWND childHWnd, WNDENUMPROC lpEnumFunc, Pointer data);

The data structures (HWND and WNDENUMPROC) are unmodified (from the original
Win32 examples). The third parameter is always set to null.

It seem like the above function usually causes the crash, although it can also
happen during finalization, see below.

The problem is new to me, it has worked for many months and I have not touched
this part of the code for a long time.

#

  1. An unexpected error has been detected by HotSpot Virtual Machine:
    #
  2. EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c911e5a, pid=5472, tid=3340
    #
  3. Java VM: Java HotSpot(TM) Client VM (1.5.0_12-b04 mixed mode)
  4. Problematic frame:
  5. C [ntdll.dll+0x11e5a]
    #

--------------- T H R E A D ---------------

Current thread (0x00d63218): JavaThread "Finalizer" daemon [_thread_in_native,
id=3340]

siginfo: ExceptionCode=0xc0000005, reading address 0x00730077

Registers:
EAX=0x3bcf8dd8, EBX=0x00b50000, ECX=0x9d000000, EDX=0x00730073
ESP=0x3b3ef7c8, EBP=0x3b3ef7d4, ESI=0x3bcf8dd0, EDI=0x3bcf8df8
EIP=0x7c911e5a, EFLAGS=0x00010246

Top of Stack: (sp=0x3b3ef7c8)
0x3b3ef7c8: 00b50000 3bcf8df8 00000000 3b3ef8a8
0x3b3ef7d8: 7c910d5c 006f0069 3bcf8df8 3b3ef88c
0x3b3ef7e8: 00000000 00000000 3bcf8e00 00d63218
0x3b3ef7f8: 3d9d0000 0000000c 49221058 00b50178
0x3b3ef808: 7c91056d 49221060 49337ac8 3bcf8e28
0x3b3ef818: 3d9d0000 494c4008 49337ac0 4946bfa0
0x3b3ef828: 3b3ef86c 49503008 00d6a6c0 00000008
0x3b3ef838: 7c90e57c 49569ac8 00b50240 4946bfa8

Instructions: (pc=0x7c911e5a)
0x7c911e4a: 7a 03 00 8b 4e 0c 8d 46 08 8b 10 89 4d 08 8b 09
0x7c911e5a: 3b 4a 04 89 55 0c 0f 85 9d 00 00 00 3b c8 0f 85

Stack: [0x3b2f0000,0x3b3f0000), sp=0x3b3ef7c8, free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [ntdll.dll+0x11e5a]
C [ntdll.dll+0x10d5c]
C [MSVCRT.dll+0x1c2de]
C [jna36118.tmp+0x89d8]
C [jna36118.tmp+0x290a]
J com.sun.jna.CallbackReference.freeNativeCallback(J)V
J com.sun.jna.CallbackReference.finalize()V
v ~RuntimeStub::alignment_frame_return Runtime1 stub
v ~StubRoutines::call_stub
V [jvm.dll+0x87599]
V [jvm.dll+0xdfbb2]
V [jvm.dll+0x8746a]
V [jvm.dll+0x8ca2d]
C [java.dll+0x2006]
J java.lang.ref.Finalizer.runFinalizer()V
J java.lang.ref.Finalizer$FinalizerThread.run()V
v ~OSRAdapter
v ~StubRoutines::call_stub
V [jvm.dll+0x87599]
V [jvm.dll+0xdfbb2]
V [jvm.dll+0x8746a]
V [jvm.dll+0x871c7]
V [jvm.dll+0xa2048]
V [jvm.dll+0x1110d8]
V [jvm.dll+0x1110a6]
C [MSVCRT.dll+0x2a3b0]
C [kernel32.dll+0xb683]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J com.sun.jna.CallbackReference.freeNativeCallback(J)V
J com.sun.jna.CallbackReference.finalize()V
v ~RuntimeStub::alignment_frame_return Runtime1 stub
v ~StubRoutines::call_stub
J java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V
J java.lang.ref.Finalizer.runFinalizer()V
J java.lang.ref.Finalizer$FinalizerThread.run()V
v ~OSRAdapter
v ~StubRoutines::call_stub


twalljava added a comment - 05/Jan/09 08:18 AM

Check to ensure your callback isn't being prematurely GC'd.


jarekf added a comment - 05/Jan/09 09:40 AM

It is not, I did check it. It is set as a final property of the object which
calls the EnumChildWindows. I copy the relevant part of the class below. The
Win_User32 directly extends User32 from the JNA examples.

public final class JNATools {
public static class HwndWindow {
public final HWND hWnd;
public int x, y, width, height;
public String titleText, className;
public final ArrayList<HwndWindow> children = new ArrayList<HwndWindow>();
public final MyCallback callback = new MyCallback(children);

HwndWindow(HWND h) { hWnd = h; }

public HwndWindow findFirstByClass(String cname) {
if (cname.equals(className))
return this;

for (int i = 0; i < children.size(); i++) { HwndWindow w = children.get(i).findFirstByClass(cname); if (w != null) return w; }

return null;
}

}

public static class MyCallback implements Win_User32.WNDENUMPROC {
ArrayList<HwndWindow> list;
MyCallback(ArrayList<HwndWindow> ilist) { list = ilist; }

public boolean callback(HWND hWnd, Pointer data) { list.add(new HwndWindow(hWnd)); return true; }
}

public static void enumChildWindows(HWND hwnd, WNDENUMPROC proc) { //System.out.println("enumerating: param1=" + hwnd + " param2=" + proc); boolean ret = Win_User32.INSTANCE.EnumChildWindows(hwnd, proc, null); //System.out.println("enumerated: " + ret); }

public static void getWindowInfo(HwndWindow w) {
//Win_User32.INSTANCE.GetWindowInfo(hWnd, pwi)

RECT r = (RECT) RECT.newInstance(RECT.class);
Win_User32.INSTANCE.GetWindowRect(w.hWnd, r);
w.x = r.left;
w.y = r.top;
w.width = r.right - r.left;
w.height = r.bottom - r.top;

// Find all children
enumChildWindows(w.hWnd, w.callback);

byte n[] = new byte[255];
Win_User32.INSTANCE.GetWindowText(w.hWnd, n, n.length);
String s;
try { s = Native.toString(new String(n, "UTF-16LE").getBytes()); } catch (Exception e) { s = "Encoding error: " + e; }
w.titleText = s;

Win_User32.INSTANCE.GetClassName(w.hWnd, n, n.length);
try { s = Native.toString(new String(n, "UTF-16LE").getBytes()); } } catch (Exception e) { s = "Encoding error: " + e; }
w.className = s;
}
}


twalljava added a comment - 05/Jan/09 10:03 AM

One possibility is that the call to obtain closure trampoline memory is failing.
The native JNA code doesn't check for a null return (although dereferencing
that would result in a shallower stack trace than the one you provided).

Can you build JNA from source, including the native bits?


twalljava added a comment - 28/Mar/09 06:20 AM

Another bug causing a null-pointer access was found and fixed in SVN r775,
although that involved using unions when passing or returning structures by value.