|
From: | Will Bryant |
Subject: | Re: Double-free bug |
Date: | Thu, 21 Dec 2006 14:14:13 +1300 |
Hi guys,
I eventually managed to reproduce the double-free bug I mentioned on the general list, which happened on one of my production servers and more or less knocked it over. Here's the stack trace:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7ca1770 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7ca2ef3 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7cd6d0b in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7cdf1cd in free () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7ce053e in calloc () from /lib/tls/i686/cmov/libc.so.6
#6 0x08060d18 in xcalloc (count=1, nbytes=16) at xmalloc.c:93
#7 0x0806d6f2 in addeventaction (_ea=0x80ad5a0, failed=1, passed=1) at p.y:2334
#8 0x0806dc77 in createservice (type=3, name=0x811b308 "renderd", value=0x80e6260 "/var/run/modellure/renderd.pid",
check=0x805f010 <check_process>) at p.y:1799
#9 0x08071909 in yyparse () at p.y:705
#10 0x08071e3a in parse (controlfile=0x8098410 "/etc/monit/monitrc") at p.y:1633
#11 0x080525d4 in main (argc=7, argv=0xbfbd9614) at monitor.c:225
Is that enough info to diagnose the problem? It looks to me like it could just be due to an uninitialized structure, but I don't understand enough of the code yet to say.
Will
[Prev in Thread] | Current Thread | [Next in Thread] |