Yes, cd73f8e9235f

fixes the problem.

Unless there is other experience, closing report is OK.

Thanks!!!

@Michael: The fix for bug #48519 has been pushed to stable. Can you confirm that it also fixes this bug?

I have learned a bit more about this: It is the use of clf
instead of close("all") that causes the seg fault.

clf requires a pause(0.0001) following it to prevent
the seg fault. So, for example:

close ("all");
do_plot = 1;
%% the plot_.. commands below contain: clear -x do_plot -x inpt_file
%% This is to ensure that they do not "inherent" any variable data
plot_orig
%%clf
close ("all")
plot_orig_tr_full
%%clf
close ("all")
plot_demods
clf
%%close ("all")
plot_orig_norm
===================================

seg faults with
Plot file is: airdata_1946-61_extr_1953/de_trend/plot_orig_norm.pdf
title_1 = 21-Dec-2018: airdata_1946-61_extr_1953
fatal: caught signal Segmentation fault -- stopping myself...
Segmentation fault (core dumped)

replacing the clf with close("all")

prevents the seg fault.

Note that there is in each case only one current figure so it is unclear
why clf and close("all") should produce different results.

Can you make a test script? I cannot reproduce it.

Dmitri.
--

I looked at this again using current dev.
Just running under gdb I get
essentially the same seg fault as below:

Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcb7fe700 (LWP 27417)]
0x00007ffff5a37dd2 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /lib64/libQt5Core.so.5

Also, the timing window seems to be pretty small.
pause(0.00001) prevents the seg fault.

Right now I have very limited time to debug this. Sorry.

This problem has returned in the current dev.
HG 1861e2ea0a4b

When I run a script containing many plots Octave seg faults
after only a few plots. Running under gdb I get:
++verbatim
Thread 8 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcb7fe700 (LWP 30871)]
0x00007ffff5a45dd2 in QMetaObject::activate(QObject*, int, int, void**) ()
   from /lib64/libQt5Core.so.5

and bt:
#0  0x00007ffff5a45dd2 in QMetaObject::activate(QObject*, int, int, void**) ()
    at /lib64/libQt5Core.so.5
#1  0x00007fffe00ea8ea in QtHandles::Figure::updateBoundingBoxHelper(void*) (data=0xe54cd0)
    at libgui/graphics/Figure.cc:639
#2  0x00007ffff7785f90 in graphics_event::execute() (this=0x7fffcb7fae10)
    at libinterp/corefcn/graphics.h:12891
#3  0x00007ffff7785f90 in gh_manager::do_process_events(bool) (this=0x7fffbc19a340, force=false)
    at libinterp/corefcn/graphics.cc:11396
#4  0x00007ffff773a55b in gh_manager::process_events() () at libinterp/corefcn/graphics.h:12937
#5  0x00007ffff773a55b in Fdrawnow(octave_value_list const&, int) (args=...)
    at libinterp/corefcn/graphics.cc:12737
#6  0x00007ffff738bbd0 in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) (this=0x7fffbc0734a0, tw=..., nargout=0, args=...) at libinterp/octave-value/ov-builtin.cc:65
#7  0x00007ffff750ed6e in octave::tree_evaluator::visit_index_expression(octave::tree_index_expression&) (this=0x7fffbc003e08, idx_expr=...) at libinterp/parse-tree/pt-eval.cc:1913
#8  0x00007ffff73cc0be in octave::tree_evaluator::evaluate(octave::tree_expression*, int)
    (this=this@entry=0x7fffbc003e08, expr=expr@entry=0x7fffbcd1cdd0, nargout=<optimized out>,
    nargout@entry=0) at libinterp/parse-tree/pt-eval.h:302
#9  0x00007ffff750a679 in octave::tree_evaluator::visit_statement(octave::tree_statement&)
    (this=0x7fffbc003e08, stmt=...) at libinterp/parse-tree/pt-eval.cc:2680

--verbatim
This may be related to the fact that after each plot I adjust the size of the bounding box.
I will try a few experiments as time permits.
My system is: Current Linux FC29: 4.18.17-300.fc29.x86_64