panic after boot - memory used after free

From: Nate Lawson <nate_at_root.org>
Date: Sat, 1 May 2004 13:27:58 -0700 (PDT)
A recent kernel with INVARIANTS gets a panic right after boot saying
memory has been used after free.  This happens when booting single user
and then immediately when the first command is run.  I'm tracking down the
source with hardware watch points.  This is 100% reproduceable with the
same addresses.  The panic message is:

... modified after free 0xc344b200(508) val=1000100 _at_ 0xc344b200

Watch points and a mod to malloc/free show the memory is modified:

1. Memory is first freed:
   free
   acpi_cmbat_get_bif
   acpi_cmbat_init_battery

2. Memory malloced/freed 4 times in:
   free
   g_bsd_try
   g_bsd_taste
   g_new_provider_event

3. Memory is written to during the ata1-slave probe:
   ata_pio_read(0xc34e6b40, 0x200) + 0x1b4
   ata_generic_interrupt + 0x605
   ata_timeout + 0x167
   softclock(0)

4. Finally, the trace of what triggers the panic is:
   mtrash_ctor+0x3a
   uma_zalloc_arg+0x169
   malloc+0xb7
   elf32_load_file+0x51
   exec_elf32_imgact+0x4c7
   kern_execve+0x34e
   execve+0x18

I think the ata_pio_read is suspicious because it accesses the memory even
though it did not appear to malloc it.  Here is the dmesg from a
non-INVARIANTS boot:

atapci0: <Intel ICH3 UDMA100 controller> port
0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1860
atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
ata0: at 0x1f0 irq 14 on atapci0
atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
ata1: at 0x170 irq 15 on atapci0
[...]
ad0: 19077MB <IC25N020ATCS04-0> [41344/15/63] at ata0-master UDMA100
ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt
ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt
acd0: CDRW <UJDA720 DVD/CDRW> at ata1-master PIO4

-Nate
Received on Sat May 01 2004 - 11:27:57 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:52 UTC