23.0rc4 crashes when trying to open the "Network Traffic" tab #582

<!-- This issue tracker is only for technical issues related to Bitcoin Core. General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com. For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/. If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

<!-- Describe the issue -->

Expected behavior

<!--- What behavior did you expect? -->

The app should not crash.

Actual behavior

<!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

The app immediately crashes when trying to open the "Network Traffic" tab. If I open the tab right after startup it doesn't crash right away and everything looks fine, but then it crashes some 30 seconds later. Other tabs work fine.

To reproduce

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

1. Start bitcoin-qt.
2. Go to Window > Network Traffic.

System information

23.0rc4 installed with bitcoin-23.0rc4-win64-setup.exe on Windows 10 over a previous installation of 22.0.0.

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

<!-- GUI-related issue? What is your operating system and its version? If Linux, what is your desktop environment and graphical shell? -->

<!-- Any extra information that might be useful in the debugging process. -->

<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

These are the last lines of the debug log:

2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 12
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 12
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 12
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 12
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 14
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 14
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 14
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 14
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 11
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 11
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 11
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 11
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 32
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 32
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 32
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 32
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 19
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 19
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 19
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 19
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 20
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 20
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 20
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 20
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 16
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 16
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 16
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 16
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS Shell Dlg 2", script 17
2022-04-11T21:48:45Z GUI:   OpenType support missing for "Arial", script 17
2022-04-11T21:48:45Z GUI:   OpenType support missing for "MS UI Gothic", script 17
2022-04-11T21:48:45Z GUI:   OpenType support missing for "SimSun", script 17

@vostrnad Thank you for testing Bitcoin Core v23.0rc4.

Can confirm the bug on Windows 11 Pro 21H2.

FWIW, no crashes with a MSVC build.

Also tested bitcoin-qt.exe cross-compiled with GCC 11.2.0 on Ubuntu 22.04 -- no crashes.

It would be very useful to have a traceback, or at least a crash address (without ASLR, or including a memory map), we were able to narrow down the previous windows crash issue quite quickly using that information and addr2line.

Reproduced in wine:

Unhandled exception: 0xc0000029 in 64-bit code (0x000000007bc28318).
Register dump:
 rip:000000007bc28318 rsp:00000000003179d0 rbp:0000000000317c20 eflags:00000202 (   - --  I   - - - )
 rax:000000000000004d rbx:00000000003179f0 rcx:00000000003179f0 rdx:0000000000318670
 rsi:000000000031ad00 rdi:000000000031ad00  r8:0000000000000000  r9:00000000003176b4 r10:00000000003176b3
 r11:0000000000000293 r12:0000000000318670 r13:0000000000317b30 r14:000000000031fea0 r15:000000000031fea0
