fix: potential crash caused by dlopen different gtk libraries - #33650
Conversation
|
Hi @deepak1556. Thanks for tracking down the source of the issue. With your PR, I am a little confused how any of the Where is the definition of |
|
|
|
Ok cool. Thanks for the background. This PR sounds like a good solution then. I wonder if Flatpak has the same issue. |
|
Not familiar with flaptak, but if it does not search for libraries from the host then worst case would be it fails to load the required gtk version with the symbols and end up calling the legacy dialog fallback. I think only classical snaps can run into this crash edge case. |
|
I am not at all familiar with the confinement of snap vs classical snap vs flatpak. As you said, I guess classical snap is the outlier here and it is really weird to have to program around this packaging format when seemingly it would work for snap and flatpak. |
| Subject: Make gtk::GetLibGtk public | ||
|
|
||
| Allows embedders to get a handle to the gtk library | ||
| already loaded in the process. |
There was a problem hiding this comment.
should this be upstreamed?
There was a problem hiding this comment.
I can give it an attempt.
|
Release Notes Persisted
|
|
I was unable to backport this PR to "16-x-y" cleanly; |
|
I was unable to backport this PR to "17-x-y" cleanly; |
|
I have automatically backported this PR to "19-x-y", please check out #33813 |
fix: potential crash caused by dlopen different gtk libraries (#33650)
Description of Change
#19159 refactored file dialog implementation that relies requiring gtk library at runtime, around the same time chromium has been refactoring itself to also require gtk at runtime https://bugs.chromium.org/p/chromium/issues/detail?id=1192861
Since chromium already loads the required gtk library into the process on startup, the file dialog implementation should just get a handle to the loaded library and perform operations on it, the current implementation can lead to situations in classic snaps where two different version gtk libraries can get loaded into the same process triggering a crash, refs microsoft/vscode#146584 (comment)
NB: There is no functionality change in this PR, simplifies library loading following upstream changes and fixes potential crash alongside.
/cc @tristan957
Checklist
npm testpassesRelease Notes
Notes: fix crash when opening gtk file dialogs due to mismatched versions