Openapoc: Crash when log size reaches >82MiB

I haven't been able to repro this - does it still happen?

A couple of weeks ago, I had a log file that was over 500MB.

Just a copy and paste from discord, i've not been able to replicate this again myself with the latest download

Will close, however, we can always reopen if needed

not on a device I can access git on ATM but with regards to the >82MB log issue

This still occurs on some devices... The lowest end I've had is 82MB

The highest is the 4GB FAT32 file size cap

It's hard to reproduce, but in effect, above 82MB sooner or later a Windows system will fail to write quickly to the large log file and OpenApoc will crash failing to write to the log

Is it necessary to keep the log expanding to the file system limit, or should we truncate it at 50MB?
Obviously on NTFS and exFAT the limit is higher so it takes longer to crash out unless a write is delayed

JonnyHYesterday at 09:14
I still can't repro this, I got my log over 500mb and didn't see any crash
Maybe it's not actually the log, but something else that happens to be around the same timing? Like a memory leak or something?
Do you get a backtrace from the crash? If using the appveyor build, you might need to extract the debug package to get symbols from the pdb files

Filmboy84Yesterday at 09:17
Could be, only had it occur rarely on a Win7 NTFS system

It happens more on an aging FAT32 WinXP install

I can try and get a backtrace

It's been a while since I looked at this (delete log file every play by habit now)

If the debug package is working again (it wasn't for a while if you recall) I'll have an explore

JonnyHYesterday at 09:19
Hmm, I no longer have anything with win7 or fat32 so might rely have issues repro-ing if they're related
But I'd be surprised if it was the log file size itself - we just use the standard apis that have been pretty battle tested over time

Filmboy84Yesterday at 09:49
It is certainly an odd one

I've never had issue on Win10 with NTFS

Will update the issue with all of this when next on a git friendly device

Also under the myriad of Linux file systems it seems ok (including ancient ones like HPFS)

So agreed it is likely not linked to file system in any way except reaching the file size limit, up till that point I hadn't thought of memory leak... Now you say it that sounds more likely