Stack dump:
0x00000000003179d0:  00000000003179f0 000000007bc28981
0x00000000003179e0:  0000000000730bf0 0000000000317b30
0x00000000003179f0:  00000001c0000029 0000000000318670
0x0000000000317a00:  000000007bc28318 0000000000000000
0x0000000000317a10:  0000000000317b30 000000000031fea0
0x0000000000317a20:  000000000031fea0 000000007bc53e36
0x0000000000317a30:  0000000000000002 0000000140000000
0x0000000000317a40:  0000000140060220 4071000000000000
0x0000000000317a50:  0000000000317c20 0000000000317b68
0x0000000000317a60:  0000000000317b48 0000000000000000
0x0000000000317a70:  4071000000000000 0000000000011830
0x0000000000317a80:  000000007bc63910 0000000000318670
Backtrace:
=>0 0x000000007bc28318 EntryPoint+0xffffffffffffffff() in ntdll (0x0000000000317c20)
  1 0x000000007bc5530f EntryPoint+0xffffffffffffffff() in ntdll (0x0000000000317c20)
  2 0x000000007bc5536f EntryPoint+0xffffffffffffffff() in ntdll (0x0000000000000000)
  3 0x00000001c8dc746a EntryPoint+0xfffb3569() in msvcrt (0x0000000000000000)
  4 0x000000014161fbee EntryPoint+0x10161e72d() in bitcoin-qt (0x0000000000000000)
  5 0x0000000141620672 EntryPoint+0x10161f1b1() in bitcoin-qt (0x0000000000000000)
  6 0x000000014161f438 EntryPoint+0x10161df77() in bitcoin-qt (0x0000000000318870)
  7 0x000000014161f045 EntryPoint+0x10161db84() in bitcoin-qt (0xaaaaaaaaaaaaaaab)
  8 0x0000000140fbe001 EntryPoint+0x100fbcb40() in bitcoin-qt (0x0000000141f898a0)
  9 0x0000000140e2de61 EntryPoint+0x100e2c9a0() in bitcoin-qt (0x0000000000000002)
  10 0x0000000140060220 EntryPoint+0x10005ed5f() in bitcoin-qt (0x0000000000000002)
  11 0x00000001411339c0 EntryPoint+0x1011324ff() in bitcoin-qt (0x000000000031b350)
  12 0x0000000140e6e0d1 EntryPoint+0x100e6cc10() in bitcoin-qt (0x000000000031b350)
  13 0x0000000140d48b80 EntryPoint+0x100d476bf() in bitcoin-qt (0x000000000031b350)
  14 0x0000000140cc63fb EntryPoint+0x100cc4f3a() in bitcoin-qt (0x000000000031b350)
  15 0x0000000140cceb3b EntryPoint+0x100ccd67a() in bitcoin-qt (0x0000000000000016)
  16 0x0000000140cc61f8 EntryPoint+0x100cc4d37() in bitcoin-qt (0x000000000031b620)
  17 0x0000000140cceb3b EntryPoint+0x100ccd67a() in bitcoin-qt (0x000000000000000d)
  18 0x0000000140cc61f8 EntryPoint+0x100cc4d37() in bitcoin-qt (0x000000000031b8f0)
  19 0x0000000140cceb3b EntryPoint+0x100ccd67a() in bitcoin-qt (0x000000000000000d)
  20 0x0000000140cc61f8 EntryPoint+0x100cc4d37() in bitcoin-qt (0x000000000031bbc0)
  21 0x0000000140cceb3b EntryPoint+0x100ccd67a() in bitcoin-qt (0x000000000000000b)
  22 0x0000000140cc61f8 EntryPoint+0x100cc4d37() in bitcoin-qt (0x000000000031be70)
  23 0x0000000140f2d47d EntryPoint+0x100f2bfbc() in bitcoin-qt (0x000000000031be60)
  24 0x000000014113420a EntryPoint+0x101132d49() in bitcoin-qt (0x00000000006ef234)
  25 0x0000000140e6e0d1 EntryPoint+0x100e6cc10() in bitcoin-qt (0x00000000006ef234)
  26 0x0000000140d4600a EntryPoint+0x100d44b49() in bitcoin-qt (0x00000000006ef234)
  27 0x0000000140f75559 EntryPoint+0x100f74098() in bitcoin-qt (0x00000000006ef234)
  28 0x0000000140fe00dd EntryPoint+0x100fdec1c() in bitcoin-qt (0x00000000006ef750)
  29 0x0000000140ef9f8f EntryPoint+0x100ef8ace() in bitcoin-qt (0x00000000006ef750)
  30 0x0000000140fe00c4 EntryPoint+0x100fdec03() in bitcoin-qt (0x0000000000000024)
  31 0x0000000140b225a3 EntryPoint+0x100b210e2() in bitcoin-qt (0x0000000000000024)
  32 0x0000000140d491e7 EntryPoint+0x100d47d26() in bitcoin-qt (0x000000000031f820)
  33 0x0000000140009e49 EntryPoint+0x100008988() in bitcoin-qt (0x000000000031f820)
  34 0x00000001400013c1 EntryPoint+0xffffff00() in bitcoin-qt (0x0000000000000002)
  35 0x00000001400014d6 EntryPoint+0x100000015() in bitcoin-qt (0x0000000000000000)
  36 0x000000007b62c6c9 EntryPoint+0xffffffffffffffff() in kernel32 (0x0000000000000000)
  37 0x000000007bc583c3 EntryPoint+0xffffffffffffffff() in ntdll (0x0000000000000000)
0x000000007bc28318 EntryPoint+0xffffffffffffffff in ntdll: jmp	0x000000007bc28310 EntryPoint+0xffffffffffffffff
Modules:
Module	Address					Debug info	Name (40 modules)
PE	        7a850000-        7a854000	Deferred        opengl32
PE	        7b000000-        7b3fd000	Deferred        kernelbase
PE	        7b600000-        7b969000	Dwarf           kernel32
PE	        7bc00000-        7bf3c000	Dwarf           ntdll
PE	       140000000-       142206000	Export          bitcoin-qt
PE	       1c8b40000-       1c8bb7000	Deferred        msacm32
PE	       1c8db0000-       1c9097000	Dwarf           msvcrt
PE	       21a7e0000-       21a9ce000	Deferred        setupapi
PE	       231ae0000-       231d60000	Deferred        rpcrt4
PE	       23d820000-       23dfc2000	Deferred        user32
PE	       25d740000-       25d75f000	Deferred        dwmapi
PE	       26b4c0000-       26bbb9000	Deferred        gdi32
PE	       2739c0000-       273ec9000	Deferred        oleaut32
PE	       2967b0000-       296949000	Deferred        d3d9
PE	       2a4090000-       2a40bf000	Deferred        wtsapi32
PE	       2b8510000-       2b854e000	Deferred        wintab32
PE	       2bb750000-       2bbcd8000	Deferred        comctl32
PE	       2e3540000-       2e364f000	Deferred        shlwapi
PE	       2e8f10000-       2e948f000	Deferred        ole32
PE	       2f1fa0000-       2f1fbe000	Deferred        version
PE	       2f61f0000-       2f625d000	Deferred        explorerframe
PE	       2f7230000-       2f72d4000	Deferred        uxtheme
PE	       3126f0000-       312744000	Deferred        shcore
PE	       31f800000-       31fa8e000	Deferred        comdlg32
PE	       327020000-       3271a4000	Deferred        combase
PE	       32a700000-       32a7bc000	Deferred        sechost
PE	       330260000-       330387000	Deferred        advapi32
PE	       388e20000-       388e4b000	Deferred        userenv
PE	       3af670000-       3af9dd000	Deferred        ucrtbase
PE	       3afd00000-       3afd62000	Deferred        imm32
PE	       3b8f00000-       3b909f000	Deferred        winmm
PE	    7fc088060000-    7fc08806b000	Deferred        winspool
PE	    7fc0aa1f0000-    7fc0aa1f4000	Deferred        wined3d
PE	    7fc0aa4c0000-    7fc0aa4c3000	Deferred        dwrite
PE	    7fc0aa820000-    7fc0aa824000	Deferred        winex11
PE	    7fc0ab800000-    7fc0ac0d2000	Deferred        shell32
PE	    7fc0ac210000-    7fc0ac214000	Deferred        dnsapi
PE	    7fc0ac230000-    7fc0ac236000	Deferred        ws2_32
PE	    7fc0ac270000-    7fc0ac273000	Deferred        netapi32
PE	    7fc0ac3b0000-    7fc0ac3b4000	Deferred        iphlpapi
Threads:
process  tid      prio (all id:s are in hex)
00000038 services.exe
	0000003c    0
	00000040    0
	0000004c    0
	00000070    0
	0000008c    0
	000000bc    0
	000000d0    0
00000044 winedevice.exe
	00000048    0
	00000054    0
	00000058    0
	0000005c    0
00000060 explorer.exe
	00000064    0
	00000088    0
	00000098    0
00000068 plugplay.exe
	0000006c    0
	00000074    0
	00000078    0
	0000007c    0
	000000a0    0
00000080 winedevice.exe
	00000084    0
	00000090    0
	00000094    0
	0000009c    0
	000000ac    0
000000b4 svchost.exe
	000000b8    0
	000000c0    0
	000000c4    0
000000c8 rpcss.exe
	000000cc    0
	000000d4    0
	000000d8    0
	000000dc    0
	000000e0    0
	000000e4    0
000000ec (D) Z:\home\hebasto\Downloads\bitcoin-23.0rc4-win64\bitcoin-23.0rc4\bin\bitcoin-qt.exe
	000000f0    0 <==
	0000011c    0
	00000140    0
	00000144    0
	00000148    0
	0000014c    0
	00000150    0
	00000154    0
	00000158    0
	0000015c    0
	00000160    0
	00000164    0
	0000016c    0
	00000170    0
	00000178    0
	0000017c    0
	00000180    0
	00000184    0
	00000188    0
	0000018c    0
000000f4 conhost.exe
	000000f8    0
System information:
    Wine build: wine-6.0.3 (Ubuntu 6.0.3~repack-1)
    Platform: x86_64
    Version: Windows 7
    Host system: Linux
    Host version: 5.15.0-25-generic

The last call in backtrace from bitcoin-qt:

$ addr2line -e bin/bitcoin-qt.exe.dbg --no-recurse-limit -aipfC 0x000000014161fbee
0x000000014161fbee: ?? at nanosleep.c:?

The last call in our code:

$ addr2line -e bin/bitcoin-qt.exe.dbg --no-recurse-limit -aipfC 0x0000000140060220
0x0000000140060220: TrafficGraphWidget::paintEvent(QPaintEvent*) at /distsrc-base/distsrc-23.0rc4-x86_64-w64-mingw32/src/qt/trafficgraphwidget.cpp:109

The last call in our code:

$ addr2line -e bin/bitcoin-qt.exe.dbg --no-recurse-limit -aipfC 0x0000000140060220
0x0000000140060220: TrafficGraphWidget::paintEvent(QPaintEvent*) at /distsrc-base/distsrc-23.0rc4-x86_64-w64-mingw32/src/qt/trafficgraphwidget.cpp:109

Hmm, just commenting out line 109 prevents crashing.

It would be interesting to see what is in the QPainterPath object passed. Unless Qt provides a way to dump its contents, I would guess the easiest way to find out is to add logging to TrafficGraphWidget::paintPath.

Best case we can find some minimal path that reproduces this issue and report it and/or find something obviously wrong on our side. Worst case it's a valid path we can maybe work around the issue somehow.

It would be interesting to see what is in the QPainterPath object passed. Unless Qt provides a way to dump its contents, I would guess the easiest way to find out is to add logging to TrafficGraphWidget::paintPath.

Done. Nothing specific found. With added qDebug() << vSamplesIn; and qDebug() << p; I got for three crashes:

2022-04-12T15:20:11Z GUI: (132.148, 111.234, 30.4196, 82.7631, 19.2302, 80.828, 30.6516, 13.1187, 65.236, 52.9836, 66.6244, 10.2147, 89.9018, 133.566, 20.4244)
2022-04-12T15:20:11Z GUI: QPainterPath: Element count=17
 -> MoveTo(x=545, y=330)
 -> LineTo(x=545, y=14)
 -> LineTo(x=545, y=64)
 -> LineTo(x=544, y=258)
 -> LineTo(x=543, y=132)
 -> LineTo(x=543, y=284)
 -> LineTo(x=542, y=137)
 -> LineTo(x=541, y=257)
 -> LineTo(x=541, y=299)
 -> LineTo(x=540, y=174)
 -> LineTo(x=539, y=204)
 -> LineTo(x=539, y=171)
 -> LineTo(x=538, y=306)
 -> LineTo(x=537, y=115)
 -> LineTo(x=537, y=10)
 -> LineTo(x=536, y=282)
 -> LineTo(x=536, y=330)

2022-04-12T15:24:52Z GUI: (90.6102, 51.9431, 83.3138, 19.7356, 76.9702, 24.3093, 15.636, 87.8804, 35.7747, 63.188, 41.2676, 133.879, 60.3027, 22.8809, 0, 0, 0)
2022-04-12T15:24:52Z GUI: QPainterPath: Element count=17
 -> MoveTo(x=545, y=330)
 -> LineTo(x=545, y=114)
 -> LineTo(x=545, y=206)
 -> LineTo(x=544, y=131)
 -> LineTo(x=543, y=283)
 -> LineTo(x=543, y=147)
 -> LineTo(x=542, y=272)
 -> LineTo(x=541, y=293)
 -> LineTo(x=541, y=120)
 -> LineTo(x=540, y=245)
 -> LineTo(x=539, y=179)
 -> LineTo(x=539, y=232)
 -> LineTo(x=538, y=10)
 -> LineTo(x=537, y=186)
 -> LineTo(x=537, y=276)
 -> LineTo(x=536, y=330)
 -> LineTo(x=535, y=330)

2022-04-12T15:29:35Z GUI: (28.3138, 16.3582, 168.981, 288.036, 65.1329, 119.463, 111.596, 47.3556, 68.9, 45.1036, 70.3858, 11.8667, 16.5391, 83.7804, 40.216, 72.2844, 73.6307, 96.524, 7)
2022-04-12T15:29:35Z GUI: QPainterPath: Element count=21
 -> MoveTo(x=545, y=330)
 -> LineTo(x=545, y=299)
 -> LineTo(x=545, y=312)
 -> LineTo(x=544, y=143)
 -> LineTo(x=543, y=10)
 -> LineTo(x=543, y=258)
 -> LineTo(x=542, y=198)
 -> LineTo(x=541, y=207)
 -> LineTo(x=541, y=278)
 -> LineTo(x=540, y=254)
 -> LineTo(x=539, y=280)
 -> LineTo(x=539, y=252)
 -> LineTo(x=538, y=317)
 -> LineTo(x=537, y=312)
 -> LineTo(x=537, y=237)
 -> LineTo(x=536, y=286)
 -> LineTo(x=535, y=250)
 -> LineTo(x=535, y=249)
 -> LineTo(x=534, y=223)
 -> LineTo(x=533, y=250)
 -> LineTo(x=533, y=330)

FWIW, this patch:

