Allow unlimited length user messages while still truncating their display by default.

[tmiw]

This PR lifts the 15 character limit on user messages, allowing users to send much longer messages as desired. However, display of the longer messages is still truncated to 15 characters by default (to keep the behavior the same for smaller displays); to view the full message, you need to select the user in the list and hover over the column. For example:

[tmiw]

@barjac, might want to try this and make sure it doesn't introduce any weird problems. (I'm currently traveling for another week or so, so my availability for testing is limited.)

[Tyrbiter]

Initial testing seems to show this is working here, I will play around some more and see how it goes.

[barjac]

Initial testing seems to show this is working here, I will play around some more and see how it goes.

Likewise.

I'm finding the display of the full message tooltip is a bit intermittent when hovering over the message, not sure whether this could be made more persistent, as in once displayed hold it for a few seconds even if the mouse moves a little.

Also: I think a right click option would be useful to save a message to the clipboard. Quite often we find ourselves discussing the content of specific web sites (bug in github etc.) and trying to communicate a URL over the air, this would be ideal in that situation.

This could be very annoying to users on earlier versions for whatever reason. Could the messages be truncated when sent to users with detected incompatible versions (maybe impossible but just thinking out loud ;)

To clarify the above I noticed yesterday when you and Mooneer were putting up test messages that my older version was running out of screen width. No doubt when this feature is released some people will push the 'no width limit' boundaries and wipe out all columns to the right of the Msg column for 'older version' users.

[Tyrbiter]

Something I have just noticed is that I need to highlight the row before I can see the full tooltip, and yes it's a bit picky about displaying the tip consistently. I would guess that is DE-dependent in some way, or wxWidgets gets its fingers in the pie too.

Right click to save another's message to the clipboard sounds a useful feature even if something I might only use occasionally.

[tmiw]

I'm finding the display of the full message tooltip is a bit intermittent when hovering over the message, not sure whether this could be made more persistent, as in once displayed hold it for a few seconds even if the mouse moves a little.

The latest commit should hopefully fix this. Or at least it does on macOS, anyway. (Weirdly, I didn't see this issue on Windows before the latest commit. Not sure why.)

Also: I think a right click option would be useful to save a message to the clipboard. Quite often we find ourselves discussing the content of specific web sites (bug in github etc.) and trying to communicate a URL over the air, this would be ideal in that situation.

Will need to think about this more as I'm not sure it'd be obvious to other users that right-clicking that column copies text to the clipboard.

This could be very annoying to users on earlier versions for whatever reason. Could the messages be truncated when sent to users with detected incompatible versions (maybe impossible but just thinking out loud ;)

I think it might be possible to truncate on the server side. However, the version field is actually free-form text (albeit in a known format for the official FreeDV clients), not to mention that what's currently a single line to broadcast that message will likely turn into more involved logic. We can monitor how quickly people upgrade to the next release and if it turns out that it's taking a while, we can revisit this.

[Tyrbiter]

The flicker fix on my Linux system is a bit better, but still requires the row to be highlighted.

Not sure how many tools wxWidgets provides for this sort of control.

[tmiw]

The flicker fix on my Linux system is a bit better, but still requires the row to be highlighted.

Shouldn't need the row selected anymore as of the latest commit.

[Tyrbiter]

The flicker fix on my Linux system is a bit better, but still requires the row to be highlighted.

Shouldn't need the row selected anymore as of the latest commit.

Seems better, however now showing me as Rx only...

Which turns out to be various audio devices disappearing or being deselected on the transmit tab of the audio options. Odd, but now fixed again. Can't see how the portaudio error change could do that.

[barjac]

Also: I think a right click option would be useful to save a message to the clipboard. Quite often we find ourselves discussing the content of specific web sites (bug in github etc.) and trying to communicate a URL over the air, this would be ideal in that situation.

Will need to think about this more as I'm not sure it'd be obvious to other users that right-clicking that column copies text to the clipboard.

I was thinking about a context menu with option to save to clipboard.

The 'hover only' is now reliable here - much better than having to select first :)

[tmiw]

Added context menu to allow copying to the clipboard. Note that this menu will only appear when hovering over a message.

[Tyrbiter]

The sequence I get is:

Hover pointer over message, tooltip appears. Right click, tooltip disappears. Second right click, row highlights. Third right click shows context menu. Message is correctly copied to clipboard on clicking the menu item.

There's something a bit odd about the way this is handled in wxWidgets, or at least that's what seems to be the case.

[tmiw]

The sequence I get is:

Hover pointer over message, tooltip appears. Right click, tooltip disappears. Second right click, row highlights. Third right click shows context menu. Message is correctly copied to clipboard on clicking the menu item.

There's something a bit odd about the way this is handled in wxWidgets, or at least that's what seems to be the case.

I did a bit more tweaking and I think this is fixed now.

[Tyrbiter]

Yes, definitely fixed, thanks @tmiw

I looked at the patch, I have no idea what you did or how you know to do it. Very impressed!

[barjac]

Yes, definitely fixed, thanks @tmiw

No not for me at #2cd00c0. :( I see the behaviour you described earlier. It takes 3 right clicks to get the context menu to appear permanently so it can be clicked. Yet all 3 clicks save the message to the clipboard. If the mouse is moved between clicks it never gets to correctly display the context menu.

I just made a video showing this. Hmm.. it won't take .ogv so I renamed it to .mov and it plays OK in vlc. It includes sound. https://github.com/drowe67/freedv-gui/assets/1324702/99e0c4a6-7b90-47ec-8205-a9e6ac312f2e

[Tyrbiter]

That's unexpected. I have checked again, I don't see this any more. GNOME Wayland 45 on Fedora 39. I know that you use KDE Plasma @barjac

[tmiw]

I just installed Plasma on my Fedora 39 VM and that seems to behave the same as GNOME for me, FWIW. Maybe I'm missing something?

[tmiw]

I was made aware yesterday that @barjac uses Mageia. Unfortunately my normal test machine is in the shop and I only have access to an ARM one at the moment, so further testing will have to wait (unless there is in fact an aarch64 Mageia release that I missed when looking around on the website?)

That said, I wouldn't think there'd be that much of a difference between different distros when using the same desktop environment. Might be worth trying a resync and a full rebuild and making sure there's nothing old still sticking around?

[barjac]

Nothing gets 'left around' here. I always build test 'packages' in the same chrooted environment that Mageia uses for official builds. Every test package is installed using the distro package manager. The build chroot only has a minimal package set plus the build requires for the package being built.

I have tested builds for both the current stable Mageia-9 x86_64 and also unstable development version Mageia-10 x86_64. Both behave exactly the same. Mga9 has Plasma-5 Mga10 has Plasma-6. Edit: Testing in Mga10 x86_64 after logging in using IceWM I see the same behaviour. Edit: Testing in Mga9 x86_64 using LXQt or OpenBox it is still the same.

I have realized that if 'right click hold' is used, the 'Copy message' box stays as long as the mouse button is depressed. (This does copy the message) Maybe this helps to diagnose?

I have just built a package of this branch for aarch64 as I do have a Mageia-9 system on a RPi4. There is no easy reliable way to install Mageia to a RPi4 yet as it is still a WIP.

On the RPi4 using LXQt desktop, a short right click does show the 'Copy message' box permanently until it is either left clicked or a left click elsewhere is made. Left clicking the box does save the message to the clipboard, so it appears to work correctly on the RPi using LXQt D.E.

My only tentative conclusion so far is that the problem is related to x86 builds, irrespective of D.E.

[Tyrbiter]

Here is the list of shared objects for freedv on my Fedora 39 system:

