Segfault on FreeBSD

[onno182]

I complied GNU Radio on FreeBSD succesfully, but get a segfault when running a simple .grc with a multiply block.

The .grc works fine on Pentoo.

Traceback (most recent call last): File "lesson1.py", line 165, in <module> main() File "lesson1.py", line 143, in main tb = top_block_cls() File "lesson1.py", line 112, in __init__ self.connect((self.analog_sig_source_x_0_0, 0), (self.blocks_multiply_xx_0, 1)) File "/usr/local/gnuradio/lib/python3.7/site-packages/gnuradio/gr/hier_block2.py", line 37, in wrapped func(self, src, src_port, dst, dst_port) File "/usr/local/gnuradio/lib/python3.7/site-packages/gnuradio/gr/hier_block2.py", line 100, in connect self.primitive_connect(*args) ValueError: port number 1 exceeds max of 0 Segmentation fault (core dumped)

GDB output:

'Thread 1 received signal SIGSEGV, Segmentation fault.
0x000000080c7be663 in gr::block_registry::unregister_primitive(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >) ()
from /usr/local/gnuradio/lib/libgnuradio-runtime.so.3.10.0git'

[willcode]

You should certainly be able to connect to port 1 on a multiply block without a core dump! FreeBSD is not a common platform for GNU Radio, and I don't see much related on Google in the last few years, so it may be a while before anyone else tries this out.

[marcusmueller]

This would look like a linker confusion (the backtrace showing you're in an unrelated function to the place of the segfault): @onno182 are you sure there's no older GNU Radio headers still lying around on your system?

I'm not a FreeBSD user, but if you tell us whether there are any special steps necessary to compile GNU Radio on a fresh FreeBSD VM, someone might come around to testing it!

[onno182]

I have reinstalled FreeBSD from scratch and rebuilt GNU Radio and Volk from source. The problem unfortunately remains.

The only special step for compiling with FreeBSD is to modify the CPU header file of Volk as it does not recognise FreeBSD as a supported operating system. The solution is to make the preprocessor handle it the same as Linux. Other than that all dependencies are available in the FreeBSD package system. The FindQWT cmake file also has to be modified as FreeBSD places the include and library files of QWT in different directories than where cmake looks.

Of course FreeBSD also needs the proc filesystem enabled, but this will already be done when running a GUI like Gnome or KDE anyway.

There is a GNU Radio version in the package system, but unfortunately this is broken as it tries to uninstall Gnome3.

[vishwin]

I disabled cpu_features from libvolk completely, you may want to try that.

(side note: I'm working on a ports update to 3.9)

[marcusmueller]

The only special step for compiling with FreeBSD is to modify the CPU header file of Volk as it does not recognise FreeBSD as a supported operating system. The solution is to make the preprocessor handle it the same as Linux.

Care to share that modification? Might be worth an upstreaming :)

CC: @jdemel @michaelld

[vishwin]

I tried to do that, but it's not foolproof. Our sysctls are different from Linux and macOS/Darwin, among other things, so the whole point of cpu_features in libvolk may not operate properly.

[vishwin]

Also should mention that FreeBSD's procfs is completely different than Linux procfs. A FreeBSD binary (compared to a Linux binary running via the Linuxulator) should not be reading cpuinfo from our linprocfs.

[onno182]

@vishwin The error remains with cpu_features disabled. On the other hand with it activated, volk_profile did run successfully.

[onno182]

cpu_features_macros.h.txt

@marcusmueller the patches to compile on FreeBSD are the following. Of course I do not know if the library functions correctly given the previous comments, although disable cpu_features does not fix the problem.

--- ../cpu_features/include/cpu_features_macros.h.orig	2021-06-06 13:08:05.165204000 +0200
+++ ../cpu_features/include/cpu_features_macros.h	2021-06-06 13:14:18.621659000 +0200
@@ -12,6 +12,8 @@
 // See the License for the specific language governing permissions and
 // limitations under the License.
 
+#include <sys/param.h>
+
 #ifndef CPU_FEATURES_INCLUDE_CPU_FEATURES_MACROS_H_
 #define CPU_FEATURES_INCLUDE_CPU_FEATURES_MACROS_H_
 
@@ -81,6 +83,10 @@
 
 #if (defined(__apple__) || defined(__APPLE__) || defined(__MACH__))
 #define CPU_FEATURES_OS_DARWIN
+#endif
+
+#if (defined(__FreeBSD__))
+#define CPU_FEATURES_OS_FREEBSD
 #endif
 
 ////////////////////////////////////////////////////////////////////////////////


--- ../cpu_features/src/cpuinfo_x86.c.orig	2021-06-06 13:03:42.821434000 +0200
+++ ../cpu_features/src/cpuinfo_x86.c	2021-06-06 13:15:05.460556000 +0200
@@ -106,6 +106,10 @@
 #error "Darwin needs support for sysctlbyname"
 #endif
 #include <sys/sysctl.h>
+#elif defined(CPU_FEATURES_OS_FREEBSD) 
+#include "internal/filesystem.h"        // Needed to parse /proc/cpuinfo
+#include "internal/stack_line_reader.h"  // Needed to parse /proc/cpuinfo
+#include "internal/string_view.h"        // Needed to parse /proc/cpuinfo
 #else
 #error "Unsupported OS"
 #endif  // CPU_FEATURES_OS
@@ -1240,6 +1244,31 @@
   features->sse4_1 = GetDarwinSysCtlByName("hw.optional.sse4_1");
   features->sse4_2 = GetDarwinSysCtlByName("hw.optional.sse4_2");
 #elif defined(CPU_FEATURES_OS_LINUX_OR_ANDROID)
+  // Handling Linux platform through /proc/cpuinfo.
+  const int fd = CpuFeatures_OpenFile("/proc/cpuinfo");
+  if (fd >= 0) {
+    StackLineReader reader;
+    StackLineReader_Initialize(&reader, fd);
+    for (;;) {
+      const LineResult result = StackLineReader_NextLine(&reader);
+      const StringView line = result.line;
+      StringView key, value;
+      if (CpuFeatures_StringView_GetAttributeKeyValue(line, &key, &value)) {
+        if (CpuFeatures_StringView_IsEquals(key, str("flags"))) {
+          features->sse = CpuFeatures_StringView_HasWord(value, "sse");
+          features->sse2 = CpuFeatures_StringView_HasWord(value, "sse2");
+          features->sse3 = CpuFeatures_StringView_HasWord(value, "sse3");
+          features->ssse3 = CpuFeatures_StringView_HasWord(value, "ssse3");
+          features->sse4_1 = CpuFeatures_StringView_HasWord(value, "sse4_1");
+          features->sse4_2 = CpuFeatures_StringView_HasWord(value, "sse4_2");
+          break;
+        }
+      }
+      if (result.eof) break;
+    }
+    CpuFeatures_CloseFile(fd);
+  }
+#elif defined(CPU_FEATURES_OS_FREEBSD)
   // Handling Linux platform through /proc/cpuinfo.
   const int fd = CpuFeatures_OpenFile("/proc/cpuinfo");
   if (fd >= 0) {
[cpuinfo_x86.c.txt](https://github.com/gnuradio/gnuradio/files/6604114/cpuinfo_x86.c.txt)

[onno182]

@marcusmueller sorry for the messy post (cant upload patch files here, but see .txt file for patch)

[marcusmueller]

@onno182 absolutely nothing to be sorry about!

I'm taking the freedom to transfer this to the VOLK issue tracker, for now. (We can always transfer back, or just open more issues here, and I feel that this is first fixing VOLK, then we can come back to GNU Radio)

[jdemel]

Is this issue still about the SegFault?
If so, is there a way to reproduce this issue with just VOLK without GNU Radio? Or is this not an issue at all

[..] The error remains with cpu_features disabled. On the other hand with it activated, volk_profile did run successfully.

Or is this issue about CPU feature detection now? The topic seems to change.
In that case, does cpu_features need to be patched, or is it sufficient to rely on Linuxulator?

[onno182]

@jdemel There is still a segfault in GNU Radio, also when disabling cpu_features.

I do not believe the segfault is in Volk, which compiles fine and also creates the profiles without issues. However, in order to get Volk to compile on FreeBSD some changes are necessary (see above). marcusmueller asked me to state which changes exactly were necessary to forward to Volk team.

The issue of segfault remains. I have no idea what is the cause. GNU Radio seems to work with some sketches but others not. The fault seems to occur when dealing with a block with multiple inputs, for instance, when adding a multiply block which receives two inputs and outputs one.

[marcusmueller]

Hi, to clarify: I've migrated this to VOLK because the code you've included makes VOLK work, and I needed @jdemel to be aware of it, and hope it's something that we can either find a workaround to in VOLK or find a way to upstream to cpu_features. But I don't know which is desirable here!

All in all, might have been a bit fast with the migration button. If you think this is wrong here, Johannes can migrate back to GNU Radio.

[vishwin]

I'll have a play once I have my copy of GNU Radio 3.9.1.0 to dogfood before sending out the call for testing in our ports tree. I will be testing with Python 3.9 compared to the OP's Python 3.7.

In that case, does cpu_features need to be patched, or is it sufficient to rely on Linuxulator?

Don't even think about using the Linuxulator, unless we're dealing with an actual Linux binary.

[onno182]

@vishwin just as a side note: My reason for compiling GNU Radio from source is because the binary package in ports seems to be broken as it uninstalls Gnome3. Also my version of GNU Radio is running with Python 3.7 as it is not possible to satisfy dependencies with binary packages from Python 3.9.

[vishwin]

Yes, the dependency mess is a big reason why I'm updating the port. (I'm a committer)