Date: Wed, 24 Nov 2004 18:07:43 +0000 From: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> To: Nate Lawson <nate@root.org> Cc: freebsd-current@freebsd.org Subject: Re: Memory modified after free: Most recently used by acpitask Message-ID: <1101319662.56574.141.camel@buffy.york.ac.uk> In-Reply-To: <41A4BB82.2010406@root.org> References: <1101312453.56574.122.camel@buffy.york.ac.uk> <41A4BB82.2010406@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2004-11-24 at 16:49, Nate Lawson wrote: > Gavin Atkinson wrote: > > Hi, > > > > Just got a panic on a 6-CURRENT (Thu Nov 18 16:36:35 GMT 2004) machine, > > while copying a large amount of data around. > > > > Seems to be an ACPI related reuse-after-free. As far as I can tell, 20 > > bytes into the acpi_task structure is (int)ta_flags within the embedded > > struct task, but I can't see use of this field in the ACPI code so ACPI > > may be a red herring. > > > > > > # cp -Rp /usr/* /var/usr > > [about 10 minutes later] > > Memory modified after free 0xc44a8420(28) val=0 @ 0xc44a8434 > > panic: Most recently used by acpitask > > Unfortunately, the panic message doesn't tell you who modified it since > someone with a stray pointer (say, who allocated/freed it before acpi) > could overwrite it and it was only detected on the next malloc. The way > I've found these is to boot -d (into ddb) and type "watch 0xc44a8420". > Then hit "c" to continue the boot. Dump a "tr" any time the watchpoint > triggers and look for suspicious callers. Sadly, I suspect it's not going to be that easy. I've just had another panic, same trigger and symptoms but different memory address. Memory modified after free 0xc50441c0(28) val=0 @ 0xc50441d4 panic: Most recently used by acpitask cpuid = 0 KDB: enter: panic [thread 100111] Stopped at kdb_enter+0x2c: leave I'll try taking the box to top-of-tree current in case it has already been fixed - however that will probably have to wait until tomorrow now as this machine cannot reboot without physical help. Surely it seems like quite a coincidence that both times it was 20 bytes into memory once owned by acpitask, though? Gavin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1101319662.56574.141.camel>