First of all thanks for your replies and sorry for the delay on mine. "On what OS is this?" Both Debian 7 and Ubuntu 12.04 (though I really think they represent the same to you).
"What type of processor is this running on?" amd64 bit processors. The Ubuntu box runs on a QuadCore (the Debian one I am not sure, but it should be something like that). "Can you get a stack trace to see where the SIGSEGV is happening?" I'll unplug the SIGSEGV and see if I get a traceback or something as soon as I get to the office, and I'll take your proposals into consideration, see what happens. "Maybe is related to the fact that you are accessing a global reference to a java object across JNI calls." I'll check that out as well and let you know ... Best regards, and thanks again for your concern. 2014-02-12 18:21 GMT-05:00, Esteban Pellegrino <pellegre.este...@gmail.com>: > Maybe is related to the fact that you are accessing a global reference to a > java object across JNI calls. I'm talking about the "jobject this" defined > at the begin of the code. > > I think the garbage collector is allowed to move it. That make sense? > Maybe you can try your code after setting a global reference to it with the > env->NewGlobalRef method. > On Feb 13, 2014 12:22 AM, "Guy Harris" <g...@alum.mit.edu> wrote: > >> Note also that there is *NO* guarantee that the struct pcap_pkthdr or >> packet data pointers handed to your callback remain valid after it >> returns, >> so those pointers must not be saved by your callback or anything it >> calls. >> _______________________________________________ >> tcpdump-workers mailing list >> tcpdump-workers@lists.tcpdump.org >> https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers >> > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
