zlib symbol confusion with newest freetype

[arch1t3cht]

I'm building Aegisub on Windows using the developer tools of Microsoft Visual Studio 2019 (2022 would fail when compiling because of some error with stdatomic.h) and the otherwise latest versions of Python, CMake, and Meson.

Aegisub compiles, but crashes with the following stack trace whenever I open a video file:

--- 22-02-25 14:37:33 ------------------
VER - 9266-master-f21d8a360
FTL - Beginning stack dump for "Fatal exception": 
000 - 00007FF7905F155B: ft_mem_alloc on D:\Coding\Aegisub\subprojects\freetype2\src\base\ftutil.c:54
001 - 00007FF7905E5E12: zcalloc on D:\Coding\Aegisub\subprojects\freetype2\src\gzip\ftgzip.c:169
002 - 00007FF791D16CEE: deflateInit2_ on D:\Coding\Aegisub\subprojects\zlib-1.2.11\deflate.c:304
003 - 00007FF791D16E9D: deflateInit_ on D:\Coding\Aegisub\subprojects\zlib-1.2.11\deflate.c:237
004 - 00007FF7910DA6D2: ZipFile::Write on D:\Coding\Aegisub\subprojects\ffms2-2.40\src\core\zipfile.cpp:107
005 - 00007FF7910D3EF5: FFMS_Index::WriteIndex on D:\Coding\Aegisub\subprojects\ffms2-2.40\src\core\indexing.cpp:110
006 - 00007FF7910D413D: FFMS_Index::WriteIndexFile on D:\Coding\Aegisub\subprojects\ffms2-2.40\src\core\indexing.cpp:130
007 - 00007FF7910C5F69: FFMS_WriteIndex on D:\Coding\Aegisub\subprojects\ffms2-2.40\src\core\ffms.cpp:397
008 - 00007FF7905B0577: FFmpegSourceProvider::DoIndexing on D:\Coding\Aegisub\src\ffmpegsource_common.cpp:97
009 - 00007FF7905AD138: `anonymous namespace'::FFmpegSourceVideoProvider::LoadVideo on D:\Coding\Aegisub\src\video_provider_ffmpegsource.cpp:207
010 - 00007FF7905ABF08: `anonymous namespace'::FFmpegSourceVideoProvider::FFmpegSourceVideoProvider on D:\Coding\Aegisub\src\video_provider_ffmpegsource.cpp:156
011 - 00007FF7905AC33A: CreateFFmpegSourceVideoProvider on D:\Coding\Aegisub\src\video_provider_ffmpegsource.cpp:377
012 - 00007FF79057B7B6: VideoProviderFactory::GetProvider on D:\Coding\Aegisub\src\video_provider_manager.cpp:70
013 - 00007FF79020EB44: AsyncVideoProvider::AsyncVideoProvider on D:\Coding\Aegisub\src\async_video_provider.cpp:97
014 - 00007FF7904B62A4: Project::DoLoadVideo on D:\Coding\Aegisub\src\project.cpp:292
015 - 00007FF7904B9809: Project::LoadVideo on D:\Coding\Aegisub\src\project.cpp:332
016 - 00007FF79034A696: `anonymous namespace'::video_open::operator() on D:\Coding\Aegisub\src\command\video.cpp:571
017 - 00007FF7902DBBFD: cmd::call on D:\Coding\Aegisub\src\command\command.cpp:51
018 - 00007FF790AA5982: wxAppConsoleBase::CallEventHandler on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\appbase.cpp:672
019 - 00007FF790AC8A04: wxEvtHandler::ProcessEventIfMatchesId on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\event.cpp:1426
020 - 00007FF790AC95E2: wxEvtHandler::SearchDynamicEventTable on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\event.cpp:1897
021 - 00007FF790AC9A04: wxEvtHandler::TryHereOnly on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\event.cpp:1618
022 - 00007FF790AC8908: wxEvtHandler::ProcessEvent on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\event.cpp:1528
023 - 00007FF790AF522E: wxWindowBase::TryAfter on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\wincmn.cpp:3493
024 - 00007FF790AC895C: wxEvtHandler::ProcessEvent on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\event.cpp:1541
025 - 00007FF790AC953A: wxEvtHandler::SafelyProcessEvent on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\event.cpp:1646
026 - 00007FF790B85246: wxMenuBase::SendEvent on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\menucmn.cpp:646
027 - 00007FF790C92DFB: wxFrame::HandleCommand on D:\Coding\Aegisub\subprojects\wxWidgets\src\msw\frame.cpp:817
028 - 00007FF790C93950: wxFrame::MSWWindowProc on D:\Coding\Aegisub\subprojects\wxWidgets\src\msw\frame.cpp:874
029 - 00007FF790B11E6C: wxWndProc on D:\Coding\Aegisub\subprojects\wxWidgets\src\msw\window.cpp:2926
030 - 00007FF909FCE7E8: CallWindowProcW
031 - 00007FF909FCE229: DispatchMessageW
032 - 00007FF790D5C3DC: wxGUIEventLoop::Dispatch on D:\Coding\Aegisub\subprojects\wxWidgets\src\msw\evtloop.cpp:230
033 - 00007FF790D266C3: wxEventLoopManual::DoRun on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\evtloopcmn.cpp:291
034 - 00007FF790D269AA: wxEventLoopBase::Run on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\evtloopcmn.cpp:90
035 - 00007FF790AA713D: wxAppConsoleBase::MainLoop on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\appbase.cpp:380
036 - 00007FF790471657: AegisubApp::OnRun on D:\Coding\Aegisub\src\main.cpp:461
037 - 00007FF790E34CAE: wxEntryReal on D:\Coding\Aegisub\subprojects\wxWidgets\src\common\init.cpp:507
038 - 00007FF790CC0168: wxEntry on D:\Coding\Aegisub\subprojects\wxWidgets\src\msw\main.cpp:184
039 - 00007FF791CFE41A: __scrt_common_main_seh on d:\a01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
040 - 00007FF909437034: BaseThreadInitThunk
041 - 00007FF90B042651: RtlUserThreadStart
End of stack dump.
----------------------------------------

My guess for what's happening here is the following: Aegisub, as well as several of its dependencies depend on zlib, which is provided as a meson subproject. However, the dependency libass depends on freetype, which ships its own (patched) version of zlib. In January, this shipped zlib was updated to the current version 1.2.11. The stack trace shows that a zcalloc call inside the zlib subproject (which was originally invoked by ffms2) suddenly calls the equivalent function in freetype's internal zlib, [either that or the stack trace is incorrect, which is equally problematic.] which I'm guessing is causing the memory error. Probably this happens because the linker confuses the symbols of both zlib implementations.

Changing the libass dependency to one which uses an older version of freetype (the meson-pr branch of this fork, which uses this freetype wrapper provided by meson here) fixes this crash, presumably because this older version of freetype ships and older version of zlib.

This is certainly not the best fix, but I don't know enough about meson to find a better one. In any case, this should prove that the version of freetype is what causes this issue.

[eli-schwartz]

The interesting thing is that freetype is supposed to check for an existing external copy of zlib, and if found, link to that.

This should pick up the zlib wrap if the feature is required or if zlib has already been found by Meson (e.g. in another subproject).

[arch1t3cht]

Maybe I can attach the meson log for more info on what subprojects are being obtained from which source: meson_output.txt (this is the log for the build that suffers from these crashes)

[eli-schwartz]

freetype2| Run-time dependency zlib found: NO (tried pkgconfig, cmake and system)
freetype2| Downloading zlib source from http://zlib.net/fossils/zlib-1.2.11.tar.gz
Download size: 607698
Downloading: ..........
freetype2| Downloading zlib patch from https://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.11/5/get_zip
Download size: 1898
Downloading: ..........

Executing subproject libass:freetype2:zlib

[arch1t3cht]

It's been a while, but I found out that moving the zlib dependency https://github.com/TypesettingTools/Aegisub/blob/f21d8a36073acecad56b2621219ba82fedc04e37/meson.build#L112 above the libass dependency in meson.build fixes the crash for me, since it makes freetype pick up the existing zlib instead of shipping its own.

Certainly not an ideal solution, but still a better fix than downgrading freetype.

[CoffeeFlux]

That's bizarre... appreciate you following up.

[arch1t3cht]

After noticing that the installer built by the CI also doesn't show this crash for me, I found out that passing --force-fallback-for=zlib to meson also fixes this for me, without needing to modify meson.build.

[arch1t3cht]

I can't reproduce this any more with the newest freetype, so I'm guessing it's fixed. Either way, passing --force-fallback-for=zlib (which is enabled on the CI builds) should fix this even if something does break again.