[Win32] crash on close

[gvanem]

I've built the latest tip-of-master FreeDV-GUI using clang-cl on Win-10. But some times I get a crash on program exit; Dr. Watson kicks in with this call-stack (Release-mode):

ucrtbase!invoke_watson+0x18
ucrtbase!_invalid_parameter+0x12d
ucrtbase!invalid_parameter_noinfo+0x9
ucrtbase!_write+0x3bb02
ucrtbase!_acrt_stdio_flush_nolock+0x47
ucrtbase!<lambda_36eeb330e99a4f0bf8a7da86d0894cb9>::operator()+0x123
ucrtbase!__crt_seh_guarded_call<int>::operator()<<lambda_fe5404e9642edbb7c8ae71e1dcfa4018>,<lambda_36eeb330e99a4f0bf8a7da86d0894cb9> &,<lambda_2fa474834de80dc12f7a3c6eddd7a366> >+0x2b
ucrtbase!__stdio_common_vfprintf+0x74
FreeDV_GUI!_vfprintf_l(struct _iobuf * _Stream = 0x00007fff`5055f540, char * _Format = 0x00007ff7`7559449c "txRxThread: timeout while waiting for CV, tx = %d.", struct __crt_locale_pointers * _Locale = <Value unavailable error>, char * _ArgList = 0x0000009b`346ffaf0 "???")+0x1c
FreeDV_GUI!fprintf(struct _iobuf * _Stream = 0x00007fff`5055f540, char * _Format = 0x00007ff7`7559449c "txRxThread: timeout while waiting for CV, tx = %d.")+0x4c
FreeDV_GUI!TxRxThread::Entry(void)+0x10c
FreeDV_GUI!wxThreadInternal::DoThreadStart(class wxThread * thread = 0x000001d3`b3512320)+0xb06
FreeDV_GUI!wxThreadInternal::WinThreadStart(void * param = 0x000001d3`b3512320)+0x5e
...

The console-trace at time until the crash:

AllocConsole: 0 m_debug_console: 1
Start .....
Setting callsign to xxxx
freedv_get_n_speech_samples(tx): 640
freedv_get_speech_sample_rate(tx): 8000
startRxStream .....
fifoSize_ms:  440 infifo2: 19404/outfilo2: 19404
fifoSize_ms: 440 infifo1: 19404/outfilo1 19404
rxInFifoSizeSamples: 1805 rxOutFifoSizeSamples: 3200
starting tx/rx processing thread
[2023-09-04 10:17:22] [connect] Successful connection
[2023-09-04 10:17:22] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1693815441101

The issue seems to be that ~MainFrame() has:

    #ifdef __WXMSW__
    fclose(g_logfile);
    #endif

while the TxRx thread (at a bit later time) still needs to use stderr. A fix for me was to write it like:

    if (g_logfile && g_logfile != stderr)
    {
        fclose(g_logfile);
        g_logfile = nullptr;
    }

[tmiw]

g_logfile isn't actually being used anywhere other than that fclose() call, so I opened #526 to remove it. Thanks for letting us know!

[gvanem]

I'm amazed this has not been an issue before. But I guess since you prefer MinGW with msvcrt.dll this illegal use of stderr has not been an issue. Why not switch to MinGW-w64 with UCRT at least?

[tmiw]

I'm amazed this has not been an issue before. But I guess since you prefer MinGW with msvcrt.dll this illegal use of stderr has not been an issue. Why not switch to MinGW-w64 with UCRT at least?

We're actually using LLVM MinGW to build the Windows builds, which in theory should be using UCRT already.