FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 09-05-2012, 03:24 PM
Dave Anderson
 
Default : gcore extension, anonymous union in inode struct

----- Original Message -----
> Hi Crash people,
>
> The gcore extension fails on the 3.4 kernel I'm using. It attempts to
> find the offset of a member within the inode struct, but the member is
> part of an anonymous union. This patch fixes the problem for me.
>
> Regards,
> Per
>

Daisuke Hatayama is the maintainer of the gcore extension module, and he
typically updates the crash-gcore-command-<version>.tar.gz with proposed
patches.

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-06-2012, 12:11 AM
HATAYAMA Daisuke
 
Default : gcore extension, anonymous union in inode struct

From: Per Fransson <per.fransson.ml@gmail.com>
Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct
Date: Wed, 5 Sep 2012 12:29:43 +0200

> Hi Crash people,
>
> The gcore extension fails on the 3.4 kernel I'm using. It attempts to
> find the offset of a member within the inode struct, but the member is
> part of an anonymous union. This patch fixes the problem for me.
>
> Regards,
> Per

Hello Per,

Thanks for reporting that. According to git repository, this was
changed by the following commit at the v3.1 period.

$ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb
v3.1-8569-ga78ef70

$ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb
commit a78ef704a8dd430225955f0709b22d4a6ba21deb
Author: Miklos Szeredi <mszeredi@suse.cz>
Date: Fri Oct 28 14:13:30 2011 +0200

vfs: protect i_nlink

Prevent direct modification of i_nlink by making it const and adding a
non-const __i_nlink alias.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>

The patch appears fine to me so I'll apply it.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-11-2012, 12:50 PM
Dave Anderson
 
Default : gcore extension, anonymous union in inode struct

----- Original Message -----
> From: Per Fransson <per.fransson.ml@gmail.com>
> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in
> inode struct
> Date: Wed, 5 Sep 2012 12:29:43 +0200
>
> > Hi Crash people,
> >
> > The gcore extension fails on the 3.4 kernel I'm using. It attempts to
> > find the offset of a member within the inode struct, but the member is
> > part of an anonymous union. This patch fixes the problem for me.
> >
> > Regards,
> > Per
>
> Hello Per,
>
> Thanks for reporting that. According to git repository, this was
> changed by the following commit at the v3.1 period.
>
> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb
> v3.1-8569-ga78ef70
>
> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb
> commit a78ef704a8dd430225955f0709b22d4a6ba21deb
> Author: Miklos Szeredi <mszeredi@suse.cz>
> Date: Fri Oct 28 14:13:30 2011 +0200
>
> vfs: protect i_nlink
>
> Prevent direct modification of i_nlink by making it const and adding a
> non-const __i_nlink alias.
>
> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
>
> The patch appears fine to me so I'll apply it.
>
> Thanks.
> HATAYAMA, Daisuke

Hi Daisuke,

Will you be updating the crash-gcore-command tar.gz package?

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-18-2012, 12:19 AM
HATAYAMA Daisuke
 
Default : gcore extension, anonymous union in inode struct

From: Dave Anderson <anderson@redhat.com>
Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct
Date: Tue, 11 Sep 2012 08:50:32 -0400

>
>
> ----- Original Message -----
>> From: Per Fransson <per.fransson.ml@gmail.com>
>> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in
>> inode struct
>> Date: Wed, 5 Sep 2012 12:29:43 +0200
>>
>> > Hi Crash people,
>> >
>> > The gcore extension fails on the 3.4 kernel I'm using. It attempts to
>> > find the offset of a member within the inode struct, but the member is
>> > part of an anonymous union. This patch fixes the problem for me.
>> >
>> > Regards,
>> > Per
>>
>> Hello Per,
>>
>> Thanks for reporting that. According to git repository, this was
>> changed by the following commit at the v3.1 period.
>>
>> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb
>> v3.1-8569-ga78ef70
>>
>> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb
>> commit a78ef704a8dd430225955f0709b22d4a6ba21deb
>> Author: Miklos Szeredi <mszeredi@suse.cz>
>> Date: Fri Oct 28 14:13:30 2011 +0200
>>
>> vfs: protect i_nlink
>>
>> Prevent direct modification of i_nlink by making it const and adding a
>> non-const __i_nlink alias.
>>
>> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
>> Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>>
>> The patch appears fine to me so I'll apply it.
>>
>> Thanks.
>> HATAYAMA, Daisuke
>
> Hi Daisuke,
>
> Will you be updating the crash-gcore-command tar.gz package?
>

Hello Dave,

I have another gcore test plan soon. I'm going to update this change
together with it. Please wait for a few weeks.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-21-2012, 08:47 AM
Lei Wen
 
Default : gcore extension, anonymous union in inode struct

Hi*
Daisuke,

On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:

From: Dave Anderson <anderson@redhat.com>

Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct

