open() returns -EFAULT when program doesn't run ctor
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libeatmydata |
Fix Released
|
Medium
|
Stewart Smith | ||
libeatmydata (Debian) |
Fix Released
|
Unknown
|
Bug Description
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_
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_
FWIW, the case of eatmydata_init() not being run as a ctor is already handled by running it in eatmydata_
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.
Changed in libeatmydata (Debian): | |
status: | Unknown → Confirmed |
Changed in libeatmydata (Debian): | |
status: | Confirmed → Fix Released |
Changed in libeatmydata: | |
assignee: | nobody → Stewart Smith (stewart) |
importance: | Undecided → Medium |
status: | New → In Progress |
Changed in libeatmydata: | |
status: | In Progress → Fix Released |
Actually that patch doesn't fully work: https:/ /bugs.debian. org/765738
This one is fine, instead.