Firefox 38.0a1 Crash Report [@ libpthread-2.18.so@0xbd2f

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: pf, Unassigned)

Tracking

({crash})

37 Branch
x86_64
Linux
crash
Points:
---

Firefox Tracking Flags

(e10s+)

Details

(Whiteboard: [KillHard linux signature], crash signature, URL)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150120030203

Steps to reproduce:

Since 38.0a1


Actual results:

Just more Nightly crashes


Expected results:

no crash...
(Reporter)

Comment 1

4 years ago
Created attachment 8552240 [details]
FF1124064

Seeing several crashes per day.  All tabs have to be reloaded via tab crash Try Again...
(Reporter)

Comment 2

4 years ago
ARGH!!!  When a tab crashes, is it necessary to sympathy-crash every other tab?  
38.0a1 (2015-01-20) is rather painful at the moment.

Comment 3

4 years ago
(In reply to Pierre Fortin from comment #2)
> ARGH!!!  When a tab crashes, is it necessary to sympathy-crash every other
> tab?  

They all share the same process, so it's not like we're doing it on purpose - the process dies, and therefore so do all the tabs.
Severity: normal → critical
tracking-e10s: --- → ?
Keywords: crash
(Reporter)

Comment 4

4 years ago
OK. Thanks.

Question:  upon Restore Session, FF appears to know which tabs to reload v. which to wait on later; based on the many tabs in big spinner mode v. actually reloaded... Any reason why the pain on the user couldn't be alleviated by performing a Restore_Session-like crash recovery? I hope/assume this crash reason can be fixed soon; but while I could do a Quit/restart, this bug happens too often to make full FF restart better than (Try Again * N_tabs) on those I'm actively using between crashes.  I know that sounds a bit redundant; but generally, an auto-reload of affected pages, or return to big spinner, would be more friendly than:
   ("Try Again" + mouse_miles.to_desired_tab + mouse_miles.to_try_again) * tabs

Comment 5

4 years ago
(In reply to Pierre Fortin from comment #4)
> OK. Thanks.
> 
> Question:  upon Restore Session, FF appears to know which tabs to reload v.
> which to wait on later; based on the many tabs in big spinner mode v.
> actually reloaded...

It just loads the selected tab first, and everything else only when you switch to that tab, which is why you might see spinners.

>  Any reason why the pain on the user couldn't be
> alleviated by performing a Restore_Session-like crash recovery?

Not really, because if the tab crashed, we don't want to immediately restore tabs as that might immediately crash again, making it impossible for the user to close the offending tab that keeps crashing their browser. I get that to you, in this case, it's not obvious which tab crashed the browser, but in some cases it will be (open page X --> immediate browser crash). If we keep reopening that page and crashing, that clearly doesn't work.

Unfortunately it's not really possible for Firefox to distinguish between the "this site always crashes Firefox" and "something strange happened and everything went pear-shaped, and we (and the user) don't know which tab crashed us" cases.

Updated

4 years ago
Crash Signature: [@ libpthread-2.18.so@0xbd2f]
(Reporter)

Comment 6

4 years ago
Trying to best help...  but I'm puzzled...  assuming FF is object-oriented, does it not crash "in context"? Even if in a subroutine/function with limited info, it could raise any exception to the upper layers which can provide their own scope info?  A la Python?  The crash reports have lots of info; but it appears to be gathered top-down as opposed to where the crash occurred from -- not bottom-up with the user info (webpage, style, etc)...

When the crash occurs, it places all tabs (except about:* and some big spinner tabs) into:
> Tab crashed
> Well, this is embarrassing. We tried to display this Web page, but it's not responding.

This implies an auto-restore (which you argue against) was attempted...  so at minimum, it's misleading.

Other than with a crashing page, Try Again always works; so I don't believe any attempt was ever made to "display" -- even less "but it's not responding".  If pages are not loaded until accessed post-restore, then there's no way all 500+ tabs I have open, minus above exceptions, should make this tab crashed claim since most should still be in the post-restore state until I "switch to that tab".

When the user switches to other tabs, is there any reason not to restore that tab like would happen post-restore, rather than have to display the current "tab crashed" which adds zero information to the already known fact that there was a recoverable crash whose time has passed?  

I understand your comment about a crash loop; but that shouldn't preclude adding a "Restore Session" button next to the "Try Again" button, or just replace it.  It's the one-at-a-time restoration via "try again" of all pages that is most aggravating.

Comment 7

4 years ago
(In reply to Pierre Fortin from comment #6)
> Trying to best help...  but I'm puzzled...  assuming FF is object-oriented,
> does it not crash "in context"? Even if in a subroutine/function with
> limited info, it could raise any exception to the upper layers which can
> provide their own scope info? A la Python? 

Crashing is not raising an exception. Crashing is crashing; the memory might be unsafe, and we can't safely "raise" anything. We should terminate the process to avoid worse things happening. Python is interpreted and very different, and so the parallel sadly doesn't really work.

>  The crash reports have lots of
> info; but it appears to be gathered top-down as opposed to where the crash
> occurred from -- not bottom-up with the user info (webpage, style, etc)...

At the point where we crash, it's often hard to get information that might be useful, because touching anything else is likely to be unsafe. It's too late to gather more debug information. If you had reliable steps to crashing, you could do something like get a NSPR log that would get us more information, but it sounds like it just happens 'after spending X time browsing', so to speak, without any clear cause / steps, so that's not very feasible (NSPR logs log a lot of things, so that even a few minutes of browsing easily gather several megabytes of logs).


> When the crash occurs, it places all tabs (except about:* and some big
> spinner tabs) into:
> > Tab crashed
> > Well, this is embarrassing. We tried to display this Web page, but it's not responding.
> 
> This implies an auto-restore (which you argue against) was attempted...  so
> at minimum, it's misleading.
> 
> Other than with a crashing page, Try Again always works; so I don't believe
> any attempt was ever made to "display" -- even less "but it's not
> responding".  If pages are not loaded until accessed post-restore, then
> there's no way all 500+ tabs I have open, minus above exceptions, should
> make this tab crashed claim since most should still be in the post-restore
> state until I "switch to that tab".
> 
> When the user switches to other tabs, is there any reason not to restore
> that tab like would happen post-restore, rather than have to display the
> current "tab crashed" which adds zero information to the already known fact
> that there was a recoverable crash whose time has passed?  
> 
> I understand your comment about a crash loop; but that shouldn't preclude
> adding a "Restore Session" button next to the "Try Again" button, or just
> replace it.  It's the one-at-a-time restoration via "try again" of all pages
> that is most aggravating.

This makes sense to me. Mike, can we improve the UX here so users don't have to go restore tabs one at a time?
Flags: needinfo?(mconley)
(In reply to :Gijs Kruitbosch from comment #7)
> This makes sense to me. Mike, can we improve the UX here so users don't have
> to go restore tabs one at a time?

We sure can! The UX design was done in bug 913651 and the work to implement the spec is being done in bug 1110511. It is adding a "Restore all crashed tabs" button to about:tabcrashed.
Flags: needinfo?(mconley)
Pierre, can you link to some of the crash reports in about:crashes?
Flags: needinfo?(pf)

Comment 11

4 years ago
mozilla::net::PCookieServiceChild::SendGetCookieString(mozilla::ipc::URIParams const&, bool const&, bool const&, IPC::SerializedLoadContext const&, nsCString*)

Think this is a dupe, but i can't find it right now.

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

4 years ago
Depends on: 1116884

Updated

4 years ago
tracking-e10s: ? → m5+

Updated

4 years ago
tracking-e10s: m5+ → m6+

Comment 12

4 years ago
This is a meta bug related to KillHard crash signatures in the child process, we're fixing these on an individual basis.
tracking-e10s: m6+ → +
Whiteboard: [KillHard linux signature]
No longer depends on: 1116884
See Also: → bug 1116884
Hi Pierre, 

Please download the Nightly 45.0a1 version from here: https://nightly.mozilla.org/
Please see if you can reproduce the problem with this version.
Flags: needinfo?(pf)
(Reporter)

Comment 15

3 years ago
I auto-download Nightly every morning; but only restart every few days. Haven't seen tab crashing in a while, so this may be corrected. No crashes (best solution :) means no opportunity to test recovery; so I'm OK with closing. Thanks!
Flags: needinfo?(pf)

Updated

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