gdb 6.1-debian : problem with restarting program with breakpoints on dynamic libraries#

gdb 6.1-debian : problem with restarting program with breakpoints on dynamic libraries#

[wim delvaux]

When I do this

		gdb SomeProgram

and set a breakpoint on a function that will be loaded at runtime

		b SomeFunctionInSomeLib

gdb properly asks me if I want to set this breakpoint when the symbol is 
found.

Answering "y' and running the program will break on the requested function.

HOWEVER.

When I want to rerun the application ('r' command) the breakpoint is still 
known by gdb (I see complaint messages) but is not set even when the function 
becomes available.

is this a but in the version I am using ?

W

Re: gdb 6.1-debian : problem with restarting program with breakpoints on dynamic libraries#

[Daniel Jacobowitz]

On Thu, Jun 03, 2004 at 12:28:34AM +0200, wim delvaux wrote:
> When I do this
> 
> 		gdb SomeProgram
> 
> and set a breakpoint on a function that will be loaded at runtime
> 
> 		b SomeFunctionInSomeLib
> 
> gdb properly asks me if I want to set this breakpoint when the symbol is 
> found.
> 
> Answering "y' and running the program will break on the requested function.
> 
> HOWEVER.
> 
> When I want to rerun the application ('r' command) the breakpoint is still 
> known by gdb (I see complaint messages) but is not set even when the function 
> becomes available.
> 
> is this a but in the version I am using ?

I can't reproduce this using the same version of GDB.  Can you give us
a complete transcript of a session that shows the problem?

-- 
Daniel Jacobowitz

Re: gdb 6.1-debian : problem with restarting program with breakpoints on dynamic libraries#

[wim delvaux]

As requested a transcript :

---> Mark the setting of the breakpoint to AP_RaiseExc 
---> Mark the FAILURE of settting the breakpoint in the second run

u19809@buro:.../MSPDataImport.par$ gdb AP_QtApp
GNU gdb 6.1-debian
Copyright 2004 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 "i386-linux"...Using host libthread_db library 
"/lib/tls/libthread_db.so.1".

(gdb) b AC_RaiseExc
Function "AC_RaiseExc" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (AC_RaiseExc) pending.
(gdb) r
Starting 
program: /mnt/buro/fs.permanent/home/u19809/projects/AP/APEE_RT/gcc3/bin/AP_QtApp
[Thread debugging using libthread_db enabled]
[New Thread 1086607392 (LWP 17986)]
Breakpoint 2 at 0x407c2656: file 
IntelLinuxGnu.arch/debugthreaded_gcc3/ActivatorErrorHandling_A.c, line 264.
Pending breakpoint "AC_RaiseExc" resolved
[New Thread 1095072688 (LWP 17994)]
1) AP.DevTools.ATFScanner (1.0.0)
2) AP.CSDManipulation.CSDFormEditor (1.0.0)
3) AP.MSP.MSPAdmin (1.0.0)
4) AP.MSP.AuthenticationGui (1.0.0)
5) AP.MSP.MSPImporter (1.0.0)
6) AP.MSP.MSPPackager (1.0.0)
7) AP.DevTools.RepoBrowser (1.0.0)

Program received signal SIG32, Real-time event 32.
[Switching to Thread 1095072688 (LWP 17994)]
0x407d5cb1 in __open_nocancel () from /lib/tls/libpthread.so.0
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting 
program: /mnt/buro/fs.permanent/home/u19809/projects/AP/APEE_RT/gcc3/bin/AP_QtApp
Error in re-setting breakpoint 2:
Function "AC_RaiseExc" not defined.
Error in re-setting breakpoint 2:
Function "AC_RaiseExc" not defined.
Error in re-setting breakpoint 2:
Function "AC_RaiseExc" not defined.
Error in re-setting breakpoint 2:
Function "AC_RaiseExc" not defined.
[Thread debugging using libthread_db enabled]
[New Thread 1086607392 (LWP 18012)]
[New Thread 1095072688 (LWP 18015)]
1) AP.DevTools.ATFScanner (1.0.0)
2) AP.CSDManipulation.CSDFormEditor (1.0.0)
3) AP.MSP.MSPAdmin (1.0.0)
4) AP.MSP.AuthenticationGui (1.0.0)
5) AP.MSP.MSPImporter (1.0.0)
6) AP.MSP.MSPPackager (1.0.0)
7) AP.DevTools.RepoBrowser (1.0.0)

Program received signal SIG32, Real-time event 32.
[Switching to Thread 1095072688 (LWP 18015)]
0x407d5cb1 in __open_nocancel () from /lib/tls/libpthread.so.0
(gdb) q





On Thursday 03 June 2004 05:57, Daniel Jacobowitz wrote:
> On Thu, Jun 03, 2004 at 12:28:34AM +0200, wim delvaux wrote:
> > When I do this
> >
> > 		gdb SomeProgram
> >
> > and set a breakpoint on a function that will be loaded at runtime
> >
> > 		b SomeFunctionInSomeLib
> >
> > gdb properly asks me if I want to set this breakpoint when the symbol is
> > found.
> >
> > Answering "y' and running the program will break on the requested
> > function.
> >
> > HOWEVER.
> >
> > When I want to rerun the application ('r' command) the breakpoint is
> > still known by gdb (I see complaint messages) but is not set even when
> > the function becomes available.
> >
> > is this a but in the version I am using ?
>
> I can't reproduce this using the same version of GDB.  Can you give us
> a complete transcript of a session that shows the problem?

Re: gdb 6.1-debian : problem with restarting program with breakpoints on dynamic libraries#

[Daniel Jacobowitz]

On Thu, Jun 03, 2004 at 01:55:19PM +0200, wim delvaux wrote:
> As requested a transcript :
> 
> ---> Mark the setting of the breakpoint to AP_RaiseExc 
> ---> Mark the FAILURE of settting the breakpoint in the second run

That says that it failed to set the breakpoint several times, not that
it never succeeded.  Try continuing to the point where the breakpoint
would hit and you should find that the breakpoint was placed.  If
that's not the case, please show a transcript and check "info
breakpoints".

The error messages themselves are a long-standing bug.

-- 
Daniel Jacobowitz

Re: gdb 6.1-debian : problem with restarting program with breakpoints on dynamic libraries#

[wim delvaux]

On Thursday 03 June 2004 22:47, Daniel Jacobowitz wrote:
> On Thu, Jun 03, 2004 at 01:55:19PM +0200, wim delvaux wrote:
> > As requested a transcript :
> >
> > ---> Mark the setting of the breakpoint to AP_RaiseExc
> > ---> Mark the FAILURE of settting the breakpoint in the second run
>
> That says that it failed to set the breakpoint several times, not that
> it never succeeded.  Try continuing to the point where the breakpoint
> would hit and you should find that the breakpoint was placed.  If
> that's not the case, please show a transcript and check "info
> breakpoints".
>
> The error messages themselves are a long-standing bug.

ok that seems to work for my test app.  Will see what it gives with other 
apps.