Closed barjac closed 6 months ago
barjac
commented
6 months ago Terminal output is as follows (same with --verbose).
[baz@jackodesktop ~]$ bt freedv [2024-03-11 21:50:01] [connect] Successful connection [2024-03-11 21:50:01] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1710193801 101 [baz@jackodesktop ~]$
Tyrbiter
commented
6 months ago This only happens when built with lpcnetfreedv-0.5 and codec2-1.2. No idea which to blame.
FWIW I have been using my own builds of both those packages, and subsequently the distro releases, on Fedora 39 without any problems of this nature.
Fedora 40 beta release in a week, I'll see if that breaks anything.
tmiw
commented
6 months ago This only happens when built with lpcnetfreedv-0.5 and codec2-1.2. No idea which to blame.
FWIW I have been using my own builds of both those packages, and subsequently the distro releases, on Fedora 39 without any problems of this nature.
Fedora 40 beta release in a week, I'll see if that breaks anything.
Yeah, the Windows and macOS builds also use LPCNet 0.5 and codec2 1.2 and I haven't heard anything like this from Windows or Mac users recently.
@barjac, are you able to compile FreeDV with -fsanitize=address? This enables libasan support and will cause additional information to be output to the terminal if it's a memory issue causing the crash (i.e. buffer overflow).
barjac
commented
6 months ago I just discovered that the codec2-1.2 build had lost its BuildRequire on lpcnetfreedv and also Cmake's -DLPCNET:BOOL=ON during the clean-up to avoid the old build-twice scenario.
Now there is still an issue but it's a segfault with core dump on hitting Start.
Re-building with libasan and -fsanitize=address and will post bt and terminal output.
barjac
commented
6 months ago Terminal output:
[baz@jackodesktop ~]$ freedv --verbose
[2024-03-12 22:20:13] [connect] Successful connection
[2024-03-12 22:20:13] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1710282013 101
AddressSanitizer:DEADLYSIGNAL
=================================================================
==349382==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000284 (pc 0x7f97d0cdae90 bp 0x7ffe3ac3d130 sp 0x7ffe3ac3d118 T0)
==349382==The signal is caused by a WRITE memory access.
==349382==Hint: address points to the zero page.
#0 0x7f97d0cdae90 in ofdm_set_verbose (/lib64/libcodec2.so.1.2+0x24e90)
#1 0x56d72f in FreeDVInterface::setVerbose(bool) (/usr/bin/freedv+0x56d72f)
#2 0x4a106f in std::_Function_handler<void (), MainFrame::performFreeDVOn_()::{lambda()#2}>::_M_invoke(std::_Any_data const&) (/usr/bin/freedv+0x4a106f)
#3 0x51821f in wxAsyncMethodCallEventFunctor<MainFrame::executeOnUiThreadAndWait_(std::function<void ()>)::{lambda()#1}>::Execute() (/usr/bin/freedv+0x51821f)
#4 0x7f97cf40ad5f in wxEvtHandler::TryHereOnly(wxEvent&) (/lib64/libwx_baseu-3.2.so.0+0x20ad5f)
#5 0x7f97cf40adb9 in wxEvtHandler::ProcessEventLocally(wxEvent&) (/lib64/libwx_baseu-3.2.so.0+0x20adb9)
#6 0x7f97cf40aed0 in wxEvtHandler::ProcessEvent(wxEvent&) (/lib64/libwx_baseu-3.2.so.0+0x20aed0)
#7 0x7f97cf40bf03 in wxEvtHandler::ProcessPendingEvents() (/lib64/libwx_baseu-3.2.so.0+0x20bf03)
#8 0x7f97cf2a2b99 in wxAppConsoleBase::ProcessPendingEvents() (/lib64/libwx_baseu-3.2.so.0+0xa2b99)
#9 0x7f97cf955030 in wxApp::DoIdle() (/lib64/libwx_gtk3u_core-3.2.so.0+0x355030)
#10 0x7f97cf955102 in wxapp_idle_callback (/lib64/libwx_gtk3u_core-3.2.so.0+0x355102)
#11 0x7f97cdcfe6ed in g_idle_dispatch (/lib64/libglib-2.0.so.0+0x546ed)
#12 0x7f97cdd00dd8 in g_main_context_dispatch_unlocked (/lib64/libglib-2.0.so.0+0x56dd8)
#13 0x7f97cdd02827 in g_main_context_iterate_unlocked.constprop.0 (/lib64/libglib-2.0.so.0+0x58827)
#14 0x7f97cdd030ce in g_main_loop_run (/lib64/libglib-2.0.so.0+0x590ce)
#15 0x7f97ce3ecf84 in gtk_main (/lib64/libgtk-3.so.0+0x1ecf84)
#16 0x7f97cf971474 in wxGUIEventLoop::DoRun() (/lib64/libwx_gtk3u_core-3.2.so.0+0x371474)
#17 0x7f97cf2d8ccc in wxEventLoopBase::Run() (/lib64/libwx_baseu-3.2.so.0+0xd8ccc)
#18 0x7f97cf2a3f3a in wxAppConsoleBase::MainLoop() (/lib64/libwx_baseu-3.2.so.0+0xa3f3a)
#19 0x7f97cf322ea6 in wxEntry(int&, wchar_t**) (/lib64/libwx_baseu-3.2.so.0+0x122ea6)
#20 0x460c6f in main (/usr/bin/freedv+0x460c6f)
#21 0x7f97cf051736 in __libc_start_call_main (/lib64/libc.so.6+0x23736)
#22 0x7f97cf0517f4 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x237f4)
#23 0x4643e0 in _start (/usr/bin/freedv+0x4643e0)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libcodec2.so.1.2+0x24e90) in ofdm_set_verbose
==349382==ABORTING
[baz@jackodesktop ~]$ The following were taken before I got fsanitize working: Backtrace: gdb3.bt.txt
strace: freedv_strace.txt
The above files appear to get lost on github I just get a 404 - tried replacing them and get the same error :(
Tyrbiter
commented
6 months ago Re-building with libasan and -fsanitize=address and will post bt and terminal output.
Just remember to disable that for stable packages, it does slow down execution to some extent.
barjac
commented
6 months ago Re-building with libasan and -fsanitize=address and will post bt and terminal output.
Just remember to disable that for stable packages, it does slow down execution to some extent.
Yes will do. Good night all!
tmiw
commented
6 months ago I just discovered that the codec2-1.2 build had lost its BuildRequire on lpcnetfreedv and also Cmake's -DLPCNET:BOOL=ON during the clean-up to avoid the old build-twice scenario.
Now there is still an issue but it's a segfault with core dump on hitting Start.
I'm wondering whether 2020 is getting disabled in the codec2 build now. There is a possible scenario where 2020 is still enabled in ~/.freedv but the binary/libraries get changed such that the mode is no longer available. In that case, it'd still try to open 2020 mode on pushing Start but doing so would cause codec2's freedv_open to return nullptr and thus cause the above fault.
Anyway, it might be worth editing ~/.freedv to force FirstTimeUse to 1 (forcing first-time testing of 2020 again) and seeing if the application behaves any better. If that ends up fixing the problem, (a) the codec2 packages on Mageia may need to be revisited and (b) perhaps FreeDV does need to do a less involved test every startup to avoid this (vs. assuming that the FreeDV2020/Allowed flag is always going to be correct).
barjac
commented
6 months ago OK this is getting somewhere. With FirstTimeUse set to 1 the only message is the two lines about connection then nothing and no GUI starts.
With FirstTimeUse set to 0 (as it was) but with: [FreeDV2020] Allowed=0 then the GUI starts and the modem worked for the first run with the following output. however the radio was not switched on. Terminal output:
[baz@jackodesktop ~]$ freedv
[2024-03-13 10:29:00] [connect] Successful connection
[2024-03-13 10:29:01] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1710325740 101
Setting callsign to G4MKT
PulseAudioDevice[Wed 13 Mar 2024 10:29:11 GMT]: connecting to record device alsa_input.usb-GeneralPlus_USB_Audio_Device-00.mono-fallback
PulseAudioDevice[Wed 13 Mar 2024 10:29:11 GMT]: connecting to playback device alsa_output.usb-0d8c_USB_PnP_Sound_Device-00.analog-stereo
PulseAudioDevice[Wed 13 Mar 2024 10:29:11 GMT]: connecting to record device alsa_input.usb-0d8c_USB_PnP_Sound_Device-00.mono-fallback
PulseAudioDevice[Wed 13 Mar 2024 10:29:11 GMT]: connecting to playback device alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo
rig_init: rig_model=Hamlib NET rigctl
rig_init: rig does not have tx_range!!
rig_token_lookup called for rig_pathname
rig_confparam_lookup called for rig_pathname
rig_set_conf called
rig_confparam_lookup called for 1073741834
rig_set_conf: rig_pathname='0.0.0.0:4532'
rig_token_lookup called for ptt_pathname
rig_confparam_lookup called for ptt_pathname
rig_set_conf called
rig_confparam_lookup called for 1073741855
rig_set_conf: ptt_pathname='0.0.0.0:4532'
1:rig.c(817):rig_open entered
rig_settings_load_all: settings_file (/home/baz/.config/hamlib_settings): No such file or directory
rig_open: cwd=/home/baz
rig_open: /home/baz/hamlib_settings does not exist
2:rig.c(7481):async_data_handler_start entered
2:rig.c(7488):async_data_handler_start returning(0)
rig.c(254):add_opened_rig returning2(0)
rig_open: 0x62900010261c rs->comm_state==1?=1
2:rig.c(6084):rig_get_powerstat entered
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
network_flush called
read_string_generic(): Timed out 10.010 seconds after 0 chars, direct=1
netrigctl_get_powerstat: PS command failed (ret=-5) so returning RIG_POWER_ON
2:rig.c(6109):rig_get_powerstat returning(0)
2:netrigctl.c(261):netrigctl_open entered
netrigctl_transaction: called len=9
network_flush called
read_string_generic(): Timed out 10.003 seconds after 0 chars, direct=1
netrigctl_open: chk_vfo error: 2:rig.c(6084):rig_get_powerstat entered
rig.c(6104) trace
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
rig_flush: called for network device
network_flush called
write_block(): TX 15 bytes, method=2
read_string_generic called, rxmax=1024 direct=1, expected_len=1
read_string_generic(): Timed out 10.010 seconds after 0 chars, direct=1
netrigctl_get_powerstat: PS command failed (ret=-5) so returning RIG_POWER_ON
2:rig.c(6109):rig_get_powerstat returning(0)
2:netrigctl.c(261):netrigctl_open entered
netrigctl_transaction: called len=9
rig_flush: called for network device
network_flush called
write_block(): TX 9 bytes, method=2
read_string_generic called, rxmax=1024 direct=1, expected_len=1
read_string_generic(): Timed out 10.003 seconds after 0 chars, direct=1
Communication timed out
Communication timed out
netrigctl_open: vfo_mode=0
netrigctl_transaction: called len=12
network_flush called
read_string_generic(): read failed, direct=1 - Connection reset by peer
2:netrigctl.c(299):netrigctl_open returning(-6) IO error
2:rig.c(7525):async_data_handler_stop entered
2:rig.c(7555):async_data_handler_stop returning(0)
network_close: close socket ret=0
1:rig.c(1301):rig_open returning(-6) IO error
[2024-03-13 10:29:31] [disconnect] Disconnect close local:[1000,End by user] remote:[1000]
=================================================================
==24178==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 59648 byte(s) in 233 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f0667be9a81 in FcPatternObjectInsertElt (/lib64/libfontconfig.so.1+0x23a81)
Direct leak of 7936 byte(s) in 12 object(s) allocated from:
#0 0x7f066c0b7c95 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xb7c95)
#1 0x7f0667be9b28 in FcPatternObjectInsertElt (/lib64/libfontconfig.so.1+0x23b28)
Direct leak of 352 byte(s) in 11 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f066aecc1a4 in codec2_fifo_create_buf (/lib64/libcodec2.so.1.2+0x161a4)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f066aee5699 in freedv_800xa_open (/lib64/libcodec2.so.1.2+0x2f699)
Indirect leak of 65312 byte(s) in 2041 object(s) allocated from:
#0 0x7f066c0b8777 in calloc (/lib64/libasan.so.8+0xb8777)
#1 0x7f0667bea24c in FcPatternObjectAddWithBinding (/lib64/libfontconfig.so.1+0x2424c)
Indirect leak of 32668 byte(s) in 11 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f066aecc1ce in codec2_fifo_create (/lib64/libcodec2.so.1.2+0x161ce)
Indirect leak of 18263 byte(s) in 1517 object(s) allocated from:
#0 0x7f066c070abb in strdup (/lib64/libasan.so.8+0x70abb)
#1 0x7f0667be9327 in FcValueSave (/lib64/libfontconfig.so.1+0x23327)
Indirect leak of 17344 byte(s) in 542 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f0667bd452f in FcConfigValues (/lib64/libfontconfig.so.1+0xe52f)
Indirect leak of 5632 byte(s) in 176 object(s) allocated from:
#0 0x7f066c0b8777 in calloc (/lib64/libasan.so.8+0xb8777)
#1 0x7f0667be967a in FcValueListDuplicate (/lib64/libfontconfig.so.1+0x2367a)
Indirect leak of 1344 byte(s) in 42 object(s) allocated from:
#0 0x7f066c0b8777 in calloc (/lib64/libasan.so.8+0xb8777)
#1 0x7f0667be9537 in FcValueListPrepend (/lib64/libfontconfig.so.1+0x23537)
Indirect leak of 336 byte(s) in 7 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f0667be2f8b in FcLangSetCopy (/lib64/libfontconfig.so.1+0x1cf8b)
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x7f066c0b9888 in operator new(unsigned long) (/lib64/libasan.so.8+0xb9888)
#1 0x76f10b in FreeDVReporterDialog::FreeDVReporterDialog(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long) (/usr/bin/freedv+0x76f10b)
#2 0x48df74 in MainFrame::initializeFreeDVReporter_() (/usr/bin/freedv+0x48df74)
#3 0x49a4e6 in MainFrame::loadConfiguration_() (/usr/bin/freedv+0x49a4e6)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7f066c0b9888 in operator new(unsigned long) (/lib64/libasan.so.8+0xb9888)
#1 0x7f06695cf173 in wxMutex::wxMutex(wxMutexType) (/lib64/libwx_baseu-3.2.so.0+0x1cf173)
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f066c0b9888 in operator new(unsigned long) (/lib64/libasan.so.8+0xb9888)
#1 0x7f0669b89a72 in wxGUIAppTraits::CreateTimerImpl(wxTimer*) (/lib64/libwx_gtk3u_core-3.2.so.0+0x389a72)
Indirect leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7f066c0b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f0667bec2f5 in FcRangeCopy (/lib64/libfontconfig.so.1+0x262f5)
SUMMARY: AddressSanitizer: 209107 byte(s) leaked in 4597 allocation(s).
[baz@jackodesktop ~]$ On subsequent runs with the same two settings in ~/.freedv the GUI dies on hitting Start and it now reports:
[baz@jackodesktop ~]$ freedv
[2024-03-13 10:48:26] [connect] Successful connection
[2024-03-13 10:48:26] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1710326906 101
Setting callsign to G4MKT
PulseAudioDevice[Wed 13 Mar 2024 10:48:32 GMT]: connecting to record device alsa_input.usb-GeneralPlus_USB_Audio_Device-00.mono-fallback
PulseAudioDevice[Wed 13 Mar 2024 10:48:32 GMT]: connecting to playback device alsa_output.usb-0d8c_USB_PnP_Sound_Device-00.analog-stereo
PulseAudioDevice[Wed 13 Mar 2024 10:48:32 GMT]: connecting to record device alsa_input.usb-0d8c_USB_PnP_Sound_Device-00.mono-fallback
PulseAudioDevice[Wed 13 Mar 2024 10:48:32 GMT]: connecting to playback device alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo
rig_init: rig_model=Hamlib NET rigctl
rig_init: rig does not have tx_range!!
rig_token_lookup called for rig_pathname
rig_confparam_lookup called for rig_pathname
rig_set_conf called
rig_confparam_lookup called for 1073741834
rig_set_conf: rig_pathname='0.0.0.0:4532'
rig_token_lookup called for ptt_pathname
rig_confparam_lookup called for ptt_pathname
rig_set_conf called
rig_confparam_lookup called for 1073741855
rig_set_conf: ptt_pathname='0.0.0.0:4532'
1:rig.c(817):rig_open entered
rig_settings_load_all: settings_file (/home/baz/.config/hamlib_settings): No such file or directory
rig_open: cwd=/home/baz
rig_open: /home/baz/hamlib_settings does not exist
2:rig.c(7481):async_data_handler_start entered
2:rig.c(7488):async_data_handler_start returning(0)
rig.c(254):add_opened_rig returning2(0)
rig_open: 0x62900010261c rs->comm_state==1?=1
2:rig.c(6084):rig_get_powerstat entered
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
network_flush called
2:rig.c(6109):rig_get_powerstat returning(0)
2:netrigctl.c(261):netrigctl_open entered
netrigctl_transaction: called len=9
network_flush called
netrigctl_open: vfo_mode=0
netrigctl_transaction: called len=12
network_flush called
=================================================================
==79009==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000adc90 at pc 0x7f95b004fc11 bp 0x7f958f83d2c0 sp 0x7f958f83ca70
READ of size 2 at 0x6020000adc90 thread T15
#0 0x7f95b004fc10 in __interceptor_setlocale.part.0 (/lib64/libasan.so.8+0x4fc10)
#1 0x7f95ae30938a in netrigctl_open (/lib64/libhamlib.so.4+0x10938a)
#2 0x7f95ae29a877 in rig_open (/lib64/libhamlib.so.4+0x9a877)
#3 0x7998f0 in HamlibRigController::connectImpl_() (/usr/bin/freedv+0x7998f0)
#4 0x79ca23 in std::_Function_handler<void (), std::_Bind<void (HamlibRigController::*(HamlibRigController*))()> >::_M_invoke(std::_Any_data const&) (/usr/bin/freedv+0x79ca23)
#5 0x7ea252 in ThreadedObject::eventLoop_() (/usr/bin/freedv+0x7ea252)
#6 0x7eaad4 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<std::_Bind<void (ThreadedObject::*(ThreadedObject*))()> > > >::_M_run() (/usr/bin/freedv+0x7eaad4)
#7 0x7f95ad0d6562 in execute_native_thread_routine (/lib64/libstdc++.so.6+0xd6562)
#8 0x7f95aceb19c9 in start_thread (/lib64/libc.so.6+0x839c9)
#9 0x7f95acf2d61b in __GI___clone3 (/lib64/libc.so.6+0xff61b)
0x6020000adc90 is located 0 bytes inside of 12-byte region [0x6020000adc90,0x6020000adc9c)
freed by thread T15 here:
#0 0x7f95b00b7a68 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb7a68)
#1 0x7f95ace5b181 in __GI_setlocale (/lib64/libc.so.6+0x2d181)
previously allocated by thread T0 here:
#0 0x7f95b00b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
#1 0x7f95acec5b19 in __strdup (/lib64/libc.so.6+0x97b19)
Thread T15 created by T10 here:
#0 0x7f95b0049a16 in __interceptor_pthread_create (/lib64/libasan.so.8+0x49a16)
#1 0x7f95ad0d6638 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (/lib64/libstdc++.so.6+0xd6638)
Thread T10 created by T0 here:
#0 0x7f95b0049a16 in __interceptor_pthread_create (/lib64/libasan.so.8+0x49a16)
#1 0x7f95ad0d6638 in std::thread::_M_start_thread(std::unique_ptr<std::thread::_State, std::default_delete<std::thread::_State> >, void (*)()) (/lib64/libstdc++.so.6+0xd6638)
#2 0x7ffdbca2882f ([stack]+0x2382f)
SUMMARY: AddressSanitizer: heap-use-after-free (/lib64/libasan.so.8+0x4fc10) in __interceptor_setlocale.part.0
Shadow bytes around the buggy address:
0x0c048000db40: fa fa fd fd fa fa 02 fa fa fa fd fd fa fa fd fd
0x0c048000db50: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x0c048000db60: fa fa fd fd fa fa fd fa fa fa fd fa fa fa 00 04
0x0c048000db70: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
0x0c048000db80: fa fa 00 04 fa fa 00 04 fa fa 00 04 fa fa 00 04
=>0x0c048000db90: fa fa[fd]fd fa fa fd fd fa fa 00 00 fa fa 00 01
0x0c048000dba0: fa fa 00 01 fa fa 00 00 fa fa fd fa fa fa fd fd
0x0c048000dbb0: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
0x0c048000dbc0: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
0x0c048000dbd0: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fa
0x0c048000dbe0: fa fa fd fd fa fa fd fa fa fa fd fd fa fa fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==79009==ABORTING
[baz@jackodesktop ~]$This kinda looks like a Hamlib problem:
==79009==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020000adc90 at pc 0x7f95b004fc11 bp 0x7f958f83d2c0 sp 0x7f958f83ca70
READ of size 2 at 0x6020000adc90 thread T15
#0 0x7f95b004fc10 in __interceptor_setlocale.part.0 (/lib64/libasan.so.8+0x4fc10)
#1 0x7f95ae30938a in netrigctl_open (/lib64/libhamlib.so.4+0x10938a)
#2 0x7f95ae29a877 in rig_open (/lib64/libhamlib.so.4+0x9a877)What version are you using?
Also, I really do suspect some sort of issue with how codec2 was built. The first time use check happens here:
#if defined(FREEDV_MODE_2020)
// First time use: make sure 2020 mode will actually work on this machine.
if (wxGetApp().appConfiguration.firstTimeUse)
{
test2020Mode_();
}
else
{
wxGetApp().appConfiguration.freedvAVXSupported = test2020HWAllowed_();
}
#endif // defined(FREEDV_MODE_2020)which would only get called if 2020 was enabled in the library. Can you try setting FirstTimeUse to 1 again and running FreeDV in gdb (pushing Ctrl-C once it hangs so you can get a backtrace)?
barjac
commented
6 months ago hamlib is lib64hamlib4-4.5.5-1.mga9. Still at last Mga9 build. lpcnetfreedv was re-built followed by codec2 with require on it , followed by freedv and freedv was using the correct newly built versions during it's build.
`backtrace:
registers: rax 0x10007fff7190 17594333491600 rbx 0x7fffffff8ca0 140737488325792 rcx 0x7fffffffffff 140737488355327 rdx 0x10007fff7194 17594333491604 rsi 0x0 0 rdi 0x7fffffff8ca0 140737488325792 rbp 0x7fffffff8ca0 0x7fffffff8ca0 rsp 0x7fffffff8c48 0x7fffffff8c48 r8 0x0 0 r9 0x0 0 r10 0x7ffff78092c8 140737345786568 r11 0x7ffff78383c0 140737345979328 r12 0x7fffffff8d20 140737488325920 r13 0x7fffffff8d20 140737488325920 r14 0x7fffffff8d20 140737488325920 r15 0x7fffffff8d20 140737488325920 rip 0x7ffff78382fb 0x7ffff78382fb <__asan_alloca_poison+43> eflags 0x202 [ IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0
current instructions: => 0x7ffff78382fb <asan_alloca_poison+43>: mov %rbp,%r13 0x7ffff78382fe <asan_alloca_poison+46>: lea 0x1f(%rbp),%r12 0x7ffff7838302 <asan_alloca_poison+50>: sub %rax,%rdx 0x7ffff7838305 <asan_alloca_poison+53>: and $0xfffffffffffffff8,%r13 0x7ffff7838309 <asan_alloca_poison+57>: mov $0xca,%esi 0x7ffff783830e <asan_alloca_poison+62>: and $0xffffffffffffffe0,%r12 0x7ffff7838312 <asan_alloca_poison+66>: mov %rax,%rdi 0x7ffff7838315 <asan_alloca_poison+69>: sub $0x8,%rsp 0x7ffff7838319 <asan_alloca_poison+73>: lea 0x113940(%rip),%rbx # 0x7ffff794bc60 0x7ffff7838320 <asan_alloca_poison+80>: call *(%rbx) 0x7ffff7838322 <asan_alloca_poison+82>: lea 0x112a77(%rip),%rax # 0x7ffff794ada0 0x7ffff7838329 <asan_alloca_poison+89>: mov %r13,%rdx 0x7ffff783832c <asan_alloca_poison+92>: mov %rbp,%rsi 0x7ffff783832f <asan_alloca_poison+95>: shr $0x3,%rdx 0x7ffff7838333 <asan_alloca_poison+99>: mov %r12,%r8 0x7ffff7838336 <asan_alloca_poison+102>: and $0x7,%esi
threads backtrace:
Thread 10 (Thread 0x7fffdb3e46c0 (LWP 16734) "FreeDV GUI"):
Thread 9 (Thread 0x7fffdbbe56c0 (LWP 16733) "FreeDV GUI"):
Thread 8 (Thread 0x7fffdc3e66c0 (LWP 16732) "FreeDV GUI"):
Thread 7 (Thread 0x7fffe8f7f6c0 (LWP 16731) "threaded-ml"):
Thread 6 (Thread 0x7fffeddfb6c0 (LWP 16730) "pool-freedv"):
Thread 5 (Thread 0x7fffee5fc6c0 (LWP 16729) "freedv"):
Thread 4 (Thread 0x7fffeedfd6c0 (LWP 16705) "gdbus"):
Thread 3 (Thread 0x7fffef5fe6c0 (LWP 16704) "gmain"):
Thread 2 (Thread 0x7fffefdff6c0 (LWP 16703) "pool-spawner"):
Thread 1 (Thread 0x7ffff1e78a80 (LWP 16700) "FreeDV GUI"):
Warning: 'set logging off', an alias for the command 'set logging enabled', is deprecated. Use 'set logging enabled off'.
`
Tyrbiter
commented
6 months ago hamlib is lib64hamlib4-4.5.5-1.mga9. Still at last Mga9 build.
Mike was working on a hamlib-4.5.6 release almost a year ago, but the changes needed for the hamlib-4.6~git development were extensive and he gave up back-porting them to 4.5.x. I have been using the 4.6~git code for almost a year and, excepting a few major regression problems that got fixed rapidly, it has been no trouble for the 2 radios I use it with most days. I have used about 360 builds of the git tree during this time, so it isn't what you would call stable in code terms but function-wise it's been quite stable for months now.
barjac
commented
6 months ago I have just packaged hamlib-4.6 as of today's snapshot and have re-built freedv against it.
freedv GUI starts ok but on starting the modem it dies: terminal.txt
Using hamlib-4.6 with lpcnetfreedv-0.3 and codec2-1.0 in mageia9 stable is fine with or without a freedv rebuild which is reasonable.
Tyrbiter
commented
6 months ago I have just packaged hamlib-4.6 as of today's snapshot and have re-built freedv against it.
freedv GUI starts ok but on starting the modem it dies: terminal.txt
Using hamlib-4.6 with lpcnetfreedv-0.3 and codec2-1.0 in mageia9 stable is fine with or without a freedv rebuild which is reasonable.
I am not sure if @mdblack98 can make any sense out of this, but it might show a problem in hamlib
barjac
commented
6 months ago I am not sure if @mdblack98 can make any sense out of this, but it might show a problem in hamlib
Does Mike follow freedv issues or will he be pinged because of the mention above?
I looked at the fc40 codec2.spec and I am surprised that the BuildRequires are not versioned, other than that I see no real difference between fc and Mageia.
Are you absolutely sure that you are building against lpcnetfreedv-0.5 and codec2-1.2?
I will test builds using only one new version of lpcnet or codec2 at a time to try to narrow it down.
Tyrbiter
commented
6 months ago I am not sure if @mdblack98 can make any sense out of this, but it might show a problem in hamlib
Does Mike follow freedv issues or will he be pinged because of the mention above?
In theory he will get an email or other notification, but maybe you could create an issue in hamlib for this. It seems real enough.
I looked at the fc40 codec2.spec and I am surprised that the BuildRequires are not versioned, other than that I see no real difference between fc and Mageia.
A fair point, the packager has not appreciated the differences between the versions I think. I will drop him an email or put something in the RH bugzilla so that it can be caught.
Are you absolutely sure that you are building against lpcnetfreedv-0.5 and codec2-1.2?
I've just checked this again and I only have lpcnetfreedv-0.5 and codec2-1.2 packages on my Fedora 39 system, the -devel packages are also the same versions as the library packages.
mdblack98
commented
6 months ago I'm here. I built freedv on my Ubuntu VM so I could debug this and it doesn't bring up any windows. .src/freedv09:01:01 AM: Debug: Element @. ("slider") of wxStaticBoxSizer should be created as child of its wxStaticBox and not of @. ("panel").09:01:01 AM: Debug: Element @. ("0 dB") of wxStaticBoxSizer should be created as child of its wxStaticBox and not of @. ("panel"). Debug show it is stuck here.#5 0x000055555561671c in MainFrame::executeOnUiThreadAndWait_(std::function<void ()>) (this=0x555555bb9a00, fn=...) at /home/mdblack98/src/freedv-gui/src/util.cpp:386386 funcConditionVariable.wait(funcLock); I think did "apt install freedv" and that one works bringing up the GUI. Just the compile one gets stuck in the mutex. Mike W9MDB If you are compiling Hamlib yourself make sure to remove the hamlib packages first. If you do "ldd freedv | grep hamlib" it's probably lookin in /usr/lib and not /usr/local/lib where a default compile will install it. Mike W9MDB
On Thursday, March 14, 2024 at 08:32:49 AM CDT, Barry Jackson ***@***.***> wrote: I am not sure if @mdblack98 can make any sense out of this, but it might show a problem in hamlib
Does Mike follow freedv issues or will he be pinged because of the mention above?
I looked at the fc40 codec2.spec and I am surprised that the BuildRequires are not versioned, other than that I see no real difference between fc and Mageia.
Are you absolutely sure that you are building against lpcnetfreedv-0.5 and codec2-1.2?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
Tyrbiter
commented
6 months ago I'm here. I built freedv on my Ubuntu VM so I could debug this and it doesn't bring up any windows. .src/freedv09:01:01 AM: Debug: Element @. ("slider") of wxStaticBoxSizer should be created as child of its wxStaticBox and not of @. ("panel").09:01:01 AM: Debug: Element @. ("0 dB") of wxStaticBoxSizer should be created as child of its wxStaticBox and not of @. ("panel"). Debug show it is stuck here.#5 0x000055555561671c in MainFrame::executeOnUiThreadAndWait_(std::function<void ()>) (this=0x555555bb9a00, fn=...) at /home/mdblack98/src/freedv-gui/src/util.cpp:386386 funcConditionVariable.wait(funcLock); I think did "apt install freedv" and that one works bringing up the GUI. Just the compile one gets stuck in the mutex.
Which packages do you have installed Mike? On Fedora the build uses shared objects for lpcnetfreedv and codec2 as well as wxBase and wxGTK3 but I am not familiar with a build on Ubuntu which is probably different. It could easily be that the version you're building locally is behaving differently because this is not a simple process.
tmiw
commented
6 months ago @mdblack98 and @barjac, can you guys try using the build_linux.sh script in the source tree to build FreeDV if you haven't done so already? That should take any packaging issues out of the picture.
Anyway, my Ubuntu VM is broken at the moment, but Fedora 39 with KDE shows the Easy Setup window as expected after doing the following:
$ cd freredv-gui
$ rm -rf codec2 LPCNet build_linux
$ ./build_linux.sh
$ cd build_linux
$ rm -f ~/.freedv && src/freedv(I also ran sudo dnf update and rebooted prior just to make sure I had the latest packages.)
barjac
commented
6 months ago OK stop searching!
All is now resolved!
The "AddressSanitizer: heap-use-after-free on address..." is caused by AddressSanitizer.
Tonight I completely cleared all versions of lpcnet, codec2 and freedv from my local repo. I removed all installed versions from my machine. I built new versions of all three in order and specified exact versions for BuildRequires. The result was the same "AddressSanitizer: heap-use-after-free on address...".
I then added a conditional to the freedv spec to easily include asan in the build or not and disabled it for a new build of freedv.
No problem!
I can only assume that the initial issue was down to a BuildRequire version error in the first build with lpcnetfreedv-0.5 and codec2-1.2 for which I apologize.
Sorry for all the noise, however I won't be using asan in a hurry again any time soon!
tmiw
commented
6 months ago It sounds like there's still possibly a hamlib issue, though, right? Even if it can only be triggered by enabling libasan, that probably should still be fixed IMO.
Also, there might still an issue when starting FreeDV for the first time, too? Let's clarify that before closing.
barjac
commented
6 months ago Hi Mooneer, I just tested first time and it's all OK with 2020 and 2020B selectable. I don't see a hamlib issue. Where do you see this?
[baz@jackodesktop ~]$ freedv --verbose
[2024-03-14 23:48:01] [connect] Successful connection
[2024-03-14 23:48:02] [connect] WebSocket Connection 208.85.243.198:80 v-2 "WebSocket++/0.8.2" /socket.io/?EIO=4&transport=websocket&t=1710460081 101
Setting callsign to G4MKT
PulseAudioDevice[Thu 14 Mar 2024 23:48:03 GMT]: connecting to record device alsa_input.usb-GeneralPlus_USB_Audio_Device-00.mono-fallback
PulseAudioDevice[Thu 14 Mar 2024 23:48:03 GMT]: connecting to playback device alsa_output.usb-0d8c_USB_PnP_Sound_Device-00.analog-stereo
PulseAudioDevice[Thu 14 Mar 2024 23:48:03 GMT]: connecting to record device alsa_input.usb-0d8c_USB_PnP_Sound_Device-00.mono-fallback
PulseAudioDevice[Thu 14 Mar 2024 23:48:03 GMT]: connecting to playback device alsa_output.usb-GeneralPlus_USB_Audio_Device-00.analog-stereo
rig_test_2038: time_t 2038 test = 0xf0000000:Mon Aug 5 10:04:00 2097
rig_init: 2038 time test passed
rig_init: rig_model=Hamlib NET rigctl 20240304.0
rig_init: rig does not have tx_range!!
rig_token_lookup called for rig_pathname
rig_confparam_lookup called for rig_pathname
rig_set_conf called
rig_confparam_lookup called for 1073741834
rig_set_conf: rig_pathname='127.0.0.1:4532'
rig_token_lookup called for ptt_pathname
rig_confparam_lookup called for ptt_pathname
rig_set_conf called
rig_confparam_lookup called for 1073741855
rig_set_conf: ptt_pathname='127.0.0.1:4532'
rig.c(945):rig_open entered
rig_settings_load_all: settings_file (/home/baz/.config/hamlib_settings): No such file or directory
rig_open: cwd=/home/baz
rig_open: /home/baz/hamlib_settings No such file or directory
***2:rig.c(8287):async_data_handler_start entered
***2:rig.c(8294):async_data_handler_start returning(0)
rig_open: 0x7f3024008044 rs->comm_state==1?=1
***2:rig.c(6782):rig_get_powerstat entered
netrigctl_get_powerstat called
netrigctl_transaction: called len=15
network_flush called
***2:rig.c(6809):rig_get_powerstat returning(0)
***2:netrigctl.c(258):netrigctl_open entered
netrigctl_transaction: called len=9
network_flush called
netrigctl_open: vfo_mode=0
netrigctl_transaction: called len=12
network_flush called
## vfo_ops=0x60
## ptt_type=0x1
netrigctl_open: ptt_type='0x1'(1)
## targetable_vfo=0x1
netrigctl_open: targetable_vfo=0x 1
## has_set_vfo=1
## has_get_vfo=1
## has_set_freq=1
## has_get_freq=1
## has_set_conf=0
## has_get_conf=0
## has_power2mW=0
## has_mW2power=0
## has_get_ant=0
## has_set_ant=0
## timeout=1000
## rig_model=2003
## rigctld_version=Hamlib 4.6~git 2024-03-10T02:23:01Z SHA=c7665c 64-bit
## agc_levels=
netrigctl_open: invalid dumpcaps line, expected 'setting=value', got 'agc_levels='
## level_gran=0=0,20,10;1=0,12,0;2=3,300,1;3=0,1065353216,998277249;4=0,1065353216,998277249;5=0,1065353216,1008981770;6=-1000,1000,1;7=0,0,0;8=0,1,0.1;9=0,0,0;10=0,0,0;11=4.2039e-43,1.47136e-42,7.00649e-44;12=0.05,1,0.01;13=0,1,0.01;14=5.60519e-45,8.40779e-44,1.4013e-45;15=1.4013e-45,4.48416e-42,1.4013e-44;16=0,1,0.01;17=0,0,0;18=4.2039e-44,4.2039e-42,1.4013e-45;19=0,0,0;20=0,0,0;21=0,1,0.01;22=0,1,0.01;23=1.4013e-44,1.4013e-42,7.00649e-44;24=1.4013e-42,7.00649e-42,1.4013e-44;25=4.2039e-44,4.2039e-42,1.4013e-45;26=0,3.57331e-43,0;27=0,0,0;28=0,5,0.00392157;29=0,1,0.01;30=0,8.40779e-44,0;31=0,0,0;32=0,1,0.00392157;33=0,1,0.00392157;34=0,1,0.00392157;35=0,1,0.00392157;36=0,0,0;37=0,1,0.01;38=0,1,0.1;39=0,100,0.00392157;40=0,0,0;41=0,0,0;42=0,0,0;43=0,0,0;44=0,0,0;45=0,0,0;46=0,0,0;47=0,0,0;48=0,0,0;49=0,2.24208e-44,1.4013e-45;50=0,1,0.1;51=0,1,0.1;52=0,0,0;53=0,0,0;54=0,0,0;55=0,0,0;56=0,0,0;57=0,0,0;58=0,0,0;59=0,0,0;60=0,0,0;61=0,0,0;62=0,0,0;63=0,0,0;
## parm_gran=0=0,20,10;1=0,12,0;2=3,300,1;3=0,1065353216,998277249;4=0,1065353216,998277249;5=0,1065353216,1008981770;6=-1000,1000,1;7=0,0,0;8=0,0,0;9=0,0,0;10=0,0,0;11=0,0,0;12=0,0,0;13=0,0,0;14=0,0,0;15=0,0,0;16=0,0,0;17=0,0,0;18=0,0,0;19=0,0,0;20=0,0,0;21=0,0,0;22=0,0,0;23=0,0,0;24=0,0,0;25=0,0,0;26=0,0,0;27=0,0,0;28=0,0,0;29=0,0,0;30=0,0,0;31=0,0,0;32=0,0,0;33=0,0,0;34=0,0,0;35=0,0,0;36=0,0,0;37=0,0,0;38=0,0,0;39=0,0,0;40=0,0,0;41=0,0,0;42=0,0,0;43=0,0,0;44=0,0,0;45=0,0,0;46=0,0,0;47=0,0,0;48=0,0,0;49=0,0,0;50=0,0,0;51=0,0,0;52=0,0,0;53=0,0,0;54=0,0,0;55=0,0,0;56=0,0,0;57=0,0,0;58=0,0,0;59=0,0,0;60=0,0,0;61=0,0,0;62=0,0,0;63=0,0,0;
## rig_model=2003
## hamlib_version=Hamlib 4.6~git 2024-03-10T02:23:01Z SHA=c7665c 64-bit
netrigctl_open: unknown setting='hamlib_version=Hamlib 4.6~git 2024-03-10T02:23:01Z SHA=c7665c 64-bit'
## done
***2:netrigctl.c(644):netrigctl_open returning(0)
***2:rig.c(3381):rig_get_vfo entered
netrigctl_get_vfo called
netrigctl_transaction: called len=2
network_flush called
rig_parse_vfo called
**2:rig_get_vfo: elapsed=113ms
***2:rig.c(3442):rig_get_vfo returning(0)
***2:rig.c(8331):morse_data_handler_start entered
morse_data_handler_start(8349): keyspd=25
***2:rig.c(8361):morse_data_handler_start returning(0)
***2:rig.c(2384):rig_get_freq entered
rig_get_freq called vfo=VFOA
rig_get_freq(2402) called vfo=VFOA
morse_data_handler: Starting morse data handler thread
rig.c(2411) vfo=VFOA, curr_vfo=MEM
rig_get_freq(2524): vfo_opt=0, model=2
netrigctl_get_freq called, vfo=VFOA
netrigctl_transaction: called len=2
network_flush called
**2:rig_get_freq: elapsed=1ms
***2:rig.c(2661):rig_get_freq returning(0)
***2:rig.c(2384):rig_get_freq entered
rig_get_freq called vfo=VFOB
rig_get_freq(2402) called vfo=VFOB
rig.c(2411) vfo=VFOB, curr_vfo=MEM
rig_get_freq(2524): vfo_opt=0, model=2
netrigctl_get_freq called, vfo=VFOB
netrigctl_transaction: called len=2
network_flush called
**2:rig_get_freq: elapsed=0ms
***2:rig.c(2661):rig_get_freq returning(0)
***2:rig.c(5837):rig_get_split_vfo entered
**2:rig_get_split_vfo: elapsed=0ms
***2:rig.c(5861):rig_get_split_vfo returning(0)
rig_open(1540): Current split=0, tx_vfo=None
***2:rig.c(2915):rig_get_mode entered
netrigctl_set_vfo called
netrigctl_set_vfo: cmd='V VFOA
'
netrigctl_transaction: called len=7
network_flush called
netrigctl_get_mode called, vfo=VFOA
netrigctl_transaction: called len=2
network_flush called
rig_parse_mode called
netrigctl_set_vfo called
netrigctl_set_vfo: cmd='V MEM
'
netrigctl_transaction: called len=6
network_flush called
****3:cache.c(39):rig_set_cache_mode entered
****3:cache.c(153):rig_set_cache_mode returning(0)
**2:rig_get_mode: elapsed=176ms
***2:rig.c(3045):rig_get_mode returning(0)
network_flush called
***2:network.c(1552):network_multicast_publisher_start entered
network.c(1561): multicast publisher address=224.0.0.1, port=4532
network.c(1630) MULTICAST_TRANSCEIVE enabled
network.c(1636) MULTICAST_SPECTRUM enabled
***2:network.c(1688):network_multicast_publisher_start returning(0)
***2:network.c(1763):network_multicast_receiver_start entered
network.c(1773): multicast receiver address=224.0.0.2, port=4532
network.c(988): Starting multicast publisher
***2:network.c(1856):network_multicast_receiver_start returning(0)
***2:event.c(272):rig_poll_routine_start entered
network.c(1327): Starting multicast receiver
***2:event.c(312):rig_poll_routine_start returning(0)
rig.c(296):add_opened_rig entered
rig.c(308):add_opened_rig returning2(0)
rig.c(1614):rig_open returning2(0)
***2:rig.c(3381):rig_get_vfo entered
**2:rig_get_vfo: elapsed=0ms
***2:rig.c(3408):rig_get_vfo returning(0)
***2:rig.c(3381):rig_get_vfo entered
**2:rig_get_vfo: elapsed=0ms
***2:rig.c(3408):rig_get_vfo returning(0)
***2:rig.c(2915):rig_get_mode entered
event.c(85): Starting rig poll routine thread
netrigctl_get_mode called, vfo=MEM
is_networked: Can use 127.0.0.1
is_networked: Will use 192.168.1.65
netrigctl_transaction: called len=2
network_flush called
multicast_receiver: multicast binding to INADDR_ANY
rig_parse_mode called
****3:cache.c(39):rig_set_cache_mode entered
****3:cache.c(153):rig_set_cache_mode returning(0)
**2:rig_get_mode: elapsed=33ms
***2:rig.c(3045):rig_get_mode returning(0)
***2:rig.c(2384):rig_get_freq entered
rig_get_freq called vfo=MEM
rig_get_freq(2402) called vfo=MEM
rig.c(2411) vfo=MEM, curr_vfo=MEM
rig_get_freq(2524): vfo_opt=0, model=2
netrigctl_get_freq called, vfo=MEM
netrigctl_Hi Mooneer, I just tested first time and it's all OK with 2020 and 2020B selectable. I don't see a hamlib issue. Where do you see this?
I was referring to the crash in the most recent text file that was included (which sounds like it only manifests when libasan is enabled):
==532020==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000078f50 at pc 0x7f1d8de4fc11 bp 0x7f1d6d9052c0 sp 0x7f1d6d904a70
READ of size 2 at 0x602000078f50 thread T15
#0 0x7f1d8de4fc10 in __interceptor_setlocale.part.0 (/lib64/libasan.so.8+0x4fc10)
#1 0x7f1d8d10938a in netrigctl_open (/lib64/libhamlib.so.4+0x10938a)
#2 0x7f1d8d09a877 in rig_open (/lib64/libhamlib.so.4+0x9a877)That can be probably be tracked in the Hamlib project on GitHub, though. I'll go ahead and close; message here if the FreeDV does end up coming back and we can reopen/investigate further.
mdblack98
commented
6 months ago The path /lib64 indicates this is an installed package and not the 4.6 self-compiled version which will be in /usr/local/lib If you compile Hamlib yourself on a Unix/Linux system it installs by default in /usr/local
Mike W9MDB
On Thursday, March 14, 2024 at 06:52:20 PM CDT, Mooneer Salem ***@***.***> wrote: Hi Mooneer, I just tested first time and it's all OK with 2020 and 2020B selectable. I don't see a hamlib issue. Where do you see this?
I was referring to the crash in the most recent text file that was included (which sounds like it only manifests when libasan is enabled): ==532020==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000078f50 at pc 0x7f1d8de4fc11 bp 0x7f1d6d9052c0 sp 0x7f1d6d904a70 READ of size 2 at 0x602000078f50 thread T15
#1 0x7f1d8d10938a in netrigctl_open (/lib64/libhamlib.so.4+0x10938a)
#2 0x7f1d8d09a877 in rig_open (/lib64/libhamlib.so.4+0x9a877)That can be probably be tracked in the Hamlib project on GitHub, though. I'll go ahead and close; message here if the FreeDV does end up coming back and we can reopen/investigate further.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
barjac
commented
6 months ago OK yes understood. What I also noticed with libasan enabled were many reports of memory leaks after a while before the Start modem button was pressed. Would you like a report on this?
tmiw
commented
6 months ago OK yes understood. What I also noticed with libasan enabled were many reports of memory leaks after a while before the Start modem button was pressed. Would you like a report on this?
IIRC some of them are from libraries outside of FreeDV but it wouldn't hurt to take another look.
barjac
commented
5 months ago The path /lib64 indicates this is an installed package and not the 4.6 self-compiled version which will be in /usr/local/lib If you compile Hamlib yourself on a Unix/Linux system it installs by default in /usr/local Mike W9MDB
Hi Mike, Sorry I missed this, I always create packages for testing whether from git snapshots or releases to keep my machine clean. Sorry for any confusion. Cheers, Barry G4MKT
Using the ms-longer-user-messages branch (with or without the Reporter running) freedv-gui closes on hitting the Start (modem) button.
This only happens when built with lpcnetfreedv-0.5 and codec2-1.2. No idea which to blame.
With lpcnetfreedv-0.3 and codec2-1.0 there is no issue.
Attached formatted backtrace from gdb.
gdb-bt.txt
Edit: Removed clutter as the bt is linked above.