Problems with gdb integration on linux

[mrothman]

I've always had problems with the gdb integration - so severe that I've never used it for long.  In a nutshell, it's painfully slow - that is, any operation (such as setting a breakpoint) seems to take up to a full minute. This includes things like simply stepping through my code.  I've tried adjusting the response times in the Settings tab, but the only success I've had with that is in speeding up the response when there's a complete failure to communicate with gdb.

Also, there seem to be disagreements between SlickEdit and gdb about how to do certain things.  For example, if I click for a breakpoint on a certain line, SlickEdit reports back that gdb says there is no such line number (again, after about 30 seconds of waiting).  I notice however that what SlickEdit asked for includes the directory just above the file.  When I do the same thing directly in gdb, I don't use the directory (and indeed, if I do, it fails just the way that SlickEdit reports).  For example, if I want a breakpoint on line 322 of foo.cpp, SlickEdit apparently asks gdb for line 322 of file bar/foo.cpp.  Is there some way I can tell it to dispense with the directory?  I'm a fairly accomplished slick-c macro programmer, so if necessary I could make some adjustments in the appropriate .e files.

I'm sure that zillions of folks use this integration successfully, so it must be something about my configuration.  I can attach to the running app quite quickly, but that's it.  I do have the debug options set to use a local version of gdb (6.3 for 64 bit suse linus), since the one shipped with SlickEdit (6.4 configured as "i686-pc-linux-gnu") doesn't recognize the file format of our app.

[rwehrli]

You don't mention what version of SE you're using...however, I've seen the same problem as what you're seeing, but using a different flavor of Linux (RHEL WS4) and it occurred after upgrading from V10.0.3 to V11.0.0.

What you probably want to do is download the latest version of GDB (6.5?) from the FSF and configure/build it.  Once it is built, you can copy the binaries into the /opt/slickedit/bin directory (or wherever you installed SE) and go back to using the "default" GDB configuration.  (I'd also recommend executing "make install" so that all of the relevant files are properly located in your usr space.)

Also, ensure that you completely rebuild your entire project after clearing all of the breakpoints and, once built, reset the breakpoints and try again.

I don't know for sure whether doing this will truly help you, but it worked for me.  While this was an "ongoing issue," I reverted back to v10 because I couldn't wait a hundred years to debug and I had gotten plenty used to using the SE front end to GDB.

Another thing to try is to archive your ~/.slickedit directory and blow it away and restart SE such that it builds a new one.  Then see if debugging is still painfully slow...of course, this assumes that you've copied the "good" version of GDB into the SE bin dir.


Take Care.

Rob!

[mrothman]

Rob - thanks for your detailed answer.  I will try what you suggest.

There was one issue I had which I doubt would be addressed by this however - the fact that SlickEdit seems to try to set line number breakpoints by telling gdb to use the last directory on the path AND the file name, rather than just the file name.  Has anyone seen any problem like that?  Is this perhaps a gdb configuration issue rather than SlickEdit?

[Dennis]

It is necessary to pass the path and not just the file name to GDB because there may be another file in the project with the same file name and a different path.

Due to a variety of weaknesses and inconsistencies in GDB's handling of paths (especially through the MI interface), we have been forced to jump though many hoops to create an effecient and compatible way to set breakpoints.

With respect to your performance issue, as Rob pointed out, it would be really helpful to know what version of SlickEdit you are using, and what sort of an application you are debugging.  Is it remote or local?  How large is the application?  How deep is the stack?  Have you tried closing the variable and watch windows so SlickEdit doesn't have to fetch as much data from GDB?  When you are waiting on GDB, what is consuming CPU cycles?  GDB or SlickEdit?

[mrothman]

Thanks for your ideas Dennis.  Some answers:

1) I'm using SlickEdit v 11.0.1 currently, but I've seen essentially this same set of problems at least back through v. 9.  Maybe further - I've been using SlickEdit for at least a decade, so some of my experiences are lost in the mists of time 
2) The application is local.  I always attach the debugger to it once it is running (Attach to running process using GDB).
3) Typically, the stack on the main thread is a dozen or less levels deep.
4) The application is large, not sure what you're interested in.  Typically at rest (waiting for input), on an amd64bit machine, it has a virtual size of 1.6 gig or so, but the vast majority of that is data, not code segment.

As I noted in my first post, the version of gdb that ships with SlickEdit complains about our file format (presumably because I'm working on an amd64 machine), so I use the one we have in-house, which is 6.3 for 64 bit suse linux.

Your remark about using path and filename makes sense, but this is what gdb seems to be objecting to. Note that SlickEdit seems to be giving only the last part of the path (e.g. bar/foo.c), rather than the entire path. As I mentioned, if I run gdb directly at the xterm command line and try to set a breakpoint using a partial path and filename, it gives me the same error message that SlickEdit eventually returns to me.  So it seems that, at least for this version of gdb, a partial path and filename isn't accepted (perhaps there's some setting in gdb that I can change?  I looked through as much of the help as seemed relevant, but didn't find anything).

This is a problem if I try to set a breakpoint in the margin of the source.  But I can set breakpoints by clicking on the add breakpoint icon in the breakpoints window IF I choose the first line of a function (it seems it's setting the breakpoint by function name rather than by line number in that case).

In all cases, the response when setting a breakpoint is usually (but not always) extremely slow.  Oddly enough, "top" doesn't show the time being taken either by SlickEdit or by gdb.  In fact, they are using 0.0 %CPU.  It's almost as if they are blocked on something else.  The main user of CPU time continues (as always) to be the command shell - in fact, as long as I don't do anything else, it and top are essentially the only CPU users.

If SlickEdit is communicating with gdb through the MI interface, I note that at least in the latest documentation, breakpoint-insert commands seem to take only the filename (and return to you the full path, which I supposed can be used as a check).  It certainly isn't clear what gdb does if there are two files with the same name.

[Dennis]

Yes, I can confirm that SlickEdit does use the GDB/MI interface.

The path that GDB/MI expects seems a little convoluted, but it is actually related to the source file path that gets stuffed into the object file when you compile.  So if you build does something like "gcc -c -o foo.o bar/foo.c", then exepct bar/foo.c.  This is, of course, not consistent on all platforms.  What we have found is that setting the breakpoint works if you give GDB just the filename, unless there are two files with that same filename, in which case, it *appears* to work, except you don't know if it set the breakpoint in the right file.  It is helpful that more recent versions of GDB (6.4) return the full path when setting a breakpoint, so, yes, we could use that as a test.  But for older versions of GDB, and for the failure case, we are back to having to find the canonical partial path for that source file.

It is impossible to debug a problem I can't reproduce; so if you could wrap up as much stuff as possible and send it into support@slickedit.com, maybe we could look into it.  Here's what we need:

   1) A copy of your GDB executable, since you are not using the standard one.
   2) An executable to debug that reproduces the problem.
   3) A debugger log.  To create this, go to Macro > Set Macro Variable... and set
       "def_debug_logging" to 1.  The log is appended to vs.log in your
       configuration directory.
   4) The source file you are trying to set the breakpoint in (also need to
       full path so that I can reproduce exactly what you are seeing).
   5) The line number you are trying to set a breakpoint at.
   6) Instructions on what to do with your executable to make it hit the breakpoint.

If you can't provide (2) and (4)-(6), then the debugger log alone would be useful, because we could at least see what GDB command is taking a long time to process.  That would narrow the problem at least.