[Discuss-gnuradio] Segmentation fault due to thread unsafety?

[jeroen]

Hi all,

I suspect I'm having problems with different threads which gives me a 
segmentation fault. Hopefully someone with knowledge on how this works 
with GNU radio can give me a hint for a solution.

What I did is as follows (C++ implementation code is quite long, so I 
hope the following sketch of the situation is sufficient):

1) I made a pure C++ test-application, so not using GRC.
2) I derived my own block from the sync-block.
3) In the work()-function of my own block, variables are prepared to be 
plotted (simple xy-graphs). These variables are members of my 
block-class.
4) My own block also has a member function to plot the xy variables, say 
void plot_all(void).
5) In the main loop (so within main()...) there is a loop which waits 
for CTRL-C, and lets the GNU Radio thread sleep for 10 ms each 
iteration. In that loop, the plotting routine is called when more than 
100 ms elapsed since the last time: my_block->plot_all().
6) If the plot_all() function now not only reads or only writes a member 
variable of my own block but both reads and writes, then I get a 
segmentation fault.
7) I even get a segmentation fault if the plotting variables are made 
global, so outside my own block.

I suspect that a solution is that I drag all plotting into my own block, 
and that also calling the plot_all() function must be done from within 
the work() function (say every 100 ms).

a) Would that work? (if I would try and test it and it works I may still 
not know if the solution is foolproof, so I ask therefore)
b) Does that give me additional chance for buffer overruns because of 
required plotting CPU time within work()?
c) Do I have to pull GLUT initializations as well to the constructor of 
my own block, or can I leave them in main()?
d) Is there a better solution?

Sorry if I ask much, but I've spent many hours on this problem already 
and an expert may just have a simple solution for me :-)

hanks and best regards,

   Jeroen