Crashing when enabling Baseband NR on ArchLinux #20
Labels
bug
Something isn't working
Comments
|
based on your exception information, however, I would like to reproduce it. Please turn off baseband NR, record around 10 seconds of baseband using recorder, and attach wav here or somewhere else. That would help. |
|
(i deleted my prev comment after reading the specs, thank you) |
|
to catch it, try to build sdrpp in RelWithDebInfo mode using cmake. Tweak Arch linux AUR, or build manually. Then use gdb to run sdrpp: $ gdb /path/to/sdrpp Meanwhile I will add overflow protection. 5700x should be fine however. |
|
just for reference, it adds +30% of CPU usage on Mac M2 for bandwidth=2.4MSPS (rtl sdr) using release build. |
|
I appreciate your time, thank you. I have compiled with RelWithDebInfo. I included bt, but I also included all of the log prior to as well (extra context could be useful?) As for baseband recording: I'm in full acknowledgement that there might be something odd with my setup, as I've had to do some hacky things for other stuff in the past and this may be the root cause of some other issues... So by all means, if this is my fault, you have permission to admonish me for wasting your time, preferably upon revealing what you're seeing that could indicate hacky shenanigans... But that Baseband NR is amazing on my other devices, an absolute game changer that I hope to use on my big rig. AMENDED: With the new CPU usage indicator in the latest update, CPU utilization shows 100% within a half second.. and CPU does go to 100% on the core it's using, if that's useful info. |
|
inside your stack trace it is unfortunately impossible to detect where exactly the out of bounds error happened. For some reason, debug information is missing in your stack traces. For example, #4 0x00007ffff68d2d60 in std::__glibcxx_assert_fail (file=, line=, function=, condition=) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/assert_fail.cc:41 ^^^^^^^^^^^^^^^^^^^^ this address is not translated to line number or symbol. Looks like you're running release version. Please build with cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo Ensure it has debug info. In general, it has a lot of array (vector) access using operator[] to check them all. I tried to simulate slow CPU by adding various delay loops, but it worked in my case all time. HOWEVER, I added slow cpu check, NR will switch off automatically when CPU usage is too high for two 400 msec iterations in row. Hope it doesn't spoil all enjoyment. |
|
also I optimized NR by 10-15 %, but looks lit it was already in your last build that you tested. |
|
That's definitely interesting, as I have certainly added it to the PKGBUILD. I'm going to wipe out that whole /usr/lib/sdrpp folder and try again, maybe it's a stale old library. AMENDED: No luck. Also it's apparently happening too quick for the two 400ms iterations to turn it off.. i can manually flip it on and right back off and hear it engage and disengage.. it's so bizarre. As for the debug info, still no dice.. I'll further amend this as I poke around and see if I can figure out why even with this flag it's refusing to give the correct symbols. I'll build manually without the pkgbuild, since I'm just recycling the original sdrpp PKGBUILD and I wonder if some optimizations are stripping them out after the fact or such. AMENDED 2: Well, I rebuilt manually and got backtrace to show more info, but realized that my default of -O3 was stripping out some symbols, so forced a rebuild with -O0 to keep the debug symbols and...... It doesn't crash... Huh. I'll rebuild with -O2 and see if it's happy with that, as obviously -O3 can be problematic (as we're seeing here) |
|
User error: systemwide -O3 override causes crashes, default -O2 does not. Modifying the PKGBUILD to override the systemwide override back to -O2 fixes the crashes. I will close this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FIRST: Before reporting any bug, make sure that the bug you are reporting has not been reported before. Also, try to use the nightly version if possible in case I've already fixed the bug.
Hardware
Software
Bug Description
A clear description of the bug.
Enabling Baseband NR plays for approximately 1 second, then freezes and crashes. Running in terminal produces this error:
Sampling piece... srate=912000 Slen=18240 nFFT=36480
/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator [with _Tp = int; _Alloc = std::allocator; reference = int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Aborted (core dumped)
Running in Ubuntu 22.04 Distrobox allows Baseband NR to work, but causes very bad audio stuttering. I'm just trying to identify where to even look to fix this, as it's seemingly an Arch issue (issue with the latest g++ perhaps?).. If you point me in a direction, I'd be grateful.
Steps To Reproduce
Additional info
Add any other relevant information.
The text was updated successfully, but these errors were encountered: