https://bugs.kde.org/show_bug.cgi?id=458915
--- Comment #16 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- In one of the trace I see the below trace. It looks like the a signal SIGALRM is delivered to the thread that encounters the futex 202 result. --24048-- async signal handler: signal=14, vgtid=24051, tid=4, si_code=-6, exitreason VgSrc_None --24048-- interrupted_syscall: tid=4, ip=0x580e687e, restart=False, sres.isErr=False, sres.val=202 --24048-- at syscall instr: returning EINTR --24048-- delivering signal 14 (SIGALRM):-6 to thread 4 --24048-- push_signal_frame (thread 4): signal 14 ==24048== at 0x4C2C340: futex_wait (futex-internal.h:146) ==24048== by 0x4C2C340: __lll_lock_wait (lowlevellock.c:49) ==24048== by 0x4C32322: __pthread_mutex_cond_lock (pthread_mutex_lock.c:93) ==24048== by 0x4C2E9B3: __pthread_cond_wait_common (pthread_cond_wait.c:616) ==24048== by 0x4C2E9B3: pthread_cond_wait@@GLIBC_2.3.2 (pthread_cond_wait.c:627) ==24048== by 0x14184D: worker_main (pool.c:70) ==24048== by 0x1395B2: thread_ep (dthreads.c:146) ==24048== by 0x4C2FB42: start_thread (pthread_create.c:442) ==24048== by 0x4CC0BB3: clone (clone.S:100) So, this is another indication that the problem is likely linked to VG_(fixup_guest_state_after_syscall_interrupted). But it is not very clear what is special in your application. Can you also reproduce the problem with the --tool=none tool ? Or does it happen only with memcheck ? Can you check if the problem goes away when using --vex-iropt-register-updates=allregs-at-each-insn ? If the problem cannot be reproduced with this setting, can you see if it reproduces with --vex-iropt-register-updates=allregs-at-mem-access ? -- You are receiving this mail because: You are watching all bug changes.
