0

One of my programs in solaris crashes suddenly without any traces in the logs with SIGABRT

The following is the core dump

threading model: multi-threaded
status: process terminated by SIGABRT (Abort)
C++ symbol demangling enabled
libc.so.1`_lwp_kill+0xa()
libc.so.1`raise+0x19()
libc.so.1`abort+0x90()
libCrun.so.1`void __Cimpl::default_terminate+9() 
libCrun.so.1`void __Cimpl::ex_terminate+0x25() 
libCrun.so.1`void __Crun::ex_throw+0x26() 
libTAO.so.2.0.7`void TAO_ORB_Core::check_shutdown+0x4c()
0x319c9a8()

There seems to be no issues with the code as the process crashes suddenly when its idle.

Then I decided to look at the syslog, and found the following message

[ID 702911 auth.error] [22216] Run idle timeout reached (32400 seconds)

Any idea why this happens?

Johnny Willemsen
  • 2,942
  • 1
  • 14
  • 16
vibz
  • 157
  • 1
  • 12
  • 1
    Looks like there was an unhandled exception got thrown in your program. I'm afraid nobody can tell why w/o source code. – Windoze Jan 20 '15 at 05:15
  • What program is this exactly? Do you have the source code? Can you `grep -r "Run idle timeout reached"` in the source? – John Zwinck Jan 20 '15 at 05:17
  • Make sure that you don't throw any exceptions from, say, a destructor when another exception is already propagating. This can happen if you use the [RAII](https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) pattern. If your code throws, then the destructor of your "guard" will be called, which will blow up. Just a wild guess of course based on the stack frames (you're trying to throw but the runtime calls terminate at once). We'd really need to see the source. – Christian.K Jan 20 '15 at 05:19

1 Answers1

0

SIGABRT is raised because you have an unhandled exception. The stack trace tells you where the exception came from:

void TAO_ORB_Core::check_shutdown()

The documentation for that function says it throws an exception if the ACE ORB has shut down, meaning the program needs to terminate. So the question becomes, why does your application logic shut down the ORB when it hits that "timeout"? That's something you'll need to dig into your application to find out--I don't think we have the source for that.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 1
    Do you have a try/catch around your call to ORB run? – Johnny Willemsen Jan 20 '15 at 07:46
  • @JohnnyWillemsen: if the OP does, it's for some exception type other than the one being thrown here. A try/catch would avoid SIGABRT but I'm not sure it solves the real problem, which seems to be "why does the program stop?" – John Zwinck Jan 20 '15 at 07:47
  • 1
    @John Zwinck thanks for that clue // CORBA::ORB *orb; orb->run() // This internally calls TAO_ORB_Core::check_shutdown. which would throw an exception if ORB is shutdown, as you had pointed out. I figured out that ORB is infact being shutdown when it hits the timeout. (I will have to figure it out why is it done) I will try to add a try, catch block to catch this exception for the moment.. // try { orb->run(); } catch(CORBA::SystemException&) { cout << "Exception" << endl; return 0; } // – vibz Jan 20 '15 at 11:51