search for: sigfpe

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/att...

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....

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 generation? T...

...t; 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, this is a bug in debian libc: some floating point flags are set incorrectly causing SIGFPE. Can't find the bug report ATM. Thanks, Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

...defined behavior. > > We have a few dusty deck codes in-house that depend on this, so I'm > motivated to push our local changes upstream. That said, if no one else > finds value in this, we can keep it local. Do you really need a special way to represent this in IR? If you need a SIGFPE, the frontend can generate the equivalent of "if (x==0) raise(SIGFPE);", which is well-defined across all targets. If you really need a "real" trap, I guess we could expose the x86 idiv as an intrinsic. -Eli

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 p->obuflen which is zero. Has anybody noticed this, too? Since I don't know the code, I cannot suggest a fix, but maybe someone who does is listening? :) For testing purposes, I changed th...

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 <fenv.h> void feclearexcept(int ex) This function should clear the specified exception status bits in the FPU status registe...

...nchronously, and the fact that LLVM doesn't support this >> is rather bad as far as Ada is concerned. That said, the Ada front-end > > You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals? AFAIK, on posix systems only SIGFPE, SIGILL, SIGSEGV and SIGBUS are turned into exceptions. For other signals, if there is no signal handler then the program is terminated; if the user installed a signal handler then it is run, and as far as I know there is no way for a user installed handler to raise an exception at the original po...

On Jun 14, 2011, at 2:11 AM, Duncan Sands wrote: > gcc Ada turns signals into exceptions. As far as I know it does this > completely asynchronously, and the fact that LLVM doesn't support this > is rather bad as far as Ada is concerned. That said, the Ada front-end You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals?

On Thu, 20 Apr 2006, Simon Burton 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 <fenv.h> > void feclearexcept(int ex) > > This function should clear the specified e...

Hi John, On 13/06/11 23:27, John McCall wrote: > On Jun 13, 2011, at 2:12 PM, Andrew Trick wrote: >> Although I believe asynchronous signals are also best handled by the runtime. They can be converted into cooperative exceptions. I have to say I can't see the value in resuming from an interrupt at literally any instruction address. > > For what it's worth, SEH (which

...ith 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'm seeing a SIGFPE with the following stacktrace: gdb /usr/lib/R/bin/R.binary GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying&q...

[+current llvm-dev address] On 03/15/2017 09:23 AM, Hal Finkel wrote: > Hi Samuel, > > What are you taking about? ;) > > The only way to get a SIGFPE from a floating-point division by zero is > to modify the floating-point environment to enable those exceptions. > We don't support that (*). In the default (supported) environment, > floating point division is well defined for all inputs (dividing by 0 > gives inf, by NaN give...

Just as a reality check, I wrote up a demonstration where one link order causes a SIGFPE and another doesn't (and the program is well defined, as far as I can tell). All TUs are compiled with -O3. This is also an instance where we don't actually speculate an inline function, but only DSE across it (after deducing readnone). Here's the link https://github.com/sanjoy/comda...

...10 is propagated into one copy of maybe_devide (in source a), and ptr[0]=10 in caller_a is DSEed ? David On Sat, Feb 27, 2016 at 1:41 PM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just as a reality check, I wrote up a demonstration where one link > order causes a SIGFPE and another doesn't (and the program is well > defined, as far as I can tell). All TUs are compiled with -O3. This is > also > an instance where we don't actually speculate an inline function, but only > DSE across it (after deducing readnone). > > Here's the link ht...

On Sat, Feb 27, 2016 at 1:41 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Just as a reality check, I wrote up a demonstration where one link > order causes a SIGFPE and another doesn't (and the program is well > defined, as far as I can tell). All TUs are compiled with -O3. This is also > an instance where we don't actually speculate an inline function, but only > DSE across it (after deducing readnone). > > Here's the link https:/...

...ndefined behavior. > > We have a few dusty deck codes in-house that depend on this, so I'm > motivated to push our local changes upstream. That said, if no one else > finds value in this, we can keep it local. Do you really need a special way to represent this in IR? If you need a SIGFPE, the frontend can generate the equivalent of "if (x==0) raise(SIGFPE);", which is well-defined across all targets. If you really need a "real" trap, I guess we could expose the x86 idiv as an intrinsic. A real trap would be preferred. I suspect that it would be difficult/expen...

...ct that LLVM doesn't support this >>> is rather bad as far as Ada is concerned. That said, the Ada front-end >> >> You're saying that it turns asynch signals like SIGHUP (which can occur on any machine instruction) into signals? > > AFAIK, on posix systems only SIGFPE, SIGILL, SIGSEGV and SIGBUS are turned into > exceptions. For other signals, if there is no signal handler then the program > is terminated; Ok, that makes sense. These are all synchronous signals, not asynch ones. -Chris

...ron running Linux (in 64 bit). It happens only when I ssh out to a server not supporting SSHv2 and when its public key is not already in the key file. Right after I answer "yes" to the "Are you sure?" prompt I get the exception. Here is the stack trace: Program received signal SIGFPE, Arithmetic exception 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 (gdb) bt #0 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 #1 0x0000002a95a0a905 in BN_div_word () from /usr/lib/libcrypto.so.0.9.7 #2 0x0000002a95a09a09 in BN_bn2dec () from /usr...

...} /* TODO: If the child exited on a signal, then log an *************** *** 846,852 **** signal(SIGUSR1, sigusr1_handler); signal(SIGUSR2, sigusr2_handler); ! signal(SIGCHLD, sigchld_handler); #ifdef MAINTAINER_MODE signal(SIGSEGV, rsync_panic_handler); signal(SIGFPE, rsync_panic_handler); --- 847,853 ---- signal(SIGUSR1, sigusr1_handler); signal(SIGUSR2, sigusr2_handler); ! /* signal(SIGCHLD, sigchld_handler); This doesn't process exit status correctly */ #ifdef MAINTAINER_MODE signal(SIGSEGV, rsync_panic_handler); signal(SIGFPE, rsync_p...