JNI wrapper for NSSavePanel
Steve Hannah
steve at weblite.ca
Sun Oct 7 08:01:28 PDT 2012
In case it offers insight, this is the backtrace of the thread that crashed:
hread 23 Crashed:: Java: Thread-2
0 libsystem_kernel.dylib 0x00007fff8a043212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff87e93b34 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff87ed7dfa abort + 143
3 libjvm.dylib 0x0000000108d47a9f os::abort(bool) + 25
4 libjvm.dylib 0x0000000108e3435e
VMError::report_and_die() + 2306
5 libjvm.dylib 0x0000000108d49193 JVM_handle_bsd_signal
+ 1073
6 libsystem_c.dylib 0x00007fff87e8092a _sigtramp + 26
7 libobjc.A.dylib 0x00007fff898d33ee objc_retain + 14
8 ??? 0x000000010959cf90 0 + 4451848080
9 ??? 0x0000000109591333 0 + 4451799859
10 ??? 0x000000010958b4f7 0 + 4451775735
11 libjvm.dylib 0x0000000108c1f083
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
Thread*) + 557
12 libjvm.dylib 0x0000000108c1ee50
JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
13 libjvm.dylib 0x0000000108d88062
Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool,
objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 2506
14 libjvm.dylib 0x0000000108d884ba
Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 360
15 libjvm.dylib 0x0000000108c4f99b JVM_InvokeMethod + 352
16 ??? 0x000000010959cf90 0 + 4451848080
17 ??? 0x0000000109591333 0 + 4451799859
18 ??? 0x0000000109591333 0 + 4451799859
19 ??? 0x00000001095919e1 0 + 4451801569
20 ??? 0x0000000109591333 0 + 4451799859
21 ??? 0x0000000109591333 0 + 4451799859
22 ??? 0x0000000109591333 0 + 4451799859
23 ??? 0x0000000109591333 0 + 4451799859
24 ??? 0x0000000109591333 0 + 4451799859
25 ??? 0x0000000109591333 0 + 4451799859
26 ??? 0x0000000109591333 0 + 4451799859
27 ??? 0x0000000109591333 0 + 4451799859
28 ??? 0x0000000109591333 0 + 4451799859
29 ??? 0x0000000109591333 0 + 4451799859
30 ??? 0x0000000109591333 0 + 4451799859
31 ??? 0x0000000109591333 0 + 4451799859
32 ??? 0x0000000109591333 0 + 4451799859
33 ??? 0x0000000109591333 0 + 4451799859
34 ??? 0x0000000109591333 0 + 4451799859
35 ??? 0x0000000109591333 0 + 4451799859
36 ??? 0x0000000109591158 0 + 4451799384
37 ??? 0x0000000109591158 0 + 4451799384
38 ??? 0x0000000109591806 0 + 4451801094
39 ??? 0x000000010958b4f7 0 + 4451775735
40 libjvm.dylib 0x0000000108c1f083
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
Thread*) + 557
41 libjvm.dylib 0x0000000108c1f560
JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*,
JavaCallArguments*, Thread*) + 256
42 libjvm.dylib 0x0000000108c1f69a
JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*,
Thread*) + 74
43 libjvm.dylib 0x0000000108c52504
thread_entry(JavaThread*, Thread*) + 169
44 libjvm.dylib 0x0000000108e09f74
JavaThread::thread_main_inner() + 134
45 libjvm.dylib 0x0000000108e0b413 JavaThread::run() +
369
46 libjvm.dylib 0x0000000108d47fc1 java_start(Thread*) +
173
47 libsystem_c.dylib 0x00007fff87e92782 _pthread_start + 327
48 libsystem_c.dylib 0x00007fff87e7f1c1 thread_start + 13
Best regards
Steve
On Sun, Oct 7, 2012 at 7:40 AM, Steve Hannah <steve at weblite.ca> wrote:
>
> Are you building/running the app from Xcode? You could try setting a
>> breakpoint to inspect the local state.
>>
>>
> I'm building the JNI library in XCode, but the application I'm building in
> Netbeans and packaging using Marco's port of AppBundler.
>
> I've experimented with threading issues and don't think that is the
> problem now in this case, but still don't know what is the problem. I have
> modified the example to make it simpler.
>
> The following code does not work:
>
> JNIEXPORT jstring JNICALL Java_ca_weblite_mactools_Sandbox_saveDialog
>
> (JNIEnv *env, jobject jthis, jstring title, jstring extension){
>
> //JNF_COCOA_ENTER(<#env#>);
>
> return JNFNSToJavaString(env, @"/Users/shannah/Downloads/out2.pdf");
>
> //JNF_COCOA_EXIT(env);
> }
>
> If I uncomment the JNF_COCOA_ENTER/EXIT lines, it works properly.
>
> I have my Java logging working now so I can follow the progress with
> println statements right up until it calls the native method. I get a
> crash at that point. It doesn't even enter the native method (i.e. if I
> put a print statement first line, nothing happens.
>
> It almost seems like putting the JNF_COCOA_ENTER/EXIT calls inside the
> method some somehow changes the method signature so that Java can no longer
> find the correct method to call at runtime.... but that doesn't seem
> possible.
>
> Given my inexperience with XCode, I suspect that it could be a problem
> with the way I'm building/linking the JNI library. The fact that calls to
> JNFNSToJavaString() work makes me thing that the JavaNativeFoundation is
> correctly linked (?).
>
> Note: I'm going through this exercise to try and write the code with
> JNF_COCOA_ENTER/EXIT because, despite the fact that the library worked
> perfectly the way it was on Mountain Lion, it doesn't work on Lion, so I'm
> trying to cover all of my bases to figure out why. When I got stuck at
> this step, I figured it's worth finding out what this problem is just in
> case it's related to the Lion problem.
>
> I'm building it with settings:
> Base SDK: Latest OS X (OS X 10.8)
> Deployment Target: OS X 10..7 (although I've tried 10.6 and 10.8 with
> same results).
>
>
> Any other suggestions or tips, much appreciated.
>
>
> Best regards
>
> Steve
>
>
>>> JNF_COCOA_ENTER/EXIT do more than just setup an autorelease pool - they
>>> also catch ObjC exceptions and re-throw them as Java runtime exceptions.
>>>
>>> Do you have the backtrace of where you are crashing when using
>>> JNF_COCOA_ENTER/EXIT?
>>>
>> I do, but I'm having difficulty making heads or tails from it. I'm also
>> struggling with getting logging information out on the Java side as I'm
>> working on a Mountain Lion machine and I can't find where System.out and
>> System.err are logged by default... and the sandbox is making it difficult
>> for me to set a log location manually... (anything that runs or fails
>> before or during the setting of a custom log location is not logged).
>>
>>
>> I think (but I'm not certain) that this is the way it is now on Lion and
>> Mountain Lion - output logged to stdout/stderr directly (including the JVM
>> System.out/err) just goes to /dev/null unless you run the primary
>> executable from a shell or some other parent process that gives it a TTY.
>> Otherwise, the only thing that gets logged to the system console comes
>> through ASL, like NSLog(). Of course, I may be completely off on this, but
>> perhaps this is explaining what you are seeing.
>>
>> Also, are you doing anything special to run this JNI method on the main
>>> AppKit thread (or are you using SWT)?
>>
>> Ah.. I hadn't thought of that, but yes. I'm overriding the
>> java.awt.FileDialog class's setVisible() method to display this as a modal
>> dialog.
>>
>>
>>> If not, you may want to use +[JNFRunLoop
>>> performOnMainThreadWaiting:withBlock:], which will block the current
>>> thread, run your block on the main thread (safe for AppKit), and then
>>> continue execution of your Java thread when the block returns.
>>>
>>
>> I'll give this a shot.
>>
>> Thanks for the suggestions.
>>
>>
>> No problem. Please do always think of the threading considerations when
>> writing JNI. We try to let you not worry about exceptions and autorelease
>> pools if you use JNF, but threading is still something you have to think
>> through when you get JNI and Cocoa tangled together.
>>
>> Best of luck,
>> Mike Swingler
>> Apple Inc.
>>
>>
>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>
>
--
Steve Hannah
Web Lite Solutions Corp.
More information about the macosx-port-dev
mailing list