[tao-users] [tao_cosnotification] coredump

[Tomek]

Hi Phill,
See my answers below.

Thanks!
Tomek

2016-01-21 13:12 GMT+01:00 Phil Mesnier <mesnierp at ociweb.com>:

> 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
>
>
> 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?
>

No it isn't.


>
> 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?
>

There are two cores for last three days:
-rw------- 1 root root 10272768 Jan 19 11:02
core-tao_cosnotifica-11-50-51-11986-1453201332
-rw------- 1 root root 28766208 Jan 19 11:48
core-tao_cosnotifica-11-50-51-1719-1453204100

Since then tao_cosnotification works stable.



>
>
> 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?
>

Well, in fact and there may be a sequence of several restarts of consumer
in short period of time - but not all such sequences cause
tao_cosnotification crash.
I will check this again but I am pretty sure that all resources are
released correctly. What in particular should I pay attention to?





>
> Best regards,
> Phil
>
> --
> Phil Mesnier
> Principal Engineer & Partner
>
> OCI | WE ARE SOFTWARE ENGINEERS.
> tel  +1.314.579.0066 x225
> ociweb.com
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.isis.vanderbilt.edu/pipermail/tao-users/attachments/20160121/270ef990/attachment-0001.html>