Hello Guy
Thank you for your note.
I am doing this on Solaris platform 2.6.
It is the application which crashes. I get each time a core dump.
Please find below the stack trace that I got with GDB by replaying the core
file.
tombarel-u5:216>gdb /users/tombarel/lib/snooper/src/snooper core
This version of gdb is for debugging native
applications. It is NOT a debugger that is able
to debug router images. Use:
gdb-bleeding.68k -- debug 68k router images
gdb-bleeding.mips64 -- debug MIPS r4k router images
gdb-bleeding.ppc -- debug power-pc router images
gdb-bleeding.r3k -- debug MIPS r3k router images
Problem reports should be directed to
[EMAIL PROTECTED]
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16.1-96q4 (sparc-sun-solaris2), Copyright 1996 Free Software
Foundation, Inc...
Core was generated by `/users/tombarel/lib/snooper/src/snooper offline
h323_ss7ctup_ni2.bin h225 ni2+'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libxnet.so.1...done.
Reading symbols from /usr/lib/libm.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
#0 0xef70820c in _libc_kill ()
(gdb) bt 1000
#0 0xef70820c in _libc_kill ()
#1 0xef6ba5d0 in abort ()
#2 0x966e0 in bpf_filter () at snss7btnup.c:2074
#3 0x9624c in pcap_offline_read () at snss7btnup.c:2074
#4 0x8e9b0 in pcap_loop () at snss7btnup.c:2074
#5 0x17d58 in util_packet_scheduler__FUi (display_type=4128) at snutil.c:798
#6 0x26c0c in main (argc=-1, argv=0xeffff17c, envp=0xeffff194) at
snmain.c:2750
(gdb) quit
According to this trace, the stack is currupted.
It said that pcap_loop () is invoked from "snss7btnup." which is false. In
my application, pcap_loop is invoked from "util_packet_scheduler" at
snutil.c:798 (like it is mentioned in the previous trace point).
In addition if I look at snss7btnup.c:2074 file, there is no code and it is
a blank line (the return address from the stack is corrupted).
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.
I am really stuck on this problem.
Could you confirm that changing dynamically the filter expression is
supported by pcap ?. 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.
Thank you for your help.
Regards,
Alain.
At 05:00 PM 12/3/2001 -0800, Guy Harris wrote:
> > I am now implementing some new features in my application which requires
> > to change dynamically the filtering expression.
> > I am invoking in my callback routine the "pcap_compile" and
> > "pcap_setfilter" functions in order to modify the filter expression
> > dynamically.
> > When doing that, the system crashes each time.
>
>On what OS are you doing this?
>
>By "system crashes", do you mean that the application crashes (core
>dump), or the entire system crashes (kernel panic/etc.)?
>
>If the entire system crashes, that's a kernel bug; report it to whoever
>maintains the OS (or its kernel), and supply a sample program.
>
>If the application crashes, could you show us a stack trace?
-
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
