On Thu, Sep 29, 2022 at 9:10 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio...@nec.com>
wrote:
> On 2022/09/27 17:56, lijiang wrote:
> > On Tue, Sep 27, 2022 at 4:27 PM HAGIO KAZUHITO(萩尾 一仁) <
> k-hagio...@nec.com>
> > wrote:
> >
> >> cc Alexey, reverting this affects VMware folks.
> >>
> >> On 2022/09/27 15:27, Lianbo Jiang wrote:
> >>> This reverts commit 2f967fb5ebd737ce5eadba462df35935122e8865. John
> >>> Pittman reports that it causes a regression issue on the old Vmware
> >>> vmcore as below:
> >>>
> >>> crash> set scope dm_table_create
> >>> set: attempting to find/load "dm_mod" module debuginfo
> >>> MODULE NAME BASE SIZE
> >> OBJECT FILE
> >>> ffffffffa0012dc0 dm_mod ffffffffa0000000 102823
> >> /home/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug
> >>> scope: ffffffffa0006cf0 (dm_table_create)
> >>> crash> whatis struct dm_table
> >>> struct dm_table {
> >>> uint64_t features;
> >>> struct mapped_device *md;
> >>> unsigned int type;
> >>> unsigned int depth;
> >>> unsigned int counts[16];
> >>> sector_t *index[16];
> >>> unsigned int num_targets;
> >>> unsigned int num_allocated;
> >>> sector_t *highs;
> >>> struct dm_target *targets;
> >>> struct target_type *immutable_target_type;
> >>> unsigned int integrity_supported : 1;
> >>> unsigned int singleton : 1;
> >>> fmode_t mode;
> >>> struct list_head devices;
> >>> void (*event_fn)(void *);
> >>> void *event_context;
> >>> struct dm_md_mempools *mempools;
> >>> struct list_head target_callbacks;
> >>> }
> >>> SIZE: 312
> >>> crash> whatis _name_buckets --->| After using the whatis
> >> _name_buckets command,
> >>> struct list_head _name_buckets[64]; |
> >>> crash> whatis struct dm_table <---| it won't show the contents
> >> of the dm_table struct.
> >>> struct dm_table {
> >>> int undefined__;
> >>> }
> >>> SIZE: 312
> >>> crash>
> >>>
> >>> With the patch, this issue disappeared.
> >> At first glance, I did not find any part of the patch that can cause
> >> the issue. Do you have any detailed information?
> >>
> >>
> > This issue is observed on an old Vmware vmcore, and looks like a
> regression
> > issue.
>
> Is the vmcore a .vmss file? or one captured by kdump?
>
>
It's a .vmss file.
> > I tried to dig into the detail, the raw_supply() operation may affect the
> > gdb behavior, it
> > will store the register values to a cache in the gdb.
> >
> > So far I haven't got a good solution, let's see if Alex has a better way
> to
> > fix it, that would be welcome. Any thoughts?
>
> I suspected that the issue might depend on the debuginfo, but could not
> reproduce it with the same 2.6.32-754.35.1.el6.x86_64 vmlinux.
>
> but even with reverting the patch, I found that "set scope 0" does not
> work well, though not sure whether it's related to the issue.
>
>
There may be a different issue, the 'set scope 0' can work in my case. Can
you try the '-r' option to work around your issue?
crash-dev> mod -s dm_mod
> MODULE NAME BASE SIZE OBJECT FILE
> ffffffffa0012dc0 dm_mod ffffffffa0000000 102823
> /home/vmcore/2022-09-28-rhel610-754.35.1.el6/usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug
> crash-dev> struct dm_table
> struct dm_table {
> int undefined__;
> }
> SIZE: 4
> crash-dev> set scope dm_table_create
> scope: ffffffffa0006cf0 (dm_table_create)
> crash-dev> struct dm_table
> struct dm_table {
> uint64_t features;
> struct mapped_device *md;
> unsigned int type;
> unsigned int depth;
> unsigned int counts[16];
> sector_t *index[16];
> unsigned int num_targets;
> unsigned int num_allocated;
> sector_t *highs;
> struct dm_target *targets;
> struct target_type *immutable_target_type;
> unsigned int integrity_supported : 1;
> unsigned int singleton : 1;
> fmode_t mode;
> struct list_head devices;
> void (*event_fn)(void *);
> void *event_context;
> struct dm_md_mempools *mempools;
> struct list_head target_callbacks;
> }
> SIZE: 312
> crash-dev> set scope 0 <<--- unset the scope
> scope: 0 (not set)
> crash-dev> struct dm_table
> struct dm_table {
> uint64_t features; <<--- but, same as above
> struct mapped_device *md;
> unsigned int type;
> unsigned int depth;
> unsigned int counts[16];
> sector_t *index[16];
> unsigned int num_targets;
> unsigned int num_allocated;
> sector_t *highs;
> struct dm_target *targets;
> struct target_type *immutable_target_type;
> unsigned int integrity_supported : 1;
> unsigned int singleton : 1;
> fmode_t mode;
> struct list_head devices;
> void (*event_fn)(void *);
> void *event_context;
> struct dm_md_mempools *mempools;
> struct list_head target_callbacks;
> }
> SIZE: 312
>
>
> It looks like gdb-10.2 has some memory, other than "crash_text_scope"
> in gdb-10.2/gdb/symtab.c.
>
>
The behavior is different between the gdb-10.2 and gdb-7.6, we had
encountered several cases. But I'm not sure which one may affect this issue.
> On the other hand, with crash-7.3.2 "set scope 0" works as expected.
>
> crash-7.3.2> mod -s dm_mod
> MODULE NAME BASE SIZE OBJECT FILE
> ffffffffa0012dc0 dm_mod ffffffffa0000000 102823
> /home/vmcore/2022-09-28-rhel610-754.35.1.el6/usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/kernel/drivers/md/dm-mod.ko.debug
> crash-7.3.2> struct dm_table
> struct dm_table {
> int undefined__;
> }
> SIZE: 4
> crash-7.3.2> set scope dm_table_create
> scope: ffffffffa0006cf0 (dm_table_create)
> crash-7.3.2> struct dm_table
> struct dm_table {
> uint64_t features;
> struct mapped_device *md;
> unsigned int type;
> unsigned int depth;
> unsigned int counts[16];
> sector_t *index[16];
> unsigned int num_targets;
> unsigned int num_allocated;
> sector_t *highs;
> struct dm_target *targets;
> struct target_type *immutable_target_type;
> unsigned int integrity_supported : 1;
> unsigned int singleton : 1;
> fmode_t mode;
> struct list_head devices;
> void (*event_fn)(void *);
> void *event_context;
> struct dm_md_mempools *mempools;
> struct list_head target_callbacks;
> }
> SIZE: 312
> crash-7.3.2> set scope 0
> scope: 0 (not set)
> crash-7.3.2> struct dm_table
> struct dm_table {
> int undefined__;
> }
> SIZE: 4
>
>
> so I guess that "set scope" with gdb-10.2 has a problem in the
> first place. The second issue above might become a clue.
>
Lianbo, is it possible to look into the issues more? It might
> find a better implementation for "set scope".
>
>
Sure. Will try it. But it might be another issue. In my case, after
reverting the commit, it can not be reproduced, otherwise, it is always
reproduced.
Thanks.
Lianbo
> Thanks,
> Kazu
--
Crash-utility mailing list
Crash-utility@redhat.com
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
