From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8106 invoked by alias); 15 Apr 2005 19:53:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8070 invoked from network); 15 Apr 2005 19:53:16 -0000 Received: from unknown (HELO cycloeastern.com) (68.184.90.205) by sourceware.org with SMTP; 15 Apr 2005 19:53:16 -0000 Received: (from pras@localhost) by cycloeastern.com (8.11.6/8.11.6) id j3FKSYC27977; Fri, 15 Apr 2005 16:28:34 -0400 Date: Fri, 15 Apr 2005 19:53:00 -0000 From: pras@cycloeastern.com To: Jeff Johnston Cc: gdb@sources.redhat.com Subject: Re: GDB problem on RH AS/Clone(). Plz help. Message-ID: <20050415202833.GA27787@cycloeastern.com> References: <20050413151816.GA13759@cycloeastern.com> <20050415141108.GA26214@cycloeastern.com> <425FFDC5.4010902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425FFDC5.4010902@redhat.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-04/txt/msg00104.txt.bz2 Jeff, Thanks for the pointers. I complied gdb 6.3 from the source tar ball. I had similar results. So I dont think it has anything to do with redhat specific patches. The debugged program is a console based application which reguires specific key sequence to exit. This works just fine when not debugged. Its worked on many other Unix variants for a long time. Just attaching gdb to the process id and issuing a cont causes the program to just exit. So its NOT a normal exit scenario. Anyways I followed all you suggestions and this is what I find.. I added break points to pthread_exit, exit and _exit (gdb) cont Continuing. [New Thread -1245619280 (LWP 32201)] [Thread -1220740176 (LWP 13698) exited] [Switching to Thread -1245619280 (LWP 32201)] Breakpoint 3, 0x06664ba0 in _exit () from /lib/tls/libc.so.6 (gdb) where #0 0x06664ba0 in _exit () from /lib/tls/libc.so.6 #1 0x014a362e in VISThreadShutdown::begin () from /usr/BDP/lib/liborb_r.so #2 0x00226749 in VISThread::_start () from /usr/BDP/lib/libvport_r.so #3 0x001fcdec in start_thread () from /lib/tls/libpthread.so.0 #4 0x06697a2a in clone () from /lib/tls/libc.so.6 What I find really interesting here is the call from start_thread to VISThread::_start() which to me appears to be a Visibroker dynamic library. I wonder if pthread is getting confused and calling the wrong function. However this does not happen when its not debugged. -Prasanna On Fri, Apr 15, 2005 at 01:45:41PM -0400, Jeff Johnston wrote: > Prasanna, > > You should submit a Bugzilla bug to Red Hat. Red Hat's gdb is a modified > version of the sources here so you are asking too much of the FSF gdb > maintainers. You should start by trying a later version of Red Hat gdb > which has many more fixes. Currently, there is a gdb 6.3-based version out > there which you can download via RHN. > > You also have not provided enough information for anyone to be helpful. > For example, what have you done to prove that your program is not actually > running to completion for a valid reason (e.g. an exit condition is being > met with your server)? Breaking on clone() isn't very helpful. Without > knowing much about your application, I suggest breaking inside your thread, > outside any server loop, and at exit points to try and see why the program > is running to completion (for example, breaking on exit, _exit, > pthread_exit, after a join operation, has some form of error occurred..). > > -- Jeff J. > > pras@cycloeastern.com wrote: > >Bump ... > > > >Can somebody please guide me with this clone() issue in gdb or am I on the > >wrong mailing list? > > > > > >On Wed, Apr 13, 2005 at 11:18:16AM -0400, pras@cycloeastern.com wrote: > > > >>All, > >> > >>This is my first email to this list. > >> > >>I work for a company in that has started using Linux for one of its > >>projects > >>that has traditionally in the past been running on all other big iron > >>*nixes. > >> > >>We just got our first build on RH Enterprise Linux AS release 3 (Taroon > >>Update 4), > >>and gdb attempts fail miserably. > >> > >>Background info: > >> > >>The product is written in C/C++ and is compiled with gcc 3.2.3 > >>The gdb version is as follows: > >>GNU gdb Red Hat Linux (6.1post-1.20040607.52rh) > >> > >>I am able to attach to a process and see the stack using backtrace or bt. > >>frame command > >>works and even break command works. > >> > >> > >>When I try to do a 'cont', the server process which is supposed to > >>execute continuously exists normally. > >> > >>This is what I see > >> > >>(gdb) cont > >>Continuing. > >>[New Thread -1245635664 (LWP 8226)] > >>[Thread -1220756560 (LWP 7953) exited] > >> > >>Program exited normally. > >>(gdb) > >> > >>The program is multithreaded and it fails. People at my local LUG > >>suggested that I try to look up problems with > >>clone() system call and GDB. They suggested using PTHREADS could solve > >>the problem. We DO use pthreads and here > >>is the stack(i.e. backtrace). I have set a break point on clone(). > >>Shortly after the program just exits. > >> > >>#0 0x0365e9d0 in clone () from /lib/tls/libc.so.6 > >>#1 0x0040a8d7 in do_clone () from /lib/tls/libpthread.so.0 > >>#2 0x0040a526 in create_thread () from /lib/tls/libpthread.so.0 > >>#3 0x00409f87 in pthread_create@@GLIBC_2.1 () from > >>/lib/tls/libpthread.so.0 > >>#4 0x0040a01c in pthread_create@GLIBC_2.0 () from > >>/lib/tls/libpthread.so.0 > >>#5 0x004a9f3a in VISThread::_create_thread () from > >>/usr/BDP/lib/libvport_r.so > >>#6 0x004aa0bc in VISThread::run () from /usr/BDP/lib/libvport_r.so > >>#7 0x0142a588 in VISManager::cleanup () from /usr/BDP/lib/liborb_r.so > >>#8 0x0142b063 in VISManager::sig_handler () from /usr/BDP/lib/liborb_r.so > >>#9 0x0142b4a1 in VISThreadSignal::begin () from /usr/BDP/lib/liborb_r.so > >>#10 0x004a8749 in VISThread::_start () from /usr/BDP/lib/libvport_r.so > >>#11 0x00409dec in start_thread () from /lib/tls/libpthread.so.0 > >>#12 0x0365ea2a in clone () from /lib/tls/libc.so.6 > >> > >> > >>I downloaded 6.3 gdb and compiled it with no options. GDB failed again > >>under that. Please let me know what can be done. > >> > >>Do you guys know what might be going wrong ? > >> > >>-- > >>________________________________________________________________________ > >>Prasanna Subash | WARNING TO ALL PERSONNEL: Firings will > >>pras@cycloeastern.com | continue until morale improves. > >> | > >> | > >>________________________________________________________________________ > > > > -- ________________________________________________________________________ Prasanna Subash | A gourmet who thinks of calories is like a pras@cycloeastern.com | tart that looks at her watch. -- James | Beard | ________________________________________________________________________