ldd /usr/bin/freedv linux-vdso.so.1 (0x00007ffdf31c6000) libcodec2.so.1.2 => /lib64/libcodec2.so.1.2 (0x00007f2f09eb1000) libpulse.so.0 => /lib64/libpulse.so.0 (0x00007f2f09e5f000) libhamlib.so.4 => /lib64/libhamlib.so.4 (0x00007f2f09200000) libsamplerate.so.0 => /lib64/libsamplerate.so.0 (0x00007f2f09091000) libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007f2f09de1000) libwx_gtk3u_core-3.2.so.0 => /lib64/libwx_gtk3u_core-3.2.so.0 (0x00007f2f08800000) libwx_baseu-3.2.so.0 => /lib64/libwx_baseu-3.2.so.0 (0x00007f2f08400000) libwx_gtk3u_aui-3.2.so.0 => /lib64/libwx_gtk3u_aui-3.2.so.0 (0x00007f2f08758000) libwx_gtk3u_propgrid-3.2.so.0 => /lib64/libwx_gtk3u_propgrid-3.2.so.0 (0x00007f2f082f0000) libspeexdsp.so.1 => /lib64/libspeexdsp.so.1 (0x00007f2f0a217000) liblpcnetfreedv.so.0.5 => /lib64/liblpcnetfreedv.so.0.5 (0x00007f2f07400000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2f07000000) libm.so.6 => /lib64/libm.so.6 (0x00007f2f08677000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2f0906d000) libc.so.6 => /lib64/libc.so.6 (0x00007f2f06e1e000) libpulsecommon-16.1.so => /usr/lib64/pulseaudio/libpulsecommon-16.1.so (0x00007f2f0737b000) libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f2f07326000) libusb-1.0.so.0 => /lib64/libusb-1.0.so.0 (0x00007f2f082d1000) libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f2f072cc000) libgsm.so.1 => /lib64/libgsm.so.1 (0x00007f2f08668000) libFLAC.so.12 => /lib64/libFLAC.so.12 (0x00007f2f07266000) libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007f2f06def000) libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x00007f2f06d44000) libopus.so.0 => /lib64/libopus.so.0 (0x00007f2f06ce8000) libogg.so.0 => /lib64/libogg.so.0 (0x00007f2f09dd3000) libmpg123.so.0 => /lib64/libmpg123.so.0 (0x00007f2f06c8b000) libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007f2f06c13000) libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007f2f06400000) libgdk-3.so.0 => /lib64/libgdk-3.so.0 (0x00007f2f06305000) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f2f0612f000) libpangocairo-1.0.so.0 => /lib64/libpangocairo-1.0.so.0 (0x00007f2f07255000) libgdk_pixbuf-2.0.so.0 => /lib64/libgdk_pixbuf-2.0.so.0 (0x00007f2f06be5000) libpango-1.0.so.0 => /lib64/libpango-1.0.so.0 (0x00007f2f060c5000) libcairo.so.2 => /lib64/libcairo.so.2 (0x00007f2f05f8e000) libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2f05e44000) libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f2f05de4000) libX11.so.6 => /lib64/libX11.so.6 (0x00007f2f05c9d000) libSM.so.6 => /lib64/libSM.so.6 (0x00007f2f06bdb000) libxkbcommon.so.0 => /lib64/libxkbcommon.so.0 (0x00007f2f05c54000) libXtst.so.6 => /lib64/libXtst.so.6 (0x00007f2f06bd3000) libpangoft2-1.0.so.0 => /lib64/libpangoft2-1.0.so.0 (0x00007f2f05c3a000) libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f2f05beb000) libSDL2-2.0.so.0 => /lib64/libSDL2-2.0.so.0 (0x00007f2f05a15000) libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f2f059dc000) libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007f2f05959000) libtiff.so.5 => /lib64/libtiff.so.5 (0x00007f2f058d0000) libz.so.1 => /lib64/libz.so.1 (0x00007f2f058b6000) libsecret-1.so.0 => /lib64/libsecret-1.so.0 (0x00007f2f05854000) libpcre2-32.so.0 => /lib64/libpcre2-32.so.0 (0x00007f2f057ce000) /lib64/ld-linux-x86-64.so.2 (0x00007f2f0a276000) libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f2f057a3000) libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f2f056b0000) libasyncns.so.0 => /lib64/libasyncns.so.0 (0x00007f2f056a8000) libudev.so.1 => /lib64/libudev.so.1 (0x00007f2f05670000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f2f0563b000) libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f2f05634000) libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f2f05526000) libfribidi.so.0 => /lib64/libfribidi.so.0 (0x00007f2f05507000) libcairo-gobject.so.2 => /lib64/libcairo-gobject.so.2 (0x00007f2f054fc000) libatk-1.0.so.0 => /lib64/libatk-1.0.so.0 (0x00007f2f054d2000) libepoxy.so.0 => /lib64/libepoxy.so.0 (0x00007f2f053af000) libXi.so.6 => /lib64/libXi.so.6 (0x00007f2f0539c000) libatk-bridge-2.0.so.0 => /lib64/libatk-bridge-2.0.so.0 (0x00007f2f0535f000) libcloudproviders.so.0 => /lib64/libcloudproviders.so.0 (0x00007f2f05345000) libtracker-sparql-3.0.so.0 => /lib64/libtracker-sparql-3.0.so.0 (0x00007f2f05267000) libwayland-client.so.0 => /lib64/libwayland-client.so.0 (0x00007f2f05256000) libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f2f0524e000) libwayland-cursor.so.0 => /lib64/libwayland-cursor.so.0 (0x00007f2f05244000) libwayland-egl.so.1 => /lib64/libwayland-egl.so.1 (0x00007f2f06bce000) libXext.so.6 => /lib64/libXext.so.6 (0x00007f2f05230000) libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f2f05223000) libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f2f0521e000) libXcomposite.so.1 => /lib64/libXcomposite.so.1 (0x00007f2f05219000) libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f2f0520c000) libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f2f05207000) libmount.so.1 => /lib64/libmount.so.1 (0x00007f2f051b4000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f2f05187000) libthai.so.0 => /lib64/libthai.so.0 (0x00007f2f0517c000) libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f2f050ac000) libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f2f050a0000) libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f2f0508f000) libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f2f0508a000) libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f2f04fda000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f2f04f3f000) libffi.so.8 => /lib64/libffi.so.8 (0x00007f2f04f2f000) libICE.so.6 => /lib64/libICE.so.6 (0x00007f2f04f0f000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2f04f05000) libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f2f04d91000) libwebp.so.7 => /lib64/libwebp.so.7 (0x00007f2f04d23000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f2f04c67000) libLerc.so.4 => /lib64/libLerc.so.4 (0x00007f2f04bd8000) libjbig.so.2.1 => /lib64/libjbig.so.2.1 (0x00007f2f04bca000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f2f04a90000) libXau.so.6 => /lib64/libXau.so.6 (0x00007f2f04a8a000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f2f04a80000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f2f04a5c000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f2f04a29000) libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f2f04a08000) libatspi.so.0 => /lib64/libatspi.so.0 (0x00007f2f049cd000) libjson-glib-1.0.so.0 => /lib64/libjson-glib-1.0.so.0 (0x00007f2f049a1000) libsqlite3.so.0 => /lib64/libsqlite3.so.0 (0x00007f2f0484b000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f2f0480f000) libdatrie.so.1 => /lib64/libdatrie.so.1 (0x00007f2f04806000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f2f047f2000) libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f2f047e4000) libsharpyuv.so.0 => /lib64/libsharpyuv.so.0 (0x00007f2f047da000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f2f047b4000) libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f2f04791000)

