> According to this trace, the stack is currupted. > It said that pcap_loop () is invoked from "snss7btnup." which is false.
No, it's saying that it's *located* in "snss7btnup.c": > #4 0x8e9b0 in pcap_loop () at snss7btnup.c:2074 it's saying that it's invoked from "util_packet_scheduler__FUi()": > #5 0x17d58 in util_packet_scheduler__FUi (display_type=4128) at snutil.c:798 which looks like a C++ mangled name, so perhaps it is, as you noted, called from a C++ function named "util_packet_scheduler()". Perhaps you should send a problem report to "[EMAIL PROTECTED]", indicating that GDB is confused about the source files in which functions reside. > The application cores after changing dynamically the filter program in my > callback routine by invoking "pcap_compile" and pcap_setfilter". > In more detail, the callback is invoked by pcap one more time with a packet > and then cores on the next one. Try writing a small C program that tries to change the filter expression in a similar fashion, to see if you can reproduce the same problem and get a core dump that your version of GDB can handle. The only "abort()" call in the current version of "bpf_filter()" is done if it sees a bad opcode in the BPF code it's trying to interpret. > Could you confirm that changing dynamically the filter expression is > supported by pcap ?. As far as I know, we never explicitly said it *wasn't* supported. I can't, however, say that we've either rigorously tested that, or rigorously audited the code to make sure it's not *buggy*. > I wonder what could occur in pcap if the code is > interrupted by a new packet to process on the interface while changing at > the same time the filter expression. Well, first of all, in your example, you're not processing code from an interface, you're processing code from a savefile: > #3 0x9624c in pcap_offline_read () at snss7btnup.c:2074 unless the debugger is even *more* confused and thinks you're calling "pcap_offline_read()" when you're actually calling "pcap_read()". Second of all, the code doesn't get "interrupted" by a new packet; packets are read only by the calls to "pcap_read()", for live captures, or "pcap_offline_read()", for savefiles, in "pcap_loop()". So, unless you're changing the filter in a signal handler, it *can't* start filtering a packet while it's in the middle of changing the filter expression. If it were, Bad Things could happen, as there's no mutex on the filter - but, as indicated, that's *not* what's happening (there's no signal handler in the stack trace). A quick look at "install_bpf_filter()" (the routine that does the work for "pcap_setfilter()", freeing the old filter and installing the new one) and the code that uses the filter doesn't show any obvious way in which installing a new filter would cause a problem *if it succeeds*. (Any code that calls "pcap_setfilter()" should, of course, check whether it returns -1 and, if so, should not continue processing.) - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
