[BUG] Rendering specific text crashes Companion

[semenovnick]

Is this a bug in companion itself or a module?

• I believe this to be a bug in companion

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When i insert large text (like responce of HTTP Get Request from generic http module) or just in custom variable editor. If i use this variable in in text for knob. Or some variable (for example vmix title text) have large text in it. Or I just insert large text in button text field, companion crashes with stack trace:

PID 44796 received ACCESS_VIOLATION for address: 0x7ffead3ecf50
[node-napi-v9.node]: segfault::init
[node-napi-v9.node]: segfault::showCallstack
[node-napi-v9.node]: segfault::handleSignal
[KERNELBASE.dll]: UnhandledExceptionFilter
[ntdll.dll]: memset
[ntdll.dll]: _C_specific_handler
[ntdll.dll]: _chkstk
[ntdll.dll]: RtlRaiseException
[ntdll.dll]: KiUserExceptionDispatcher
[skia.win32-x64-msvc.node]: napi_register_module_v1
[skia.win32-x64-msvc.node]: napi_register_module_v1
[skia.win32-x64-msvc.node]: napi_register_module_v1
[skia.win32-x64-msvc.node]: napi_register_module_v1
[skia.win32-x64-msvc.node]
[node.exe]: v8::base::CPU::has_popcnt

Seems like error in canvas submodule...

Steps To Reproduce

paste large text in Button text field

Expected Behavior

Companion not crushes

Environment (please complete the following information)

- OS: Win 10
- Browser: Any
- Companion Version: from 4.3.3 up to 3.5.2

Additional context

No response

[thedist]

I wonder if this may be the cause of the issue in #3282

[dnmeid]

I have just tried to reproduce this problem but I could not generate a crash. I tried rendering text from a custom variable that I doubled repeatedly. I stopped at 100 something million characters, because it started getting slow but no crash.
I tried fixed font size of 7pt and Auto.
Only difference is, I have Windows 11.

What do you mean with "large"? GB?

[semenovnick]

I checked today. You right, It happens not every time. But if you add generic http get module. Add JSON Response Data Variable to custom variable. Add this variable as text for any button and as test send request to:
https://www.lipsum.com/feed/html?amount=5&&what=words which responds Lorem Ipsum html. Crash happens in 10/10 attempts.
Also if variable is not on the button text, module saves responce silently, crash happens when after adding this variabe to button text (it shows that it problem in companion not in http module).
Maybe it is because of hidden symbols or somethig\r\n. Because if after storing in variable after http get I make cut and paste back in that variable and then add this variable to button everything OK
Video showing that:

2025-02-14.15-20-11.mp4

[dnmeid]

OK, so far I can say that there are no fancy characters in the response that coud cause the crash.
I can reproduce it with sizes over 1050 characters but it seems that it needs something to be special within that text to crash.

[semenovnick]

Just tried on fresh companion install on win 11... Same crash when storing html in a variable.

[Julusian]

I'm also noticing how slow it is to draw buttons with this much text on them, cpu looks to be maxing out a core for multiple seconds, which looks to be our algorithm for splitting the text into lines. I'm going to see what I can do on this

One potential solution I am wondering about is adding some arbitrary limits to how much text we try to draw.
something like limiting it to 1000 characters overall, and 100 per line. That will allow us to take various shortcuts and make drawing quicker.

That doesnt necessarily address the underlying issue though, just making it less likely to occur

[dnmeid]

One potential solution I am wondering about is adding some arbitrary limits to how much text we try to draw.

I thought, I'd already done that when speeding up the linebreaking algorithm for the Auto size. Maybe it got lost.

[Julusian]

I thought, I'd already done that when speeding up the linebreaking algorithm for the Auto size. Maybe it got lost.

It was not drawing any lines that wouldn't be visible, but it is still chunking up the text that will never be visible.
I have a fix for this ready.

I'm also seeing each call to findLastChar take 2ms+, presumably as it tries to draw 10000 chars on one line, and then tries again with various shorter lengths.
I was going to do the limiting to 100 chars, but found some cases where we aren't handling multi-codepoint unicode currently..

[Julusian]

@dnmeid feel free to look over my changes 7ed5448

I am wondering about refactoring this logic into its own class and writing some unit tests for it. probably not checking the visual output, just the chunking and numbers