Another mapping DB issue: uses memory after free()

Hi,

it seems that I encountered another issue of the (new) mapping database:
All I do is starting Sigma0, a root task and a hello application. Hello
requests a 4K (address 0x02000000) from the root task. Then, hello
requests root task to unmap this page again. During the unmap operation
an assertion is triggered and the kmem free list ist destroyed.

  [for better readability, I have disabled word wrap of my MUA]

mdb
/mdb> dumpallmem
00000000 table [objsize=4M  radix=1024  count=11] (f3001030)
  00000000 table [objsize=4K  radix=1024  count=913] (f3001020)
    00000000 [1] vaddr: 00000000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f30056b4)
    00001000 [1] vaddr: 00001000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f3005f24)

  ...

  01000000 [1] vaddr: 01000000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f300572c)
    01000000 table [objsize=4K  radix=1024  count=8] (f3001050)
      01000000 [2] vaddr: 01000000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300ed30)
      01001000 [2] vaddr: 01001000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300ed6c)
      01002000 [2] vaddr: 01002000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300ed94)
      01003000 [2] vaddr: 01003000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300ed80)
      01004000 [2] vaddr: 01004000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300edbc)
      01005000 [2] vaddr: 01005000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300ed58)
      01006000 [2] vaddr: 01006000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300eda8)
      01007000 [2] vaddr: 01007000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300ed44)
  01400000 [1] vaddr: 01400000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f3005718)
  01800000 [1] vaddr: 01800000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f3005704)
  01c00000 [1] vaddr: 01c00000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f30056f0)
  02000000 [1] vaddr: 02000000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f30056dc)
    02000000 table [objsize=4K  radix=1024  count=1] (f3001060)
      02000000 [2] vaddr: 02000000  spc: f3010000  rights: [o=rwx i=rwx e=rwx] (f300edd0)
  02400000 [1] vaddr: 02400000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f30056c8)
  02800000 [1] vaddr: 02800000  spc: f035c000  rights: [o=rwx i=rwx e=rwx] (f30056a0)
/mdb> up
> tracepoints
/tracepoints> enableall
/tracepoints> up
> stats
/stats> kmem
kmem_free_list = f300d400
Kernel memory statistics:
  Chunk size  = 1024 bytes
  Free chunks = 16268 (15MB)

  Consecutive   Number of
  chunks        matches
        1        16268
        2         8133
        4         4066
        8         2033
       16         1016
       32          508
       64          254
      128          127
      256         63
      512           31
     1024+          26

  Max consecutive chunks: 8192

Kernel memory distribution:
  kmem_iofp            24 KB
  kmem_mdb             57 KB
  kmem_misc             4 MB
  kmem_pgtab           84 KB
  kmem_resources        0 KB
  kmem_space           48 KB
  kmem_tcb             16 KB
  kmem_utcb            12 KB

/stats> up
> go

  [root task now performs unmap on physical page 0x02000000]

SYS_UNMAP: control=0x0 (num=0, flush=0) eip=0xbff008c6
unmap_fpage (f_spc=f035c000  f_fp=020000c7)
mem::mapctrl (f30056dc, 80 [~~~~u~], 0, 00000000) phys=02000000
free(00001000 @ f301b000) from f0316c2b
kmem_free (f301b000, 4096 [4K]), ip: f0316c2b
--- "KD# assert" ---
------------------------------- (eip=f03173e5, esp=f0325fa0) ---
 stats
/stats> kmem
kmem_free_list = f300d400
Kernel memory statistics:
  Chunk size  = 1024 bytes
  Free chunks = 16272 (15MB)

  Consecutive   Number of
  chunks        matches
        1            4
        2            1
        4            0
        8            0
       16            0
       32            0
       64            0
      128            0
      256            0
      512            0
     1024+           0

  Max consecutive chunks: 2

Kernel memory distribution:
  kmem_iofp            24 KB
  kmem_mdb             53 KB
  kmem_misc             4 MB
  kmem_pgtab           84 KB
  kmem_resources        0 KB
  kmem_space           48 KB
  kmem_tcb             16 KB
  kmem_utcb            12 KB
>

  [the kmem_free_list is destroyed!]

To find out how destroys the kmem_free_list I forced Pistachio to enter the
kernel debugger after kmem::free(f301b000, ...) was called. Then I set a
hardware write breakpoint to address f301b000.

The kernel debugger was entered again from inside mdb_t::mapctrl().

Please tell me if you need more information.

Frank
-- 
## InnoTek Systemberatung GmbH, http://www.innotek.de ##

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBEmU636z8pigLf3EcRAlGZAKCIA0igpIagECwqDZjqni3DgJo/ywCfUU5i
MczUMU2BHCESbEGf7mUUTGA=
=z4Sx
-----END PGP SIGNATURE-----