1180582 - On occasion Firefox {39.0,39.0.3,40.0,40.0.3,41.0.1,41.0.2,42.0,43.0.1,43.0.2} doesn't start, drives kernel memory consumption up and makes no progress

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Steve Chessin]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

I had an iPhone 4s (in Airplane mode but with WiFi on and connected) plugged into my MacBookPro when I started Firefox. Firefox went into "not responding", and both Firefox and kernel memory consumption went up.


Actual results:

Firefox went into "not responding", and both Firefox and kernel memory consumption went up.


Expected results:

Firefox should have started up with reasonable memory consumption.

Comment 1

[Steve Chessin]

I will attach three files showing what Activity Monitor displays for memory consumption:
1.memory.before.png - The state of memory consumption before starting Firefox (the iPhone is connected to the MacBookPro for charging purposes).
2.memory.loading.Firefox39.0.iPhone.connected.png - The state of memory consumption after starting Firefox with the iPhone still connected to the MacBookPro. It goes into "Not responding" mode and I have to Force Quit it.
3.memory.running.Firefox39.0.iPhone.not.connected.png - I killed Firefox, disconnected the iPhone from the MacBookPro, and restarted Firefox. This is what Activity Monitor showed after Firefox finished opening all of its windows.

I note the same thing happened with Firefox 38.0.5.

Comment 2

[Steve Chessin]

Attachment: 1.memory.before.png

Comment 3

[Steve Chessin]

Attachment: 2.memory.loading.Firefox39.0.iPhone.connected.png

Note kernel_task has grown from 694.5 MB to 2.70 MB (and was still increasing).

Comment 4

[Steve Chessin]

Attachment: 3.memory.running.Firefox39.0.iPhone.not.connected.png

Comment 5

[Steve Chessin]

Another data point. This morning at home I Quit Firefox, Quit Thunderbird, and Shut Down my MBP. I bring it to work and restart it. After all my usual applications come up (except Firefox and Thunderbird, of course, because I Quit them before the Shut Down), I turn off WiFi and connect the Ethernet cable to the office intranet (which goes through a firewall and proxy to get to the external network; the firewall blocks certain ports). I restart Thunderbird (31.7.0), and then I restart Firefox (39.0). After bringing up one window (with New Tab showing in all the tabs), it goes "(Not Responding)" and kernel_task memory consumption starts to climb, quickly driving memory pressure into the red.

So I Force Quit Firefox and bring up Firefox 38.0.5 and it comes up fine.

I'm running MacOS X 10.9.5. I'm going to stick to 38.0.5 until there's a fix for the kernel memory problem.

Comment 6

[Steve Chessin]

Changing subject from
Having iPhone connected when starting Firefox results in huge memory consumption
to
Certain circumstances (including having iPhone connected) when starting Firefox results in huge memory consumption and no progress
because not being able to use it at work is a bigger problem for me.

Comment 7

[Steve Chessin]

This time I tried starting Firefox 39.0 at home and the same thing happened; kernel consumption went up into the red zone. Firefox 38.0.5 came up with no problem. Changing subject to:

Firefox 39.0 won't start, drives kernel memory consumption up and makes no progress

I only got it to start once, so am thinking the iPhone thing might be a red herring. OTOH, having the iPhone connected also interfered with starting 38.0.5, so it might be a clue.

Comment 8

[:Gijs (away/busy until Mar 10)]

Steve, are you able to reproduce this if you start Firefox in safe mode? (hold down shift when starting firefox, or start from the commandline with the --safe-mode option)

Comment 9

[Steve Chessin]

Attachment: Held the shift key down while starting Firefox 39.0

Comment 10

[Steve Chessin]

