problem remote debugging

Brendan Miller
Tue Feb 24 17:01:00 GMT 2009

On Mon, Feb 23, 2009 at 6:32 PM, Daniel Jacobowitz <> wrote:
> On Mon, Feb 23, 2009 at 04:59:48PM -0800, Brendan Miller wrote:
>> I'm having a problem with remote debugging where when debugging
>> locally I will launch fine, but when remotely debugging my program
>> will fail to open a certain text file, then segfault.
>> Both the host and client are running x86 RHEL4. The gdb version is
> A frequent cause of this problem is different patch levels of
> libraries installed on the two systems.  If they don't exactly match,
> you need a copy on the host of the target's libraries, and to use set
> sysroot.  Otherwise GDB may place internal breakpoints in the wrong
> locations, leading to mayhem.

I'm not sure if that makes sense. What happened was a file failed to
be read, which to me implies different behavior given the same
binaries executed on the same machine, depending on if in local or
remote debugging mode. This was followed by a segfault which may or
may not be related. I can see how the gdb client would crash if I
didn't have the proper debugging symbols on the client, but could that
really effect other behavior on the remote machine?

I did originally copy over all .so's related to the service directly
and included their path in LD_LIBRARY_PATH, although I may have a
*slightly* different glibc or something.

> Also, this is a very old GDB - I always recommend trying the latest
> (GDB and gdbserver).

Is there a known bug that was fixed that would resolve this? That
would be a lot of work, given that I have no newer RPM's and there
isn't a compiler on my remote machine. I'll try it if there's a reason
to think it would work, or if I run out of other ideas.

This really looks to me like executable behavior is different under
local and remote debugging, so I was hoping someone knowledgeable
about GDB could comment on if that is possible, or if there are known
bugs here. Things like mismatched symbols don't seem like they should
effect runtime behavior on the remote machine.

More information about the Gdb mailing list