similar to: [LLVMdev] Asan: Print stacktrace on SIGFPE

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

> -----Original Message----- > From: Cameron McInally <cameron.mcinally at nyu.edu> > Sent: Friday, June 14, 2019 4:02 PM > To: Eli Friedman <efriedma at quicinc.com>; LLVM Developers Mailing List <llvm- > dev at lists.llvm.org> > Cc: Craig Topper <craig.topper at gmail.com>; Kaylor, Andrew > <andrew.kaylor at intel.com> > Subject: [EXT]

Just a quick question... I've been attempting to trap floating point badness by setting up a SIGFPE handler. However, I'm not seeing it trigger, even for simple test code that forces division by zero. I'm generating bitcode with llvm-gcc and then executing it with a (modified) version of the jitter, for reference. Is there any arcane magic necessary to turn on SIGFPE

Hi, I'm running the latest CVS HEAD version of asterisk, and I'm experiencing hangups during voice conversation. This happens quite regularely and often. The problem is in dsp.c, line 1235, where it says accum /= len; But `len', at this point, is 0, resulting in a SIGFPE. The routine ast_frame *i4l_read() in channels/chan_modem_i4l.c:411 is setting p->fr.datalen to

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 >

On Tue, 18 Apr 2006 23:27:39 -0700 Evan Cheng <evan.cheng at apple.com> wrote: > Hi Simon, > > The x86 backend does generate scalar SSE2 instructions. For your > example, it should emit something like: Oh, how did you get this ? [...] > > There is nothing here that should cause an exception. Are you using a > release or cvs? CVS. >From what I remember,

Hi All, Currently libfuzzer depends on (often freshly built) clang, yet the dependency is not explicitly specified in cmake. That leads to various issues: for instance, it’s not possible to check out LLVM repo and run libfuzzer tests: one would often need to compile fresh clang first, and then create a separate build directory, where libfuzzer could be tested. For the buildbot this problem is

> Does anyone see good reasons why libFuzzer should remain in llvm repo (as > opposed to moving it to compiler-rt)? Does moving LibFuzzer to compiler-rt imply that it is compiled as part of compiler-rt and shipped with it? How does that fit with LibFuzzer's model of allowing the user to provide their own `main()`. Would you just build two different libraries. One with a `main()` and

r247321 refactors the code so that it should build on Mac. I haven't actually tested it on Mac -- so please help me and send follow up patches if needed. check-fuzzer will still fail because some of the libFuzzer tests require dfsan. I'd use some help from someone with a Mac to modify lib/Fuzzer/test/CMakeLists.txt so that it does not run dfsan-dependent tests on Mac. Thanks, --kcc On

On Tue, May 2, 2017 at 4:28 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, May 2, 2017 at 12:26 PM, George Karpenkov <ekarpenkov at apple.com> > wrote: > >> From my understanding, all these problems can be solved entirely >> > by moving libfuzzer to compiler-rt, where (other) sanitizers already >> reside. >> >

Hi there. I’m trying to use LibFuzzer on OSX and face some issues: I checked out LibFuzzer documentation[1] and managed to proceed until the final step of the first example. Now I see linker errors related to dfsan, dfsan’s documentation[2] states explicitly “DataFlowSanitizer is a work in progress, currently under development for x86_64 Linux.”. Does it mean that LibFuzzer available only on

On 9 May 2017 at 18:55, Kostya Serebryany <kcc at google.com> wrote: > > > On Tue, May 9, 2017 at 10:23 AM, Dan Liew <dan at su-root.co.uk> wrote: >> >> > Does anyone see good reasons why libFuzzer should remain in llvm repo >> > (as >> > opposed to moving it to compiler-rt)? >> >> Does moving LibFuzzer to compiler-rt imply that it

Hi -- I'm trying to package R for inclusion on some upcoming Red Hat Powertools distribution. I have started with the 0.61 version packaged by Martyn Plummer <plummer at iarc.fr> (Thanks Martyn!) and have upgraded to 0.62-2. I have succeeded in running R demo's on i386-redhat-linux-gnu, and now I am also trying to get the alpha and sparc versions working. On sparc-redhat-linux,

I am working of using libfuzzer and asan to test out a third-party library. As demonstrated in the tutorial, I wrote a fuzz target to fuzz a specific function in the library. The fuzz target is then linked to the library and compiles clean and I do see some tests generated by the fuzzer. However, I have some questions regarding the "right" way to go about doing this. I have doubts that

On Wed, 19 Apr 2006 19:28:34 +0100 Simon Burton <simon at arrowtheory.com> wrote: > > >From what I remember, this is a bug in debian libc: > some floating point flags are set incorrectly causing SIGFPE. > Can't find the bug report ATM. Oh, it just showed up on numpy-discussion: http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 """ #include

It might be a wider problem than libfuzzer. I did want to raise the problem asap and libfuzzer is something we know has the problem. If it came across as "libfuzzer is evil" that was not my intent, sorry! --paulr From: Kostya Serebryany [mailto:kcc at google.com] Sent: Thursday, December 01, 2016 2:53 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev]

I have a project I want to do based on Libfuzzer. Is there a separate list for it or should I bring up any ideas for it here? What I have in mind is to fuzz Postgres. Trying to fuzz the SQL interpreter in general is not very productive because traditional fuzzers try to execute the entire program repeatedly and it has a fairly high startup and shutdown cost. Also the instrumentation-guided

On Tue, May 9, 2017 at 1:56 PM, George Karpenkov <ekarpenkov at apple.com> wrote: > Again, after offline conversation with Chris Bieneman: > > - move to compiler-rt would be too complicated due to change in licenses > - it would make much more sense to move to “tools” folder instead, for > the following reasons: > * conceptually, it’s a tool, not a library > *

> I really like the property of libFuzzer living in its own place so that > it's easy to use without building the world But it’s not: the implementation of the coverage instrumentation is done in one of the sanitizers, so it’s impossible to just use libFuzzer without them. Furthermore, I would think that almost all libFuzzer users would use a sanitizer while fuzzing. I can see a few

> On May 10, 2017, at 4:43 PM, George Karpenkov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Actually, there’s another problem we have missed: libraries under `build/lib` are not installed into toolchain > on mac os (and neither on linux, I would suppose). Actually that isn't accurate. By default we don't install the LLVM libraries, but that is completely