This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/18929] New: NULL deref on throw in cp_print_value_fields
- From: "anton_nix at mail dot ru" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Mon, 07 Sep 2015 01:41:18 +0000
- Subject: [Bug gdb/18929] New: NULL deref on throw in cp_print_value_fields
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18929
Bug ID: 18929
Summary: NULL deref on throw in cp_print_value_fields
Product: gdb
Version: 7.10
Status: NEW
Severity: normal
Priority: P2
Component: gdb
Assignee: unassigned at sourceware dot org
Reporter: anton_nix at mail dot ru
Target Milestone: ---
Created attachment 8583
--> https://sourceware.org/bugzilla/attachment.cgi?id=8583&action=edit
Patch
I think i found a bug
gdb-7.10/gdb/cp-valprint.c:316
struct value *v = NULL;
TRY { v = value_static_field (type, i); }
CATCH ...
END_CATCH
cp_print_static_field (TYPE_FIELD_TYPE (type, i),
v, stream, recurse + 1,
options);
Assume that throw happend in value_static_field, then "v" would still
be NULL, but cp_print_static_field expects "v" to be non-zero. This
situation would lead to SEGFAULT
Propose to place "v" and cp_print_static_field call into TRY block
Digging in git history, I found out that, if v == NULL before
cp_print_static_field call, then val_print_optimized_out happend
(commit 686d4defdf4a343d4b700b8b544cd40c4f16b0d1). But in my case
variable was not optimized out, and value_static_field throws.
P.S.: I was debugging remote linux application from windows host.
Patch to 7.10 attached
--
You are receiving this mail because:
You are on the CC list for the bug.