[omniORB] Apparent crash-level bug in CORBA::Object::_is_a
Nathaniel Smith
njs@uclink4.berkeley.edu
Tue, 1 Feb 2000 02:51:18 -0800
On Mon, Jan 31, 2000 at 11:56:43AM +0000, Duncan Grisby wrote:
> On Monday 31 January, Nathaniel Smith wrote:
>
> > This is omniorb 2.8.0, on debian potato, using the packaged versions of
> > everything. I've tried getting a stack trace, but it's remarkably unhelpful,
> > since the program in question is threaded, etc. Someone said that it might
> > be related to my omniorb.cfg consisting of:
>
> I don't understand how the program being multi-threaded stops you
> giving a stack trace of the thread which dies. Linux core dumps don't
> work with threads, so you have to run the program under gdb.
>
> > ORBInitialHost WyrmWeyr.frop.org
> > ORBInitialPort 8088
> > rather than the more usual nameservice IOR.
>
> There is a bug in that if you run omniNames with a configuration file
> like the above, pointing to itself, then calls to
> resolve_initial_references() with names which don't exist cause an
> infinite recursion which blows up the stack. In this case, it is the
> omniNames process which dies. To be safe, you should run omniNames
> with a different (empty is fine) omniORB.cfg.
>
> That problem doesn't have anything to do with _is_a(), though.
Oddly, though the crash was perfectly consistent a few days ago and I
haven't touched my omniorb configuration since then, I am now unable
to reproduce it. Calls to _narrow just fail correctly. If I'm able
to reproduce it again, I'll re-raise the issue, otherwise, I guess you
can ignore this report.
-- Nathaniel