Re: [tcpdump-workers] pcap segment violation
Yes, even so 2014-02-13 16:36 GMT-05:00, Guy Harris g...@alum.mit.edu: On Feb 13, 2014, at 1:24 PM, Daniel H. Bahr dhb...@gmail.com wrote: For some reason, as I said earlier, if the SIGSEGV is not connected to the bailout nothing queer happens, Even if you leave SIGQUIT and SIGTERM connected? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
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
Re: [tcpdump-workers] pcap segment violation
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 2 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
Re: [tcpdump-workers] pcap segment violation
The other thought I have is that java is heavily threaded, while libpcap is not thread safe. pcap_loop() is going to block. I see that your jni variable is a global... I wonder about that. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
On Feb 13, 2014, at 7:21 AM, Daniel H. Bahr dhb...@gmail.com wrote: 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 2 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? It's not possible that a SIGSEGV that causes a process to crash was emitted from a process other than the one that crashes - that's not how UN*Xes work. It is not impossible that a process could send another process a SIGSEGV with a kill() call, but it's sufficiently unlikely that I really don't think that's what's happening. It could be that this is a threading issue (as Michael noted, libpcap is not thread-safe; it can be run safely in a multi-threaded process only if 1) you don't do pcap_compile() simultaneously in multiple threads and 2) you don't do operations on any particular pcap_t * simultaneously in multiple threads (you can do operations on one pcap_t * - except for pcap_compile() - in one thread and operations on another pcap_t * - again, except for pcap_compile() - in another thread, but you can't do operations on any individual pcap_t * simultaneously in more than one thread). I don't know whether you can run Java inside a debugger, but, if you can, try putting the catch SIGSEGV code back and run your Java program inside a debugger (if necessary, use the right debugger commands to make sure the SIGSEGV is first handled by the debugger, and that the debugger stops the process so that you can get a stack trac even though the program is catching it). ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
I see what you mean, but the native startSniffing method is invoked
from a nested inner Thread. That is:
Java Main Thread {
do stuff...
Nested Outer Thread {
do more stuff...
Nested Inner Thread {
startSniffing here...
}
}
}
2014-02-13 12:29 GMT-05:00, Michael Richardson m...@sandelman.ca:
The other thought I have is that java is heavily threaded, while libpcap is
not thread safe. pcap_loop() is going to block.
I see that your jni variable is a global... I wonder about that.
--
] Never tell me the odds! | ipv6 mesh networks
[
] Michael Richardson, Sandelman Software Works| network architect
[
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
[
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
Guy,
my previous reply was sent before I saw your last message.
There IS a chance more than one instance of the Object owning the
native methods would be created IF there would be need to sniff at
several network interfaces simultaneously; in which case there would
be a single instance of the class for each network interface to be
sniffed.
Could this raise the issues you mention above?
2014-02-13 13:11 GMT-05:00, Daniel H. Bahr dhb...@gmail.com:
I see what you mean, but the native startSniffing method is invoked
from a nested inner Thread. That is:
Java Main Thread {
do stuff...
Nested Outer Thread {
do more stuff...
Nested Inner Thread {
startSniffing here...
}
}
}
2014-02-13 12:29 GMT-05:00, Michael Richardson m...@sandelman.ca:
The other thought I have is that java is heavily threaded, while libpcap
is
not thread safe. pcap_loop() is going to block.
I see that your jni variable is a global... I wonder about that.
--
] Never tell me the odds! | ipv6 mesh
networks
[
] Michael Richardson, Sandelman Software Works| network
architect
[
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails
[
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
On Feb 13, 2014, at 10:23 AM, Daniel H. Bahr dhb...@gmail.com wrote: There IS a chance more than one instance of the Object owning the native methods would be created IF there would be need to sniff at several network interfaces simultaneously; in which case there would be a single instance of the class for each network interface to be sniffed. Could this raise the issues you mention above? As long as each pcap_t * you have open is being accessed by one specific *OS-level thread of control within the address space*, the only issues you will have would happen if more than one thread (thread in the sense of an OS-level thread of control within the address space) is trying to run pcap_compile(). That wouldn't cause a crash while capturing traffic, however; you'd only get a problem if more than one thread of control within the address space is running pcap_compile() at the same time. I don't know whether you'd get a crash or just mysterious parsing errors. (I say OS-level thread of control within the address space because I'm not sure there's always a one-to-one correspondence between Java threads and OS-level threads.) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
Daniel H. Bahr dhb...@gmail.com wrote: my previous reply was sent before I saw your last message. There IS a chance more than one instance of the Object owning the native methods would be created IF there would be need to sniff at several network interfaces simultaneously; in which case there would be a single instance of the class for each network interface to be sniffed. Could this raise the issues you mention above? You have only one *jni variable, that might be a problem if it will be different in different threads/contexts. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
Well, I tried to debug the thing from eclipse but the crash could not be caught so I couldn't get the stack trace, I'll try and do that again later. For some reason, as I said earlier, if the SIGSEGV is not connected to the bailout nothing queer happens, I've run some large simulations and everything works out fine, as opposed as when I connect the signal in which case it crashes every time. I'll also take a look at the singleton *jni and see how to work that around. Best regards to everyone 2014-02-13 16:16 GMT-05:00, Michael Richardson m...@sandelman.ca: Daniel H. Bahr dhb...@gmail.com wrote: my previous reply was sent before I saw your last message. There IS a chance more than one instance of the Object owning the native methods would be created IF there would be need to sniff at several network interfaces simultaneously; in which case there would be a single instance of the class for each network interface to be sniffed. Could this raise the issues you mention above? You have only one *jni variable, that might be a problem if it will be different in different threads/contexts. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails [ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
On Feb 13, 2014, at 1:24 PM, Daniel H. Bahr dhb...@gmail.com wrote: For some reason, as I said earlier, if the SIGSEGV is not connected to the bailout nothing queer happens, Even if you leave SIGQUIT and SIGTERM connected? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
On Feb 12, 2014, at 11:42 AM, Daniel H. Bahr dhb...@gmail.com wrote:
Hello everyone, I really hope this is the right place to post this
since I did not find a pcap-specific mailing list,
There aren't separate tcpdump or libpcap mailing lists. This list is for all
tcpdump-related and libpcap-related mail, regardless of whether they're about
using tcpdump/libpcap (you're in the using libpcap group) or developing
tcpdump/libpcap.
Now it has been displaying an erratic behaviour in which after a
number of packets captured it would crash with a SIGSEGV.
On what OS is this? (I ask because not all OSes use SIGSEGV and SIGBUS for the
same purposes, and because, with some versions of some OSes and libpcap, the
packet data handed to your callback will, I think, be write-protected - see
below.)
What type of processor is this running on? (I ask because there might be
alignment issues on some processors, although I'd expect a SIGBUS, rather than
a SIGSEGV, for alignment issues.)
Can you get a stack trace to see where the SIGSEGV is happening?
capture_loop (pd, packets, (pcap_handler)parse_packet);
The cast to (pcap_handler) shouldn't be necessary...
void parse_packet(u_char *user, struct pcap_pkthdr *packethdr,
u_char *packetptr) {
...and *won't* be necessary if you change that to
void parse_packet(u_char *user, const struct pcap_pkthdr *packethdr,
const u_char *packetptr) {
If your code fails to compile after you make that change, your code may be
incorrect; libpcap does not guarantee that you will be able to modify either
the struct pcap_pkthdr handed to you or the raw packet data handed to you, and,
if you try to do so, Bad Things could happen (including a crash, if that data
is in a region of your address space not writable by you).
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap segment violation
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
