- User Since
- Feb 14 2017, 7:36 AM (153 w, 5 d)
Wed, Jan 22
one rebase is never enough
Given that this is a simple change and Kostya is a busy man I'm going to go ahead and land this. We can always revert if there is any concern.
rebase + getting ready to commit
Tue, Jan 21
Thu, Jan 2
Dec 12 2019
Landed as https://github.com/llvm/llvm-project/commit/926fa4088cc2d6fdcd9301e80d05d9310009b660, not sure why it hasn't closed automatically.
Dec 9 2019
Another (real) example, imagine a fuzz target like this: https://cs.chromium.org/chromium/src/net/spdy/fuzzing/http2_frame_decoder_fuzzer.cc?rcl=0be62a8d95f7fa1455fce1a76f0fa5b8484d0c8c&l=34
Here's a concrete example:
Dec 6 2019
If you're running fuzz targets manually, then it makes sense -- you need to type one command less to print the crash input. Although it seems like cargo fuzz can do that for you as well, so it will be still a single command.
The problem with approaches like this is that you still need to identify the last failing use case and run it a second time. With this patch the user experience is very smooth: the failing string is formatted and printed immediately.
Dec 4 2019
- [compiler-rt] FDP: assert that num_bytes_to_consume == 0 when size == 0.
TBR simple change.
- remove empty line
Nov 14 2019
Ha, nice! LGTM. Is there any test you could easily update or add to reproduce this corner case?
Oct 9 2019
@Dor1s - any chance you know more folks actively working on sancov who have the bandwidth to review?
Oct 2 2019
@vsk Vedant, sorry I'm a bit swamped right now and may not be able to review this promptly. Please let me know If my feedback is important here, I'll try to make up some time in that case. Sorry!
Sep 25 2019
I think Matt is right, but I wouldn't mind to have the stacktrace and stats just to be consistent with the other crashes. Also, having a stacktrace should increase the chances that such a crash would be handled by fuzzing infrastructure and reported to people.
Sep 16 2019
Self-approval, removing a stale file that I've gradually migrated to another location.
Sep 13 2019
Sep 11 2019
Hm, doesn't fail for me, but I guess the feature detection might be platform-dependent to some extent, so I'm fine with replacing the number of the features with a regex. Do you want to upload a change, or should I?
Address review comments
Sep 10 2019
Sep 9 2019
Made the regexp more explicit. TBRing to fix the broken buildbot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/23356/steps/check-sanitizer%20in%20gcc%20build/logs/stdio
Added a test
Thanks everyone! Good point regarding the test, added!
Removed @kcc as a "blocking" reviewer, since we've discussed this offline last week. I'll check with @vitalybuka regarding potential breakages and also ping @samsonov. Other than that, should be good to go.
Sep 6 2019
Sep 4 2019
Sep 3 2019
Implement another solution brainstromed with kcc@
Aug 29 2019
Pardon my ignorance, but what does rdar://54843625 mean? I guess it's not http://openradar.appspot.com/54843625 ? Is it something I can access? :)
Aug 16 2019
Aug 14 2019
Guys, thanks a lot for the feedback! Some answers below, I'll get back to the code soon.
Aug 13 2019
Friendly ping :) Feedback on the description would be the most important at this point, as I feel like I can improve the code a bit more. But if you could check out the code, that would be also great. Note there are at least two TODOs that I'll address before merging. It's still a draft, even though it works.
Aug 12 2019
Update the test a bit more
Actually updated the test to prove everyone (including myself) that this works.
fix a typo
Aug 9 2019
Use LOADED instead of INITED, plus fix alignment of keywords in the log