Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
( Jump to the original submission )
closing report and mark as fixed on the wiki
Yes, cd73f8e9235f
fixes the problem.
Unless there is other experience, closing report is OK.
Thanks!!!
@Michael, can you reproduce this now with Pantxo's fix in place? Otherwise, I'm going to cross it of at https://wiki.octave.org/Bug_Fix_List_-_5.0_Release.
@Michael: The fix for bug #48519 has been pushed to stable. Can you confirm that it also fixes this bug?
I think this could be a duplicate of #48519 where I get the same backtrace as in the first post.
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.
Some background: this has been a problem for a long time, but was fixed at some point. I had put pause(1) calls in the code and then about a year ago I found that the pause was not needed. Then recently the seg fault returned. The plots require a quite large set of data.
I will try to isolate the problem, but I do not right now have the time to work on it. bisecting may be useful...
One point: it seems odd that pause(0.00001) prevents the seg fault. This pause is placed just after the previous plot and there is considerable computing before the plot that seg faults.
Anyhow, I will work on it more when I can.
Can you make a test script? I cannot reproduce it.
Dmitri. --
I should add that the "many" plots in the title is inaccurate. The seg fault occurs on the second of the plots. So, 2 plots a re sufficient to cause the fault.
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.
Definitely timing. I placed pause(5) after each plot and script completes normally.
I will open a new report for the fact that pause with no argument hangs. ^C is required to continue.
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
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2022 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9