From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 37C33389850D; Mon, 5 Dec 2022 10:37:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 37C33389850D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670236666; bh=zvlvlyb/ks9LSNNZ4gHulu3PJxWlbOt45bVhu7ZIyf0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vGocO5vV2uJdNpqDrP0iziTevFip82InK+TEEpCbWdpDF57ykGn1Y+DGrescFqqYm 43xjb5JDNpJH56VPXPl7yKDcGI9hWFaldCSX4TQQGrR4XmI2kx7aETlxBop0N87M38 HK4hucqrVP/0d6fSg6c7loxtMbcUPNvbslO/DEr8= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/107965] libstdc++ Python Pretty-Printers: Many Exceptions From Uninitialized Structures Date: Mon, 05 Dec 2022 10:37:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107965 --- Comment #6 from Jonathan Wakely --- Reading symbols from p... (gdb) start Temporary breakpoint 1 at 0x4022ea: file p.cc, line 18. Starting program: /tmp/p=20 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Temporary breakpoint 1, main () at p.cc:18 18 } Why is the location for the 'start' breakpoint the closing brace of main() = ?! (gdb) n 9 vector test{"test", "test2"}; (gdb) info locals test =3D std::vector of length 5, capacity 38 =3D {" ", , "",=20 , } blabla =3D "" b =3D 32767 The errors here seem reasonable, but they depend entirely on the garbage th= at happens to be in the uninitialized variables. Different garbage will produce worse errors. (gdb) disable pretty-printer 200 printers disabled 0 of 200 printers enabled (gdb) info locals test =3D {, std::allocator >, std::allocator, std::allocator > > >> =3D { _M_impl =3D {, std::allocator > >> =3D {, std::allocator > >> =3D {}, }, , std::allocator >, std::allocator, std::allocator > > >::_Vector_impl_data> =3D {_M_start =3D 0x7ffff7e2e9a0 <(anonymous namespace)::moneypunct_cache_wf>,= =20 _M_finish =3D 0x7ffff7e2ea40 <(anonymous namespace)::moneypunct_cache_wt>,=20 _M_end_of_storage =3D 0x7ffff7e2ee60 <(anonymous namespace)::moneypunct_cache_ct>}, }}, } Even with the printers disabled (which is what would happen if the printers caught all exceptions and didn't show anything) we get nonsense. moneypunct_cache_wf, moneypunct_cache_wt, and moneypunch_cache_ct are global variables inside libstdc++.so, but the uninitialized pointers in the std::vector just happen to point at them. blabla =3D {_M_dataplus =3D {> =3D {> =3D {}, },=20 _M_p =3D 0x7ffff7e2ede0 <(anonymous namespace)::moneypunct_cache_cf> "x9\342\367\377\177"}, _M_string_length =3D 140737352232672, { _M_local_buf =3D "\300\357\342\367\377\177\000\000\002\316\314\367\377\177\000", _M_allocated_capacity =3D 140737352232896}} This is all garbage. b =3D 32767 At least with an uninitialized int we just get an arbitrary int value, not nonsense. But none of these variables should be live yet, so gdb shouldn't even try to show their values.=