Bug 203231

Summary: collect2 cannot deal with full /tmp
Product: [Fedora] Fedora Reporter: Ulrich Drepper <drepper>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: dvlasenk, triage
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-02 12:01:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Do not loop for TMP_MAX times, it takes ages. Output proper error messages before aborting when mkstemps fails.
none
Updated patch
none
Updated patch (style fixes) none

Description Ulrich Drepper 2006-08-19 17:10:33 UTC
Description of problem:
Running the compiler to link an executable results in an endless loop if /tmp is
full.

Version-Release number of selected component (if applicable):
gcc-4.1.1-18.x86_64

How reproducible:
always

Steps to Reproduce:
1.fill up /tmp
2.compile any toy program
3.
  
Actual results:
strace output like this:
2419  open("/tmp/ccbEA47Z.c", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 ENOSPC (No space
left on device)
2419  open("/tmp/ccCFC47Z.c", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 ENOSPC (No space
left on device)
2419  open("/tmp/cc3GE47Z.c", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 ENOSPC (No space
left on device)
2419  open("/tmp/ccuIG47Z.c", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 ENOSPC (No space
left on device)



Expected results:
Error message about full filesystem

Additional info:

Comment 1 Bug Zapper 2008-04-03 17:59:19 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 2 Bug Zapper 2008-05-07 00:45:23 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Comment 3 Ulrich Drepper 2008-05-10 15:34:18 UTC
This problem is still present in rawhide/F9.

To reproduce:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dd if=/dev/zero of=somefile bs=1024 count=1024
n=$(sudo /sbin/losetup -f -s somefile)
sudo /sbin/mke2fs $n
sudo /sbin/losetup -d $n
mkdir mntpoint
sudo mount somefile mntpoint -o loop
sudo chown -R $(id -u):$(id -g) mntpoint
dd if=/dev/zero of=mntpoint/full bs=1024 count=1024
while touch mntpoint/f$RANDOM; do :; done
cat > t.c <<EOF
#include <stdio.h>
int main(void) {
  puts ("hello world");
  return 0;
}
EOF
strace -E TMPDIR=mntpoint gcc -c t.c
sudo umount mntpoint
rm somefile
rmdir mntpoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If the compiler fails to proceed press C-c to interrupt it.

Comment 4 Bug Zapper 2008-05-14 02:17:37 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 Denys Vlasenko 2008-07-21 14:33:44 UTC
Created attachment 312263 [details]
Do not loop for TMP_MAX times, it takes ages. Output proper error messages before aborting when mkstemps fails.

It actually does not loop infinitely, it loops "only" 238328 times (on my
machine), after which it aborts without explaining why. Patch fixes both
issues.
Sample output:

Cannot create temporary file in /vda/srcdevel/gcc/testdir/: Permission denied
./z.sh: line 13: 22173 Aborted	   TMP=$PWD/testdir gcc -o t t.c

Comment 6 Denys Vlasenko 2008-07-28 17:03:07 UTC
Created attachment 312795 [details]
Updated patch

This patch addresses Jakub's concerns (I talked with him on IRC).

Comment 7 Denys Vlasenko 2008-07-30 11:55:52 UTC
Created attachment 312985 [details]
Updated patch (style fixes)

Comment 8 Denys Vlasenko 2008-09-02 11:09:44 UTC
Submitted the patch upstream, it should appear here today:

http://sources.redhat.com/ml/libc-alpha/2008-09/

Comment 9 Jakub Jelinek 2008-09-02 12:01:30 UTC
The patch has been committed over a month ago and is in gcc-4.3.1-6 and above.