Re: malloc failure in a KEXT
Re: malloc failure in a KEXT
- Subject: Re: malloc failure in a KEXT
- From: Joe van Tunen <email@hidden>
- Date: Tue, 16 Jun 2009 14:28:51 -0700
- Thread-topic: malloc failure in a KEXT
> From: Satyen Lele <email@hidden>
> Date: Tue, 16 Jun 2009 13:18:02 -0700
>
> I am trying to debug a peculiar problem with malloc() failure inside a KEXT,
> when it is trying to allocate a struct of 9184 bytes size. malloc() returns
> ENOMEM after about 1139 such allocations that¹s just under 10MB. This
> problem is only reproducible on the two Mac Pros with 2GB RAM and Mac OS X
> 10.4.11. I panic¹ed the system in the KEXT just after malloc returned error.
> Using zprint in gdb, I checked various memory zones and comparing the TOT_SZ
> and MAX_SZ, I can see 1 zone to be running out of space. However, if ELT_SZ
> is the allocation size of each element in the zone, it does not match the
> allocation that is failing.
>
> ZONE COUNT TOT_SZ MAX_SZ ELT_SZ ALLOC_SZ NAME
> 0x01f6ee40 2438 2bdfdc 2be000 44
> 1000 kernel map entries
>
> I have tried building the KEXT on a couple of Mac OS X and XCode combinations
> 10.4.7+XCode2.5, 10.5.6+XCode3.1.2.
>
> How do I debug this problem?
> Is there a way to find out which zone is being used for malloc()?
> What do all the labels in zprint actually mean?
>
> Thanks,
> -s.
Looking at the source code for malloc would answer your questions I think.
MALLOC calls kalloc which calls kalloc_canblock which calls kmem_alloc
(kmem_alloc is called instead of zalloc_canblock because the requested size,
9184 bytes, is greater than 8192 bytes). zalloc_canblock works on a zone
(one of the zones kalloc.1 to kalloc.8192) but kmem_alloc works on a vm_map
called kalloc_map.
There is a gdb command called zprint (from /Volumes/KernelDebugKit/kgmacros)
which is similar to the shell command of the same name but it does not print
fake zones such as kalloc.large (see
/SourceCache/xnu/xnu-792.24.17/osfmk/kern/zalloc.c for a list of fake
zones). kalloc.large is a fake zone representing the kalloc_map vm_map. A
real zone has fixed sized elements. For the elem size column for
kalloc.large, the shell zprint command prints the average size of the
variable sized allocations. For the max size column, the shell zprint
command prints the most bytes allocated for kalloc.large but for real zones
it prints the maximum (that would be 16 MB for kalloc.large). The faked zone
information for kalloc.large is provided by the kalloc_fake_zone_info
function. That function uses the variables kalloc_large_inuse,
kalloc_large_total, kalloc_large_max which all can be printed in gdb.
The following command in gdb can print the entries of the vm_map used by
kalloc.large:
showmapvme kalloc_map
This command will show the number of bytes used as greater than the number
given by the zprint command (kalloc_large_total) because allocations are
page aligned (4096 bytes per page) in vm_maps and the zprint info for
kalloc.large does not take that into account like it does for real zones.
You can modify showmapvme in kgmarcros to also print the sizes of free
ranges. When you do that, you can see that even though more than 9184 bytes
might be free, the largest free range is less than that and thus would cause
MALLOC to fail.
On Tiger (OS X 10.4) the kalloc.large vm_map has a hard limit of 16 MB
compared to Leopard's (10.5) hard limit of 128 MB.
9184 bytes takes 3 pages = 12k.
12k * 1139 = 13.3 MB.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden