Roberto Bertolini

I think we need to revert this @io-no Slow test suite on my PC before merge: ``` ➜ test git:(dev) git checkout 52d5dcf3991fb3c4705f68b82118968c9a8619d0 Note: switching to '52d5dcf3991fb3c4705f68b82118968c9a8619d0'. [...] Slowest test...

``` Slowest test durations ---------------------------------------------------------------------- 13.857s test_deep_dive_division (scripts.deep_dive_division_test.DeepDiveDivisionTest.test_deep_dive_division) 11.801s test_vmwhere1 (scripts.vmwhere1_test.Vmwhere1Test.test_vmwhere1) 6.794s test_vmwhere1_callback (scripts.vmwhere1_test.Vmwhere1Test.test_vmwhere1_callback) ---------------------------------------------------------------------- Ran 216 tests in 56.606s ``` Issue solved @io-no

On the latest commit I get ``` Slowest test durations ---------------------------------------------------------------------- 14.879s test_deep_dive_division_recvline (scripts.deep_dive_division_test.DeepDiveDivisionTest.test_deep_dive_division_recvline) 14.644s test_deep_dive_division_recv (scripts.deep_dive_division_test.DeepDiveDivisionTest.test_deep_dive_division_recv) 13.143s test_vmwhere1 (scripts.vmwhere1_test.Vmwhere1Test.test_vmwhere1) ``` Looks fine to me now.

We can implement this feature easily by calling sigalarm before execve, but what if the debugged binary sets up a sigalarm handler for it? Do we care? The other way...

Mhmm we can make it work without the third thread, with timeouts in the background thread loop

Dear @MarcoMeinardi , rest assured that we have assigned our most estemeed developer on this issue. Consider it fixed.

Choosing the mode at access time would multiply the amount of syscalls we need to do this, as at every access we would need to perform open+seek+read+close. It's probably still...

All memory is shared in multithreaded processes (the different stacks are just at different addresses) and I am pretty sure that /proc/[pid]/mem is process-scoped, so I do not see a...

I personally see this feature as opt-in just for now, if we don't observe any drawbacks I'd propose to switch the default to fast_memory=True and keep the ptrace implementation as...

So you are proposing something like d.memory going through ptrace and d.fast_memory using proc/pid/mem? What would the benefit of two different views be?