support ioctl KVM_GET_MSRS
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 10.7k
- Forks
- 662
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 2
Description
Version
rr 5.2.0-238-g77c116f8
libvirt app-emulation/libvirt-5.6.0
gdb sys-devel/gdb-8.3
kernel: 5.2.0-gentoo
CPU
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 39 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 158
Model name: Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz
Stepping: 9
CPU MHz: 3223.274
CPU max MHz: 3500.0000
CPU min MHz: 800.0000
BogoMIPS: 4992.00
Virtualization: VT-x
L1d cache: 128 KiB
L1i cache: 128 KiB
L2 cache: 1 MiB
L3 cache: 6 MiB
Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, STIBP disabled, RSB filling
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
Steps
Record libvirtd: rr record libvirtd
rr: Saving execution to trace directory `/root/.local/share/rr/libvirtd-6'.
[FATAL /var/tmp/portage/dev-util/rr-5.2.0-r1/work/rr-5.2.0/src/AddressSpace.cc:651:at_preload_init_arch()]
(task 421864 (rec:421864) at time 2659)
-> Assertion `t->session().as_record()->use_syscall_buffer() == params.syscallbuf_enabled' failed to hold. Tracee thinks syscallbuf is disabled, but tracer thinks enabled
=== Start rr backtrace:
rr(_ZN2rr13dump_rr_stackEv+0x41)[0x55675d2d44f1]
rr(_ZN2rr9GdbServer15emergency_debugEPNS_4TaskE+0x605)[0x55675d20a2c5]
rr(_ZN2rr21EmergencyDebugOstreamD1Ev+0x122)[0x55675d215ba2]
rr(_ZN2rr12AddressSpace20at_preload_init_archINS_7X64ArchEEEvPNS_4TaskE+0xf0)[0x55675d1cd960]
rr(_ZN2rr4Task15at_preload_initEv+0x2e)[0x55675d2be88e]
rr(_ZN2rr10RecordTask15at_preload_initEv+0x20)[0x55675d275080]
rr(+0xf60d4)[0x55675d2680d4]
rr(_ZN2rr19rec_process_syscallEPNS_10RecordTaskE+0x196)[0x55675d26a786]
rr(_ZN2rr13RecordSession21syscall_state_changedEPNS_10RecordTaskEPNS0_9StepStateE+0xcf8)[0x55675d233a48]
rr(_ZN2rr13RecordSession11record_stepEv+0x4c3)[0x55675d239663]
rr(_ZN2rr13RecordCommand3runERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0x8df)[0x55675d22f71f]
rr(main+0x253)[0x55675d1c0a23]
/lib64/libc.so.6(__libc_start_main+0xeb)[0x7f7ac5f4ce4b]
rr(_start+0x2a)[0x55675d1c0b3a]
=== End rr backtrace
Launch gdb with
gdb '-l' '10000' '-ex' 'set sysroot /' '-ex' 'target extended-remote 127.0.0.1:28648' /usr/sbin/dnsmasq
Then run gdb as gdb -l 10000 -ex set sysroot / -ex target extended-remote 127.0.0.1:28648 /usr/sbin:
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint -1: Remote connection closed
Command aborted
Then rr gets segment fault:
[1] 421839 segmentation fault (core dumped) rr record libvirtd
Addition info
rr Backtrace:
#0 std::__uniq_ptr_impl<rr::Session::CloneCompletion, std::default_delete<rr::Session::CloneCompletion> >::_M_ptr (this=0x98) at /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/bits/unique_ptr.h:150
#1 0x000055d097080cec in std::unique_ptr<rr::Session::CloneCompletion, std::default_delete<rr::Session::CloneCompletion> >::get (this=0x98)
at /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/bits/unique_ptr.h:343
#2 0x000055d09707eb6e in std::unique_ptr<rr::Session::CloneCompletion, std::default_delete<rr::Session::CloneCompletion> >::operator bool (this=0x98)
at /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include/g++-v8/bits/unique_ptr.h:357
#3 0x000055d09707ad4b in rr::Session::finish_initializing (this=0x0) at /home/hhan/Software/rr/src/Session.cc:399
#4 0x000055d097079a06 in rr::Session::find_task (this=0x0, rec_tid=420196) at /home/hhan/Software/rr/src/Session.cc:166
#5 0x000055d097079abf in rr::Session::find_task (this=0x0, tuid=...) at /home/hhan/Software/rr/src/Session.cc:172
#6 0x000055d097039233 in rr::ReplaySession::find_task (this=0x0, tuid=...) at /home/hhan/Software/rr/src/ReplaySession.cc:1674
#7 0x000055d096f49cb2 in rr::GdbServer::dispatch_debugger_request (this=0x7ffd120d0bd0, session=..., req=..., state=rr::GdbServer::REPORT_NORMAL) at /home/hhan/Software/rr/src/GdbServer.cc:579
#8 0x000055d096f4c6f4 in rr::GdbServer::process_debugger_requests (this=0x7ffd120d0bd0, state=rr::GdbServer::REPORT_NORMAL) at /home/hhan/Software/rr/src/GdbServer.cc:1033
#9 0x000055d096f50327 in rr::GdbServer::emergency_debug (t=0x55d097304fd0) at /home/hhan/Software/rr/src/GdbServer.cc:1685
#10 0x000055d096f75f78 in rr::emergency_debug (t=0x55d097304fd0) at /home/hhan/Software/rr/src/log.cc:403
#11 0x000055d096f761d2 in rr::EmergencyDebugOstream::~EmergencyDebugOstream (this=0x7ffd120d1030, __in_chrg=<optimized out>) at /home/hhan/Software/rr/src/log.cc:425
#12 0x000055d096ed65e0 in rr::AddressSpace::at_preload_init_arch<rr::X64Arch> (this=0x55d0972ae290, t=0x55d097304fd0) at /home/hhan/Software/rr/src/AddressSpace.cc:620
#13 0x000055d096ec5fa0 in rr::AddressSpace::at_preload_init (this=0x55d0972ae290, t=0x55d097304fd0) at /home/hhan/Software/rr/src/AddressSpace.cc:635
#14 0x000055d09709be64 in rr::Task::at_preload_init (this=0x55d097304fd0) at /home/hhan/Software/rr/src/Task.cc:2395
#15 0x000055d0970159b2 in rr::RecordTask::at_preload_init (this=0x55d097304fd0) at /home/hhan/Software/rr/src/RecordTask.cc:433
#16 0x000055d096fe62f0 in rr::rec_process_syscall_arch<rr::X64Arch> (t=0x55d097304fd0, syscall_state=...) at /home/hhan/Software/rr/src/record_syscall.cc:5605
#17 0x000055d096fd0721 in rr::rec_process_syscall_internal (t=0x55d097304fd0, arch=rr::x86_64, syscall_state=...) at /home/hhan/Software/rr/src/record_syscall.cc:5635
#18 0x000055d096fd080c in rr::rec_process_syscall (t=0x55d097304fd0) at /home/hhan/Software/rr/src/record_syscall.cc:5649
#19 0x000055d096fb4d3e in rr::RecordSession::syscall_state_changed (this=0x55d0972a9910, t=0x55d097304fd0, step_state=0x7ffd120d188c) at /home/hhan/Software/rr/src/RecordSession.cc:1014
#20 0x000055d096fb9ef8 in rr::RecordSession::record_step (this=0x55d0972a9910) at /home/hhan/Software/rr/src/RecordSession.cc:2043
#21 0x000055d096facc51 in rr::record (args=std::vector of length 1, capacity 2 = {...}, flags=...) at /home/hhan/Software/rr/src/RecordCommand.cc:606
#22 0x000055d096fad721 in rr::RecordCommand::run (this=0x55d097291e70 <rr::RecordCommand::singleton>, args=std::vector of length 1, capacity 2 = {...}) at /home/hhan/Software/rr/src/RecordCommand.cc:729
#23 0x000055d0970e4c97 in main (argc=3, argv=0x7ffd120d1c68) at /home/hhan/Software/rr/src/main.cc:268
Full backtrace with all threads
[
gdb.txt
](url)
rr record with all log enabled
[
rr.log
](url)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the failure with rr record libvirtd, then inspect src/AddressSpace.cc, src/GdbServer.cc, and src/record_syscall.cc at the backtrace locations. Use the attached gdb.txt and rr.log to trace the KVM_GET_MSRS path; done means the reported recording and debugger interaction no longer crashes and the ioctl is supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, linux
- Domain
- devtools, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100