| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Christian Grothoff:
> I'm seeing some _very_ odd behavior with processes hanging on exit (?)
> with GNU libc 2.28-6 on Debian (amd64 threadripper). This seems to
> happen at random (for random tests, with very low frequency!) in the
> GNUnet (Git master) testsuite when a child process is about to exit.
It looks like you call exit from a signal handler, see
src/util/scheduler.c:
/**
* Signal handler called for signals that should cause us to shutdown.
*/
static void
sighandler_shutdown ()
{
static char c;
int old_errno = errno; /* backup errno */
if (getpid () != my_pid)
exit (1); /* we have fork'ed since the signal handler was created,
* ignore the signal, see https://gnunet.org/vfork discussion */
GNUNET_DISK_file_write (GNUNET_DISK_pipe_handle
(shutdown_pipe_handle, GNUNET_DISK_PIPE_END_WRITE),
&c, sizeof (c));
errno = old_errno;
}
In general, this results in undefined behavior because exit (unlike
_exit) is not an async-signal-safe function.
I suspect you either call the exit function while a fork is in progress,
or since you register this signal handler multiple times for different
signals:
sh->shc_int = GNUNET_SIGNAL_handler_install (SIGINT,
&sighandler_shutdown);
sh->shc_term = GNUNET_SIGNAL_handler_install (SIGTERM,
&sighandler_shutdown);
one call to exit might interrupt another call to exit if both signals
are delivered to the process.
The deadlock you see was introduced in commit
27761a1042daf01987e7d79636d0c41511c6df3c ("Refactor atfork handlers"),
first released in glibc 2.28. The fork deadlock will be gone (in the
single-threaded case) if Debian updates to the current
release/2.28/master branch because we backported commit
60f80624257ef84eacfd9b400bda1b5a5e8e7816 ("nptl: Avoid fork handler lock
for async-signal-safe fork [BZ #24161]") there.
But this will not help you. Even without the deadlock, I expect you
still experience some random corruption during exit, but it's going to
be difficult to spot.
Thanks,
Florian
|
| |
|
|
|
|
|
|
| |
wakeup
time
|
|
|
|
| |
Using the SCHEDULER_add* functions is now allowed before the first call to GNUNET_SCHEDULER_do_work.
|
| |
|
| |
|
| |
|
|
|
|
| |
1st shutdown did not finish the process
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
- GNUNET_SCHEDUELR_run_with_driver has been replaced with
GNUNET_SCHEDULER_driver_init and GNUNET_SCHEDUELR_driver_done
- GNUNET_SCHEDULER_run_from_driver has been renamed to
GNUNET_SCHEDULER_do_work (as it's no longer being called from a driver
callback)
- documentation has been updated
|
| |
|
|
|
|
|
|
|
| |
GNUNET_SCHEDULER_run_from_driver may now be called without any tasks
being ready if the timeout has not been reached yet. A warning is
printed because it may be a programming error in the driver (see
comments)
|
| |
|
|
|
|
| |
This reverts commit d45c008e677fa2fbff03e22745390d4775b031d2.
|
| |
|
|
|
|
| |
The reason field of tasks in the pending_timeout queue is never modified while the tasks are in the queue
|
|
|
|
| |
this shouldn't change anything but makes debugging easier.
|
| |
|
|
|
|
|
|
| |
- add assertions to make sure all tasks have been run or cancelled
- don't cancel all pending tasks during shutdown, only cancel the two
internal tasks scheduled in GNUNET_SCHEDULER_run_with_driver
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 5c4ae18d2e58c8bf3ba60a4f69251e304fbb9915.
|
| |
|
|
|
|
|
| |
There's no need of checking for timeouts in GNUNET_SCHEDULER_task_ready,
as the check is done in GNUNET_SCHEDULER_run_from_driver.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
network/file handles
|
|
|
|
| |
This reverts commit 201a67be13ae31b4eb7fb8ad38b349fe287c0baf.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The select loop has to keep running as long as the driver has tasks
available (indicating that there are file descriptors left to wait for)
or the timeout is not FOREVER (indicating that the scheduler has tasks
with timeout left).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Busy waiting should never happen (at least the shutdown pipe is always
there for the driver to wait for).
When busy waiting happens, i.e. GNUNET_SCHEDULER_run_from_driver is
called without any task ready, it is a programming error (at least I
don't know any valid use case for busy waiting).
Hence, remove the busy waiting checks and let
GNUNET_SCHEDULER_run_from_driver return GNUNET_SYSERR instead in this
case.
|
| |
|
|
|
|
|
|
|
|
|
| |
The driver callback for deleting a task has been simplified: Now it is
only possible to delete a task, not single FdInfos.
A logic bug in GNUNET_SCHEDULER_cancel has been fixed (FD-related tasks
need to be deleted from the driver, when they are already in the ready
queue).
|
|
|
|
|
|
| |
if GNUNET_SCHEDULER_add_select is called with empty fdsets, the
resulting task is now added to the pending_timeout queue instead of
the pending queue. This way the driver will not know about the task.
|
| |
|