Thanks for the report.  What are the steps to reproduce this bug?  Build GCC?

Yes, just build gcc.

BTW: after building gcc I found several core dumps in /var/lib/systemd/coredump. Looks like almost all ow them have been generated durin %check.
Should I open separated gcc ticket for all those issues?

Just in case. All those crashes happens during gcc %check.

[root@barrel coredump]# ls -1 *gdb* | wc -l
16

So the way to trigger this bug is to build the GCC *RPM*, right?  I am going to try here, but a more detailed instruction would be better.  Thanks.

Yep .. just please use rawhide gcc source rpm :)

In mean time I've finished building one more time gcc on my devel box and I can confirm that there is no any crashes (gdb as well) during build or generate final packages.
All bad happens only in %check :/

Just checked and after building gcc I found 707 core files in /var/lib/systemd/coredump.
I'm not sure is it something so wrong with test suite that it crashes in so many points or it is symptom of something more serious in gcc.
Should I open the ticket against gcc or you will try to take care of this as well?

(In reply to Tomasz Kłoczko from comment #6)
> Yep .. just please use rawhide gcc source rpm :)

Right, that's what I am doing indeed.

> In mean time I've finished building one more time gcc on my devel box and I
> can confirm that there is no any crashes (gdb as well) during build or
> generate final packages.

You mean that you built GCC without performing the %check step and it didn't crash?

> All bad happens only in %check :/
> 
> Just checked and after building gcc I found 707 core files in
> /var/lib/systemd/coredump.
> I'm not sure is it something so wrong with test suite that it crashes in so
> many points or it is symptom of something more serious in gcc.
> Should I open the ticket against gcc or you will try to take care of this as
> well?

Honestly, I don't know.  I'm not a GCC developer.  Just seeing corefiles being generated during the testsuite run is not an indicative that there is a bug; GDB, for example, also generates many corefiles during its testsuite.  I advise you to talk to some GCC developer and check with them.

