Crash when pressing search button

[Douile]

Checklist

• I am using the latest version - 74ad488
• I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

Similar to #6231 but different null pointer exception

0. Build the app from dev branch

1. Open app
2. Press search button

Actual behaviour

App crashes (ui error)

Expected behavior

App doesn't crash (no null pointer exception)

Screenshots/Screen recordings

Logs

Exception

• User Action: ui error
• Request: ACRA report
• Content Country: GB
• Content Language: en-GB
• App Language: en_GB
• Service: none
• Version: 0.21.5
• OS: Linux Android 11 - 30

Crash log

java.lang.NullPointerException: Attempt to invoke virtual method 'org.schabi.newpipe.extractor.linkhandler.SearchQueryHandlerFactory org.schabi.newpipe.extractor.StreamingService.getSearchQHFactory()' on a null object reference
	at org.schabi.newpipe.fragments.list.search.SearchFragment.onCreateOptionsMenu(SearchFragment.java:430)
	at androidx.fragment.app.Fragment.performCreateOptionsMenu(Fragment.java:3100)
	at androidx.fragment.app.FragmentManager.dispatchCreateOptionsMenu(FragmentManager.java:3181)
	at androidx.fragment.app.FragmentController.dispatchCreateOptionsMenu(FragmentController.java:391)
	at androidx.fragment.app.FragmentActivity.onCreatePanelMenu(FragmentActivity.java:288)
	at androidx.appcompat.view.WindowCallbackWrapper.onCreatePanelMenu(WindowCallbackWrapper.java:94)
	at androidx.appcompat.app.AppCompatDelegateImpl$AppCompatWindowCallback.onCreatePanelMenu(AppCompatDelegateImpl.java:3070)
	at androidx.appcompat.view.WindowCallbackWrapper.onCreatePanelMenu(WindowCallbackWrapper.java:94)
	at androidx.appcompat.app.ToolbarActionBar.populateOptionsMenu(ToolbarActionBar.java:456)
	at androidx.appcompat.app.ToolbarActionBar$1.run(ToolbarActionBar.java:57)
	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:972)
	at android.view.Choreographer.doCallbacks(Choreographer.java:796)
	at android.view.Choreographer.doFrame(Choreographer.java:727)
	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:957)
	at android.os.Handler.handleCallback(Handler.java:938)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:223)
	at android.app.ActivityThread.main(ActivityThread.java:7660)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

---

[TacoTheDank]

Are you just using 0.21.5 or did you specifically use the GitHub Action APK build of my PR?

[Douile]

I built from remote/dev on the commit specified

[Douile]

@TacoTheDank the issue also occurs on the github action build of the PR

[TacoTheDank]

I see 🤔

However, I don't really see why this could be triggering this bug to occur.

@opusforlife2 Any ideas?

[opusforlife2]

Wow, dude. I'm flattered, but I'm not a dev. 🤭

[Douile]

I did find a "fix" #6394 (comment)

[TacoTheDank]

I believe I have made a development.

This bug most likely has to do with two things:

• How they have rewritten the internals of FragmentManager in AndroidX Fragment 1.3.0.
• And AndroidX Fragment now uses AndroidX Lifecycle 2.3.1 internally as of 1.3.2, whereas NewPipe itself is still using 2.2.0.

I believe these are the source of this new bug (and may be the cause of possibly undiscovered new bugs as well).

There is likely some new behavior that NewPipe has not sufficiently accounted for, and that is the source of this bug. But, given all the weird shit we have to do around the app just to dispose of stuff properly when views and stuff are destroyed, I suppose this isn't surprising.

But this is the price of progress. If we're too afraid to take risks, we'd never get anywhere 😁

(Btw this bug came about because of the library bumps in #6394)

[opusforlife2]

@TacoTheDank So should this change be reverted for now, until a solution is found?

[Douile]

Observing the logging in this situation the following behavior occurs:

1. SearchFragment onCreate called
2. SearchFragment onStart called
3. SearchFragment onCreateOptionsMenu called (SearchFragment.service used without null check)
4. SearchFragment onResume called (SearchFragment.service set)

My approach to this would be moving setting the service from onResume to onStart (as per lifecycle docs it seems whenever fragment is displayed onStart then onResume is called) while also null checking in onCreateOptionsMenu. The null check is ultimately unnecessary would prevent crashes for similar issues (although maybe you want a crash so the issue is noticed).

A draft of this fix is here: Douile@384ca66

[B0pol]

Can you open a pull request?

[TacoTheDank]

@opusforlife2 I think it'll be okay. This bump would've needed to be done sooner or later anyway, so it's better that we catch it now. Also, @Douile has made a PR with the fix.

For some reason it didn't occur to me to test the searching function, even though I usually do when making PRs, so this happened to slip by me. Big oops on my part.