Red Hat Bugzilla – Bug 110535
gdb reports setting breakpoints, but breakpoints are never hit
Last modified: 2007-11-30 17:10:33 EST
Description of problem:
If you set a breakpoint in Mozilla with gdb, sometimes the breakpoints
don't stop the program, even though I know the code where the
breakpoint is set is being executed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fire up gdb and Mozilla
2. Set a breakpoint in nsPluginInstanceOwner::nsPluginInstanceOwner
3. Load a page that includes a plugin.
Breakpoint does not cause stop.
Stops during building of the plugin frame.
This is somewhat flaky. I can sometimes get random breakpoints in
this code to work, but not often. For example, putting a breakpoint
in nsPluginInstanceOwner::AddRef seems to work.
Another strange thing is that when you try to set the breakpoint it
asks you which version of the function you want to break in. However,
that function only has one signature, which is a little odd.
Please supply a precise scenario for reproducing. i.e. start the
binary how, click and type exactly what.
0x004eac32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) b nsPluginInstancePeerImpl::nsPluginInstancePeerImpl
 nsPluginInstancePeerImpl at
 nsPluginInstancePeerImpl at
Breakpoint 1 at 0x60b0caf: file
Note: breakpoint 1 also set at pc 0x60b0caf.
Breakpoint 2 at 0x60b0caf: file
warning: Multiple breakpoints were set.
warning: Use the "delete" command to delete unwanted breakpoints.
button was 0
For application/x-bong-noises found plugin
LoadPlugin() /home/blizzard/src/gtk2plug/libgtk2plug.so returned a137ec0
That *** nsPluginInstancePeerImpl is the code where the break is
supposed to happen being executed.
Created attachment 102219 [details]
Sounds like gdb/1091 & gdb/1193, not being able to properly set
breakpoints in constructors. The not-in-charge/in-charge duality.
make gdbtestc++ in the previous attachment reproduces for me
Fedora Core 1 is maintained by the Fedora Legacy project for security updates
only. If this problem is a security issue, please reopen and reassign to the
Fedora Legacy product. If it is not a security issue and hasn't been resolved in
the current FC5 updates or in the FC6 test release, reopen and change the
version to match.
NOTE: Fedora Core 1 is reaching the final end of support even by the Legacy
project. After Fedora Core 6 Test 2 is released (currently scheduled for July
26th), there will be no more security updates for FC1. Please use these next two
weeks to upgrade any remaining FC1 systems to a current release.
Note that FC1 and FC2 are no longer supported even by Fedora Legacy. Please
install a still supported version and retest. If this still occurs on FC3 or
FC4 and is a security issue, please reopen and assign to that version and Fedora
Legacy. If it still occurs on FC5 or FC6, please reopen and assign to the