Open EionRobb opened 1 month ago
Thank you for the report. I did not check the Windows build lately. I just assumed "if it builds, it works". So much for that… Since the problem manifests during the probing and not the actual execution, I suspect issues somewhere in the build process (compilation, linking,…). I hope I can look into it next week.
Unfortunately, I am unable to reproduce this behaviour. I tested the nightly offered by github and a local build in Pidgin 2.14.12 and 2.14.13 on my private Windows 10 installation and my place of work. It loaded just fine.
So very odd.
I downloaded a fresh copy from https://nightly.link/hoehermann/purple-presage/workflows/build/master/libpresage.dll.zip and fired up with gdb with the same backtrace. Running on Windows 11 22631.3958, with libpurple 2.14.13
Tried to compare it with other protocol plugins, but the only thing that jumped out was that dependency scanner is trying to look up libpurple functions by ordinal instead of name:
Since you mentioned that you've tested with the same version of libpurple, but different versions of Windows, I went through the system dll imports and saw that ws2_32 had a lot of ordinal's imported too
I don't know much about ordinals vs named imports, but could it potentially be that its trying to import a function that's moved to a different ordinal in a different version of the dll?
Today, I learned that ordinal imports exist. Thank you. :slightly_smiling_face: Curiously WS2_32.dll seems to be a popular example for ordinal imports (see this article). So I guess that is okay and just the way it is.
As for using ordinals when linking libpurple.dll, that is probably on me and the way I generate the .lib file here. I should look into this technique.
Unfortunately, I am still not able to reproduce the issue. I just tried the current nightly on Windows 11 23H2 Build 22631.2506 (I currently do not have anything more recent available). Works for me there, too. :slightly_frowning_face:
After trying to read about the problem some more, I've seen other stackoverflow posts talking about order of library loading in C++ code being a potential trigger (searching for "LoadLibrary error 998" seemed to bring up a few more results). With that in mind, I tried renaming the dll to aalibpresage.dll and it loads. I've then binary searched with file renames... so this works
(08:33:55) plugins: probing C:\Program Files (x86)\Pidgin\plugins\iconaway.dll
(08:33:55) plugins: probing C:\Program Files (x86)\Pidgin\plugins\iconaway_libpresage.dll
(08:33:56) plugins: probing C:\Program Files (x86)\Pidgin\plugins\icon_override.dll
but this does not
(08:36:12) plugins: probing C:\Program Files (x86)\Pidgin\plugins\iconaway.dll
(08:36:12) plugins: probing C:\Program Files (x86)\Pidgin\plugins\icon_override.dll
(08:36:12) plugins: probing C:\Program Files (x86)\Pidgin\plugins\icon_override_libpresage.dll
Program received signal SIGSEGV, Segmentation fault.
Disabling the icon_override.dll (from https://github.com/EionRobb/pidgin-icon-override/releases/download/0.1/icon_override.dll ) allows the library to load, but then crashes if renamed back to libpresage.dll again. Another binary search found that libnetnexus.dll also caused it to crash.
By this stage I was a bit nervous that adding new plugins in the future could suddenly break the loading of this plugin, so renamed it zzlibpresage.dll and went through the list of all dlls that caused it to crash if they were loaded before it:
I kinda gave up at this point as it was seeming like more libs than not were starting to conflict - my theory was that it was trying to load the dll into a memory address that was being used by another plugin? But that's a wild guess and I honestly have no idea.
So as a workaround, naming it aa_libpresage.dll gets it to load. Just makes me a bit nervous :)
Thank you for your wonderful research. The findings are interesting and horrific. 😱
I spent a couple of hours of installing Windows 11 in a virtual machine to have a pristine environment. Alas, I did not manage to replicate the behaviour described.
I did, however, notice some linker warnings. I updated the build instructions for more static linking so the Visual C++ Runtime dll is no longer needed. Unfortunately, this seems to work well only for Release configurations. Maybe this solves this issue, too: libpresage.dll.zip
I am glad you found a workaround. Do you have feed-back regarding the actual user experience?
When trying to load the plugin on Windows, there's some kind of memory corruption issue. Either the debug window will show
or when loading with gdb open, will just segfault:
Not quite sure how to debug this one, as I've never seen this error before