Closed
Bug 1159826
Opened 10 years ago
Closed 10 years ago
ensure_copy_recursive() leaks directory streams
Categories
(Toolkit :: Application Update, defect)
Toolkit
Application Update
Tracking
()
RESOLVED
FIXED
mozilla40
People
(Reporter: mcs, Assigned: robert.strong.bugs)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tor])
Attachments
(1 file)
(deleted),
patch
|
spohl
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
We received a report that an update of Tor Browser failed with the message: "ensure_copy_recursive: path is not a directory: .../Cache/4/99, rv: 0, err: 24"
Errno 24 is EMFILE aka "Too many open files." In reviewing the code, we found that ensure_copy_recursive() in updater.cpp is missing a call to closedir().
Something like this should fix the problem:
--- a/toolkit/mozapps/update/updater/updater.cpp
+++ b/toolkit/mozapps/update/updater/updater.cpp
@@ -797,16 +797,17 @@ static int ensure_copy_recursive(const NS_tchar *path, const NS_tchar *dest,
NS_T("%s/%s"), dest, entry->d_name);
rv = ensure_copy_recursive(childPath, childPathDest, skiplist);
if (rv) {
break;
}
}
}
+ NS_tclosedir(dir);
return rv;
}
// Renames the specified file to the new file specified. If the destination file
// exists it is removed.
static int rename_file(const NS_tchar *spath, const NS_tchar *dpath,
bool allowDirs = false)
{
Updated•10 years ago
|
Attachment #8599421 -
Flags: review?(spohl.mozilla.bugs) → review+
Assignee | ||
Comment 2•10 years ago
|
||
Pushed to mozilla-inbound
https://hg.mozilla.org/integration/mozilla-inbound/rev/d84644c09199
Flags: in-testsuite-
Target Milestone: --- → mozilla40
Assignee | ||
Updated•10 years ago
|
status-firefox37:
--- → wontfix
status-firefox38:
--- → affected
status-firefox38.0.5:
--- → affected
status-firefox39:
--- → affected
status-firefox-esr31:
--- → wontfix
Assignee | ||
Comment 3•10 years ago
|
||
Comment on attachment 8599421 [details] [diff] [review]
patch
Requesting now since I will be on pto soon
Approval Request Comment
[Feature/regressing bug #]: Bug 307181
[User impact if declined]: It is possible that some users may error during update with too many open files
[Describe test coverage new/current, TreeHerder]: landed on m-i and soon to be on m-c. Tested locally.
[Risks and why]: Minimal. This is an obvious correctness fix
[String/UUID change made/needed]: None
Attachment #8599421 -
Flags: approval-mozilla-beta?
Attachment #8599421 -
Flags: approval-mozilla-aurora?
Comment 4•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 5•10 years ago
|
||
Comment on attachment 8599421 [details] [diff] [review]
patch
[Triage Comment]
Taking it in 38.0RC1 (because 38 is an ESR).
Attachment #8599421 -
Flags: approval-mozilla-release+
Attachment #8599421 -
Flags: approval-mozilla-beta?
Attachment #8599421 -
Flags: approval-mozilla-aurora?
Attachment #8599421 -
Flags: approval-mozilla-aurora+
Comment 6•10 years ago
|
||
Comment 7•10 years ago
|
||
Comment 8•10 years ago
|
||
status-firefox-esr38:
--- → fixed
Comment 9•10 years ago
|
||
Comment 10•10 years ago
|
||
Robert, could you please provide some steps to verify this?
Flags: needinfo?(robert.strong.bugs)
Comment 11•10 years ago
|
||
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #10)
> Robert, could you please provide some steps to verify this?
I mean verification on ESR 38 particularly.
Assignee | ||
Comment 12•10 years ago
|
||
This is a correctness fix that would take a significant effort to simulate a failure condition which is likely why we've never had a bug report for it previously. The patch landing, the tests passing, and updates being successful will likely need to be enough for verification.
Flags: needinfo?(robert.strong.bugs)
Comment 13•9 years ago
|
||
Got it, thank you Robert! No manual verification for this then.
Flags: qe-verify-
You need to log in
before you can comment on or make changes to this bug.
Description
•