sigsegv on linux during running a simple jogl program

OpenGL Development JOGL Development
#1

I have been noticing that when I run simple jogl programs on Linux and attach a ddd session to the javavm, I can see signal exceptions being thrown. What I normally get are SIGFPE and SIGSEGV. I’ve tried this with:

  • Jogl1.0, Jogl1.1, and 1.1.1
  • different graphics card (Intel & Nvidia)
  • different Linux machines.
  • I have tried this with CentOS 4 and CentOS 5.
  • different sample programs and my own code

If I hit continue in ddd, the program recovers and continues (it seems to close the thread in question).

I downloaded my example code ( a simple 3d triangle base pyramid) from:

I’ve noticed issue 124 https://jogl.dev.java.net/issues/show_bug.cgi?id=124 but this occurs when at random times during the running of the program, not at exit.

Is this a known problem? Is there a reason these happen and what can I do to stop them?

Thanks.

#2

SIGSEGVs raised by the JVM are normal, and are used for things like detecting and raising NullPointerExceptions as well as starting garbage collections. SIGFPE should not be raised, I think, though it’s possible it may come from the OpenGL implementation. If you can provide a stack trace from the debugger I might be able to tell whether it’s intended. In both cases, if the program continues normally then there’s nothing to worry about. In general when debugging things in the context of the JVM it’s necessary to ignore SIGSEGV, SIGUSR1, SIGUSR2, and possibly SIGPIPE (not sure why the latter is in my .dbxrc). It’s true that having to ignore SIGSEGV makes it difficult to debug native code, but if you’re writing in Java using JOGL then you shouldn’t have to worry about bugs in native code since it’s almost all autogenerated.

#3

Ken,

Thanks for you quick response. Unfortunately, the issue is that we are using the JOGL code as part of C++/Java application through a JNI. What appears to be happening is that the graphics card driver is handling the SIGSEGV in such a way that it does not cause the application to exit. Since we have defined our own C++ signal handlers, our C++ native code captures and handles these signals. We have run a Java program with the same C++ JNI but without JOGL code and we do not see SIGSEGVs happening. I also have tried to put in some signal handling into my java code by implementing my own SignalHandler but java won’t let me override a SIGSEGV or a SIGFPE. I get an error:
java.lang.IllegalArgumentException: Signal already used by VM: SIGSEGV

Do you expect these kinds of exceptions to be raised from a JOGL program? One thing to note, we were using C++ and OpenGL directly and did not run into these issues. It seems to be specific to JOGL and java.

The traces aren’t that useful either:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1458390112 (LWP 7057)]
(gdb) backtrace
#0 0xad062f84 in ?? ()
#1 0x3f800000 in ?? ()
#2 0x3f800000 in ?? ()
#3 0x3f800000 in ?? ()
#4 0x3f800000 in ?? ()
#5 0x00001d80 in ?? ()
#6 0x00001f80 in ?? ()
#7 0xa912a6b8 in ?? ()
#8 0xad062e81 in ?? ()
#9 0x00000008 in ?? ()
#10 0xad062a93 in ?? ()
#11 0xa912a530 in ?? ()
#12 0xa912a678 in ?? ()
#13 0xa912a67c in ?? ()
#14 0x008548a1 in malloc_consolidate () from /lib/tls/libc.so.6
(gdb) cont

< then continues for a little while>

Program received signal SIGSEGV, Segmentation fault.
0xb5de17cc in ?? ()
(gdb) backtrace
#0 0xb5de17cc in ?? ()
#1 0xb5dd9b9c in ?? ()
#2 0xae187430 in ?? ()
#3 0xb5dd5d22 in ?? ()
#4 0xae199228 in ?? ()
#5 0x00000003 in ?? ()
#6 0xa912acc8 in ?? ()
#7 0xa912acc8 in ?? ()
#8 0xadd3ece0 in ?? ()
#9 0xadd3eca8 in ?? ()
#10 0xadd3eca8 in ?? ()
#11 0xa912acfc in ?? ()
#12 0xadd3eca8 in ?? ()
#13 0xae191f28 in ?? ()
#14 0xae199228 in ?? ()
#15 0xae199228 in ?? ()
#16 0x08261c00 in ?? ()
#17 0x00000000 in ?? ()

Thanks for your help,
Nisha

#4

If you’re using the Java-level SignalHandler class I’m not sure there’s a workaround for this. If you need to register a native level signal handler then see these two results from this Google search.

SIGSEGV I would expect but not SIGFPE. It isn’t clear to me exactly what the issue is. If the program is working then you can ignore the signals. If the issue is that they’re making it hard to debug then you can ignore them in gdb / ddd, unless of course it’s a crash in your native code that is the problem. In this case the hs_err log should help track down where the problem might be.

#5

Ken,

Thanks for your response. I did try the java handling but that didn’t help.

The reason that this is an issue is because the java code needs to interface to our C++ code and our driver. That C++ code has to implement signal handling to make sure that the driver is shut down properly. When I run our java code but do not do any jogl code, I do not get the SIGSEGV. We cannot remove the C++ signal handling because of the driver cleanup issue.

I expected to find an hs_err log but it is not there. I expected it to be in directory where I am building and running. (BTW, I am using Eclipse if that makes any difference.)

– Nisha

#6

If you have C++ signal handlers then I think you should study the signal chaining link I sent you more. You may be inadvertently interfering with the JVM’s internal signal handling. Beyond this I’m afraid I don’t have any more suggestions at this point.