From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A83CA3850423; Fri, 29 Jan 2021 09:20:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A83CA3850423 From: "craig.ringer at 2ndquadrant dot com" To: systemtap@sourceware.org Subject: [Bug translator/27274] New: stap: staptree.h:1349: virtual update_visitor::~update_visitor(): Assertion `values.empty()' failed. Date: Fri, 29 Jan 2021 09:20:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: craig.ringer at 2ndquadrant dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 09:20:40 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27274 Bug ID: 27274 Summary: stap: staptree.h:1349: virtual update_visitor::~update_visitor(): Assertion `values.empty()' failed. Product: systemtap Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: translator Assignee: systemtap at sourceware dot org Reporter: craig.ringer at 2ndquadrant dot com Target Milestone: --- I've been seeing intermittent assertion failures `update_visitor::~update_visitor(): Assertion `values.empty()' failed` in script compilation and finally tracked down one of the ways it arises. In a SDT marker based probe, if not enough arguments are passed to a functi= on, then in some cases this assertion seems to fire. I finally reduced this to a minimal example, attached. Run gcc -Wextra -Wall -Wno-unused-parameter -o test_sdt test_sdt.c stap -v sdt_assert.stp Result: $ /usr/local/systemtap/bin/stap -v sdt_assert.stp=20 Pass 1: parsed user script and 497 library scripts using 357068virt/114944res/13316shr/101304data kb, in 210usr/20sys/232real ms. stap: staptree.h:1349: virtual update_visitor::~update_visitor(): Asser= tion `values.empty()' failed. Aborted (core dumped) Full backtrace attached, but here's the short one: ``` #0 __GI_raise (sig=3D) at ../sysdeps/unix/sysv/linux/raise.= c:49 #1 __GI_abort () at abort.c:79 #2 __assert_fail_base (fmt=3D"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=3D"values.empty()", file=3D"staptree.h", line=3D1349, function=3D= ) at assert.c:92 #3 __GI___assert_fail (assertion=3D"values.empty()", file=3D"staptree.h", line=3D1349, function=3D"virtual update_visitor::~update_visitor()") at assert.c:101 #4 update_visitor::~update_visitor (this=3D, __in_chrg=3D) at staptree.h:1349 #5 update_visitor::~update_visitor (this=3D, __in_chrg=3D) at staptree.h:1349 #6 sdt_query::handle_probe_entry (this=3D) at /usr/include/c++/10/ext/new_allocator.h:89 #7 sdt_query::setup_note_probe_entry (this=3D, scn_name=3D..., note_name= =3D..., type=3D, data=3D"p\215\005M\377\177", len=3D)= at tapsets.cxx:7890 #8 dwflpp::iterate_over_notes (this=3Dthis@entry=3D, object=3Dobject= @entry=3D,=20 =20=20=20 callback=3Dcallback@entry=3D, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, int, char const*, unsigned long)>) at dwflpp.cxx:1292 #9 dwflpp::iterate_over_notes ( callback=3D, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, int, char const*, unsigned long)>, object=3D, this=3D) at dwflpp.h:310 #10 sdt_query::handle_query_module (this=3D) at tapsets.cxx:7748 #11 query_module (mod=3D, name=3D"/home/craig/projects/2Q/systemtap/test_sd= t", addr=3D, q=3D) at tapsets.cxx:2664 #12 dwfl_getmodules () from /lib64/libdw.so.1 #13 dwflpp::iterate_over_modules (data=3D, callback=3D, this=3D) at dwflpp.h:228 #14 dwarf_builder::build (this=3D, sess=3D..., base=3D, location=3D, parameters=3Dstd::map with 2 elements =3D {...}, finished_results=3Dstd::ve= ctor of length 0, capacity 0) at tapsets.cxx:8805 #15 match_node::find_and_build (this=3D, s=3D..., p=3D, loc=3D, pos=3D, results=3Dstd::vector of length 0, capacity 0, builders=3Dstd::set with 0 e= lements) at elaborate.cxx:479 #16 match_node::find_and_build (this=3D, s=3D..., p=3D, loc=3D, pos=3D1, results=3Dstd::vector of length 0, capacity 0, builders=3Dstd::set with 0 e= lements) at elaborate.cxx:653 #17 match_node::find_and_build (this=3D, s=3D..., p=3D, loc=3D, pos=3D0, results=3Dstd::vector of length 0, capacity 0, builders=3Dstd::set with 0 e= lements) at elaborate.cxx:653 #18 derive_probes (s=3D..., p=3D, dps=3Dstd::vector of length 0, capacity 0, optional=3D, rethrow_errors=3Dfalse) at elaborate.cxx:1020 #19 semantic_pass_symbols (s=3D...) at elaborate.cxx:1950 #20 semantic_pass (s=3D...) at elaborate.cxx:2540 #21 passes_0_4 (s=3D...) at main.cxx:1019 #22 main (argc=3D, argv=3D) at main.cxx:1504 ``` --=20 You are receiving this mail because: You are the assignee for the bug.=