C::B debug (gdb) with breakpoints pending is VERY SLOW ...

[kccheng]

Hi,

I want to debug a DLL which will be loaded by my host application (myApp).
If I set breakpoints first (pending breakpoints), then click
on Debug->Start ... myApp (multi-threads, gtk2 app) will take about 1min. to start.
But without breakpoints, it only takes couple sec to start.

I try to use text mode gdb directly, with breakpoints pending on, it will slow
down a little bit but only couple sec delay which is similar to C::B without breakpoints.

So my simple guess ... it's C::B debug plugin's problem.
I also tested debugger branch nightly build ... the same, it's very slow.
If I set more breakpoints, it will get slower !!!

Anyone know what's wrong.

Thanks a lot
KC

[oBFusCATed]

Hm, sound like a gdb bug.
Can you post the full debugger's debug log (you need to enable it in the debugger's settings)?
Can you try to execute the same commands in a cmd gdb session?

[kccheng]

Hm, sound like a gdb bug.
Can you post the full debugger's debug log (you need to enable it in the debugger's settings)?
Can you try to execute the same commands in a cmd gdb session?

Attachment is the debug log I recorded.
I guess it's C::B's problem because using gdb 6.8 (mingw version) directly to
run the host application does not slow down much (only ~5 sec which is acceptable).

But in C::B ... the host application will take sometime 1 min. to start.

I'm trying to ask my customer to accept C::B as development platform ... this
performance issue is quite critical for me.
Any suggestion will be appreciated.


Regards,
KC

[ouch]

I don't get any unusual delays when setting breakpoints in the plain codeblocks trunk.

I imagine the new debugger is a plugin like everything else, you can probably just have your customer disable it till it gets improved a bit and use the old one for now.

[oBFusCATed]

Attachment is the debug log I recorded.
I guess it's C::B's problem because using gdb 6.8 (mingw version) directly to
run the host application does not slow down much (only ~5 sec which is acceptable).

You're saying that if you execute the same commands in a console gdb session, you'll have no delay?
Have you tried newer gdb?

p.s. we're talking about windows, aren't we?

[kccheng]

Attachment is the debug log I recorded.
I guess it's C::B's problem because using gdb 6.8 (mingw version) directly to
run the host application does not slow down much (only ~5 sec which is acceptable).

You're saying that if you execute the same commands in a console gdb session, you'll have no delay?

YES.  In fact, I found some similar discussion via Google
http://cygwin.com/ml/cygwin/2008-12/msg00162.html
http://sourceware.org/ml/gdb/2010-07/msg00080.html

But none have solution.  Some claim it's gdb's bug too ... but base on
what I got, I will just say maybe.

Have you tried newer gdb?

Not yet ... I'm using gdb 6.8 from www.mingw.org.  Will try 7.2 later ...

p.s. we're talking about windows, aren't we?

Yes we are talking about windows (WinXP, SP3).  I try C::B+gdb under
SuSE enterprise 11.0 ... there are no such performance issue.


Regards,
KC

[oBFusCATed]

Can you try to find the command that slows it down? (start removing them one by one)

[kccheng]

Can you try to find the command that slows it down? (start removing them one by one)

I'm trying ... however, it's not easy since the host application is a VERY BIG project !!
BTW, I tested gdb 7.2 (from mingw.org) ... it's worse :-(
But this time it looks like the problem comes from gdb itself, because gdb 7.x slow down
all Gtk2 application on WinXP !!!

KC

[ollydbg]

If I set breakpoints first (pending breakpoints), then click
on Debug->Start ... myApp (multi-threads, gtk2 app) will take about 1min. to start.
But without breakpoints, it only takes couple sec to start.

This is 100% true when I try to debug c::b in c::b.
But I think this is by design of gdb .
I have meet this kind of problem several months ago, and we have several solutions(work around) in our forum, you can search them.

PS:
This post http://sourceware.org/ml/gdb/2010-07/msg00080.html was written by me.

[kccheng]

This post http://sourceware.org/ml/gdb/2010-07/msg00080.html was written by me.

Hi

After check the post you mentioned and couple discussion I found by Google search,
I think the following step probably is the only solution to avoid the SLOW DOWN
issue at this moment:

1) start the host application without breakpoints
1.a) for Gtk2 (and probably all GUI apps with event loop), break the app from C::B
       (send SIGTRAP to app) make sure C::B get the control back.
