[tcpdump-workers] print-rx.c time format
Building windump using MingW + gcc 4.7.2, I get:
print-rx.c: In function 'fs_print':
print-rx.c:929:4: warning: unknown conversion type character 'T' in format
[-Wformat]
print-rx.c:933:4: warning: unknown conversion type character 'T' in format
[-Wformat]
This comes from the macro DATEOUT():
strftime(str, 256, "%Y/%m/%d %T", tm); \
If I should trust what my 'man strftime' says:
%T or %X
is equivalent to %H:%M:%S.
we could show the time using this format instead (as print-ntp.c does).
IMHO. there should be an easy-access function in util.c for this.
Something like: const char *get_tm_str (time_t t);
But for now this patch makes gcc/MingW shutup:
--- Git-Latest/print-rx.c2014-01-14 17:51:07 +
+++ print-rx.c 2014-02-13 13:08:40 +
@@ -788,7 +788,7 @@
t = (time_t) EXTRACT_32BITS(bp); \
bp += sizeof(int32_t); \
tm = localtime(&t); \
- strftime(str, 256, "%Y/%m/%d %T", tm); \
+ strftime(str, 256, "%Y/%m/%d %H:%M:%S", tm); \
printf(" %s", str); \
}
-
--gv
___
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 : > 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" 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 : > 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 > : >> 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" 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] Request for DLT for new BlueZ Monitor
Ping. -- Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ 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" 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 :
>
> 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 :
> 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 :
>>
>> 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
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 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 :
>> 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 :
>>>
>>> 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" 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 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 : > > 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 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" 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
