Closed Bug 462621 Opened 13 years ago Closed 13 years ago

test_retention_is_0_closes.xul times out and leaks, on my computer

Categories

(Toolkit :: Downloads API, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.9.1b2

People

(Reporter: sgautherie, Assigned: neil)

References

Details

(Keywords: memory-leak, regression, verified1.9.1)

Attachments

(1 file)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081031 Minefield/3.1b2pre] (home, optim default) (W2Ksp4)

A DM window appears and stays there for a (long) while reporting "Scanning for viruses...";
but I don't have any antivirus software installed.

{
2 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/toolkit/mozapps/downloads/tests/chrome/test_retention_is_0_closes.xul | Test timed out.
}

It also leaks "the world".

NB: It was succeeding when I ran the tests on 2008-09-17.
In case it matters, I build with |ac_add_options --disable-vista-sdk-requirements|.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081103 SeaMonkey/2.0a2pre] (home, optim default) (W2Ksp4)

Same with SeaMonkey (with a TK DLMGR patch).
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20081106 Minefield/3.1b1pre] (home, optim default) (W2Ksp4)

"197f83ad7678 2008-10-07 15:45:10" was succeeding.
Whiteboard: [Regressed between 2008-10-07 and 2008-10-31]
(In reply to comment #3)
> "197f83ad7678 2008-10-07 15:45:10" was succeeding.

"197f83ad7678	2008-10-07 08:45:33 -0700"

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081106 Minefield/3.1b2pre] (home, optim default) (W2Ksp4)

"28fc43e4394c	2008-10-19 05:37:54 -0700" was already failing.
Flags: blocking1.9.1?
Whiteboard: [Regressed between 2008-10-07 and 2008-10-31] → [Regressed between 2008-10-07 and 2008-10-19]
(In reply to comment #2)
> Same with SeaMonkey (with a TK DLMGR patch).

I also experienced it in a real life case ("opening" a JNLP file).
Keywords: mlk
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081108 Minefield/3.1b2pre] (nightly) (W2Ksp4)

But a nightly works fine...
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081109 Minefield/3.1b2pre] (home, optim default) (W2Ksp4)

"f0d87d0a9156	2008-10-13 13:14:36 -0700" was succeeding.
Whiteboard: [Regressed between 2008-10-07 and 2008-10-19] → [Regressed between 2008-10-13 and 2008-10-19]
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081109 Minefield/3.1b2pre] (home, optim default) (W2Ksp4)

"9fde2bdd93ef	2008-10-16 08:17:07 -0700" was already failing.
Whiteboard: [Regressed between 2008-10-13 and 2008-10-19] → [Regressed between 2008-10-13 and 2008-10-16]
Blocks: 459329
This is caused by bug 459329 checkin.
No longer blocks: 437302
Severity: normal → major
Whiteboard: [Regressed between 2008-10-13 and 2008-10-16]
Blocks: 463855
Strange, because the whole point of bug 459329 was that you couldn't build with --disable-vista-sdk-requirements ...

Can you compare the output of make nsDownloadManager.i with and without the patch?
(In reply to comment #10)
> Strange, because the whole point of bug 459329 was that you couldn't build with
> --disable-vista-sdk-requirements ...

I know, though I never had any issue building Firefox (or SeaMonkey) with/without the patch :-|

> Can you compare the output of make nsDownloadManager.i with and without the
> patch?

without:
(nsDownloadScanner.obj size is 72 KB.)
nsDownloadManager.i size is 6,222 KB.

with:
(there is no nsDownloadScanner.obj.)
nsDownloadManager.i size is 5,586 KB.

At first glance (inside the file), it seems the patch does what it's supposed to.
Anything specific that you want me to check ?
Attached patch Proposed patchSplinter Review
We were getting into the DOWNLOAD_SCANNING state without having a scanner...

I haven't actually tested this, but a) Shawn might decide that the patch is sufficiently trivial to review b) Serge might test this for me anyway.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #347193 - Flags: review?(sgautherie.bz)
Attachment #347193 - Flags: review?(sdwilsh)
This bug probably explains why every download I've started lately on my Vista system has been getting stuck in a download scanning state even though I don't have a virus scanner installed. I build with --disable-vista-sdk-requirements on VC8SP1. I'll give this patch a shot and see if it fixes that problem for me.
Yup, this patch fixes the problem!
Comment on attachment 347193 [details] [diff] [review]
Proposed patch

(In reply to comment #13)
> This bug probably explains why every download I've started lately on my Vista

That is this bug :->

(In reply to comment #14)
> Yup, this patch fixes the problem!

And bug 463855 to ;-)
Attachment #347193 - Flags: review?(sgautherie.bz)
No longer blocks: 463855
Duplicate of this bug: 463855
Comment on attachment 347193 [details] [diff] [review]
Proposed patch

ugh, yes.  I missed this in my original review...

r=sdwilsh
Attachment #347193 - Flags: review?(sdwilsh) → review+
Target Milestone: --- → mozilla1.9.1b2
Attachment #347193 - Flags: approval1.9.1b2?
Comment on attachment 347193 [details] [diff] [review]
Proposed patch

This is NPOTDB IMO, so you don't need approval.
Attachment #347193 - Flags: approval1.9.1b2?
Flags: blocking1.9.1? → blocking1.9.1+
Target Milestone: mozilla1.9.1b2 → mozilla1.9.1
Pushed changeset 40fbebff0cd5 to mozilla-central.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre] (home, optim default) (W2Ksp4)

V.Fixed
Status: RESOLVED → VERIFIED
Target Milestone: mozilla1.9.1 → mozilla1.9.1b2
fixed1.9.1 -> verified1.9.1, per comment 20.
You need to log in before you can comment on or make changes to this bug.