Closed
Bug 699711
Opened 13 years ago
Closed 13 years ago
"Analyze the leak" always fails with "Could not find log file in cache for id: ..." on tbpl.m.o
Categories
(Tree Management Graveyard :: TBPL, defect)
Tree Management Graveyard
TBPL
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: philor, Unassigned)
References
Details
And as a user, having https://tbpl.mozilla.org/leak-analysis/?id=7199799&tree=Mozilla-Inbound tell me "Could not find log file in cache for id: 7199799" doesn't tell me a single thing I want to know. Can't find it? Go fetch it! No clue why it wouldn't be there, either - I'd already loaded the scrape and the summary long before I hit that link, so I'd think we must have fetched the log.
Reporter | ||
Updated•13 years ago
|
Severity: normal → major
Reporter | ||
Comment 1•13 years ago
|
||
I can't really remember the last time it actually worked.
Reporter | ||
Updated•13 years ago
|
Severity: major → critical
Reporter | ||
Comment 2•13 years ago
|
||
Interesting that it never works at all on tbpl.m.o, and works perfectly on tbpl.swatinem.de. Since that's quite a few revs back right now, can't really tell whether that means that we broke it sometime between whatever it's updated to and the tip, or just means that something in the setup of tbpl.m.o is breaking it.
Summary: "Analyze the leak" frequently fails with "Could not find log file in cache for id: ..." → "Analyze the leak" always fails with "Could not find log file in cache for id: ..." on tbpl.m.o
Comment 3•13 years ago
|
||
I’ve recently updated my server to 962932eba448 (+ qseries), so it’s not that far back.
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Arpad Borsos (Swatinem) from comment #3) > I’ve recently updated my server to 962932eba448 (+ qseries), so it’s not > that far back. Was it that upgrade, or the patch for bug 717005, which completely broke this on your server as well?
Severity: critical → blocker
Comment 5•13 years ago
|
||
(In reply to Phil Ringnalda (:philor) from comment #4) > (In reply to Arpad Borsos (Swatinem) from comment #3) > > I’ve recently updated my server to 962932eba448 (+ qseries), so it’s not > > that far back. > > Was it that upgrade, or the patch for bug 717005, which completely broke > this on your server as well? Yes definitely bug 717005, the leak analysis php script is different from all the others. Time to refactor it. The problem is that it still has usetinderbox fallback mode which makes it a bit harder. When can we get rid of that altogether?
Reporter | ||
Comment 6•13 years ago
|
||
From leak-analysis? Right now. The only Firefox-related things still using tinderbox are SpiderMonkey shell builds and Jetpack, neither of which would know a domwindow if it leaked into their shoe, and the mozillamessaging version of tbpl is probably very nearly a completely separate fork by now.
Comment 7•13 years ago
|
||
I think the cause for this bug is the same as in bug 717005. The leak-analysis script expects the raw log to be present (without downloading it itself). The assumption is that once the UI presents a leak-analysis link, the raw log would already be present in the filesystem. This is not the case once the UI is updated based on a request served by server 1 (with a cached raw log), but server 2 (without a cached log) is used to serve leak-analysis.
Comment 8•13 years ago
|
||
Fixed, per bug 717005 comment 49.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
Product: Webtools → Tree Management
Assignee | ||
Updated•10 years ago
|
Product: Tree Management → Tree Management Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•