Date: Tue, 11 Sep 2012 08:50:32 -0400



>

>

> ----- Original Message -----

>> From: Per Fransson <per.fransson.ml@gmail.com>

>> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in

>> inode struct

>> Date: Wed, 5 Sep 2012 12:29:43 +0200

>>

>> > Hi Crash people,

>> >

>> > The gcore extension fails on the 3.4 kernel I'm using. It attempts to

>> > find the offset of a member within the inode struct, but the member *is

>> > part of an anonymous union. This patch fixes the problem for me.

>> >

>> > Regards,

>> > Per

>>

>> Hello Per,

>>

>> Thanks for reporting that. According to git repository, this was

>> changed by the following commit at the v3.1 period.

>>

>> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb

>> v3.1-8569-ga78ef70

>>

>> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb

>> commit a78ef704a8dd430225955f0709b22d4a6ba21deb

>> Author: Miklos Szeredi <mszeredi@suse.cz>

>> Date: * Fri Oct 28 14:13:30 2011 +0200

>>

>> * * vfs: protect i_nlink

>>

>> * * Prevent direct modification of i_nlink by making it const and adding a

>> * * non-const __i_nlink alias.

>>

>> * * Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

>> * * Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>

>> * * Signed-off-by: Christoph Hellwig <hch@lst.de>

>>

>> The patch appears fine to me so I'll apply it.

>>

>> Thanks.

>> HATAYAMA, Daisuke

>

> Hi Daisuke,

>

> Will you be updating the crash-gcore-command tar.gz package?

>



Hello Dave,



I have another gcore test plan soon. I'm going to update this change

together with it. Please wait for a few weeks.



I have a curious question for the gcore. Current what we could do withgcore is to generate a core dump image, and then be parsed with externalgdb along with user space lib symbol.

Could it be possible that integrating the whole process into crash itself.That is without referring to external gdb's help, crash itself could print outthe call stack from user to kernel. I think it would be more convenient like
it current is.
Do you think implement it would be complex?*
Thanks.

HATAYAMA, Daisuke



Thanks,Lei*
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-21-2012, 01:37 PM
Dave Anderson
 
Default : gcore extension, anonymous union in inode struct

----- Original Message -----
> Hi Daisuke,
>
>
> On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <
> d.hatayama@jp.fujitsu.com > wrote:
>
>
> From: Dave Anderson < anderson@redhat.com >
> Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous
> union in inode struct
> Date: Tue, 11 Sep 2012 08:50:32 -0400
>
>
>
> >
> >
> > ----- Original Message -----
> >> From: Per Fransson < per.fransson.ml@gmail.com >
> >> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union
> >> in
> >> inode struct
> >> Date: Wed, 5 Sep 2012 12:29:43 +0200
> >>
> >> > Hi Crash people,
> >> >
> >> > The gcore extension fails on the 3.4 kernel I'm using. It attempts to
> >> > find the offset of a member within the inode struct, but the member is
> >> > part of an anonymous union. This patch fixes the problem for me.
> >> >
> >> > Regards,
> >> > Per
> >>
> >> Hello Per,
> >>
> >> Thanks for reporting that. According to git repository, this was
> >> changed by the following commit at the v3.1 period.
> >>
> >> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb
> >> v3.1-8569-ga78ef70
> >>
> >> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb
> >> commit a78ef704a8dd430225955f0709b22d4a6ba21deb
> >> Author: Miklos Szeredi < mszeredi@suse.cz >
> >> Date: Fri Oct 28 14:13:30 2011 +0200
> >>
> >> vfs: protect i_nlink
> >>
> >> Prevent direct modification of i_nlink by making it const and adding a
> >> non-const __i_nlink alias.
> >>
> >> Signed-off-by: Miklos Szeredi < mszeredi@suse.cz >
> >> Tested-by: Toshiyuki Okajima < toshi.okajima@jp.fujitsu.com >
> >> Signed-off-by: Christoph Hellwig < hch@lst.de >
> >>
> >> The patch appears fine to me so I'll apply it.
> >>
> >> Thanks.
> >> HATAYAMA, Daisuke
> >
> > Hi Daisuke,
> >
> > Will you be updating the crash-gcore-command tar.gz package?
> >
>
> Hello Dave,
>
> I have another gcore test plan soon. I'm going to update this change
> together with it. Please wait for a few weeks.
>
> I have a curious question for the gcore. Current what we could do with
> gcore is to generate a core dump image, and then be parsed with external
> gdb along with user space lib symbol.
>
> Could it be possible that integrating the whole process into crash itself.
> That is without referring to external gdb's help, crash itself could print out
> the call stack from user to kernel. I think it would be more convenient like
> it current is.
>
> Do you think implement it would be complex?

Probably...

