<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Comment 3

•

2 years ago

Confirmed: had the same issue.
Starting in troubleshooting mode and disable hardware acceleration, then restarted Firefox in normal mode without any further problems.
Graphics driver is Intel Iris Xe 31.0.101.3889.

Comment 4

•

2 years ago

(In reply to tomasch from comment #3)

Confirmed: had the same issue.
Starting in troubleshooting mode and disable hardware acceleration, then restarted Firefox in normal mode without any further problems.
Graphics driver is Intel Iris Xe 31.0.101.3889.

This was too hasty. Disabeling hardware acceleration does not solve the problem of freezing at startup.

Comment 5

•

2 years ago

Just found that disabling the Ublock origin add-on (version 1.47.4) solves the problem.

Comment 6

•

2 years ago

Just found that disabling the Ublock origin add-on (version 1.47.4) solves the problem.
(In reply to tomasch from comment #5)
Sorry, again not true!
The effect that got me confused is the following:
Once started in troubleshoot mode Firefox is running flawlessly.
Close Firefox.
After this, another start of Firefox will not run into freeze but normally start-up.
Close again.
After this second closing a new attempt to startup Firefox will end in freezing again.

Ray Kraesig [:rkraesig]

Comment 7

•

2 years ago

I would have been very surprised indeed if there had been any correlation with uBlock Origin!

@tomasch: can you use mozregression to narrow down when this started? If it only happens on the second startup, instead of selecting "good" or "bad" after each run, you may need to use the "other..." dropdown and select "retry".

Flags: needinfo?(tomasch)

Reporter

Comment 8

•

2 years ago

FF in troubleshoot mode works.
Same effect as tomasch reported. After starting in troubleshoot it runs ok once in normal mode.
Second startup hangs again, until I start and close troubleshoot mode
Nighty build 113.0a1 has same problem
Running with a new empty profile works

Not sure if I use mozregression right, it loaded a lot of build, everyone worked. But apparently it was using not my usual profile

Flags: needinfo?(ulli.conrad)

jscher2000

Comment 9

•

2 years ago

Can you run a text compare of the prefs.js file in the profile folders for the working (new) and non-working (regular) profiles? On the about:profiles page, you can use the button next to Root Directory to access the respective folders.

A lot of irrelevant data accumulates in the file over time, but you might be able to spot some startup-related or security-related differences.

Comment 10

•

2 years ago

The mail PID is (per ProcessExplorer) at xll.dll!XRE_GetBootstrap+0x9edde0 .
The two subsidiary PIDs are waiting at firefox.exe!s.SandboxedProcess+0x1c30.
Does anyone know what is occurring at these two points in the source code?

jj-amq

Comment 11

•

2 years ago

This is also affecting the x64 version of the windows build. I have had to roll back the update to 110.0.1 and the profile to keep things working.
There is little point to diff the pref.js files as one is full (from the old existing profile) and the other is fresh and empty from the new profile.

I will have other machines to test on when I'm back in the office next week so will see what I can find out.

Gian-Carlo Pascutto [:gcp]

Reporter

Comment 12

•

2 years ago

Did a compare, as jj-amq said, the new working is pretty empty, but didn't found any apperently startup settings.
Additional info on both profiles:
I took the not working one, copied it to another computer (running Win10, reported bug appearead on a W11 machine), and started with FF 110.0.1 everything worked as expected. Update that to FF 111.0 and - big suprise - also worked on that machine.

Updated

•

2 years ago

Comment 13

•

2 years ago

(In reply to Barry S. Finkel from comment #10)

The mail PID is (per ProcessExplorer) at xll.dll!XRE_GetBootstrap+0x9edde0 .
The two subsidiary PIDs are waiting at firefox.exe!s.SandboxedProcess+0x1c30.
Does anyone know what is occurring at these two points in the source code?

These are the Start Address of the threads.
If you double click each thread line to get the stacks, would you Copy All and paste the stacks into a comment, please.

Flags: needinfo?(bsfinkel)

Ray Kraesig [:rkraesig]

Comment 14

•

2 years ago

(In reply to Ulli Conrad from comment #8)

Not sure if I use mozregression right, it loaded a lot of build, everyone worked. But apparently it was using not my usual profile

You can get mozregression to use your usual profile. Follow the directions in comment 9 to find your profile root directory. (If you have more than one profile, it'll be the one where Default Profile is "yes".) Paste that into the Profile field on the second page of the mozregression wizard, and make sure Profile Persistence is set to "clone" (the default). You'll need to close your primary Firefox instance while you're doing this, though, or else mozregression won't be able to make a copy of your profile.

Before running through a full bisection, you may want to try just doing a single build (the [S] button) of a recent Nightly to make sure the bug does show up in mozregression while using your profile. (Don't forget to retry once! See comment 7.)

Note that, for the full bisection, you'll also need to use a known-good date of 2022-11-24 or later (or at least I needed to); there were some non-backwards-compatible changes made to Firefox profiles around then, and recently-created Firefox profiles won't load.

Flags: needinfo?(ulli.conrad)

Donal Meehan [:dmeehan]

Comment 15

•

2 years ago

Hello bug reporter,

Thanks again for your report. We are tracking a similar issue under Bug 1823159.
If you had the opportunity, could you take a look at a test build with a potential fix. Would you be able to test it out and let us know?
Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1823159#c11 for instructions

Comment 16

•

2 years ago

(In reply to Bob Owen from comment #13)
I have screenshots of the Process Explorer windows. I took the jpeg images and fed them through newocr.com. I have not verified the OCR. Here are the results:

@ firefox.exe:35672 Properties - Oo x
Image Performance Performance Graph GPUGraph Threads TCP/IP Security Environment Strings
Count: 36
TID CPU Cycles Delta Suspend Count Start Address a
20144 0.01 2,391,192 xul.dil!XRE_GetBootstrap+Ox9edde0
23476 ucrtbase dil!configthreadlocale+0k50
23300 ucrtbase dil!configthreadlocale+0x50
15576 ucrtbase.dil!configthreadlocale+0x50
11320 ucrtbase dil!configthreadlocale+0x50
3612 ucrtbase dil!configthreadlocale+0x50
13448 ucrtbase dil!configthreadlocale+0x50
24984 firefox.exe!OrdinalO+-0x 1770
18756 ucrtbase dil!configthreadlocale+150
24396 xul.dilJOG_RegisterPing+kd8ae0
11596 xul.dil!XRE_Get Bootstrap +0x540F60
24284 xul.dil!XRE_GetBootstrap+OxSedde0
24952 ucrtbase.dil!configthreadlocale+0x50
42752 ucrtbase.dillconfigthreadlocale+0x50
27912 ucrtbase dil!configthreadlocale+0x50
17088 ucrtbase dil!configthreadlocale+0x50
202% ucrtbase dil!configthreadlocale+0k50
11392 ucrtbase dil!configthreadlocale+0x50
<<more that I did not scroll to capture>>

Thread ID: 28476 Stack || Module |
Start Time: 9:21:18 PM 3/16/2023
State: Wait:WrAlertByThreac Base Priority: 8
-----@r firefox.exe:19724 Properties - Oo
Image Performance Performance Graph GPUGraph Threads TcP/IP Security Environment Strings
Count: 21
TID CPU Cycles Delta Suspend Count Start Address `
28084 firefox.exe!ls SandboxedProcess+k 1¢30
40308 xul.dil!XRE_Get Bootstrap+IkSedde0
15820 ucrtbase dil!configthreadlocale+0x50
11600 ucrtbase dil!configthreadlocale+0x50
42580 ucrtbase dil!configthreadlocale+0x50
37864 ucrtbase.dil!configthreadlocale+0x50
29240 xul.dil!XRE_Get Bootstrap-+x540F60
25964 xul.dil!XRE_Get Bootstrap+Ox540F60
20572 xul.dil!XRE_Get Bootstrap+0x540F60
24032 xul.dll!XRE_Get Bootstrap+0x540F60
27620 xul.dil!XRE_Get Bootstrap +0x540F60
36316 xul.dil!XRE_Get Bootstrap +0x540F60
32836 xul.dil!XRE_Get Bootstrap-+k540F60
38412 xul.dll!XRE_Get Bootstrap +0x540f60
17564 xul.dil!XRE_Get Bootstrap-+x540F60
31812 xul.dil!XRE_Get Bootstrap+Ox540F60
4564 xul.dil!XRE_Get Bootstrap+0x540F60
8156 xul.dil!XRE_Get Bootstrap +k540f60
|
Thread ID: 19104 [stack | [Module
Start Time: 9:21:18 PM 3/16/2023
State: Wait:UserRequest Base Priority: 8
Kernel Time: 0:00:00.000 Dynamic Priority: = 11
User Time: 0:00:00.000 T/O Priority: Normal
Context Switches: 2 Memory Priority: 5
Cydes: 1,475,969 Ideal Processor: 5
| Permissions | | Kil | Suspend

@ firefox.exe:37084 Properties - Oo x
Image Performance Performance Graph GPUGraph Threads TcP/IP Security Environment Job Strings
Count: §
TID CPU Cycles Delta Suspend Count Start Address
22228 firefox.exe!ls SandboxedProcess+{k 1c}
29168 xul.dil!XRE_GetBootstrap+xSedde0
8964 ucrtbase dil!configthreadlocale+0x50
33968 ucrtbase dil!configthreadlocale+0x50
32252 ucrtbase dillconfigthreadlocale+0x50

Thread ID: _ Stack Module
Start Time:
State: Base Priority:
Kernel Time: Dynamic Priority:
User Time: (0 Priority:
Context Switches: Memory Priority:
Cydes: Ideal Processor:
Permissions Kil Suspend
Lo} [cance |

Is this what you wanted?

Flags: needinfo?(bsfinkel)

Reporter

Comment 17

•

2 years ago

(In reply to Donal Meehan [:dmeehan] from comment #15)

If you had the opportunity, could you take a look at a test build with a potential fix. Would you be able to test it out and let us know?
Please see https://bugzilla.mozilla.org/show_bug.cgi?id=1823159#c11 for instructions

Hi Donal,
everything works fine with that fix :-) Thank you very much indeed so far!

Flags: needinfo?(ulli.conrad)

Bob Owen (:bobowen) (PTO until 5th Jan)

Reporter

Comment 18

•

2 years ago

(In reply to Ray Kraesig [:rkraesig] from comment #14)

Note that, for the full bisection, you'll also need to use a known-good date of 2022-11-24 or later (or at least I needed to); there were some non-backwards-compatible changes made to Firefox profiles around then, and recently-created Firefox profiles won't load.

Tried a couple builds, this are the results:

build_date: 2023-02-18
build_url: https://archive.mozilla.org/pub/firefox/nightly/2023/02/2023-02-18-09-09-55-mozilla-central/firefox-112.0a1.en-US.win64.zip
changeset: 54f1bd9fa6d68b7697e353c0b1a19c48be54bc83
= BAD

build_date: 2023-02-04
build_url: https://archive.mozilla.org/pub/firefox/nightly/2023/02/2023-02-04-21-26-31-mozilla-central/firefox-111.0a1.en-US.win64.zip
changeset: 40237e7707f1928c84d09cdd2f1fd018a74ea784
= BAD

build_date: 2023-01-28
build_url: https://archive.mozilla.org/pub/firefox/nightly/2023/01/2023-01-28-21-11-06-mozilla-central/firefox-111.0a1.en-US.win64.zip
changeset: f4f63f0138feb7535fa58c3f77fd8a51361371d8
= GOOD

build_date: 2023-02-01
build_url: https://archive.mozilla.org/pub/firefox/nightly/2023/02/2023-02-01-21-51-12-mozilla-central/firefox-111.0a1.en-US.win64.zip
changeset: b7f07512450399f35fc38a7e94241b19a4c2693c
= BAD

build_date: 2023-01-30
build_url: https://archive.mozilla.org/pub/firefox/nightly/2023/01/2023-01-30-21-44-13-mozilla-central/firefox-111.0a1.en-US.win64.zip
changeset: 8eb2c58dc4154d83f57adcfa1f83d7003ac13800
= BAD

build_date: 2023-01-29
build_url: https://archive.mozilla.org/pub/firefox/nightly/2023/01/2023-01-29-21-35-53-mozilla-central/firefox-111.0a1.en-US.win64.zip
changeset: e6e21353ce699b8f8e0f2d05e6b06dfd81d28cb8
= BAD

Hope this helps

Comment 19

•

2 years ago

(In reply to Barry S. Finkel from comment #16)

(In reply to Bob Owen from comment #13)
...

Is this what you wanted?

Thanks, but that still looks like a list of the threads.
When you have the hang you would need to double click on the thread to get the stack and there is a Copy All button.

The bugs that we think are related have a fix, but it would be good to confirm this is the same.
Alternatively, if you are prepared to share a memory dump with us there are instruction in bug 1823159 comment 6.
As they say don't share a memory dump publicly, because it may contain private information.

Bob Owen (:bobowen) (PTO until 5th Jan)

Comment 20

•

2 years ago

I now see how to get the stack. But there is one problem - after I experienced this problem, I cancelled FF twice and restarted. On the second restart FF started OK. So, I am not sure I can reproduce this. Do I need to Exit and then restart FF?

Comment 21

•

2 years ago

(In reply to Barry S. Finkel from comment #20)

I now see how to get the stack. But there is one problem - after I experienced this problem, I cancelled FF twice and restarted. On the second restart FF started OK. So, I am not sure I can reproduce this. Do I need to Exit and then restart FF?

I don't think we have exact steps to reproduce unfortunately.
I believe that the issue that has already been fixed required an update to have just occurred.

Andrew McCreight [:mccr8]

Comment 22

•

2 years ago

The problem arose for me after I had upgraded from 102.8.0 to 102.9.0; FF hung on the restart.

Comment 23

•

2 years ago

(In reply to Barry S. Finkel from comment #22)

The problem arose for me after I had upgraded from 102.8.0 to 102.9.0; FF hung on the restart.

Are you seeing the hang every other browser restart? That is what other people were seeing. Your case is also interesting because all of the other reports have been on release, not ESR. We have a potential fix, but we aren't backporting it to ESR 102 because it doesn't seem like it exactly applies. So it would be good to understand what might be going wrong for you.

Andrew McCreight [:mccr8]

Updated

•

2 years ago

Status: UNCONFIRMED → NEW

Ever confirmed: true

Comment 24

•

2 years ago

To Andrew: I do not have a regular schedule for restarting FF. I restart after FF crashes, obviously after an infrequent reboot, and when FF tells me that there is a newer version to install. I have not had a need to restart FF since this past weekend., and I would try a restart if you think that it would create a hang situation that would allow me to get diagnostic information.