public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: pras@cycloeastern.com
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: GDB problem on RH AS/Clone(). Plz help.
Date: Fri, 15 Apr 2005 19:53:00 -0000	[thread overview]
Message-ID: <20050415202833.GA27787@cycloeastern.com> (raw)
In-Reply-To: <425FFDC5.4010902@redhat.com>

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

  reply	other threads:[~2005-04-15 19:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-13 14:43 pras
2005-04-15 13:35 ` pras
2005-04-15 17:45   ` Jeff Johnston
2005-04-15 19:53     ` pras [this message]
2005-04-21 19:24       ` Jeff Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050415202833.GA27787@cycloeastern.com \
    --to=pras@cycloeastern.com \
    --cc=gdb@sources.redhat.com \
    --cc=jjohnstn@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).