Not enough disk space in for /tmp

VERIFIED FIXED in mozilla1.0

Status

SeaMonkey
Installer
--
major
VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: Syd Logan)

Tracking

Trunk
mozilla1.0
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

17 years ago
using the stubs installer for the 2001.10.31.08 build [commercial, on linux
rh6.2], the xpi's are downloaded, but the installation fails.

i get the following error while extracting libmozjs.so: "Fatal error [-616]:
Extraction of XPCOM failed."
(Reporter)

Comment 1

17 years ago
eek, i tried using the non-installer blob, but when i issue 'tar zxvf
[blobname]' i'm unable to completely decompress it:

gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Child returned status 1
tar: Error exit delayed from previous errors
fwiw, it fails after decompressing package/chrome/comm.jar...

grace and curt will prolly come over to see if there's something fishy with my
machine. it might be a bug, but then again it might be something odd that has a
workaround...
Severity: critical → blocker
(Reporter)

Comment 2

17 years ago
hrm, wonder if my dir permissions have changed...

Updated

17 years ago
QA Contact: bugzilla → ktrina
(Reporter)

Comment 3

17 years ago
this might be due to lack of disk space, d'oh!

testing now...
(Reporter)

Comment 4

17 years ago
hrm...actually, the /export partition on which i usually install is only 68%
full. the / partition is at 100%, but i guess i don't understand how that might
be causing this... other suggestions? i'll try removing some stuff off of / ...
(Reporter)

Comment 5

17 years ago
okay, i removed a few things from / , although that still reports 100% used...
then i also removed the install directory, recreated it...then was successful at
installing using the stubs.

closing out as wfm.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
The installer unpacks things into /tmp. I thought the installer accounted for
that required space when /tmp is on a different volume than the install
directory, but maybe it's only windows that does that.

Comment 7

17 years ago
Reopening based on Dan's comments and changing the summary to reflect the
problem that we really care about.  Seems that we should spot this problem and
give the user some clue about what it going on.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: unable to use the linux installer: error -616, xpcom install failed → Not enough disk space in for /tmp

Comment 8

17 years ago
I'll take this bug
Assignee: syd → curt
Status: REOPENED → NEW

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
(Reporter)

Comment 9

17 years ago
bumping down sev, since i was able to find a workaround [threw out some big
items from /tmp, even tho' / remained at 100%, and removing the previous install
dir].
Severity: blocker → major
(Reporter)

Comment 10

17 years ago
curt, i wonder if this might be dependent on bug 55690?

Updated

17 years ago
Keywords: nsbeta1

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Updated

17 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0
(Assignee)

Comment 11

17 years ago
a comment
Assignee: curt → syd
Status: ASSIGNED → NEW
Keywords: nsbeta1 → nsbeta1+
*** Bug 55085 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

17 years ago
Created attachment 67237 [details] [diff] [review]
Improve how we do temp directory creation and removal

A couple of problems:

We should let the system give us a temporary name, this is preferred in unix.
For one, /tmp might not exist. Or, the user may prefer a different temp
directory. tempnam() is designed to give an appropriate unique name, and take
into account the TMP and TMPDIR env variables (which we ignored). In many cases
when the user fails because of minimal space in /tmp, he or she will have set
TMPDIR in their sh init file to specify a place that has more space. Also, if
the user fails, we can suggest they change TMPDIR to some other location and
rerun the installer. By hardcoding /tmp, they have to clear up /tmp or we will
fail, there is no other workaround.

Another problem I fixed is we never remove the temporary directory in the
engine destructor (we do free the memory allocated to the member variable that
holds the path, for what that is worth). So, added that code in as well.
(Assignee)

Comment 14

17 years ago
Regarding the above patch, someone will point out potential security
implications using tempnam() (race conditions). These issues should only apply
to file creation, here we are creating a directory, not a file. I scanned the
appropriate bulletins and this is usage of tempnam() is not a problem.
(Assignee)

Updated

17 years ago
Keywords: patch

Comment 15

17 years ago
Comment on attachment 67237 [details] [diff] [review]
Improve how we do temp directory creation and removal

r=sgehani
Attachment #67237 - Flags: review+
Comment on attachment 67237 [details] [diff] [review]
Improve how we do temp directory creation and removal

>+    if ( mTmp != (char *) NULL ) {

That's pretty ugly, especially the cast. Couldn't you "if ( mTmp )"?
If you absolutely must "if ( mTmp != 0 )", but the NULL #define is
discouraged in C++

ditto with if (buf)

>+    buf = tempnam( (const char *) NULL, "xpi" );
> 
>-    mTmp = (char *) malloc( (strlen(buf) * sizeof(char)) + 1 );
>+    if ( buf != (char *) NULL ) 
>+      mTmp = (char *) malloc( strlen(buf) + 1 );
>     if (!mTmp) return E_MEM;
>-
>     sprintf(mTmp, "%s", buf);
>-    mkdir(mTmp, 0755);
>-
>+    err = mkdir(mTmp, 0755);
>+    if ( err == -1 )
>+      err = E_DIR_CREATE;
>     return err;
> }

This routine leaks buf.
Attachment #67237 - Flags: needs-work+
(Assignee)

Comment 17

16 years ago
Casting to (char *) NULL is very standard C. While NULL is almost always == 0,
it is not guaranteed. Man page for malloc() states NULL is returned on failure
(and makes no guarantee it is 0). 

Thanks for catching the leak, I'll put up a new patch.
(Assignee)

Comment 18

16 years ago
Created attachment 68031 [details] [diff] [review]
New patch, fix leak in first patch
(Assignee)

Updated

16 years ago
Attachment #67237 - Attachment is obsolete: true
Comment on attachment 68031 [details] [diff] [review]
New patch, fix leak in first patch

> nsXIEngine::MakeUniqueTmpDir()
> {
>     int err = OK;
>     int i;
>-    char buf[MAXPATHLEN];
>-    struct stat dummy;
>+    char *buf; 
>     mTmp = NULL;
> 
>-    for (i = 0; i < MAX_TMP_DIRS; i++)
>-    {
>-        sprintf(buf, TMP_DIR_TEMPLATE, i);
>-        if (-1 == stat(buf, &dummy))
>-            break; 
>-    }
>+    buf = tempnam( (const char *) NULL, "xpi" );
> 
>-    mTmp = (char *) malloc( (strlen(buf) * sizeof(char)) + 1 );
>+    if ( buf != (char *) NULL ) 
>+      mTmp = (char *) malloc( strlen(buf) + 1 );
>     if (!mTmp) return E_MEM;

You still potentially leak buf if you return early here.

>-
>     sprintf(mTmp, "%s", buf);

Didn't notice this bit of ugliness before. Why not strcpy()?

>-    mkdir(mTmp, 0755);
>-
>+    err = mkdir(mTmp, 0755);
>+    if ( err == -1 )
>+      err = E_DIR_CREATE;
>+    free( buf );
>     return err;
> }

Looking at this again I'm not sure you even need buf anymore.
Couldn't you just mTmp = tempnam() now and be done with it?
(Assignee)

Updated

16 years ago
Attachment #68031 - Attachment is obsolete: true
(Assignee)

Comment 20

16 years ago
Created attachment 68037 [details] [diff] [review]
better patch
Comment on attachment 68037 [details] [diff] [review]
better patch

sr=dveditz
Attachment #68037 - Flags: superreview+
Attachment #68037 - Flags: review+
(Assignee)

Comment 22

16 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 23

16 years ago
Verified code fix
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.