10:48 a.m.
Hi,
When I changed code as following:
public class Connect {
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback());
}
The server will generate the following core dump:
Program terminated with signal 6, Aborted.
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
#1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6
#2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6
#3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6
#4 0x0000003f9b07276b in free () from /lib64/libc.so.6
#5 0x00002aaaacf46868 in ?? ()
#6 0x0000000000000000 in ?? ()
The problem was caused that when JNA call setErrorFunc, it will create ErrorCallback
object. But when GC is executed, the object is GCed. But even I change code as following.
When GC is excuted, the callback object will be moved. Then C can't find this object.
Both of scenarios will cause core dump. It seems that JNA mustn't provide
ErrorCallback Class,
Because nobody can use this.
Please correct me.
public class Connect {
+ private static final ErrorCallback callback = new ErrorCallback();
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, callback);
}
B.R.
Benjamin Wang
6:36 a.m.
>>>> "BW" == Benjamin Wang (gendwang)
<gendwang(a)cisco.com> writes:
BW> Hi, When I changed code as following:
BW> public class Connect {
BW> // Load the native part
BW> static {
BW> Libvirt.INSTANCE.virInitialize();
BW> try {
BW> ErrorHandler.processError(Libvirt.INSTANCE);
BW> } catch (Exception e) {
BW> e.printStackTrace();
BW> }
BW> + Libvirt.INSTANCE.virSetErrorFunc(null, new
BW> ErrorCallback());
BW> }
BW> The problem was caused that when JNA call setErrorFunc, it
BW> will create ErrorCallback object. But when GC is executed, the
BW> object is GCed.
Yes, that's why you should keep a reference to the object around.
BW> But even I change code as following.
BW> When GC is excuted, the callback object will be moved. Then C
BW> can’t find this object. Both of scenarios will cause core
BW> dump. It seems that JNA mustn’t provide ErrorCallback Class,
First off, JNA does not provide this class, it is provided by the
libvirt-java wrapper.
Which version of JNA did you use? As I said in a previous mail, I had
crashes with JNA < 3.4.2. Consequently, I cannot reproduce the crash
using your code, JNA 3.4.2 and with having this series
(https://www.redhat.com/archives/libvir-list/2012-October/msg00578.html)
applied. (at least patch #15 is needed when using JNA 3.4.2)
--
AV-Test GmbH, Klewitzstr. 7, 39112 Magdeburg, Germany
Phone: +49 391 6075466, Fax: +49 391 6075469
Web: <http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern
7:12 a.m.
Hi,
I am using JNA 3.4.1. The problem is caused by libvirt java. You are right.
B.R.
Benjamin Wang
-----Original Message-----
From: Claudio Bley [mailto:cbley@av-test.de]
Sent: 2012年10月19日 19:36
To: Benjamin Wang (gendwang)
Cc: libvir-list(a)redhat.com; Guannan Ren; Daniel Veillard; Yang Zhou (yangzho)
Subject: Re: JNA Error Callback could cause core dump.
>>>> "BW" == Benjamin Wang (gendwang)
<gendwang(a)cisco.com> writes:
BW> Hi, When I changed code as following:
BW> public class Connect {
BW> // Load the native part
BW> static {
BW> Libvirt.INSTANCE.virInitialize();
BW> try {
BW> ErrorHandler.processError(Libvirt.INSTANCE);
BW> } catch (Exception e) {
BW> e.printStackTrace();
BW> }
BW> + Libvirt.INSTANCE.virSetErrorFunc(null, new
BW> ErrorCallback());
BW> }
BW> The problem was caused that when JNA call setErrorFunc, it
BW> will create ErrorCallback object. But when GC is executed, the
BW> object is GCed.
Yes, that's why you should keep a reference to the object around.
BW> But even I change code as following.
BW> When GC is excuted, the callback object will be moved. Then C
BW> can’t find this object. Both of scenarios will cause core
BW> dump. It seems that JNA mustn’t provide ErrorCallback Class,
First off, JNA does not provide this class, it is provided by the libvirt-java wrapper.
Which version of JNA did you use? As I said in a previous mail, I had crashes with JNA
< 3.4.2. Consequently, I cannot reproduce the crash using your code, JNA 3.4.2 and with
having this series
(https://www.redhat.com/archives/libvir-list/2012-October/msg00578.html)
applied. (at least patch #15 is needed when using JNA 3.4.2)
--
AV-Test GmbH, Klewitzstr. 7, 39112 Magdeburg, Germany
Phone: +49 391 6075466, Fax: +49 391 6075469
Web: <http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076) Geschaeftsfuehrer (CEO):
Andreas Marx, Guido Habicht, Maik Morgenstern
9:55 a.m.
At Thu, 18 Oct 2012 15:48:22 +0000,
Benjamin Wang (gendwang) wrote:
Hi,
When I changed code as following:
public class Connect {
// Load the native part
static {
Libvirt.INSTANCE.virInitialize();
try {
ErrorHandler.processError(Libvirt.INSTANCE);
} catch (Exception e) {
e.printStackTrace();
}
+ Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback());
}
The server will generate the following core dump:
Program terminated with signal 6, Aborted.
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
(gdb) where
#0 0x0000003f9b030265 in raise () from /lib64/libc.so.6
#1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6
#2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6
#3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6
#4 0x0000003f9b07276b in free () from /lib64/libc.so.6
#5 0x00002aaaacf46868 in ?? ()
#6 0x0000000000000000 in ?? ()
The problem was caused that when JNA call setErrorFunc, it will
create ErrorCallback object. But when GC is executed, the object is
GCed.
This should not lead to the crash above.
But even I change code as following. When GC is excuted, the
callback object will be moved. Then C can't find this object.
No, this cannot happen. The VM keeps track of its objects, the C code
never gets a direct pointer to an object but only a handle and JNA is
registering a trampoline function in native code which doesn't move.
Both of scenarios will cause core dump. It seems that JNA mustn't
provide ErrorCallback Class,
Because nobody can use this.
Please correct me.
Which version of JNA are you using?
Which OS and which machine type?
Are you running this on a virtual machine? If yes, which one?
Which JVM are you using?
There's a unit test which exercises the Connect.setErrorCallback
method (which in turn calls virSetErrorFunc). This test works for me
for any version of JNA from 3.3.0 to 4.0.0 using OpenJDK 1.6.0 64bit
on Linux. Did you try to run the unit tests?
Could you show us the Java crash dump?
Claudio
--
AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany
Phone: +49 341 265 310 19
Web:<http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern
2:39 a.m.
Sorry, I must have taken some bad pills. Just realized that I replied
to a message already more than a year old. I swear my MUA displayed it
as new...
At Thu, 19 Dec 2013 16:55:58 +0100,
Claudio Bley wrote:
At Thu, 18 Oct 2012 15:48:22 +0000,
Benjamin Wang (gendwang) wrote:
--
AV-Test GmbH, Henricistraße 20, 04155 Leipzig, Germany
Phone: +49 341 265 310 19
Web:<http://www.av-test.org>
Eingetragen am / Registered at: Amtsgericht Stendal (HRB 114076)
Geschaeftsfuehrer (CEO): Andreas Marx, Guido Habicht, Maik Morgenstern
3989
days inactive
4417
days old
4 comments
2 participants
participants (2)
-
Benjamin Wang (gendwang) -
Claudio Bley