Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: RFA: Make sigthread.exp more reliable
Date: Sat, 12 Jan 2008 01:32:00 -0000	[thread overview]
Message-ID: <m33at3vng0.fsf@codesourcery.com> (raw)


sigthread.exp fails intermittently, because the program exits due to a
segfault instead of the ^C GDB sends it.  I believe this is because
the threads throwing signals at each other don't wait until all the
pthread_t variables are initialized before they do so.  So they
occasionally pass an uninitialized pthread_t to pthread_kill, which
segfaults.

This patch uses barriers to make sure everyone's ready to go before
the fun begins.  Although barriers were not in the original POSIX
threads spec, they have been in the GNU C library since version 2.2,
released in 2000.  When barriers are not present, the test reports
itself as "UNSUPPORTED".

Is this okay?

gdb/testsuite/ChangeLog:
2008-01-11  Jim Blandy  <jimb@codesourcery.com>

	* gdb.threads/sigthread.c: Use barriers to ensure that
	child_thread and child_thread_two are always initialized before we
	start to use them.

diff -r a4b196da8237 -r 15f7131243ac gdb/testsuite/gdb.threads/sigthread.c
--- a/gdb/testsuite/gdb.threads/sigthread.c	Fri Jan 11 14:54:31 2008 -0800
+++ b/gdb/testsuite/gdb.threads/sigthread.c	Fri Jan 11 17:15:53 2008 -0800
@@ -20,6 +20,8 @@
    testing.  */
 #define NSIGS 10000000
 
+pthread_barrier_t barrier;
+
 void
 handler (int sig)
 {
@@ -34,6 +36,8 @@ child_two (void *arg)
 {
   int i;
 
+  pthread_barrier_wait (&barrier);
+
   for (i = 0; i < NSIGS; i++)
     pthread_kill (child_thread, SIGUSR1);
 }
@@ -42,6 +46,8 @@ thread_function (void *arg)
 thread_function (void *arg)
 {
   int i;
+
+  pthread_barrier_wait (&barrier);
 
   for (i = 0; i < NSIGS; i++)
     pthread_kill (child_thread_two, SIGUSR2);
@@ -54,9 +60,13 @@ int main()
   signal (SIGUSR1, handler);
   signal (SIGUSR2, handler);
 
+  pthread_barrier_init (&barrier, NULL, 3);
+
   main_thread = pthread_self ();
   pthread_create (&child_thread, NULL, thread_function, NULL);
   pthread_create (&child_thread_two, NULL, child_two, NULL);
+
+  pthread_barrier_wait (&barrier);
 
   for (i = 0; i < NSIGS; i++)
     pthread_kill (child_thread_two, SIGUSR1);


             reply	other threads:[~2008-01-12  1:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-12  1:32 Jim Blandy [this message]
2008-01-29 18:14 ` Daniel Jacobowitz
2008-01-29 19:28   ` Jim Blandy

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=m33at3vng0.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=gdb-patches@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