In Java, "5/0" Statement Doesn't Fire Sigfpe Signal on My Linux MAChine, Why

In java, 5/0 statement doesn't fire SIGFPE signal on my Linux machine, why?

Here, it raises a SIGFPE.

You forgot to tell strace to follow children. Add the -f option to strace and you should see something similar to:

[pid  2304] read(3, "\312\376\272\276\0\0\0001\0n\n\0\23\0I\t\0\3\0J\7\0K\n\0L\0M\n\0N\0"..., 2369) = 2369
[pid  2304] --- SIGFPE (Floating point exception) @ 0 (0) ---
[pid  2304] rt_sigreturn(0x1c50800)     = 5
[pid  2304] write(2, "Exception in thread \"main\" ", 27Exception in thread "main" ) = 27
[pid  2304] write(2, "java.lang.ArithmeticException: /"..., 40java.lang.ArithmeticException: / by zero) = 40
[pid  2304] write(2, "\n", 1

How does Java handle division by zero?

In an Unix environment, in which division-by-zero is signalled via SIGFPE, the JVM will have installed a signal handler which traps the SIGFPE and in turn throws an ArithmeticException. If you're interested in the internals, see e.g. man signal

What I believe the OP is asking is based on the fact that, until/unless a SIGFPE handler is in place, most processes will take the default action on receiving this signal, which is to terminate. Thus, e.g. a C program

 int main (int argc, char** argv) { int n = 5 / 0; } 

… if it even compiles, will be killed by the default SIGFPE → SIG_DFL action. The JVM's handler instead issues the (catchable) RuntimeException so that these exceptions can be handled in a native-seeming way.

As several others pointed out, and just for completeness, in point of fact the SIGFPE generated from the kernel is generally mapped from a special interrupt from the processor itself; thus, the “pipeline” is something like

• CPU error trap interrupt → kernel interrupt handler → SIGFPE SIG_DFL → process death

or

• CPU error trap interrupt → kernel interrupt handler → SIGFPE handler in JVM → RuntimeException ArithmeticException in user code

On non-Unix platforms the handling is analogous.

CTRL+C from system() in C not recognized

I'm trying to make a C program that can continue running also after a CTRL+C. ? when the process receives CTRL+C you set the handler for that using sigaction() and in that handler you can specify whether to continue or ignore or whatever you want.

May be you want like this

void sighandle_int(int sign) {
            /*when process receives SIGINT this isr will be called,
            here you can specify whether you want to continue or ignore,
            by signal handler again */
            signal(SIGINT,SIG_IGN);
            //or
            signal(SIGINT,sighandle_int);
    }

Meanwhile use sigaction() instead of signal() as told here What is the difference between sigaction and signal?

What is runtime ?

Runtime describes software/instructions that are executed while your program is running, especially those instructions that you did not write explicitly, but are necessary for the proper execution of your code.

Low-level languages like C have very small (if any) runtime. More complex languages like Objective-C, which allows for dynamic message passing, have a much more extensive runtime.

You are correct that runtime code is library code, but library code is a more general term, describing the code produced by any library. Runtime code is specifically the code required to implement the features of the language itself.

print call stack in C or C++

For a linux-only solution you can use backtrace(3) that simply returns an array of void * (in fact each of these point to the return address from the corresponding stack frame). To translate these to something of use, there's backtrace_symbols(3).

Pay attention to the notes section in backtrace(3):

The symbol names may be unavailable
without the use of special linker
options.
For systems using the GNU linker, it is necessary to use the
-rdynamic linker
option. Note that names of "static" functions are not exposed,
and won't be
available in the backtrace.

---

Related Topics