On Thu, 2008-12-04 at 10:32 -0500, Elena Zannoni wrote: > Can we get these two new people from Redhat posting to this list as they > make progress on utrace?
Ok, here is my part. I created a few testcases for utrace. See http://sourceware.org/systemtap/wiki/utrace/tests I also looked into kernel side of ptrace bugs. I admit success rate on kernel side isn't impressive. Either I am too dumb or utrace's asyncronous nature makes it inherently difficult to track what's going on. I also sent some patches to strace-devel. > The list has been quite for 1.5 months I added utrace-devel to my mail filter which was used to find strace-devel mails. Since both are related and not high volume, will track them together. > There is nothing visible from outside, really. Do you have suggestions? For example, wiki/utrace/tests page. Let's see what can be improved. * Updating it is a chore. * Is it "visible enough"? How many people know that it exists? Do they use these tests? * It does not scale well - some tests might have complex history and current status behind them: - description of the problem for non-initiated - on which kernels and architectures this test is known to fail? Known to work? - does it depend on CPU model and number of CPUs in the system? - if the test is non-deterministic, how difficult is it to hit a bug? and all this is not captured by the wiki page The tests themselves: Currently, there is a blanket env var TESTTIME=NNN seconds, which is supposed to enhance the probability of bugs being not missed. The result, though, is that some bugs are VERY hard to hit and you need to set TESTTIME to ridiculous values like 600, and this incidentally makes ALL tests to run for 10 minutes each, even those which are known to easily find a bug after a few iterations. If bug doesn't happen on a kernel being tested, they iterate for gazillion times. Such test runs last four hours instead of 30 minutes, and it means people won't run them that often. gcc -O2 <testname>.c does not work, you need to add -D_GNU_SOURCE iirc. Many tests are for some really obscure conditions, but after a lot of effort went into making a test, the last 1% of work sometimes was not done: source is insufficiently commented, or comments were written in the heat of the battle and they don't make much sense until you read and reread the test a few times. > What is the plan of integrating with upstream kernel? > What are the plans for gdb starting to use this new stuff? I doubt that > kernel people will accept things until there is a legitimate user. Another concern might be that it looks complex and difficult to debug. More difficult than "old" ptrace. Again, maybe I am just not bright enough for this stuff? -- vda
