Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Brendan Miller <catphive@catphive.net>
To: gdb@sourceware.org
Subject: Re: problem remote debugging
Date: Tue, 24 Feb 2009 17:01:00 -0000	[thread overview]
Message-ID: <ef38762f0902240901i73fc78f6ve97ff11643e713c6@mail.gmail.com> (raw)
In-Reply-To: <20090224023251.GA22085@caradoc.them.org>

On Mon, Feb 23, 2009 at 6:32 PM, Daniel Jacobowitz <drow@false.org> 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
>> 6.3.0.0-1.153.el4rh.
>
> 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.


  reply	other threads:[~2009-02-24 17:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24  0:59 Brendan Miller
2009-02-24  2:25 ` teawater
2009-02-24  2:33 ` Daniel Jacobowitz
2009-02-24 17:01   ` Brendan Miller [this message]
2009-02-24 17:08     ` Daniel Jacobowitz
2009-02-24 19:52       ` Brendan Miller
2009-02-25  6:07         ` Paul Pluzhnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef38762f0902240901i73fc78f6ve97ff11643e713c6@mail.gmail.com \
    --to=catphive@catphive.net \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox