Yes, even so
2014-02-13 16:36 GMT-05:00, Guy Harris :
>
> On Feb 13, 2014, at 1:24 PM, "Daniel H. Bahr" 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?
>
>
___
On Feb 13, 2014, at 1:24 PM, "Daniel H. Bahr" 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
tcpdu
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
everyth
Daniel H. Bahr 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 t
On Feb 13, 2014, at 10:23 AM, "Daniel H. Bahr" 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 clas
Probably worth noting is the fact that the times I experienced the
buggy behavior there was only one sniffer up and running...
2014-02-13 13:23 GMT-05:00, Daniel H. Bahr :
> Guy,
>
> my previous reply was sent before I saw your last message.
>
> There IS a chance more than one instance of the Obje
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 cla
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
On Feb 13, 2014, at 7:21 AM, "Daniel H. Bahr" 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 po
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,
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 wa
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
o
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
On Feb 12, 2014, at 11:42 AM, Daniel H. Bahr 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,
14 matches
Mail list logo
