linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@transmeta.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [patch] kksymoops-2.5.38-C9
Date: Thu, 26 Sep 2002 09:36:37 -0500 (CDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0209260914170.6032-100000@chaos.physics.uiowa.edu> (raw)
In-Reply-To: <Pine.LNX.4.44.0209261536020.18328-100000@localhost.localdomain>

On Thu, 26 Sep 2002, Ingo Molnar wrote:

> in the attached kksymoops patch (against BK-curr) has the following fixes
> over yesterday's version:

I know this seems to be a never ending story to get exactly right, but 
anyway, more comments.

> kksymoops-disabled, modules-enabled output:
> 
> --------->
> kernel BUG at time.c:100!
> invalid operand: 0000
> 
> CPU:    1
> EIP:    0060:[<c011ddd4>]    Not tainted
> EFLAGS: 00010246
> eax: 0000004e   ebx: cf0fe000   ecx: 00000000   edx: 00000068
> esi: 00000000   edi: 00000000   ebp: bffffad8   esp: cf0fffa0
> ds: 0068   es: 0068   ss: 0068
> Process gettimeofday (pid: 569, threadinfo=cf0fe000 task=cf418060)
> Stack: 4001695c bffff414 40156154 00000004 c0112b50 cf0fe000 400168e4 bffffb44
>        c0107973 00000000 00000000 40156154 400168e4 bffffb44 bffffad8 0000004e
>        0000002b 0000002b 0000004e 400cecc1 00000023 00000246 bffffacc 0000002b
> Call Trace: [<c0112b50>] [<c0107973>]

Actually, in this case I would have expected to get the symbols resolved
using the exported symbols the kernel knows anyway. I can see two possible
explanations for that not happening: The addresses are lower than the
first exported symbol (look in /proc/ksyms to check), or (more likely)
there is still a bug in the address_to_exported_symbol() function.

I wondered initially, if it even makes any sense to use exported symbols 
only for resolving an address, but it actually is useful in the case of 
modules. For one reason, it actually names the module which the crash 
occured in, and given the module it also allows to actually find out where 
exactly the problem happened, which you normally cannot do, since you do 
not know which address the module was loaded at.

> @@ -137,15 +136,16 @@
>  	if (!stack)
>  		stack = (unsigned long*)&stack;
>  
> -	printk("Call Trace: ");
> +	printk("Call Trace:");
> +#if CONFIG_KALLSYMS

I think this should be || CONFIG_MODULES (see above)

> +	printk("\n");
> +#endif
>  	i = 1;
>  	while (((long) stack & (THREAD_SIZE-1)) != 0) {
>  		addr = *stack++;
>  		if (kernel_text_address(addr)) {
> -			if (i && ((i % 6) == 0))
> -				printk("\n   ");
> -			printk("[<%08lx>] ", addr);
> -			i++;
> +			printk(" [<%08lx>]", addr);
> +			print_symbol("%s\n", addr);
>  		}
>  	}
>  	printk("\n");

This will produce rather ugly output when the call trace is longer than
what fits in one line, since no one is adding "\n" then at all.

(This can be done with an ifdef, to avoid it I used the return value of
print_symbol() before, which is not really all that nice, either).
Maybe it's better to bite the bullet, use one #ifdef and get both cases 
separate, even if that's a slight duplication of code. (Oh, and I think 
most code uses #ifdef not #if, though of course both works the same)


> --- linux/include/linux/module.h.orig	Fri Sep 20 17:20:32 2002
> +++ linux/include/linux/module.h	Thu Sep 26 15:31:15 2002

> +extern void print_symbol(const char *fmt, unsigned long address);
> +
> +#else
> +
> +static inline int
> +print_symbol(const char *fmt, unsigned long address)
> +{
> +	return -ESRCH;
> +}
> +
>  #endif
>  
>  #endif /* _LINUX_MODULE_H */

You missed converting the return value of the inline variant.


--Kai





  reply	other threads:[~2002-09-26 14:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-26 14:01 Ingo Molnar
2002-09-26 14:36 ` Kai Germaschewski [this message]
2002-10-02 11:16 ` Gianni Tedesco

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=Pine.LNX.4.44.0209260914170.6032-100000@chaos.physics.uiowa.edu \
    --to=kai@tp1.ruhr-uni-bochum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@transmeta.com \
    --subject='Re: [patch] kksymoops-2.5.38-C9' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).