Adding reset feature to dfsan. This is especially needed in the context of fuzzing. Otherwise, we would run out of labels very fast.
Diff Detail
- Build Status
Buildable 9144 Build 9144: arc lint + arc unit
Event Timeline
also, would like to hear from @pcc
include/sanitizer/dfsan_interface.h | ||
---|---|---|
55 | Explain thread-[un]safety | |
lib/dfsan/dfsan.cc | ||
180 | Add some code to check-fail in case __dfsan_last_label has changed (i.e. to check that no other threads are messing around) Then, add a test with threads that will trigger that check-fail. |
include/sanitizer/dfsan_interface.h | ||
---|---|---|
55 | Please also document that there should also be no active stack frames which may be processing values with non-zero labels. | |
test/dfsan/reset.cc | ||
19 | Is this safe, given the constraint I mentioned above? I'd prefer to move the code that creates labels into a separate function. |
lib/dfsan/dfsan.cc | ||
---|---|---|
180 |
That means I will have to add a flaky test that sometimes passes and sometimes fails. |
lib/dfsan/dfsan.cc | ||
---|---|---|
180 | You can create a test that runs a very long loop in a thread and thus guarantee that the test will crash 9999999999999999 our of 100000000000000 times. |
lib/dfsan/dfsan.cc | ||
---|---|---|
180 | I tried that and let it run for 12+ hours and could not trigger the assertion after the atomic store to fail. But what I did is control the thread scheduling from the test and make an assertion in that test fail (check the update). |
lib/dfsan/dfsan.cc | ||
---|---|---|
175 | Is this part necessary? I believe that the mmap call above will also reset the union table to zero. | |
test/dfsan/reset_multithread.cc | ||
21 | Is this really testing for the property that Kostya mentioned? It seems like it is trying to reproduce the scenario where the labels are created in the other thread *after* (i.e. not parallel with) the reset. You might have better luck reproducing if you change the dfsan_reset function to do this: void dfsan_reset() { atomic store to dfsan_last_label; mmap; assert(atomic load from dfan_last_label == 0); } |
lib/dfsan/dfsan.cc | ||
---|---|---|
175 | You're right it's not. Thanks! |
Please add the other hooks in a separate patch.
test/dfsan/reset_multithread.cc | ||
---|---|---|
20 | Is this assert necessary? It's basically testing for the same thing as the assert in dfsan_reset, isn't it? |
Explain thread-[un]safety
I assume this function is *not* thread safe and thus the comment must be clear on this topic.
Add '.' at the end