Would it make sense to add the possibility to print a stacktrace also on SIGFPE and not only on SIGSEGV or SIGBUS? Only noticed that LibFuzzer doesn't generate any crash report because asan is not handling the signal. Kind regards, Karl Skomski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/507b1b9c/attachment.html>
On Fri, Jul 31, 2015 at 5:15 AM, Karl Skomski <karl at skomski.com> wrote:> Would it make sense to add the possibility to print a stacktrace also on > SIGFPE and not only on SIGSEGV or SIGBUS? >Yes, under a separate flag (handle_sigfpe=1). I think it's fine to have this flag on by default. Would you like to contribute a patch?> Only noticed that LibFuzzer doesn't generate any crash report because asan > is not handling the signal. >Makes sense. The sanitizers (except maybe a bit of ubsan) typically don't deal with floating point errors, so no one cared about SIGFPE. But libFuzzer may discover some of those errors. --kcc> > Kind regards, > > Karl Skomski > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/6605a473/attachment.html>
SIGFPE is thrown (at least on Linux x86_64) for integer divide by zero. This sounds like a worthy target for a fuzzer. On Fri, Jul 31, 2015 at 12:32 PM, Kostya Serebryany <kcc at google.com> wrote:> > > On Fri, Jul 31, 2015 at 5:15 AM, Karl Skomski <karl at skomski.com> wrote: > >> Would it make sense to add the possibility to print a stacktrace also on >> SIGFPE and not only on SIGSEGV or SIGBUS? >> > > Yes, under a separate flag (handle_sigfpe=1). > I think it's fine to have this flag on by default. > Would you like to contribute a patch? > > >> Only noticed that LibFuzzer doesn't generate any crash report because >> asan is not handling the signal. >> > > Makes sense. The sanitizers (except maybe a bit of ubsan) typically don't > deal with floating point errors, > so no one cared about SIGFPE. But libFuzzer may discover some of those > errors. > > --kcc > > >> >> Kind regards, >> >> Karl Skomski >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150731/a3d6097f/attachment.html>
Apparently Analagous Threads
- [LLVMdev] Asan: Print stacktrace on SIGFPE
- Constrained integer DIV (WAS: Re: Planned change to IR semantics: constant expressions never have undefined behavior)
- [LLVMdev] SIGFPE generation
- Constrained integer DIV (WAS: Re: Planned change to IR semantics: constant expressions never have undefined behavior)
- Hangups - SIGFPE in dsp.c