mirror/binutils-gdb
2
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2025-02-05 12:53:16 +08:00
Code Issues Packages Projects Releases Wiki Activity
96,368 Commits 391 Branches 138 Tags 627 MiB
C 51.3%
Makefile 22.7%
Assembly 12.5%
C++ 5.9%
Roff 1.4%
Other 5.6%
2eab46b176
Go to file
Joel Brobecker 2eab46b176 GDB crash re-running program on Windows (native) 
Running any program twice on Windows current results in GDB crashing:

    $ gdb -q any_program
    (gdb) run
    $ gdb dummy -batch -ex run -ex run
    [New Thread 684960.0xe5878]
    [New Thread 684960.0xd75ac]
    [New Thread 684960.0xddac8]
    [New Thread 684960.0xc1f50]
    [Thread 684960.0xd75ac exited with code 0]
    [Thread 684960.0xddac8 exited with code 0]
    [Thread 684960.0xc1f50 exited with code 0]
    [Inferior 1 (process 684960) exited normally]
    (gdb) run
    Segmentation fault

The crash happens while processing the CREATE_PROCESS_DEBUG_EVENT
for  the second run; in particular, we have in get_windows_debug_event:

    | case CREATE_PROCESS_DEBUG_EVENT:
    |   [...]
    |   if (main_thread_id)
    |     windows_delete_thread (ptid_t (current_event.dwProcessId, 0,
    |                                    main_thread_id),
    |                            0);

The problem is that main_thread_id is the TID of the main thread from
the *previous* inferior, and this code is trying to delete that
thread. The problem is that it is constructing a PTID by pairing
the TID of the previous inferior with the PID of the new inferior.
As a result, when we dig inside windows_delete_thread to see
how it would handle that, we see...

    | delete_thread (find_thread_ptid (ptid));

Since the PTID is bogus, we end up calling delete_thread with
a NULL thread_info. It used to be harmless, turning the delete_thread
into a nop, but the following change...

    | commit 0803633106
    | Date:   Thu Nov 22 16:09:14 2018 +0000
    | Subject: Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc.

... changed delete_thread to get the list of threads from
the inferior, which itself is now accessed via the given
thread_info. This is the corresponding diff that shows the change:

    | -  for (tp = thread_list; tp; tpprev = tp, tp = tp->next)
    | +  for (tp = thr->inf->thread_list; tp; tpprev = tp, tp = tp->next)

As a result of this, passing a NULL thread_info is no longer
an option!

Stepping back a bit, the reason behind deleting the thread late
could be found in a patch from Dec 2003, which laconically explains:

    | commit 87a45c9606
    | Date:   Fri Dec 26 00:39:04 2003 +0000
    |
    | * win32-nat.c (get_child_debug_event): Keep main thread id around
    | even after thread exits since Windows insists on continuing to
    | report events against it.

A look at the gdb-patches archives did not provide any additional
clues (https://www.sourceware.org/ml/gdb-patches/2003-12/msg00478.html).
It is not clear whether this is still needed or not. This patch
assumes that whatever isue there was, the versions of Windows
we currently support no longer have it.

With that in mind, this commit fixes the issue by deleting the thread
when the inferior sends the exit-process event as opposed to deleting it
later, while starting a new inferior.

This also restores the printing of the thread-exit notification for
the main thread, which was missing before. Looking at the transcript
of the example shown above, we can see 4 thread creation notifications,
and only 3 notifications for thread exits. Now creation and exit
notifications are balanced.

In the handling of EXIT_THREAD_DEBUG_EVENT, the main_thread_id
check is removed because deemed unnecessary: The main thread was
introduced by a CREATE_PROCESS_DEBUG_EVENT, and thus the kernel
is expected to report its death via EXIT_PROCESS_DEBUG_EVENT.

And finally, because the behavior of delete_thread did change
(albeit when getting a value we probably never expected to receive),
this patch also adds a gdb_assert. The purpose is to provide some
immediate information in case there are other callers that mistakenly
call delete_thread with a NULL thread info. This can be useful
information when direct debugging of GDB isn't an option.

gdb/ChangeLog:

	* thread.c (delete_thread_1): Add gdb_assert that THR is not
	NULL. Initialize tpprev to NULL instead of assigning it
	to NULL on the next statement.
	* windows-nat.c (windows_delete_thread): Remove check for
	main_thread_id before printing thread exit notifications.
	(get_windows_debug_event) <EXIT_THREAD_DEBUG_EVENT>:
	Remove thread ID check against main_thread_id.
	<CREATE_PROCESS_DEBUG_EVENT>: Remove call to
	windows_delete_thread.
	<EXIT_PROCESS_DEBUG_EVENT>: Add call to windows_delete_thread.
2019-01-05 11:55:08 +04:00
bfd Automatic date update in version.in 2019-01-05 00:00:37 +00:00
binutils Fix a possible integer overflow problem when examining corrupt binaries using a 32-bit binutil. 2019-01-04 13:44:34 +00:00
config
contrib
cpu
elfcpp
etc
gas Fix potential buffer overrun whilst scanning macro strings. 2019-01-04 16:18:59 +00:00
gdb GDB crash re-running program on Windows (native) 2019-01-05 11:55:08 +04:00
gold
gprof
include
intl
ld
libdecnumber
libiberty
opcodes
readline
sim
texinfo
zlib
.cvsignore
.gitattributes
.gitignore
ar-lib
ChangeLog
compile
config-ml.in
config.guess
config.rpath
config.sub
configure
configure.ac
COPYING
COPYING3
COPYING3.LIB
COPYING.LIB
COPYING.LIBGLOSS
COPYING.NEWLIB
depcomp
djunpack.bat
install-sh
libtool.m4
lt~obsolete.m4
ltgcc.m4
ltmain.sh
ltoptions.m4
ltsugar.m4
ltversion.m4
MAINTAINERS
Makefile.def
Makefile.in
Makefile.tpl
makefile.vms
missing
mkdep
mkinstalldirs
move-if-change
multilib.am
README
README-maintainer-mode
setup.com
src-release.sh
symlink-tree
test-driver
ylwrap

README 

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.