If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Status

()

Firefox
Untriaged
RESOLVED INVALID
4 months ago
4 months ago

People

(Reporter: merike, Unassigned)

Tracking

54 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

4 months ago
Is there anything useful in https://crash-stats.mozilla.com/report/index/087ed3b1-5da0-40b2-b776-9cfaf0170509 ?

It's a second hang this week (and it's only Tuesday..) and I'd like to know what's causing it. (first one I didn't report) I cannot remember any hangs like that in recent history on the same machine, so it's not typical here.

At the time of crash CPU was at 25% by Firefox, although there were other moderately CPU-heavy programs running too. I assume the hanging thread was UI-related as it was completely unusable at the time. I cannot correlate it to any specific conditions or activity of mine so far.
Are you using Bitdefender Antivirus by any chance? It has a problem this week interfering Firefox.
Flags: needinfo?(merikes.lists)
(Reporter)

Comment 2

4 months ago
No, Symantec product is installed though.
Flags: needinfo?(merikes.lists)
Hi Merike,

I've seen that you mentioned that you haven't managed to correlate this issue to any specific conditions or activity so far, so it's quite difficult to reproduce this without any STR.
However can you please re-test this with a clean Firefox profile on the latest Firefox release and the latest Nightly build to see if the issue is reproducible there?
Also do you think you can remember on which webpages you had observed the hang?

Thank you!
Flags: needinfo?(merikes.lists)
(Reporter)

Comment 4

4 months ago
My hopes were not necessarily on reproducibility but rather that for a developer with experience the stacks of various threads in the report might hint something to go from. Although I'm unsure if it's possible to tell from the report which thread was causing CPU loop at the time... Also, since it does not trigger a crash automatically if this was occurring for other users no bug or crash reports at all might come in. If the stacks are deemed useless then so is this bug. I don't take offence if this is closed for lack of developer time to look into :)

As long as it does not keep reproducing on my main profile (and it has not for the rest of this week) there's not much point of trying with a new one. I think one of the times the last responding page was VisualSVN page, but this does not mean much as I use it often. The other time I don't remember sadly as I was coming back from another application.
Flags: needinfo?(merikes.lists)
We can ignore the crashing thread (70), since that's the one merike injected. Thread 0 is the interesting one, I believe.

It appears to be stuck inside nsFrameIterator::Next(). Unless there's just a humongous number of frames in the iterator, I wonder if we're somehow caught in an infinite loop in here?

Hey TYLin, ni?ing you arbitrarily because I notice you've touched nsFrameTraversal.cpp... any edge cases in nsFrameIterator::Next that merike might be falling into resulting in an infinite loop?
Flags: needinfo?(tlin)
It's not obvious to me how nsFrameIterator::Next() ended up in infinite loop in this case. Perhaps thread (0) just happens to be caught in this state when thread (70) crashed.
Flags: needinfo?(tlin)
(Reporter)

Comment 7

4 months ago
Sorry, forgot to include there was another crash after reporting this bug: https://crash-stats.mozilla.com/report/index/8b36d3f8-09b2-4dad-9dc5-d9a2b0170509 but none since that. Feel free to close as incomplete.
This one also has nsFrameIterator::Next() on the stack.

I unfortunately don't have access to the URI of the page that was being loaded at the time of the crash, if one was recorded. Do you happen to remember the page you were loading at the time of the hang?
Flags: needinfo?(merikes.lists)
(Reporter)

Comment 9

4 months ago
Sorry, no. Last site logged in history that I haven't revisited meanwhile is a VisualSVN page though.

I did have four more hangs in close succession yesterday (should have same email in crash reports) In one case I specifically restored only two tabs from a site I wasn't using last week and still it hung shortly after. So while there may be unknown similarities between trouble causing sites there isn't one specific site or domain at fault. Although it may be be that it usually hangs on one of the internal sites that would make diagnosing this even harder if true.. This hang sure likes to cluster, multiple repeats per day and then days in hiding :)
Flags: needinfo?(merikes.lists)
Hey Merike, is the issue still reproducible for you?
Did you managed to figure out certain steps, or actions needed to be taken in order to reproduce this?
It will be really helpful if you could provide us with the loaded URLs or any other information or activity that you were doing while encountering this, so that we can try to debug this further.
Thank you.
Flags: needinfo?(merikes.lists)
(Reporter)

Comment 11

4 months ago
The issue disappeared as mysteriously as it started. Haven't seen it once meanwhile. Maybe it got embarrassed :)
So, perhaps resolve invalid if nobody else is complaining?
Flags: needinfo?(merikes.lists)
Based on comment 11 and the fact that I cannot reproduce this, I will mark this as Resolved-Invalid.

If anyone can still reproduce it, feel free to reopen the issue and provide more information.
Status: NEW → RESOLVED
Last Resolved: 4 months ago
Resolution: --- → INVALID
(Reporter)

Updated

4 months ago
Crash Signature: [@ @0x0 | __RtlUserThreadStart | _RtlUserThreadStart]
You need to log in before you can comment on or make changes to this bug.