| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
in service.c
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Newer GCCs do not like truncation and emit a warning. We don't want to
disable truncation warnings (-Wnostringop-truncation), as in some cases
these warnings can point to a security flaw.
Using strcat instead of strncat is fine, since *both* equally overflow
the destination buffer if not used carefully.
See https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/
|
| |
|
| |
|
| |
|
|
|
|
| |
fix the error message in the wrong place
|
|
|
|
| |
the README.
|
| |
|
| |
|
| |
|
|
|
|
| |
should satisfy safety checks
|
| |
|
| |
|
|\ |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent versions of gcc on some architectures (MIPS, PPC, ...) moved
atomic functions into a separate library. As we are using atomic
load/store in util/time.c we may need to link libgnunetutil against
libatomic for __atomic_load_8 and __atomic_store_8 to be defined.
Fixes build problem on MIPS:
ld: ./.libs/libgnunetutil.so: undefined reference to `__atomic_store_8'
ld: ./.libs/libgnunetutil.so: undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
|
| |
|
|
|
|
| |
possible, closing that one
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
python2.7 script.
|
|
|
|
|
|
| |
for gnunet-qr with an incredible annoying workaround for autotools inability to deal with 2 major python versions at the same time
Signed-off-by: ng0 <ng0@n0.is>
|
| |
|
|\ |
|
| | |
|
| | |
|
|/
|
|
| |
Signed-off-by: ng0 <ng0@n0.is>
|
| |
|
| |
|
|
|
|
| |
Give GNUNET_FORCE_LOG priority over GNUNET_LOG.
|
|
|
|
| |
- Add compat memrchr layer for Win32 and macOS
|
| |
|
| |
|