> > This bugfix / patch consists of two portions > >=20 > > 1) A 'Z' option which forces strace to use ptrace() memory access > > routines all the time instead of vm-based memory access routines if > > they are present.. This allows a fallback if you find that VM based > > requests are failing or producing incorrect output. The existing > > ptrace based methods are quite robust and tested :-) > > As there are no known issues with kernel implementation of process_vm_readv, > why should anybody want to disable fast process_vm_readv based code > in favour of slow PTRACE_PEEKDATA based one?
The kernel implementation is correct; however there are issues with strace's use of that feature; hence the bugfix. The option allows one to disable the process_vm_readv at the user's choice, so that they can see if the problem exists with both methods of ptrace memory access, or only happens with with vm_process_readv(). It also allows testing of strace with the same kernel interface on multiple variants of linux, and give performance comparisons. It also allows comparing linux ptrace/vm_process_readv to ptrace on other platforms. > Well, it was a genuine bug in process_vm_readv based code, thank you for > reporting it, although I haven't got it from your description and patch > after the first read. > > It's fixed by commit v4.10-56-g4832134 which also contains a regression > test. There is also a follow-up cleanup commit v4.10-57-gea1fea6. Thanks. I noticed afte the fact I hadn't moved the fixes to the comments forward from the strace-5.8 fix due to random changes in that comment in the middle. > I've tried to reproduce alignment issues with process_vm_readv from your > description, but without success. It is difficult to reproduce, but it is reproducible. Our project, the SWAMP, happens to run millions of strace invocations, and the sample set size is large enough that this bug surfaces about 1% of the time. Sometimes it can be 100% with the compilation of a package on some linux platforms. Reproducibility can depend on the exact amount of memory in the machine, and other factors, such as process scheduling or other things happening on a system which are beyond control. > > When this alignment constraint is relaxed, or strace incorrectly issues > > reads across page boundaries, strace fails with a error of > >=20 > > "umovestr: short read (%d < %d) @0x%lx" > >=20 > > due to the incorect code. In addition, since the vm-based code doesn't > > correctly update the address and lengths of the region to be accessed, > > the fallback code -- which is implemented correctly, fails to work. > > There is no fallback to PTRACE_PEEKDATA based code in case when > process_vm_readv has read at least one byte. It has been about a year since I worked on this, and I put it into the current strace last month. I believe that the fixes I provide do allow fallback to work correctly in the face of process_vm_readv() failure. I may have left out some of the code which allowed it; it has been a while since it has been on my mind. I would need to go back and review last years test cases to verify that, however. > > The new code also deals with arbitrary page sizes correctly in extracting > > data using the vm mode, instead of relying upon a 4k pagesize. > >=20 > > 3) Reproducing this error depends upon where the kernel is putting items > > in memory, and may also be based on the load of the kernel. As such, > > this error can be difficult to reproduce. > > Actually, the reproducer is quite simple: > http://sourceforge.net/p/strace/code/ci/HEAD/tree/tests/umovestr.c Nice. Bolo -- Josef T. Burger ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Strace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/strace-devel
