hutao | 2 Sep 09:46 2010

crash does not get proper backtrace?

Hi,

I got a problem where it seemed crash got a bad backtrace.
The problem occurred under the following conditions:
On a qemu guest system loading a module that stuck at
the init function(say, call a function that did deadlooping),
then dumped the guest by `virsh dump vm dumpfile', and run
crash on the dumpfile.

The module is:

---
#include <linux/module.h>

int endless_loop(void)
{
	printk("endless loop\n");
	while (1);

	return 0;
}

int __init endless_init(void)
{
	endless_loop();

	return 0;
}
module_init(endless_init);

(Continue reading)

hutao | 2 Sep 10:23 2010

Re: crash does not get proper backtrace?

On Thu, Sep 02, 2010 at 03:46:00PM +0800, hutao <at> cn.fujitsu.com wrote:
> Hi,
> 
> I got a problem where it seemed crash got a bad backtrace.
> The problem occurred under the following conditions:
> On a qemu guest system loading a module that stuck at
> the init function(say, call a function that did deadlooping),
> then dumped the guest by `virsh dump vm dumpfile', and run
> crash on the dumpfile.
> 
> The module is:
> 
> ---
> #include <linux/module.h>
> 
> int endless_loop(void)
> {
> 	printk("endless loop\n");
> 	while (1);
> 
> 	return 0;
> }
> 
> int __init endless_init(void)
> {
> 	endless_loop();
> 
> 	return 0;
> }
> module_init(endless_init);
(Continue reading)

Dave Anderson | 2 Sep 14:44 2010
Picon

Re: crash does not get proper backtrace?


----- hutao <at> cn.fujitsu.com wrote:

