|
From: Roger L. <ro...@at...> - 2019-03-12 17:15:44
|
Hi all, I've been taking another look at the experimental tool I wrote last year, which allows a user to have heap allocation and syscall failures as their code is running, based on what call stacks have been seen before. I've split the patch up into four parts to make it easier to review. They are all on https://bugs.kde.org/show_bug.cgi?id=396290 The first patch is the basic tool which allows heap allocation failures only. It lets you control whether allocation failures happen based on the size of allocation, on random chance, and on the count of failures so far. Allocations that are made to fail have their callstack saved to a file, which can then be reloaded on a subsequent run. There are gdb monitor commands and client requests which allow control of whether failures are allowed amongst other things. The big downside to this patch is that there is no instrumentation and so it isn't possible to have an --alloc-toggle-fn option similar to the callgrind --toggle-collect option to give straightforward control of where testing is carried out. With this patch, you either have to test the entire program at once, or use client requests to toggle whether failures are enabled. This is still useful - in automated testing you could use client requests to keep repeating a test until no new failures are reported, for example. The second patch adds a function to coregrind that allows tools to set an error code on syscalls. The third patch adds syscall failures to the tool, with a variety of options for controlling how and what failures occur, such as specifying what errno a certain syscall will return. It assumes that appropriate instrumentation is present and so adds the --alloc-toggle-fn and --syscall-toggle-fn options. There is no instrumentation code though, so these options don't work. The fourth patch is a cut down version of the instrumentation code from callgrind. It allows use of the --alloc-toggle-fn and --syscall-toggle-fn options, but is a lot of code duplication essentially just to add support for those options. It is only for demonstration purposes. I'd like to hear your thoughts on this as a possible future supported valgrind tool. My own feeling is that without the instrumentation code or the toggle functions it is in a good state, but might not be that practical for larger programs unless users are willing to use client requests. With the toggle functions it becomes really useful, but needs a better solution than importing a load of callgrind code. Cheers, Roger |