Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NullPointerException in DownloadManager$InternalHandler.onContentLengthChanged() #8078

Closed
tuesda opened this issue Oct 15, 2020 · 6 comments
Closed

NullPointerException in DownloadManager$InternalHandler.onContentLengthChanged() #8078

tuesda opened this issue Oct 15, 2020 · 6 comments
Assignees
@ojw28
Labels
bug

Comments

@tuesda
Copy link

tuesda commented Oct 15, 2020

[REQUIRED] Issue description

  • there are some crashes on sentry which occurs in DownloadManager.InternalHandler.onContentLengthChanged()
  • this crash is new on exoplayer 2.12.0, there is zero crash on exoplayer 2.11.7

[REQUIRED] Reproduction steps

It is hard to reproduce for me on my device, but I found 600 times crash on sentry which occurs on user's devices

[REQUIRED] Link to test content

There is no specific content for this issue, regarding of this crash's frequency, I guess this crash is not related with specific media content.

[REQUIRED] A full bug report captured from the device

java.lang.NullPointerException: throw with null exception
    at com.google.android.exoplayer2.util.Assertions.checkNotNull(Assertions.java:1)
    at com.google.android.exoplayer2.offline.DownloadManager$InternalHandler.onContentLengthChanged(DownloadManager.java:2)
    at com.google.android.exoplayer2.offline.DownloadManager$InternalHandler.handleMessage(DownloadManager.java:6)
    at android.os.Handler.dispatchMessage(Handler.java:107)
    at android.os.Looper.loop(Looper.java:224)
    at android.os.HandlerThread.run(HandlerThread.java:67)

[REQUIRED] Version of ExoPlayer being used

2.12.0
There is zero of this crash on Exoplayer version below 2.12.0 (like 2.11.7

[REQUIRED] Device(s) and version(s) of Android being used

A variety of kinds of devices are found, list as below
image

Additional Info

almost crash occurs after DownloadService is destroyed
@marcbaechinger marcbaechinger self-assigned this Oct 16, 2020
@marcbaechinger
Copy link
Contributor

Thanks for reporting. I'll look into this asap.

@finneapps
Copy link

finneapps commented Nov 19, 2020 •
edited
Loading

I am also seeing this crash on 2.12.1. In my case It seems to be happening when a download fails after resuming the app

@ojw28
Copy link
Contributor

ojw28 commented Nov 19, 2020 •
edited
Loading

What type of content is being downloaded in these cases? Adaptive (i.e., HLS / DASH / SmoothStreaming) or progressive (i.e., regular media files like MP4 / MP3, etc)?

@ojw28 ojw28 assigned ojw28 and unassigned marcbaechinger Nov 19, 2020
@ojw28
Copy link
Contributor

ojw28 commented Nov 19, 2020

Also, are you passing an Executor to the DownloadManager constructor, or using one of the constructors that doesn't take one? If you are passing one, which thread does it execute the downloads on?

@ojw28
Copy link
Contributor

ojw28 commented Nov 19, 2020

If the answers are (1) progressive media, and (2) using a separate executor, then I have figured out what's wrong. We will provide a fix shortly.

ojw28 added a commit that referenced this issue Nov 20, 2020
@ojw28
Fix ProgressiveDownloader retry logic
1b50071 
RunnableFutureTask is not reusable. Trying to reuse it meant that a
failure in one doWork() call would cause subsequent download() calls
to (a) not block until the runnable has finished executing (does not
apply when using a direct executor), and (b) throw the same failure
as thrown from the first doWork() call.

This could cause #8078 if the initial failure occurred before the
content length was resolved. Retries are not blocked on their work
completing due to (a), and the download would be marked as failed due
to (b). The work itself could then resolve the content length, which
causes the stack trace in this issue.

Issue: #8078
PiperOrigin-RevId: 343498252
@ojw28
Copy link
Contributor

ojw28 commented Nov 20, 2020

The fix ref'd above will be included in the 2.12.2 release, which is due in the next couple of weeks.

@ojw28 ojw28 closed this as completed Nov 20, 2020
roblav96 pushed a commit to roblav96/ExoPlayer that referenced this issue Nov 24, 2020
@ojw28 @roblav96
Fix ProgressiveDownloader retry logic
18f7d85 
RunnableFutureTask is not reusable. Trying to reuse it meant that a
failure in one doWork() call would cause subsequent download() calls
to (a) not block until the runnable has finished executing (does not
apply when using a direct executor), and (b) throw the same failure
as thrown from the first doWork() call.

This could cause google#8078 if the initial failure occurred before the
content length was resolved. Retries are not blocked on their work
completing due to (a), and the download would be marked as failed due
to (b). The work itself could then resolve the content length, which
causes the stack trace in this issue.

Issue: google#8078
PiperOrigin-RevId: 343498252
icbaker pushed a commit that referenced this issue Nov 30, 2020
@ojw28 @icbaker
Fix ProgressiveDownloader retry logic
3a8524d 
RunnableFutureTask is not reusable. Trying to reuse it meant that a
failure in one doWork() call would cause subsequent download() calls
to (a) not block until the runnable has finished executing (does not
apply when using a direct executor), and (b) throw the same failure
as thrown from the first doWork() call.

This could cause #8078 if the initial failure occurred before the
content length was resolved. Retries are not blocked on their work
completing due to (a), and the download would be marked as failed due
to (b). The work itself could then resolve the content length, which
causes the stack trace in this issue.

Issue: #8078
PiperOrigin-RevId: 343498252
@google google locked and limited conversation to collaborators Jan 20, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@ojw28 ojw28

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@marcbaechinger @tuesda @finneapps @ojw28