Crash using VK/TX monitoring branch

[barjac]

Using VK/TX monitoring branch at #4fe00ee with the 'revert BETA back' patch applied.
This happens multiple times per session generally in RX apparently randomly, but also once on band change at RX using net_rigctl in read only mode. I applied the patch as I was also seeing the crashes yesterday without it, just in case it was related.

Thread 1 "FreeDV GUI" received signal SIGSEGV, Segmentation fault.
0x00007ffff4dede6b in __memmove_sse2_unaligned_erms () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff4dede6b in __memmove_sse2_unaligned_erms () from /lib64/libc.so.6
#1 0x00007ffff5158fb3 in wmemcpy (__n=11, __s2=, __s1=)
at /usr/include/bits/wchar2.h:39
#2 std::char_traits<wchar_t>::copy (__n=11, __s2=, __s1=)
at /usr/src/debug/gcc-12.3.0-3.mga9.x86_64/obj-x86_64-mageia-linux/x86_64-mageia-linux/libstdc++-v3/include/bits/char_traits.h:562
#3 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_S_copy (__n=11,
__s=, __d=)
at /usr/src/debug/gcc-12.3.0-3.mga9.x86_64/obj-x86_64-mageia-linux/x86_64-mageia-linux/libstdc++-v3/include/bits/basic_string.h:431
#4 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::_M_assign (
this=0x8be4d8, __str=...)
at /usr/src/debug/gcc-12.3.0-3.mga9.x86_64/obj-x86_64-mageia-linux/x86_64-mageia-linux/libstdc++-v3/include/bits/basic_string.tcc:291
#5 0x0000000000483f07 in std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::assign (__str=..., this=) at /usr/include/c++/12/bits/basic_string.h:1548
#6 std::__cxx11::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::operator= (
__str=..., this=) at /usr/include/c++/12/bits/basic_string.h:813
#7 wxString::operator= (stringSrc=..., this=) at /usr/include/wx-3.2/wx/string.h:1892
#8 operator() (__closure=0x7fffb4007818)
at /usr/src/debug/freedv-1.9.1-0.202308161457.4fe00ee.1.mga.x86_64/src/freedv_reporter.cpp:438
#9 0x00007ffff66052b0 in wxEvtHandler::TryHereOnly (this=this@entry=0xcef300, event=...)
at ./src/common/event.cpp:1636
#10 0x00007ffff660530a in wxEvtHandler::TryBeforeAndHere (event=..., this=0xcef300) at ./include/wx/event.h:4007
#11 wxEvtHandler::ProcessEventLocally (this=0xcef300, event=...) at ./src/common/event.cpp:1561
#12 0x00007ffff6605421 in wxEvtHandler::ProcessEvent (this=0xcef300, event=...) at ./src/common/event.cpp:1534
#13 0x00007ffff6606494 in wxEvtHandler::ProcessPendingEvents (this=0xcef300) at ./src/common/event.cpp:50
#14 0x00007ffff64a375f in wxAppConsoleBase::ProcessPendingEvents (this=0x5f6150) at ./include/wx/vector.h:493
#15 wxAppConsoleBase::ProcessPendingEvents (this=0x5f6150) at ./src/common/appbase.cpp:546
#16 0x00007ffff6b5571d in wxApp::DoIdle (this=0x5f6150) at ./src/gtk/app.cpp:151
#17 0x00007ffff6b55863 in wxapp_idle_callback () at ./src/gtk/app.cpp:101
#18 0x00007ffff3d9a40e in g_idle_dispatch (source=0x7fffb4009a10,
callback=0x7ffff6b55850 <wxapp_idle_callback(gpointer)>, user_data=0x0) at ../glib/gmain.c:6163
#19 0x00007ffff3d9e689 in g_main_dispatch (context=0x62e000) at ../glib/gmain.c:3460
#20 g_main_context_dispatch (context=0x62e000) at ../glib/gmain.c:4200
#21 0x00007ffff3d9ea18 in g_main_context_iterate (context=0x62e000, block=block@entry=1,
--Type for more, q to quit, c to continue without paging--c
dispatch=dispatch@entry=1, self=) at ../glib/gmain.c:4276
#22 0x00007ffff3d9ecbf in g_main_loop_run (loop=loop@entry=0x9daab0) at ../glib/gmain.c:4479
#23 0x00007ffff43ecc45 in gtk_main () at ../gtk/gtkmain.c:1329
#24 0x00007ffff6b723e5 in wxGUIEventLoop::DoRun (this=0xda7ad0) at ./src/gtk/evtloop.cpp:61
#25 0x00007ffff64d72ad in wxEventLoopBase::Run (this=0xda7ad0) at ./src/common/evtloopcmn.cpp:87
#26 0x00007ffff64a4afb in wxAppConsoleBase::MainLoop (this=0x5f6150) at ./src/common/appbase.cpp:381
#27 0x00007ffff651ec67 in wxEntry (argc=, argv=) at ./src/common/init.cpp:503
#28 0x0000000000437a98 in main (argc=, argv=) at /usr/src/debug/freedv-1.9.1-0.202308161457.4fe00ee.1.mga.x86_64/src/main.cpp:177

[tmiw]

I don't think it's specific to the VK PR based on taking a look at the FreeDV Reporter code mentioned in the stack trace. Try merging in the changes from #505 and let me know how that goes.

[barjac]

OK I ran #4fe00ee with pr503 and pr505 patches for maybe 30 mins tonight. Only one QSO to decode but lots of band switching and calling without a crash, so looking good. Will test this more as I get chance.

I am still seeing the VK message audio glitches which are NOT in the audio files as previously suspected. It seems that the glitches are always worse on the re-transmits rather than the first call. Lots of maybe 100ms gaps appear. Currently testing in my PA/WP system running under gdb with all the debuginfo packages installed, however I was in the native PA system when I first noticed this.
I need to monitor off air and in a local recording as well to check whether the glitches appear in the transmitted signal or only the VK monitor audio.

[tmiw]

I'll address the VK monitoring stuff in the other thread, but for now I merged #505 into master. Feel free to reopen this issue if you're still able to duplicate the crash.