Applying filters fails often, hangs daemonsu

[paour]

On a Galaxy S3 running CM 10.2, with SuperSU 1.80, Adaway 2.8 often fails to apply filter changes (after successfully downloading the various files). When it does, it leaves one of the daemonsu:nnnnn processes in such a state that the process consumes 100% of one core and keeps the CPU awake, running down the battery.

What sort of logs should I provide so that you can investigate and fix the issue?

[khaytsus]

I find that adaway has a dozen or so entries in the SuperSU logs for when it automatically applies filters, so I'm not sure if this is related or is harmless but I don't see any other apps which appear to request root that many times at once or in a row.

[ericlathrop]

This happens for me with SuperSU 1.86, AdAway 2.8, Stock KitKat 4.4.2 on both my Nexus 5 and Nexus 10.

It doesn't happen every day, but when it does it looks like this:

• During the daily update check I'll get a "AdAway has stopped unexpectedly" dialog. There's only an "OK" button, no "Report" button like other crash dialogs.
• AdAway will leave the "updating..." notification in my tray, and it cannot be dismissed.
• Using OS Monitor I can see the daemonsu:xxxxx is burning up CPU
• If I force stop AdAway, then open a root terminal to kill the daemonsu:xxxxx process, I can reopen AdAway to successfully check for updates.

[Human]

I recently re-created this bug and here's a relevant section of the logs:

E/AndroidRuntime( 3214): FATAL EXCEPTION: IntentService[AdAwayApplyService]
E/AndroidRuntime( 3214): Process: org.adaway, PID: 3214
E/AndroidRuntime( 3214): java.lang.RuntimeException: org.sufficientlysecure.rootcommands.util.RootAccessDeniedException: stdout line is null! Access was denied or this executeable is not a shell!
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Remounter.findMountPointRecursive(Remounter.java:144)
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Remounter.remount(Remounter.java:115)
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Toolbox.remount(Toolbox.java:733)
E/AndroidRuntime( 3214):    at org.adaway.util.ApplyUtils.copyHostsFile(ApplyUtils.java:195)
E/AndroidRuntime( 3214):    at org.adaway.service.ApplyService.apply(ApplyService.java:399)
E/AndroidRuntime( 3214):    at org.adaway.service.ApplyService.doWakefulWork(ApplyService.java:100)
E/AndroidRuntime( 3214):    at com.commonsware.cwac.wakeful.WakefulIntentService.onHandleIntent(WakefulIntentService.java:100)
E/AndroidRuntime( 3214):    at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
E/AndroidRuntime( 3214):    at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 3214):    at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 3214):    at android.os.HandlerThread.run(HandlerThread.java:61)
E/AndroidRuntime( 3214): Caused by: org.sufficientlysecure.rootcommands.util.RootAccessDeniedException: stdout line is null! Access was denied or this executeable is not a shell!
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Shell.(Shell.java:147)
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Shell.startRootShell(Shell.java:62)
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Shell.startRootShell(Shell.java:74)
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Remounter.getMounts(Remounter.java:166)
E/AndroidRuntime( 3214):    at org.sufficientlysecure.rootcommands.Remounter.findMountPointRecursive(Remounter.java:134)
E/AndroidRuntime( 3214):    ... 10 more

[paour]

Probably related to #476.

[Human]

If I understand #476 correctly, it's that the hosts file changes are not being used by the OS. This issue seems to be about failures to change the hosts file, so I don't think they're related.

[heldchen]

had the hosts update problem since 4.4.0 (now on 4.4.2). can confirm the daemonsu hanging process(es) killing my battery. also seeing lots of adaway supersu requests.

[d4rken]

This issue is not directly caused by AdAway but by the library "RootCommands" used by it.
In my case it was specifically the function remount that failed.
After which obviously the other operations could not work either because /system was still read only.

I fixed the issue for myself by replacing the code in that function with something that opens an unrelated root shell independent of the RootCommands library. It's a lazy fix, but i really did not want to dive into the RootCommands library to find the underlying issue. Sorry.

The code:
https://gist.github.com/d4rken/8428287
I modified the findMountPointRecursive and remount function.

I don't know whether this works for you, but you can try if you want.
http://goo.gl/eFUCy8
The only changed file is the one from the gist above.

[paour]

Thank you. Since there are few official updates, a hacked and temporary fix
is much appreciated!

Note to others: because the apk signature is different, the official app
needs to be uninstalled prior to installing this one. Remember to backup
your preferences with TiBu first.

[wbedard]

Just wanted to chime in to say that d4rken's release fixes this issue for me, too. I'm really grateful for the generous community support and I hope this fix gets rolled into future official releases!

[Condor70]

Patch also works on a stock 4.3 Galaxy Nexus rooted with SuperSU.

[shoman94]

Patch worked on Samsung Galaxy s4 on 4.4.2

[nemchik]

The fix seems to work well for me on CyanogenMod 11 on my LG G2 d800. Please merge.

