Closed Bug 1272036 Opened 10 years ago Closed 2 years ago

Crash in libxul.so@0x287ad36 | libxul.so@0x270c062 | libxul.so@0x2a72eaf

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
46 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: makalu, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is report bp-eccb2066-b098-407b-8f14-357542160511. =============================================================
Do you have Gtk3?
Component: General → Untriaged
Flags: needinfo?(chillingham)
Keywords: crash
Version: unspecified → 46 Branch
Yes. 3.10
Chillingham, the error is a bit generic. Could you maybe remember what were you doing at the moment of the crash at that point or/and if you could reproduce the error. I'm afraid that we can't do much just the error report (at least in this case).
Did not do anything. I can just leave the browser and go, but after a while the browser will fall . Or work, the browser will fall. The number of open pages may be different from one or more, but the browser crashes. I have every day from ten to twenty browser crashes.
Could you please try: 1. Run Firefox in safe mode. https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode 2. Run Firefox with a new profile. https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles Could you also tell me the distro you're using? Also it would be important to know if the problems appeared after you updated for example to Release 47 and you didn't experience them on Release 46.
Hardware: Unspecified → x86_64
Distro: Linux Mint 17.3 Rosa Kernel: 4.2.0-34-generic x86_64 (64 bit) Desktop: Cinnamon 2.8.8 From release to release only changed the frequency of falls browser. But the problem for a long time watching.
Could you please try: 1. Run Firefox in safe mode. https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode 2. Run Firefox with a new profile. https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles Did not help.
Chillingham, it would be most helpful to try to catch these crashes on an official build. Could you try it please?
Done.
(In reply to chillingham from comment #9) > Done. Would you please submit the Socorro link in the bug?
Thanks Chillingham, much better now with symbols. Based on crash signature in comment 11, setting Layout/Text component.
Crash Signature: [@ libxul.so@0x287ad36 | libxul.so@0x270c062 | libxul.so@0x2a72eaf] → [@ nsTextFrame::ClearTextRun ]
Component: Untriaged → Layout: Text
Flags: needinfo?(chillingham)
Product: Firefox → Core
Hello, I would like to work on this issue. I have the impression this is linked to Bug 338851 that has introduced RefPtr<gfxTextRun>. However GetTextRun() either return value coming from a RefPtr<gfxTextRun> data member or a raw pointer converted to RefPtr<gfxTextRun> through a call to GetUninflatedTextRun(). Could this mix be the root cause of crash?
Sorry, i wanted to mention Bug 1280887
Flags: needinfo?(jfkthame)
GetTextRun() returns a raw pointer to a gfxTextRun that is owned (i.e. a strong reference is held) by the frame, either in its mTextRun member or in the UninflatedTextRunProperty. (Note that when a textrun is recorded in the UninflatedTextRunProperty by nsTextFrame::SetTextRun, we explicitly call AddRef to hold a reference to the textrun; this is released when the property is cleared, because it was declared with NS_DECLARE_FRAME_PROPERTY_RELEASABLE.) In other words, although the UninflatedTextRunProperty is declared as just holding a raw gfxTextRun pointer, in practice it holds a strong reference to that run; we just add the reference manually instead of automatically using a smart pointer. So I don't think this, in itself, is the problem. For us to encounter a crash here, something about the textframe or its references to text runs must be getting damaged, I guess, but it's not clear to me what might be the root cause. The reporter in comment 2 seemed to be getting crashes like this quite frequently, but I don't believe that has been the case for most users. This leads me to suspect that perhaps something unusual about the user's configuration or environment was leading to corruption in the frame tree, as a result of a bug elsewhere in the layout code (or indeed in an unrelated part of Firefox, or in an extension, etc), which eventually manifests as a crash when we try to use an invalid textrun pointer; but the underlying cause might not be directly in the textrun code at all. Without a reproducible testcase here, I suspect it will be difficult to get to the root of the problem. :(
Flags: needinfo?(jfkthame)
QA Whiteboard: qa-not-actionable

The bug has a crash signature, thus the bug will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: critical → S3

Closing because no crashes reported for 12 weeks.

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