This keeps getting weirder... Just unplugged the SIGSEGV signal to get a stacktrace upon its occurrence and I've performed 3 complete cycle (that is 20000 packets) simulations without getting any buggy behavior.
Is it at all possible that the Segment Violation signal that triggered the bailout was emitted from a process other than this one? 2014-02-13 8:11 GMT-05:00, Daniel H. Bahr <dhb...@gmail.com>: > 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
