1789609 - Crash in [@ mozilla::EditorBase::InitInternal]

Status: RESOLVED INVALID

(Core :: DOM: Editor, defect)

Description

[Pascal Chevrel:pascalc]

Crash report: https://crash-stats.mozilla.org/report/index/25f92a09-5c4d-4dff-b6a0-935590220907

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0 libxul.so mozilla::EditorBase::InitInternal editor/libeditor/EditorBase.cpp:357
1 libxul.so mozilla::HTMLEditor::Init editor/libeditor/HTMLEditor.cpp:313
2 libxul.so nsEditingSession::SetupEditorOnWindow editor/composer/nsEditingSession.cpp:411
3 libxul.so nsEditingSession::MakeWindowEditable editor/composer/nsEditingSession.cpp:164
4 libxul.so mozilla::dom::Document::EditingStateChanged dom/base/Document.cpp:6054
5 libxul.so mozilla::dom::Document::DeferredContentEditableCountChange dom/base/Document.cpp:6167
6 libxul.so mozilla::dom::DeferredContentEditableCountChangeEvent::Run dom/base/Document.cpp:6139
7 libxul.so mozilla::dom::Element::SetAttr dom/base/Element.cpp:2506
8 libxul.so nsGenericHTMLElement::SetContentEditable dom/html/nsGenericHTMLElement.h:121
9 libxul.so mozilla::dom::HTMLElement_Binding::set_contentEditable dom/bindings/HTMLElementBinding.cpp:910

16 crashes in BuildID 20220906213903

Changelog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f8e8c96064386b2f3405adefc512f7fbc2808ff8&tochange=b7f6557aaf06a26f589489fc439e74fd6e75a022

Comment 1

[Andrew McCreight [:mccr8]]

It looks like the crashes are all from a single installation, FWIW.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox106 (nightly). We have limited time to fix this, the soft freeze is in 8 days. However, the bug still isn't assigned.

:hsinyi, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The crash line is recorded as the last line of the method. This typically occurs on Windows, but on Debian, so we need to investigate that the user actually meets the crash in which line first.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #3)

The crash line is recorded as the last line of the method. This typically occurs on Windows, but on Debian, so we need to investigate that the user actually meets the crash in which line first.

Hi Gabriele,
As comment 3 mentioned, this isn't a typical pattern that Masayuki sees on Linux, we're stuck with proceeding with this stack. Can you help us take a look at, if this crash stack is valid or give some hints which line the crash happens? Thank you.

Comment 5

[Gabriele Svelto [:gsvelto]]

The bad crash line is an artifact on how we used to deal with inlined functions, it will be solved once bug 1398533 goes into production which should be real soon now. That being said this is a crash happening from a single installation, it has several extensions installed and it's happening deep into code called via JavaScript which means it's likely not actionable and not very common either. If we get more crashes under this signature we might investigate further, but without having reports from at least another user I'd tend to let it go unless we get new reports.

Comment 6

[Andrew McCreight [:mccr8]]

This crash is very rare, despite the weird one day one installation spike so it doesn't need to be S2.

Comment 7

[Bogdan Maris, Desktop Test Engineering]

Removing regressionwindow-wanted since there are no information on how could this crash be reproducible and crashstats has no comments.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that after fixing bug 1398533, we don't get received same stack crash reports.