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.

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

Vivaldi not Loading Websites #22

Open
marcoh242 opened this issue Apr 30, 2024 · 14 comments
Open

Vivaldi not Loading Websites #22

marcoh242 opened this issue Apr 30, 2024 · 14 comments
Labels
bug Something isn't working

Comments

@marcoh242
Copy link

marcoh242 commented Apr 30, 2024

So I installed the latest(7cbb41b) version of Zygisk-Assistant with KSU and got finally my banking app running with that. Unfortunetely my browser vivaldi wont display any website anymore as long this module is active. Other browser work fine...so not sure where to look to debug that.

@snake-4
Copy link
Owner

snake-4 commented Apr 30, 2024

Could you try these steps?

  1. Disable other modules.
  2. Install the latest debug build of this module.
  3. After reproducing the bug, do adb logcat > log.txt on your PC and upload the log here.

@snake-4 snake-4 added the question Further information is requested label Apr 30, 2024
@marcoh242
Copy link
Author

This issue only occurs when Zygisk-Assistant AND https://github.com/AndroidAudioMods/ViPER4Android is active.
As I dont really need Viper4Android its no big issue for me. Attached the log anyway if u wanna look over it.
log.txt

@snake-4
Copy link
Owner

snake-4 commented Apr 30, 2024

I've checked the log and I don't think the ViPER's bind mount is there at all and this is what the chromium crash log states:
[ERROR:gl_display.cc(515)] EGL Driver message (Error) eglCreateContext: Requested GLES version (3.0) is greater than max supported (2, 0).

Have you tried without Shamiko as well? The issue doesn't seem related to either modules.

@marcoh242
Copy link
Author

marcoh242 commented Apr 30, 2024

Tested it now only with Viper4Android and Zygisk-Assistant and it doesnt work. Disabling on of them and it works.

@privacyguy123
Copy link

A Shamiko dev once helped me fix it with

ro.zygote.disable_gl_preload=1

Perhaps same issue with your module if you are mass umounting things

@snake-4
Copy link
Owner

snake-4 commented Apr 30, 2024

A Shamiko dev once helped me fix it with

ro.zygote.disable_gl_preload=1

Perhaps same issue with your module if you are mass umounting things

This makes sense and it was mentioned in another issue too. But I didn't think that would be the case here since Viper module doesn't seem replace the OpenGL drivers.

@aviraxp
Copy link

aviraxp commented May 2, 2024

I am still looking on this too. I am not sure how OpenGL has to do with it. I only note that umount every module that mounts files in /vendor will cause this behavior.

Note OpenGL is preloaded in zygote as well, so maybe there is some additional checks that will be inconsistent and fail after umounting?

@aviraxp
Copy link

aviraxp commented May 2, 2024

Also, this issue seems only exist on ksu.

@snake-4
Copy link
Owner

snake-4 commented May 2, 2024

I am still looking on this too. I am not sure how OpenGL has to do with it. I only note that umount every module that mounts files in /vendor will cause this behavior.

Note OpenGL is preloaded in zygote as well, so maybe there is some additional checks that will be inconsistent and fail after umounting?

Oh, I figured it out! When there are files to be replaced, KSU mounts an overlayfs over the parent folder, whereas Magisk modules just bind mount the files.

I'm sure this is obvious, but when you call umount2(..., MNT_DETACH) the overlayfs device gets detached from the FS tree. The problem is that every file opened on /vendor before that would refer to the overlayfs device in their inode structures and not the lowerdir device. So procfs wouldn't be able to determine the base path for these FDs because the device that inode refers to is not in the FS tree anymore!

Zygote just closes these FDs after the fork because the path appears like /egl/lib.so. Now, not all Adreno drivers open FDs to other libs on preload. Particularly, drivers of Adreno 630 don't seem to do this but Adreno 660 drivers do it.

I'm thinking of getting rid of MNT_DETACH entirely because it has too many side effects. I think we can instead close the FDs, unmount normally without MNT_DETACH, then re-open all FDs so they would refer to the correct device.

This would also solve #11 but I'm not sure if that's how I want to solve that one because I think just replacing the FDs without actually removing the RROs from AssetManager would have some side effects.

@snake-4 snake-4 added bug Something isn't working and removed question Further information is requested labels May 3, 2024
@privacyguy123
Copy link

You've blown my mind wide open with this latest explanation - good work. You've helped explain a lot of weirdness I've been trying to work out on my side

@snake-4
Copy link
Owner

snake-4 commented May 5, 2024

@marcoh242 Could you try the latest CI debug build and see if that fixes the problem? Also please attach the logs even if it works.

@marcoh242
Copy link
Author

Not working
log.txt

@snake-4
Copy link
Owner

snake-4 commented May 5, 2024

I see. I can't reproduce this bug on my only device probably because it's 4.9 and 2a9c6d0 (ovl: allocate anonymous devs for lowerdirs) was added in 4.15. I'm sure that a dlopen is failing somewhere in the EGL libs likely because the dev changes.

If anyone wants to give it a go, check linker logs with LD_DEBUG=3. Also compare lsof -p $(pidof zygote64) with lsof -p $(pidof com.vivaldi.browser) both with the module on and off.

@oldman20
Copy link

hello, i think i have similiar case, but with EDGE, i install 1f2e9d3 and edge just black screen, asa force close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants