[omniORB] omni problem - getting a core dump

[Agarwal, Shelendra]

Hi All,
This is an urgent issue happening regularly in production machine.
We are using omniORB_280 in one of our Application.
I am attaching the core trace below:

===============
***@fmsra-center sys]$ gdb omniNames core.28513
GNU gdb Red Hat Linux (6.3.0.0-1.62rh)
Copyright 2004 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" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib64/tls/libthread_db.so.1".

Core was generated by `/opt/app/detection/rt/sys/omniNames -start 14285 -logdir /opt/app/detection/rt/'.
Program terminated with signal 6, Aborted.
Reading symbols from /opt/app/detection/rt/sys/libomniORB2.so.8...(no debugging symbols found)...done.
Loaded symbols for /opt/app/detection/rt/sys/libomniORB2.so.8
Reading symbols from /opt/app/detection/rt/sys/libomniDynamic2.so.8...(no debugg
Loaded symbols for /opt/app/detection/rt/sys/libomniDynamic2.so.8
Reading symbols from /opt/app/detection/rt/sys/libomnithread.so.2...(no debuggin
Loaded symbols for /opt/app/detection/rt/sys/libomnithread.so.2
Reading symbols from /lib64/tls/libpthread.so.0...(no debugging symbols found)..
Loaded symbols for /lib64/tls/libpthread.so.0
Reading symbols from /opt/app/detection/rt/sys/libtcpwrapGK.so.1...(no debugging
Loaded symbols for /opt/app/detection/rt/sys/libtcpwrapGK.so.1
Reading symbols from /usr/lib64/libstdc++.so.5...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libstdc++.so.5
Reading symbols from /lib64/tls/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/tls/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found).
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.2
#0 0x0000002a9630a745 in raise () from /lib64/tls/libc.so.6
(gdb) bt
#0 0x0000002a9630a745 in raise () from /lib64/tls/libc.so.6
#1 0x0000002a9630beb3 in abort () from /lib64/tls/libc.so.6
#2 0x0000002a96303dc9 in __assert_fail () from /lib64/tls/libc.so.6
#3 0x0000002a956c13b1 in Strand::decrRefCount () from /opt/app/detection/rt/sys/libomniORB2.so.8
#4 0x0000002a956ce9a0 in tcpSocketRendezvouser::run_undetached () from /opt/app/detection/rt/sys/libomniORB2.so.8
#5 0x0000002a95b3ddc0 in omni_thread_wrapper () from /opt/app/detection/rt/sys/libomnithread.so.2
#6 0x0000002a95c5ac64 in start_thread () from /lib64/tls/libpthread.so.0
#7 0x0000002a963b3243 in thread_start () from /lib64/tls/libc.so.6
#8 0x0000000000000000 in ?? ()
(gdb) where
#0 0x0000002a9630a745 in raise () from /lib64/tls/libc.so.6
#1 0x0000002a9630beb3 in abort () from /lib64/tls/libc.so.6
#2 0x0000002a96303dc9 in __assert_fail () from /lib64/tls/libc.so.6
#3 0x0000002a956c13b1 in Strand::decrRefCount () from /opt/app/detection/rt/sys/libomniORB2.so.8
#4 0x0000002a956ce9a0 in tcpSocketRendezvouser::run_undetached () from /opt/app/detection/rt/sys/libomniORB2.so.8
#5 0x0000002a95b3ddc0 in omni_thread_wrapper () from /opt/app/detection/rt/sys/libomnithread.so.2
#6 0x0000002a95c5ac64 in start_thread () from /lib64/tls/libpthread.so.0
#7 0x0000002a963b3243 in thread_start () from /lib64/tls/libc.so.6
#8 0x0000000000000000 in ?? ()
==============

It will be of great help if you can describe the cause of this core.

Thanks and Regards,

Shelendra Agarwal
CentralView L2
HP, India

[Duncan Grisby]

Post by Agarwal, Shelendra
This is an urgent issue happening regularly in production machine.
We are using omniORB_280 in one of our Application.

omniORB 2.8.0 was released very nearly 10 years ago. I'm afraid nobody
is likely to be able to help you with it.

Are you able to upgrade to 4.1.4, at least for omniNames if not for your
application code?

Cheers,

Duncan.

[Agarwal, Shelendra]

Hi Duncan,
Thanks for your reply.
You see that this issue (core dump) is happening regularly in production Machine at Customer's Site and it is not possible to upgrade to new version at least for now.
We will appreciate if you can help us in understanding this core trace and likely cause of this core.
Just for your information someone logged a message in www.omniorb-support.com in Dec, 1999 with similar core trace.
http://www.omniorb-support.com/pipermail/omniorb-list/1999-December/014378.html



Thanks and Regards,

Shelendra Agarwal
CentralView L2
HP, India

-----Original Message-----
From: Duncan Grisby [mailto:***@grisby.org]
Sent: Friday, August 21, 2009 8:21 PM
To: Agarwal, Shelendra
Cc: omniorb-***@omniorb-support.com; Vijayan, Pratheesh T (HP CentralView)
Subject: Re: [omniORB] omni problem - getting a core dump

Post by Agarwal, Shelendra
This is an urgent issue happening regularly in production machine.
We are using omniORB_280 in one of our Application.

omniORB 2.8.0 was released very nearly 10 years ago. I'm afraid nobody
is likely to be able to help you with it.

Are you able to upgrade to 4.1.4, at least for omniNames if not for your
application code?

Cheers,

Duncan.