Ok this is something new for me. I thought that LD_PRELOAD is only for dynamic libraries. That’s why I couldn’t get this inside my mind.
yes I’m applying the patch through patch manager.
I was just confused that when I ssh onto the phone and do: vi /usr/share/sailfish-browser/pages/SettingsPage.qml
I see the patch there. So you’re saying that it’s working like this system wide? I.e. what I see in VI is already “patched”?
This is still correct.
Part of Patchmanager is a shared library (ld_preloaded) which basically hijacks file open operations for files modified by patches, and substitutes the patched contents.
This way patches never modify files on disk.
I see then the bug should be changed as it’s not related to official SFOS but it’s some problem with patchmanager. So now we need to find out what’s wrong with it.
Thaaanks for the help explaining me this.
Exactly. Try NO_PM_PRELOAD=1 vi /usr/share/sailfish-browser/pages/SettingsPage.qml to see the original.
@vlagged
I spot something more lately. It seems crash is not relevant for the patch to stop working.
It’s just enough to close the browser, left the phone for hour or more then try to use it back and see the browser is without a patch again. Killing that booster is enough to get patch back.
Could be that booster is using some different mechanism instead of open to read the file? Or what exactly the booster is doing? It seems it’s the common denominator in this equation.
Sorry, I will try to find sources for the browser-booster, Search · org:sailfishos booster · GitHub is not promising