| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
These functions are copied from dns/gnunet-helper-dns.c,
move them into a common library.
Or think about implementing a even more elaborate version.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Still to-do:
* running gnunet-uri
* Proper error handling
* integration into build system (automake)
Reimplementing in C was chosen since
- official zbar python-bindings support python 2 only,
- none of the other bindings available at PyPI supports the high-level
"processor" interface which gnunet-qr uses
- implementing bindings for zbar using ctypes required addin a lot of
low-level error handling code, thus implementing in C seamed to be
easier,
- the programm is short, thus re-implementing is not such complicated, and
- this allows to reduce the number of dependencies (here: another
Python version), which should ease porting to other plattforms (zbar
is a dependency anyway).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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>
|
