Re: [PATCH] gdb: Fix an assertion failure in the dw2_find_pc_sect_compunit_symtab()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023/03/09 16:56, lijiang wrote:>>> Thank you for the comment, Kazu.
>>>
>>> On Thu, Mar 9, 2023 at 12:26 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx <mailto:k-hagio-ab@xxxxxxx>> wrote:
>>>
>>>     On 2023/03/07 20:04, Lianbo Jiang wrote:
>>>     > This is a backported patch from gdb. Without the patch, the "dis -rl"
>>>     > command may abort due to an assertion failure in the gdb's
>>>     > dw2_find_pc_sect_compunit_symtab():
>>>     >
>>>     >    crash> dis -rl ffffffff96ad716c
>>>     >    dwarf2/read.c:4928: internal-error: compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, bound_minimal_symbol, CORE_ADDR, obj_section*, int): Assertion `result != NULL' failed.
>>>     >    A problem internal to GDB has been detected,
>>>     >    further debugging may prove unreliable.
>>>     >    Quit this debugging session? (y or n) dwarf2/read.c:4928: internal-error: compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, bound_minimal_symbol, CORE_ADDR, obj_section*, int): Assertion `result != NULL' failed.
>>>     >    A problem internal to GDB has been detected,
>>>     >    further debugging may prove unreliable.
>>>     >    Aborted (core dumped)
>>>     >
>>>     > The gdb commit 834eaf9201c1 ("Fix crash in new DWARF indexer")
>>>     > solved the current issue.
>>>
>>>     I think this partial backport will be fine.Few questions:
>>>
>>>     Doesn't this happen with "dis" or "dis -l" commands?
>>>
>>>
>>> These two commands can not reproduce this issue for my side.
>>>
>>>     In other words, are the minimum options "dis -rl" above?
>>>
>>>
>>> The "dis -r"  can also reproduce it.
>>>
>>>
>>>     Is there no warning and problem in the result with the patch?
>>>
>>> With the patch:
>>> crash> dis -r ffffffff96ad716c
>>> 0x0 <>: (Error: pc 0x33fff in address map, but not in symtab.)
>>> No line number information available for address 0x33fff
>>> crash> dis -rl ffffffff96ad716c
>>> 0x0 <>: (Internal error: pc 0x33fff in read in CU, but not in symtab.)
>>> 0x0 <>: (Error: pc 0x33fff in address map, but not in symtab.)
>>> No line number information available for address 0x33fff

Thanks for the information.

Seems the issue rarely happens and it looks hard to backport it fully,
so ack, agree on the partial backport.

Applied with a few tweaks.
https://github.com/crash-utility/crash/commit/ade71c3ec1d28751c3d6ba1eec71781bdff093d3

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




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux