Closed
Bug 794354
Opened 12 years ago
Closed 11 years ago
Valgrind on tbpl detects leak with mozilla::safebrowsing::Classifier::ApplyUpdates on the stack
Categories
(Toolkit :: Safe Browsing, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: gkw, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: memory-leak, valgrind)
Attachments
(1 file)
(deleted),
text/plain
|
Details |
Valgrind detects a leak of 192 bytes (direct) with mozilla::safebrowsing::Classifier::ApplyTableUpdates on the stack, see attached snippet which comes from:
https://tbpl.mozilla.org/php/getParsedLog.php?id=15521837&tree=Firefox&full=1
Guessing Toolkit: General, please change component if necessary.
Reporter | ||
Comment 1•12 years ago
|
||
mozilla::safebrowsing::HashStore::WriteFile is also on the stack, and mozilla::safebrowsing::Classifier::ApplyUpdates is lower down on the stack.
Summary: Valgrind on tbpl detects leak - 192 bytes are definitely lost (direct) with mozilla::safebrowsing::Classifier::ApplyTableUpdates on the stack → Valgrind on tbpl detects leak - 192 bytes are definitely lost (direct) with mozilla::safebrowsing::Classifier::ApplyUpdates on the stack
Updated•12 years ago
|
Component: General → Phishing Protection
Product: Toolkit → Firefox
Updated•12 years ago
|
Summary: Valgrind on tbpl detects leak - 192 bytes are definitely lost (direct) with mozilla::safebrowsing::Classifier::ApplyUpdates on the stack → Valgrind on tbpl detects leak with mozilla::safebrowsing::Classifier::ApplyUpdates on the stack
Comment 2•12 years ago
|
||
Is this with any specific workload or test? Or does it just always happen for regular runs?
Reporter | ||
Comment 3•12 years ago
|
||
(In reply to Gian-Carlo Pascutto (:gcp) from comment #2)
> Is this with any specific workload or test? Or does it just always happen
> for regular runs?
It happens for PGO tests I think:
python _profile/pgo/profileserver.py --debugger=valgrind --debugger-args="$debugger_args" || exit 1
from http://hg.mozilla.org/build/tools/file/default/scripts/valgrind/valgrind.sh#l82
Comment 4•12 years ago
|
||
ApplyTableUpdates is supposed to delete all the TableUpdate* entries it consumes, but it looks reasonably obvious to me that that won't happen if there are failures while processing the update.
The comments in the code make it obvious this bug isn't unexpected. But for judging the urgency it would be nice to know if this happens during normal operation, or during failure cases.
Comment 5•12 years ago
|
||
>It happens for PGO tests I think
I dunno what those are but if I read that profileserver.py correctly, it just loads index.html, which loads 4 webpages and some JS code?
That shouldn't be a failure case, in which case we're leaking in normal operation.
:-(
Comment 6•12 years ago
|
||
The PGO build might shut down before the download finishes, or it might be completely unable to contact the server. Would either of those scenarios trigger the leak?
Comment 7•12 years ago
|
||
Perhaps yes. I ran valgrind with --leak-check=all on current m-c and didn't get any warnings or leaks inside the safebrowsing stuff, during a normal run that received updates.
Given that we only seem to trigger this when things are already hosed, reducing the severity. We'll want to fix this but it looks like it wont leak during normal operation.
Severity: major → minor
Comment 8•11 years ago
|
||
This is no longer occurring in Valgrind-on-TBPL runs.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•11 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•