Forum for usage questions, reporting bugs, posting patches, and requesting features for the crash utility

hutao | 2 Sep 2010 09:46

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 2010 10:23

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 2010 14:44

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 2010 14:55

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 2010 02:17

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 2010 09:43

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 2010 17:39

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 2010 17:39

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 2010 04:34

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 2010 15:48

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

Group

gmane.linux.kernel.crash-dump.crash-utility.

Advertisement

Project Web Page

Forum for usage questions, reporting bugs, posting patches, and requesting features for the crash utility

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6

Articles in period: 54

September 2010

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Fw: Cross architecture analysis for Crash (19 Jun 2013)
[ANNOUNCE] crash-7.0.1 is available (17 Jun 2013)
x86_64: Function parameters from stack frames (6 Jun 2013)
[PATCH] s390x: Fix linux-3.10 backtrace for interrupt stacks (4 Jun 2013)
[Patch v4] Show module taint flags (19 May 2013)
EPPIC: fails to build in crash-7.0.0/gdb-7.6 environment (17 May 2013)
[ANNOUNCE] crash gcore command, version 1.2.1 is released (14 May 2013)
[ANNOUNCE] crash-7.0.0 is available (10 May 2013)
[PATCH v3] Show module taint flags (7 May 2013)
HEADS-UP: Linux kernel 3.9 debuginfo issues (30 Apr 2013)
How do I get IA64 register R32 and above? (23 Apr 2013)
fix bug of struct command (12 Apr 2013)
Threaded crash tool? Is it time? (12 Apr 2013)
'crash' compilation on Arch fails with -D_FORTIFY_SOURCE=2 (11 Apr 2013)
[ANNOUNCE] crash version 6.1.6 is available (4 Apr 2013)
Packaging eppic (2 Apr 2013)
[PATCH] kmem option to display pages per migrate type (29 Mar 2013)
[PATCH] fix bug of gdb involved by gdb-7.3.1.patch (29 Mar 2013)
[ANNOUNCE] crash-6.1.5 is available (28 Mar 2013)
A possible "dev -d" fix for newer kernels (27 Mar 2013)
[PATCH v2] Add -m option to kmem (27 Mar 2013)

Archives

7	June 2013
12	May 2013
32	April 2013
178	March 2013
42	February 2013
55	January 2013
35	December 2012
54	November 2012
72	October 2012
39	September 2012
106	August 2012
73	July 2012
68	June 2012
74	May 2012
86	April 2012
138	March 2012
201	February 2012
150	January 2012
61	December 2011
39	November 2011
74	October 2011
74	September 2011
7	August 2011
6	July 2011
45	June 2011
57	May 2011
34	April 2011
46	March 2011
59	February 2011
96	January 2011
16	December 2010
43	November 2010
57	October 2010
53	September 2010
61	August 2010
1	July 2010
39	June 2010
33	May 2010
30	April 2010
31	March 2010
69	February 2010
37	January 2010
23	December 2009
20	November 2009
25	October 2009
63	September 2009
32	August 2009
10	July 2009
35	June 2009
36	May 2009
61	April 2009
12	March 2009
38	February 2009
84	January 2009
28	December 2008
43	November 2008
99	October 2008
55	September 2008
59	August 2008
14	July 2008
3	June 2008
33	May 2008
40	April 2008
92	March 2008
40	February 2008
27	January 2008
39	December 2007
48	November 2007
30	October 2007
89	September 2007
31	August 2007
77	July 2007
11	June 2007
68	May 2007
28	April 2007
54	March 2007
30	February 2007
51	January 2007
65	December 2006
56	November 2006
99	October 2006
54	September 2006
62	August 2006
27	July 2006
9	June 2006

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template