Valgrind fails while executing C++ code which uses mmap to map a PCIe device Valgrind output: valgrind: m_debuginfo/image.c:612 (set_CEnt): Assertion '!sr_isError(sr)' failed. host stacktrace: ==43357== at 0x58044AD0: show_sched_status_wrk (m_libcassert.c:426) ==43357== by 0x58044C37: report_and_quit (m_libcassert.c:497) ==43357== by 0x58044DB3: vgPlain_assert_fail (m_libcassert.c:564) ==43357== by 0x580CB653: set_CEnt (image.c:612) ==43357== by 0x580CB8AB: vgModuleLocal_img_from_fd (image.c:956) ==43357== by 0x580860E7: vgModuleLocal_check_elf_and_get_rw_loads (readelf.c:3884) ==43357== by 0x580749AF: vgPlain_di_notify_mmap (debuginfo.c:1357) ==43357== by 0x580A5767: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2863) ==43357== by 0x580B308B: vgSysWrap_arm64_linux_sys_mmap_before (syswrap-arm64-linux.c:311) ==43357== by 0x580A07C3: vgPlain_client_syscall (syswrap-main.c:2409) ==43357== by 0x5809BD4B: handle_syscall (scheduler.c:1214) ==43357== by 0x5809E1EB: vgPlain_scheduler (scheduler.c:1588) ==43357== by 0x580FC2CB: thread_wrapper (syswrap-linux.c:102) ==43357== by 0x580FC2CB: run_a_thread_NORETURN (syswrap-linux.c:154) ==43357== by 0xFFFFFFFFFFFFFFFF: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 222 (lwpid 43357) ==43357== at 0x63C3D60: __mmap64 (mmap64.c:58) ==43357== by 0x63C3D60: mmap (mmap64.c:46) ... ... Thread 2: status = VgTs_WaitSys syscall 73 (lwpid 58128) ==57509== at 0x63BE264: poll (poll.c:41) ... ... the rest of the error message contains private library information, so I don't think I can share it here, or provide the source code for reproduction. I believe the relevant code is int barFd; barFd = open(barPath.c_str(), O_RDWR | O_SYNC) mmap(NULL, newBar->size, PROT_READ | PROT_WRITE, MAP_SHARED, barFd, 0); I believe this is related to Bug 480405, as the Host Stacktrace seems identical, but as that was fixed in v3.22 it must be some other issue SOFTWARE/OS VERSIONS Linux: custom linux image compiled via the Yocto project, running on an armv8 processor ADDITIONAL INFORMATION valgrind compiled from source, cross-compiled from linux-x86_64 to linux-arm64
What happens if you remove O_SYNC from the open call? Does Valgrind still assert? I'm not suggesting that as a fix, I just want to know if that flag is causing a problem for Valgrind.