Re: GDB problem on RH AS/Clone(). Plz help.

[Jeff Johnston <jjohnstn@redhat.com>]

pras@cycloeastern.com wrote:
> 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.
>

So the process is indeed exiting on its own accord.  My next suggestion would be 
to try and find the debuginfo for the shared libraries in question, if 
available.  See if you can track the point where the application determined to 
do the _exit call.  I notice that you have a thread exit event above.  Before 
continuing, do a thread apply all bt to see what every thread is doing.  Perhaps 
the other thread's exiting is the event causing the application to quit.  If so, 
find out why the thread is exiting, etc...  For example, perhaps an operation 
timer exhausts while gdb has the application stopped.  I'm not yet convinced gdb 
is doing anything wrong.

-- Jeff J.

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