Hi Linus, On Fri, Jan 18, 2013 at 05:12:11PM +0100, Linus Nordberg wrote:
> FWIW, while playing around with mappings I managed to provoke segfaults > in the memory plugin: > > nfacctd[21723]: segfault at 9d49018 ip 0809aed2 sp bff11730 error 4 in > nfacctd[8048000+a3000] > > It's strictly related to invocations of `pmacct -s'. Haven't had the > chance to hunt it down yet (gdb and threaded programs, how does it work?;)) > but let me know if you're interested in more details on this. We're running > recent CVS. Thanks for reporting this. Well, one thing actually good to check first (easy one!) is that you are not running out of memory. That not being the case you can do the following: * recompile the pmacct package as usual but adding the --enable-debug switch to the command-line. * invoke nfacctd from with gdb enabling only a single plugin: the memory one that after will crash, ie. gdb /path/to/nfacctd * within gdb point the configuration file you want to use, set gdb to follow childs upon forks and run the daemon, ie. (gdb) set args /path/to/nfacctd.conf (gdb) set follow-fork-mode child (gdb) run * let it crash and collect information as usual (ie. backtrace) Alternatively, if you have a way to reproduce and you can provide remote access to the box - i will happily look into this for you. Either way, if it gets deeply into the debugging/troubleshooting part of this, ie. discussion not of general interest, feel free to switch to unicast emails. Cheers, Paolo _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
