Closed Bug 1639275 Opened 5 years ago Closed 5 years ago

Crash in mozilla::widget::Base64UtilsSupport::Encode

Categories

(GeckoView :: General, defect, P1)

Unspecified
Android
defect

Tracking

(firefox-esr68 wontfix, firefox76 wontfix, firefox77 wontfix, firefox78 fixed)

RESOLVED FIXED
mozilla78
Tracking Status
firefox-esr68 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- fixed

People

(Reporter: agi, Assigned: snorp)

Details

(Keywords: crash, Whiteboard: [geckoview:m78])

Crash Data

Attachments

(1 file)

This bug is for crash report bp-4fda00b7-8785-4c54-83a0-0b88f0200519.

A reddit user is seeing frequent crashes with this signature.

https://www.reddit.com/r/firefox/comments/gmqkcp/random_crash_error_from_firefox_nightly_after/fr5gk3u/

Looks like something in jni, aklotz any ideas?

Top 10 frames of crashing thread:

0 libc.so libc.so@0x83134 
1 libc.so libc.so@0x83104 
2 libart.so libart.so@0x4b3c08 
3 libbase.so libbase.so@0xc5b4 
4 libart.so libart.so@0x374a94 
5 libart.so libart.so@0x3c1f40 
6 libxul.so mozilla::jni::ArrayRefBase<_jbyteArray*, signed char>::GetElements const widget/android/jni/Refs.h:819
7 libxul.so _jstring* mozilla::jni::NativeStub<mozilla::java::Base64Utils::Encode_t, mozilla::widget::Base64UtilsSupport, mozilla::jni::Args<mozilla::jni::Ref<mozilla::jni::TypedObject<_jbyteArray*>, _jbyteArray*> const&> >::Wrap<&mozilla::widget::Base64UtilsSupport::Encode> widget/android/jni/Natives.h:690
8 base.odex base.odex@0x1964ec 
9 base.odex base.odex@0x1964ec 

Flags: needinfo?(aklotz)

I'm wondering if we have more of these buried under the libc.so@<addr> signature.

Some kind of failure retrieving the length of an array, but that's the best I can do without analyzing the raw dump (which is a non-trivial process).

Flags: needinfo?(aklotz)

Thanks, I skimmed our crashes, they're all in mozilla::widget::Base64UtilsSupport under various libc.so signature.

Crash Signature: [@ libc.so@0x83134 | libc.so@0x83104 | libart.so@0x4b3c08] → [@ libc.so@0x83134 | libc.so@0x83104 | libart.so@0x4b3c08] [@ libc.so@0x1cece | libart.so@0x35128f ] [@ libc.so@0x77a88 | libc.so@0x1e6a0 | libart.so@0x436920 ] [@ libc.so@0x4aaa0 | libart.so@0x338b71 ] [@ libc.so@0x21c64 | libc.so@0x21c38 | libart.so…

Looks like there's been an uptick recently. I wonder if it runs some java stacks after the jni call.

Summary: Crash in [@ libc.so@0x83134 | libc.so@0x83104 | libart.so@0x4b3c08] → Crash in mozilla::widget::Base64UtilsSupport::Encode

snorp, ni in case you have ideas.

Flags: needinfo?(snorp)

It looks like we're just missing a null check in the native side.

Assignee: nobody → snorp
Flags: needinfo?(snorp)
Severity: -- → S2
Priority: -- → P1
Whiteboard: [geckoview:m78]
Pushed by jwillcox@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/f121c6c8aeb0 Add some null checking to Base64Utils r=geckoview-reviewers,aklotz
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: