First breakpoint at AVX instruction with memory operand causes SIGSEGV when tring to continue execution
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gdb (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
I noticed random looking SIGSEGV to application when trying to continue execution after first breakpoint. I now seem to have narrowed the issue to SIMD instruction with memory operand as first breakpoint location. I haven't managed to figure out why the SIGSEGV is delivered to the debugger application.
It is important have first breakpoint exactly at a problematic instructions. If I first break on a different instruction then later breakpoints won't reproduce that crash
I haven't tested if this is a hardware specific issue.
I managed to write a simple test case which reproduces the crash if breakpoint is set. I attached the test.cc which includes compilation and testing instructions. test.cc is supposed to generate a simple main function like:
Dump of assembler code for function main():
=> 0x0000555555554520 <+0>: vmovdqa 0x1af8(%rip),%xmm0 # 0x555555556020 <foo>
0x0000555555
0x0000555555
I set breakpoint with:
b main
Then either continue or stepping causes SIGSEGV to the debugged application.
This was happening already with disco. I only now figured out enough details to make a simple test case which is worth a bug report.
ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: gdb 8.3-0ubuntu1
ProcVersionSign
Uname: Linux 5.3.0-19-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue Oct 29 09:44:52 2019
InstallationDate: Installed on 2037-12-25 (-6632 days ago)
InstallationMedia: Lubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
SourcePackage: gdb
UpgradeStatus: Upgraded to eoan on 2019-10-27 (1 days ago)
Actually it seems like it is more restricted towards a few instructions with memory operand. But if breakpoint is set to them at any point of execution they crash.
That means also breakpoint before and single stepping to problematic breakpoint will crash application. But single stepping over problematic instruction without breakpoint doesn't crash. That was adding to my earlier confusion why application crashes looked so random.