Closed Bug 1624099 Opened 5 years ago Closed 3 years ago

Crash Reason SIGSEGV /SEGV_MAPERR

Categories

(Core :: Widget: Gtk, defect, P5)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 90
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- affected
firefox84 --- wontfix
firefox85 --- wontfix
firefox88 --- wontfix
firefox90 --- wontfix
firefox91 --- affected

People

(Reporter: Crashdows, Unassigned)

References

Details

(Keywords: crash, steps-wanted)

Crash Data

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

first sure you are using linux ubuntu base, and try to work with firefox like saving files and open pages.

Actual results:

crash happens with SIGSEGV /SEGV_MAPERR reason idk why but in every release of firefox in linux this happens

Expected results:

just not crash more details here so you can see all of these crash for SIGSEGV /SEGV_MAPERR reason:

firefox 74: https://crash-stats.mozilla.org/report/index/79316e9a-7136-4f3c-977d-d46390200321

firefox 73: https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307

firefox 73 same as 74 crash : https://crash-stats.mozilla.org/report/index/050e7dd3-0b50-467c-83a5-7ee120200221

firefox 72 same as 74 crash: https://crash-stats.mozilla.org/report/index/42d9e981-e5f3-4fe2-8585-0ad1f0200116

also you can see deatils in More Report Part and Reports

its a invalid memory access and cause crash please fix immediately, this cause attacker can use this for crash firefox here is details for it also please check all crashs , Regard.

http://stackoverflow.com/questions/1000002/ddg#28116503

Severity: normal → critical
OS: Unspecified → Linux

another user have my problem see https://bugzilla.mozilla.org/show_bug.cgi?id=1570117 in elementary os

is there any one answer this please this is a critical problem i saw even on report users have same problem

I've added the crash signature to the bug and set another component. If the component is not correct, please feel free to change it to a different one.

Crash Signature: [@ mozalloc_abort | abort | g_assertion_message ]
Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

(In reply to Javad ahmadi from comment #0)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

first sure you are using linux ubuntu base, and try to work with firefox like saving files and open pages.

Actual results:

crash happens with SIGSEGV /SEGV_MAPERR reason idk why but in every release of firefox in linux this happens

Expected results:

just not crash more details here so you can see all of these crash for SIGSEGV /SEGV_MAPERR reason:

firefox 74: https://crash-stats.mozilla.org/report/index/79316e9a-7136-4f3c-977d-d46390200321

firefox 73: https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307

Seems that not all the crash reports share the same cause. But this one did point out that IDB may be suspicious. Let's try to start from there ...

firefox 73 same as 74 crash : https://crash-stats.mozilla.org/report/index/050e7dd3-0b50-467c-83a5-7ee120200221

firefox 72 same as 74 crash: https://crash-stats.mozilla.org/report/index/42d9e981-e5f3-4fe2-8585-0ad1f0200116

also you can see deatils in More Report Part and Reports

Component: DOM: Core & HTML → Storage: IndexedDB

The crash reason of https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307 is MOZ_CRASH(IndexedDB shutdown timed out), this is a duplicate of Bug 1593863

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #5)

(In reply to Javad ahmadi from comment #0)

firefox 73: https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307

Seems that not all the crash reports share the same cause. But this one did point out that IDB may be suspicious. Let's try to start from there ...

This one has a totally different signature and is not part of this pile of crashes, it seems (not sure why the reporter included this in his first description).

On the other crashes I see strange source directories, as if these were home-made builds. And we crash always within nsAppShell::ProcessNextNativeEvent(bool) on some GTK event it seems. I cannot see any relation with IndexedDB here.

Status: RESOLVED → REOPENED
Component: Storage: IndexedDB → General
Ever confirmed: true
Resolution: DUPLICATE → ---

(In reply to Simon Giesecke [:sg] [he/him] from comment #6)

The crash reason of https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307 is MOZ_CRASH(IndexedDB shutdown timed out), this is a duplicate of Bug 1593863

*** This bug has been marked as a duplicate of bug 1593863 ***
this not MOZ_CRASH(IndexedDB shutdown timed out) and please don't waste my time, my browser in linux crash so better fix that nor treat as duplicate

(In reply to Jens Stutte [:jstutte] from comment #7)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #5)

(In reply to Javad ahmadi from comment #0)

firefox 73: https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307

Seems that not all the crash reports share the same cause. But this one did point out that IDB may be suspicious. Let's try to start from there ...

This one has a totally different signature and is not part of this pile of crashes, it seems (not sure why the reporter included this in his first description).

On the other crashes I see strange source directories, as if these were home-made builds. And we crash always within nsAppShell::ProcessNextNativeEvent(bool) on some GTK event it seems. I cannot see any relation with IndexedDB here.

thank you bro, you save my time

Looks like it might have something to do with the Gtk file picker? Maybe Martin can take a look.

Component: General → Widget: Gtk
Flags: needinfo?(stransky)

The crashes referenced here (except https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307) are some gtk assertions. It's impossible to say what's going on without reproducer or terminal output where the assertion / gtk error message is printed. Those aren't security risks.

https://crash-stats.mozilla.org/report/index/2a59854f-c91d-4fd5-8b0f-da7a80200307 is an assertion/null pointer crash at
https://hg.mozilla.org/releases/mozilla-release/annotate/5b0905233e5d29d9fbad98c1380030387cda5dd9/dom/indexedDB/ActorsParent.cpp#l16704
not exploitable, maybe out or memory or so.

Anyway, there's no way how to fix those without further info/reproducers.

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(stransky)

I think out of memoy or maybe memory leak so you must have idea for these crash, every one in linux have same problem you can look in reports.

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

If you not fiz this problem firefox crash, crash ans crash in linux so users hate crash(when they catch never get fixed leave firefox and this is bad)

Priority: -- → P5

These are current, open bugs with a Severity of critical. The Severity of these bugs is being changed to S2 to be consistent with the May 4 2020 Severity definitions.

Please let Release Management know if these bugs are still S2.

Severity: critical → S2

what is wrong with firefox in linux even latest Firefox ESR 68.8.0 crash too please fix it

(In reply to Javad ahmadi from comment #17)

what is wrong with firefox in linux even latest Firefox ESR 68.8.0 crash too please fix it

Dear Javad, as Martin pointed out in comment 11, there is no way to understand better what is happening without further information. In particular if there are steps to reproduce. But also information about your environment in general might help, like:

  • The firefox is a binary release (from which distribution or channel?) or built from the sources?
  • It might seem from your stack trace, that you are using a debug build of libglib and libgtk? There seems to be an assertion from libglib that causes the crash on the stack.
  • Are you actively developing something for/in Firefox?

Thanks for your support!

Severity: S2 → S4
Flags: needinfo?(Crashdows)
The firefox is a binary release (from which distribution or channel?) or built from the sources? from (https://www.mozilla.org/en-US/exp/firefox/new)

Release channel, ESR channel and also download from offical source.

It might seem from your stack trace, that you are using a debug build of libglib and libgtk? There seems to be an assertion from libglib that causes the crash on the stack. idk, how to i know this??
Are you actively developing something for/in Firefox? no ofc not, just adding add-ons and changing setting but even without them also crash.
Flags: needinfo?(Crashdows)

i notice tor browser(based on firefox esr have same problem)

Severity: S4 → S2

sorry for interrupts but what is fix-optional?

It will probably not be fixed during Beta 78 although it would be good if it's possible.

S1 or S2 bugs need an assignee - could you find someone for this bug?

Flags: needinfo?(stransky)

Let's wait if there's any report from Nightly/79.

Flags: needinfo?(stransky)

hi
in 78.0.2 update i see nor crash for this and happy for that but yesterday i have once.
https://crash-stats.mozilla.org/report/index/9f08bb11-3ab3-40c2-bee3-ed5e20200723

(In reply to Martin Stránský [:stransky] from comment #24)

Let's wait if there's any report from Nightly/79.

i found a lot of reports from 78 and earlier, but is there any reports from nightly 79???

status-firefox79: --- → ?
status-firefox80: --- → ?

(In reply to Luker from comment #25)

hi
in 78.0.2 update i see nor crash for this and happy for that but yesterday i have once.
https://crash-stats.mozilla.org/report/index/9f08bb11-3ab3-40c2-bee3-ed5e20200723

Hi, I see a normal reaction of our abort() on a process level SIG_ABORT issued by a g_assert within GTK code called during native event processing. The build seems to have GTK debug symbols incorporated and G_DISABLE_ASSERT is apparently FALSE. So I would suspect, that some GTK expert should look on this? Still this seems a non-normal "end-user" mode of operating firefox, so more context on what you are actually doing here while crashing (debugging GTK?) would be great.

Flags: needinfo?(Crashdows)

(In reply to Jens Stutte [:jstutte] from comment #27)

(In reply to Luker from comment #25)

hi
in 78.0.2 update i see nor crash for this and happy for that but yesterday i have once.
https://crash-stats.mozilla.org/report/index/9f08bb11-3ab3-40c2-bee3-ed5e20200723

Hi, I see a normal reaction of our abort() on a process level SIG_ABORT issued by a g_assert within GTK code called during native event processing. The build seems to have GTK debug symbols incorporated and G_DISABLE_ASSERT is apparently FALSE. So I would suspect, that some GTK expert should look on this? Still this seems a non-normal "end-user" mode of operating firefox, so more context on what you are actually doing here while crashing (debugging GTK?) would be great.

hi i found a lot report with firefox 79 and 80 so please take a look to fix this bug

Flags: needinfo?(Crashdows)

It's assert/crash at set_button_image_get_info_cb(), looking at the code there are three asserts:

g_assert (GTK_IS_PATH_BAR (data->path_bar));
g_assert (G_OBJECT (data->path_bar)->ref_count > 0);

g_assert (cancellable == data->button_data->cancellable);

and the line number seems to match to:

g_assert (cancellable == data->button_data->cancellable);

From the backtrace it's difficult to say which button is affected. As it's not a startup crash, I guess some Gtk dialog is opened with a button
but it's difficult to say from the bt.

is there any working ? still crash

status-firefox81: affected → wontfix
status-firefox82: affected → wontfix
status-firefox83: --- → affected
status-firefox84: --- → ?
status-firefox85: --- → ?
Version: 74 Branch → Firefox 83

(In reply to Martin Stránský [:stransky] from comment #29)

From the backtrace it's difficult to say which button is affected. As it's not a startup crash, I guess some Gtk dialog is opened with a button
but it's difficult to say from the bt.

I've gone through some of the crashes which appear to be quite frequent on certain distros. Many user comments in the crashes mention clicking a button to upload a file so this happens while opening a file picker dialog, or downloading something which should also open a file picker dialog. The crash seems to happen just before the dialog shows up.

(In reply to Gabriele Svelto [:gsvelto] from comment #32)

(In reply to Martin Stránský [:stransky] from comment #29)

From the backtrace it's difficult to say which button is affected. As it's not a startup crash, I guess some Gtk dialog is opened with a button
but it's difficult to say from the bt.

I've gone through some of the crashes which appear to be quite frequent on certain distros. Many user comments in the crashes mention clicking a button to upload a file so this happens while opening a file picker dialog, or downloading something which should also open a file picker dialog. The crash seems to happen just before the dialog shows up.

yes exactly so you can guess what happenings!

I noticed there's at least two different crashes lurking behind this signature, one is related to the file-picker has something to do with icons. I'll file a bug to make the crash signatures more meaningful in the hope we can find a fix.

See Also: → 1696373
See Also: → 1634590
status-firefox88: --- → ?

Closing because no crashes reported for 12 weeks.

Status: REOPENED → RESOLVED
Closed: 5 years ago → 3 years ago
Resolution: --- → WORKSFORME

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #35)

Closing because no crashes reported for 12 weeks.

Good to see it get fixed in that cass if error occur i open this again, regards

Its happening again

Status: RESOLVED → REOPENED
status-firefox90: --- → wontfix
status-firefox91: --- → affected
Resolution: WORKSFORME → ---
Version: Firefox 83 → Firefox 90

Crash Reason SIGSEGV /SEGV_MAPERR
bp-71bceb7f-04aa-4c86-bfba-c8ef90210912

Closing because no crashes reported for 12 weeks.

Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
Resolution: --- → WORKSFORME

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #39)

Closing because no crashes reported for 12 weeks.

I'll open that if i found any related crash.

You need to log in before you can comment on or make changes to this bug.