This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/16594] info os processes -fsanitize=address error
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 21 Feb 2014 17:42:30 +0000
- Subject: [Bug gdb/16594] info os processes -fsanitize=address error
- Auto-submitted: auto-generated
- References: <bug-16594-4717 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=16594
--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 184cd07257b5dd74a4eb9f6857fc6dd785f53492 (commit)
from dcf893b581c440902d68a0095967acd4ae7ae8d1 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=184cd07257b5dd74a4eb9f6857fc6dd785f53492
commit 184cd07257b5dd74a4eb9f6857fc6dd785f53492
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
Date: Fri Feb 21 18:39:40 2014 +0100
Fix crash on process name "(sd-pam)" (PR 16594).
info os processes -fsanitize=address error
https://sourceware.org/bugzilla/show_bug.cgi?id=16594
info os processes
=================================================================
==5795== ERROR: AddressSanitizer: heap-use-after-free on address
0x600600214974 at pc 0x757a92 bp 0x7fff95dd9f00 sp 0x7fff95dd9ef0
READ of size 4 at 0x600600214974 thread T0
#0 0x757a91 in get_cores_used_by_process (.../gdb/gdb+0x757a91)
At least Fedora 20 has process(es):
6678 ? Ss 0:00 /usr/lib/systemd/systemd --user
6680 ? S 0:00 \_ (sd-pam)
and GDB "info os processes" crashes on it as /proc/6680/stat contains:
6680 ((sd-pam)) S 6678 6678 6678 0 -1 1077961024 33 0 0 0 0 0 0 0 20 0 1 0
18568 73768960 120 18446744073709551615 1 1
0 0 0 0 0 4096 0 18446744073709551615 0 0 17 6 0 0 0 0 0 0 0 0 0 0 0 0 0
and GDB fails to find the proper end of the process name "((sd-pam))".
Therefore it reads core number off-by-one (it reads 17 instead of 6) and
overruns the array.
(1) Make the process name parsing more foolproof.
(2) Do not trust the parsed number from /proc/PID/stat and verify it
against
the array size.
I noticed that 'ps' gets this right, so I've peeked at its
sources, and it just looks for the first ')' starting at
the end.
https://gitorious.org/procps/procps/source/dc072aced7250fed9b01fb05f0d672678752a63e:proc/readproc.c
Look for stat2proc.
Given ps does that, I believe the kernel won't ever be changed
in a way that would break it. So it sounds like could do strrchr
from the end of stat just as well without worry, which is simpler.
gdb/
2014-02-21 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16594
* common/linux-osdata.c (linux_common_core_of_thread): Find the end of
process name.
(get_cores_used_by_process): New parameter num_cores, use it.
(linux_xfer_osdata_processes): Pass num_cores to it.
* linux-tdep.c (linux_info_proc, linux_fill_prpsinfo): Find the end of
process name.
Message-ID: <20140217212826.GA15080@host2.jankratochvil.net>
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 10 ++++++++++
gdb/common/linux-osdata.c | 16 ++++++----------
gdb/linux-tdep.c | 18 +++++++++++-------
3 files changed, 27 insertions(+), 17 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.