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
|
________________________________________________________________________
next prev parent 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).