This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/20569] New: GDB segv in follow_exec


https://sourceware.org/bugzilla/show_bug.cgi?id=20569

            Bug ID: 20569
           Summary: GDB segv in follow_exec
           Product: gdb
           Version: 7.11.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: sandra at codesourcery dot com
  Target Milestone: ---

Created attachment 9491
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9491&action=edit
patch for segv

I am seeing that GDB is dying with a segv on several exec-related tests, e.g.
gdb.base/execl-update-breakpoints.exp.  It appears that follow_exec () in
infrun.c is not prepared for the case where exec_file_find returns NULL and is
passing the null pointer on to strlen.  The attached patch fixes the segv, but
doesn't allow the test to work, so it's probably not a sufficient fix by
itself.

More background: I'm testing a Canadian cross configuration, GDB 7.11.1, build
is i686-pc-linux-gnu, target nios2-linux-gnu, host i686-mingw32.  The sysroot
lives on the build and is NFS-mounted on the target and Samba-mounted on the
host, and there are symbolic links so that it appears to be at the same
pathname on all three machines.  The test harness does "set sysroot /." since
testing is faster when libraries are accessed locally instead of transferred
over the RSP.

I think the root of the problem is that the pathname reported by gdbserver
running on the target is not valid on the host -- it is reporting the fully
resolved NFS path, like

/net/buildmachine/path/to/execl-update-breakpoints2

instead of

/path/to/execl-update-breakpoints2

IIUC, gdbserver is getting the resolved path from /proc/PID/exe on the target.

Do we need a different mechanism than "set solib" to specify the mapping of
executable pathnames as opposed to shared library pathnames?  Should the
testcases be issuing a "file" command explicitly instead of relying on a valid
host pathname, or pathname within the sysroot, being supplied by the target? 
Or something else?

I think this is the set of tests that are affected (most of them are tripping
over the segv more than once as they run multiple variants):

gdb.base/execl-update-breakpoints.exp
gdb.base/foll-exec.exp
gdb.base/foll-vfork.exp
gdb.base/infcall-exec.exp
gdb.threads/execl.exp
gdb.threads/thread-execl.exp

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]