Maybe compare and see if there are any .so version differences relative to your distro.

The other question is how often does Mageia update packages? I have just noticed that plasma 5 is about to get a new bugfix version on Fedora, the packages appeared today in pending->updates-testing.

[tmiw]

Apparently aarch64 Ubuntu 22.04 and KDE Plasma was the right combo. Hopefully the changes I just pushed help; they seem to for me.

[Tyrbiter]

Apparently aarch64 Ubuntu 22.04 and KDE Plasma was the right combo. Hopefully the changes I just pushed help; they seem to for me.

Still working for me here, the only noticeable change is that the 'Copy message' button appears slightly to the left of the message instead of to the right, which is what the commit says in the comment. It's actually slightly easier to click without moving the mouse. Over to @barjac :)

[barjac]

That has fixed it - it's now working as tyrbiter described. Thanks Mooneer as always, great work finding that!

Tested OK so far in Mga9 x86_64 and Mga9 aarch64. Just now Mga10 segfaults on start of modem - will investigate later :\

[barjac]

Here is the list of shared objects for freedv on my Fedora 39 system:

--snip--

I got about half way through checking and there are quite a few differences. One or two stand out as being a bit odd:

In Fedora I don't see libsioclient, libnotify, libicudata, libicuuc nor libpixman.

In Mageia I don't see libgsm, libLerc nor libreadline.

There may be others but that is as far as I got manually, I should have written a script to do a proper full comparison but it didn't seem worth the effort at the time :\

Thoughts anyone?

[Tyrbiter]

Here is the list of shared objects for freedv on my Fedora 39 system:

--snip--

I got about half way through checking and there are quite a few differences. One or two stand out as being a bit odd:

In Fedora I don't see libsioclient, libnotify, libicudata, libicuuc nor libpixman.

A few comments:

libsioclient is not (yet) available as a Fedora rpm so it gets downloaded and built during the freedv build, maybe one day @hobbes1069 will fix that up, I think he had some problems with the Fedora build system. I know you don't do that in your systems.

libnotify and libnotify-devel are installed here but not linked in during the build, I don't think that it's a buildrequire either.

libicudata.so. is installed, again appears not to be mentioned in the spec file, the same is true for libicuuc.so.

Not sure exactly what they do related to freedv

In Mageia I don't see libgsm, libLerc nor libreadline.

There may be others but that is as far as I got manually, I should have written a script to do a proper full comparison but it didn't seem worth the effort at the time :\

Thoughts anyone?

Distros differ I suppose.

[tmiw]

That has fixed it - it's now working as tyrbiter described. Thanks Mooneer as always, great work finding that!

Tested OK so far in Mga9 x86_64 and Mga9 aarch64. Just now Mga10 segfaults on start of modem - will investigate later :\

OK to merge, then? Will another issue get created for Mga10 if it ends up being something FreeDV related?

[barjac]

That has fixed it - it's now working as tyrbiter described. Thanks Mooneer as always, great work finding that! Tested OK so far in Mga9 x86_64 and Mga9 aarch64. Just now Mga10 segfaults on start of modem - will investigate later :\

OK to merge, then? Will another issue get created for Mga10 if it ends up being something FreeDV related?

Yes - it is fine in stable systems and we expect issues in Cauldron.

[barjac]

Following IRC chat about libasan errors these are terminal outputs from building and running of freedv.

Output from freedv build_linux.sh asan_build_freedv1.txt

Output running freedv and starting modem asan_run_freedv1.txt

[tmiw]

I created https://github.com/drowe67/codec2/issues/43 for the build error. This looks like it's a failure in the test programs and not in the library itself.

As for the other one, the following makes me think it's some sort of locale issue:

0x6020000ae930 is located 0 bytes inside of 12-byte region [0x6020000ae930,0x6020000ae93c)
freed by thread T15 here:
    #0 0x7f19034b7a68 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb7a68)
    #1 0x7f18ffe5b181 in __GI_setlocale (/lib64/libc.so.6+0x2d181)

previously allocated by thread T0 here:
    #0 0x7f19034b8d8f in __interceptor_malloc (/lib64/libasan.so.8+0xb8d8f)
    #1 0x7f18ffec5b19 in __strdup (/lib64/libc.so.6+0x97b19)

Might be worth running LC_ALL=C ./freedv and seeing if that works any better.

[barjac]

Thanks for creating the codec2 bug. LC_ALL=C does not stop the crash on staring modem but it does look a bit different.

asan_output2.txt

[tmiw]

Thanks for creating the codec2 bug. LC_ALL=C does not stop the crash on staring modem but it does look a bit different.

asan_output2.txt

Hmm, I wonder if this change I did as part of the Codec2 PR I just opened for the build issue you reported will resolve that. What happens if you disable multiple receive and set FreeDV to something other than 800XA?

[barjac]

I tried to build freedv using build_linux.sh edited to use codec2 ms-libasan-crash-fix branch but it aborts with dynamic-stack-buffer-overflow using:

CFLAGS=-fsanitize=address LDFLAGS=-fsanitize=address ./build_linux.sh > ../asan_build_output3.txt 2>&1

asan_build_output3.txt

What happens if you disable multiple receive and set FreeDV to something other than 800XA?

Testing with a previous successful build_linux.sh build does run the modem without crash. Reproduced several times reliably with multi RX on and off. Always crashes with multi-RX on. TX mode was set to 700e for the tests.

[tmiw]

I tried to build freedv using build_linux.sh edited to use codec2 ms-libasan-crash-fix branch but it aborts with dynamic-stack-buffer-overflow using:

CFLAGS=-fsanitize=address LDFLAGS=-fsanitize=address ./build_linux.sh > ../asan_build_output3.txt 2>&1

asan_build_output3.txt

What happens if you disable multiple receive and set FreeDV to something other than 800XA?

Testing with a previous successful build_linux.sh build does run the modem without crash. Reproduced several times reliably with multi RX on and off. Always crashes with multi-RX on. TX mode was set to 700e for the tests.

Try that codec2 build again. I was testing without LPCNet compiled in before and missed that failure.

[barjac]

Yes it now builds OK. Running without LC_ALL=C it crashes:

freedv_run_output4.txt

Running with radio off and LC_ALL=C it continues to run:

freedv_run_output5.txt

Running with radio on and LC_ALL=C it crashes:

freedv_run_output6.txt

If I run it with radio off I can stop and start the modem at will without a crash. I get the hamlib communication timeout messages but still no crash. If I then stop the modem, turn on the radio and start the modem the radio beeps indicating that it is communicating but then it crashes.:

freedv_run_output7.txt

All the above with multi RX on. 700E TX mode.

OK bed time here now :) ZZzzz

[tmiw]

One more try with the latest? I believe I was able to get all the tests that were failing with libasan enabled to pass.

[barjac]

I don't think there is any change. Build: CFLAGS=-fsanitize=address LDFLAGS=-fsanitize=address ./build_linux.sh > ../asan_build_output6.txt 2>&1

asan_build_output6.txt

Run: With multi RX on: [baz@jackodesktop src]$ LC_ALL=C ./freedv > ../freedv_run_output9.txt 2>&1

freedv_run_output9.txt

The modem runs for longer after starting it with LC_ALL=C maybe 500ms.

With multi RX off: ...and LC_ALL=C it runs fine except for the reported mem leaks.

freedv_run_output12.txt

Without LC_ALL=C it crashes:

freedv_run_output13.txt

[tmiw]

Can you create a separate issue in this project for the memory leaks? I think those are definitely in the application and not Codec2.

Also, try the latest from Codec2 again and see if that helps at all?

[barjac]

No real change. With radio off (multi or single) the modem runs until hamlib times out (no crash). With radio on in single RX mode the GUI appears normal and RX and TX work. (mem leaks reported):

freedv_run_output7b.txt

With radio on in multi RX mode it crashes:

freedv_run_output7d.txt

I have the other outputs from all 4 cases if they are needed.

In view of David's comment in codec2 PR#43 do you still want the leak bug reported?

[tmiw]

With radio on in multi RX mode it crashes:

Can you duplicate the crash without AddressSanitizer built in? If so, how often?

In view of David's comment in codec2 PR#43 do you still want the leak bug reported?

