Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)

[Cinaed Simson]

Hi Vasil - when I checked out gr-fosphor from

  https://github.com/osmocom/gr-fosphor.git

it appeared the only versions supported using were

  3.7, 3.8

It's possible it's supported under under master - I didn't try.

Or maybe you have different author.

-- Cinaed


On 10/28/22 06: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
> --
> Ville Eerola
> ville.eerola@iki.fi
> 050-4804435