Gavin Atkinson wrote: > On Wed, 2004-11-24 at 16:49, Nate Lawson wrote: > >>Gavin Atkinson wrote: >>># cp -Rp /usr/* /var/usr >>>[about 10 minutes later] >>>Memory modified after free 0xc44a8420(28) val=0 _at_ 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 _at_ 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? The only coincidence is it's likely the same component causing this problem. acpi is probably only a victim. FYI, in August I fixed an overflow in ATA that had the same symptoms of overwriting an ACPI struct (although that doesn't mean this is caused by ATA). -NateReceived on Wed Nov 24 2004 - 17:28:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:23 UTC