| Commit message (Collapse) | Author | Age |
|
|
|
| |
work
|
| |
|
| |
|
|
|
|
| |
least 5
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
files.
configures and builds okay.
testsuite wasn't checked, will be checked.
diff including the plibc removal is now around 14370 lines of code less.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Without entering an asynchronous scope, logs are the same before. When
entering an asynchronous scope (either thread-based of
scheduler/task-based), all log lines within an asynchronous scope
contain its ID.
Currently this is only used in GNU Taler, for debugging requests across
multiple services. This allows us to get all log lines pertaining to a
particular request for a user or another service.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|