SIGABRT (SIGSEGV) signal

[alverson]

When I start the client side of my application (Windows), the various proxies are obtained, methods are called, etc. and no errors occur. If I wait approximately 60 seconds, leaving up the server side of my app (Red Hat Linux) which are executing within icebox services and then repeat, one my services is exiting with a SIGABRT or SIGSEGV. I’ve obtained a core file with the following backtrace:

#0 0x0000003445430265 in raise () from /lib64/libc.so.6
#1 0x0000003445431d10 in abort () from /lib64/libc.so.6
#2 0x0000003449008c64 in _Unwind_Resume () from /lib64/libgcc_s.so.1
#3 0x00002aaaab5bc5fa in IceDelegateM::Bt::ULS::validateOperToken ()
from /home/acepremier/lib/libBtIceInterface.so.1
#4 0x0000003445752a00 in main_arena () from /lib64/libc.so.6
#5 0x0000003445752a00 in main_arena () from /lib64/libc.so.6
#6 0x0000003447c45170 in vtable for IceInternal::OutgoingMessageCallback () from /usr/lib64/libIceBox.so.34
#7 0x000000001ae1f150 in ?? ()
#8 0x0000000000000000 in ?? ()

ULS proxy method validateOperToken is called on every instance when I bring up the client side of my app, but for some reason, if I wait for 60 seconds to execute it again, I get the SIGABRT (SIGSEGV) with the above backtrace.

I realize that you might need more information to the full context of the application, but I thought I would post the question to see if the 60 second delay is significant because I can repeat the startup sequence any number of times as long as I don't wait the 60 seconds. I've tried playing with the ACM properties to no avail.

Any ideas what might be happening?

[mes]

Hi Dennis,

It's not clear why your service is crashing after the delay. I suggest starting everything up as usual, use gdb to attach to the running IceBox server process that contains your ULS service, and then invoke the proxy operation again. When the crash occurs, you'll be able to poke around in the service using gdb and hopefully gain more insight into the cause of the crash.

If that doesn't help, my next step would be to set a breakpoint inside the implementation of validateOperToken so that I could step line-by-line through the code to find the problem.

Take care,
Mark

[alverson]

Don't spend too much time on this at this point. I think it might be a dependent library being out of date. I've downloaded a needed package for our development environment, and it seems to have solved the problem. The issue was our target deployment environment was acting different than our development environment. Though I'm still not getting where the 60 seconds comes into play