> Hi,
> 
> I got a problem where it seemed crash got a bad backtrace.
> The problem occurred under the following conditions:
> On a qemu guest system loading a module that stuck at
> the init function(say, call a function that did deadlooping),
> then dumped the guest by `virsh dump vm dumpfile', and run
> crash on the dumpfile.
> 
> The module is:
> 
> ---
> #include <linux/module.h>
> 
> int endless_loop(void)
> {
> 	printk("endless loop\n");
> 	while (1);
> 
> 	return 0;
> }
> 
> int __init endless_init(void)
> {
> 	endless_loop();
> 
> 	return 0;
(Continue reading)

Dave Anderson | 2 Sep 14:55 2010
Picon

Re: crash does not get proper backtrace?


----- hutao <at> cn.fujitsu.com wrote:

> On Thu, Sep 02, 2010 at 03:46:00PM +0800, hutao <at> cn.fujitsu.com wrote:
> > Hi,
> > 
> > I got a problem where it seemed crash got a bad backtrace.
> > The problem occurred under the following conditions:
> > On a qemu guest system loading a module that stuck at
> > the init function(say, call a function that did deadlooping),
> > then dumped the guest by `virsh dump vm dumpfile', and run
> > crash on the dumpfile.
> > 
> > The module is:
> > 
> > ---
> > #include <linux/module.h>
> > 
> > int endless_loop(void)
> > {
> > 	printk("endless loop\n");
> > 	while (1);
> > 
> > 	return 0;
> > }
> > 
> > int __init endless_init(void)
> > {
> > 	endless_loop();
> > 
(Continue reading)

KAMEZAWA Hiroyuki | 3 Sep 02:17 2010

Re: crash does not get proper backtrace?

On Thu, 2 Sep 2010 08:44:12 -0400 (EDT)
Dave Anderson <anderson <at> redhat.com> wrote:

> 
> ----- hutao <at> cn.fujitsu.com wrote:
> 
> > Hi,
> > 
> > I got a problem where it seemed crash got a bad backtrace.
> > The problem occurred under the following conditions:
> > On a qemu guest system loading a module that stuck at
> > the init function(say, call a function that did deadlooping),
> > then dumped the guest by `virsh dump vm dumpfile', and run
> > crash on the dumpfile.
> > 
> > The module is:
> > 
> > ---
> > #include <linux/module.h>
> > 
> > int endless_loop(void)
> > {
> > 	printk("endless loop\n");
> > 	while (1);
> > 
> > 	return 0;
> > }
> > 
> > int __init endless_init(void)
> > {
(Continue reading)

hutao | 3 Sep 09:43 2010

Re: crash does not get proper backtrace?

On Thu, Sep 02, 2010 at 08:55:38AM -0400, Dave Anderson wrote:
> 
> ----- hutao <at> cn.fujitsu.com wrote:
> 
> > On Thu, Sep 02, 2010 at 03:46:00PM +0800, hutao <at> cn.fujitsu.com wrote:
> > > Hi,
> > > 
> > > I got a problem where it seemed crash got a bad backtrace.
> > > The problem occurred under the following conditions:
> > > On a qemu guest system loading a module that stuck at
> > > the init function(say, call a function that did deadlooping),
> > > then dumped the guest by `virsh dump vm dumpfile', and run
> > > crash on the dumpfile.
> > > 
> > > The module is:
> > > 
> > > ---
> > > #include <linux/module.h>
> > > 
> > > int endless_loop(void)
> > > {
> > > 	printk("endless loop\n");
> > > 	while (1);
> > > 
> > > 	return 0;
> > > }
> > > 
> > > int __init endless_init(void)
> > > {
> > > 	endless_loop();
(Continue reading)

CAI Qian | 5 Sep 17:39 2010
Picon

Fwd: crash failure with 2.6.36-rc3 vmcore


----- Forwarded Message -----
From: "CAI Qian" <caiqian <at> redhat.com>
To: "Dave Anderson" <anderson <at> redhat.com>, "guenter roeck" <guenter.roeck <at> ericsson.com>,
tj <at> kernel.org, gregkh <at> suse.de
Cc: "linux-kernel" <linux-kernel <at> vger.kernel.org>
Sent: Saturday, September 4, 2010 2:01:06 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
Subject: crash failure with 2.6.36-rc3 vmcore

> crash> mod -S
> 
> mod: invalid structure member offset: attribute_owner
>      FILE: symbols.c  LINE: 8577  FUNCTION: add_symbol_file_kallsyms()
> 
>      MODULE       NAME                   SIZE  OBJECT FILE
> ffffffffa000de60  dm_mod                76230 
> /lib/modules/2.6.36-rc2-mm1-wqfix-mkdfix+/kernel/drivers/md/dm-mod.ko
> [/usr/bin/crash] error trace: 4affb0 => 4f3236 => 4f12b5 => 4e587a
> 
>   4e587a: OFFSET_verify.clone.4+186
>   4f12b5: add_symbol_file+933
>   4f3236: load_module_symbols+566
>   4affb0: do_module_cmd+1264
> 
> mod: invalid structure member offset: attribute_owner
>      FILE: symbols.c  LINE: 8577  FUNCTION: add_symbol_file_kallsyms()
This failure was due to this commit,

commit 6fd69dc578fa0b1bbc3aad70ae3af9a137211707
Author: Guenter Roeck <guenter.roeck <at> ericsson.com>
(Continue reading)

CAI Qian | 5 Sep 17:39 2010
Picon

Fwd: another crash failure with 2.6.36-rc3 vmcore


----- Forwarded Message -----
From: caiqian <at> redhat.com
To: "Dave Anderson" <anderson <at> redhat.com>
Cc: "linux-kernel" <linux-kernel <at> vger.kernel.org>, npiggin <at> kernel.dk, "tim c chen"
<tim.c.chen <at> linux.intel.com>, ak <at> linux.intel.com, viro <at> zeniv.linux.org.uk
Sent: Saturday, September 4, 2010 7:29:38 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
Subject: another crash failure with 2.6.36-rc3 vmcore

> crash> mount -f
>     VFSMOUNT         SUPERBLK     TYPE   DEVNAME                      
>       DIRNAME
> ffff88046e367e80 ffff880c6e4e9400 rootfs rootfs                       
>       /
> mount: invalid kernel virtual address: 18278  type: "first list entry"
Dave, this failure is due to this commit,

commit 6416ccb7899960868f5016751fb81bf25213d24f
Author: Nick Piggin <npiggin <at> kernel.dk>
Date:   Wed Aug 18 04:37:38 2010 +1000

    fs: scale files_lock

    fs: scale files_lock

    Improve scalability of files_lock by adding per-cpu, per-sb files lists,
    protected with an lglock. The lglock provides fast access to the per-cpu lists
    to add and remove files. It also provides a snapshot of all the per-cpu lists
    (although this is very slow).

(Continue reading)

KAMEZAWA Hiroyuki | 6 Sep 04:34 2010

Re: crash does not get proper backtrace?

On Thu, 2 Sep 2010 08:44:12 -0400 (EDT)
Dave Anderson <anderson <at> redhat.com> wrote:

> 
> ----- hutao <at> cn.fujitsu.com wrote:
> 
> > Hi,
> > 
> > I got a problem where it seemed crash got a bad backtrace.
> > The problem occurred under the following conditions:
> > On a qemu guest system loading a module that stuck at
> > the init function(say, call a function that did deadlooping),
> > then dumped the guest by `virsh dump vm dumpfile', and run
> > crash on the dumpfile.
> > 
> > The module is:
> > 
> > ---
> > #include <linux/module.h>
> > 
> > int endless_loop(void)
> > {
> > 	printk("endless loop\n");
> > 	while (1);
> > 
> > 	return 0;
> > }
> > 
> > int __init endless_init(void)
> > {
(Continue reading)

Dave Anderson | 7 Sep 15:48 2010
Picon

[PLEASE NOTE] LKML and the crash-utility mailing list


Please do NOT clutter the LKML with crash utility failures that are caused by
recent changes to the upstream kernel.

The crash utility by definition will require constant updates in order to
handle the changes being made to the upstream kernel that affect subsystems
that crash depends upon.

It has always been that way, and always will, and is one of the major reasons
that I generally release a new version every month.

While I do appreciate reports on *this* mailing list that spotlight the specific
upstream kernel patch that causes breakage to the crash utility, it serves
no purpose to post those findings on the LKML.  THEY ARE NOT KERNEL BUGS.

Thanks,
  Dave


Gmane