public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
Date: Thu, 19 Mar 2015 19:59:00 -0000	[thread overview]
Message-ID: <bug-65475-4-1ucUFlufLX@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-65475-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
In odr_vtable_hasher::equal:

585      t2 = TYPE_MAIN_VARIANT (t2);
586      if (t1 == t2)
587        return true;
588      tree v1 = BINFO_VTABLE (TYPE_BINFO (t1));
589      tree v2 = BINFO_VTABLE (TYPE_BINFO (t2));
590      return (operand_equal_p (TREE_OPERAND (v1, 1),
591                   TREE_OPERAND (v2, 1), 0)
592          && DECL_ASSEMBLER_NAME
593             (TREE_OPERAND (TREE_OPERAND (v1, 0), 0))
594             == DECL_ASSEMBLER_NAME


(gdb) p t1->type_non_common.binfo->binfo.vtable
$4 = (tree) 0x0

(gdb) p t2->type_non_common.binfo->binfo.vtable
$5 = (tree) 0x7ffff6e289b0


(gdb) p debug_tree(t1)
 <record_type 0x7ffff6e2bd20 failure QI
    size <integer_cst 0x7ffff6c36ca8 type <integer_type 0x7ffff6c3a150
bitsizetype> constant 8>
    unit size <integer_cst 0x7ffff6c36cc0 type <integer_type 0x7ffff6c3a0a8
sizetype> constant 1>
    align 8 symtab 0 alias set -1 canonical type 0x7ffff6e2bd20
    attributes <tree_list 0x7ffff6e28550
        purpose <identifier_node 0x7ffff6e28500 __abi_tag__>
        value <tree_list 0x7ffff6e28528
            value <string_cst 0x7ffff6e1b900 type <array_type 0x7ffff6e2bc78>
                readonly constant static "cxx11\000">>>
    fields <type_decl 0x7ffff6e29558 failure
        type <record_type 0x7ffff6e2e0a8 failure QI size <integer_cst
0x7ffff6c36ca8 8> unit size <integer_cst 0x7ffff6c36cc0 1>
            align 8 symtab 0 alias set -1 canonical type 0x7ffff6e2bd20
attributes <tree_list 0x7ffff6e28550> fields <type_decl 0x7ffff6e29558 failure>
context <record_type 0x7ffff6e2bdc8 ios_base>
            chain <type_decl 0x7ffff6e29260 failure>>
        nonlocal VOID file 1.ii line 4 col 57
        align 1 context <record_type 0x7ffff6e2bd20 failure> result
<record_type 0x7ffff6e2bd20 failure>> context <record_type 0x7ffff6e2bdc8
ios_base>
    chain <type_decl 0x7ffff6e29260 failure>>

(gdb) p debug_tree(t2)
 <record_type 0x7ffff6e2ec78 Trans_NS___cxx11_basic_ostringstream addressable
needs-constructing BLK
    size <integer_cst 0x7ffff6c36bb8 type <integer_type 0x7ffff6c3a150
bitsizetype> constant 64>
    unit size <integer_cst 0x7ffff6c36bd0 type <integer_type 0x7ffff6c3a0a8
sizetype> constant 8>
    align 64 symtab 0 alias set -1 canonical type 0x7ffff6e2ec78
    fields <field_decl 0x7ffff6e29d10 D.3973
        type <record_type 0x7ffff6e2ebd0 B addressable needs-constructing BLK
size <integer_cst 0x7ffff6c36bb8 64> unit size <integer_cst 0x7ffff6c36bd0 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6e2e9d8 fields
<field_decl 0x7ffff6e29be0 _vptr.B> context <namespace_decl 0x7ffff6e29130 std>
            chain <type_decl 0x7ffff6e29b48 B>>
        ignored BLK file 2.ii line 9 col 37 size <integer_cst 0x7ffff6c36bb8
64> unit size <integer_cst 0x7ffff6c36bd0 8>
        align 64 offset_align 128
        offset <integer_cst 0x7ffff6c36be8 constant 0>
        bit offset <integer_cst 0x7ffff6c36c30 constant 0> context <record_type
0x7ffff6e2ec78 Trans_NS___cxx11_basic_ostringstream>
        chain <type_decl 0x7ffff6e29da8 Trans_NS___cxx11_basic_ostringstream
type <record_type 0x7ffff6e2ed20 Trans_NS___cxx11_basic_ostringstream>
            external nonlocal suppress-debug VOID file 2.ii line 9 col 78
            align 8 context <record_type 0x7ffff6e2ec78
Trans_NS___cxx11_basic_ostringstream> result <record_type 0x7ffff6e2ec78
Trans_NS___cxx11_basic_ostringstream>>> context <namespace_decl 0x7ffff6e29130
std>
    chain <type_decl 0x7ffff6e29c78 Trans_NS___cxx11_basic_ostringstream>>


Thanks,
Martin
>From gcc-bugs-return-480866-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 19 19:25:00 2015
Return-Path: <gcc-bugs-return-480866-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 96234 invoked by alias); 19 Mar 2015 19:25:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 96198 invoked by uid 48); 19 Mar 2015 19:24:56 -0000
From: "aral at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
Date: Thu, 19 Mar 2015 20:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: aral at gmx dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65470-4-sYhawJ0FdJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65470-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65470-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02010.txt.bz2
Content-length: 895

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide470

--- Comment #4 from aral at gmx dot de ---
Addition: after you referred to the properties of match_results, I had a look
at

  http://en.cppreference.com/w/cpp/regex/match_results

which has a clearer wording. However, I still think this clear statement
  => "it's undefined behavior to examine std::match_results if the original
character sequence was destroyed or iterators to it were invalidated for other
reasons"

should be added to the description of the functions that populate the
match_results. "The user" (I, in this case) does not always check the
descriptions of every single function parameter if the function description
seems to give all the information needed to use it.

What could be improved (to avoid bugs going undetected) is to raise an
exception if the match_results are accessed after the haystack has been
destroyed.


  reply	other threads:[~2015-03-19 19:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19 19:44 [Bug lto/65475] New: " marxin at gcc dot gnu.org
2015-03-19 19:59 ` marxin at gcc dot gnu.org [this message]
2015-03-19 22:21 ` [Bug lto/65475] " hubicka at gcc dot gnu.org
2015-03-20  8:29 ` hubicka at gcc dot gnu.org
2015-03-20 10:07 ` marxin at gcc dot gnu.org
2015-03-20 10:58 ` rguenth at gcc dot gnu.org
2015-03-20 19:11 ` hubicka at ucw dot cz
2015-03-20 19:12 ` hubicka at gcc dot gnu.org
2015-03-20 21:41 ` hubicka at gcc dot gnu.org
2015-03-23  2:19 ` hubicka at gcc dot gnu.org
2015-03-23  3:01 ` hubicka at gcc dot gnu.org
2015-03-23 21:07 ` jakub at gcc dot gnu.org

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=bug-65475-4-1ucUFlufLX@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).