It is possible to invoke the gdb "add-symbol-file" file command giving it
the name of the user's executable and its starting address as shown by the
"vm" command, and then the embedded gdb will have a copy of the executable's
symbol values and debuginfo data. But the top-level crash utility does not
store those symbols. I've done that in order to display user program data,
say for example, the crash utility's program_context data structure:

crash> vm
PID: 2179 TASK: ffff8801f4171710 CPU: 1 COMMAND: "crash"
MM PGD RSS TOTAL_VM
ffff88020e56d080 ffff8801fbcba000 182636k 331376k
VMA START END FLAGS FILE
ffff8801deae9a50 400000 a0c000 8001875 /var/CVS/crash/crash
ffff8801deae9420 c0c000 c2d000 8101873 /var/CVS/crash/crash
ffff8801de8da580 c2d000 dc3000 100073
ffff8801deafcd10 2935000 60ca000 100073
ffff8801de8daa50 3550000000 3550020000 8000875 /usr/lib64/ld-2.15.so
ffff8801de8da0b0 355021f000 3550220000 8100871 /usr/lib64/ld-2.15.so
...

crash> add-symbol-file /var/CVS/crash/crash 0x400000
add symbol table from file "/var/CVS/crash/crash" at
.text_addr = 0x400000
Reading symbols from /var/CVS/crash/crash...done.
crash>