[Jake90]

Upgrading vom CM 10.x to CM 11 works perfect

Only problem is if CM11 is the first installation

[ITGeekMonkeys]

Patch worked on N4, Paranoid Android, SuperSu

[cray-]

Patched version worked on N4, 4.4.2, CM11-M3. Cheers!

[Magissia]

Hello @d4rken , i'm facing the problem you seem to have fixed on your fork, did you tried to send a pull request on your fix ? It would be nice to have your fix merged.

[d4rken]

@Magissia No i didn't. I don't consider the change i made as something that should be merged. It was a workaround not the real solution. As far as i could see the issue was not with AdAway but with the root library being used. It replaced a call to the root library with a custom root call.

The clean solution would be to fix the underlying issue in the root library or replace every use of the library with something different.

[Magissia]

@d4rken Someone reported the problem on library's issue tracker ? (seems not on my side, worth double checking in case i didn't checked at the correct place https://github.com/dschuermann/superuser-commands/issues )

[d4rken]

@Magissia Did now , :p Free-Software-for-Android/RootCommands#23

[justmwa]

Same issue on LG G Pad 8.3, Samsung Galaxy S4 and Notes2 (all running stock 4.4.2). While I understand that the issue is not with the app itself and the hack fixes an external lib, the reality is that if the underlying lib is not going to be fixed, AdAway is broken in its official version with many recent Android releases. I did the mount myself to ln -s from /data/data/hosts but it would be cleaner to have a working app in the first place . Thanks anyway for this must-have apk!

[Dragon31337]

Can someone build a 2.8.1 version with this temporary fix? Seems like I have the same issue on my Motorola DRIOD Maxx with KitKat 4.4.

[Condor70]

Latest AdAway patched build can be downloaded from XDA:
http://forum.xda-developers.com/showthread.php?t=2190753

It looks like everybody using SuperSU instead of Superuser (independent of the phone make and model) needs the patched build.

[Magissia]

@Condor70 thanks for the analysis.

[hjjiang]

the one uploaded to XDA:
http://forum.xda-developers.com/showthread.php?t=2190753

links to a file that is ~300kbps which is too small:
http://d-h.st/lZ4

[Dragon31337]

Updated version works like a charm for a couple of month already. This should be integrated to the main branch.

[hjjiang]

are you talking about the regular 2.8.1?

[Dragon31337]

I'm about modified version of adaway. Both original 2.8 and 2.8.1 did not update my hosts file properly and hang every now and than on update while patched versions from this thread work flawlessly.

[hjjiang]

could someone reupload 2.8.1 modified version or is this link correct? http://d-h.st/lZ4

[Magissia]

It's more complicated than that, let's be patient

[BlackX777]

After a change from SuperSU to Superuser, the original pp works fine. So maybe the problem is SuperSU.

[nemchik]

I'm going to say that's not the case and I believe it's already been
discussed in the contents here. Also I've experienced this issue on all of
the su managers (superuser by chainsdd, superuser by koush, SuperSU, etc).
With some of them this issue happens more often, and with others it happens
less, but still happens eventually.

Unfortunately this is an issue with adaway. Someone graciously posted a
patched version of adaway with a fix in the comments here.
On Aug 10, 2014 4:58 AM, "BlackX777" notifications@github.com wrote:

After a change from SuperSU to Superuser, the original pp works fine. So
maybe the problem is SuperSU.

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

[nemchik]

Apologies, the issue isn't with adaway directly, it's with the root library adaway uses for root access (my first response was via email so I hadn't looked back at the contents). To better explain;

Adaway -> root library (RootCommands) -> su binary -> su app

The su binary and su app are usuals bundled together and maintained by one person (like chainfire, koush, or chainsdd).
The root library, in this case RootCommands makes the requests to the su binary on behalf of the app. This might not be how all apps operate, but it seems to be how adaway operates. The real issue is with RootCommands.

So this leaves the adaway Dev with two options; fix the RootCommands library being used by adaway, or stop using RootCommands all together and rewrite adaway to use another method of calling the su binary.

For those reading this that have more direct knowledge of the situation, I apologize if I've butchered anything, this is my basic understanding of the situation from the outside.

[dschuermann]

@nemchik that is correct.
My idea was to rebuild RootCommands based on Chainfire's libsuperuser, but I am too busy with other Android projects in my free time, so this is currently on hold.
The faster option to make a quick fix for the current RootCommands version without rebuilding it will be no sustainable solution due to all upcoming problems with Android L, but I appreciate pull requests. Unfortunately, an extreme amount of people are using the app, but no one did a mergable pull request. I actually get way more pull requests for my other less used Android apps than here. Maybe AdAway works for the tech-savy people because they use a Android distribution like Cyanogenmod, and not stock roms with SuperSU ;)

[DavisNT]

This may be fixed by pull request #536

[DavisNT]

Can somebody who had this issue verify that it is fixed in AdAway 2.9?

[Arinerron]

Please check issue #476