Bug 2125720

Summary:	unable to set scope for dm_table_create without prior whatis
Product:	Red Hat Enterprise Linux 9	Reporter:	John Pittman <jpittman>
Component:	crash	Assignee:	lijiang
Status:	CLOSED WONTFIX	QA Contact:	Jie Li <jieli>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	lijiang
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-11-21 20:29:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John Pittman 2022-09-09 20:47:40 UTC

Description of problem:

cannot set scope for dm_table_create without prior whatis

Version-Release number of selected component (if applicable):

crash 8.0.0-6.el9
issue also reproducible on latest upstream crash (head at bdbf5887d6259ea3108d4fa674f3794adad54d52)

How reproducible:

every time in provided core

Steps to Reproduce:

# crash vmcore.vmsn vmlinux

crash> mod -S usr/lib/debug/lib/modules/3.10.0-229.el7.x86_64

crash> set scope dm_table_create
set: gdb cannot find text block for address: dm_table_create

crash> whatis dm_table_create
int dm_table_create(struct dm_table **, fmode_t, unsigned int, struct mapped_device *);

crash> set scope dm_table_create
scope: ffffffffa0005380 (dm_table_create)

Actual results:

set scope fails first time

Expected results:

set scope should work the first time ; whatis should be unneeded

Comment 3 John Pittman 2022-09-26 13:28:29 UTC

Hi Lijiang; thanks so much.  Yes the mod -rS works around the issue.  Should the first mod command run on a core go through the readnow path?

Comment 4 lijiang 2022-09-27 06:23:48 UTC

(In reply to John Pittman from comment #3)
> Hi Lijiang; thanks so much.  Yes the mod -rS works around the issue.  Should
> the first mod command run on a core go through the readnow path?

The '-r' option will cause the GDB to read the full symbol file, it may be slower. Most of time, it is not needed.

I would suggest closing this issue as WON'T because it can work well with the '-r' option, and this doesn't affect the debugging.

Thanks.

Comment 5 John Pittman 2022-09-27 12:50:06 UTC

Thanks; why does the whatis command fix the issue?

Comment 6 lijiang 2022-09-28 02:53:12 UTC

(In reply to John Pittman from comment #5)
> Thanks; why does the whatis command fix the issue?

The 'whatis' and 'ptype' can passthrough the gdb, eventually they will call the whatis_exp() in gdb, which will parse expression, this operation may affect the SYMTAB BLOCK and symbol search. If you are interested, you could refer to the parse_exp_in_context().

Thanks.