1449567 - Crash in java.lang.NullPointerException: NativeException NullHandle() [T = nsWindow::LayerViewSupport] at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method)

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect, P1)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-a2ca0a59-aba6-4a5b-b126-4cda60180322.
=============================================================

Java Stack Trace 	

java.lang.NullPointerException: NativeException NullHandle() [T = nsWindow::LayerViewSupport]
	at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method)
	at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:407)


Top 10 frames of crashing thread:

0 libxul.so mozilla::jni::detail::ProxyNativeCall<nsWindow::LayerViewSupport, mozilla::java::LayerSession::Compositor, false, false, const mozilla::jni::Ref<mozilla::jni::Object, _jobject*>&>::Call<false, false, 0> widget/android/jni/Natives.h:437
1 libxul.so mozilla::jni::detail::ProxyNativeCall<nsWindow::LayerViewSupport, mozilla::java::LayerSession::Compositor, false, false, const mozilla::jni::Ref<mozilla::jni::Object, _jobject*>&>::operator widget/android/jni/Natives.h:499
2 libxul.so mozilla::ThreadEventQueue<mozilla::PrioritizedEventQueue<mozilla::EventQueue> >::PutEventInternal xpcom/threads/ThreadEventQueue.cpp
3 libxul.so mozilla::detail::RunnableFunction<mozilla::jni::detail::ProxyNativeCall<nsWindow::LayerViewSupport, mozilla::java::LayerSession::Compositor, false, false, const mozilla::jni::Ref<mozilla::jni::Object, _jobject*>&> >::Run xpcom/threads/nsThreadUtils.h:529
4 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1040
5 libxul.so mozilla::detail::VariantImplementation<unsigned char, 0, const int, const char*, void > > mfbt/Variant.h:219
6 libxul.so NS_IdleDispatchToCurrentThread xpcom/threads/nsThreadUtils.cpp:324
7 libxul.so wcsrtombs 
8 libxul.so wcsrtombs 
9 libxul.so NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:517

=============================================================

these crashes on fennec are regressing since firefox 58. they mainly affect users on samsung devices and comments generally refer to using split-screen/multi-windows mode...

Comment 1

[Ryan VanderMeulen [:RyanVM]]

Over 260 crashes on release in the last week. Is this something maybe the SV folks could take a look at?

Comment 2

[:sdaswani]

Vlad, please have the crew look at this sooner rather than later.

Comment 3

[Vlad Baicu]

Hello, we've looked at the details and investigated a bit but this seems to be more of a core issue rather than frontend

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

This crash is still present in 61, with moderate (800 crashes/week) volume on release but not common on beta or nightly. 

User comment with STR:

Crash when resizing Firefox for use in overlay in other application  

Observed: Whenever resizing firefox into a small overlay window for use in other applications on a Samsung Galaxy Tab S3 Firefox has a high probability to crash. When it does crash, it does so immediately after resizing and will get frizen for a short while before crashing. After the crash has happened the window sometimes doesn 't close but isn 't interactive. It stays until I reopen Firefox and repeat the process of resizing or until I restart the Tablet.It also seems to relate to what software is in the background. When it 's a game probability for a crash is higher.

What I expected: Firefox shouldn 't just crash no matter what I do. Though the other sofware might be at fault here. Aso when it crashed it should close completely.

Steps to Reproduce: 
1 Start Firefox on a Samsung Galaxy Tab S3
2 Open another application
3 Drag any corner to resize the window. The page opened doesn 't seem to have any influence since the crash happenes with any page, even just the default starupp page.
4 If the crash hasn 't happened yet tab out of firefox and open the other application to view both.

Reproduceable: Yes random Occurence Likelyhood when following steps to reproduce ~75
Haven 't tested on other devices

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Susheel, might that help?

Comment 6

[:sdaswani]

It helps :lizzard, but I would need to get that device to see if we can STR.

Sorina, do you have a Samsung Galaxy Tab S3 available to try and repro?

Comment 7

[Sorina Florean [:sflorean]]

(In reply to :sdaswani only needinfo from comment #6)
> It helps :lizzard, but I would need to get that device to see if we can STR.
> 
> Sorina, do you have a Samsung Galaxy Tab S3 available to try and repro?

Yes, we have a Samsung Galaxy Tab S3(Android 8.0) and we will investigate following the information from comment 4 to see if we can get STR. Keeping the needinfo flag and get back with the results ASAP.

Comment 8

[Sorina Florean [:sflorean]]

Tested with the affected device but we weren't able to reproduce the crash. We performed steps from comment 4 and exploratory testing and everything worked fine. We only manage to reproduce bug 1439513 on an S8 device.

Comment 9

[:sdaswani]

David, we think this is a Gecko bug - can you have someone on your team take a look.

Petru - can you detail why you think it's a gecko bug?

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

It looks like this signature has been around a while. Jim do you know what's going on here?

Comment 11

[Vlad Baicu]

Well, the stacktrace points to a gecko/native issue and in absence of STRs I don't think there is much we can do here

Comment 12

[(inactive) Jim Chen [:jchen] [:darchons]]

Not sure of the exact cause of this but I have a speculative fix.

Comment 13

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Bug 1449567 - Don't reattach compositor for the same compositor object; r=snorp

If we're trying to detach and reattach the same compositor object for
whatever reason, we should skip it so we don't inadvertently end up not
attaching the object at all.

Comment 14

[Chris Peterson [:cpeterson]]

Should we uplift this fix to the GV 62 relbranch?

Comment 15

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 9008230 [details]
Bug 1449567 - Don't reattach compositor for the same compositor object; r=snorp

James Willcox (:snorp) ([e-mail]) has approved the revision.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52573727971b
Don't reattach compositor for the same compositor object; r=snorp

Comment 17

[Andreea Pavel [:apavel]]

Backed out for android build bustages

Push that started the failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=199540339&revision=52573727971b04056f78c20e6873215c2345bbba

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=199540339&repo=autoland&lineNumber=23751

Backout: https://hg.mozilla.org/integration/autoland/rev/300d0f16cf6f770200d2e57b1f7bed48f434ab65

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28888ba362a1
Don't reattach compositor for the same compositor object; r=snorp

Comment 19

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/28888ba362a1

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Please request Beta approval on this when you get a chance. Doesn't look like we'll be able to verify this bug until then.

Comment 21

[(inactive) Jim Chen [:jchen] [:darchons]]

Comment on attachment 9008230 [details]
Bug 1449567 - Don't reattach compositor for the same compositor object; r=snorp

Approval Request Comment
[Feature/Bug causing the regression]: N/A
[User impact if declined]: Low volume crash on some Samsung devices
[Is this code covered by automated tests?]: No
[Has the fix been verified in Nightly?]: No
[Needs manual test from QE? If yes, steps to reproduce]: No
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Not really
[Why is the change risky/not risky?]: Speculative fix that doesn't add any new behavior
[String changes made/needed]: None

Comment 22

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9008230 [details]
Bug 1449567 - Don't reattach compositor for the same compositor object; r=snorp

Uplift approved for 63 beta 8, thanks.

Comment 23

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7ffbd3e49f62

Comment 24

[Bogdan Surd, QA [:bsurd, NI]]

Device:
 - Samsung Galaxy Tab S3 (Android 8.0)

Tested following the steps in Comment 4, plus several other scenarios in the same context (large number of tabs opened, different addons/themes installed, with normal/private browsing, guest session). FF performed as expected in all of the scenarios, marking as verified.