This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/20569] New: GDB segv in follow_exec
- From: "sandra at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 08 Sep 2016 03:05:47 +0000
- Subject: [Bug gdb/20569] New: GDB segv in follow_exec
- Auto-submitted: auto-generated
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.