File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Swing GUI crashes (using JNI) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Swing GUI crashes (using JNI)" Watch "Swing GUI crashes (using JNI)" New topic
Author

Swing GUI crashes (using JNI)

Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
Hi,

I am working on java swing application(GUI) using JNI code to communicate with native C code. The Swing application launches properly and works fine.
The GUI is used to start some customized system level tests(io,memory,cpu) and show their progress. The tests have to be left running at-least overnight to get the
results. However, if I check the next morning, GUI crashes and throws following message.

Any pointers on source of the issue will be greatly appreciated.

Java version: java 1.5 / java 1.6
OS: Solaris 10.

Thanks,
Divya
PS: Also posted on stackoverflow for more insight. http://stackoverflow.com/questions/3008378/swing-gui-using-jni-crashes

=============MESSAGES==================
# uname -a
SunOS Generic_127127-11 sun4v sparc SUNW,
#
# #
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xff268924, pid=9473, tid=272
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_14-b03 mixed mode)
# Problematic frame:
# C [libc.so.1+0x68924] strstr+0x20
#
# An error report file with more information is saved as hs_err_pid9473.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

=============================

Another machine:

# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xff231fd0, pid=1406, tid=180
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode solaris-sparc )
# Problematic frame:
# C [libc.so.1+0x31fd0] strcpy+0x70
#
# An error report file with more information is saved as:
# /usr/sunvts/bin/hs_err_pid1406.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10535
    
    9

Did you check out the contents of the hs_err_pidxxx logs? If I am not mistaken, they will be dumped in your home directory, though not so sure.


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
Yes I do see the log.
The trace shows the calls all the way to my JNI code and then points to libc.so.1

But what exactly should I be looking for ? Could it be an issue in my code or is it JVM code issue?
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10535
    
    9

No idea. Sorry.
Since this problem is not related to Swing, I will move this tread to the Java in General forum for you.
Hopefully somebody will be able to throw some light on this issue.
pete stein
Bartender

Joined: Feb 23, 2007
Posts: 1561
Cross-posted at java-forums.org

http://www.java-forums.org/awt-swing/29682-swing-gui-crashes-using-jni.html
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19073
    
  40


Well, it is a seg fault ... meaning core dump.

If the stack trace shows that it is occuring in the JVM (and not related to the JNI call), then I recommend submitting the core dump to Sun/Oracle as a bug report. I also recommend upgrading to the latest underscore release too.

If the stack trace shows that it is due to the JNI call, then you have the core dump to track it down. Fire up gdb on the core dump, and try to isolate the issue. This should be treated as no different than hunting down any other C/C++ bug.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Looks like some pretty classic C programming issues. Segvs like these

# C [libc.so.1+0x31fd0] strcpy+0x70

or

# C [libc.so.1+0x68924] strstr+0x20


are very likely just due to passing dangling pointers around in the native code.

How much do you know about JNI programming? It can be pretty tricky dealing with thread-related memory ownership issues, which I suspect are quite thick in the kind of program you're describing. Maybe you could give us an idea of the scope of your native code, and maybe show us a representative sample.


[Jess in Action][AskingGoodQuestions]
Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
Native code base is pretty huge and complex. To begin with, I will check for dangling pointers. Thanks.
Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
Below is what I see in stack trace. It doesn't appear to be JVM issue.
Looks like the problem is happening in native function call
vts_connect() and vts_user_cred(), Is that so???


Stack: [0xa2980000,0xa2a00000), sp=0xa29feb58, free space=506k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1+0x68924] strstr+0x20
C [libjniapi.so+0x1d80] vts_connect+0x134
C [libjniapi.so+0x19e4] __1cQvts_authenticate6F_i_+0x30
C [libjniapi.so+0x1ad4] Java_com_deg_agent_JNILink_vtsCommand+0xc
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0
j com.deg.agent.JNILink.executeVTSKCommand(Ljava/lang/String;)Ljava/lang/String;+7


Stack: [0xac200000,0xac280000], sp=0xac27e698, free space=1f9ff231fd0k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1+0x31fd0] strcpy+0x70
C [libjniapi.so+0x2c60] vts_user_cred+0x94
C [libjniapi.so+0x2720]
C [libjniapi.so+0x1d64] vts_connect+0x118
C [libjniapi.so+0x19e4] __1cQvts_authenticate6F_i_+0x30
C [libjniapi.so+0x1ad4] Java_com_deg_agent_JNILink_vtsCommand+0xc
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+15
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0






Ernest Friedman-Hill wrote:Looks like some pretty classic C programming issues. Segvs like these

# C [libc.so.1+0x31fd0] strcpy+0x70

or

# C [libc.so.1+0x68924] strstr+0x20


are very likely just due to passing dangling pointers around in the native code.

How much do you know about JNI programming? It can be pretty tricky dealing with thread-related memory ownership issues, which I suspect are quite thick in the kind of program you're describing. Maybe you could give us an idea of the scope of your native code, and maybe show us a representative sample.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19794
    
  20

Divya Marwaha wrote:Stack: [0xa2980000,0xa2a00000), sp=0xa29feb58, free space=506k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1+0x68924] strstr+0x20
C [libjniapi.so+0x1d80] vts_connect+0x134
C [libjniapi.so+0x19e4] __1cQvts_authenticate6F_i_+0x30
C [libjniapi.so+0x1ad4] Java_com_deg_agent_JNILink_vtsCommand+0xc
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0
j com.deg.agent.JNILink.executeVTSKCommand(Ljava/lang/String;)Ljava/lang/String;+7

