From: Ville Herva <vherva@niksula.hut.fi>
To: clock@atrey.karlin.mff.cuni.cz
Cc: linux-kernel@vger.kernel.org
Subject: Re: kmalloc size too large
Date: Sun, 23 Jun 2002 16:12:26 +0300 [thread overview]
Message-ID: <20020623131226.GE1548@niksula.cs.hut.fi> (raw)
In-Reply-To: <20020623104012.B532@ghost.cybernet.cz>
On Sun, Jun 23, 2002 at 10:40:12AM +0200, you [clock@atrey.karlin.mff.cuni.cz] wrote:
> 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.
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?
> Kernel 2.2.20
-- v --
v@iki.fi
diff -aur ../linux/arch/i386/kernel/traps.c ./arch/i386/kernel/traps.c
--- ../linux/arch/i386/kernel/traps.c Fri Nov 2 18:39:05 2001
+++ ./arch/i386/kernel/traps.c Sun Jun 23 16:00:29 2002
@@ -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;
diff -aur ../linux/include/linux/kernel.h ./include/linux/kernel.h
--- ../linux/include/linux/kernel.h Sun Mar 25 19:31:03 2001
+++ ./include/linux/kernel.h Mon Dec 10 19:53:42 2001
@@ -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)));
next prev parent reply other threads:[~2002-06-23 13:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-23 8:40 clock
2002-06-23 13:12 ` Ville Herva [this message]
2002-06-23 13:25 ` Ville Herva
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020623131226.GE1548@niksula.cs.hut.fi \
--to=vherva@niksula.hut.fi \
--cc=clock@atrey.karlin.mff.cuni.cz \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®