lp:~mapreri/libeatmydata/1556410

Created by Mattia Rizzolo and last modified
Get this branch:
bzr branch lp:~mapreri/libeatmydata/1556410
Only Mattia Rizzolo can upload to this branch. If you are Mattia Rizzolo please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Mattia Rizzolo
Project:
libeatmydata
Status:
Development

Recent revisions

106. By Mattia Rizzolo

Use a weak reference to pthread_testcancel, so that it's called only if the program itself pulls libpthread

This avoid an hard link on pthread.

libeatmydata is linked against libpthread. This thus pulls libpthread
in all processes run under eatmydata. It happens that having
libpthread in a process makes pthread_mutex_lock() and all such basic
performance-sensitive operations much heavier (since they then have to
deal with potential multithreading). This avoids that by using a weak reference
to pthread_testcancel, so that pthread_testcancel is called only if the program
itself pulls libpthread.

LP: #1556410

105. By Stewart Smith

tag version 105

104. By Mattia Rizzolo

Fix executable-not-elf-or-script lintian warning

103. By Mattia Rizzolo

Fix multiarch issue

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765810

102. By Stewart Smith

merge remove install-exec hook

101. By Stewart Smith

update AUTHORS

100. By Stewart Smith

Some test suite updates.

Add tst-key4 from libc, although we need to deal with 1 less pthread key
than normal due to something that's going on with pthread when libeatmydata
is present that I don't quite know what's going on.

We also update tst-cancel and the test run script so that we better capture
errors from the test suite.

99. By Mattia Rizzolo

open() returns -EFAULT when program doesn't run ctor

https://bugs.launchpad.net/libeatmydata/+bug/1374862

bug forwarded from debian, see the remote tracker.

I encountered some mysterious errors with eatmydata. For example, when installing gnunet-server (as a build dependency of some source package), the following error happens:

Fatal: can't open /dev/urandom: Bad address

In fact, you can easily reproduce this (also on other arches like amd64) with:

# eatmydata gnunet-arm
Fatal: can't open /dev/urandom: Bad address
Aborted
#

This is due to the assumption that normally, eatmydata_init() is called as a constructor before main():

void __attribute__ ((constructor)) eatmydata_init(void)

However, some programs like gnunet-arm for some reason don't run ctors of our SO's ctor eatmydata_init(). While it might be a good idea to fix this in gnunet also, I propose a workaround in eatmydata to even run programs like gnunet-arm
with this issue more transparently (as run without eatmydata).

Consider the attached patch: It fixes the issue by detecting directly if we are just in the process of eatmydata_init() already. This is already done by checking for !libc_open but this also happens in the above case: eatmydata_init() not been called previously, leading to the assumption in open() that we are catching the case of just initing and coming back from
dlsym() to open(). But here, this branch catches the wrong state, because in gnunet-arm, eatmydata_init() wasn't called at all.

So the patch issues EFAULT only in case of actually just eatmydata_init()ing. Otherwise, eatmydata_is_hungry() and therefore eatmydata_init() can be called just as usual.

FWIW, the case of eatmydata_init() not being run as a ctor is already handled by running it in eatmydata_is_hungry() but this doesn't work in case of open() being called before one of the other triggering functions.

Note that gnunet-server is just an example. I encountered the same issue in some other occasions also.

Furthermore, this bug affects the new release of gnutls, and thus every package that use it. This makes impossible to use gnutls with eatmydata.

Please consider the patch attached, which is tested by various people and soon will be uploaded to Debian.

98. By Stewart Smith

update copyright headers

97. By Stewart Smith

whitespace cleanup

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:libeatmydata
This branch contains Public information 
Everyone can see this information.

Subscribers