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 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?
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
