site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245259214; bh=QTbBJJjMyI2v9Ia+J1joys8wYN6tK0SDVe91bDlM5ps=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xrI2WPNsZEKfxKT38hnA6jhtl+I95k7kBWHNzlMoI42wuKawspC03CgNMf+Q8CbajcYL55a3Hgg99AfmTLT7UUb1P68oaACiLd/fjp0/+3GIESUSy2uMQRacBPAfPzqVYICzQOwPg2imUFml4XKscrEHrg2I6nCKwCdJ+rbVIG8= Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4ueX+Z6Hfbw1NGkY2sxx2RMR74Jf50dtilNW1Yc5U2KyjkzJRTal6yRp5A/eIthqidTGrfUyoDOvRt4VkxOiIH/MPWx62MRqcdipA0gJ7NXafGuKdQ3uZ8MqoQcHVBrH1Ck9lkpioS+s8cvLYnusZjod7ya75FlzsFYR4XEvgb4=; Thank you so much. This was tremendously useful. I see that kalloc.large zone is almost full with holes of 4k and 8k - too small to satisfy a request of 3 pages. I must acknowledge the other reply by Michael Smith as well. I fully agree that the need for allocating separate thousands of malloc() requests is a result of a poor design for performance reason. However, I needed to understand why malloc() would fail in this way on 10.4 only. Thanks for the help. -s. ----- Original Message ---- From: Satyen Lele <SLele@Omneon.com> To: satyen_lele@yahoo.com Sent: Tuesday, June 16, 2009 2:53:40 PM Subject: Re: malloc failure in a KEXT From: Joe van Tunen [mailto:joseph.vantunen@pearson.com] Sent: Tuesday, June 16, 2009 2:29 PM To: Satyen Lele; Darwin Kernel Subject: Re: malloc failure in a KEXT
From: Satyen Lele <SLele@Omneon.com> 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com