[tao-users] [tao_cosnotification] coredump

[Phil Mesnier]

Hi Tomek,

> On Jan 21, 2016, at 2:16 AM, Tomek <tomek.w.gran.chaco at gmail.com> wrote:
> 
> TAO version 2.3.1
> ACE version 6.3.1
> 

Note the current release is TAO 2.3.3, ACE 6.3.3. If any changes to TAO/ACE sources are required, they will be applied to the latest release. If you need long term commercial support, please contact one of the companies listed here: http://www.dre.vanderbilt.edu/~schmidt/commercial-support.html <http://www.dre.vanderbilt.edu/~schmidt/commercial-support.html>

> 
> Red Hat Enterprise Linux 7.6.1-80.el7
> 
> I am running the tao_cosnotification with the following options:
> /SA/tao/bin/tao_cosnotification -NoNameSvc -IORoutput /SA/data/fp1/ca/tmp/ntfy.ior -ORBDottedDecimalAddresses 1 -ORBListenEndpoints iiop://:20001
> 

Is there a "svc.conf" file involved?

> 
> It sometimes drops a core. It happens occasionally from time to time and I can not determine any relation to suppliers' or consumers' behavior.
> 
> The core stack is listed below. Is this a bug or can I do anything to avoid those coredumps?
> 

How large is the core? How long does it take to reach this end?


> warning: core file may not match specified executable file.
> [New LWP 2038]
> [New LWP 1719]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/SA/tao/bin/tao_cosnotification -NoNameSvc -IORoutput /SA/data/fp1/ca/tmp/ntfy.'.
> Program terminated with signal 11, Segmentation fault.
> #0  reset_event_loop_thread (this=0x84f3188) at ../tao/Leader_Follower.inl:128
> 128     ../tao/Leader_Follower.inl: No such file or directory.
> Missing separate debuginfos, use: debuginfo-install ace+tao-6.3.1-1.i686
> (gdb) bt full
> #0  reset_event_loop_thread (this=0x84f3188) at ../tao/Leader_Follower.inl:128
>         tss = 0x0


This means the ORB Core was not able to retrieve thread-specific storage. I don't have an explanation as to why not at this time, this is a very unusual situation.

A common pit fall with the Notify service is the use of defaulted proxies/admins for short-lived suppliers and consumers without destroying the server-side objects when done. In those cases the abandoned objects are effectively leaked, and at some point the notify server hits a resource limit and crashes. Is this something you might be doing?

Best regards,
Phil

--
Phil Mesnier
Principal Engineer & Partner

OCI | WE ARE SOFTWARE ENGINEERS.
tel  +1.314.579.0066 x225
ociweb.com <http://ociweb.com/>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/tao-users/attachments/20160121/a8f89f12/attachment.html>