--- a/src/qt/trafficgraphwidget.cpp
+++ b/src/qt/trafficgraphwidget.cpp
@@ -103,18 +103,18 @@ void TrafficGraphWidget::paintEvent(QPaintEvent *)
     }
 
     painter.setRenderHint(QPainter::Antialiasing);
-    if(!vSamplesIn.empty()) {
+    if (!vSamplesIn.empty()) {
         QPainterPath p;
         paintPath(p, vSamplesIn);
-        painter.fillPath(p, QColor(0, 255, 0, 128));
         painter.setPen(Qt::green);
+        painter.setBrush(QColor(0, 255, 0, 128));
         painter.drawPath(p);
     }
-    if(!vSamplesOut.empty()) {
+    if (!vSamplesOut.empty()) {
         QPainterPath p;
         paintPath(p, vSamplesOut);
-        painter.fillPath(p, QColor(255, 0, 0, 128));
         painter.setPen(Qt::red);
+        painter.setBrush(QColor(255, 0, 0, 128));
         painter.drawPath(p);
     }
 }

does not help.

A workaround suggested in bitcoin/bitcoin#24838.

Does it maybe have to do with the transparency? What if you use a solid color?

Does it maybe have to do with the transparency? What if you use a solid color?

Verified. Solid colors do not help, unfortunately.

Thanks for checking. That would have been an easy workaround at least. Thinking of it, we could always go with not filling the graph at all on 23.0rc5. A line should be enough?

Something that becomes apparent here is that we don't generate Qt symbols in our debug information. All the Qt addresses end up in nanosleep which makes no sense. That's probably the last library function that does get symbols.

0x000000007bc28318 ?? ??:0 (unknown symbol in ntdll)
0x000000007bc5530f ?? ??:0 (unknown symbol in ntdll)
0x000000007bc5536f ?? ??:0 (unknown symbol in ntdll)
0x00000001c8dc746a: ?? ??:0 (unknown symbol in msvcrt, looks like longjmp)
0x000000014161fbee: ?? at gray_record_cell.part.0
0x0000000141620672: ?? at gray_render_line
0x000000014161f438: ?? at gray_convert_glyph_inner
0x000000014161f045: ?? at gray_convert_glyph
0x0000000140fbe001: ?? at QRasterPaintEnginePrivate::rasterize(QT_FT_Outline_*, void (*)(int, QT_FT_Span_ const*, void*), void*, QRasterBuffer*)
0x0000000140e2de61: ?? at QRasterPaintEngine::fill(QVectorPath const&, QBrush const&)
0x0000000140060220: TrafficGraphWidget::paintEvent(QPaintEvent*) at /distsrc-base/distsrc-23.0rc4-x86_64-w64-mingw32/src/qt/trafficgraphwidget.cpp:109

Let's look into getting qt symbols (well, line numbers) into our .dbg.

Edit: Seems that objdump can see the Qt function names, but not line numbers. I've filled them in.

• gray_record_cell is inside freetype. Did we change version on that? (irrelevant, see below) From the assembly it looks like the crash happens while trying to unwind the stack with __imp_longjmp.
  • Also no clue why the stack unwind fails. This may actually be a GCC bug.
  • Going deeper: it seems Qt is not using our freetype at all, but its internal one in src/3rdparty/freetype. I noticed this because in Ft 2.11, the function gray_record_cell has been refactored away :smile:
• I do not possibly understand why this line ends up in freetype. It's rendering a path, not text ! Edit: might be anti-aliasing related. Edit.2: or is it using freetype for all path rendering on Windows?

Edit: might want to try disabling anti-aliasing at the top of TrafficGraphWidget::paintEvent:

painter.setRenderHint(QPainter::Antialiasing, false);
painter.setRenderHint(QPainter::TextAntialiasing, false);
painter.setRenderHint(QPainter::SmoothPixmapTransform, false);

This could be: https://bugreports.qt.io/browse/QTBUG-93476.

This could be: https://bugreports.qt.io/browse/QTBUG-93476.

Yes. The traceback at least looks eerily familiar. This would mean the root cause, and the reason this didn't happen on 22.x, is the compiler version bump?

Edit: it's some really ugly code in freetype where it longjmps when a certain buffer has reached its size and needs to be reallocated. Iff this code is gone in newer freetype maybe we can avoid the issue by making sure it uses the newer freetype.

Edit.2: no, the longjmp is not gone in Ft 2.11. It's just moved upward in the call tree.

This could be: https://bugreports.qt.io/browse/QTBUG-93476.

Could we use a patch from https://bugreports.qt.io/browse/QTBUG-94692?

Edit: it's some really ugly code in freetype where it longjmps when a certain buffer has reached its size and needs to be reallocated.

This explains that some time is required to crash.