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::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, std::allocator >::_S_copy (__n=11,

__s=<optimized out>, __d=<optimized out>)
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, std::allocator >::_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, std::allocator >::assign (__str=..., this=) at /usr/include/c++/12/bits/basic_string.h:1548

6 std::__cxx11::basic_string<wchar_t, std::char_traits, std::allocator >::operator= (

__str=..., this=<optimized out>) 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.