Closed Bug 506491 Opened 15 years ago Closed 15 years ago

Download Manager opens 'Blank' - intermittent - Error: gStr.timeUnits is undefined and download is null

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: jmjjeffery, Assigned: jorendorff)

References

Details

(Keywords: intermittent-failure, regression, Whiteboard: , [nv])

Attachments

(4 files)

Opening the DM at times results in a Blank window, with no previous history showing.  

Failing in today's nightly build with changeset:
http://hg.mozilla.org/mozilla-central/rev/78fa6be2aac1

Sorry for being vague, but I 'think' its ok with changeset:
http://hg.mozilla.org/mozilla-central/rev/b8c752d9bc65

When the DM opens blank I also see these errors in Console2:
DownloadUtils.jsm: Couldn't get string 'units' from property ''
DownloadUtils.jsm: Couldn't get string 'timeFewSeconds' from property ''


others are reporting the issue in the nightly build thread on MZ:
http://forums.mozillazine.org/viewtopic.php?f=23&t=1379845
OK, just got it to fail using changeset:
http://hg.mozilla.org/mozilla-central/rev/b8c752d9bc65

This in Console2:
Error: gStr.timeUnits is undefined
Source file: file:///J:/Program%20Files%20(x86)/Minefield/modules/DownloadUtils.jsm
Line: 472
 ----------
DownloadUtils.jsm: Couldn't get string 'transferNoTotal' from property ''
 ----------
Error: download is null
Source file: chrome://mozapps/content/downloads/DownloadProgressListener.js
Line: 78
Waiting confirmation from others in the build thread on MZ, but it now appears that with HTML5 = enabled, the fails occur.  Its very intermittent, so I'm thinking it must be a weird timing issue maybe ?
Not HTML5 related, others are reporting still getting blank DM on occasion. 

I can repo it at times:
Set downloads in options to 'always ask where to save...'
Click a file to download, when the Windows Explorer opens, create a new sub-folder in a folder.
Click 'save file' 
The DM will open 'Blank' at times.. not 100% however, sometimes it works OK.
Summary: Download Manager opens 'Blank' - intermittant → Download Manager opens 'Blank' - intermittent
Flags: blocking1.9.2?
Seeing this on Linux trunk.

