pcap_open_offline and JVM
Brought to you by:
pcharles
Menu
▾
▴
#31 pcap_open_offline and JVM
Hi I'm Max, can someone help me?
I 've developed a java application that sniffs packets on
Hard Disk dumped form the web.
The java library that I used is net.sourceforge.jpcap-
0.01.15.jar downloaded at
http://sourceforge.net/project/showfiles.php?
group_id=27207&package_id=18976&release_id=224195
that uses the pcap_open_offline method of WinPcap.
The problem is that during the process the memory used
by JVM increases constantly, even with the explicit
Garbage Collector calls.
I think the problem is in the C funtion pcap_open_offline,
but I don't know what!
Has anyone allready experencied this?
Thanks
Logged In: NO
hi
i'm josef
i have the same problem. don'tknow how to solve it
Logged In: YES
user_id=1026448
Hello,
I have got similar problems using a sniffer application
under linux.
Even when running the Example15-programme the memory
consumption of the JVM increases up to about 530 megabytes
(in some other cases 'only' about 210 megabytes).
Then the programme crashes with unknown errors outside the
vm (see my postings in the development-forum).
The problem occurs under slackware 9.1 and SuSE 9.0.
Complete-Error-Message:
"
An unexpected exception has been detected in native code
outside the VM.
Unexpected Signal : 11 occurred at PC=0x400F6F2D
Function=(null)+0x400F6F2D
Library=/lib/libc.so.6
NOTE: We are unable to locate the function name symbol for
the error
just occurred. Please refer to release documentation
for possible
reason and solutions.
Current Java thread:
at
net.sourceforge.jpcap.capture.PacketCapture.capture(Native
Method)
at
net.sourceforge.jpcap.capture.PacketCapture.capture(PacketCapture.java:88)
at
net.sourceforge.jpcap.capture.SyncPacketCapture.syncCapture(SyncPacketCapture.java:29)
at
net.sourceforge.jpcap.capture.CaptureThread.run(SyncPacketCapture.java:96)
Dynamic libraries:
08048000-0804e000 r-xp 00000000 03:04 13891402
/usr/lib/j2sdk1.4.2_04/bin/java
0804e000-0804f000 rw-p 00005000 03:04 13891402
/usr/lib/j2sdk1.4.2_04/bin/java
40000000-40015000 r-xp 00000000 03:04 21012826
/lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:04 21012826
/lib/ld-2.3.2.so
4002b000-40039000 r-xp 00000000 03:04 21012842
/lib/libpthread-0.10.so
40039000-4003c000 rw-p 0000e000 03:04 21012842
/lib/libpthread-0.10.so
4007c000-4007e000 r-xp 00000000 03:04 21012831
/lib/libdl-2.3.2.so
4007e000-4007f000 rw-p 00001000 03:04 21012831
/lib/libdl-2.3.2.so
4007f000-401ae000 r-xp 00000000 03:04 21012829
/lib/libc-2.3.2.so
401ae000-401b3000 rw-p 0012f000 03:04 21012829
/lib/libc-2.3.2.so
401b5000-405b0000 r-xp 00000000 03:04 25446393
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/client/libjvm.so
405b0000-405cb000 rw-p 003fa000 03:04 25446393
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/client/libjvm.so
405de000-405e6000 r-xp 00000000 03:04 22168320
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/native_threads/libhpi.so
405e6000-405e7000 rw-p 00007000 03:04 22168320
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/native_threads/libhpi.so
405f2000-40604000 r-xp 00000000 03:04 21012834
/lib/libnsl-2.3.2.so
40604000-40605000 rw-p 00011000 03:04 21012834
/lib/libnsl-2.3.2.so
40607000-40629000 r-xp 00000000 03:04 21012832
/lib/libm-2.3.2.so
40629000-4062a000 rw-p 00021000 03:04 21012832
/lib/libm-2.3.2.so
4062a000-4062e000 rw-s 00000000 03:04 906595
/tmp/hsperfdata_root/983
4063e000-40649000 r-xp 00000000 03:04 21012835
/lib/libnss_compat-2.3.2.so
40649000-4064a000 rw-p 0000a000 03:04 21012835
/lib/libnss_compat-2.3.2.so
4064a000-4065a000 r-xp 00000000 03:04 17204301
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/libverify.so
4065a000-4065c000 rw-p 0000f000 03:04 17204301
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/libverify.so
4065c000-4067c000 r-xp 00000000 03:04 16787658
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/libjava.so
4067c000-4067e000 rw-p 0001f000 03:04 16787658
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/libjava.so
4067e000-40692000 r-xp 00000000 03:04 16787653
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/libzip.so
40692000-40695000 rw-p 00013000 03:04 16787653
/usr/lib/j2sdk1.4.2_04/jre/lib/i386/libzip.so
40695000-42035000 r--s 00000000 03:04 25446422
/usr/lib/j2sdk1.4.2_04/jre/lib/rt.jar
4207f000-42095000 r--s 00000000 03:04 25446412
/usr/lib/j2sdk1.4.2_04/jre/lib/sunrsasign.jar
42095000-42170000 r--s 00000000 03:04 25446406
/usr/lib/j2sdk1.4.2_04/jre/lib/jsse.jar
42170000-42181000 r--s 00000000 03:04 25446428
/usr/lib/j2sdk1.4.2_04/jre/lib/jce.jar
42181000-426da000 r--s 00000000 03:04 25446418
/usr/lib/j2sdk1.4.2_04/jre/lib/charsets.jar
44782000-44785000 r--s 00000000 03:04 13591552
/usr/lib/j2sdk1.4.2_04/jre/lib/ext/dnsns.jar
60944000-60960000 r--s 00000000 03:04 13591554
/usr/lib/j2sdk1.4.2_04/jre/lib/ext/sunjce_provider.jar
60960000-6096d000 r--s 00000000 03:04 13591555
/usr/lib/j2sdk1.4.2_04/jre/lib/ext/ldapsec.jar
6096d000-60a29000 r--s 00000000 03:04 13591556
/usr/lib/j2sdk1.4.2_04/jre/lib/ext/localedata.jar
60a29000-60a43000 r-xp 00000000 03:04 38842781
/usr/local/lib/libjpcap.so
60a43000-60a45000 rw-p 00019000 03:04 38842781
/usr/local/lib/libjpcap.so
60a59000-60a90000 r-xp 00000000 03:04 29360400
/usr/i486-slackware-linux/lib/libstdc++-3-libc6.2-2-2.10.0.so
60a90000-60a9c000 rw-p 00036000 03:04 29360400
/usr/i486-slackware-linux/lib/libstdc++-3-libc6.2-2-2.10.0.so
Heap at VM Abort:
Heap
def new generation total 576K, used 311K [0x44790000,
0x44830000, 0x46510000)
eden space 512K, 48% used [0x44790000, 0x447cdea0,
0x44810000)
from space 64K, 99% used [0x44820000, 0x4482fff8, 0x44830000)
to space 64K, 0% used [0x44810000, 0x44810000, 0x44820000)
tenured generation total 1408K, used 27K [0x46510000,
0x46670000, 0x5c790000)
the space 1408K, 1% used [0x46510000, 0x46516de0,
0x46516e00, 0x46670000)
compacting perm gen total 4096K, used 1079K [0x5c790000,
0x5cb90000, 0x60790000)
the space 4096K, 26% used [0x5c790000, 0x5c89dc58,
0x5c89de00, 0x5cb90000)
Local Time = Sun Jun 13 00:01:23 2004
Elapsed Time = 3
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode)
#
"
Logged In: YES
user_id=1059997
Hi,
We found as well there was (maybe) a memory leak. We
reproduce it by running Example1 with an INFINITE capture:
m_pcap.capture( INFINITE );
I modified slightly the file process.cpp by adding the following
line and recompile the library:
javaEnvironment->DeleteLocalRef(cls);
at the end of the funcion processing::processData, just
after "javaEnvironment->DeleteLocalRef(jba);".
My knowledge in development and in jpcap is very limited and
I'd like somebody to confirm it.
Regards
Pascal
Logged In: NO
Hi,
I have also problems with this memory leak. I'm developing
an application that have to go through even millions of
packets from libpcap dumpfiles (and most of packets are just
discarded) and memory leak with openOffline method is
critical problem. The leak seams to be quite little but
inevitable when reading multiple large files consecutively.
I'm using Windows XP/2000 with Java 1.5.0.
Does that pmaugeri's solution work for others? I have very
little experience of building the .dll from source to test
this and I'm using the ready compiled files with my project.
Hope this bug gets fixed for next distribution.
Logged In: YES
user_id=1458062
Hi,
I've been looking through the bug report history and this
issue has evidently come up before; see reports 1006887
and 608347. The problem was fixed in version 0.01.13 but
re-introduced somewhere between there and 0.01.16. The
DeleteLocalRef() method will fix it, but the best solution
is to do the GetObjectClass() and GetMethodID() calls just
once at the start of the capture() method instead of on
every packet. This is also a very significant performance
boost.
I have patched the source files and tested on Windows and
Linux for anyone who is interested, just not sure how to
attach the files to this report... they're kind of big to
put inline here.
- regards,
Roland Lockhart
Logged In: YES
user_id=1262793
Originator: NO
Multiple memory leaks during capture and elsewhere have been addressed in the forthcoming release 2.0.