Null pointer exception during instruction 'monitor-enter v0'

[aloz77]

Some Android 5.0 and 5.1 devices produce NPE with the latest libsuperuser. However I'm not sure what exactly triggers these NPEs.

implementation 'eu.chainfire:libsuperuser:1.1.0.+'

java.lang.NullPointerException: Null pointer exception during instruction 'monitor-enter v0'
	at eu.chainfire.libsuperuser.f$y.c(Shell.java:2838)
	at eu.chainfire.libsuperuser.f$d.b(Shell.java:1875)
	at eu.chainfire.libsuperuser.f$d.m(Shell.java:1725)
	at eu.chainfire.libsuperuser.f$d.n(Shell.java:1526)
	at eu.chainfire.libsuperuser.f$d$8.a(Shell.java:2118)
	at eu.chainfire.libsuperuser.g.run(StreamGobbler.java:168)

[tobalr]

Same issue here on Android 6.0.1 device.
I get two different crash reports from this device:

1st type of crash report

Fatal Exception: java.lang.NullPointerException: Null pointer exception during instruction 'monitor-enter v0'
       at eu.chainfire.libsuperuser.Shell$Threaded.onClosed(Shell.java:2838)
       at eu.chainfire.libsuperuser.Shell$Interactive.runNextCommand(Shell.java:1875)
       at eu.chainfire.libsuperuser.Shell$Interactive.runNextCommand(Shell.java:1725)
       at eu.chainfire.libsuperuser.Shell$Interactive.access$3700(Shell.java:1526)
       at eu.chainfire.libsuperuser.Shell$Interactive$6.onStreamClosed(Shell.java:2118)
       at eu.chainfire.libsuperuser.StreamGobbler.run(StreamGobbler.java:168)

and
2nd type of crash report

Caused by java.lang.NullPointerException: Null pointer exception during instruction 'monitor-enter v0'
       at eu.chainfire.libsuperuser.Shell$Threaded.onClosed(Shell.java:2838)
       at eu.chainfire.libsuperuser.Shell$Interactive.runNextCommand(Shell.java:1875)
       at eu.chainfire.libsuperuser.Shell$Interactive.runNextCommand(Shell.java:1725)
       at eu.chainfire.libsuperuser.Shell$Interactive.open(Shell.java:2218)
       at eu.chainfire.libsuperuser.Shell$Interactive.<init>(Shell.java:1665)
       at eu.chainfire.libsuperuser.Shell$Threaded.<init>(Shell.java:2728)
       at eu.chainfire.libsuperuser.Shell$ThreadedAutoCloseable.<init>(Shell.java:2909)
       at eu.chainfire.libsuperuser.Shell$Builder.openThreadedEx$2f1695e8(Shell.java:1348)
       at eu.chainfire.libsuperuser.Shell$Builder.access$4900$4b409c5f(Shell.java:969)
       at eu.chainfire.libsuperuser.Shell$Pool.newInstance(Shell.java:3316)
       at eu.chainfire.libsuperuser.Shell$Pool.get$6c5e7630(Shell.java:3446)
       at eu.chainfire.libsuperuser.Shell$Pool.get(Shell.java:3401)
       at eu.chainfire.libsuperuser.Shell$PoolWrapper.get(Shell.java:2961)
       at eu.chainfire.libsuperuser.Shell$PoolWrapper.run$11bf2cfc(Shell.java:3019)
       at eu.chainfire.libsuperuser.Shell$PoolWrapper.run(Shell.java:3051)
       at eu.chainfire.libsuperuser.Shell.run$3f01f0ae(Shell.java:197)
       at eu.chainfire.libsuperuser.Shell$SU.run(Shell.java:435)
       at eu.chainfire.libsuperuser.Shell$SU.available(Shell.java:449)

I'm using.
implementation 'eu.chainfire:libsuperuser:1.1.0.201907261845'

It puzzles me that the available() method seems to interact with Shell.threaded. This should not be the behaviour as far as I can read from the code. I suspect that this might be related to some kind of threading / synchronization error.

[Chainfire]

Need minimal code to reproduce and as much device info as possible.

If you're not using Interactive/Threaded mode anyway, you might be able to work around the issue for now by calling Shell.setRedirectDeprecated(false) from Application::onCreate().

It's certainly strange though, the synchronizer at the quoted line should never be null. It seems to happen if the shell was unexpectedly closed, reading the line numbers that were hit before the NPE.

[tobalr]

Unfortunately I'm unable to reproduce this yet.
The app where I have included libsupersu have been released to 15 test devices. Three of these devices run the exact same hardware and firmware as the affected. This leads me to think that this issue is timing related.

I have set the following NewBuilderListener. Could this be related to the issue?

    static {
        Shell.Pool.setOnNewBuilderListener(() -> {
            Shell.Builder builder = new Shell.Builder()
                    .useSU()
                    .setWatchdogTimeout(30);
            return builder;
        });
    }

I can see that the affected device keeps crashing (500 + times)
I'm trying to get in contact with the owner so that I can test the issue - however so far without success.
If I get access to the device I will test with Shell.setRedirectDeprecated(false)

Our code do make use of Threaded mode for some other calls. I fear that this issue could occur for these calls as well..

[Chainfire]

Reading up some more, the only reason I can come up with for the synchronizer causing an NPE (as you can read in the code its a final member of the Shell.Threaded instance) is that the instance is being garbage collected during the onClosed() call. Probably L2833 removes the last reference.

I think that would be relatively easy to test (and fix), but we need a testable case first. I have some ideas on how to make one.

I do not believe your NewBuilderListener is related.

[Chainfire]

Also any info about the specific device, firmware, root app and version, is welcome.

[tobalr]

Great to hear that there might be a way ahead!

I have the following information on the device:
Low ram device (512mb). LargeHeap enabled so the app has rough 192MB
Device fingerprint: rk312x/rk312x:6.0.1/MXC89K/user.liuh.20170405.141404:user/release-keys
SU binary: 2.45:SUPERSU
App implementing libsuperuser is running as launcher and is always in foreground as kiosk.

Is there anything else I can do or more exact information I can provide?

Thank you so much for all your hard work on superSU and in the community! I hope you and your family are safe during all this.

[Chainfire]

I pushed a new version, you may see if that works:
1.1.0.202004101746

See 5005486

[tobalr]

Cool! I'll give it a spin.

[tobalr]

It looks good. I have still not been able to get access to the device that was showing the issue and thus cannot verify the fix completely. I hope to be able to do so soon an will inform you then.
I will update our code to use the new version. If it makes it through testing it will gradually roll out thousands of similar devices so we should be able to get see if the issue persists.

Thank you.