On 2022/09/27 17:56, lijiang wrote:
> On Tue, Sep 27, 2022 at 4:27 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx>
> 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?
> 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.
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.
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".
Thanks,
Kazu
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
