public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: sergiodj+buildbot@redhat.com
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] [LynxOS] GDBserver crash debugging threaded program
Date: Mon, 23 Nov 2015 18:24:00 -0000	[thread overview]
Message-ID: <80d82c196402f6a61aa84452104b9aaed364eb42@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 80d82c196402f6a61aa84452104b9aaed364eb42 ***

Author: Joel Brobecker <brobecker@adacore.com>
Branch: master
Commit: 80d82c196402f6a61aa84452104b9aaed364eb42

[LynxOS] GDBserver crash debugging threaded program

This crash is observable by debugging a threaded program on LynxOS.
On the GDB side, this is what we would see:

    % gdb q
    (gdb) target remote machine:4444
    (gdb) break q.adb:6
    (gdb) cont
    [gdb hits breakpoint]
    (gdb) cont
    Remote connection closed    <<<--- expected: [Inferior 1 (Remote target) exited normally]

On the gdbserver side, which was launched as usual:

    % gdbserver --once :4444 q
    Segmentation fault (core dumped)

Ooops!

The problem happens while GDB is trying to handle the thread termination
event of the thread that hit the breakpoint. It started happening after
the following change was made:

    commit 96e7a1eb6d09fda9e22e112e35e7d0085a8f4fd0
    Date:   Fri Oct 16 11:08:38 2015 -0400
    Subject: gdbserver: Reset current_thread when the thread is removed.

    Reset current_thread and make sure 'remove_process' is used
    after all associated threads have been removed first.

More precisely:

  . GDBserver receives the execution-resume order;

  . lynx-low resumes it succesfully, and then relies on lynx_wait_1
    to wait for the next event;

  . We quickly receive one, which lynx_wait_1 analyzes to be
    a "thread exit" event, and therefore does...

          case SIGTHREADEXIT:
            remove_thread (find_thread_ptid (new_ptid));
            lynx_continue (new_ptid);
            goto retry;

    => remove_thread causes current_thread to be set to NULL...
       (that's the recent change mentioned above)

    => ... which causes problems during lynx_continue, because
       it calls lynx_resume, which calls regcache_invalidate,
       which unfortunately assumes that CURRENT_THREAD is not NULL:

        void
        regcache_invalidate (void)
        {
          /* Only update the threads of the current process.  */
SEGV!-->  int pid = ptid_get_pid (current_thread->entry.id);

          find_inferior (&all_threads, regcache_invalidate_one, &pid);
        }

Since the problem at hand is caused by trying to figure out which
inferior to reset the regcache for, and since lynx_resume actually
had that info, this patch fixes the problem by introducing a new
routine called regcache_invalidate_pid, which invalidates the cache
of the given pid; and then modifies lynx_resume use that new routine
rather than relying on regcache_invalidate to invalidate the regcache
of the expected inferior.

gdb/gdbserver/ChangeLog:

        * regcache.h (regcache_invalidate_pid): Add declaration.
        * regcache.c (regcache_invalidate_pid): New function, extracted
        from regcache_invalidate.
        (regcache_invalidate): Reimplement using regcache_invalidate_pid.
        Add trivial documentation comment.
        * lynx-low.c: Use regcache_invalidate_pid instead of
        regcache_invalidate.


             reply	other threads:[~2015-11-23 18:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 18:24 sergiodj+buildbot [this message]
2015-11-23 18:26 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot
2015-11-23 19:40 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2015-11-23 19:50 ` Failures on Debian-s390x-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-11-23 20:19 ` Failures on AIX-POWER7-plain, " sergiodj+buildbot
2015-11-23 21:13 ` Failures on Fedora-s390x-m64, " sergiodj+buildbot
2015-11-23 21:48 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2015-11-23 21:54 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot
2015-11-23 22:06 ` Failures on Debian-i686, " sergiodj+buildbot
2015-11-23 22:06 ` Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot
2015-11-23 22:24 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2015-11-23 22:37 ` Failures on Debian-i686-native-gdbserver, " sergiodj+buildbot
2015-11-23 22:50 ` Failures on Debian-i686-native-extended-gdbserver, " sergiodj+buildbot
2015-11-23 23:05 ` Failures on Debian-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2015-11-23 23:42 ` Failures on Fedora-ppc64be-native-gdbserver-m64, " sergiodj+buildbot
2015-11-23 23:58 ` Failures on Fedora-ppc64be-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-11-24  1:23 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot
2015-11-24  2:03 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot

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=80d82c196402f6a61aa84452104b9aaed364eb42@gdb-build \
    --to=sergiodj+buildbot@redhat.com \
    --cc=gdb-testers@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).