2) set breakpoints from C::B
3) continue

This is acceptable, but it raises another issue.

What if I have multiple breakpoints which need to be set at one time ?
The solution I got at this moment is send command "source gdb.script"
directly from C::B to gdb.   However, C::B does not show
the breakpoints defined inside gdb.script :-(
My question is:
Is there any way to update C::B GUI so it can show all breakpoints
defined in gdb command file or initial file (gdbinit) ?

Another related question ... if I use C::B GUI to define breakpoints
by click on program's source file, how can I export the breakpoints
to external file ?  Is this possible ?


Regards,
KC

[MortenMacFly]

Another related question ... if I use C::B GUI to define breakpoints
by click on program's source file, how can I export the breakpoints
to external file ?  Is this possible ?

Right-click in the watches windows and select the appropriate option.

[ollydbg]

My question is:
Is there any way to update C::B GUI so it can show all breakpoints
defined in gdb command file or initial file (gdbinit) ?

From my point of view, I think this is not implemented, which means: C::B GUI only maintain breakpoints the user sets from the GUI, if you set extra breakpoint from the debugger plugin's command line, then C::B GUI does not recognize them. Hope this can be improved.

Another related question ... if I use C::B GUI to define breakpoints
by click on program's source file, how can I export the breakpoints
to external file ?  Is this possible ?

I have a patch to do this, it will save all the breakpoints to an external file.
Look at:
Watches and breakpoints persistent
The only issue is: it is best to save all the breakpoints in the cbp file, not an external file, So the C::B developers were not apply this patch.

[kccheng]

From my point of view, I think this is not implemented, which means: C::B GUI only maintain breakpoints the user sets from the GUI, if you set extra breakpoint from the debugger plugin's command line, then C::B GUI does not recognize them. Hope this can be improved.

me too

I have a patch to do this, it will save all the breakpoints to an external file.
Look at:
Watches and breakpoints persistent

The only issue is: it is best to save all the breakpoints in the cbp file, not an external file, So the C::B developers were not apply this patch.

Maybe we don't need to save all the breakpoints to an external file ?
Save them in cbp might be good enough if we have a button called "Update" or "Sync"
which will do:

1) query gdb for current breakpoints
2) check if it's in cbp file
3) if not in cbp, the C::B will remove that breakpoints and redefine it from C::B
    so the GUI will be updated.

Make the "Update" or "Sync" button be used only manually, instead of try to
sync C::B GUI and gdb automatically ... this way, it will not affect performance.
(only at project open time, should has a checkbox for user to select
 Update/Sync while project opened)

I think this is a good feature to add, at least, it's important to work around
slow pending breakpoints issue.  Anyone with me ?

Regards,
KC

[ollydbg]

Well, I'm not fully understand your idea.
Here we discuss two things:
1, you want to save breakpoints to an external file or cbp file, this way you can do breakpoints persistence, the bps will automatically loaded or added when you load a project.
2, you want to set breakpoints in a batch mode(especially you have debugee already started), this way, you stop the debugee, and run a gdb script command or other command, then gdb try to set several bps, meanwhile, the C::B GUI dialog should always updated.

Maybe, you can enhance the debugger plugin to set some "dummy breakpoints", and enabled them by context menu?

[kccheng]

Well, I'm not fully understand your idea.
Here we discuss two things:
1, you want to save breakpoints to an external file or cbp file, this way you can do breakpoints persistence, the bps will automatically loaded or added when you load a project.
2, you want to set breakpoints in a batch mode(especially you have debugee already started), this way, you stop the debugee, and run a gdb script command or other command, then gdb try to set several bps, meanwhile, the C::B GUI dialog should always updated.

Thanks to ask my questions by using better English :-)

Yes, both 1 and 2 are what I wanted.  And I think 1) and 2) could be merged
if we provide one checkbox (or control flag) to
allow user to select whether he want to load persistence breakpoints
when project been loading.

Maybe, you can enhance the debugger plugin to set some "dummy breakpoints", and enabled them by context menu?

I love to try ... but I don't know how to impl. C::B plugin yet :-(  I'm new to C::B even
be a user.   And I'm not good C++ programmer, but I'm quite good on C :-)
So, that will take a long time  ...

Regards
KC