RE: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow

Elena Zannoni
2002-11-07T21:54:01Z

Ah, I think this is a known problem:
there is gdb PR 521 that has a patch in it.
http://sources.redhat.com/cgi-bin/gnatsweb.pl

the patch doesn't apply to the current sources anymore, maybe you want
to try downloading the current CVS gdb and see if the problem is gone.

Elena

Mark Crosland writes:

>
> The symptoms I am experiencing are long before the program is run,
> dlopen() has not been called yet my my program.
>
> gdb program
> break main (it don't come back, at least not after 15 minutes)
>
> Below is a stack trace. I generated the stack trace by doing the following
> steps
>
> started gdb "gdb myProgram"
>
> gdb prompt comes back right away and I enter "break main"
>
> after 15 minutes it still has not come back from "break main", CPU is
> peaked by GDB
>
> kill -7 the GDB process to get a GDB core
>
> gdb'ed GDB "gdb gdb core"
>
> "where" to get the backtrace
>
> # ~/gdb/gdb ~/gdb/gdb core
> GNU gdb 5.2.1
> Copyright 2002 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 "sparc-sun-solaris2.8"...
> Core was generated by `/homedir/markc/gdb/gdb
> /vob/reactor/dist/bin32/test32'.
> Program terminated with signal 7, Emulation trap.
> Reading symbols from /usr/lib/libcurses.so.1...done.
> Loaded symbols for /usr/lib/libcurses.so.1
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Loaded symbols for /usr/lib/libsocket.so.1
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Loaded symbols for /usr/lib/libnsl.so.1
> Reading symbols from /usr/lib/libdl.so.1...done.
> Loaded symbols for /usr/lib/libdl.so.1
> Reading symbols from /usr/lib/libm.so.1...done.
> Loaded symbols for /usr/lib/libm.so.1
> Reading symbols from /usr/lib/libc.so.1...done.
> Loaded symbols for /usr/lib/libc.so.1
> Reading symbols from /usr/lib/libmp.so.2...done.
> Loaded symbols for /usr/lib/libmp.so.2
> Reading symbols from
> /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1...
> done.
> Loaded symbols for /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
> Reading symbols from /usr/lib/libthread_db.so.1...done.
> Loaded symbols for /usr/lib/libthread_db.so.1
> Reading symbols from
> /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...
> done.
> Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2
> #0 0xff1e0708 in exit ()
> from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
> (gdb) where
> #0 0xff1e0708 in exit ()
> from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1
> #1 0x00075fe0 in finish_cv_type (type=0xb75de0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/gdbtypes.c:510
> #2 0x000fda40 in read_struct_type (pp=0xffbedba0, type=0xb75de0,
> objfile=0x2d67f0) at /homedir/markc/gdb/gdb-5.2.1/gdb/stabsread.c:4211
> #3 0x000fb74c in read_type (pp=0xffbedba0, objfile=0x2d67f0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/stabsread.c:2814
> #4 0x000f97f4 in define_symbol (valu=0,
> string=0x1 <Address 0x1 out of bounds>, desc=0, type=128,
> objfile=0x2d67f0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/stabsread.c:2004
> #5 0x000e4c9c in process_one_symbol (type=128, desc=0, valu=0,
> name=0x459f15 "map<std::basic_string<char, std::char_traits<char>,
> std::allocator<char>
> >,systemCore::logFacility*(*)(systemCore::logFacilityArgs*),std::less<std::basic_string<char,
> std::char_traits<char>, std::allo"...,
> section_offsets=0x2a1ff8, objfile=0x2d67f0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:3208
> #6 0x000e48e8 in read_ofile_symtab (pst=0xa34878)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:2602
> #7 0x000e443c in dbx_psymtab_to_symtab_1 (pst=0xa34878)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:2430
> #8 0x000e4534 in dbx_psymtab_to_symtab (pst=0xa34878)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/dbxread.c:2471
> #9 0x000562e0 in psymtab_to_symtab (pst=0xa34878)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/symfile.c:374
> #10 0x00051d90 in find_pc_sect_symtab (pc=124320, section=0x2b6ec8)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/symtab.c:1490
> #11 0x00050aa4 in lookup_symbol_aux (name=0xffbee000 "main", block=0x0,
> namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0xffbee014)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/symtab.c:741
> #12 0x0005084c in lookup_symbol (name=0xffbee000 "main", block=0x0,
> namespace=VAR_NAMESPACE, is_a_field_of_this=0x0, symtab=0xffbee014)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/symtab.c:603
> #13 0x0005d2e8 in decode_line_1 (argptr=0xffbee1c4, funfirstline=1,
> default_symtab=0x0, default_line=0, canonical=0xffbee15c)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/linespec.c:1188
> #14 0x000c0eb8 in parse_breakpoint_sals (address=0xffbee1c4,
> sals=0xffbee168,
> addr_string=0xffbee15c)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/breakpoint.c:4477
> #15 0x000c0f5c in break_command_1 (arg=0x24827a "", flag=0, from_tty=1)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/breakpoint.c:4561
> #16 0x0011cb00 in do_cfunc (c=0x24df78, args=0x248276 "main", from_tty=0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/cli/cli-decode.c:50
> #17 0x000b0748 in execute_command (p=0x248279 "n", from_tty=1)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:715
> #18 0x0006cddc in command_handler (command=0x248270 "break main")
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:504
> #19 0x0006d30c in command_line_handler (rl=0x258d00 "break main")
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:802
> #20 0x0019467c in rl_callback_read_char ()
> at /homedir/markc/gdb/gdb-5.2.1/readline/callback.c:114
> #21 0x0006c610 in rl_callback_read_char_wrapper (client_data=0x0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:168
> #22 0x0006ccc0 in stdin_event_handler (error=443908, client_data=0x0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-top.c:418
> #23 0x000c80b4 in handle_file_event (event_file_desc=1)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:714
> #24 0x000c7a14 in process_event ()
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:335
> #25 0x000c7a6c in gdb_do_one_event (data=0x1)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:372
> #26 0x000b0354 in do_catch_errors (uiout=0x268740, data=0xffbee7a8)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491
> #27 0x000b026c in catcher (func=0xb0344 <do_catch_errors>,
> func_uiout=0x268740, func_args=0xffbee7a8, func_val=0xffbee7a4,
> func_caught=0xffbee7a0, errstring=0x1dc738 "", mask=6)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:423
> #28 0x000b038c in catch_errors (func=0xc7a30 <gdb_do_one_event>,
> func_args=0x0, errstring=0x1dc738 "", mask=6)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:503
> #29 0x000c7a9c in start_event_loop ()
> at /homedir/markc/gdb/gdb-5.2.1/gdb/event-loop.c:396
> #30 0x00038b38 in captured_command_loop (data=0x0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/main.c:94
> #31 0x000b0354 in do_catch_errors (uiout=0x268740, data=0xffbeea58)
> ---Type <return> to continue, or q <return> to quit---
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491
> #32 0x000b026c in catcher (func=0xb0344 <do_catch_errors>,
> func_uiout=0x268740, func_args=0xffbeea58, func_val=0xffbeea54,
> func_caught=0xffbeea50, errstring=0x1b0160 "", mask=6)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:423
> #33 0x000b038c in catch_errors (func=0x38b10 <captured_command_loop>,
> func_args=0x0, errstring=0x1b0160 "", mask=6)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:503
> #34 0x00039480 in captured_main (data=0xffbefa14)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/main.c:723
> #35 0x000b0354 in do_catch_errors (uiout=0x22c258, data=0xffbeede0)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:491
> #36 0x000b026c in catcher (func=0xb0344 <do_catch_errors>,
> func_uiout=0x22c258, func_args=0xffbeede0, func_val=0xffbeeddc,
> func_caught=0xffbeedd8, errstring=0x1b0160 "", mask=6)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:423
> #37 0x000b038c in catch_errors (func=0x38b74 <captured_main>,
> func_args=0xffbeee58, errstring=0x1b0160 "", mask=6)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/top.c:503
> #38 0x000397b4 in main (argc=2, argv=0xffbeeed4)
> at /homedir/markc/gdb/gdb-5.2.1/gdb/main.c:734
> (gdb)
>
>
> On Thu, 7 Nov 2002, Elena Zannoni wrote:
>
> > Garriss, Michael writes:
> > > I second that.
> > >
> > > -----Original Message-----
> > > From: Mark Crosland [mailto:mjc@attbi.com]
> > > Sent: Thursday, November 07, 2002 11:36 AM
> > > To: gdb@sources.redhat.com
> > > Subject: Re: gcc 3.2, gdb 5.2.1, solaris2.8 sparc, slow
> > >
> > >
> > >
> > > OK, I will assume that no response means gdb is not suitable for medium ->
> > > large multi-threaded c++ development on solaris.
> > >
> > > Thanks,
> > > Mark
> >
> >
> > Actually no. gdb should be able to debug such applications. Would
> > you have a chance to poke around gdb and see what it's doing that
> > takes so long?
> > It may be the same thing reported in this thread:
> > http://sources.redhat.com/ml/gdb/2001-10/msg00157.html
> >
> > Maybe the thread maintainers have some additional comments.
> >
> > Elena
> >
> > >
> > > On Wed, 6 Nov 2002, Mark Crosland wrote:
> > >
> > > >
> > > > I noticed a recent thread regarding rather slow response from gdb. I am
> > > > experiencing the same thing on solaris 2.8, sparc platform. It is an
> > > > enterpirse class server, not the fastest thing sun makes, but not slow.
> > > >
> > > > I built gcc 3.2
> > > > ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
> > > > --disable-nls --prefix=/homedir/markc/gcc --enable-languages=c,c++
> > > > --enable-shared --enable-threads
> > > >
> > > > and then built gdb 5.2.1
> > > > mkdir build
> > > > cd build
> > > > /full/path/to/configure
> > > > make
> > > >
> > > > using gnu make 3.77
> > > >
> > > > solaris 2.8 sparc
> > > >
> > > > gdb responds with the most simple programs, but anything that isn't dirt
> > > > simple seems to cause it to take forever to do basic commands.
> > > >
> > > > I do "gdb myProgram", it starts right up, get the gdb prompt.
> > > >
> > > > "info address main" never returns
> > > > "break main" never returns
> > > >
> > > > CPU is peaked by gdb process
> > > >
> > > > If I say "run", it eventualy runs
> > > >
> > > > the program that is being run in gdb runs fine outside the debugger, isn't
> > > > really all that large, runs on several platforms, etc... it does load some
> > > > relatively average sized shared libraries (both from the OS and using
> > > > dlopen()). The program is multi-threaded.
> > > >
> > > > It is a c++ and c program
> > > >
> > > > The modules that contain main are compiled with -g. nm from binutils shows
> > > > lots of symbols.
> > > >
> > > > trying to get away from Sun compiler, but a debugger is a critical
> > > > piece...
> > > >
> > > > ???
> > > >
> > > > Mark,
> > > >
> >