(In reply to Sergio Durigan Junior from comment #7)
[..]
> > In mean time I've finished building one more time gcc on my devel box and I
> > can confirm that there is no any crashes (gdb as well) during build or
> > generate final packages.
> 
> You mean that you built GCC without performing the %check step and it didn't
> crash?

No. It is way worse .. I mean that gcc %check does not stop if any  test unit crashes or fails :(
In build logs going to stdout or stderr it is not possible to find single line that some tests units finished with SIGSEV/core dump.

(In reply to Tomasz Kłoczko from comment #8)
> (In reply to Sergio Durigan Junior from comment #7)
> [..]
> > > In mean time I've finished building one more time gcc on my devel box and I
> > > can confirm that there is no any crashes (gdb as well) during build or
> > > generate final packages.
> > 
> > You mean that you built GCC without performing the %check step and it didn't
> > crash?
> 
> No. It is way worse .. I mean that gcc %check does not stop if any  test
> unit crashes or fails :(
> In build logs going to stdout or stderr it is not possible to find single
> line that some tests units finished with SIGSEV/core dump.

Sorry, this is related to GCC, so I can't really help here.  I'm interested in knowing about the GDB failure you've experienced.  For example, which version of GDB are you using?  Are you able to try reproducing this bug with an earlier version of GDB?  I have a suspicion that this bug has been introduced in the last version of GDB that is available on Rawhide.  If that's what you're using, can you try downgrading to the previous version?

I'm using current rawhide gdb

$ rpm -q gdb
gdb-8.3.50.20190304-1.fc31.x86_64

Notice that you did not reply to my questions regarding the possibility of downgrading GDB.  Please answer the questions, they greatly help me to try and locate the problem.

I have built the latest GCC RPM on Rawhide, but I don't to see the failure you posted.  Can you please be more specific and post the exact steps you take to reproduce this?  Otherwise it is a waste of time and effort to try to understand

Rawhide dos not preserve any prev versions of any packages.
I don't see how can downgrade gdb.

How did you obtain the backtrace you posted on the Description?

Istalling gdb-debuginfo, than starting gdb -c <core_file>

[tkloczko@barrel ~]$ rpm -q gdb gdb-debuginfo binutils gcc
gdb-8.3.50.20190304-1.fc31.x86_64
gdb-debuginfo-8.3.50.20190304-1.fc31.x86_64
binutils-2.32-9.fc31.x86_64
gcc-9.0.1-0.10.fc30.x86_64

I want to know which corefile you used to obtain this backtrace.

I've took first one dumped during the %check

[root@barrel coredump]# cd
[root@barrel ~]# cd /var/lib/systemd/coredump
[root@barrel coredump]# ls -la *gdb*
-rw-r-----+ 1 root root 8585915 Mar 19 11:52 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.25085.1552996374000000.lz4
-rw-r-----+ 1 root root 9565874 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.28435.1552996379000000.lz4
-rw-r-----+ 1 root root 8675487 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.30916.1552996383000000.lz4
-rw-r-----+ 1 root root 8621034 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.33542.1552996386000000.lz4
-rw-r-----+ 1 root root 8572882 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.36436.1552996390000000.lz4
-rw-r-----+ 1 root root 8737537 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.39673.1552996395000000.lz4
-rw-r-----+ 1 root root 8710301 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.42578.1552996399000000.lz4
-rw-r-----+ 1 root root 8786563 Mar 19 11:53 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.45274.1552996404000000.lz4
-rw-r-----+ 1 root root 8644979 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.6590.1552997304000000.lz4
-rw-r-----+ 1 root root 9568098 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.6946.1552997307000000.lz4
-rw-r-----+ 1 root root 8702557 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.7129.1552997309000000.lz4
-rw-r-----+ 1 root root 8610487 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.7271.1552997312000000.lz4
-rw-r-----+ 1 root root 8587971 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.7409.1552997314000000.lz4
-rw-r-----+ 1 root root 8705610 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.7600.1552997317000000.lz4
-rw-r-----+ 1 root root 8702147 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.7825.1552997320000000.lz4
-rw-r-----+ 1 root root 8774895 Mar 19 12:08 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.8012.1552997322000000.lz4
[root@barrel coredump]# unlz4 core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.25085.1552996374000000.lz4
Decoding file core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.25085.1552996374000000 
core.gdb.1000.e950f5 : decoded 32251904 bytes                                  
[root@barrel coredump]# gdb -c core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.25085.1552996374000000
GNU gdb (GDB) Fedora 8.3.50.20190304-1.fc31
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
[New LWP 25085]
Reading symbols from /usr/libexec/gdb...
Reading symbols from /usr/lib/debug/usr/libexec/gdb-8.3.50.20190304-1.fc31.x86_64.debug...

warning: Ignoring non-absolute filename: <linux-vdso.so.1>
Missing separate debuginfo for linux-vdso.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/48/f4868bbdf62fae9fa85d4e5a6589c5d894e271
Missing separate debuginfo for /home/tkloczko/rpmbuild/BUILD/gcc-9.0.1-20190312/obj-x86_64-redhat-linux/x86_64-redhat-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/8f/9f73207c5f1ac4623f1d27e63e915bb9720bd2
Missing separate debuginfo for /home/tkloczko/rpmbuild/BUILD/gcc-9.0.1-20190312/obj-x86_64-redhat-linux/gcc/libgcc_s.so.1
Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/98/f1e9225225349486e36a89573f881abf703877
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `gdb -nx -nw -quiet -batch -x array.gdb'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f54a90887c6 in ?? () from /lib64/libpython3.7m.so.1.0
Missing separate debuginfos, use: dnf debuginfo-install boost-regex-1.69.0-6.fc30.x86_64 bzip2-libs-1.0.6-29.fc30.x86_64 elfutils-libelf-0.176-1.fc30.x86_64 elfutils-libs-0.176-1.fc30.x86_64 expat-2.2.6-2.fc30.x86_64 glib2-2.60.0-3.fc31.x86_64 glibc-2.29.9000-6.fc31.x86_64 gmp-6.1.2-10.fc31.x86_64 libacl-2.2.53-4.fc30.x86_64 libbabeltrace-1.5.6-2.fc30.x86_64 libcap-2.26-5.fc30.x86_64 libdb-5.3.28-37.fc30.x86_64 libicu-63.1-2.fc30.x86_64 libselinux-2.9-0.rc2.1.fc31.x86_64 libuuid-2.33.1-4.fc31.x86_64 libzstd-1.3.8-2.fc30.x86_64 lua-libs-5.3.5-5.fc30.x86_64 mpfr-3.1.6-4.fc30.x86_64 ncurses-libs-6.1-10.20180923.fc30.x86_64 pcre-8.43-1.fc31.x86_64 pcre2-10.33-0.3.RC1.fc31.x86_64 popt-1.16-17.fc30.x86_64 python3-libs-3.7.2-7.fc30.x86_64 readline-8.0-2.fc30.x86_64 rpm-libs-4.14.2.1-4.fc30.1.x86_64 source-highlight-3.1.8-23.fc31.x86_64 sssd-client-2.0.0-8.fc30.x86_64 xz-libs-5.2.4-5.fc30.x86_64 zlib-1.2.11-15.fc30.x86_64
(gdb) bt full
#0  0x00007f54a90887c6 in ?? () from /lib64/libpython3.7m.so.1.0
No symbol table info available.
#1  0x00007f54a908898c in PyGILState_Ensure () from /lib64/libpython3.7m.so.1.0
No symbol table info available.
#2  0x000055ed7c80a697 in gdbpy_enter::gdbpy_enter (this=0x7ffe3b220f70, gdbarch=0x55ed7e3b0f10, language=0x55ed7ce749a0 <cplus_language_defn>)
    at ../../gdb/python/python.c:212
No locals.
#3  0x000055ed7c8088a6 in python_xmethod_worker::~python_xmethod_worker (this=0x55ed7e6fb040, __in_chrg=<optimized out>) at ../../gdb/python/py-xmethods.c:72
        enter_py = {m_previous_active = 0x55ed7e776bf0, m_state = (PyGILState_UNLOCKED | unknown: 2835769840), m_gdbarch = 0x55ed7e3b0f10, 
          m_language = 0x55ed7ce749a0 <cplus_language_defn>, m_error = {{m_dummy = {<No data fields>}, m_item = {m_error_type = 0x7f54a9060f30, 
                m_error_value = 0x7f54a5caa240, m_error_traceback = 0x7f54a5b449e0}}, m_instantiated = false}}
        enter_py = <optimized out>
#4  0x000055ed7c8088fd in python_xmethod_worker::~python_xmethod_worker (this=0x55ed7e6fb040, __in_chrg=<optimized out>) at ../../gdb/python/py-xmethods.c:69
        enter_py = <optimized out>
#5  0x000055ed7c946e3f in value::~value (this=0x55ed7ea6a250, __in_chrg=<optimized out>) at ../../gdb/value.c:195
No locals.
#6  value_decref (val=0x55ed7ea6a250) at ../../gdb/value.c:1599
        __PRETTY_FUNCTION__ = <optimized out>
#7  0x000055ed7c94b72e in value_ref_policy::decref (ptr=<optimized out>) at ../../gdb/value.h:111
No locals.
#8  gdb::ref_ptr<value, value_ref_policy>::~ref_ptr (this=0x55ed7e495c18, __in_chrg=<optimized out>) at ../../gdb/common/gdb_ref_ptr.h:91
No locals.
#9  std::_Destroy<gdb::ref_ptr<value, value_ref_policy> > (__pointer=0x55ed7e495c18) at /usr/include/c++/9/bits/stl_construct.h:98
No locals.
#10 std::_Destroy_aux<false>::__destroy<gdb::ref_ptr<value, value_ref_policy>*> (__last=<optimized out>, __first=0x55ed7e495c18)
    at /usr/include/c++/9/bits/stl_construct.h:108
No locals.
#11 std::_Destroy<gdb::ref_ptr<value, value_ref_policy>*> (__last=<optimized out>, __first=<optimized out>) at /usr/include/c++/9/bits/stl_construct.h:137
No locals.
#12 std::_Destroy<gdb::ref_ptr<value, value_ref_policy>*, gdb::ref_ptr<value, value_ref_policy> > (__last=0x55ed7e495c20, __first=<optimized out>)
    at /usr/include/c++/9/bits/stl_construct.h:206
No locals.
#13 std::vector<gdb::ref_ptr<value, value_ref_policy>, std::allocator<gdb::ref_ptr<value, value_ref_policy> > >::~vector (this=0x55ed7cf1ea10 <all_values>, 
    __in_chrg=<optimized out>) at /usr/include/c++/9/bits/stl_vector.h:677
No locals.
--Type <RET> for more, q to quit, c to continue without paging--
#14 0x00007f54a87b8700 in __run_exit_handlers () from /lib64/libc.so.6
No symbol table info available.
#15 0x00007f54a87b8840 in exit () from /lib64/libc.so.6
No symbol table info available.
#16 0x000055ed7c8fd1c2 in quit_force (exit_arg=exit_arg@entry=0x0, from_tty=from_tty@entry=0) at ../../gdb/top.c:1692
        exit_code = 0
        qt = {from_tty = 0}
#17 0x000055ed7c61b3e0 in quit_command (args=<optimized out>, from_tty=0) at ../../gdb/cli/cli-cmds.c:351
        exit_code = 0
#18 0x000055ed7c62197a in cmd_func (cmd=<optimized out>, args=<optimized out>, from_tty=<optimized out>) at ../../gdb/cli/cli-decode.c:1892
        restore_suppress = {{m_dummy = {<No data fields>}, m_item = {<scoped_restore_base> = {m_saved_var = 0x0}, m_saved_value = 0}}, m_instantiated = <optimized out>}
#19 0x000055ed7c8fbe40 in execute_command (p=<optimized out>, p@entry=0x55ed7e2ffcd0 "quit", from_tty=0) at ../../gdb/top.c:630
        without_whitespace = {static npos = 18446744073709551615, 
          _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7ffe3b221190 ""}, 
          _M_string_length = 0, {_M_local_buf = '\000' <repeats 15 times>, _M_allocated_capacity = 0}}
        cmd = 0x55ed7e2ffcd4 ""
        arg = 0x0
        was_sync = 0
        save_repeat_args = <optimized out>
        args_pointer = 0x55ed7e2ffcd4 ""
        c = 0x55ed7e2427c0
        line = 0x55ed7e2ffcd0 "quit"
        cmd_start = 0x55ed7e2ffcd0 "quit"
        cleanup_if_error = {<scope_exit_base<scope_exit<void (*)()> >> = {m_released = false}, m_exit_function = <optimized out>}
        cleanup = {m_value = 0x55ed7ea6a250}
        __PRETTY_FUNCTION__ = "void execute_command(const char*, int)"
#20 0x000055ed7c6d62a5 in command_handler (command=0x55ed7e2ffcd0 "quit") at ../../gdb/event-top.c:586
        ui = 0x55ed7df67810
        c = <optimized out>
        stat_reporter = {m_msg_type = true, m_time_enabled = 0, m_space_enabled = 0, m_symtab_enabled = 0, m_start_cpu_time = {__d = {__r = 0}}, m_start_wall_time = {
            __d = {__r = 0}}, m_start_space = -782603711387270656, m_start_nr_symtabs = 1634890337, m_start_nr_compunit_symtabs = 1684483705, 
          m_start_nr_blocks = 2113304592}
#21 0x000055ed7c8fcabf in read_command_file (stream=stream@entry=0x55ed7e2c8ae0) at ../../gdb/top.c:425
        command = <optimized out>
        ui = 0x55ed7df67810
--Type <RET> for more, q to quit, c to continue without paging--
        save_instream = <optimized out>
#22 0x000055ed7c6288d1 in script_from_file (stream=stream@entry=0x55ed7e2c8ae0, file=file@entry=0x7ffe3b2230fb "array.gdb") at ../../gdb/cli/cli-script.c:1548
        exception_try_scope_instance = {saved_state = 0x55ed7cae0a40 <sentinel_cleanup>}
        restore_line_number = <optimized out>
        restore_file = @0x7ffe3b2212f0: {m_saved_var = 0x55ed7cf1d6c0 <source_file_name[abi:cxx11]>}
        save_async = <optimized out>
#23 0x000055ed7c61e49b in source_script_from_stream (file_to_open=0x7ffe3b2230fb "array.gdb", file=0x7ffe3b2230fb "array.gdb", stream=0x55ed7e2c8ae0)
    at ../../gdb/cli/cli-cmds.c:569
        __PRETTY_FUNCTION__ = <optimized out>
        extlang = <optimized out>
        sourcer = <optimized out>
#24 source_script_with_search (file=0x7ffe3b2230fb "array.gdb", from_tty=<optimized out>, search_path=0) at ../../gdb/cli/cli-cmds.c:605
        opened = {{m_dummy = {<No data fields>}, m_item = {stream = {_M_t = {
                  _M_t = {<std::_Tuple_impl<0, _IO_FILE*, gdb_file_deleter>> = {<std::_Tuple_impl<1, gdb_file_deleter>> = {<std::_Head_base<1, gdb_file_deleter, true>> = {<gdb_file_deleter> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0, _IO_FILE*, false>> = {
                        _M_head_impl = 0x55ed7e2c8ae0}, <No data fields>}, <No data fields>}}}, full_path = {_M_t = {
                  _M_t = {<std::_Tuple_impl<0, char*, gdb::xfree_deleter<char> >> = {<std::_Tuple_impl<1, gdb::xfree_deleter<char> >> = {<std::_Head_base<1, gdb::xfree_deleter<char>, true>> = {<gdb::xfree_deleter<char>> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0, char*, false>> = {
                        _M_head_impl = 0x55ed7e2c7ad0 "/home/tkloczko/rpmbuild/BUILD/gcc-9.0.1-20190312/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/testsuite/normal3/array.gdb"}, <No data fields>}, <No data fields>}}}}}, m_instantiated = true}
#25 0x000055ed7c771498 in catch_command_errors (command=0x55ed7c61e590 <source_script(char const*, int)>, arg=0x7ffe3b2230fb "array.gdb", from_tty=0)
    at ../../gdb/main.c:381
        was_sync = 0
        exception_try_scope_instance = {saved_state = 0x55ed7cae0a40 <sentinel_cleanup>}
#26 0x000055ed7c7728d5 in captured_main_1 (python_script=<synthetic pointer>: <optimized out>, context=0x7ffe3b221570) at ../../gdb/main.c:1222
        cmdarg_p = <optimized out>
        argv = <optimized out>
        execarg = 0x0
        cdarg = 0x0
        local_gdbinit = 0x0
        i = 0
        save_auto_load = <optimized out>
        ret = <optimized out>
        argc = <optimized out>
        pid_or_core_arg = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
        ttyarg = 0x0
        cmdarg_vec = {<std::_Vector_base<cmdarg, std::allocator<cmdarg> >> = {
            _M_impl = {<std::allocator<cmdarg>> = {<__gnu_cxx::new_allocator<cmdarg>> = {<No data fields>}, <No data fields>}, <std::_Vector_base<cmdarg, std::allocator<cmdarg> >::_Vector_impl_data> = {_M_start = 0x55ed7df67ac0, _M_finish = 0x55ed7df67ad0, _M_end_of_storage = 0x55ed7df67ad0}, <No data fields>}}, <No data fields>}
        dirarg = {<std::_Vector_base<char*, std::allocator<char*> >> = {
            _M_impl = {<std::allocator<char*>> = {<__gnu_cxx::new_allocator<char*>> = {<No data fields>}, <No data fields>}, <std::_Vector_base<char*, std::allocator<char*> >::_Vector_impl_data> = {_M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}, <No data fields>}}, <No data fields>}
        system_gdbinit = 0x55ed7e25e900 "/etc/gdbinit"
        home_gdbinit = 0x0
        corearg = 0x0
        tmp_warn_preprint = {_M_t = {
            _M_t = {<std::_Tuple_impl<0, char*, gdb::xfree_deleter<char> >> = {<std::_Tuple_impl<1, gdb::xfree_deleter<char> >> = {<std::_Head_base<1, gdb::xfree_deleter<char>, true>> = {<gdb::xfree_deleter<char>> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0, char*, false>> = {
                  _M_head_impl = 0x0}, <No data fields>}, <No data fields>}}}
        symarg = 0x0
        pidarg = 0x0
        stat_reporter = {m_msg_type = false, m_time_enabled = -1, m_space_enabled = -1, m_symtab_enabled = -1, m_start_cpu_time = {__d = {__r = 59558}}, 
          m_start_wall_time = {__d = {__r = 81552493059499}}, m_start_space = 0, m_start_nr_symtabs = 0, m_start_nr_compunit_symtabs = 0, m_start_nr_blocks = 0}
        argc = <optimized out>
        argv = <optimized out>
        quiet = 1
        set_args = 0
        inhibit_home_gdbinit = 0
        symarg = <optimized out>
        execarg = <optimized out>
        pidarg = <optimized out>
        corearg = <optimized out>
        pid_or_core_arg = <optimized out>
        cdarg = <optimized out>
        ttyarg = <optimized out>
        print_help = 0
        print_version = 0
        print_configuration = 0
        cmdarg_vec = <optimized out>
        dirarg = <optimized out>
--Type <RET> for more, q to quit, c to continue without paging--
        system_gdbinit = <optimized out>
        home_gdbinit = <optimized out>
        local_gdbinit = <optimized out>
        i = <optimized out>
        save_auto_load = <optimized out>
        ret = <optimized out>
        stat_reporter = <optimized out>
        tmp_warn_preprint = <optimized out>
        tmp = <optimized out>
        c = <optimized out>
        long_options = {{name = 0x55ed7cbd2942 "tui", has_arg = 0, flag = 0x0, val = 14}, {name = 0x55ed7cbce4ed "dbx", has_arg = 0, 
            flag = 0x55ed7cf180b0 <dbx_commands>, val = 1}, {name = 0x55ed7cb7bcbb "readnow", has_arg = 0, flag = 0x0, val = 19}, {name = 0x55ed7cb7bcc4 "readnever", 
            has_arg = 0, flag = 0x0, val = 20}, {name = 0x55ed7cbd91b5 "r", has_arg = 0, flag = 0x0, val = 19}, {name = 0x55ed7cb3807f "quiet", has_arg = 0, 
            flag = 0x55ed7cf180d4 <captured_main_1(captured_main_args*, int&)::quiet>, val = 1}, {name = 0x55ed7cbd8c4e "q", has_arg = 0, 
            flag = 0x55ed7cf180d4 <captured_main_1(captured_main_args*, int&)::quiet>, val = 1}, {name = 0x55ed7cb3808b "silent", has_arg = 0, 
            flag = 0x55ed7cf180d4 <captured_main_1(captured_main_args*, int&)::quiet>, val = 1}, {name = 0x55ed7cbcf00d "nh", has_arg = 0, 
            flag = 0x55ed7cf180cc <captured_main_1(captured_main_args*, int&)::inhibit_home_gdbinit>, val = 1}, {name = 0x55ed7cb42a13 "nx", has_arg = 0, 
            flag = 0x55ed7cf1d770 <inhibit_gdbinit>, val = 1}, {name = 0x55ed7cb8105a "n", has_arg = 0, flag = 0x55ed7cf1d770 <inhibit_gdbinit>, val = 1}, {
            name = 0x55ed7cb38085 "batch-silent", has_arg = 0, flag = 0x0, val = 66}, {name = 0x55ed7cb38092 "batch", has_arg = 0, flag = 0x55ed7cf18078 <batch_flag>, 
            val = 1}, {name = 0x55ed7cac3866 "fullname", has_arg = 0, flag = 0x0, val = 102}, {name = 0x55ed7cbd889f "f", has_arg = 0, flag = 0x0, val = 102}, {
            name = 0x55ed7cb38098 "annotate", has_arg = 1, flag = 0x0, val = 12}, {name = 0x55ed7cadc6c4 "help", has_arg = 0, 
            flag = 0x55ed7cf180c8 <captured_main_1(captured_main_args*, int&)::print_help>, val = 1}, {name = 0x55ed7cbf22e4 "se", has_arg = 1, flag = 0x0, val = 10}, {
            name = 0x55ed7cae0058 "symbols", has_arg = 1, flag = 0x0, val = 115}, {name = 0x55ed7cba8539 "s", has_arg = 1, flag = 0x0, val = 115}, {
            name = 0x55ed7cac3bab "exec", has_arg = 1, flag = 0x0, val = 101}, {name = 0x55ed7cbd880b "e", has_arg = 1, flag = 0x0, val = 101}, {
            name = 0x55ed7cb57da8 "core", has_arg = 1, flag = 0x0, val = 99}, {name = 0x55ed7cb67e02 "c", has_arg = 1, flag = 0x0, val = 99}, {
            name = 0x55ed7cb32561 "pid", has_arg = 1, flag = 0x0, val = 112}, {name = 0x55ed7cb4b583 "p", has_arg = 1, flag = 0x0, val = 112}, {
            name = 0x55ed7cb3eae7 "command", has_arg = 1, flag = 0x0, val = 120}, {name = 0x55ed7cb380b3 "eval-command", has_arg = 1, flag = 0x0, val = 88}, {
            name = 0x55ed7cb3e4b5 "version", has_arg = 0, flag = 0x55ed7cf180c4 <captured_main_1(captured_main_args*, int&)::print_version>, val = 1}, {
            name = 0x55ed7cadc724 "configuration", has_arg = 0, flag = 0x55ed7cf180c0 <captured_main_1(captured_main_args*, int&)::print_configuration>, val = 1}, {
            name = 0x55ed7cb5587e "x", has_arg = 1, flag = 0x0, val = 120}, {name = 0x55ed7cabdd41 "ex", has_arg = 1, flag = 0x0, val = 88}, {
            name = 0x55ed7cb380a1 "init-command", has_arg = 1, flag = 0x0, val = 17}, {name = 0x55ed7cb380ae "init-eval-command", has_arg = 1, flag = 0x0, val = 18}, {
            name = 0x55ed7cbd6249 "ix", has_arg = 1, flag = 0x0, val = 17}, {name = 0x55ed7cbd6512 "iex", has_arg = 1, flag = 0x0, val = 18}, {
            name = 0x55ed7cb88b1a "ui", has_arg = 1, flag = 0x0, val = 105}, {name = 0x55ed7cac0141 "interpreter", has_arg = 1, flag = 0x0, val = 105}, {
            name = 0x55ed7cb51095 "i", has_arg = 1, flag = 0x0, val = 105}, {name = 0x55ed7cb380c5 "directory", has_arg = 1, flag = 0x0, val = 100}, {
            name = 0x55ed7cc05dfa "d", has_arg = 1, flag = 0x0, val = 100}, {name = 0x55ed7cb380c0 "data-directory", has_arg = 1, flag = 0x0, val = 68}, {
--Type <RET> for more, q to quit, c to continue without paging--
            name = 0x55ed7cbd7b0a "D", has_arg = 1, flag = 0x0, val = 68}, {name = 0x55ed7cb3de75 "cd", has_arg = 1, flag = 0x0, val = 11}, {
            name = 0x55ed7cb275aa "tty", has_arg = 1, flag = 0x0, val = 116}, {name = 0x55ed7cb380cf "baud", has_arg = 1, flag = 0x0, val = 98}, {
            name = 0x55ed7cbd8d96 "b", has_arg = 1, flag = 0x0, val = 98}, {name = 0x55ed7cbd3387 "nw", has_arg = 0, flag = 0x0, val = 15}, {
            name = 0x55ed7cb380d4 "nowindows", has_arg = 0, flag = 0x0, val = 15}, {name = 0x55ed7cbd7a56 "w", has_arg = 0, flag = 0x0, val = 16}, {
            name = 0x55ed7cb380d6 "windows", has_arg = 0, flag = 0x0, val = 16}, {name = 0x55ed7cb7cea5 "statistics", has_arg = 0, flag = 0x0, val = 13}, {
            name = 0x55ed7cae0648 "write", has_arg = 0, flag = 0x55ed7cf167d8 <write_files>, val = 1}, {name = 0x55ed7cac1de0 "args", has_arg = 0, 
            flag = 0x55ed7cf180d0 <captured_main_1(captured_main_args*, int&)::set_args>, val = 1}, {name = 0x55ed7cbd91dc "l", has_arg = 1, flag = 0x0, val = 108}, {
            name = 0x55ed7cb380de "return-child-result", has_arg = 0, flag = 0x55ed7cf18070 <return_child_result>, val = 1}, {name = 0x55ed7cadecf7 "python", 
            has_arg = 0, flag = 0x0, val = 80}, {name = 0x55ed7cbd8748 "P", has_arg = 0, flag = 0x0, val = 80}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
        option_index = <optimized out>
        rate = <optimized out>
        p = <optimized out>
        timeout = <optimized out>
        p = <optimized out>
        cmdarg_p = <optimized out>
        func = <optimized out>
        objfile = <optimized out>
        __for_range = <optimized out>
        __for_begin = <optimized out>
        __for_end = <optimized out>
        cmdarg_p = <optimized out>
        error_status = <optimized out>
        exit_arg = <optimized out>
#27 captured_main (data=0x7ffe3b221570) at ../../gdb/main.c:1253
        context = 0x7ffe3b221570
        python_script = <optimized out>
        context = <optimized out>
        python_script = <optimized out>
        exception_try_scope_instance = <optimized out>
        ex = <optimized out>
#28 gdb_main (args=0x7ffe3b221570) at ../../gdb/main.c:1291
        exception_try_scope_instance = {saved_state = 0x55ed7cae0a40 <sentinel_cleanup>}
#29 0x000055ed7c56dcbf in main (argc=<optimized out>, argv=<optimized out>) at ../../gdb/gdb.c:40
        args = {argc = 7, argv = 0x7ffe3b221678, interpreter_p = 0x55ed7caad004 "console"}
(gdb)

BTW: systemd by default is storing cores in compressed form. It would be good to learn gdb how to operate on comressed cores.

[root@barrel coredump]# coredumpctl 25085
Unknown operation 25085.
[root@barrel coredump]# coredumpctl info 25085
           PID: 25085 (gdb)
           UID: 1000 (tkloczko)
           GID: 1000 (tkloczko)
        Signal: 11 (SEGV)
     Timestamp: Tue 2019-03-19 11:52:54 GMT (1 day 7h ago)
  Command Line: gdb -nx -nw -quiet -batch -x array.gdb
    Executable: /usr/libexec/gdb
 Control Group: /user.slice/user-1000.slice/session-4.scope
          Unit: session-4.scope
         Slice: user-1000.slice
       Session: 4
     Owner UID: 1000 (tkloczko)
       Boot ID: e950f5e384f247e4bc43613f5c2845e7
    Machine ID: 32721e50e50340949e667d4322623e09
      Hostname: barrel
       Storage: /var/lib/systemd/coredump/core.gdb.1000.e950f5e384f247e4bc43613f5c2845e7.25085.1552996374000000.lz4
       Message: Process 25085 (gdb) of user 1000 dumped core.
                
                Stack trace of thread 25085:
                #0  0x00007f54a90887c6 n/a (libpython3.7m.so.1.0)
                #1  0x00007f54a908898c PyGILState_Ensure (libpython3.7m.so.1.0)
                #2  0x000055ed7c80a697 _ZN11gdbpy_enterC2EP7gdbarchPK13language_defn (gdb)
                #3  0x000055ed7c8088a6 _ZN21python_xmethod_workerD2Ev (gdb)
                #4  0x000055ed7c8088fd _ZN21python_xmethod_workerD0Ev (gdb)
                #5  0x000055ed7c946e3f _ZN5valueD4Ev (gdb)
                #6  0x000055ed7c94b72e _ZN16value_ref_policy6decrefEP5value (gdb)
                #7  0x00007f54a87b8700 __run_exit_handlers (libc.so.6)
                #8  0x00007f54a87b8840 exit (libc.so.6)
                #9  0x000055ed7c8fd1c2 _Z10quit_forcePii (gdb)
                #10 0x000055ed7c61b3e0 _Z12quit_commandPKci (gdb)
                #11 0x000055ed7c62197a _Z8cmd_funcP16cmd_list_elementPKci (gdb)
                #12 0x000055ed7c8fbe40 _Z15execute_commandPKci (gdb)
                #13 0x000055ed7c6d62a5 _Z15command_handlerPKc (gdb)
                #14 0x000055ed7c8fcabf _Z17read_command_fileP8_IO_FILE (gdb)
                #15 0x000055ed7c6288d1 _Z16script_from_fileP8_IO_FILEPKc (gdb)
                #16 0x000055ed7c61e49b source_script_from_stream (gdb)
                #17 0x000055ed7c771498 catch_command_errors (gdb)
                #18 0x000055ed7c7728d5 captured_main_1 (gdb)
                #19 0x000055ed7c56dcbf main (gdb)
                #20 0x00007f54a87a1f73 __libc_start_main (libc.so.6)
                #21 0x000055ed7c57223e _start (gdb)

it is quite possible that it is something wrong with that python plugin

(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007f54a92f6290  0x00007f54a931d4b9  Yes (*)     /lib64/libreadline.so.8
0x00007f54a92c65f0  0x00007f54a92d3878  Yes (*)     /lib64/libz.so.1
0x00007f54a929e850  0x00007f54a92b6680  Yes (*)     /lib64/libselinux.so.1
0x00007f54a9261b30  0x00007f54a9288912  Yes (*)     /lib64/libncursesw.so.6
0x00007f54a92353d0  0x00007f54a9242a2c  Yes (*)     /lib64/libtinfo.so.6
0x00007f54a9221270  0x00007f54a9222029  Yes (*)     /lib64/libdl.so.2
0x00007f54a8f37480  0x00007f54a90dc96d  Yes (*)     /lib64/libpython3.7m.so.1.0
0x00007f54a8eb5b50  0x00007f54a8ec3f85  Yes (*)     /lib64/libpthread.so.0
0x00007f54a8d77390  0x00007f54a8e12bf8  Yes (*)     /lib64/libm.so.6
0x00007f54a8d3c3f0  0x00007f54a8d57557  Yes (*)     /lib64/libexpat.so.1
0x00007f54a8d129f0  0x00007f54a8d29986  Yes (*)     /lib64/liblzma.so.5
0x00007f54a8d02af0  0x00007f54a8d086a6  Yes (*)     /lib64/libbabeltrace.so.1
0x00007f54a8cb5290  0x00007f54a8ce3179  Yes (*)     /lib64/libbabeltrace-ctf.so.1
0x00007f54a8c8f550  0x00007f54a8ca00ce  Yes (*)     /lib64/libipt.so.2
0x00007f54a8c311d0  0x00007f54a8c7dd2f  Yes (*)     /lib64/libmpfr.so.4
0x00007f54a8b87b30  0x00007f54a8bf75ba  Yes (*)     /lib64/libsource-highlight.so.4
0x00007f54a89f6f50  0x00007f54a8af0e42  Yes         /home/tkloczko/rpmbuild/BUILD/gcc-9.0.1-20190312/obj-x86_64-redhat-linux/x86_64-redhat-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
0x00007f54a89435f0  0x00007f54a8953a85  Yes         /home/tkloczko/rpmbuild/BUILD/gcc-9.0.1-20190312/obj-x86_64-redhat-linux/gcc/libgcc_s.so.1
0x00007f54a87a06b0  0x00007f54a88eac7f  Yes (*)     /lib64/libc.so.6
0x00007f54a86ef490  0x00007f54a8750e01  Yes (*)     /lib64/libpcre2-8.so.0
0x00007f54a9365110  0x00007f54a93848a4  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007f54a86e73f0  0x00007f54a86e7d70  Yes (*)     /lib64/libutil.so.1
0x00007f54a869e4b0  0x00007f54a86d3723  Yes (*)     /lib64/libdw.so.1
0x00007f54a867c690  0x00007f54a868bf95  Yes (*)     /lib64/libelf.so.1
0x00007f54a866d9f0  0x00007f54a8674acd  Yes (*)     /lib64/libpopt.so.0
0x00007f54a8663610  0x00007f54a86670a1  Yes (*)     /lib64/libuuid.so.1
0x00007f54a865c450  0x00007f54a865d333  Yes (*)     /lib64/libgmodule-2.0.so.0
0x00007f54a8551b30  0x00007f54a85d1782  Yes (*)     /lib64/libglib-2.0.so.0
0x00007f54a84c4600  0x00007f54a85192e4  Yes (*)     /lib64/libgmp.so.10
0x00007f54a83dc6f0  0x00007f54a848b866  Yes (*)     /lib64/libboost_regex.so.1.69.0
0x00007f54a83ac530  0x00007f54a83b91e6  Yes (*)     /lib64/libbz2.so.1
0x00007f54a8338390  0x00007f54a8388b7e  Yes (*)     /lib64/libpcre.so.1
0x00007f54a832c710  0x00007f54a832fab0  Yes (*)     /lib64/librt.so.1
--Type <RET> for more, q to quit, c to continue without paging--
0x00007f54a693a040  0x00007f54a693a0f9  Yes (*)     /lib64/libicudata.so.63
0x00007f54a67349f0  0x00007f54a68a4712  Yes (*)     /lib64/libicui18n.so.63
0x00007f54a64e28b0  0x00007f54a65b9587  Yes (*)     /lib64/libicuuc.so.63
0x00007f54a93370d0  0x00007f54a9338b7a  Yes (*)     /usr/lib64/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so <<== HERE
0x00007f54a60dfd90  0x00007f54a61236d2  Yes (*)     /lib64/librpm.so.8
0x00007f54a604f350  0x00007f54a6067294  Yes (*)     /lib64/librpmio.so.8
0x00007f54a5fa0f10  0x00007f54a602d10a  Yes (*)     /lib64/libzstd.so.1
0x00007f54a60c33f0  0x00007f54a60c4e6a  Yes (*)     /lib64/libcap.so.2
0x00007f54a60bb2e0  0x00007f54a60bdf54  Yes (*)     /lib64/libacl.so.1
0x00007f54a5f66b10  0x00007f54a5f89c81  Yes (*)     /lib64/liblua-5.3.so
0x00007f54a5ce0ff0  0x00007f54a5e24b5f  Yes (*)     /lib64/libdb-5.3.so
0x00007f54a5a46000  0x00007f54a5be9070  Yes (*)     /lib64/libcrypto.so.1.1
0x00007f54a5f54550  0x00007f54a5f59561  Yes (*)     /lib64/libnss_sss.so.2
0x00007f54a5f415f0  0x00007f54a5f4792c  Yes (*)     /lib64/libnss_files.so.2
(*): Shared library is missing debugging information.

No sorry .. /usr/lib64/python3.7/lib-dynload/_heapq.cpython-37m-x86_64-linux-gnu.so looks like is loaded by gdb themselves because gdb is using python.

Phew, it took some time to find what was happening here, especially because, coincidentally, the bug has been fixed by a seemingly unrelated commit on March 20th!  This led to a scenario where I was trying upstream GDB and it wasn't failing anymore, but when I to test upstream GDB using the same base commit as the one being used by the current Fedora Rawhide GDB, I started seeing the failure.  I spent a lot of time debugging this against upstream GDB, and wasn't being able to find what was happening.

So, the problem is happening with the following test from libstdcxx:

libstdc++-v3/testsuite/normal1/array.cc
libstdc++-v3/testsuite/normal1/array.gdb (which is generated from array.cc)

If you build GCC's RPM and go into the x86_64-redhat-linux/libstdc++-v3/testsuite/normal1 directory (i.e., the build directory), you can trigger this by doing:

~/build/gdb/gdb --data-directory ~/build/gdb/data-directory/ -nx -nw -q -batch -x ./array.gdb

Anyway, the problem here is that GDB seems to be calling the destructor of Python xmethods after it exit() is called.  This happens in a *very specific* scenario, which I wasn't able to reproduce when I was trying to write a testcase for the bug.  I was able to reduce the array.gdb script to:

file ./array.exe
source /home/sergio/fedora/gcc/gcc-9.0.1-20190312/libstdc++-v3/testsuite/../python/libstdcxx/v6/xmethods.py
python register_libstdcxx_xmethods(None)
break 50
run
whatis a[0]
quit

When I was trying to write a testcase for GDB, I could not reproduce the issue, even though I was following the same steps as above.  I found out that GDB's testsuite invokes a few command when you start GDB, in order to prepare the environment for the test ("set height", "set width", "dir", "kill", etc.), and these commands were preventing the test from being reproduced.  This shows how hard it is for this problem to manifest.

After a lot of investigation, I found that Tom's recent commit:

commit 595915c1c135a77afa01d30a888a48fcc55a08ec
Author: Tom Tromey <tromey>
Date:   Wed Mar 20 07:57:09 2019 -0600

    Merge handle_inferior_event and handle_inferior_event_1

Has actually fixed this problem.  If you look at the commit, you'll see that what it does it basically get rid of handle_inferior_event_1 (which, in turn, gets rid of the "value_mark"/"value_free_to_mark" thing), in favour of using handle_inferior_event directly (which now uses a "scoped_value_mark").  That's enough to fix the issue.

I am now preparing a new Fedora Rawhide GDB release which will contain this commit, and will release it as soon as I finish running the regression test.

OK I think I this commit
http://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=595915c1c135a77afa01d30a888a48fcc55a08ec

Will try to add to gdb and after rebuilding will try to repeat my test with building gcc :)
If it will be ok will close this ticket.

Thank you :)

You might want to wait until I release a new release of the Fedora Rawhide GDB, just in case.

The package is building now, so I'm closing the bug.  Please reopen if you still experience it.  Thanks.

Some more investigation took place, and I have more details to share here.  First, thanks to Tom Tromey, Pedro Alves, Mark Wielaard and Frank Eigler for the help.

Basically, what is happening here is that, for some reason, the Python xmethods objects present in the value chain are being destroyed (i.e., their destructors are being called) while the global destructors are being run.  This, however, happens *after* GDB calls "finalize_python" (due to a "make_final_cleanup (finalize_python, NULL)", which executes "finalize_python" before the global destructors), which is responsible for destroying the Python interpreter.  Why is that important?  Because the Python xmethods's destructors call gdbpy_enter, which try to acquire the Python GIL, which depends on the Python interpreter to still exist.  Therefore, the issue here is that GDB is wrongly depending on the existence of the Python interpreter, which causes a segfault because it doesn't exist anymore.

A few things are still pending investigation here:

- Why does the bug not happen when we insert a non-xmethod value in the value chain?  As explained above, it takes a very specific scenario to trigger this bug.

- Why was "value_free_to_mark" not cleaning up (i.e., destroying) the Python xmethods values?  One theory was that there was an exception being thrown, which was skipping the call to "value_free_to_mark".  However, I investigated and found that no exceptions are thrown.

FYI I'm using at the moment everywhere gdb-8.3.50.20190321-3.fc31.x86_64 and trying to investigate some crashes of the gnome-shell I found that this version of the gdb is crashing on loading gnome-shell core files which only happens when I've started using glib compiled with -DG_DISABLE_CHECKS -DG_DISABLE_ASSERT.

I've not been looking on details of that crash and I generated some call traces data using lldb.
However I've left the laptop which when I've been visiting today my family so only tomorrow will be able to add more details.
Will try to add those details here ASAP.
As far as I remember that call trace it is quite possible that it is something new because bt output this time was quite short but at the moment I'm not 100% sure.

(In reply to Tomasz Kłoczko from comment #26)
> FYI I'm using at the moment everywhere gdb-8.3.50.20190321-3.fc31.x86_64 and
> trying to investigate some crashes of the gnome-shell I found that this
> version of the gdb is crashing on loading gnome-shell core files which only
> happens when I've started using glib compiled with -DG_DISABLE_CHECKS
> -DG_DISABLE_ASSERT.
> 
> I've not been looking on details of that crash and I generated some call
> traces data using lldb.
> However I've left the laptop which when I've been visiting today my family
> so only tomorrow will be able to add more details.
> Will try to add those details here ASAP.
> As far as I remember that call trace it is quite possible that it is
> something new because bt output this time was quite short but at the moment
> I'm not 100% sure.

Please, create another bug for this.