Can you supply a copy of the nameclt executable in question (or
some other simple recipe for reproducing the problem)?

Craig Rodriguez told me you were working on this bug.

	I built omniOrb with the latest REDHAT 6 C++ and also with the
latest cygnus snapshots of gdb and latest egcs.

	This should be fairly easy to reproduce if you
just grab the latest version of omniOrb.

       I've been trying to build and run omniORB_280pre2 under gdb on
redhat linux 6.  I downloaded and built egcs and the latest gdb
snapshot from sourceware.cygnus.com.  gdb-4-18.4 core dumps when I
run.  Older versions dont even get to a prompt.  The cygnus snapshot
gives an unknown signal exeception whenever I try to run any of the
apps that come with the omniORB distrib, such as omniNames or nameclt.

These apps run fine from the shell.  When I tried fixing the gdb 4-18
so it wouldn't core dump, it too gave me this error.

To reproduce this, the simplest approach is to just download omniOrb
and
build it as instructions indicate.  Then run any of the omniOrb/bin
apps.
These work fine with gdb on solaris.  This will cause gdb to fail in
some way.

I think this is holding up alot of users of omniOrb on linux.  Can you
please look at this?  You can download omniOrb and try this yourself.

Thank you ,
Mark Weissman
weissman
781 466 2404



This is a corba orb available free from:

http://www.uk.research.att.com/omniORB/

My system is:

uname -va
Linux gogo 2.2.5-15 #1 Mon Apr 19 23:00:46 EDT 1999 i686 unknown

My compiler is:

gcc -v
Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs
gcc version 2.95.1 19990816 (release)


GDB version is snapshot 19990830

gogo:/usr/local/home/mw06/oo/bin/i586_linux_2.0_glibc> gdb nameclt
gdb nameclt
GNU gdb 19990830
Copyright 1998 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 "i686-pc-linux-gnu"...
(gdb) run
Starting program:
/usr/local/home/mw06/omniORB_280pre2/bin/i586_linux_2.0_glibc/nameclt

Program received signal ?, Unknown signal.
0x403741bb in __sigsuspend (set=0xbfffeafc)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
48	../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
(gdb) where
#0  0x403741bb in __sigsuspend (set=0xbfffeafc)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:48
#1  0x402e0462 in __pthread_create_2_1 (thread=0x8059ddc,
attr=0xbfffec34,
    start_routine=0x402d08a0 <omni_thread_wrapper>, arg=0x8059da8)
    at restart.h:32
#2  0x402e0c8f in __pthread_create_2_0 (thread=0x8059ddc,
attr=0xbfffeca4,
    start_routine=0x402d08a0 <omni_thread_wrapper>, arg=0x8059da8)
    at pthread.c:445
#3  0x402d0c84 in omni_thread::start ()
   from
/usr/local/home/mw06/oo/lib/i586_linux_2.0_glibc/libomnithread.so.2
#4  0x402d0dc8 in omni_thread::start_undetached ()
   from
/usr/local/home/mw06/oo/lib/i586_linux_2.0_glibc/libomnithread.so.2
#5  0x4006f272 in StrandScavenger::initOutScavenger ()
   from
/usr/local/home/mw06/oo/lib/i586_linux_2.0_glibc/libomniORB2.so.8
#6  0x40096d63 in omni_scavenger_initialiser::attach ()
   from
/usr/local/home/mw06/oo/lib/i586_linux_2.0_glibc/libomniORB2.so.8
#7  0x4004cda7 in CORBA::ORB_init ()
   from
/usr/local/home/mw06/oo/lib/i586_linux_2.0_glibc/libomniORB2.so.8
#8  0x8049d3d in main ()
#9  0x4036dcb3 in __libc_start_main (main=0x8049d1c <main>, argc=1,
    argv=0xbffff494, init=0x804965c <_init>, fini=0x804e184 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffff48c)
    at ../sysdeps/generic/libc-start.c:78
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Using this executable I was able to reproduce the coredump
with gdb-4.18-4.  When I tried the development version of
GDB (from http://sourceware.cygnus.com/gdb) the core dump
went away.

From: Craig Rodrigues <rodrigc>
To: kingdon
Cc: weissman, rodrigc
Subject: BUG 4835: gdb-4.18-4 crashes on debugging omniorb
Content-Type: text/plain; charset=us-ascii

Jim,

Sorry to not get back to you for a while, but I've been busy at work.

I have the following configuration:
Redhat 5.2
glibc 2.0.7-29
egcs-1.1b2

I obtained gdb-4.18-4.src.rpm from rawhide.redhat.com and compiled it
on my system.

I compiled omniorb 2.8.0 pre-2 on my system, obtained from
http://www.uk.research.att.com/omniORB

I then proceeded to debug nameclt, as described by Mark Weissman in
the notes for 4835 on the bugzilla website.

I managed to core dump gdb 4.18-4 in exactly the same fashion that
Mark Weissman did, even though he is running Redhat 6.0 with glibc
2.1.

I have the full source, and compiled binary versions of omniorb
at: http://dibbler.ne.mediaone.net/omniorb.html

If you grab omniorb.tar.gz from my site, and extract to $SOMEDIR:

export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SOMEDIR/omniORB_280pre2/lib/i586_linux_2.0_glibc
cd $SOMEDIR/omniORB_280pre2/bin/i586_linux_2.0_glibc

nameclt is in this directory, and you can debug it as Mark Weissman
outlined.

If you want to rebuild omniorb,
cd $SOMEDIR/omniORB_280pre2/src
gmake clean
gmake export


If you could assist me with this problem, I would greatly appreciate
it,
as well as many other omniorb developers, who use Redhat Linux as
their
primary development platform!
--
Craig Rodrigues
http://www.gis.net/~craigr
rodrigc

From running GDB under a debugger, the bug is in the C++ demangler.
It can be reproduced with:

maint dem
__thunk_68__0RL__list__Q29CosNaming18_nil_NamingContextUlRPQ29CosNaming11BindingListRPQ29CosNaming15BindingIterator

at the GDB prompt.  The GDB's which ship with Red Hat Linux 6.0 and
6.1 both have the bug.  A development GDB from
http://sourceware.cygnus.com/gdb/ does not.

I'll probably be taking a GDB from sourceware and putting it into
rawhide at some point; haven't done so yet.

Fixed in gdb-4.18-6 in rawhide ("rawhide" directory on your
favorite ftp.redhat.com mirror).