This is what I see in stack trace. It doesn't appear to be JVM issue.
Looks like the problem is happening in native function call vts_connect(), Is that so???

It appears so. That's indirectly called by class com.deg.agent.JNILink, method String vtsCommand(String). Maybe you're passing a null string and it doesn't check for it.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
But once the tests are started from the swing GUI, the progress of tests is shown properly. After 24+ hours run, at some random time the SEGV crash is reported. While tests are running no changes can be made from the GUI.

Rob Prime wrote:
Divya Marwaha wrote:Stack: [0xa2980000,0xa2a00000), sp=0xa29feb58, free space=506k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1+0x68924] strstr+0x20
C [libjniapi.so+0x1d80] vts_connect+0x134
C [libjniapi.so+0x19e4] __1cQvts_authenticate6F_i_+0x30
C [libjniapi.so+0x1ad4] Java_com_deg_agent_JNILink_vtsCommand+0xc
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0
j com.deg.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+0
j com.deg.agent.JNILink.executeVTSKCommand(Ljava/lang/String;)Ljava/lang/String;+7

This is what I see in stack trace. It doesn't appear to be JVM issue.
Looks like the problem is happening in native function call vts_connect(), Is that so???

It appears so. That's indirectly called by class com.deg.agent.JNILink, method String vtsCommand(String). Maybe you're passing a null string and it doesn't check for it.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Indeed. 999,999 times out of a million, your code might work fine -- but it still may not be coded correctly to deal with thread ownership of references or with the possible data movement that can occur due to garbage collection. That's why I said JNI can be tricky.
Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
I made some string related changes in C files (native layer for string manipulation operations)
The error is still appearing after 24 + hours of running the application. and stack is pointing to same strcpy location.

Code flow is :
Swing UI
|
java code
|
JNI C file (jniapi.cc)
|
native layer

The Swing UI sends command to native layer and native layer returns a response which is displayed by UI.

code from jniapi.cc is also below which makes calls to native functions.
################

################

What sort of JNI optimization can be introduced?

Thanks,
Divya



Ernest Friedman-Hill wrote:Indeed. 999,999 times out of a million, your code might work fine -- but it still may not be coded correctly to deal with thread ownership of references or with the possible data movement that can occur due to garbage collection. That's why I said JNI can be tricky.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19794
    
  20

Please UseCodeTags. It will work even for C code (although the highlighting may be incorrect, but at least the indentation will be there).
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

Can we see vts_connect? If we saw the call to strstr, then we could figure out where its arguments came from, and that would let us trace where they might possibly go wrong.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19794
    
  20

One unrelated note: you're calling GetStringUTFChars but your missing the ReleaseStringUTFChars call.
Divya Marwaha
Greenhorn

Joined: Feb 09, 2008
Posts: 11
Stack trace for jvm dump mostly points to strcpy (and sometimes strstr, strcat)

  • C [libc.so.1+0x31fd0] strcpy+0x70
    C [libjniapi.so+0x2c60] vts_user_cred+0x94
    C [libjniapi.so+0x2720]
    C [libjniapi.so+0x1d64] vts_connect+0x118
    C [libjniapi.so+0x19e4] __1cQvts_authenticate6F_i_+0x30
    C [libjniapi.so+0x1ad4] Java_com_sun_deg_sunvts_agent_JNILink_vtsCommand+0xc
    j com.sun.deg.sunvts.agent.JNILink.vtsCommand(Ljava/lang/String;)Ljava/lang/String;+15


  • I am including important fn def.


    Ernest Friedman-Hill wrote:Can we see vts_connect? If we saw the call to strstr, then we could figure out where its arguments came from, and that would let us trace where they might possibly go wrong.
    Divya Marwaha
    Greenhorn

    Joined: Feb 09, 2008
    Posts: 11
    Another thing is , when I started running the java GUI app, free disk space was about 27% and later at the time of crash I saw free space of only about 8% (using df -k on solaris sparc box). Also, If one uses terminal based UI (TTYUI using C n C ++ code) then no sort of error in seen. Only when swing based UI is used with native code, jvm dumps..why is it so?? Can it be something to do with jvm heap size or similar issue? If the problem is in native code alone then should it not get reported in some form with other UIs as well which interact with native Code? I am just wondering...expert thoughts will be enlightening for me...
    Ernest Friedman-Hill
    author and iconoclast
    Marshal

    Joined: Jul 08, 2003
    Posts: 24187
        
      34

    Well, boy howdy. There are all kinds of things that might happen here, depending on what the data looks like. One that jumps out at me is this:

    static struct user_info ustr;

    That "ustr" is going to be shared by all calls to vts_user_cred. If the code we're looking at is called by the JVM in multiple threads simultaneously, then the contents of that structure could become inconsistent -- i.e., from one thread's perspective, ustr.num_groups could be wrong about how many grp_names there are, and you could easily be passing a dangling or garbage pointer directly into strcat, or freeing a garbage or dangling pointer, etc.

    Divya Marwaha
    Greenhorn

    Joined: Feb 09, 2008
    Posts: 11
    Thanks all for your valuable and prompt inputs.
    strcpy was done from larger size buffer (1024) to 512 size user_cred variable...
    Even after making the change the reason I wasn't seeing the crash was because
    all the related binaries were not copied on the testing box properly....my bad
    Anyhow,Thanks again.
    -Divya

     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Swing GUI crashes (using JNI)