Closed Bug 731720 Opened 13 years ago Closed 4 years ago

Hangs on logging into Evernote

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox11 --- unaffected
firefox12 --- affected
firefox13 --- affected

People

(Reporter: akeybl, Unassigned)

References

Details

(Keywords: hang)

Attachments

(5 files)

Evertnote Network Waterfall
465.47 KB, image/png
Details
MemChaser log
4.42 KB, text/plain
Details
Instruments trace (hang)
1.62 MB, application/zip
Details
Instruments trace (no hang)
1.79 MB, application/zip
Details
Screenshot (Instruments)
22.75 KB, image/jpeg
Details
STR: 1) Go to https://www.evernote.com/Home.action 2) Type in your username/password 3) Sign in Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0 ==> No hang Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0a2) Gecko/20120229 Firefox/12.0a2 ==> No hang Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120226 Firefox/13.0a1 ==> Hangs for a couple of seconds before loading
Adding qawanted to see whether this reproduces for others.
status-firefox11: --- → unaffected
status-firefox12: --- → unaffected
status-firefox13: --- → affected
tracking-firefox13: --- → +
Keywords: qawanted
Keywords: regressionwindow-wanted
Not reproducible for me on Fedora 16 x64.
(In reply to Alex Keybl [:akeybl] from comment #1) > Adding qawanted to see whether this reproduces for others. I've forwarded this to the QA team for investigation. In the meantime, can you use http://harthur.github.com/mozregression/ to determine where the regression happens on your end?
No hang for me on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120229 Firefox/13.0a1, thought there does seem to be a more-noticeable *delay* on my Mac nightly, Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120229 Firefox/13.0a1
Thanks Stephen. Evidence so far seems to indicate this is Mac-only.
OS: All → Mac OS X
I saw no noticeable hang on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120228 Firefox/13.0a1 (Mac OS X 10.7.3)
This is significantly less pronounced when running the mozregression tool. From 1-2s hangs on loading down to less than a half a second now that I'm using mozregression. Trying to reproduce again on FF13 also yields half second loads. Perhaps this is something that builds up over time?
Do you have memchaser installed? https://addons.mozilla.org/en-US/firefox/addon/memchaser/ If not, it might be worth installing to determine if any GC/CC issues are happening.
Did not hang for me using the latest Mac nightly on 10.7.3 as well as the latest nightly on Win 7.
I have attached a waterfall of signing in to Evernote. They do some big downloads and they break a number of best practises for client side performance. E.g. JavaScript downloads in <head> I could reproduce a slow loading page but the browser didnt hang
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8) > Do you have memchaser installed? > https://addons.mozilla.org/en-US/firefox/addon/memchaser/ > > If not, it might be worth installing to determine if any GC/CC issues are > happening. I'll make sure to try this as soon as possible. (In reply to David Burns :automatedtester from comment #10) > I could reproduce a slow loading page but the browser didnt hang The hang lasted for only a couple of seconds when I could reproduce (UI unresponsive, beach balled for a moment I believe).
Alex I have experienced a hang with an Aurora build from Feb 26th but not with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0a2) Gecko/20120227 Firefox/12.0a2 ID:20120227042012 It's right after a restart. So not sure if even that fixed the problem. I will try investigate this.
Keywords: hang
Severity: normal → critical
status-firefox12: unaffected → affected
Henrik, have you had a chance to look into this further?
Attached file MemChaser log —
I currently have seen it again with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0a2) Gecko/20120304 Firefox/12.0a2 Firefox was running for a couple of days now and I have never upgraded. So I would assume the following: * Hibernation mode could play into here * High memory usage is related to it * Extensions shouldn't affect that strange behavior because it works right after a restart Attached you can find a MemChaser log of the login process.
CCing Steven, who could probably help us to get it better analyzed on OS X.
It looks like that this issue is really related to the handling of memory. During the login process we spend a lot of time in __mmap. Here an excerpt of the trace recorded with Instruments on OS X 10.7: Running Time Self Symbol Name 8783.0ms 52.4% 8783.0 vm_map_enter 8713.0ms 52.0% 0.0 vm_map_enter_mem_object 8679.0ms 51.8% 0.0 mmap 8679.0ms 51.8% 0.0 unix_syscall64 8679.0ms 51.8% 0.0 __mmap 19.0ms 0.1% 0.0 mem_allocate 19.0ms 0.1% 0.0 ripl_Create 3.0ms 0.0% 0.0 JSC::ExecutableAllocator::systemAlloc(unsigned long) 12.0ms 0.0% 0.0 bsdthread_create 11.0ms 0.0% 0.0 mach_vm_server_routine 9.0ms 0.0% 0.0 device_data_action 2.0ms 0.0% 0.0 workqueue_exit 66.0ms 0.3% 0.0 mach_vm_allocate 3.0ms 0.0% 0.0 kernel_preempt_check 1.0ms 0.0% 0.0 ml_set_interrupts_enabled Attached you will find the full trace for investigation. When checking the sample list you will see that it starts right after some js:Parser method calls. Also other parser calls have been made throughout the whole hang. Could it be related to the parser? I will no restart Aurora and create another trace so we have a base line to compare with.
This is a trace when Firefox doesn't hang.
As you can see in the screenshot it takes way longer for the seconds run (which is the one with the hang) to login to Evernote.
In the next couple of days I will run the latest beta of Firefox 11.0 and check if that branch is also affected.
Anybody see these hangs on OS X 10.6.8, or 10.5.8? So far it looks like they've only been reported on OS X 10.7.X. And it also looks like they're quite difficult to reproduce even there. I'll try to do some testing later this week.
By the way, when people say "hang" do they just mean a long delay? Or does the UI become unresponsive, and does the mouse cursor turn into a beachball? Only the second is a true "hang".
Yes, there are about 5 seconds where the beachball is shown.
Henrik, by any chance can you do the following? 1) Make a custom, debug build. 2) Run it in gdb, and break when you get a hang. 3) Enter 'thread apply all bt' to get a stack trace of all threads. 4) Attach the output here.
I still don't have reproducible steps. The last time it has taken me about 1 week to be able to reproduce. Also it only happens in my daily profile with a high usage. So as long as I don't have STR I don't think running a second instance would be helpful. Also I don't want to run a Nightly Debug build with my daily profile. I could think about a debug build of Aurora once I have finished testing with Beta.
Quite frankly, if this bug is so difficult to reproduce, I'm not going to get to it anytime soon. Also, only the information I request in comment #23 would be really useful. Hangs are a sign of thread contention, and only that information can tell us which threads are in contention, at which parts of the code.
I've now tried to reproduce these hangs on OS X 10.7.3, using an opt custom build with the symbols not stripped. Not surprisingly, I failed. This bug will probably be intractable until we either get reliable STR or someone does what I ask in comment #23. If we can't achieve either of these things in the next week or so, I think we should stop tracking this bug.
Given discussion in the channel meeting we will not track this anymore. If someone can come up with a reproducible testcase, please re-nom.
tracking-firefox13: + → ---
Keywords: qawanted
I haven't seen this for a while. I'm now on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120516 Firefox/14.0a2 ID:20120516042006
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #27) > Given discussion in the channel meeting we will not track this anymore. If > someone can come up with a reproducible testcase, please re-nom. I've done some regressionwindow tests that I hope will fix this. Here are my results for OS Mac 10.7.5: Last good nightly: 2012-03-13 First bad nightly: 2012-03-14 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ca7a94573f2&tochange=c71845b3b2a6
Mario, this is a great start! Would you be able to continue with an hg bisect and compiling Firefox yourself? We can help you on that. It would be necessary to find the real causing changeset. Otherwise do you have a testcase which reproduces the problem for you all the time?
(In reply to Henrik Skupin (:whimboo) from comment #30) > Mario, this is a great start! Would you be able to continue with an hg > bisect and compiling Firefox yourself? We can help you on that. It would be > necessary to find the real causing changeset. Sorry for delay. I have made a hg bisest trying to find the real causing changeset. I have made this twice and in both cases I have found same changeset as causing this issue. HG Bisect done on Mac OS 10.7.5 with following results: The first bad revision is: changeset: 88847:17de225179ac user: Fabrice Desré <fabrice@mozilla.com> date: Mon Mar 12 17:33:10 2012 -0700 summary: Bug 697006 - Add desktop support for the Open Web Apps API - Part 1 : enable mozApps on desktop [r=gavin] Hope this is the right changeset and it will fix this issue.
Keywords: regressionwindow-wanted
In addition after doing some manual tests using checkout command for the other build changesets around 17de225179ac, I found this issue more visible for the following changeset: changeset: 88847:374977a5f8c6 user: Fabrice Desré <fabrice@mozilla.com> summary: Bug 697006 - Add desktop support for the Open Web Apps API - Part 2 : UI [r=gavin]
Thank you Mario! That's really helpful. I will CC the original author of the patch and Gavin, who might be able to help out on this bug.
Blocks: 697006
That patch just enabled a larger feature in Firefox desktop. That suggests that the slowness is somehow related to that feature, which seems odd.
Mario, can you please tell us the step you are using to reproduce this problem? We are still missing those for further investigation. Thanks!
I have reproduce this problem following STR from Comment 0 with new profile. In addition I could reproduce this issue with and without HWA. There is something that looks odd: Using for the first time evernote on a new profile, it hangs for a couple seconds (4-5) even for all the changesets done before the one mentioned in Comment 31 and Comment 32, but reloging it works as expected. I can see in awesome bar that it tries to redirect to another link and only after that, the page is displayed https://www.evernote.com/Home.action#st=p&n=60e5ed39-58e6-4f28-b11e-2d4441d237b7 Starting with changeset mentioned in Comment 31, it hang all the time even if you have logged before on that profile or not. I can make a screencast if you this it could help.

I was unable to reproduce this
tested it on Windows 10 64bit and also MacOs 10.14
Using Firefox Release 85 and Firefox ESR 78.7.0

no hangs were shown, I was able to login to https://www.evernote.com/Home.action

marking this bug as Resolved, works for me.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: