Getting 'sending message to a Handler on a dead thread' (dev branch)

[dnutcracker]

When performing the following call from the UI main thread:
exoPlayer.blockingSendMessage(videoRenderer, MediaCodecVideoTrackRenderer.MSG_SET_SURFACE, null);

I randomly get the following exception:
05-03 13:41:39.468 23310-25973/me.samba.app W/MessageQueue﹕ Handler (com.google.android.exoplayer.upstream.Loader$LoadTask) {44fe3a10} sending message to a Handler on a dead thread
java.lang.RuntimeException: Handler (com.google.android.exoplayer.upstream.Loader$LoadTask) {44fe3a10} sending message to a Handler on a dead thread
at android.os.MessageQueue.enqueueMessage(MessageQueue.java:320)
at android.os.Handler.enqueueMessage(Handler.java:626)
at android.os.Handler.sendMessageAtTime(Handler.java:595)
at android.os.Handler.sendMessageDelayed(Handler.java:566)
at android.os.Handler.sendEmptyMessageDelayed(Handler.java:530)
at android.os.Handler.sendEmptyMessage(Handler.java:515)
at com.google.android.exoplayer.upstream.Loader$LoadTask.run(Loader.java:249)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)

What am I doing wrong?

[ojw28]

It's only a warning in the logs, right? What's actually happening here is that one of ExoPlayer's loading threads is notifying the playback thread after the playback thread has exited (because you called release() on the player). This is working as intended, and the warning can be safely ignored.

It's slightly unfortunate that the platform chooses to print this warning at all, since there are cases such as this one where the behavior is intentional and expected.

[dnutcracker]

Yep - it is a little bit annoying.

Can the release() ask the loading threads to stop?
Can the loading threads check if release() was called before trying to notify the playback thread?

[ojw28]

We can probably suppress it in most cases; I'll take a look at doing that. It's not possible to suppress it in 100% of cases though (doing this would require the playback thread to potentially block on network reads, which violates the threading model and may lead to application ANRs).

[dnutcracker]

Great. Thanks.

On Tue, May 5, 2015 at 11:41 AM, ojw28 [email protected] wrote:

We can probably suppress it in most cases; I'll take a look at doing that.
It's not possible to suppress it in 100% of cases though (doing this would
require the playback thread to potentially block on network reads, which
violates the threading model and may lead to application ANRs).

—
Reply to this email directly or view it on GitHub
#426 (comment).

[chrisjenx]

Wouldn't getLooper().getThread().isAlive() make more sense?

[ojw28]

I don't think any of these solutions are completely ideal. I'm inclined to do nothing, given there's no actual adverse affects to the user or application. The best long term solution would be a platform change to allow these kind of warnings to be turned off. I'll follow up internally about that (obviously it would only help in new platform releases).

[chrisjenx]

Yeah, I've seen them before, not sure why they are exposed to the user.

Agreed, was just my two cents.

On Thu, 20 Aug 2015 12:50 ojw28 [email protected] wrote:

I don't think any of these solutions are completely ideal. I'm inclined to
do nothing, given there's no actual adverse affects to the user or
application. The best long term solution would be a platform change to
allow these kind of warnings to be turned off. I'll follow up internally
about that (obviously it would only help in new platform releases).

—
Reply to this email directly or view it on GitHub
#426 (comment).

[issamux]

Any solution for this warning ?
Player show a warning icon (File not found) even if the link is ok .??)

08-26 13:07:45.977: W/MessageQueue(3405): Handler (android.os.Handler) {422005a8} sending message to a Handler on a dead thread

[chrisjenx]

@issamux sounds like two different issues, The Handler issue is safe to ignore as stated. Its just a warning, they shouldn't really be exposed to the user.

[issamux]

@chrisjenx yes, u're right ,bad link issue solved... but the handler warning message still loged in android log messages
thanks

[alexeyvasilyev]

Still getting this warning even on Android N Beta 3.
It is extremely annoying.

[ojw28]

Please clarify why it's extremely annoying? It's not like it spams logcat at high frequency or anything. Why don't you just ignore it?

[alexeyvasilyev]

It overloads app logs with useless information (stack) especially if you have used ExoPlayer a lot.

[ojw28]

To clarify, are these app specific logs, or do you mean general logcat? How are you capturing these logs?

[alexeyvasilyev]

It overloads app specific logs with

05-26 13:41:26.035 2376-2708/com.app.package W/MessageQueue: Handler (com.google.android.exoplayer.upstream.Loader$LoadTask) {e2106a} sending message to a Handler on a dead thread
java.lang.IllegalStateException: Handler (com.google.android.exoplayer.upstream.Loader$LoadTask) {e2106a} sending message to a Handler on a dead thread
at android.os.MessageQueue.enqueueMessage(MessageQueue.java:543)
at android.os.Handler.enqueueMessage(Handler.java:643)
at android.os.Handler.sendMessageAtTime(Handler.java:612)
at android.os.Handler.sendMessageDelayed(Handler.java:582)
at android.os.Handler.sendEmptyMessageDelayed(Handler.java:546)
at android.os.Handler.sendEmptyMessage(Handler.java:531)
at com.google.android.exoplayer.upstream.Loader$LoadTask.run(Loader.java:212)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)

[ojw28]

I know what the logging looks like. I'm asking where you're getting these logs from and why you can't just ignore the message? What is the workflow you have that is disrupted?

Overloading sounds like a bit of an exaggeration. The only time this message is printed is when the player is released (i.e. once per playback or similar). It's hard to argue that fixing this is more important than fixing pretty much anything that results in user visible issues.

[alexeyvasilyev]

My app has an option to read logs from logcat and send it to me. There is a fixed log buffer size in Android. When I check logs I see these logs which sometimes can overwrite more important information.

Of cause this bug is not important, but it is very annoying for those developers who check their logs.

[ojw28]

I don't think it's fixed size per application. I think it's fixed size shared by all applications, and given the amount of log spam other processes tend to produce the errors discussed here most likely have very minimal impact on the amount of useful logging that you're able to capture.

If you believe the above to be incorrect, could you please point to the documentation that describes a per application fixed size log buffer, and also explain what method/api you're using to read the logs.

[Bidp]

Hi, I think this does have a problem. The message sent to the dead thread is intended to release the memory that had allocated. And I toggled many times between prepare and release, each time this warning occurs, the memory is accumulating without releasing.

[ojw28]

@Bidp - This is correct, but it's only a problem if you try and re-use an Allocator across multiple instances of ExoPlayer over time, or if you continue to hold references to released ExoPlayer instances. Provided you instantiate a new Allocator instance for each player, and don't have references to released ExoPlayer instances, all memory should be garbage collected correctly.

We've fixed this issue in ExoPlayer 2.x (not yet available on GitHub). We have no plans to backport the change to 1.x.

[Bidp]

@ojw28 Thank you. Your reply solves my problem. Looking forward to ExoPlayer 2.x. Good job, guys.

[ojw28]

This is fixed in the 2.x.x experimental branch.

[ojw28]

Fixed in dev-v2, which is the V2 development branch.

[zhaojigao]

the application sends a message to the Handler that has exited