DownloadUtils.jsm: Couldn't get string 'timeUnknown' from property ''
DownloadUtils.jsm: Couldn't get string 'units' from property ''
OS: Windows Vista → All
Hardware: x86 → All
Didn't any of the automated tests catch this?  Seems like they didn't. :-(
(In reply to comment #5)
> Didn't any of the automated tests catch this?  Seems like they didn't. :-(
Maybe the test boxes aren't seeing it?  I don't follow how those errors are coming up though.  Is this with chrome JIT on or off?
I don't have it turned on. javascript.options.jit.chrome;false
It's not showing the first download I initiate, but it shows the next ones. But then if I search in the download list, it goes blank again, even when I cancel the search. In my about:config : html5 disabled, both jit options false.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090727 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090727044731
Do people also see the status bar shows "# downloads (undefined)" ? I ran in to this just now, but I can't reproduce it..

I did try Cu.importing and calling various functions just to try debugging.

DownloadUtils.getTimeLeft(-1) results in..
Warning: reference to undefined property gStr.timeUnknown

DownloadUtils.getTimeLeft(1000)..
Error: gStr.timeUnits is undefined

So it's not just the array strings (units/timeUnits) that are failing to load. Somehow loading the strings failed.. ?

I tried manually loading the strings from the Error Console and that seemed to work fine:
x = Components.classes["@mozilla.org/intl/stringbundle;1"].getService(Components.interfaces.nsIStringBundleService).createBundle("chrome://mozapps/locale/downloads/downloads.properties").GetStringFromName; x("timeUnknown")
In reply to comment #10 , yes the status-bar is (undefined) when the issue of coming up 'blank' arises.
I also see the "(undefined)" in the status bar. And in the Downloads dialog I don't see any transfer rate below the progress bar.
This file hasn't changed since 5/12/2009, so did something break importing JavaScript modules maybe?
With comment 11 still happening, makes me wonder how bug 487638 was tested prior to checkin.
(In reply to comment #14)
Afaict, bug 487638 is unrelated, it's dealing with page loads, not downloads in the dm.
un-scientific testing I have found what I believe is a pattern in getting the DM to open blank.  Seems to me that its a start-up initialization issue perhaps.

Open Minefield several tabs, I have 16. Once ALL tabs are loaded open the DM, note: its blank.
Close/Open Minefield again and as soon as the UI appears hit Ctrl+J, note the DM will fill as it should.  I have repeated this about 6 times, and every-time I let all the tabs fill, the DM is blank.  

I have no clue how to trace startup steps/routines.
Could a tracemonkey merge possible have broken js module files?
Once the DM "blank" window occurs, if you then download something it appears in the blank window without any download progress indicators.  If the DM window then gets closed, upon re-opening the latest entry that had appeared in DM has also been removed from the window and you're presented with a "blank" window again.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090729 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090729045158
Simplist would be to backout some patches and to upload the builds to tryserver for testing.
I see this -- toggling jit off didn't help. Last two nightlies, IIRC. Can anyone bisect down to a particular cset?

/be
Making some progress on the regression range. 
Changeset: http://hg.mozilla.org/mozilla-central/rev/566ec4a87812 Nightly OK
Changeset: http://hg.mozilla.org/mozilla-central/rev/f353d2b637b3 is Bad

Still a large range of patches landed, still trying to narrow it down.
(In reply to comment #22)
> Best range I can get for the builds I happened to download:

In order to get a foolproof range, could you please post the changesets that these builds were built from?
OK, more....
cset http://hg.mozilla.org/mozilla-central/rev/9dfacae57238 is OK
cset http://hg.mozilla.org/mozilla-central/rev/7fc462364b5e is broken

Leaving cset: http://hg.mozilla.org/mozilla-central/rev/a928ab3ec436 as the range, which I can't find an hourly build for...

238 changeset I used zip build from here:
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1248463050-20090724121730-9dfacae57238-firefox-3.6a1pre.en-US.win32.zip

b53 changeset I used zip build from here:
http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/1248464824-20090724124704-7fc462364b5e-firefox-3.6a1pre.en-US.win32.zip

Note for convenience at least for me, I'm only using the last 3 letter/numbers of the changeset, full changeset is above.
Assignee: nobody → general
Component: Download Manager → JavaScript Engine
Product: Toolkit → Core
QA Contact: download.manager → general
Does tracemonkey tip show the problem?

/be
I'm seeing this in both TM tip and trunk nightlies but it's very random.  Haven't been able to nail down STR.  :-(

Just encountered this issue downloading the latest trunk hourly .zip file using build: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090730044307

~B
Consistently reproduces for me going to http://taossa.com/ and clicking on the "here" link in the "BlackHat 2009 Whitepaper: Attacking Interoperability" blog item (dated July 29th, 2009).

Interesting to note that clicking on a registration-walled download-this-PDF link (haven't looked at how it works, looks like a CGI -- not a .pdf file link) in mail I regularly get, which opens a new tab per the Firefox pref default, does open the download manager, download the PDF, and successfully render the download manager's list of recent downloads.

/be
Happened to me on windows 7, fresh profile, first download.  The first download was the windows 7 sdk from: http://www.microsoft.com/downloads/details.aspx?familyid=a91dc12a-fc94-4027-b67e-46bab7c5226c&displaylang=en

Will try to see if it is reproducible after my download completes.

Sorry for the dupe.
(In reply to comment #30)
> Happened to me on windows 7, fresh profile, first download.  The first download
> was the windows 7 sdk from:
> http://www.microsoft.com/downloads/details.aspx?familyid=a91dc12a-fc94-4027-b67e-46bab7c5226c&displaylang=en

Not related to this bug, but if you have win7 RC, you should get the newer SDK for the RC. It contains a number of fixes since the beta:
http://www.microsoft.com/downloads/details.aspx?familyid=F75F2CA8-C1E4-4801-9281-2F5F28F12DBD&displaylang=en
#10 I'm seeing the "undefined" and I believe I saw the count say "2" when it should have been "1". So the count was OUT OF DATE. The out-of-dateness may be significant.

This on Linux freshly built (2 days ago) from mozilla-central on Ubuntu 9.04 Linux.
> TEST-INFO | chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_bug471962.js | Console message: [JavaScript Error: "docToSave is null" {file: "chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_bug471962.js" line: 281}]
> TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_bug471962.js | Timed out

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1249040145.1249042129.24012.gz#err2
Blocks: 438871
Whiteboard: [orange]
The download window works again for me on the past two nightly trunks.  I don't know if that is circumstantial or if another patch fixed this regression.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090731044744

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090801042759
(In reply to comment #34)
> The download window works again for me on the past two nightly trunks.  I don't
> know if that is circumstantial or if another patch fixed this regression.
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731
> Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090731044744
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801
> Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090801042759

the same for me on linux. I wonder which checkin fixed this..
confirmed fixed with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 Minefield/3.6a1pre ID:20090731044744
It does appear to be "fixed" but when I stop and restart a download I see the following in the error console:

Error: aText is undefined
Source File: file:///C:/Program%20Files/Firefox%20Trunk/firefox/modules/DownloadUtils.jsm
Line: 493
DownloadUtils.jsm: Couldn't get string 'timeLeftSingle' from property ''
DownloadUtils.jsm: Couldn't get string 'timeFewSeconds' from property ''

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090801081931

~B
It is NOT fixed, I see blank DM still!!
Until someone that can read patches and understand the code and analyze which patch in the list given in comment #25 , its not going to magically go away or fix itself.  Its down to making a best guess as to which patch broke the DM or backing out stuff and checking.  Both a slow process..
I wonder if the problem could ultimately be the declaration "let kStrings = {...}" at lines 81-96.

There's an extra, seemingly unnecessary, trailing "," after "timeUnits: ["seconds", "minutes", "hours", "days"]" (i.e. line 95).

I deleted that extra comma and so far no more problems.  Of course, this could all be coincidence.
Oops.  I should have mentioned that the file is \modules\DownloadUtils.jsm.
I am no programmer, but that comma fixed it for me also, none errors in error console while downloading now..  Must test more but looks promising...
And because I am no programmer, makes me wonder what has changed because that comma is there in Firefox 3.5 version of DownloadUtils.jsm as well, and it works as all know?
Heh... of course it had to be a coincidence.  I'm getting desperate. :-(

The comma is necessary.  Ignore me.
That comma did something but just now my DM is empty again... 
Downloads are timed on status bar though...

And that DownloadUtils.jsm did not change when DM broke...
Download Manager is indeed still blank (sometimes) with latest hourly on Vista.
I still have the DM displaying files, but it doesn't show anything about progress changes, including only updating the progress bar every few minutes.

Like in the earlier comments, I get these errors repeatedly in the JS Console "aText is undefined DownloadUtils.jsm Line 493" and "gStr.timeUnits is undefined DownloadUtils.jsm Line 477"

I don't get "download undefined", instead "One active download (Unknown time remaining)" on a file with a known size.

I wonder if something was changed in another file which hands arguments to a function like getDownloadStatus(), that function is the one--if I read the code correctly--should generate arguments that ultimately define aTime, and it's called by another file (I just don't know which one...).
Can anyone get some reliable steps to reproduce here? When it shows blank, is there a workaround (like closing it and opening again, or restarting Firefox?)

This is now nominated to block the alpha, sigh.
Priority: -- → P1
(In reply to comment #48)
> Can anyone get some reliable steps to reproduce here? When it shows blank, is
> there a workaround (like closing it and opening again, or restarting Firefox?)
> 
> This is now nominated to block the alpha, sigh.

Sadly, no.. I keep hammering on it trying to find STR, and its a total moving target.  It might work 5-6 times in a row, then out of the blue - fail.
Sometimes closing/reopening the DM will cause it to refresh and populate, other times it won't populate until close/restart of browser, and even then, I've seen it open blank right off the bat, or sometime later.  

I can't help but feel strongly there is a race-condition or some javascript getting GC'd or something.  There were several landings from TM at noted in the comment #25 , but I'm not a coder, or know anything about localized trees and testing to start doing back-outs...
adding qawanted
Keywords: qawanted
Something that could help is to find the regression window using the tracemonkey builds (the ones located on http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-MM-DD-HH-tracemonkey/). That should hopefully find a regression window with less JS related changes than comment 25.
For those experiencing the bug, does restarting Firefox / reducing the number of tabs you have open / opening and closing the download manager fix the problem?
(sorry for spam, just thought of this)

Does clearing the download history and then trying again fix it?
This is now WFM, before I cleared DM history (but I may have deleted an item or two). Sorry I can't say more. I also lost sessionstore.{js,bak} somehow recently -- I'm running m-c nightlies.

/be
> Does clearing the download history and then trying again fix it?

No.
I don't know if this is related to this issue but my DM window opens in the upper left hand corner of my screen instead of where I've moved it previously!  Basically every now and then the previous DM window state does not persist.

I also continue to experience this very random issues of the DM being blank when downloading.

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090806065318

~B
(In reply to comment #53)
> For those experiencing the bug, does restarting Firefox / reducing the number
> of tabs you have open / opening and closing the download manager fix the
> problem?

Yes, I saw this today with
Mozilla/5.0 (Windows; U; Windows NT 6.0; sk; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre
I tried to download a file, empty DM window opened in upper left corner, obviously wrong "1 download (undefined)" text appeared in the status bar and the error console was full of "gStr.timeUnits is undefined" errors (see comment 1 for detailed output). After restarting I tried to download the same file, everything went well and since then I can't reproduce this behaviour.

So it seems restarting may help here.
I can't reproduce using lastest-trunk nightly on Windows using any of the STR provided (by Brendan in comment 28, Clint in comment 30)

Those experiencing this issue, please indicate if you're using a latest trunk nightly or not?
Moving to P2 / not blocking alpha 1 on this.

Juan and Clint have both said that while they were experiencing this before, it went away with latest nightlies. I don't think we can close it yet, but I do think we can't block alpha on it, either.
Flags: blocking1.9.2? → blocking1.9.2+
Priority: P1 → P2
Using today's nightly m-c build.
I just renamed my downloads.sqlite with Minefield closed, then reopened the browser and the very 1st download attempted popped up with an empty DM. No amount of closes/reopens of the DM would fix the issue or being blank, closed/reopened the browser and now its filled.
I then started another download, zip file this time, and boom - blank DM
Once the download completed I clicked on the slider link in the lower right corner and low-behold it was filled.  Very-very strange and stay's illusive.
Flags: blocking1.9.2+ → blocking1.9.2?
Priority: P2 → P1
Tried all the builds posted in comment #52 and experienced no issues with the DM

I'm now using the latest hourly build, and so far have not been able to make it fail :(  I'm sure, as soon as I post this it will no doubt act up.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090806092832

cset: http://hg.mozilla.org/mozilla-central/rev/8df64551e067
Flags: blocking1.9.2? → blocking1.9.2+
Priority: P1 → P2
(In reply to comment #60)
> Moving to P2 / not blocking alpha 1 on this.
> 
> Juan and Clint have both said that while they were experiencing this before, it
> went away with latest nightlies. I don't think we can close it yet, but I do
> think we can't block alpha on it, either.
I'd agree with this.  Sorry for the radio silence, I'm way behind on bugmail.  I couldn't reproduce it today, much of the testing I've done in the last few days haven't reproduced the problem.  So, somehow this went away, but we can't exactly point to why :/
(In reply to comment #57)
> I don't know if this is related to this issue but my DM window opens in the
> upper left hand corner of my screen instead of where I've moved it previously! 
> Basically every now and then the previous DM window state does not persist.
> 

This is a problem I've been experiencing too, occasionally.  It's a bit worse in my case: when it does happen, all that shows is the title bar and minimize/maximize/close buttons--all squeezed to minimum width (i.e. just wide enough for the "Downloads" text and the buttons).  I then have to resize it.

However, the window size issue does not necessarily occur in relation to the blank DM.  That being said, both problems appear to have shown up in relatively close proximity, though I can't be precise.

As for the blank DM and directly related issue, it still exists.  One effect of this bug is that the updater no longer shows progress--even when DM otherwise still shows downloads during any given browsing session.

I have a new profile where I have yet to experience the issue, and will do some more testing with it.

Is it possible that some data format, schema, or user configurable pref changed within the time frame of the issue?
can someone zip up a profile where they're getting this somewhat more reproducibly?  (Put it somewhere secure if needed)

Have you tried closing Firefox, deleting localstore.rdf and reopening?

(Sorry those are the two things I'd ask for if I were doing support.  Don't mind me if you've tried both.)
I think it's a timing thing, depending on whether DownloadUtils is loaded in the DM first or in browser.js. It also depends on whether or not there are pending downloads (there can't be any), plus some other stuff I haven't been able to confirm, but I've been able to repro semi-consistently fiddling around with these things.

I'll play around a bit more tonight.
Just noticed something:

On the new profile where I wasn't seeing the blank DM, I've just observed the following:

I was downloading a 35 MB file while watching a flash video.  I browsed for the location to save the file and once DM popped up, the download was listed and the progress bar displayed, but the text read "Unknown time remaining," with bytes indicating 0. Status bar also indicated "Unknown time remaining."  At about 30 % or so complete, the timings and bytes showed up and DM was displaying the active download correctly.  At the end of the download, during the virus scan phase, the status bar once again showed showed "Unknown time remaining."  I repeated the download, saving to a different location, and the exact same thing happened.  I tried a third time: exact same thing happened.

The link to the file I was downloading is: http://www.tucows.com/preview/611051
The change that triggered this was
http://hg.mozilla.org/mozilla-central/rev/3915e2d2c748

57f03473969d seems to be fine.

I can reproduce this with a new profile (on 3915e2d2c748/Linux/x86_64) after enough downloads (of attachment 392745 [details] [diff] [review], for example.)
Blocks: 503080
This issue has occurred everyday for me at least two times each day.  Someone mentioned this before I believe but I deleted my downloads.sqlite and have downloaded more then fifty files today of various sizes (both .exe and .zip) and cannot reproduce this issue anymore.  Keeping my fingers crossed!

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090806164927

~B
I could reproduce this with 4983120bae8a (when last known regression from Bug
503080 was fixed) although less reliably.  Valgrind didn't have any unusual
complaints.

But I haven't seen this happen with d300a4725056 (last tracemonkey merge) nor
dc02eff6d8c0 (3_6a1).
By the way, my new profile, which wasn't exhibiting the blank DM dialog, finally does suffer from the problem.

Therefore, for those who say they no longer experience the problem.  I would say that your relief is likely only temporary.

So this bug will remain until it's actually fixed.
A note about this bug should be release notes for alpha 1.
Keywords: relnote
Since i have been following empty files created with write protection(Windows NTFS),
the problem is no longer exists:
XPC.mfl  XUL.mfl  xpti.dat  xpti.dat.tmp

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre
Attached image Same Bug in OS X 10.5.8
Empty Download Manager in os X as well (10.5.8)
This reproduces 100% against the WinCE Tegra builds.  Adding [nv] whiteboard for tracking.

STR: 
1) Save file as.. in context menu.  (save an image)
2) file saves, but download manager comes up blank

Build ID: Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.2a1pre) Gecko/20090806 Minefield/3.6a1pre
Whiteboard: [orange] → [orange], [nv]
Anybody on the JS team looking at this?  We even have the changeset identified that looks to have regressed this (comment 68).
Keywords: qawanted
Assigning to jorendorff, who checked in the apparently-regressing change.
Assignee: general → jorendorff
Summary: Download Manager opens 'Blank' - intermittent → Download Manager opens 'Blank' - intermittent - Error: gStr.timeUnits is undefined and download is null
Upgraded to http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1bf16951d1be (Namoroka, first time I saw that name from the nightly update) and this bug started biting again. Not at the moment, though -- unclear why but I see download history again. Will try to debug it.

/be
A bit more info: Even at times when DM is properly displaying downloads, when Software Updater is checking and downloading builds, I get the following (already noted) message in Error Console (16 in rapid succession):

Error: aText is undefined
Source file: file:///C:/Program%20Files/Internet/firefox/modules/DownloadUtils.jsm
Line: 493

And of course, no download progress information shown in the Software Update dialog.  Since this bug began, Software Update has not shown progress -- even when Download Manager is showing progress and listing downloads.

Maybe the connection between the two will help.
I would like to debug this but I can't reproduce it at all!

Probably the best thing would be to team-debug with tchung or someone else who can reproduce it reliably in a debug build. Volunteers?
(In reply to comment #82)
> I would like to debug this but I can't reproduce it at all!
> 
> Probably the best thing would be to team-debug with tchung or someone else who
> can reproduce it reliably in a debug build. Volunteers?

I'd be happy to help, but the debugging tools on the firefox tegra builds is horrible.  For example, there's no command line to output anything to.  Dolske has a physical debugger attached to his breadboard, and maybe he can shed some light if his build does the same.   But i'll try to see if we can get a debug build up and usable today, and maybe get some data for you.
I've seen this on Mac laptop, so we shouldn't need to debug this on a Tegra.
I see this on a Windows 7 desktop pretty consistently as well.
This bug affects Fennec too, as we use DownloadUtils.jsm in our download
manager code. We get "gStr.units is undefined" when attempting to call
DownloadUtils.convertByteUnits
(http://mxr.mozilla.org/mobile-browser/source/chrome/content/downloads.js#333)
(In reply to comment #84)
> I've seen this on Mac laptop, so we shouldn't need to debug this on a Tegra.

OK. I'm still in desperate need of a debug buddy, though.

The place to put the breakpoint is js_ReportIsNullOrUndefined.  (The web being what it is, surely some pages out there would trigger this a lot. But our own chrome JS should not, aside from this bug.)
When the problem occurs, it's easy to trigger the error from the error console:

Components.utils.import("resource://gre/modules/DownloadUtils.jsm"); DownloadUtils.getTimeLeft(4)
When the problems appear, a DownloadUtils logs the failure message of:

DownloadUtils.jsm: Couldn't get string 'timeUnits' from property ''

Where "property ''" is actually supposed to print out the property but turns out to be undefined.


So then all properties of gStr are undefined because _getStr fails to assign the value:

return gStr[name] = typeof value == "string" ? getStr(value) : value.map(getStr);

value turns out to be undefined instead of a string or array, so (undefined).map throws


_getStr is only called from here, and somehow value disappears but not name?

_init: function() {
  for (let [name, value] in Iterator(kStrings))
    let ([n, v] = [name, value])
      gStr.__defineGetter__(n, function() gStr._getStr(n, v));

The [n, v] are local copies of [name, value] because name and value will end up as the last [name, value] by the time the getter is triggered.

I'm assuming the GC is *not* collecting "n" because it was used in the defineGetter, but "v" isn't so lucky and disappears by the time the getter is executed.


When trying to reproduce this issue, I do seem to run in to it more after visiting big pages like amazon.com and digg.com and doing a Weave sync, so those are causing the GC to run.
> function() {
>   for (let [name, value] in Iterator(kStrings))
>     let ([n, v] = [name, value])
>       gStr.__defineGetter__(n, function() gStr._getStr(n, v));

Awesome work. Thanks, Mardak. Can you call Components.utils.forceGC() from here? Does it make the bug reproduce more reliably?
(In reply to comment #91)
> Awesome work. Thanks, Mardak. Can you call Components.utils.forceGC() from
> here? Does it make the bug reproduce more reliably?

Mardak says he can, but it does not. Also, the error mysteriously went away...

It would be very helpful to know what the actual exception is that we're squelching here:

>      } catch (e) {
>        log(["Couldn't get string '", name, "' from property '", value, "'"]);

Since we are looking at a bug inside the JS engine, the exception could be something completely unexpected and illuminating. Or not.

The patch fingered in comment 68 contains some noise about cloned Block objects, and we definitely have one of those here (being accessed via JSOP_NAME). I am still in the dark and help is welcome.
(In reply to comment #92)
> It would be very helpful to know what the actual exception is that we're
> squelching here:
> >        log(["Couldn't get string '", name, "' from property '", value, "'"]);
I was able to get the problem to trigger one time after modifying .app/../modules/DownloadUtils.jsm with "e" as part of the array.

It was "value is undefined". I don't remember the line, but the only way it should be able to trigger is from value.map.
Excellent. That makes sense and fits with the earlier stuff. It rules out a lot of sheer nonsense.

It would be even more useful to capture this in gdb in a debug build, maybe by changing the script there to call any rarely-used native function and setting a breakpoint in that:

>       } catch (e) {
>+        Components.utils.forceGC();
>         log(["Couldn't get string '", name, "' from property '", value, "'"]);

Dying to get my hands on the output of js_DumpStackFrame(cx->fp) right around there, with follow-up js_DumpObject(obj) calls on various objects along cx->fp->scopeChain.
Here's the stack frame of the getter being called with the scope change object and the parent:

JSStackFrame at 0xbfffcf10
<unnamed function at 0x174deba0 (JSFunction at 0x17586578)>
file DownloadUtils.jsm line 109
  pc = 0x1dc1bed4
  current op: call
  slots: 0x1e234cec
  sp:    0x1e234cfc = slots + 4
    0x1e234cec: <unnamed function at 0x174ea460 (JSFunction at 0x17586620)>
    0x1e234cf0: <Object at 0x174de480>
    0x1e234cf4: "timeFewSeconds"
    0x1e234cf8: undefined
  argv:  0x1e234cec (argc: 0)
  this: <Object at 0x174de480>
  rval: undefined
  flags: rooted_argv
  scopeChain: (JSObject *) 0x174deb60

object 0x174deb60
class 0x43f420 Block
properties:
    enumerate permanent shared "n": slot -1
    enumerate permanent shared "v": slot -1
proto <Block object at 0x174e1ae0>
parent <Block object at 0x174de640>
private 0x0
slots:
   3 (reserved) = 4

object 0x174de640
class 0x43f420 Block
properties:
    enumerate permanent shared "name": slot -1
    enumerate permanent shared "value": slot -1
proto <Block object at 0x174e1a80>
parent <Call object at 0x174de4e0>
private 0x0
slots:
   3 (reserved) = 0
To clarify, I modified DownloadUtils.jsm to call forceGC on exception with a breakpoint at js_GC to get the frame/scope chain blocks.

This seems to trigger the problem from time to time on my main profile:

Cu = Components.utils; Cu.import("resource://gre/modules/DownloadUtils.jsm"); DU = DownloadUtils; DU.getTimeLeft(-1); Cu.forceGC(); DU.getTimeLeft(1);
Some notes: Besides the JS issue, this screen shot in windows shows the status line text as well as the blank download window.  Not sure if the JS issue plays into the status line at the bottom at the browser which shows the file is an undefined type downloading.  As in this case it is a podcast/MP3 file.  Modifying the Remember download history perf doesn't affect the download window display either turning it off and on again.
I've reproduced this blank window 4 times in a row on a tryserver built rev 9428880490ce BH_20090817.  I went to the twit.tv site and I've only tried to download MP3 podcasts with this build.  

I haven't closed the browser yet and its the only file type I tried to download with this build. I adjusted the perf. Between Save-Link As-> initiations, but it has not updated the download window screen with the 4 MP3 files I downloaded.

I'm not sure what codebase the tryserver build is based off of though.
Tryserver build Note: 

The tryserver build might be based on the nightly code base as its labeled as 3.7a1pre and non of my Firefox add-ons work.

Restarted Browser Followup Behavior:

I did a browser restart, went back to the same web page.  Right clicked Save Link As-> and all the download history came up in the download manager window.  The screen status text changes to a timer as shown in this screen shot.  Its shows all my downloads for this profile including those downloads I did on an older build in the same install folder.

A few things to note:
 
I installed the build, downloaded files over and over again, the browser window was blank.  Second, did a restart, went back to exact same web page and tried to download the same files and the download manager history came back.  I had Remember Download History off/on between downloads, but checked between a browser restart.  The window shows history every time I try to download again. 

--Hope that clarifies more of the behavior we're seen, and hopefully the JS can get figured out.
gczeal (forces a GC on every allocation, etc) might help make this bug reproducible.  But I'm not sure how to use it nowadays.
There's an --enable-gczeal option to configure.
I've got some STR that seems to always work for me on Minefield 0818:

1) create a new profile
2) restart minefield saving session
3) open error console and paste in

Cu = Components.utils; Cu.import("resource://gre/modules/DownloadUtils.jsm"); DU = DownloadUtils; DU.getTimeLeft(-1); Cu.forceGC(); DU.getTimeLeft(1);

(It should say "A few seconds remaining,1")

4) restart minefield saving session
5) open error console again and paste in the above

This time it results in the error/warning.

Not sure why it only triggers on the third time, but once it does, you can restart and do the error console thing again and it'll trigger again.
Could this be a bug in XDR?
> I've got some STR that seems to always work for me on Minefield 0818:

This reproduces for me in locally built tracemonkey tip on Mac.  W00t, thanks Mardak!
Jason, since we looked at all the changesets, can't we just review the bug and patch that turned this into a bug and reverse engineer the problem?
Feel free.
Sorry, I was rude. What I mean to say is, I re-reviewed the patch that caused this regression and couldn't figure out what might have caused this. But of course more eyes on that code are welcome.

Unfortunately this doesn't reproduce (reliably anyway) in gdb, so I'm printf-debugging.

I just discovered that the JSScope being shared by this Block object, its proto, and presumably a bunch of other Block objects, is owned. It shouldn't be. Probably XDR; at least I sure hope so.

(The long story: js_PutBlockObject is being called, and it sets the Block object up correctly, but during GC, js_TraceObject is calling js_ShrinkSlots which nulls out obj->dslots. At that point the Block object is wounded, and if I get through this alive, I'll add assertions to the engine to detect this situation. IIUC, the precise change that caused this regression was to stop allowing scopes to be both owned and shared. That was an intentional change; I just missed a spot where it happens!)
(In reply to comment #107)
> Unfortunately this doesn't reproduce (reliably anyway) in gdb
I'm not sure if this will help more, but if it doesn't fail for the second getter after the first forceGC, you can try other getters for other properties:

Cu = Components.utils; Cu.import("resource://gre/modules/DownloadUtils.jsm"); DU = DownloadUtils; DU.getTimeLeft(-1); Cu.forceGC(); DU.getTimeLeft(1); Cu.forceGC(); DU.getTimeLeft(5); Cu.forceGC(); DU.convertTimeUnits(1); Cu.forceGC(); DU.convertByteUnits(1); Cu.forceGC(); DU.getDownloadStatus(1234567, 2345678900, 3456)
Attached patch v1Splinter Review
The probable fix.  Writing a test for this now.
Comment on attachment 395342 [details] [diff] [review]
v1

The test is in bug 505798. This patch fixes it.
Attachment #395342 - Flags: review?(brendan)
(In reply to comment #84)
> I've seen this on Mac laptop, so we shouldn't need to debug this on a Tegra.

fwiw, I'm seeing this consistently on my mac using the FF3.5.2 release build: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

Also, this is reproducing consistently for me running on OSX10.5.8, and was also last week when I was still running on OSX10.5.7.

HTH
John.
Comment on attachment 395342 [details] [diff] [review]
v1

Whew. Thanks to everyone who helped nail this.

/be
Attachment #395342 - Flags: review?(brendan) → review+
http://hg.mozilla.org/mozilla-central/rev/addb1c7c8f77

If someone would like to confirm this in the next hourly/nightly, I'd be much obliged. Thanks again to everyone who helped.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Jason, thanks.  Looks like its working in the latest hourly, but haven't seen it blank yet.  Well keep our fingers crossed. :)
Still Blank....
(In reply to comment #116)
> Still Blank....
On *what*?  You comment is not at all helpful unless you give us a build ID that you see it being blank.
It's version 3.6a2pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090822 Namoroka/3.6a2pre (.NET CLR 3.5.30729) is this what you need...
This was fixed on the trunk.  Your using a 1.9.2 branch build.  

BE, Jason - Which I'm assuming since this is 1.9.2 blocker and nominated?  Will this get pushed on the branch?  As it probably hasn't been yet.
Attachment #395342 - Flags: approval1.9.2?
Attachment #395342 - Flags: approval1.9.2?
Comment on attachment 395342 [details] [diff] [review]
v1

Do not need approval for 1.9.2 because this bug is a blocker.
Waiting for a push to the 1.9.2 branch.
Keywords: checkin-needed
Still blank tonight.
(In reply to comment #123)
> Still blank tonight.
I was landed nine hours ago.  Nightly builds have not been produced for it yet (wait at least another 12 hours).
Removing relnote.
Keywords: relnote
I am having problem with blank download box and no download.  Problem appeared for a few weeks in early October.  There was resolution for about a week - starting around the 15th or so - and now I can't download the .doc any longer.  I can't even pull up the document to look at it, much less download to print.  I can see and download .docx documents.  Also, I have no trouble with acrobat, powerpoint, etc.
?? Still have this problem with 3.5.6, upgraded to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
download manager is still blank (white).
Patrik: This bug is fixed for Firefox 3.6, and it was introduced only in nightly "trunk" builds and 3.6 nightlies/betas. You should file a new bug, after first looking a bit for existing ones and trying support forums.

/be
Whiteboard: [orange], [nv] → , [nv]
You need to log in before you can comment on or make changes to this bug.