search for: alarmhandl

...============ RCS file: /home/ncvs/src/usr.sbin/lpr/common_source/displayq.c,v retrieving revision 1.4.2.5 retrieving revision 1.4.2.6 diff -u -u -r1.4.2.5 -r1.4.2.6 --- displayq.c 1997/10/15 12:25:35 1.4.2.5 +++ displayq.c 1997/11/07 13:20:29 1.4.2.6 @@ -242,6 +242,7 @@ savealrm = signal(SIGALRM, alarmhandler); alarm(CT); fd = getport(RM, 0); + alarm(0); (void)signal(SIGALRM, savealrm); if (fd < 0) { if (from != host) Index: src/usr.sbin/lpr/lpd/printjob.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/lpr/lpd/printjob.c,v retrieving...

On Sat, Sep 5, 2015 at 11:50 AM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 5, 2015 at 6:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > This is more like a limitation of asan, not libFuzzer. > > By design, asan does not recover from the first crash. > > This feature has been criticized quite a lot, but I am still convinced > this >

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

...89a in fuzzer::Fuzzer::AlarmCallback (this=0x7fffd956f440) at /home/brian/tmp/testing/llvm_src//llvm/lib/Fuzzer/FuzzerLoop.cpp:73 #19 0x0000000000579b97 in fuzzer::Fuzzer::StaticAlarmCallback () at /home/brian/tmp/testing/llvm_src//llvm/lib/Fuzzer/FuzzerLoop.cpp:57 #20 0x0000000000572355 in fuzzer::AlarmHandler () at /home/brian/tmp/testing/llvm_src//llvm/lib/Fuzzer/FuzzerUtil.cpp:49 #21 <signal handler called> #22 __sanitizer::internal_mmap (addr=0x621000f20000, length=65536, prot=prot at entry=3, flags=flags at entry=50, fd=fd at entry=-1, offset=offset at entry=0) #23 0x00000000004edbf8 in __sa...