Skip to contentSkip to conversation

kmalloc size too large

DISCUSSION [email protected] 2 participants 3 messages Jun 23, 2002

lore
Share & tools
lore

[email protected]

author
#0 lore raw

Hello

when dumping tracks from an IDE CD using cdda2wav I sometimes get this kernel message:

Jun 23 10:34:18 ghost kernel: kmalloc: Size (4294852048) too large
Jun 23 10:34:18 ghost kernel: kmalloc: Size (4294852048) too large
Jun 23 10:37:55 ghost last message repeated 29 times
Jun 23 10:37:55 ghost last message repeated 29 times

It is not deterministic but looks like some tracks cause it often and some not.

Kernel 2.2.20

Signature · 1 line
Karel 'Clock' Kulhavy
#1 lore raw
Quoted 5 lines · On Sun, Jun 23, 2002 at 10:40:12AM +0200, you [[email protected]]…

Hello

when dumping tracks from an IDE CD using cdda2wav I sometimes get this kernel message:

Quoted 7 lines
Jun 23 10:34:18 ghost kernel: kmalloc: Size (4294852048) too large
Jun 23 10:34:18 ghost kernel: kmalloc: Size (4294852048) too large
Jun 23 10:37:55 ghost last message repeated 29 times
Jun 23 10:37:55 ghost last message repeated 29 times

It is not deterministic but looks like some tracks cause it often and some not.

4294852048 = 0xfffe3dd0, ie. 115247 bytes less than 2^32. Someone is trying to allocate -115247 bytes. Is the number 4294852048 always?

You could first check if 2.2.21rc4 has any updates to ide cd relative to 2.2.20. (Better yet, try reproducing it on 2.2.21rc4).

To fix the bug one has find out which function does the faulty kmalloc() call. You could try kdb, kgdb etc. Or, you could add the show_stack() helper (patch below, I think it's originally by Keith Owens) and add

	show_stack(NULL);

right below the "kmalloc: Size (4294852048) too large" printk() call (find it with grep.) Once you trigger the bug with that patch, you should get a stack dump. Then you need to convert the addresses to symbol named using system.map (I'm not sure if ksymoops can do it directly, or if you have to do it by hand.)

One more thing: I'm not sure about the 4095 below. If the stack dump makes no sense, try 8195. (2.4 uses THREAD_SIZE-1 and THREAD_SIZE is 2*PAGE_SIZE (2*4096) on i386). ISTR the value changed during 2.2, but perhaps I'm wrong... Can anyone clarify this?

Quoted 1 line

Kernel 2.2.20

-- v --

[email protected]

arch/i386/kernel/traps.c renamed from linux/arch/i386/kernel/traps.c +50 -0
diff -aur ../linux/arch/i386/kernel/traps.c ./arch/i386/kernel/traps.c
@@ -120,6 +120,56 @@
 #define VMALLOC_OFFSET (8*1024*1024)
 #define MODULE_RANGE (8*1024*1024)
 
+
+/* Separate show_stack() so adhoc debugging code can use it */
+void show_stack(const unsigned long *esp)
+{
+       int i;
+       unsigned long *stack, *save_stack, addr, module_start, module_end;
+       printk("Stack: ");
+       /* show_registers passes a real esp, adhoc debugging passes NULL */
+       if (esp)
+               stack = (unsigned long *) esp;
+       else
+               asm("movl %%esp,%0": "=m" (stack));
+       save_stack = stack;
+       for(i=0; i < kstack_depth_to_print; i++) {
+               if (((long) stack & 4095) == 0)
+                       break;
+               if (i && ((i % 8) == 0))
+                       printk("\n       ");
+               printk("%08lx ", *stack++);
+       }
+       printk("\nCall Trace: ");
+       stack = save_stack;
+       i = 1;
+       module_start = PAGE_OFFSET + (max_mapnr << PAGE_SHIFT);
+       module_start = ((module_start + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1));
+       module_end = module_start + MODULE_RANGE;
+       while (((long) stack & 4095) != 0) {
+               addr = *stack++;
+               /*
+                * If the address is either in the text segment of the
+                * kernel, or in the region which contains vmalloc'ed
+                * memory, it *may* be the address of a calling
+                * routine; if so, print it so that someone tracing
+                * down the cause of the crash will be able to figure
+                * out the call path that was taken.
+                */
+               if (((addr >= (unsigned long) &_stext) &&
+                    (addr <= (unsigned long) &_etext)) ||
+                   ((addr >= module_start) && (addr <= module_end))) {
+                       if (i && ((i % 8) == 0))
+                               printk("\n       ");
+                       printk("[<%08lx>] ", addr);
+                       i++;
+               }
+       }
+       printk("\n");
+}
+
+
+
 static void show_registers(struct pt_regs *regs)
 {
 	int i;
include/linux/kernel.h renamed from linux/include/linux/kernel.h +1 -0
diff -aur ../linux/include/linux/kernel.h ./include/linux/kernel.h
@@ -53,6 +53,7 @@
 extern int vsprintf(char *buf, const char *, va_list);
 
 extern int session_of_pgrp(int pgrp);
+extern void show_stack(const unsigned long *); /* For adhoc debugging */
 
 asmlinkage int printk(const char * fmt, ...)
 	__attribute__ ((format (printf, 1, 2)));
#2 lore raw
In reply to [email protected]
Quoted 2 lines · On Sun, Jun 23, 2002 at 10:40:12AM +0200, you [[email protected]]…
Jun 23 10:34:18 ghost kernel: kmalloc: Size (4294852048) too large

Come to think of it, adding mere

        printk ("Current PID: %i\n", current->pid);
        printk ("called from %p\n", __builtin_return_address(0));

after

        printk(KERN_ERR "kmalloc: Size (%lu) too large\n", (unsigned long) size);

in mm/slab.c:kmalloc() might be enough.

-- v --

[email protected]