UI: Address logging buffer size discrepancies

[jcm93]

Description

Changes the remaining log buffer allocations in the log handler to use a buffer of size 8192 instead of 4096. Also adds improved string handling in the form of using strncpy rather than strcpy in the too_many_repeated_entries() check.

Motivation and Context

OBS was crashing on startup when logging messages over 4096 characters in length with corruption of the QPointer object for the log viewer. It turns out that this was due to a buffer overrun in the log handling code.

43a1b30 changed the size of the log buffer in obs-app.cpp's do_log, but to change the size of the buffer properly we need to also modify the buffer size in the subsequent check for repeated entries, as well as the base log handler in libobs. Otherwise the repeated entries check will bulldoze over memory adjacent to cmp_str if fed a message exceeding 4096 characters in length, as well as other memory in the base log handler.

How Has This Been Tested?

Verified that OBS no longer crashes when failing to load VLC on startup, and logging continues to work correctly.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[RytoEX]

cc @palana who authored 43a1b30 in #10633.

[palana]

looks good to me 👍 the only suggestion I'd have beyond this is to move the buffer size into a constant somewhere to avoid this situation in the future (although another change in buffer size seems unlikely)

[derrod]

I've been chasing too many random crashes that seem to be all caused by this so I'm just gonna merge this to preserve what remains of my sanity while working based on current master.

[RytoEX]

looks good to me 👍 the only suggestion I'd have beyond this is to move the buffer size into a constant somewhere to avoid this situation in the future (although another change in buffer size seems unlikely)

Agree with this as a welcome future change.