Nedávno jsem tedy s někým diskutoval o strace a ptali se, co by se stalo, kdybyste sledovali běžící proces právě při vytváření síťového soketu nebo něčeho podobného. Mohlo by to způsobit neočekávané selhání programu?
Z toho, co jsem četl o ptrace, syscall používaném strace, by nemělo být schopné způsobit nic takového, pokud právě ladíte vlákno. Proces se zastaví pokaždé, když je zavoláno systémové volání, ale měl by se později obnovit a být o nic moudřejší. Signály se zařazují do fronty, když neběží, takže předpokládám, že se něco podobného stane s syscalls/sockets/listen.
Může ptrace použitý v kontextu strace způsobit nějaké podivné pády procesu?
Přijatá odpověď:
Ne , strace by nemělo způsobit pád programu –
Kromě v tomto poněkud neobvyklém případě:
Pokud má chybu, která závisí na načasování provedení nebo umístění paměti za běhu .
Může to spustit tento druh „heisenbug “ – ale extrémně zřídka, protože tento druh chyby je vzácný a musí se spustit pouze pod strace nebo jiným zařízením.
A když najdete heisenbug, je to často dobrá věc.
Ohledně ptrace() – syscall – to je právě to, co strace myslím, že uvnitř, takže je to podobné. Člověk může udělat víc než jen strace můžete při použití ptrace() přímo.
Váš příklad by byl právě tento druh chyby:
V příkladu strace by změnilo načasování kroků k vytvoření síťového připojení. Pokud to způsobuje problém, byl to „problém čekající na to, až se stane“ – načasování provádění se neustále mění. S strace , jen trochu víc. Jakákoli jiná aplikace však mohla změnit načasování více, například spuštění programu.