Hi William,

generally, your CMake code looks right. So, I can't really rule out that
the segfaults happens due to the fact that if you're running a python
GNU Radio program, as you noted, your C++/python interface might be
accessing python structures that the python runtime already uses. I
honestly can't tell; maybe a backtrace would enlighten us (basically,
`gdb --args python2 yourflowgraph.py`; `run` (crash); `backtrace`)?
Generally, what you're doing might be a bit problematic; from the
matplotlib-cpp README:

> This library is not thread safe. Protect all concurrent access with a
mutex. Sadly, this is not easy to fix since it is not caused by the
library itself but by the python interpreter, which is itself not
thread-safe.

and general_work is running in a thread that is *separate* from the main
python thread, whilst this looks like it assumes it is able to spawn the
main python thread. To make matters worse, I can barely fathom what
happens if c++->matplotlib->c++->Qt happens…

What's the other lib that causes segfaults?

Best regards,
Marcus


On 26.07.2017 23:05, William Johnson wrote:
> I have been having some difficulty successfully using external
> libraries in a custom OOT module that I have not been able to understand.
>
> I have had this issue with a few different external libraries.  The
> symptom is a segmentation fault when a function in the external
> library is called.  The below example is just representative and a bit
> circular as we are going from python->c++->python.
>
> For this example, I would like to use matplotlib within a C++ OOT
> module to visualize some data during the debug of my module.  I
> understand that this is not something I would want to do within a gnu
> radio module during normal usage and that there are other ways to
> visualize the data.  
>
> I am using matplotlib.cpp (https://github.com/lava/matplotlib-cpp) for
> this purpose.  This is simply a header file that requires linking to
> the python libraries.
>
> To do this I have:
>
> 1. Included matplotlibcpp.h in my /lib folder.
>
> 2. In /lib/CMakeList.txt I have added the following:
>
> find_package(PythonLibs 2.7)
> include_directories(${Boost_INCLUDE_DIR} ${PYTHON_INCLUDE_DIRS} )
> link_directories(${Boost_LIBRARY_DIRS}  ${PYTHON_LIBRARIES} )
> ...
> target_link_libraries( gnuradio-mymodule   ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${PYTHON_LIBRARIES}) 
>
>
> 3. Within my general_work function I have added the following (as a
> test only):
>
> #include <cmath>
> #include "matplotlibcpp.h"
> namespace plt = matplotlibcpp;
> ...
> general_work(...
> ...
>       // This just creates an interesting figure to plot.
>       int n = 5000;
>       std::vector<double> x(n), y(n), z(n), w(n,2);
>       for(int i=0; i<n; ++i) {
>               x.at <http://x.at>(i) = i*i;
>               y.at <http://y.at>(i) = sin(2*M_PI*i/360.0);
>               z.at <http://z.at>(i) = log(i);
>       }
>
>       plt::plot(x, y);
>       plt::show();
> ...
>
> I am able to build successfully but when I run my qa_XYZ.py unit test
> I get a segmentation fault at the plt::plot(x,y) line.  removing these
> two plt:: lines results in no segmentation fault.  I have seen this
> same behavior when linking with other (not python) libraries for
> different reasons so I am suspecting that there is some fundamental
> issue with how I am configuring CMakeLists.txt or what I am trying to
> do is not possible for some other reason.
>
> ----
> The following code runs without any issues on the same machine outside
> of gnuradio.
> --------------------------------------------------
> #include <cmath>
> #include "matplotlibcpp.h"
>
> namespace plt = matplotlibcpp;
>
> int main() 
> {
> // Prepare data.
> int n = 5000;
> std::vector<double> x(n), y(n), z(n), w(n,2);
> for(int i=0; i<n; ++i) {
> x.at <http://x.at>(i) = i*i;
> y.at <http://y.at>(i) = sin(2*M_PI*i/360.0);
> z.at <http://z.at>(i) = log(i);
> }
>
> plt::plot(x, y);
> plt::show();
> }
> --------------------------------------------------
> >g++ test.cpp -I/usr/include/python2.7 -lpython2.7
>
> Any help would be appreciated.
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to