From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
To: Pedro Alves <pedro@palves.net>, gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH 8/8] gdb: resume ongoing step after handling fork or vfork
Date: Fri, 1 Apr 2022 14:42:45 -0400 [thread overview]
Message-ID: <91b49c61-5371-0d12-5a3a-121500fe2cd6@polymtl.ca> (raw)
In-Reply-To: <697452b1-271b-8802-1403-936e1b6bc706@palves.net>
>> +#include <pthread.h>
>> +#include <unistd.h>
>> +#include <sys/types.h>
>> +#include <sys/wait.h>
>> +#include <errno.h>
>> +#include <assert.h>
>> +#include <limits.h>
>> +
>> +/* Number of threads doing forks. */
>> +#define N_FORKERS 4
>> +
>> +static void *
>> +forker (void *arg)
>> +{
>> + for (;;)
>> + {
>> + pid_t pid = FORK_FUNC ();
>> +
>> + if (pid == 0)
>> + _exit(11);
>
> Missing space before parens.
Done.
>
>> +
>> + assert (pid > 0);
>> +
>> + /* Wait for children to exit. */
>> + int ret;
>> + int stat;
>> + do {
>
> { on the next line. Thus:
Done (and re-indented the whole do-while). Is there a missing part to
your comment that should come after "Thus:"?
>
>> + ret = waitpid (pid, &stat, 0);
>> + } while (ret == EINTR);
>> +
>> + assert (ret == pid);
>> + assert (WIFEXITED (stat));
>> + assert (WEXITSTATUS (stat) == 11);
>> +
>> + usleep (40 * 1000);
>
> Why not sleep_a_bit()? Is the fact that it's a little less time significant?
Ah, good question. We need the forking threads to fork reasonably
often, if we want the bug to reproduce most of the time. But we need
some sleep, with any sleep the forking threads just spam events and
starve the stepping thread, and we don't really make progress. I'll add
a comment to that effect.
>
>> + }
>> +
>> + return NULL;
>> +}
>> +
>> +static void
>> +sleep_a_bit (void)
>> +{
>> + usleep (1000 * 50);
>> +}
>> +
>> +int
>> +main (void)
>> +{
>> + alarm (60);
>> +
>> + pthread_t thread[N_FORKERS];
>> + for (int i = 0; i < N_FORKERS; ++i)
>
> Declare "int i" outside the loop so this compiles as C90 as well. Ditto below.
Done.
Simon
prev parent reply other threads:[~2022-04-01 18:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-17 16:27 [PATCH 0/8] Some fixes for handling vfork by multi-threaded programs Simon Marchi via Gdb-patches
2022-01-17 16:27 ` [PATCH 1/8] gdb/infrun: add reason parameter to stop_all_threads Simon Marchi via Gdb-patches
2022-03-31 15:05 ` Pedro Alves
2022-03-31 15:35 ` Simon Marchi via Gdb-patches
2022-01-17 16:27 ` [PATCH 2/8] gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait Simon Marchi via Gdb-patches
2022-03-31 16:12 ` Pedro Alves
2022-03-31 17:06 ` Simon Marchi via Gdb-patches
2022-01-17 16:27 ` [PATCH 3/8] gdb: replace inferior::waiting_for_vfork_done with inferior::thread_waiting_for_vfork_done Simon Marchi via Gdb-patches
2022-03-31 18:17 ` Pedro Alves
2022-04-01 14:25 ` Simon Marchi via Gdb-patches
2022-01-17 16:27 ` [PATCH 4/8] gdb/infrun: add inferior parameters to stop_all_threads and restart_threads Simon Marchi via Gdb-patches
2022-03-31 18:17 ` Pedro Alves
2022-01-17 16:27 ` [PATCH 5/8] gdb/infrun: add logging statement to do_target_resume Simon Marchi via Gdb-patches
2022-03-31 18:18 ` Pedro Alves
2022-01-17 16:27 ` [PATCH 6/8] gdb: fix handling of vfork by multi-threaded program (follow-fork-mode=parent, detach-on-fork=on) Simon Marchi via Gdb-patches
2022-03-31 18:21 ` Pedro Alves
2022-04-01 17:28 ` Simon Marchi via Gdb-patches
2022-01-17 16:27 ` [PATCH 7/8] gdbserver: report correct status in thread stop race condition Simon Marchi via Gdb-patches
2022-03-31 18:21 ` Pedro Alves
2022-01-17 16:27 ` [PATCH 8/8] gdb: resume ongoing step after handling fork or vfork Simon Marchi via Gdb-patches
2022-03-31 18:22 ` Pedro Alves
2022-03-31 18:28 ` Pedro Alves
2022-04-01 18:42 ` Simon Marchi via Gdb-patches [this message]
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=91b49c61-5371-0d12-5a3a-121500fe2cd6@polymtl.ca \
--to=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
--cc=simon.marchi@efficios.com \
--cc=simon.marchi@polymtl.ca \
/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