Status

()

Core
General
RESOLVED INCOMPLETE
3 years ago
2 months ago

People

(Reporter: michael, Unassigned)

Tracking

({crash, regression})

35 Branch
x86_64
Linux
crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150113033800

Steps to reproduce:

http://i.imgur.com/91Qq1h9.png <-- link crashes me

xorg-server: 1.16.3-2

chromium didn't crash on that link.


Actual results:

Xorg-server crashed


Expected results:

Not kill Xorg.

Comment 1

3 years ago
Does this happen if you use Firefox nightly: https://nightly.mozilla.org/ ?

Are you able to get some kind of stack / crash dump out of xorg-server?
Flags: needinfo?(tak)
Keywords: crash
(Reporter)

Comment 2

3 years ago
(In reply to :Gijs Kruitbosch from comment #1)
> Does this happen if you use Firefox nightly: https://nightly.mozilla.org/ ?
> 
> Are you able to get some kind of stack / crash dump out of xorg-server?

Nightly also crashes. My friend using the 34 branch on the same distro doesn't have the problem if that helps.
Flags: needinfo?(tak)

Comment 3

3 years ago
(In reply to tak from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > Does this happen if you use Firefox nightly: https://nightly.mozilla.org/ ?
> > 
> > Are you able to get some kind of stack / crash dump out of xorg-server?
> 
> Nightly also crashes. My friend using the 34 branch on the same distro
> doesn't have the problem if that helps.

There are a lot of changes that happen between 2 Firefox releases, so while it's useful to know that it worked on 34, sadly that by itself doesn't immediately pinpoint what's going on here.

I'm very much not an expert on Linux system component crashes. I expect that really, the two things that would most help figure out what's going on here is:

a) crash dump info from the xorg crash
b) a narrowed down regression range. In theory, mozregression ( http://mozilla.github.io/mozregression/ ) can help you find this, but I don't know how easy it will be to make that work when your X server is going down all the time. YMMV. :-\

Maybe Karl has better ideas when he gets back...
Component: Untriaged → Untriaged
Flags: needinfo?(karlt)
Keywords: regression, regressionwindow-wanted
Product: Firefox → Core
(Reporter)

Comment 4

3 years ago
(In reply to :Gijs Kruitbosch from comment #3)
> (In reply to tak from comment #2)
> > (In reply to :Gijs Kruitbosch from comment #1)
> > > Does this happen if you use Firefox nightly: https://nightly.mozilla.org/ ?
> > > 
> > > Are you able to get some kind of stack / crash dump out of xorg-server?
> > 
> > Nightly also crashes. My friend using the 34 branch on the same distro
> > doesn't have the problem if that helps.
> 
> There are a lot of changes that happen between 2 Firefox releases, so while
> it's useful to know that it worked on 34, sadly that by itself doesn't
> immediately pinpoint what's going on here.
> 
> I'm very much not an expert on Linux system component crashes. I expect that
> really, the two things that would most help figure out what's going on here
> is:
> 
> a) crash dump info from the xorg crash
> b) a narrowed down regression range. In theory, mozregression (
> http://mozilla.github.io/mozregression/ ) can help you find this, but I
> don't know how easy it will be to make that work when your X server is going
> down all the time. YMMV. :-\
> 
> Maybe Karl has better ideas when he gets back...

Sadly none of my xorg logs contain any sort of error, but It does crash me out to login.
Tried again with disabled addons and still happened.
I would usually expect to find X server crash stacks in /var/log/Xorg.0.log.old and /var/log/kdm.log, but a different display manager may have the logs in a different place.

There wouldn't be much trace there if the kernel killed the X server due to out of memory, but there might be a record that SIGKILL was used, or something in dmesg.

The image doesn't crash my X servers 1.12.4 and 1.15.2, and I don't see much change in server memory usage.

A crash in the X server is a bug in the X server or one of its modules (e.g. drivers), unless Firefox is DoSing it by demanding too many resources.  Has it been confirmed that a change in behavior in Firefox triggers this?  i.e. do some versions of Firefox not crash the server on this system?
Flags: needinfo?(karlt)
(Reporter)

Comment 6

3 years ago
(In reply to Karl Tomlinson (back 2 Feb:karlt) from comment #5)
> I would usually expect to find X server crash stacks in
> /var/log/Xorg.0.log.old and /var/log/kdm.log, but a different display
> manager may have the logs in a different place.
> 
> There wouldn't be much trace there if the kernel killed the X server due to
> out of memory, but there might be a record that SIGKILL was used, or
> something in dmesg.
> 
> The image doesn't crash my X servers 1.12.4 and 1.15.2, and I don't see much
> change in server memory usage.
> 
> A crash in the X server is a bug in the X server or one of its modules (e.g.
> drivers), unless Firefox is DoSing it by demanding too many resources.  Has
> it been confirmed that a change in behavior in Firefox triggers this?  i.e.
> do some versions of Firefox not crash the server on this system?

The 34 branch has no problem.
I think what Karl asked was if you could find any relevant information in the log
files he named, or any file under /var/log/ ?

Also, there might be a better error message if you start Firefox with the --sync
flag on the command line (it makes X calls synchronous).
Flags: needinfo?(tak)
(Reporter)

Comment 8

3 years ago
Well what I can say is that this bug no longer exists in the 26 branch for me.
OK, good.  Feel free to file a new bug if it occurs again.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(tak)
Resolution: --- → INCOMPLETE
Keywords: regressionwindow-wanted
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.