mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-03 18:13:01 +00:00
74fb3e1c3e
Most of the time, Valgrind masks async signals, and polls for such signals at regular interval. There is a very narrow range of code (around client syscall logic) where such signals are unmasked (as they must be able to interrupt syscalls). This is the only range of code where Valgrind is expecting to receive such a signal. When gdbserver is ptraced invoked, Valgrind is artificially made to jump out of this code portion. Signals are not masked. When ptraceing valgrind, vgdb will get these signals but cannot transmit them immediately, otherwise they arrive in range of code where they are not expected (causing internal error in syscall logic) and/or causing gdbserver syscalls to be interrupted. 3 solutions to solve that were looked at: 1. have the gdbserver code masking signals "as quickly as possible". Easy to implement, but this leaves still a small window of code where signals are not masked and would cause a problem. 2. have vgdb setting the SIGMASK of valgrind before invoking gdbserver. This would be easy to implement, but changing the SIGMASK of the ptrace-d process is only available on very recent kernels. 3. have vgdb queuing signals, and only transmitting them once gdbserver invocation is finished. This 3rd solution has been implemented. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13896
12 lines
314 B
Plaintext
12 lines
314 B
Plaintext
Nulgrind, the minimal Valgrind tool
|
|
|
|
(action at startup) vgdb me ...
|
|
|
|
|
|
loops/sleep_ms/burn/threads_spec: 1000000000 1000000000 1 BSBSBSBS
|
|
Brussels ready to sleep and/or burn
|
|
London ready to sleep and/or burn
|
|
Petaouchnok ready to sleep and/or burn
|
|
main ready to sleep and/or burn
|
|
Gdb request to kill this process
|