crash> whatis program_context
struct program_context {
char *program_name;
char *program_path;
char *program_version;
char *gdb_version;
char *prompt;
long long unsigned int flags;
char *namelist;
char *dumpfile;
char *live_memsrc;
...

crash> p &program_context
$11 = (struct program_context *) 0xc46ee0
crash> struct -u program_context 0xc46ee0
struct program_context {
program_name = 0x7fff3d6f0806 "crash",
program_path = 0x7fff3d6f0804 "./crash",
program_version = 0x81d2b0 "6.1.0rc14",
gdb_version = 0x8927e9 "7.3.1",
prompt = 0x294acb0 "crash> ",
flags = 879609304517639,
namelist = 0x29404a0 "/usr/lib/debug/lib/modules/3.5.3-1.fc17.x86_64/vmlinux",
dumpfile = 0x0,
live_memsrc = 0x7c72b8 "/dev/crash",
...

And you could query gdb for the user-space text addresses:

crash> p &x86_64_init
$18 = (void (*)(int)) 0x48c770 <x86_64_init>
crash> p &cmd_vm
$19 = (void (*)(void)) 0x425d00 <cmd_vm>
crash>

There's no way I would consider polluting the per-arch backtrace
functions with any kind of user-space support. But it might be
interesting to try to do something in an extension module.

Dave


>
> Thanks,
> Lei



--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-24-2012, 12:18 AM
HATAYAMA Daisuke
 
Default : gcore extension, anonymous union in inode struct

From: Lei Wen <adrian.wenl@gmail.com>
Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct
Date: Fri, 21 Sep 2012 16:47:41 +0800

> Hi Daisuke,
>

Hello,

> On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com
>> wrote:
>
>> From: Dave Anderson <anderson@redhat.com>
>> Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in
>> inode struct
>> Date: Tue, 11 Sep 2012 08:50:32 -0400
>>
>> >
>> >
>> > ----- Original Message -----
>> >> From: Per Fransson <per.fransson.ml@gmail.com>
>> >> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in
>> >> inode struct
>> >> Date: Wed, 5 Sep 2012 12:29:43 +0200
>> >>
>> >> > Hi Crash people,
>> >> >
>> >> > The gcore extension fails on the 3.4 kernel I'm using. It attempts to
>> >> > find the offset of a member within the inode struct, but the member
>> is
>> >> > part of an anonymous union. This patch fixes the problem for me.
>> >> >
>> >> > Regards,
>> >> > Per
>> >>
>> >> Hello Per,
>> >>
>> >> Thanks for reporting that. According to git repository, this was
>> >> changed by the following commit at the v3.1 period.
>> >>
>> >> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb
>> >> v3.1-8569-ga78ef70
>> >>
>> >> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb
>> >> commit a78ef704a8dd430225955f0709b22d4a6ba21deb
>> >> Author: Miklos Szeredi <mszeredi@suse.cz>
>> >> Date: Fri Oct 28 14:13:30 2011 +0200
>> >>
>> >> vfs: protect i_nlink
>> >>
>> >> Prevent direct modification of i_nlink by making it const and
>> adding a
>> >> non-const __i_nlink alias.
>> >>
>> >> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
>> >> Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>
>> >> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> >>
>> >> The patch appears fine to me so I'll apply it.
>> >>
>> >> Thanks.
>> >> HATAYAMA, Daisuke
>> >
>> > Hi Daisuke,
>> >
>> > Will you be updating the crash-gcore-command tar.gz package?
>> >
>>
>> Hello Dave,
>>
>> I have another gcore test plan soon. I'm going to update this change
>> together with it. Please wait for a few weeks.
>>
>>
> I have a curious question for the gcore. Current what we could do with
> gcore is to generate a core dump image, and then be parsed with external
> gdb along with user space lib symbol.
>
> Could it be possible that integrating the whole process into crash itself.
> That is without referring to external gdb's help, crash itself could print
> out
> the call stack from user to kernel. I think it would be more convenient like
> it current is.
>
> Do you think implement it would be complex?
>

As Dave suggests, I think it a reasonable way to do is do it in an
extension module independently of crash utility (so integrated gdb),
because my understanding is that gdb can manage only one symbol space
so symbol conflicts may happen. Also, basically kernel crash dump
typically have physical memory shape, and crash utility does
virtual-to-physical address translation. I think it possible to do it
in an independent extnesion module that manages memory view, symbols
and other debugging information locally.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 09-24-2012, 03:08 AM
Lei Wen
 
Default : gcore extension, anonymous union in inode struct

Hi Daisuke and Dave,

On Mon, Sep 24, 2012 at 8:18 AM, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:

From: Lei Wen <adrian.wenl@gmail.com>

Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in inode struct

Date: Fri, 21 Sep 2012 16:47:41 +0800



> Hi *Daisuke,

>



Hello,



> On Tue, Sep 18, 2012 at 8:19 AM, HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com

>> wrote:

>

>> From: Dave Anderson <anderson@redhat.com>

>> Subject: Re: [Crash-utility] [PATCH]: gcore extension, anonymous union in

>> inode struct

>> Date: Tue, 11 Sep 2012 08:50:32 -0400

>>

>> >

>> >

>> > ----- Original Message -----

>> >> From: Per Fransson <per.fransson.ml@gmail.com>

>> >> Subject: [Crash-utility] [PATCH]: gcore extension, anonymous union in

>> >> inode struct

>> >> Date: Wed, 5 Sep 2012 12:29:43 +0200

>> >>

>> >> > Hi Crash people,

>> >> >

>> >> > The gcore extension fails on the 3.4 kernel I'm using. It attempts to

>> >> > find the offset of a member within the inode struct, but the member

>> *is

>> >> > part of an anonymous union. This patch fixes the problem for me.

>> >> >

>> >> > Regards,

>> >> > Per

>> >>

>> >> Hello Per,

>> >>

>> >> Thanks for reporting that. According to git repository, this was

>> >> changed by the following commit at the v3.1 period.

>> >>

>> >> $ git describe a78ef704a8dd430225955f0709b22d4a6ba21deb

>> >> v3.1-8569-ga78ef70

>> >>

>> >> $ git log -1 a78ef704a8dd430225955f0709b22d4a6ba21deb

>> >> commit a78ef704a8dd430225955f0709b22d4a6ba21deb

>> >> Author: Miklos Szeredi <mszeredi@suse.cz>

>> >> Date: * Fri Oct 28 14:13:30 2011 +0200

>> >>

>> >> * * vfs: protect i_nlink

>> >>

>> >> * * Prevent direct modification of i_nlink by making it const and

>> adding a

>> >> * * non-const __i_nlink alias.

>> >>

>> >> * * Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>

>> >> * * Tested-by: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>

>> >> * * Signed-off-by: Christoph Hellwig <hch@lst.de>

>> >>

>> >> The patch appears fine to me so I'll apply it.

>> >>

>> >> Thanks.

>> >> HATAYAMA, Daisuke

>> >

>> > Hi Daisuke,

>> >

>> > Will you be updating the crash-gcore-command tar.gz package?

>> >

>>

>> Hello Dave,

>>

>> I have another gcore test plan soon. I'm going to update this change

>> together with it. Please wait for a few weeks.

>>

>>

> I have a curious question for the gcore. Current what we could do with

> gcore is to generate a core dump image, and then be parsed with external

> gdb along with user space lib symbol.

>

> Could it be possible that integrating the whole process into crash itself.

> That is without referring to external gdb's help, crash itself could print

> out

> the call stack from user to kernel. I think it would be more convenient like

> it current is.

>

> Do you think implement it would be complex?

>



As Dave suggests, I think it a reasonable way to do is do it in an

extension module independently of crash utility (so integrated gdb),

because my understanding is that gdb can manage only one symbol space

so symbol conflicts may happen. Also, basically kernel crash dump

typically have physical memory shape, and crash utility does

virtual-to-physical address translation. I think it possible to do it

in an independent extnesion module that manages memory view, symbols

and other debugging information locally.



Thanks.

HATAYAMA, Daisuke




I think display backtrace inside extension module could already fulfillthe need, and it is true that we shouldn't pollute crash's symbol context.

I would try to dig further to see what could we benefit from this inside bt.
Thanks,Lei
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 

Thread Tools




All times are GMT. The time now is 01:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org