Hi Ville, Try running your reduced testcase under gdb and take a backtrace. First open your flowgraph in gnuradio companion, generate (F5) python script and then in the terminal execute.
gdb -ex=run --args python3 testcase.py when it stops in execute the "bt" command and provide the full output (gdb) bt Best Regards, Vasil On 28/10/2022 16.24, Ville Eerola wrote: > Hi all, > > I used to have a working flowgraph developed with GR 3.10.2, but after update > to GR 3.10.4 it just ends with a segmentation fault. > > Now some details: > - I'm running Ubuntu 22.04, which is kept up to date. > - GR is installed from PPA > https://ppa.launchpadcontent.net/gnuradio/gnuradio-releases/ubuntu/ jammy main > - GR was automatically updated with Software Updater (from 3.10.2 -> 3.10.4) > - The flowgraph is using a gr-fosphor (Osmosdr) spectrum display > (fosphor_qt_sink) (Two of them) > - The data comes from a Soapy BladeRF Source, which seems to initialize > correctly > - If I disable the Fosphor displays (using "Disable" in GRC), the flowgraph > runs just fine > - With the Fosphor displays enabled, the Flowgraph prints out the normal > BladeRF initialization messages, and then "Done (return code -11)". When > running the Python code from command line, instead of "Done", it prints out > "Segmentation fault (core dumped)" > > - In order to rectify this I have updated all the OOT modules from Osmocom, > which I had previously installed with: > $ cd <module directory>/ > $ rm -rf build; > $ git fetch > $ git pull > $ mkdir build; cd build > $ cmake -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_SHARED_LIBS=true ../ > $ make > $ sudo make install; sudo ldconfig > > But, this did not help > > I was able to make a reduced testcase with just a Signal Source connected to > the Fosphor Sink (Qt), and this segfaults in similar fashion to my full model. > > > Regards, Ville >
