Magisk-Modules-Repo / HideNavBar

GNU General Public License v3.0
498 stars 55 forks source link

There is a bug in your magisk module #39

Closed chunxiaoyi closed 3 years ago

chunxiaoyi commented 3 years ago

Module version: 8.7 Magisk version: 22.1(22100) Android version: 10 device: LG G8 install: Fullscreen + Low (Module Default)

Problems is in post-fs-data.sh this file. In my device (lg g8 with Android 10),when the device boots,the log shows

01-29 05:14:23.500  1423  1423 I Magisk  : HideNavBar: exec [post-fs-data.sh]
01-29 05:14:58.287  1423  1423 W Magisk  : * post-fs-data scripts blocking phase timeout
01-29 05:14:58.287  1423  1423 I Magisk  : riru_lsposed: exec [post-fs-data.sh]

(I just pick up the useful part in the boot log.And it will make riru_lsposed broken.) Why will it timeout?

The reason of causing this bug is this code in post-fs-data.sh resetprop ro.com.google.ime.kb_pad_port_b 1.0

Why will it (resetprop) cause bugs?We don't know yet,but it looks like magisk's problem. It is very hard to locate it,so,it's hard for magisk developers to fix it.

However,you can easily fix this problem by doing this. 1.Delete post-fs-data.sh 2.Make a new file called system.prop 3.Write this in system.prop ro.com.google.ime.kb_pad_port_b=1.0

I am using my own fixed versions now,and it works well so far.Now just reporting this bug to you for fixing it.

DanGLES3 commented 3 years ago

The reason why I've used a script instead of system.prop was so that i could check if any other gboard bottom padding altering module was present (and if they were the code wouldn't run and it would let those modules handle the padding instead) and if no other module was present it would insert that property

A fix seems to be to simply switch the script from a post-fs-data script to a service script (which wouldn't block boot), although I'm not sure a service script would consistently insert the property before Gboard starts up

Also this blocking seem to be rare, so far I've only gotten 2 reports of this issue, so I'm wondering why exactly are a few devices hanging at this simple script

chunxiaoyi commented 3 years ago

Actually,this blocking does be rare,we don't know why magisk will not exec resetprop. Anyway, what is the other bug device's name ?

chunxiaoyi commented 3 years ago

And this blocking happens randomly, sometimes riru_lsposed will still work. This is another questions cofused me.

By the way,when I update magisk to 22102 (offcial),this blocking will not happen again

DanGLES3 commented 3 years ago

And this blocking happens randomly, sometimes riru_lsposed will still work. This is another questions cofused me.

By the way,when I update magisk to 22102 (offcial),this blocking will not happen again

Alright, I've switched to using service.sh, try redownloading the module and check if the issue is fixed

yujincheng08 commented 3 years ago

The bug is because Magisk will load system.prop from modules and update system properties. However, system properties can only be upgraded by one single process and the process that acquires the lock will be Magisk if there is any module that contains system.prop and triggers Magisk to get the lock. Once that happens, resetprop will be blocked until Magisk finishes its loading.

In short, resetprop is not safe on post-fs-data.sh.

See comments about __system_property_update: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/_system_properties.h;drc=0fe22033095dc0805c191c37075eb0c3e9d29334;l=107

DanGLES3 commented 3 years ago

The bug is because Magisk will load system.prop from modules and update system properties. However, system properties can only be upgraded by one single process and the process that acquires the lock will be Magisk if there is any module that contains system.prop and triggers Magisk to get the lock. Once that happens, resetprop will be blocked until Magisk finishes its loading.

In short, resetprop is not safe on post-fs-data.sh.

See comments about __system_property_update: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/_system_properties.h;drc=0fe22033095dc0805c191c37075eb0c3e9d29334;l=107

You see, that's what confuses me, i have a few other modules that have system.prop but never once have i gotten this blockage, either way i've already switched to service.sh in the module