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. > > The problem is, we currently run conntrack -L every minute. It segfaults > about 20 times a day, usually during the period with the highest number > of connections. Unless I can always run conntrack in valgrind/gdb > automatically and get a usable dump when it fails I have a hard time to > get any information from it. Are you using latest version? -- 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