(In reply to :Gijs Kruitbosch from comment #8)
> Steve, are you able to reproduce this if you start Firefox in safe mode?
> (hold down shift when starting firefox, or start from the commandline with
> the --safe-mode option)

I started Firefox 39.0 while holding down the shift key as you requested, and a similar thing happened. However, as the attachment shows, kernel memory consumption went up, then down, then up again, as opposed to just going up.

I held the shift key down before I clicked on the Firefox 39.0 icon in the dock, and kept it held down until the first window appeared, as I don't know when Firefox notes that the shift key is down.

I do note that https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode says one starts safe mode by holding down the *option* key (not the shift key), so I will try that next.

Comment 11

[Steve Chessin]

Ah, the *option* key is how one gets safe mode. And Firefox 39.0 came up with no problems in safe mode. I will now go through the process outlined at https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems to see what is causing the problem.

Comment 12

[:Gijs (away/busy until Mar 10)]

(In reply to Steve Chessin from comment #10)
> I do note that
> https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-
> mode says one starts safe mode by holding down the *option* key (not the
> shift key), so I will try that next.

Gah, I'm sorry. I didn't realize that was different only on mac. It's shift on windows and linux. Platform conventions and all that...

(In reply to Steve Chessin from comment #11)
> Ah, the *option* key is how one gets safe mode. And Firefox 39.0 came up
> with no problems in safe mode. I will now go through the process outlined at
> https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-
> problems to see what is causing the problem.

Note that the problem might be hardware acceleration rather than add-ons... if you go to the Preferences, then Advanced, then the "general" subpane, there's a checkbox ("Use hardware acceleration when available") that you could try un-toggling.

Comment 13

[Steve Chessin]

(In reply to :Gijs Kruitbosch from comment #12)
> (In reply to Steve Chessin from comment #11)
> > Ah, the *option* key is how one gets safe mode. And Firefox 39.0 came up
> > with no problems in safe mode. I will now go through the process outlined at
> > https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-
> > problems to see what is causing the problem.
> 
> Note that the problem might be hardware acceleration rather than add-ons...
> if you go to the Preferences, then Advanced, then the "general" subpane,
> there's a checkbox ("Use hardware acceleration when available") that you
> could try un-toggling.

Yes, that procedure is specified at
https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems
First disable hardware acceleration.
Then try the default theme.
Then disable add-ons, and add them back (either one at a time or use binary search).

I think my 40+ years experience as a software engineer will help me here :-).

Comment 14

[Steve Chessin]

Here's my progress so far:
Troubleshooting steps:

1. Does it happen in Safe Mode?
No.

2. Does it happen with hardware acceleration turned off?
Yes, so that's not the problem.
Go back to Safe Mode, turn acceleration back on, and go to the next step.

3. Does it happen with the default theme?
I am using the default theme; Add-ons -> Appearance only shows the default theme. So yes, it does happen with the default theme. Go to the next step.

4. Does it happen with  all extensions disabled?
Oops. I apparently didn't disable all of them. But it doesn't happen with these extensions enabled:
Bobsled by T-Mobile (usually disabled anyway)
Flashblock

5. Turn on extensions, either one at a time or use binary search.
My extensions:
Add to Search Bar
Better Bug
Bobsled by T-Mobile (usually disabled anyway)
Flashblock
NoScript
Troubleshooter
WOT

Trying with these extensions enabled:
Add to Search Bar
Better Bug
Flashblock
NoScript

Problem does not occur.
Now enable Troubleshooter and restart.

Problem does not occur.
Now enable WOT and restart.

Problem occurs. So WOT is a factor. Need to see if it's just WOT.
So restart in Safe Mode, disable all extensions *except* WOT, and restart.

Problem does NOT occur!
Oh, great, it's an extension interaction problem! So now I have to binary search again with WOT enabled to see what other extensions are involved. This could take the rest of this morning and all afternoon!

Comment 15

[Steve Chessin]

Try with these extensions enabled:
Add to Search Bar
Better Bug
Flashblock
WOT

Problem does not occur. So try with these extensions enabled:
NoScript
Troubleshooter
WOT

Problem does not occur. So it's more than two extensions including WOT, it has to be some combination of the above. Try with these:
Better Bug
Flashblock
NoScript
Troubleshooter
WOT

Problem occurs. Now try with these:
Add to Search Bar
Flashblock
NoScript
Troubleshooter
WOT

Problem does NOT occur. So need at least WOT and Better Bug, and can rule out Add to Search Bar. Let's try just these two again:
Better Bug
WOT

Problem does not occur. Let's add Troubleshooter:
Better Bug
Troubleshooter
WOT

Problem does not occur. Let's add Flashblock:
Better Bug
Flashblock
Troubleshooter
WOT

Problem does not occur. Let's add NoScript (problem should occur):
Better Bug
Flashblock
NoScript
Troubleshooter
WOT

Problem does NOT occur!?! This makes no sense. Let's add back Add to Search Bar:
Add to Search Bar
Better Bug
Flashblock
NoScript
Troubleshooter
WOT

Problem does not occur. Okay, I give up. So much for my 40+ years of programming experience. Time to get lunch. How does one debug this?

Comment 16

[Steve Chessin]

Hi, Gijs. Any advice you (or anyone else) can give me on debugging this further would be most appreciated, as apparently this is more than just a simple extension issue.

Comment 17

[:Gijs (away/busy until Mar 10)]

(In reply to Steve Chessin from comment #16)
> Hi, Gijs. Any advice you (or anyone else) can give me on debugging this
> further would be most appreciated, as apparently this is more than just a
> simple extension issue.

Sorry for not getting back to you immediately after you posted your responses, I'm a little distracted by all the windows 10 work I'm supposed to be doing. "needinfo" is very effective though, so thanks for using that.

Yeah, err, I'm afraid I'm as stumped as you are as to what's going on here. :-\

Is there any way to get Firefox out of its "not responding" state once it gets into it (apart from killing it)?

After you finished trying to look at which add-ons were causing this, you didn't have the problem the first time you started with that set of add-ons (not in safe mode), but then did it come back at some point? How quickly? If it happens on the second/third startup, the best I can suggest is redoing the search for the busted add-on but running Firefox a number of times to confirm a combination of add-ons is really "OK" vs. just "mostly not OK but maybe I got lucky". Or something. :-\

I'd also make sure that when you start Firefox with the newly enabled/disabled set of add-ons, you're sure you're not in safe mode (it does other things, like making JS slower because it disables some optimizations).


One other thing you could try is narrowing down which version of Firefox broke stuff for you. We publish a lot of builds, and you could consider using mozregression: http://mozilla.github.io/mozregression/ . This is a commandline tool that will let you basically say that it worked in 38 and broke in 39, and then do a binary search with temporarily-downloaded copies of Firefox's nightly builds in that range, to see if we can narrow down when this broke. Make sure you pass it your profile path so it uses that to test with. I'm not 100% sure this will work well if it's dependent on add-ons that might break when used with nightly builds that enable e10s though... If it doesn't work well because it disables add-ons or something, you could try checking, for instance, if you saw this with the first beta build of 39. Or, for that matter, if maybe it's already fixed in the first beta build of 40...

Comment 18

[Steve Chessin]

The past 20+ years of my 40+ programming/debugging experience is with SPARC Solaris (nee SunOS), and before that 4.2BSD on the IBM RT PC, and before that MVS (and more stuff even less relevant to this issue before that). I haven't tried debugging MacOS applications. I see that, in addition to Force Quit, Activity Monitor allows me to send a signal (of which at least two, SIGQUIT and SIGABRT, should produce a core dump, at least if MacOS adheres to traditional Unix semantics), "Sample Process" (kind of like gprof?), and "Run Spindump" (I'm not sure what that does; the man page says it "samples user and kernel stacks for every process in the system", and the output I just observed seems to support that). The default action for all the signals Activity Monitor will send, except SIGINFO, is to terminate the process. (The default for SIGINFO is to discard it.) I suppose I could try sending a SIGINFO the next time this happens to see what happens.

So far the problem hasn't reproduced, but then I don't restart Firefox all that often, and as far as I can tell this is a startup problem. Once Firefox is up, it seems to stay up.

I suppose I could try the conditions that first produced it (namely, starting Firefox while I had an iPhone 4s connected to a USB port). I note that that also produced the symptom in 38.0.5 (nothing else has).

If and when I can get it to reproduce, what information would be most useful to the Firefox internals folks? Given how kernel memory consumption grows, I speculate Firefox is in some kind of loop (so "not responding" to keystrokes and other messages, such as Quit), issuing some system call that causes the kernel to allocate memory. But not being familiar with Mach (which I think was the basis for NextStep which I think was the basis for MacOS X), I'm not sure what that might be.

Comment 19

[Steve Chessin]

This morning, after updating Flash, I performed my weekly reboot of my machine. When I started Firefox 39.0, it went into that not-responding state, so I captured a "sample" (twice) and a spin dump (twice), all of which I will attach. I then sent it a SIGQUIT, but I couldn't find the core file. (The SIGQUIT also caused a "Problem Report for Firefox" to be produced, and I'll attach that as well.) So I read "man core" and discovered that core dumps are disabled by default and learned how to enable them. So I enabled them and restarted Firefox 39.0 and when it got into the Not Responding state sent it a SIGQUIT. It took about 40 minutes for it to write out the 5GB core file; I'll only attach that if requested.

Let me know if there's anything else I should do.

Comment 20

[Steve Chessin]

Attachment: First sample of Not Responding Firefox 39.0

Comment 21

[Steve Chessin]

Attachment: First spindump of Not Responding Firefox 39.0

Comment 22

[Steve Chessin]

Attachment: Second sample of Not Responding Firefox 39.0

Comment 23

[Steve Chessin]

Attachment: Second spindump of Not Responding Firefox 39.0

Comment 24

[Steve Chessin]

Attachment: Content of Problem Report for Firefox

Comment 25

[Steve Chessin]

Hi, Gijs, do any of the new attachments help? Should I upload the 5GB core file?

Comment 26

[Steve Chessin]

For what it's worth, here's some more (anecdotal) data:

I had been running Firefox 38.0.5 since I rebooted my MacBookPro on Monday, and Quit it this (Thursday) afternoon because its memory consumption had grown to the point that my machine was swapping (I don't think this is a leak, just I have a lot of tab groups with lots of tabs and as I visit them over the course of a few days, forcing them to reload, memory consumption naturally increases). (Mozilla crash reporter came up during the Quit, which surprised me. I hope that report got to you folks.) I decided to see if Firefox 39.0 would start; it went into Not Responding with kernel memory going into the red zone, so I did a Force Quit.

I then started Firefox 38.0.5. As it started to come up it opened a tab so NoScript could tell me I was running the latest version; I clicked the "x" to get rid of it, but it didn't go away, and 38.0.5 went Not Responding with kernel memory going into the red zone, so I did a Force Quit on that.

Now I had a problem. I need a browser, and neither was working. I decided to try Firefox 39.0 again. To my surprise, it came up with the "We're having trouble recovering your session" window, and gave me the option of removing tabs or starting from scratch. I went down the list, deselected just the NoScript tab, and clicked Restore. To my surprise, Firefox 39.0 came up!

I don't know if this means NoScript is the culprit; I do know that NoScript doesn't "congratulate" me every time I restart Firefox, but I haven't bothered to determine what triggers its "congratulations". I just looked and yes there is a noscript.net cookie with an expiration date of August 4th; maybe that's when it will next try to congratulate me? I guess I can do a series of experiments, seeing how the presence or absence of the cookie affects the starting of FF39.0, but first it'd help me to know where in the filesystem cookies are stored so I can easily put it back after "deleting" it.

Comment 27

[Steve Chessin]

Hi, Gijs. Welcome back. Should I upload the core file?

Comment 28

[:Gijs (away/busy until Mar 10)]

(In reply to Steve Chessin from comment #27)
> Hi, Gijs. Welcome back. Should I upload the core file?

Thanks for the needinfo! No, it is likely to be more useful if you can go to about:crashes in your now-working browser, and copy/paste the crash IDs, because per

> Mozilla crash reporter came up during the Quit, which surprised me. I hope that report got to you folks.

we should have one, but I don't think I have access to the part of our crash stat repo that lets me search for your email address or something else that would identify your report, other than its crash ID. So if you can provide the crash ID that would be helpful.

I'll also needinfo smichaud and mstange and see if they can help look at the spindumps/samples and what those tell us. Thanks for all the extra information!

Comment 29

[Steven Michaud [:smichaud] (Retired)]

I don't have an iPhone, and never will.  So I won't be able to work on this bug.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

However at some point in the next few days I'll try connecting an Android phone.  You connected your phone via USB, right?  And what is "WOT"?

Comment 31

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #30)
> However at some point in the next few days I'll try connecting an Android
> phone.  You connected your phone via USB, right?  And what is "WOT"?

I did connect the phone via USB, but that might be a red herring.

"WOT" is Web of Trust; it let's you know (based on crowd-sourcing) if a website is suspected of containing malware and/or being unsafe for children.

Comment 32

[Steve Chessin]

(In reply to :Gijs Kruitbosch from comment #28)
> (In reply to Steve Chessin from comment #27)
> > Hi, Gijs. Welcome back. Should I upload the core file?
> 
> Thanks for the needinfo! No, it is likely to be more useful if you can go to
> about:crashes in your now-working browser, and copy/paste the crash IDs,
> because per
> 
> > Mozilla crash reporter came up during the Quit, which surprised me. I hope that report got to you folks.
> 
> we should have one, but I don't think I have access to the part of our crash
> stat repo that lets me search for your email address or something else that
> would identify your report, other than its crash ID. So if you can provide
> the crash ID that would be helpful.

These are the three most recent (I did a copy-and-paste; I don't know why the formatting is messed up):

Submitted Crash Reports
Report ID 	Date Submitted
bp-49e9c4cf-38a1-495e-9dac-4e3202150730
	7/30/15	2:42 PM
bp-6c7c20cf-0817-4e47-99b8-bc2412150724
	7/24/15	2:27 PM
bp-657e46a3-2988-42b0-9433-30ced2150719
	7/18/15	10:22 PM

Comment 33

[Steve Chessin]

(In reply to Steve Chessin from comment #32)
> (In reply to :Gijs Kruitbosch from comment #28)
[...]
> > we should have one, but I don't think I have access to the part of our crash
> > stat repo that lets me search for your email address or something else that
> > would identify your report, other than its crash ID. So if you can provide
> > the crash ID that would be helpful.
> 
> These are the three most recent (I did a copy-and-paste; I don't know why
> the formatting is messed up):
> 
> Submitted Crash Reports
> Report ID 	Date Submitted
> bp-49e9c4cf-38a1-495e-9dac-4e3202150730
> 	7/30/15	2:42 PM
> bp-6c7c20cf-0817-4e47-99b8-bc2412150724
> 	7/24/15	2:27 PM
> bp-657e46a3-2988-42b0-9433-30ced2150719
> 	7/18/15	10:22 PM

Note that these are from attempts to Quit 38.0.5; they may indicate a problem but probably not the one I'm having with 39.0.

Comment 34

[Steve Chessin]

(In reply to Steve Chessin from comment #26)

> I don't know if this means NoScript is the culprit; I do know that NoScript
> doesn't "congratulate" me every time I restart Firefox, but I haven't
> bothered to determine what triggers its "congratulations". I just looked and
> yes there is a noscript.net cookie with an expiration date of August 4th;
> maybe that's when it will next try to congratulate me? I guess I can do a
> series of experiments, seeing how the presence or absence of the cookie
> affects the starting of FF39.0, but first it'd help me to know where in the
> filesystem cookies are stored so I can easily put it back after "deleting"
> it.

Well, I don't think NoScript is the culprit. I was doing some browsing and FF went into Not Responding with kernel memory consumption going into the red zone. (This is the first time I've seen this happen at other than start-up!) I did a Force Quit, started it in Safe Mode, disabled NoScript, and started it in regular mode. (This was the control.) It came up. I checked cookies, saw there were some from NoScript, so deleted them and restarted FF. It still came up. But it didn't congratulate me on having the latest, nor did it recreate the cookies, so I'm not sure what's going on.

Oh, when it came up in Safe Mode, it came up with the "Well, this is embarrassing" window. The only thing suspicious thing I saw was an about:blank page so I un-checked it before restoring the session.

Comment 35

[Steve Chessin]

Justin, why did you put "with iPhone connected" back into the Subject? That doesn't seem to be a necessary condition and may not even be a sufficient one.

Comment 36

[Steven Michaud [:smichaud] (Retired)]

Steve, I've taken a look at your samples and am stumped.  I can't find anything in them that explains your problems.

So here's a wild guess:  Do you have any (other) external hardware attached to your MacBook Pro (besides your iPhone)?  If so, do the problems still occur with all of it detached?

Comment 37

[Steven Michaud [:smichaud] (Retired)]

Another thing:  Trigger the bug again and take a look at system console output (using Applications : Utilities : Console).

Comment 38

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #36)
> Steve, I've taken a look at your samples and am stumped.  I can't find
> anything in them that explains your problems.
> 
> So here's a wild guess:  Do you have any (other) external hardware attached
> to your MacBook Pro (besides your iPhone)?  If so, do the problems still
> occur with all of it detached?

I think the iPhone is a red herring. It happens without the phone attached. The only other external device I have attached is the USB receiver for my wireless Targus mouse.

(In reply to Steven Michaud [:smichaud] from comment #37)
> Another thing:  Trigger the bug again and take a look at system console
> output (using Applications : Utilities : Console).

Okay. I will open the Console the next time this happens, before doing a Force Quit.

I did take a look at the Console just now and filtered on "firefox" and this is what it shows:

7/30/15 2:41:07.004 PM com.apple.launchd.peruser.503[196]: (org.mozilla.firefox.242560[474]) Exited with code: 1
7/30/15 2:48:02.029 PM com.apple.launchd.peruser.503[196]: (org.mozilla.firefox.245728[5553]) Exited: Terminated: 15
7/30/15 2:54:00.920 PM com.apple.launchd.peruser.503[196]: (org.mozilla.firefox.242560[5563]) Exited: Terminated: 15
7/31/15 8:50:56.427 AM com.apple.launchd.peruser.503[155]: ([0x0-0x6006].org.mozilla.firefox[172]) Exited: Terminated: 15
8/3/15 5:03:08.855 PM firefox[575]: invalid drawable
8/4/15 8:51:48.086 AM firefox[575]: -deltaZ is deprecated for NSEventTypeMagnify.  Please use -magnification.
8/4/15 9:03:40.945 PM com.apple.launchd.peruser.503[200]: (org.mozilla.firefox.245728[575]) Exited: Terminated: 15
8/4/15 9:14:57.935 PM com.apple.launchd.peruser.503[200]: ([0x0-0x9c09c].org.mozilla.firefox[2580]) Exited: Terminated: 15
8/5/15 7:20:02.034 AM com.apple.launchd.peruser.503[195]: (org.mozilla.firefox.245728[486]) Exited: Terminated: 15

I don't know if those correlate with the problem, however.

Comment 39

[Steven Michaud [:smichaud] (Retired)]

> I did take a look at the Console just now and filtered on "firefox"

Don't just filter on "firefox".  I frankly suspect you have some kind of hardware problem.  Look for signs of that.  Check the time stamps to make sure you only look at messages that cooincide with the problems you see.

Comment 40

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #39)
> > I did take a look at the Console just now and filtered on "firefox"
> 
> Don't just filter on "firefox".  I frankly suspect you have some kind of
> hardware problem.  Look for signs of that.  Check the time stamps to make
> sure you only look at messages that cooincide with the problems you see.

Well, I did run hardware diagnostics a few days ago and it found nothing amiss. And the problem only seems to affect FF 39.0 (FF 38.0.5 did exhibit it once). But I will check the Console the next time I start Firefox.

Comment 41

[Steven Michaud [:smichaud] (Retired)]

Another thing:  Without clear, reliable steps to reproduce this bug, there's nothing we can do here.  As best I can tell, you haven't yet provided that.

Comment 42

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #41)
> Another thing:  Without clear, reliable steps to reproduce this bug, there's
> nothing we can do here.  As best I can tell, you haven't yet provided that.

Yeah, intermittent problems are among the hardest to debug. They're usually due to race conditions. If I had a reliable way of making it happen every time I would have posted it.

I don't know the details of Not Responding; I gather it means that the application isn't responding to keystrokes, mouse clicks, and other external events. (Not being a MacOS application developer I'm not sure how the OS detects that; does it ping every app periodically with a null message?) But that kernel memory consumption keeps increasing indicates to me that Firefox may be in some kind of loop making system calls that require "kernel_task" (process 0) to allocate memory.

Do the samples and/or spindumps I've uploaded indicate if any of Firefox's threads are in a section of code that makes system calls? Should I upload the 5GB core file I captured? Would that help?

Also, are there any debugging flags I can turn on that would help? Any dtrace scripts you could send me that I could run?

Comment 43

[Steven Michaud [:smichaud] (Retired)]

> Should I upload the 5GB core file I captured?

You *can't* upload something that big to bugzilla.mozilla.org -- the size limit is something like a few MBs.  In any case I doubt it would be helpful.

There's nothing in your profiles to indicate a hang of any sort in Firefox.

> Also, are there any debugging flags I can turn on that would help?

I can't think of any.  And the problem is so ill defined that it's very difficult to know where to start.

In short, I think this bug is intractable without good STR.

But I stand by my hunch that this is at bottom a hardware problem.  I have *lots* of experience dealing with incomprehensible bugs reported here, and after a while you develop a kind of sixth sense.

Do look again at your system console output.  And more important still, please test with the wireless receiver for your Targus mouse detached -- try using just the trackpad for a day or so.

Comment 44

[Steven Michaud [:smichaud] (Retired)]

> I don't know the details of Not Responding

You get the beachball cursor in an app when it can no longer process user input (OS-level mouse and keyboard events) in a timely fashion.  You see can the beachball even if you don't move the mouse or press any keys on the keyboard -- so clearly the OS looks for delays in more than just user-input events.  But basically "not responding" means "not able to process user-input events quickly enough".

Comment 45

[Steven Michaud [:smichaud] (Retired)]

By the way, your non-"spindump" samples are useless -- the symbol names are either absent or inaccurate.

Comment 46

[Steven Michaud [:smichaud] (Retired)]

Mozilla-specific symbols are also missing from your spindump samples, but they're marginally more readable.

However, like I said, neither indicates that Firefox is hung.  That doesn't mean that Firefox *isn't* hung -- it pretty clearly is.  Just that your samples are useless for diagnosing the condition.

Comment 47

[Markus Stange [:mstange]]

Yeah, our release Firefox versions don't come with symbols.

If you can reproduce this in Nightly and get an Activity Monitor sample from Nightly, that might get us closer to the problem, since Nightly comes with symbols so the sample will be much more useful.

Comment 48

[Steven Michaud [:smichaud] (Retired)]

By the way, if you're still into taking samples, try doing it with a current trunk (aka mozilla-central) nightly build.  Only those builds don't have their symbols stripped.

http://ftp.mozilla.org/pub/firefox/nightly/

I can't promise your new samples will be any more useful, but at least they won't be crippled by the absence of Mozilla-specific symbols.

Comment 49

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #45)
> By the way, your non-"spindump" samples are useless -- the symbol names are
> either absent or inaccurate.

I apologize for the fact that (as Markus said) your release Firefox versions don't come with symbols. I also apologize for not knowing that fact prior to Markus' posting. I apologize for being an ordinary user that runs your release versions instead of running development versions. (I do have a day job and Firefox is mission-critical for me.) I am trying to be a helpful user. I am not a Firefox developer.

(In reply to Steven Michaud [:smichaud] from comment #48)
> By the way, if you're still into taking samples, try doing it with a current
> trunk (aka mozilla-central) nightly build.  Only those builds don't have
> their symbols stripped.
> 
> http://ftp.mozilla.org/pub/firefox/nightly/
> 
> I can't promise your new samples will be any more useful, but at least they
> won't be crippled by the absence of Mozilla-specific symbols.

When I go to that link I see a lot of directories of the form NN.N[bN]-candidates, each of which contains one or more buildN directories. From a build directory, I see that I can navigate to mac/en-US/ and download the FirefoxNN.N[bN].dmg file, which presumably contains a non-stripped Firefox binary. I assume I want a non-stripped binary that corresponds to the 39.0 release I am using, meaning I want one of the 39.0[bN]-candidates. But I'm not sure how to determine which build of which candidate I should download.

about:buildconfig tells me that 39.0 was "Built from https://hg.mozilla.org/releases/mozilla-release/rev/d3b3e57e8088", and following that link takes me to a page that has this line in it:

Automated checkin: version bump for firefox 39.0 release. DONTBUILD CLOSED TREE a=release GECKO390_2015063018_RELBRANCH FIREFOX_39_0_BUILD6 FIREFOX_39_0_RELEASE 

Does that mean I want 39.0b6-candidates/build1/? Or do I want 39.0-candidates/build6/? Or are they the same? Please advise.

Comment 50

[Steven Michaud [:smichaud] (Retired)]

> http://ftp.mozilla.org/pub/firefox/nightly/

What you want from here is the latest build that has "mozilla-central" in its name.  For example, the following link is to today's mozilla-central (aka trunk) nightly:

http://ftp.mozilla.org/pub/firefox/nightly/2015-08-06-03-02-05-mozilla-central/firefox-42.0a1.en-US.mac.dmg

Comment 51

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #50)
> > http://ftp.mozilla.org/pub/firefox/nightly/
> 
> What you want from here is the latest build that has "mozilla-central" in
> its name.  For example, the following link is to today's mozilla-central
> (aka trunk) nightly:
> 
> http://ftp.mozilla.org/pub/firefox/nightly/2015-08-06-03-02-05-mozilla-
> central/firefox-42.0a1.en-US.mac.dmg

Thank you. I do see later mozilla-central directories (for example,
http://ftp.mozilla.org/pub/firefox/nightly/2015-08-06-10-32-24-mozilla-central/
and
http://ftp.mozilla.org/pub/firefox/nightly/2015-08-06-10-32-22-mozilla-central/)
but they don't contain mac binaries.

I'll download
http://ftp.mozilla.org/pub/firefox/nightly/2015-08-06-03-02-05-mozilla-central/firefox-42.0a1.en-US.mac.dmg

and install and use it and see if I can get the problem to recur with that (and unplug the mouse and start the console before restarting Firefox).

Comment 52

[Steven Michaud [:smichaud] (Retired)]

Please restart your computer after you unplug your mouse's base station, to clear out any drivers that may be associated with it.

Comment 53

[Steve Chessin]

Well, I've got good news and bad news.

The good news (at least for me) is that my Targus mouse is innocent.
The bad news (at least for you) is that Firefox 42.0a1 has lots of problems and is definitely not ready for prime time; it at least doesn't seem useful for root-causing this bug.

This is what I did and what happened:

** Shutdown MBP
** Unplugged Mouse
** Rebooted
** Logged in
** Opened Console
** Cleared messages
** Started Thunderbird
** Started Nightly 42.0a1
** Nightly Web Content Crashed
** All tabs in all windows were New Tab with a red exclamation point (except one that just said New Tab)
(Misfeature: It doesn't tell me what URL the tab that crashed wanted to load)
** Tried Restore All Crashed Tabs
** Nightly Web Content Crashed
** Tried Restore This Tab
** Nightly Web Content Crashed
** Did not want to close tab since I was concerned I'd have to close them all and lose all my browser state, so Quit Nightly
** Started Firefox 39.0, went Not Responding, kernel memory consumption increased (this vindicated my Targus mouse).
** Plugged Mouse back in
** Force Quit Firefox
** Saved Console log
** Started Firefox 39.0 again, went Not Responding, kernel memory consumption increased (to make sure problem would recur, in preparation for the following intervention)
** Force Quit Firefox
** Started Firefox 38.0.5, got Well This is Embarrassing
** Unchecked about:blank, and did Restore (I suspected about:blank was causing the problem)
** All my windows and tabs came up
** Quit Firefox 38.0.5
** Started Firefox 39.0, all my windows and tabs came up (so suspect that whatever about:blank wanted to load was causing the problem)

I'll attach the Console log, but I don't think it will tell you anything useful.

Two comments on Nightly 42.0a1:
1. Nightly Web Content Crashed repeatedly.
2. I gather showing a tab with a red exclamation point and giving me the option of closing the tab, restoring that tab, or restoring all crashed tabs is a replacement for the "Well, this is embarrassing" page? Unfortunately, it doesn't tell me what URL that tab was trying to load. I have a lot of state in my browser and want to be very judicious about which tabs I close. You should include the URL that the tab is crashing on. (It also doesn't make sense that *all* my tabs should be crashing, since when I unchecked one tab, about:blank, in 38.0.5, 39.0 was able to come up. I assume it was that one about:blank tab that was the problem. It would be very nice to know what URL Firefox wanted to load into that tab.)

Anyway, since Steven's original complaint about my samples and spindumps was that they didn't have symbols, it seems the proper debugging step is to use an unstripped Firefox 39.0 so we only change one variable (symbols versus no symbols), instead of trying the latest and greatest and confusing the issue.

So how do I get an unstripped Firefox 39.0? I note that
http://ftp.mozilla.org/pub/firefox/nightly/39.0-candidates/build6/mac/en-US/Firefox%2039.0.dmg
is identical to the Firefox 39.0.dmg I downloaded in June, so presumably is stripped, whereas
http://ftp.mozilla.org/pub/firefox/nightly/39.0b6-candidates/build1/mac/en-US/Firefox%2039.0b6.dmg
is not identical. Does that contain the symbols?

Comment 54

[Steve Chessin]

Attachment: Console log related to Comment 53 https://bugzilla.mozilla.org/show_bug.cgi?id=1180582#c53

Comment 55

[Steve Chessin]

Hmmm. A FileMerge comparison of the Firefox.app in Firefox 39.0.dmg with the Firefox.app in Firefox 39.0b6.dmg leads me to believe that the "b" in "b6" stands for Beta, not Build. The giveaway was the application.ini file. The former contains the line
SourceRepository=https://hg.mozilla.org/releases/mozilla-release
whereas the latter contains the line
SourceRepository=https://hg.mozilla.org/releases/mozilla-beta

If that's the case, I'm going to need someone to build me an unstripped version of Firefox 39.0, if that's at all possible.

Comment 56

[Markus Stange [:mstange]]

Did you submit crash reports for the tab crashes? Can you paste links to them here? They're under about:crashes, as usual.

Comment 57

[Steve Chessin]

(In reply to Markus Stange [:mstange] from comment #56)
> Did you submit crash reports for the tab crashes?

You mean the "Nightly Web Content" crashes? Of course I did! I'm a software engineer with 40+ years of experience. What kind of fool do you take me for? (The proper response is "First class." :-).)

> Can you paste links to
> them here? They're under about:crashes, as usual.

02A6584F-3AFD-452D-B003-4AD78E57C2F3
	8/7/15	6:53 AM
bp-8f3d5afc-d55c-4190-9d65-de4102150807
	8/7/15	6:53 AM
bp-5e0471d5-faae-422b-9e86-b301d2150807
	8/7/15	6:52 AM
bp-c1d31d5a-cf13-4eaf-9878-9eca52150807
	8/7/15	6:50 AM

Or:
https://crash-stats.mozilla.com/about/throttling
https://crash-stats.mozilla.com/report/index/bp-8f3d5afc-d55c-4190-9d65-de4102150807
https://crash-stats.mozilla.com/report/index/bp-5e0471d5-faae-422b-9e86-b301d2150807
https://crash-stats.mozilla.com/report/index/bp-c1d31d5a-cf13-4eaf-9878-9eca52150807

Comment 58

[Steve Chessin]

(I'm impressed. Bugzilla recognized those strings as crash report IDs and made links to them! I didn't have to paste in those extra lines.)

Comment 59

[Steve Chessin]

A non-stripped FF39.0.3 would work, too, as it has the same problem.

I do seem to have a workaround: Start FF39.x. If it goes Not Responding with memory consumption into the red zone, Force Quit it and start FF38.0.5. After it comes up, Quit it, and restart FF39.x.

BTW, when I started FF38.0.5, it went non-responding with kernel memory into the redzone also, but then came out of it. I'll attach the Activity Monitor graph. The same thing happened the first time I launched FF39.0.3, but then it went back into the redzone.

Gijs, Markus, is there any way I can get a non-stripped FF39.0 or FF39.0.3? (I would think you'd want to keep non-stripped versions of released binaries just for this reason.) (I'd ask Steven also but he's on vacation.)

Comment 60

[Steve Chessin]

Attachment: Activity monitor showing memory consumption going briefly into redzone, then recovering (FF38.0.5)

Comment 61

[:Gijs (away/busy until Mar 10)]

(In reply to Steve Chessin from comment #59)
> Gijs, Markus, is there any way I can get a non-stripped FF39.0 or FF39.0.3?

I don't understand our symbol stripping story on OS X, so I don't know. It's possible someone could do a try push off mozilla-release that would do the right thing, but I don't know what config flags you'd need for that.

> (I would think you'd want to keep non-stripped versions of released binaries
> just for this reason.) (I'd ask Steven also but he's on vacation.)

We have symbols online for the stripped binaries, and software that can apply the symbols to the crash stacks when they come in, so we get symbolicated crash stacks. This is all automated. On Windows, debugging tools like MSVC and the "old" debugger tool all take remote symbol server paths (which we also have for release versions). And developers who want this locally don't usually use release versions. All of this ends up meaning that the cases where we need this are few and far between.

Comment 62

[Steve Chessin]

(In reply to :Gijs Kruitbosch from comment #61)
[...]
> We have symbols online for the stripped binaries, and software that can
> apply the symbols to the crash stacks when they come in, so we get
> symbolicated crash stacks. This is all automated.

Could that also be done with the samples and spindumps I sent? I see that the samples have lines such as:
    + 953 start  (in firefox) + 52  [0x100000ba4]
    + ! 953 ???  (in firefox)  load address 0x100000000 + 0x15f8  [0x1000015f8]
    + !   953 XRE_main  (in XUL) + 240  [0x102fe0240]
(so offset in hex)

and the spindumps have lines such as:
  396 ??? (XUL + 986326) [0x1010f0cd6]
(so offset in decimal)

I'm not familiar with your tools that apply symbols to crash stacks, but it (naively?) seems to me that someone who is (especially the people who wrote and maintain them) could create a tool that would do the same for MacOS samples and spindumps.

Comment 63

[Markus Stange [:mstange]]

It wouldn't be hard to write such a script (there's a very similar one here: https://github.com/mstange/analyze-tryserver-profiles/blob/master/resymbolicate_dmd.py ), but somebody would need to do it. I don't have time for it at the moment, sorry.

Comment 64

[Steve Chessin]

I've updated the subject because I just upgraded to 40.0 and it has the same problem. (Should I change the Version to 40 branch or leave it at 39 branch?)

These were the steps I followed:
(Running FF 39.0.3)
Download FF 40.0
Quit FF 39.0.3 (it crashed during the Quit; crash report is at bp-e6ef1af8-cc68-4422-836a-0f86c2150812)
Install FF 40.0
Start FF 40.0 (it goes Not Responding with kernel memory consumption going into red zone)
Force Quit FF 40.0
Start FF 40.0 again (it came up into "Well, this is embarassing ...")
Click Restore (I did NOT delete any tabs)
FF 40.0 comes up without difficulty!

So I seem to have a workaround (Force Quit and launch it again), but I'm saving 38.0.5 just in case.

Comment 65

[Steve Chessin]

(In reply to Markus Stange [:mstange] from comment #63)
> It wouldn't be hard to write such a script (there's a very similar one here:
> https://github.com/mstange/analyze-tryserver-profiles/blob/master/
> resymbolicate_dmd.py ), but somebody would need to do it. I don't have time
> for it at the moment, sorry.

And I am not familiar with Python. Maybe when Steven comes back from vacation he can do it?

Comment 66

[Steve Chessin]

Another data point:

I Quit FF40.0; it crashed during the Quit; see bp-bcfc1202-2d59-45b6-8614-0d4782150813.
I rebooted my MacBookPro.
I started FF40.0; it went red; I Force Quit it.
I started FF40.0 again; it went red again; I Force Quit it.
I started FF40.0 a third time; I got one window with the restore session tab AND the Noscript "Congratulations, you've got the latest version” tab: https://noscript.net/?ver=2.6.9.35&prev=2.6.9.34
I closed that tab; I clicked Restore in the restore session tab; FF40.0 came up.

I'm guessing that that NoScript page might have something to do with it, or else the cookie check NoScript does before deciding to open that page.

Comment 67

[Steven Michaud [:smichaud] (Retired)]

The best/easiest way to get symbols in profiles made using Apple tools is to use a build without symbols stripped.  The *only* such builds are trunk/mozilla-central nightlies.  But you can't use them because they crash on startup.

I'm still stumped, and none of the information above provides any useful clues.  One thing is clear, though -- your problems appear to be unique, so there must be one or more external (non-Mozilla) factors that we haven't yet found.

I still think it's most likely to be some kind of hardware problem.  But a couple more ideas just occurred to me:  1) What kind of account are you using?  Is it an admin account, or one with reduced privileges?  2) Are you running antivirus software, or some other kind(s) of non-Apple "background" application(s)?

Comment 68

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #67)

Here's something to try:

Create a new admin account and log into it.  Before installing anything else there, download and install the current release version of Firefox (which I believe is FF 40).  Run it and see if your problems still happen.

Comment 69

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #67)
> The best/easiest way to get symbols in profiles made using Apple tools is to
> use a build without symbols stripped.  The *only* such builds are
> trunk/mozilla-central nightlies.  But you can't use them because they crash
> on startup.
> 
> I'm still stumped, and none of the information above provides any useful
> clues.  One thing is clear, though -- your problems appear to be unique, so
> there must be one or more external (non-Mozilla) factors that we haven't yet
> found.

It also seems to be related to the order in which FF opens all the windows on startup. I did something to change that order and so far have been unable to recreate the problem.

> I still think it's most likely to be some kind of hardware problem.  But a
> couple more ideas just occurred to me:  1) What kind of account are you
> using?  Is it an admin account, or one with reduced privileges?  2) Are you
> running antivirus software, or some other kind(s) of non-Apple "background"
> application(s)?

I run a standard account. I hardly ever log in with my admin account. Whenever I need to do something that requires admin privilege (such as installing a new version of FF into Applications or moving an older version to Trash) MacOS prompts me for my admin account name and password.

There is a background app that periodically checks that I'm running approved software; I can't turn it off. But it just looks at files in the filesystem; it doesn't try to talk to applications.

(In reply to Steven Michaud [:smichaud] from comment #68)
> (Following up comment #67)
> 
> Here's something to try:
> 
> Create a new admin account and log into it.  Before installing anything else
> there, download and install the current release version of Firefox (which I
> believe is FF 40).  Run it and see if your problems still happen.

1. Why an admin account as opposed to a standard account? (I'll be happy to do the test both ways.)

2. I've already downloaded and installed FF 40.0 into Applications (I'm running it now) so why would I need to download and install it again?

Comment 70

[Steven Michaud [:smichaud] (Retired)]

So ... you no longer see this bug with FF 40?

Is the only difference that you're testing with a newly downloaded copy of it?  If so, then your old copy may have somehow got corrupted (possibly because of hard disk problems).

Do you still have your old copy to test with?

Comment 71

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #70)
> So ... you no longer see this bug with FF 40?

See comment #66. I was able to get FF40 to go red twice in a row. Then during my experiments I did something (click on a window before quitting FF?) that seemed to change the order in which FF opens windows on startup and now I can't recreate the problem. (I have 8 windows. There are over 40K different orders in which those windows can be opened and I don't know how to get FF to use a particular order, even if I knew which one of those 40K orderings was the magic one.)

> Is the only difference that you're testing with a newly downloaded copy of
> it?  If so, then your old copy may have somehow got corrupted (possibly
> because of hard disk problems).

I am not having hard disk problems. I am not having hardware problems (other than a swollen battery; I just took my machine to an Apple store for diagnosis and that was the only problem they found). It is not a hardware problem.

> Do you still have your old copy to test with?

Yes. I can go back to FF39.0 or FF39.0.3 and try them. But I bet the answer is buried in that 5GB core file I took for which you don't have symbols.

Comment 72

[Steven Michaud [:smichaud] (Retired)]

> I run a standard account

How, exactly, did you create this account?

You're very unusual in not using an admin account.  But I know that some people do, and I wasn't aware of any problems with it.

> Yes. I can go back to FF39.0 or FF39.0.3 and try them.

Don't bother.  I was looking for different behavior in two different copies of exactly the same version of Firefox.

> 1. Why an admin account as opposed to a standard account? (I'll be happy to do the test both ways.)

Please do test both ways.  Create a new "standard account" and a new admin account.  In each of them, test with Firefox 40 (maybe the copy that's already in /Applications), before installing any other software.

Comment 73

[Steve Chessin]

(In reply to Steven Michaud [:smichaud] from comment #72)
> > I run a standard account
> 
> How, exactly, did you create this account?

I did this in 2009, and it went something like this:

When you get your very first MacOSX-based system and turn it on for the first time, it prompts you for enough information to create an Admin account for you. (You can get the folks at the Apple store to help you with this if you want.)

So while logged in with Admin privileges, you open System Preferences, select Users & Groups (at least that's what Mavericks calls it; it might have been different under Leopard when I did this), click the lock to unlock it if necessary, then use the plus sign to create the account. Create it as a Standard account.

> You're very unusual in not using an admin account.

I'm very cautious. (I'm a software engineer with 40+ years of experience.) If some malware gets loose on my machine, since it won't have admin privilege it won't be able to do as much damage as it would if it had admin privilege. Folks who routinely use an admin account are (at least IMHO) driving without seat belts.

> But I know that some
> people do, and I wasn't aware of any problems with it.

There shouldn't be. If there is, it's a bug.

> > Yes. I can go back to FF39.0 or FF39.0.3 and try them.
> 
> Don't bother.  I was looking for different behavior in two different copies
> of exactly the same version of Firefox.
> 
> > 1. Why an admin account as opposed to a standard account? (I'll be happy to do the test both ways.)
> 
> Please do test both ways.  Create a new "standard account" and a new admin
> account.  In each of them, test with Firefox 40 (maybe the copy that's
> already in /Applications), before installing any other software.

When I have some down time from my day job I will do that.

Comment 74

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #63)
> It wouldn't be hard to write such a script (there's a very similar one here:
> https://github.com/mstange/analyze-tryserver-profiles/blob/master/
> resymbolicate_dmd.py ), but somebody would need to do it.

I've written the script now, it's at https://github.com/mstange/analyze-tryserver-profiles/blob/master/resymbolicate_activitymonitorsample.py .

Comment 75

[Steve Chessin]

(In reply to Markus Stange [:mstange] from comment #74)
> (In reply to Markus Stange [:mstange] from comment #63)
> > It wouldn't be hard to write such a script (there's a very similar one here:
> > https://github.com/mstange/analyze-tryserver-profiles/blob/master/
> > resymbolicate_dmd.py ), but somebody would need to do it.
> 
> I've written the script now, it's at
> https://github.com/mstange/analyze-tryserver-profiles/blob/master/
> resymbolicate_activitymonitorsample.py .

Does this mean someone is now going to look at the samples and/or spindumps I posted?

BTW, the problem continues with 40.0.3 and 41.0.1. My workaround of Force Quit and restart continues to work as well.

Comment 76

[Markus Stange [:mstange]]

Attachment: First sample of Not Responding Firefox 39.0, symbolicated

Comment 77

[Markus Stange [:mstange]]

Attachment: First spindump of Not Responding Firefox 39.0, symbolicated

Comment 78

[Markus Stange [:mstange]]

Attachment: Second sample of Not Responding Firefox 39.0, symbolicated

Comment 79

[Markus Stange [:mstange]]

Attachment: Second spindump of Not Responding Firefox 39.0, symbolicated

Comment 80

[Steve Chessin]

Updating the Subject. This problem has occurred with every release of Firefox since 39.0. Fortunately, the workaround (Force Quit and restart) also works. I just monitor memory consumption of Firefox after I start it, and if it approaches 2GB without having opened any tabs then I Force Quit it, long before it starts pushing up kernel memory consumption. Then the restart tends to work without bringing up the "Well, this is embarrassing" window.

My reproducible test case is: Quit Firefox. Restart the MacBookPro. Open Firefox.

Comment 81

[Steve Chessin]

I just rebooted my Mac, and launched FF 43.0.3 for the very first time. Whenever I launched FF 39.0 through FF 43.0.2 after rebooting, it would go into the "not responding/memory consumption increasing" state, whereupon I would Force Quit it and relaunch it. On the second (or sometimes third) launch it would come up normally.

But with FF 43.0.3 it did not do that; it came up normally the very first time after the reboot. Now, one event is not proof that the problem has been fixed, and I'll have to see if the good behavior :-) continues on subsequent reboots and FF launches. But I did want to post this information.

Comment 82

[Steve Chessin]

Is there a way to find out what bugs were fixed in 43.0.3 that hadn't been fixed as of 43.0.2? When I click on "Complete list of changes for this release" on the 43.0.3 release notes page
https://www.mozilla.org/en-US/firefox/43.0.3/releasenotes/
it gives me the same exact list of 3079 bugs that I get if I click on that same link on the 43.0.2 release notes page
https://www.mozilla.org/en-US/firefox/43.0.2/releasenotes/

It seems Bugzilla only records the major release number, not the minor or micro number, in which a bug is fixed.

The release notes page says these bugs were fixed:

    On some Windows configurations, improve the decoding of some videos on YouTube (1233970)
    Fix network issue when using Nvidia's Network Access Manager (1233237)

but were those the only two? Often the release notes just say "Various stability and security fixes" with a link to a list of security fixes, but no link to a list of the other fixes (except for the link that gives everything in the major release).

Comment 83

[Ryan VanderMeulen [:RyanVM]]

Yeah, those actually were the only two bugs fixed in 43.0.3 (compared to 43.0.2).
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=FIREFOX_43_0_2_RELEASE&tochange=FIREFOX_43_0_3_RELEASE

Very odd indeed if your problem went away with that build. Thanks for all your patience in trying to diagnose this bug, I'm sure it's been frustrating on your end. It's obviously frustrating for us as well to be unable to reproduce on our end :(

Comment 84

[Justin [:JW_SoftvisionQA]]

I will close this bug per comment 81. If this issue persists, please feel free to reopen.

Comment 85

[Steve Chessin]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #83)
> Yeah, those actually were the only two bugs fixed in 43.0.3 (compared to
> 43.0.2).
> https://hg.mozilla.org/releases/mozilla-release/
> pushloghtml?fromchange=FIREFOX_43_0_2_RELEASE&tochange=FIREFOX_43_0_3_RELEASE
> 
> Very odd indeed if your problem went away with that build. Thanks for all
> your patience in trying to diagnose this bug, I'm sure it's been frustrating
> on your end. It's obviously frustrating for us as well to be unable to
> reproduce on our end :(

I'm wondering if this bug was somehow related to bug 1243098 that was apparently introduced in 43.0.3, that whatever change cured my hangs caused those hangs. Of course, that bug was on Windows whereas mine was on MacOS. But both use Intel processors.