Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hey! On Tue, Apr 30, 2019 at 08:18:25PM +1000, Stewart Smith wrote: > Have I sneakily tried to make you maintainer yet? :) one day somebody > will fall for it :) You already tried a couple of times. I'm already weary of it ;) > Quick look at the patch looks sane, I’ll do the merge things when home > and in front of the laptop with the right github credentials to do so. Did you have a chance to look at the various patches around (remember, also the ones in the 2 launchpad MRs against the bzr tree, not just this one)? :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hi! Have I sneakily tried to make you maintainer yet? :) one day somebody will fall for it :) Quick look at the patch looks sane, I’ll do the merge things when home and in front of the laptop with the right github credentials to do so. Sent from my iPhone > On 29 Apr 2019, at 04:25, Alberto Bertogli wrote: > >> On Sun, Apr 28, 2019 at 11:25:22AM +0200, Mattia Rizzolo wrote: >>> On Mon, Jan 28, 2019 at 05:07:34PM +, Alberto Bertogli wrote: >>> As far as I can see, this is caused by a bug/race in libeatmydata's >>> initialization, as described before. >>> >>> It is not a problem in libfiu, or its tests. >>> >>> >>> The attached patch for libeatmydata fixes the issue, but it's mostly for >>> illustration since I don't know how the maintainers would prefer to fix >>> this, and I have not tested it thoroughly (for example there's a chance of >>> infinite recursion in some very odd conditions, but it might be better to >>> leave it on purpose to ease debuggability). >> >> I fail to see those, could you maybe expand on where you think there >> could be infinite recursions? > > Looking at this again, and digging around my git repository, I think I wrote > this note based on a previous iteration of the patch. > > I think the patch in your email fixes the problems I was originally worried > about, and can't find any infinite recursion paths right now. > > Sorry for the confusion! > > Thanks! >Alberto >
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Sun, Apr 28, 2019 at 11:25:22AM +0200, Mattia Rizzolo wrote: On Mon, Jan 28, 2019 at 05:07:34PM +, Alberto Bertogli wrote: As far as I can see, this is caused by a bug/race in libeatmydata's initialization, as described before. It is not a problem in libfiu, or its tests. The attached patch for libeatmydata fixes the issue, but it's mostly for illustration since I don't know how the maintainers would prefer to fix this, and I have not tested it thoroughly (for example there's a chance of infinite recursion in some very odd conditions, but it might be better to leave it on purpose to ease debuggability). I fail to see those, could you maybe expand on where you think there could be infinite recursions? Looking at this again, and digging around my git repository, I think I wrote this note based on a previous iteration of the patch. I think the patch in your email fixes the problems I was originally worried about, and can't find any infinite recursion paths right now. Sorry for the confusion! Thanks! Alberto
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hi Stewart,
It has been a while :)
It seems that libeatmydata has some problems with multi-threading, that
I think were known to potentially arise, and it seems they now did.
Alberto (CCed) wrote a patch that looks mostly sane to me that ought to
be able to fix this issue; do you think you could merge it upstream?
On Mon, Jan 28, 2019 at 05:07:34PM +, Alberto Bertogli wrote:
> As far as I can see, this is caused by a bug/race in libeatmydata's
> initialization, as described before.
>
> It is not a problem in libfiu, or its tests.
>
>
> The attached patch for libeatmydata fixes the issue, but it's mostly for
> illustration since I don't know how the maintainers would prefer to fix
> this, and I have not tested it thoroughly (for example there's a chance of
> infinite recursion in some very odd conditions, but it might be better to
> leave it on purpose to ease debuggability).
I fail to see those, could you maybe expand on where you think there
could be infinite recursions?
> https://blitiri.com.ar/tmp/eatmydata-safe-init.patch
I'm also attaching it to this email for Stewart's benefit.
Stewart: [OT] I see that
https://bugs.launchpad.net/libeatmydata/+bug/1556410 is also still open,
could you please merge that? (I noticed that you moved to git, so maybe
you could manually pull that patch in, and close the MR?).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
From 72a074fde1b722a3e784a3648a34cd58c3196598 Mon Sep 17 00:00:00 2001
From: Alberto Bertogli
Date: Mon, 28 Jan 2019 15:39:31 +
Subject: [PATCH] Make initialization thread-safe, and support early callers
The current initialization code is not thread-safe, and assumes that the
only possible caller of open() before initialization completes is
dlsym(), which is not the case if there are other preloaded libraries.
This patch makes the initialization thread-safe by using thread-local
variables, and adjusts the recursive checking logic to support early
callers.
See Debian bug #918520 for more background:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918520
---
configure.ac| 2 +
libeatmydata/libeatmydata.c | 39 ++-
m4/ax_tls.m4| 74 +
3 files changed, 98 insertions(+), 17 deletions(-)
create mode 100644 m4/ax_tls.m4
diff --git a/configure.ac b/configure.ac
index 7343e0a..140387a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,8 @@ AC_CHECK_DECLS(sync_file_range)
AC_CHECK_FUNCS(sync_file_range)
AC_CHECK_FUNCS(open64)
+AX_TLS(:,:)
+
AC_CONFIG_FILES(Makefile libeatmydata.spec)
AC_OUTPUT
diff --git a/libeatmydata/libeatmydata.c b/libeatmydata/libeatmydata.c
index 991146b..b54a98b 100644
--- a/libeatmydata/libeatmydata.c
+++ b/libeatmydata/libeatmydata.c
@@ -50,19 +50,23 @@ typedef int (*libc_sync_file_range_t)(int, off64_t, off64_t, unsigned int);
typedef int (*libc_fcntl_t)(int, int, ...);
#endif
-static libc_open_t libc_open= NULL;
+/* All the following are thread-local, to avoid initialization races between
+ * threads. */
+static TLS int init_running = 0;
+static TLS int init_complete = 0;
+static TLS libc_open_t libc_open= NULL;
#ifdef HAVE_OPEN64
-static libc_open64_t libc_open64= NULL;
+static TLS libc_open64_t libc_open64= NULL;
#endif
-static libc_fsync_t libc_fsync= NULL;
-static libc_sync_t libc_sync= NULL;
-static libc_fdatasync_t libc_fdatasync= NULL;
-static libc_msync_t libc_msync= NULL;
+static TLS libc_fsync_t libc_fsync= NULL;
+static TLS libc_sync_t libc_sync= NULL;
+static TLS libc_fdatasync_t libc_fdatasync= NULL;
+static TLS libc_msync_t libc_msync= NULL;
#ifdef HAVE_SYNC_FILE_RANGE
-static libc_sync_file_range_t libc_sync_file_range= NULL;
+static TLS libc_sync_file_range_t libc_sync_file_range= NULL;
#endif
#if defined(F_FULLFSYNC) && defined(__APPLE__)
-static libc_fcntl_t libc_fcntl= NULL;
+static TLS libc_fcntl_t libc_fcntl= NULL;
#endif
#define ASSIGN_DLSYM_OR_DIE(name) \
@@ -87,7 +91,7 @@ void __attribute__ ((constructor)) eatmydata_init(void);
void __attribute__ ((constructor)) eatmydata_init(void)
{
- initing = 1;
+ init_running++;
ASSIGN_DLSYM_OR_DIE(open);
#ifdef HAVE_OPEN64
ASSIGN_DLSYM_OR_DIE(open64);
@@ -102,13 +106,14 @@ void __attribute__ ((constructor)) eatmydata_init(void)
#if defined(F_FULLFSYNC) && defined(__APPLE__)
ASSIGN_DLSYM_OR_DIE(fcntl);
#endif
- initing = 0;
+ init_running--;
+ init_complete++;
}
static int eatmydata_is_hungry(void)
{
/* Init here, as it is called before any libc functions */
- if(!libc_open)
+ if(!init_complete)
eatmydata_init();
#ifdef CHECK_FILE
@@ -164,9 +169,9 @@ int LIBEATMYDATA_API open(const char* pathname, int flags, ...)
#endif
Bug#918520: Lack of thread safety (in eatmydata_init?) causes non-deterministic behaviour (was: "Re: Bug#918520: libfiu: FTBFS randomly when built with eatmydata")
retitle 918520 Lack of thread safety (in eatmydata_init?) causes non-deterministic behaviour affects 918520 + libfiu thanks Hi Santiago, > > Any further thoughts folks? > > Based on everything Alberto said, should this bug not be reassigned to > eatmydata? That's probably right. Doing so now. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Sun, Feb 03, 2019 at 08:50:48AM +0100, Chris Lamb wrote: > Chris Lamb wrote: > > > > I'll dig in a bit more and see if I can fix libeatmydata, but it might > > > end up being too invasive and time consuming. I'll send another message > > > once I know more. > > > > Oh, nice analysis so far. Sounds like that needs to get (at least > > copied...) upstream at the very least so that it doesn't > > accidentally lost in this "branch" bug report. > > > > (Probably has implications for other packages that Santiago is > > testing too, naturally…) > > Any further thoughts folks? :) Based on everything Alberto said, should this bug not be reassigned to eatmydata? Thanks.
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Chris Lamb wrote: > > I'll dig in a bit more and see if I can fix libeatmydata, but it might > > end up being too invasive and time consuming. I'll send another message > > once I know more. > > Oh, nice analysis so far. Sounds like that needs to get (at least > copied...) upstream at the very least so that it doesn't > accidentally lost in this "branch" bug report. > > (Probably has implications for other packages that Santiago is > testing too, naturally…) Any further thoughts folks? :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hi Alberto, > I'll dig in a bit more and see if I can fix libeatmydata, but it might > end up being too invasive and time consuming. I'll send another message > once I know more. Oh, nice analysis so far. Sounds like that needs to get (at least copied...) upstream at the very least so that it doesn't accidentally lost in this "branch" bug report. (Probably has implications for other packages that Santiago is testing too, naturally…) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Mon, Jan 28, 2019 at 03:13:46PM +, Alberto Bertogli wrote:
I'll dig in a bit more and see if I can fix libeatmydata, but it might
end up being too invasive and time consuming. I'll send another
message once I know more.
As far as I can see, this is caused by a bug/race in libeatmydata's
initialization, as described before.
It is not a problem in libfiu, or its tests.
The attached patch for libeatmydata fixes the issue, but it's mostly for
illustration since I don't know how the maintainers would prefer to fix
this, and I have not tested it thoroughly (for example there's a chance
of infinite recursion in some very odd conditions, but it might be
better to leave it on purpose to ease debuggability).
https://blitiri.com.ar/tmp/eatmydata-safe-init.patch
Thanks!
Alberto
>From 72a074fde1b722a3e784a3648a34cd58c3196598 Mon Sep 17 00:00:00 2001
From: Alberto Bertogli
Date: Mon, 28 Jan 2019 15:39:31 +
Subject: [PATCH] Make initialization thread-safe, and support early callers
The current initialization code is not thread-safe, and assumes that the
only possible caller of open() before initialization completes is
dlsym(), which is not the case if there are other preloaded libraries.
This patch makes the initialization thread-safe by using thread-local
variables, and adjusts the recursive checking logic to support early
callers.
See Debian bug #918520 for more background:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918520
---
configure.ac| 2 +
libeatmydata/libeatmydata.c | 39 ++-
m4/ax_tls.m4| 74 +
3 files changed, 98 insertions(+), 17 deletions(-)
create mode 100644 m4/ax_tls.m4
diff --git a/configure.ac b/configure.ac
index 7343e0a..140387a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,8 @@ AC_CHECK_DECLS(sync_file_range)
AC_CHECK_FUNCS(sync_file_range)
AC_CHECK_FUNCS(open64)
+AX_TLS(:,:)
+
AC_CONFIG_FILES(Makefile libeatmydata.spec)
AC_OUTPUT
diff --git a/libeatmydata/libeatmydata.c b/libeatmydata/libeatmydata.c
index 991146b..b54a98b 100644
--- a/libeatmydata/libeatmydata.c
+++ b/libeatmydata/libeatmydata.c
@@ -50,19 +50,23 @@ typedef int (*libc_sync_file_range_t)(int, off64_t, off64_t, unsigned int);
typedef int (*libc_fcntl_t)(int, int, ...);
#endif
-static libc_open_t libc_open= NULL;
+/* All the following are thread-local, to avoid initialization races between
+ * threads. */
+static TLS int init_running = 0;
+static TLS int init_complete = 0;
+static TLS libc_open_t libc_open= NULL;
#ifdef HAVE_OPEN64
-static libc_open64_t libc_open64= NULL;
+static TLS libc_open64_t libc_open64= NULL;
#endif
-static libc_fsync_t libc_fsync= NULL;
-static libc_sync_t libc_sync= NULL;
-static libc_fdatasync_t libc_fdatasync= NULL;
-static libc_msync_t libc_msync= NULL;
+static TLS libc_fsync_t libc_fsync= NULL;
+static TLS libc_sync_t libc_sync= NULL;
+static TLS libc_fdatasync_t libc_fdatasync= NULL;
+static TLS libc_msync_t libc_msync= NULL;
#ifdef HAVE_SYNC_FILE_RANGE
-static libc_sync_file_range_t libc_sync_file_range= NULL;
+static TLS libc_sync_file_range_t libc_sync_file_range= NULL;
#endif
#if defined(F_FULLFSYNC) && defined(__APPLE__)
-static libc_fcntl_t libc_fcntl= NULL;
+static TLS libc_fcntl_t libc_fcntl= NULL;
#endif
#define ASSIGN_DLSYM_OR_DIE(name) \
@@ -87,7 +91,7 @@ void __attribute__ ((constructor)) eatmydata_init(void);
void __attribute__ ((constructor)) eatmydata_init(void)
{
- initing = 1;
+ init_running++;
ASSIGN_DLSYM_OR_DIE(open);
#ifdef HAVE_OPEN64
ASSIGN_DLSYM_OR_DIE(open64);
@@ -102,13 +106,14 @@ void __attribute__ ((constructor)) eatmydata_init(void)
#if defined(F_FULLFSYNC) && defined(__APPLE__)
ASSIGN_DLSYM_OR_DIE(fcntl);
#endif
- initing = 0;
+ init_running--;
+ init_complete++;
}
static int eatmydata_is_hungry(void)
{
/* Init here, as it is called before any libc functions */
- if(!libc_open)
+ if(!init_complete)
eatmydata_init();
#ifdef CHECK_FILE
@@ -164,9 +169,9 @@ int LIBEATMYDATA_API open(const char* pathname, int flags, ...)
#endif
va_end(ap);
- /* In pthread environments the dlsym() may call our open(). */
- /* We simply ignore it because libc is already loaded */
- if (initing) {
+ /* If we get called recursively during initialization (which should
+ * be rare but might happen), just fail. */
+ if (init_running > 0) {
errno = EFAULT;
return -1;
}
@@ -191,9 +196,9 @@ int LIBEATMYDATA_API open64(const char* pathname, int flags, ...)
#endif
va_end(ap);
- /* In pthread environments the dlsym() may call our open(). */
- /* We simply ignore it because libc is already loaded */
- if (initing) {
+ /* If we get called recursively during initialization (which should
+ * be rare but might happen), just fail. */
+ if (init_running > 0) {
errno = EFAULT;
return -1;
}
diff --git a/m4/ax_tls.m4 b/m4/ax_tls.m4
new file mode 100644
index 000..51edee8
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Tue, Jan 22, 2019 at 11:17:41AM +, Chris Lamb wrote: Hi Alberto, > It could be a couple of weeks before I get time to do this though, as > I'm away on holidays No problem; have you managed to get anywhere? :) I've been looking at this today. There are some bugs and races in libeatmydata wrt. early initialization and threading that I think are the root cause. If libeatmydata's open() wrapper gets called while libeatmydata's constructor is running, it assumes it's because a recursive call in dlsym() and makes open() return EFAULT: https://git.launchpad.net/libeatmydata/tree/libeatmydata/libeatmydata.c#n167 This has a few problems: 1) the check for "is the constructor running" is not thread safe; and 2) the assumption about dlsym() is wrong. In the libfiu tests that are failing, it is libfiu's initialization that calls open(), not dlsym(), hitting the problem #2 (and also possibly #1). So libfiu calls open() -> libmetadats's open() -> return EFAULT. This causes libfiu's initialization fail, and in turn causes the test to fail/hang. I believe this is not happening in the exact same spot all the time because the libfiu test triggering this issue is multi-process and multi-thread, so depending on the kernel scheduling decisions, which thread calls libeatmydata's constructor can change. In addition, as the check in libeatmydata is also not thread safe, it probably adds to the noise and unpredictability. I'll dig in a bit more and see if I can fix libeatmydata, but it might end up being too invasive and time consuming. I'll send another message once I know more. Thanks! Alberto
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hi Alberto, > > It could be a couple of weeks before I get time to do this though, as > > I'm away on holidays No problem; have you managed to get anywhere? :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Mon, Jan 07, 2019 at 08:02:12PM +, Alberto Bertogli wrote: I'll follow up on the ssh offer separately and post my findings later. It could be a couple of weeks before I get time to do this though, as I'm away on holidays and this seems to be low priority. FYI thanks to Santiago's kind offer of access to the failing environment, I could investigate and then reproduce this issue locally. Indeed a single test is hanging when ran wrapped with eatmydata. That test uses some tricky combination with pipes and early initialization and I suspect there is some race which eatmydata brings up to light, even though there is no sync going on, but it's too early to tell for sure. I'll continue to investigate and will let you know once I have a better understanding of what's going on, and a fix. Thanks, Alberto
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Sun, Jan 06, 2019 at 11:26:01PM +0100, Chris Lamb wrote: [Adding albert...@blitiri.com.ar to CC] Dear Santiago, It is a "just in case". The offer to ssh into my machine is a blurb which I now add to all my bug reports when the problem is "weird", for example, when it does not seem to happen in buildd.debian.org or reproducible-builds. Awesome -- I just checking as it is somewhat unusual to receive that offer and I was just 100% confirming before I potenaily spent cycles on this and I was missing something.. I'm tempted to think that upstream (CC'd) might have an idea at this stage...? :) I don't! libfiu doesn't particularly care for data persistency, there's not a single sync/fsync/etc. call. But it could be a tight race in the build rules that eatmydata makes it more prone to manifest. I'll follow up on the ssh offer separately and post my findings later. It could be a couple of weeks before I get time to do this though, as I'm away on holidays and this seems to be low priority. Thanks! Alberto
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
[Adding albert...@blitiri.com.ar to CC] Dear Santiago, > It is a "just in case". The offer to ssh into my machine is a blurb > which I now add to all my bug reports when the problem is "weird", > for example, when it does not seem to happen in buildd.debian.org or > reproducible-builds. Awesome -- I just checking as it is somewhat unusual to receive that offer and I was just 100% confirming before I potenaily spent cycles on this and I was missing something.. I'm tempted to think that upstream (CC'd) might have an idea at this stage...? :) > [..] sometimes the maintainer decides to never ssh to the machine, > downgrade the bug, and keep saying it only happens to me, even when I > can reproduce it in more than 20 different machines, the bug has also > been found by other people doing QA, and there is not even a > successful build log in buildd.debian.org. Amazing, isn't it? Unfortunately this sort of unnecessary addition is not very motivating. Sorry. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
On Sun, Jan 06, 2019 at 10:54:13PM +0100, Chris Lamb wrote: > Hi Santiago, > > > [ I can offer a machine for you to ssh into it and reproduce this if you > > need it, please contact me privately for details ]. > > Just out of interest, is there a good reason why I might not be > able to reproduce this locally, or is this a "just in case"? It is a "just in case". The offer to ssh into my machine is a blurb which I now add to all my bug reports when the problem is "weird", for example, when it does not seem to happen in buildd.debian.org or reproducible-builds. Sometimes this has the desired effect and the bug is fixed in record time (see the great job of Cyril Brulebois with the clojure packages), and sometimes the maintainer decides to never ssh to the machine, downgrade the bug, and keep saying it only happens to me, even when I can reproduce it in more than 20 different machines, the bug has also been found by other people doing QA, and there is not even a successful build log in buildd.debian.org. Amazing, isn't it? Thanks.
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Hi Santiago, > [ I can offer a machine for you to ssh into it and reproduce this if you > need it, please contact me privately for details ]. Just out of interest, is there a good reason why I might not be able to reproduce this locally, or is this a "just in case"? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#918520: libfiu: FTBFS randomly when built with eatmydata
Package: src:libfiu
Version: 0.98-1
Tags: ftbfs
Hello Chris.
I'm getting random build failures for this package:
[...]
debian/rules build-arch
dh build-arch --with python3,python2
dh_update_autotools_config -a
dh_autoreconf -a
dh_auto_configure -a
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
rst2html doc/posix.rst > doc/posix.html
rst2html doc/guide.rst > doc/guide.html
rst2html doc/remote_control.rst > doc/remote_control.html
dh_auto_build -- V=1
make -j2 "INSTALL=install --strip-program=true" V=1
make[2]: Entering directory '/<>'
make -C libfiu
[... snipped ...]
cc -I../../libfiu/ -L../../libfiu/ -L./ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall -std=c99 -pedantic -Wall -L. binary.c -lfiu -lcoltest -o binary
LD_LIBRARY_PATH="./:../../libfiu/" ./binary
make[4]: Leaving directory '/<>/tests/collisions'
cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall -std=c99 -pedantic -Wall tests/fread.c -lfiu -o tests/fread.bin
ln -f ../preload/posix/fiu_posix_preload.so libs/
ln -f ../preload/run/fiu_run_preload.so libs/
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/strdup.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fprintf.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/kill.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/open.bin
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall test-parallel-wildcard.c -lfiu -lpthread -o test-parallel-wildcard
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/pread.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/malloc.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/open64.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/mmap.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/pread64.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fopen.bin
LD_LIBRARY_PATH=../../libfiu/ LD_PRELOAD="../../preload/run/fiu_run_preload.so
../../preload/posix/fiu_posix_preload.so" ./tests/fread.bin
rm tests/open.bin tests/fread.bin tests/open64.bin tests/strdup.bin
tests/pread.bin tests/pread64.bin tests/malloc.bin tests/mmap.bin
tests/fprintf.bin tests/kill.bin tests/fopen.bin
make[4]: Leaving directory '/<>/tests/generated'
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall \
-rdynamic -fno-optimize-sibling-calls test-enable_stack.c -lfiu
-lpthread -o test-enable_stack
test-enable_stack.c: In function 'main':
test-enable_stack.c:32:43: warning: ISO C forbids conversion of function
pointer to object pointer type [-Wpedantic]
r = fiu_enable_stack("fp-1", 1, NULL, 0, (void *) , -1);
^
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall \
-rdynamic -fno-optimize-sibling-calls test-enable_stack_by_name.c -lfiu
-lpthread -o test-enable_stack_by_name
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall test-parallel.c -lfiu -lpthread -o test-parallel
cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
-DFIU_ENABLE=1 -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -pedantic
-Wall test-ferror.c -lfiu -lpthread -o test-ferror
LD_LIBRARY_PATH=../libfiu/
LD_PRELOAD=./libs/fiu_run_preload.so:./libs/fiu_posix_preload.so
