On Wednesday 2009-06-24 13:17, Krzysztof Oledzki wrote: > On Wed, 24 Jun 2009, Bernhard Schmidt wrote: >> On Wed, Jun 24, 2009 at 12:39:58AM +0200, Bernhard Schmidt wrote: >> >> Hi, >> >>> Oh, and we're dumping conntrack -L every minute. Works fine during the >>> day with 30k connections, but starts to frequently segfault with 60k >>> connections in the evening. Also trying to get a coredump now. >> >> sorry, this is slightly off-topic, but I can't decode the core dump :-( >> >> Jun 24 12:03:01 secomat2 kernel: conntrack[14117]: segfault at >> 7fff1ce83f34 ip 00007fff1ce83f34 sp 00007fff1ce82f20 error 15 > > I think you should rather try using valgrind. It is very hard to trace memory > corruption problem with gdb. A number of libc functions do not seem to always keep the stack pointers around, or when you are in a signal handler, so gdb is confused until these functions are exited. I have seen such even with programs that otherwise behave normally and which merely have been attached to with gdb. The solution there would be to set a breakpoint at a well-known function and let it continue, but in case of segfaults that barely works. Here, use valgrind to determine the faulty spot, then maybe run gdb on it (no attach, but direct run) and set a breakpoint before the spot is hit to examine the variables. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
