Bug 137240 – glibc-2.4-r3 testsuit results in an access violation on /dev/full

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Sascha Biberhofer 2006-06-19 02:59:54 UTC]

Overview Description:

In the testsuit, glibc generates an access violation when trying to open /dev/full. It compiles and emerges successfully, yet when adding FEATURES="test" to the make.conf/command line the sandbox kills the process as soon as make check tries to access the device. 

Steps to Reproduce:

FEATURES="test" emerge glibc
(at least if you're using the ~x86 version of the glibc)

Actual Results:

(snippet)
>>> Source compiled.
Checking GLIBC with NPTL...
[....]
make[1]: Leaving directory `/var/tmp/portage/glibc-2.4-r3/work/glibc-2.4'
--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE = "/var/log/sandbox/sandbox-sys-libs_-_glibc-2.4-r3-10348.log"

open_wr:   /dev/full
--------------------------------------------------------------------------------

Additional Information:

The bug could be reproduced on two different machines, all resulting in the same access violation. 
To fix this, it is enough to add /dev/full to the SANDBOX_WRITE and SANDBOX_READ exports in the ebuild.sh file, so e.g.:

export SANDBOX_WRITE="${SANDBOX_WRITE}:/dev/shm:/dev/stdout:/dev/stderr:/dev/full:${PORTAGE_TMPDIR}"
export SANDBOX_READ="${SANDBOX_READ}:/dev/shm:/dev/stdin:/dev/full:${PORTAGE_TMPDIR}"

Even though this works in general, these lines are often rewritten, so you need to take care that /dev/full is in there any time you decide to remerge glibc, a task that is quite nasty. 

Another possible workaround might be to disable the sandbox completely (not tested).

I've got logs of both emerges when the bug occured, yet they are about 15 MB each, if you need them I could upload them anytime. 

An additional emerge --info: 

Gentoo Base System version 1.12.1
Portage 2.1.1_pre1-r1 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16.3 i686)
=================================================================
System uname: 2.6.16.3 i686 Pentium II (Deschutes)
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r2
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium2 -mmmx -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=pentium2 -mmmx -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict test"
GENTOO_MIRRORS="ftp://192.168.0.10 http://gentoo.inode.at http://gentoo.osuosl.org http://www.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --e
xclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="apache2 apm arts atm avi berkdb bitmap-fonts cli crypt cups dri eds emboss encode esd foomaticdb fortran gdbm gif gpm gstreamer gtk2 imlib isdnlo
g jpeg libg++ libwww mad mikmod mmx motif mp3 mpeg ncurses nls nptl nptlonly ogg opengl pam pcre pdflib perl png pppd python quicktime readline reflec
tion sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev vorbis x86 xml xorg xv zlib elibc_glibc kernel_linux userland_GNU"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

[Comment 1 SpanKY 2006-06-20 21:11:00 UTC]

any reason we cant just add /dev/full to default write list for sandbox ?

[Comment 2 Martin Schlemmer (RETIRED) 2006-06-22 08:05:45 UTC]

Not really - question still though is does it work under sandbox anyhow?  I know it did not pass some of the pthread_key_create() tests a while back (as preloading seemed to already allocate an key) ...

[Comment 3 Martin Schlemmer (RETIRED) 2006-07-05 03:56:55 UTC]

Hmm, well, svn sandbox the tests actually passwd twice with latest patchset of glibc-2.4 (not sure what if any is related).  Anyhow, added to svn.

[Comment 4 Martin Schlemmer (RETIRED) 2006-07-05 03:57:52 UTC]

Hmm, well, svn sandbox the tests actually passed twice with latest patchset of glibc-2.4 (not sure what if any is related).  Anyhow, added to svn.