Yeah, some of the leaks are indeed in this project and not on codec2. For example:

Direct leak of 160 byte(s) in 1 object(s) allocated from:
    #0 0x7f87ca6b9888 in operator new(unsigned long) (/lib64/libasan.so.8+0xb9888)
    #1 0x43c840 in MainFrame::startRxStream() /home/baz/BLD/BLD_MgaX_FREEDV/freedv-git/SOURCES/freedv-1.9.9-202403221300-3e864/src/main.cpp:2949
    #2 0x4371d6 in MainFrame::performFreeDVOn_() /home/baz/BLD/BLD_MgaX_FREEDV/freedv-git/SOURCES/freedv-1.9.9-202403221300-3e864/src/main.cpp:2053
    #3 0x438494 in operator() /home/baz/BLD/BLD_MgaX_FREEDV/freedv-git/SOURCES/freedv-1.9.9-202403221300-3e864/src/main.cpp:2278
    #4 0x44eb53 in __invoke_impl<void, MainFrame::OnTogBtnOnOff(wxCommandEvent&)::<lambda()> > /usr/include/c++/12/bits/invoke.h:61
    #5 0x44ead9 in __invoke<MainFrame::OnTogBtnOnOff(wxCommandEvent&)::<lambda()> > /usr/include/c++/12/bits/invoke.h:96
    #6 0x44ea33 in _M_invoke<0> /usr/include/c++/12/bits/std_thread.h:279
    #7 0x44e837 in operator() /usr/include/c++/12/bits/std_thread.h:286
    #8 0x44e135 in _M_run /usr/include/c++/12/bits/std_thread.h:231
    #9 0x7f87c70d6562 in execute_native_thread_routine (/lib64/libstdc++.so.6+0xd6562)

[barjac]

With radio on in multi RX mode it crashes:

Can you duplicate the crash without AddressSanitizer built in? If so, how often?

No, I have not seen any crashes recently using master which I normally run from locally built packages.

In view of David's comment in codec2 PR#43 do you still want the leak bug reported?

Yeah, some of the leaks are indeed in this project and not on codec2. For example:

Direct leak of 160 byte(s) in 1 object(s) allocated from:
    #0 0x7f87ca6b9888 in operator new(unsigned long) (/lib64/libasan.so.8+0xb9888)
    #1 0x43c840 in MainFrame::startRxStream() /home/baz/BLD/BLD_MgaX_FREEDV/freedv-git/SOURCES/freedv-1.9.9-202403221300-3e864/src/main.cpp:2949
    #2 0x4371d6 in MainFrame::performFreeDVOn_() /home/baz/BLD/BLD_MgaX_FREEDV/freedv-git/SOURCES/freedv-1.9.9-202403221300-3e864/src/main.cpp:2053
    #3 0x438494 in operator() /home/baz/BLD/BLD_MgaX_FREEDV/freedv-git/SOURCES/freedv-1.9.9-202403221300-3e864/src/main.cpp:2278
    #4 0x44eb53 in __invoke_impl<void, MainFrame::OnTogBtnOnOff(wxCommandEvent&)::<lambda()> > /usr/include/c++/12/bits/invoke.h:61
    #5 0x44ead9 in __invoke<MainFrame::OnTogBtnOnOff(wxCommandEvent&)::<lambda()> > /usr/include/c++/12/bits/invoke.h:96
    #6 0x44ea33 in _M_invoke<0> /usr/include/c++/12/bits/std_thread.h:279
    #7 0x44e837 in operator() /usr/include/c++/12/bits/std_thread.h:286
    #8 0x44e135 in _M_run /usr/include/c++/12/bits/std_thread.h:231
    #9 0x7f87c70d6562 in execute_native_thread_routine (/lib64/libstdc++.so.6+0xd6562)

OK I will do it ASAP.

[barjac]

OK I will do it ASAP.

Sorry it didn't happen, just too busy with family etc. over the holiday and I now see that you already fixed it. :)