public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/27899] [GNU/Linux, sparc64] GDB crashes when debugging multithreaded programs
Date: Mon, 07 Jun 2021 15:03:28 +0000	[thread overview]
Message-ID: <bug-27899-4717-KSVXuofjvV@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-27899-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=27899

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Simon Marchi <simark@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cfa8e270c9dce83e89b03bc5d793835027731891

commit cfa8e270c9dce83e89b03bc5d793835027731891
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Mon Jun 7 11:03:04 2021 -0400

    gdb: set only inferior_ptid in sparc_{fetch,store}_inferior_registers

    The past commit d1e93af64a6b ("gdb: set current thread in
    sparc_{fetch,collect}_inferior_registers (PR gdb/27147)") changed
    sparc_fetch_inferior_registers and sparc_store_inferior_registers to
    look up the thread corresponding to the regcache's ptid and make it the
    current thread.  The reason being that down the call chain, some
    functions (like sparc_supply_rwindow) can do some memory reads or write,
    through target_read_memory/target_write_memory, and those rely on the
    current global context.

    There is one small problem with this approach: when debugging a
    multi-threaded program, the regcache for a new thread is created just
    before the corresponding thread_info is created.  In fact, the regcache
    is created somewhere during the call to thread_from_lwp, which is
    responsible for creating the thread_info:

        #8  0x0000010000ab9968 in internal_error (file=0x10000bfca20
"/home/simark/src/binutils-gdb/gdb/thread.c", line=1346, fmt=0x10000bfc918 "%s:
Assertion `%s' failed.") at
/home/simark/src/binutils-gdb/gdbsupport/errors.cc:55
        #9  0x0000010000827f3c in switch_to_thread (thr=0x0) at
/home/simark/src/binutils-gdb/gdb/thread.c:1346
        #10 0x0000010000753444 in sparc_fetch_inferior_registers
(proc_target=0x10000fa8cb0 <the_sparc64_linux_nat_target>,
regcache=0x10000ff03c0, regnum=-1) at
/home/simark/src/binutils-gdb/gdb/sparc-nat.c:175
        #11 0x000001000075b908 in sparc64_linux_nat_target::fetch_registers
(this=0x10000fa8cb0 <the_sparc64_linux_nat_target>, regcache=0x10000ff03c0,
regnum=-1) at /home/simark/src/binutils-gdb/gdb/sparc64-linux-nat.c:38
        #12 0x00000100007fe6f4 in target_ops::fetch_registers
(this=0x10000f7feb0 <the_thread_db_target>, arg0=0x10000ff03c0, arg1=-1) at
/home/simark/src/binutils-gdb/gdb/target-delegates.c:496
        #13 0x00000100008162a0 in target_fetch_registers
(regcache=0x10000ff03c0, regno=-1) at
/home/simark/src/binutils-gdb/gdb/target.c:3287
        #14 0x000001000060a4bc in ps_lgetregs (ph=0x10001264368, lwpid=458727,
gregset=0x7feff97d388) at /home/simark/src/binutils-gdb/gdb/proc-service.c:158
        #15 0xffff800103e32420 in __td_ta_lookup_th_unique
(ta_arg=0x100012d7080, lwpid=<optimized out>, th=0x7feff97d7c8) at
td_ta_map_lwp2thr.c:119
        #16 0xffff800103e32604 in td_ta_map_lwp2thr (ta_arg=0x100012d7080,
lwpid=<optimized out>, th=0x7feff97d7c8) at td_ta_map_lwp2thr.c:207
        #17 0x000001000051fee8 in thread_from_lwp (stopped=0x100011a3650,
ptid=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:415
        #18 0x0000010000520150 in thread_db_notice_clone (parent=...,
child=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:446
        #19 0x00000100005068a8 in linux_handle_extended_wait (lp=0x10001230700,
status=4479) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1978
        #20 0x000001000050a278 in linux_nat_filter_event (lwpid=458724,
status=198015) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:2913
        #21 0x000001000050b818 in linux_nat_wait_1 (ptid=...,
ourstatus=0x7feff97e8d0, target_options=...) at
/home/simark/src/binutils-gdb/gdb/linux-nat.c:3194
        #22 0x000001000050ca4c in linux_nat_target::wait (this=0x10000fa8cb0
<the_sparc64_linux_nat_target>, ptid=..., ourstatus=0x7feff97e8d0,
target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3432
        #23 0x00000100005237ec in thread_db_target::wait (this=0x10000f7feb0
<the_thread_db_target>, ptid=..., ourstatus=0x7feff97e8d0, options=...) at
/home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1379
        #24 0x00000100007fa668 in target_wait (ptid=..., status=0x7feff97e8d0,
options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2000
        #25 0x00000100004adb0c in do_target_wait_1 (inf=0x10001173170,
ptid=..., status=0x7feff97e8d0, options=...) at
/home/simark/src/binutils-gdb/gdb/infrun.c:3464
        #26 0x00000100004add48 in operator() (__closure=0x7feff97e658,
inf=0x10001173170) at /home/simark/src/binutils-gdb/gdb/infrun.c:3527
        #27 0x00000100004ae15c in do_target_wait (wait_ptid=...,
ecs=0x7feff97e8a8, options=...) at
/home/simark/src/binutils-gdb/gdb/infrun.c:3540
        #28 0x00000100004af254 in fetch_inferior_event () at
/home/simark/src/binutils-gdb/gdb/infrun.c:3880
        #29 0x0000010000486ef8 in inferior_event_handler
(event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:42

    The problem is that while sparc_fetch_inferior_registers runs and is
    asked to read the registers of a given ptid, there isn't a thread_info
    with that ptid yet.  So, find_thread_ptid returns nullptr, and
    switch_to_thread gives an internal error.

    Fix this by only setting inferior_ptid, instead of the whole global
    context, as switch_to_thread does.  This is sufficient for
    target_read_memory / target_write_memory to work down the line.

    Ideally, it would be nice to be able to pass the ptid down the whole
    call chain and to target_read_memory / target_write_memory, so that this
    setting of inferior_ptid would not be necessary.  But this is not going
    to happen soon.

    This fixes running a multi-threaded program, which would hit the
    internal error show in the call stack above.

    gdb/ChangeLog:

            PR gdb/27899
            * sparc-nat.c (sparc_fetch_inferior_registers): Set
            inferior_ptid instead of using switch_to_thread.
            (sparc_store_inferior_registers): Likewise.

    Change-Id: I0b6ddb3af9b11f67b10ee46a734fb82ecc6462d5

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2021-06-07 15:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22 17:22 [Bug gdb/27899] New: " koachan+sourceware at protonmail dot com
2021-05-22 17:23 ` [Bug gdb/27899] " koachan+sourceware at protonmail dot com
2021-05-23 11:54 ` simark at simark dot ca
2021-05-23 11:54 ` simark at simark dot ca
2021-05-23 13:09 ` simark at simark dot ca
2021-05-23 15:42 ` koachan+sourceware at protonmail dot com
2021-05-25 14:10 ` koachan+sourceware at protonmail dot com
2021-05-27  2:34 ` simark at simark dot ca
2021-05-31  1:17 ` simark at simark dot ca
2021-06-07 15:03 ` cvs-commit at gcc dot gnu.org [this message]
2021-06-07 15:04 ` simark at simark dot ca

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-27899-4717-KSVXuofjvV@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.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).