bugGNU Octave - Bugs: bug #57353, crash signal 11 when using patch()...

 
 

bug #57353: crash signal 11 when using patch() with large stl file

Submitted by:  None
Submitted on:  Tue 03 Dec 2019 10:32:14 PM UTC  
 
Category:  Plotting Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  Rik <rik5>
Originator Name:  Marcel Hell Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  5.1.0
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 06 Dec 2019 08:27:36 PM UTC, comment #36: 

Marcus, Rik, and Hg200, thanks for fixing this problem.

John W. Eaton <jwe>
Project Administrator
Fri 06 Dec 2019 07:20:22 PM UTC, comment #35: 

I made a few changes to wording and pushed Markus' comment here https://hg.savannah.gnu.org/hgweb/octave/rev/1e6389ae4060.

Rik <rik5>
Project AdministratorIn charge of this item.
Fri 06 Dec 2019 07:09:03 PM UTC, comment #34: 

Yes, I agree we need some explanation of the intent.

std::vector<T> [N]

is also confusing.  I needed more time than I would like to admit to understand why both of the following worked without any other changes:

std::vector<T> foo [N];
std::vector<T> *foo = new std::vector<T> [N];

It's obvious now, but an array of std::vector<T> objects is not something I expect to see.

John W. Eaton <jwe>
Project Administrator
Fri 06 Dec 2019 06:35:14 PM UTC, comment #33: 

The attached patch adds a comment to motivate why that particular type is used.
It is very wordy. Maybe someone with better English skills could improve on that.

(file #48019)

Markus Mützel <mmuetzel>
Project Member
Fri 06 Dec 2019 03:52:11 PM UTC, comment #32: 

I think a comment above the declaration is probably required, just so it doesn't get undone at a later point in time.  It isn't at all clear to me what "std::vector<std::vector<RowVector>>" is and why it would be required. 

Rik <rik5>
Project AdministratorIn charge of this item.
Fri 06 Dec 2019 03:27:41 AM UTC, comment #31: 

Thanks for finding a fix for this problem.

I pushed an additional change to use "std::vector<std::vector<T>> (SIZE)" instead of "new std::vector<T> [SIZE]" so that the object will be cleaned when it goes out of scope even if that happens because an exception occurs.  In Octave, we generally want to limit use of new to constructors and delete to destructors.

Also, std::vector<std::vector<RowVector>> is a bit of a strange data structure, so maybe there is a better way to express what we are trying to do in that function?  But, for now, I left it as is since it seems to work.

John W. Eaton <jwe>
Project Administrator
Thu 05 Dec 2019 11:08:53 PM UTC, comment #30: 

Thank you all, now it worked!
Sorry for the trouble :-)

Marcel Hell <marcel756>
Thu 05 Dec 2019 09:57:03 PM UTC, comment #29: 

The error "Network is unreachable" is usually a temporary issue caused by too many requests.  It usually clears up in 10-15 minutes.  You might just try hg pull again.

Rik <rik5>
Project AdministratorIn charge of this item.
Thu 05 Dec 2019 09:45:34 PM UTC, comment #28: 

Hi Marcel,

i have taken the changes displayed here

http://hg.savannah.gnu.org/hgweb/octave/rev/088d5e7a2b7e

and edited them with a simple editor (e.g. gedit) into grahpics.cc (red lines = remove, green lines = add) and then simply type "make" to do an incremental build (compile only changed files).

Loading big stl files takes long time but displays correctly and does not segfault any more at my side.

Hg200 <hg200>
Thu 05 Dec 2019 09:27:53 PM UTC, comment #27: 

hg200:
how can I download this specific revision? hg pull leads to
pulling from http://www.octave.org/hg/octave
abort: error: Network is unreachable

comment #23:

> I pushed the following change to use "new" to allocate the memory dynamically:
> http://hg.savannah.gnu.org/hgweb/octave/rev/088d5e7a2b7e
>
> Does this fix the segmentation fault for you?

Marcel Hell <marcel756>
Thu 05 Dec 2019 09:24:18 PM UTC, comment #26: 

unfortunately not:

octave:2> run test_patch_v2.m
number of facets: 4 x 100000
Segmentation fault (core dumped)

comment #22:

> i have tweaked the MWE to create the "new" segfault (according to the gdb backtrace) on my laptop. please find attached test_patch_v2.m.
>
> @Marcel: Please test and give feedback if that segfaults at your side too.
>
> thanks
>

> octave:1>  __octave_config_info__ ("hg_id")
> ans = 54767f6a93f5
> octave:2>

>
> (file #48005)

Marcel Hell <marcel756>
Thu 05 Dec 2019 08:58:59 PM UTC, comment #25: 

I'm not the original reporter, but I can verify that this now works for me.

In the original implementation, the variable vec_vn is a local variable in a function, which means the memory for it comes from the stack.  I used gdb and the sizeof() operator to find that the size of the variable was 9.6 MB.  In the shell, I checked with "limit" and the stacksize was 8.192 MB.  Just to verify, I changed the stacksize in the shell to 10 MB and then the code in test_patch_v2.m passes.  Clearly, this is the root problem and I agree with Markus' fix to shift this variable on to the heap.

Rik <rik5>
Project AdministratorIn charge of this item.
Thu 05 Dec 2019 08:57:06 PM UTC, comment #24: 

Markus,

ahhh - your suggestion is what i had in my mind for some time but i didn't try. Yes that solves the problem!

However before we congratulate ourselves i suppose we should wait what Marcel will respond ;-)

Thanks and best regards

Hg200 <hg200>
Thu 05 Dec 2019 08:24:37 PM UTC, comment #23: 

I pushed the following change to use "new" to allocate the memory dynamically:
http://hg.savannah.gnu.org/hgweb/octave/rev/088d5e7a2b7e

Does this fix the segmentation fault for you?

Markus Mützel <mmuetzel>
Project Member
Thu 05 Dec 2019 08:20:30 PM UTC, comment #22: 

i have tweaked the MWE to create the "new" segfault (according to the gdb backtrace) on my laptop. please find attached test_patch_v2.m.

@Marcel: Please test and give feedback if that segfaults at your side too.

thanks

octave:1>  __octave_config_info__ ("hg_id")
ans = 54767f6a93f5
octave:2>

(file #48005)

Hg200 <hg200>
Thu 05 Dec 2019 07:22:32 PM UTC, comment #21: 

Sorry. Please ignore. 10 MiB not 10 GiB.

Markus Mützel <mmuetzel>
Project Member
Thu 05 Dec 2019 07:18:25 PM UTC, comment #20: 

The size of a std::vector is implementation dependent. But most commonly, it is 24 bytes on 64bit systems. I.e. that call tries to allocate more than 10 GiB of memory. That might be the cause of the segfault.
Maybe we should disable lighting (at least "gouraud") if patches reach a critical number of vertices?
How high should that threshold be?

Markus Mützel <mmuetzel>
Project Member
Thu 05 Dec 2019 05:32:37 PM UTC, comment #19: 

Here is my backtrace output. Some informations in advance:

RAM is 4GB total

(gdb) break graphics.cc:10125
Breakpoint 1 at 0x7fcab33c56e5: file libinterp/corefcn/graphics.cc, line 10125.
(gdb) c
Continuing.
Thread 5 "QThread" hit Breakpoint 1, patch::properties::update_vertex_normals (this=0x7fca88379650, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10125
10125         std::vector<RowVector> vec_vn [num_v];  // list of normals for vertices
(gdb) print num_v
$1 = 471129
(gdb) ptype num_v
type = long

Looks not suspicious (?) because is consistent with the call to patch (i am calling with 3 x 157043 = 471129 points). Hint: I am using different stl data (much smaller) than marcel.

Backtrace:

Thread 5 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f2b97fff700 (LWP 9180)]
0x00007f2bc1b627a4 in std::_Vector_base<RowVector, std::allocator<RowVector> >::_Vector_impl::_Vector_impl (this=0x7f2b977ff000)
    at /usr/include/c++/8/bits/stl_vector.h:96
96              : _Tp_alloc_type(), _M_start(), _M_finish(), _M_end_of_storage()
#0  0x00007f2bc1b627a4 in std::_Vector_base<RowVector, std::allocator<RowVector> >::_Vector_impl::_Vector_impl() (this=0x7f2b977ff000)
    at /usr/include/c++/8/bits/stl_vector.h:96
#1  0x00007f2bc1b5c77a in std::_Vector_base<RowVector, std::allocator<RowVector> >::_Vector_base() (this=0x7f2b977ff000)
    at /usr/include/c++/8/bits/stl_vector.h:249
#2  0x00007f2bc1b582f4 in std::vector<RowVector, std::allocator<RowVector> >::vector() (this=0x7f2b977ff000)
    at /usr/include/c++/8/bits/stl_vector.h:395
#3  0x00007f2bc1b047f4 in patch::properties::update_vertex_normals(bool, bool) (this=0x7f2b90379650, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10125
#4  0x00007f2bc1b4558c in patch::properties::update_normals(bool, bool) (this=0x7f2b90379650, reset=false, force=false)
    at libinterp/corefcn/graphics.h:9299
#5  0x00007f2bc1afcf3a in axes::properties::trigger_normals_calc() (this=0x7f2b90307900) at libinterp/corefcn/graphics.cc:9292
#6  0x00007f2bc1b00263 in light::initialize(graphics_object const&) (this=0x7f2b90857200, go=...) at libinterp/corefcn/graphics.cc:9590
#7  0x00007f2bc1b2bbf3 in graphics_object::initialize() (this=0x7f2b97fec120) at libinterp/corefcn/graphics.h:3110
#8  0x00007f2bc19f00fb in xinitialize(graphics_handle const&) (h=...) at libinterp/corefcn/graphics.cc:3194
#9  0x00007f2bc1b19e6f in make_graphics_object(std::__cxx11::string const&, bool, octave_value_list const&)
    (go_name="light", integer_figure_handle=false, args=...) at libinterp/corefcn/graphics.cc:13124
#10 0x00007f2bc1b1b938 in F__go_light__(octave::interpreter&, octave_value_list const&, int) (interp=..., args=...)
    at libinterp/corefcn/graphics.cc:13346
#11 0x00007f2bc167cb1b in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) (
    this=0x7f2b900787c0, tw=..., nargout=1, args=...) at libinterp/octave-value/ov-builtin.cc:68
#12 0x00007f2bc183368c in octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) (this=0x7f2b90878410, tw=..., nargout=1)

Hg200 <hg200>
Thu 05 Dec 2019 04:36:36 PM UTC, comment #18: 

Hi, here's the output:

Thread 4 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fea2bf1e700 (LWP 27402)]
0x00007fea55ccc363 in patch::properties::update_vertex_normals (
    this=0x7fea1c5e41c0, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10125
10125         std::vector<RowVector> vec_vn [num_v];  // list of normals for vertices
(gdb) p num_v
$1 = 2284149
(gdb) p num_v
$2 = 2284149
(gdb) c
Continuing.

Thread 4 "QThread" received signal SIGSEGV, Segmentation fault.
0x00007fea55ccc363 in patch::properties::update_vertex_normals (
    this=0x7fea1c5e41c0, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10125
10125         std::vector<RowVector> vec_vn [num_v];  // list of normals for vertices

My machine has 16GB RAM.

Hope this helps.

Marcel Hell <marcel756>
Thu 05 Dec 2019 03:44:44 PM UTC, comment #17: 

I guess it's time to try poking around with the debugger.

The line that provokes the segfault is

std::vector<RowVector> vec_vn [num_v];  // list of normals for vertices

Try running Octave under the debugger as before, when it segfaults, instead of executing 'bt', try

p num_v

Let's see if this value is negative, 0, or excessively large.

Second question, how much memory does your machine have?

Third question, did you compile Octave with --disable-64 to have a 32-bit octave_idx_type?

Rik <rik5>
Project AdministratorIn charge of this item.
Thu 05 Dec 2019 03:36:58 PM UTC, comment #16: 

I guess: Two independent problems.

I have merged Rik's patch to a somewhat older stable version i had on hand. The problem forced in test_patch.m seems to be solved. I can not create the segfault with Rik's patch applied.

But i also still get a segfault when loading big stl data. LIBGL_ALWAYS_SOFTWARE=1 does not show any difference.

I am coming back as soon as a new build with -g has been finished.

Hg200 <hg200>
Thu 05 Dec 2019 09:19:10 AM UTC, comment #15: 

@Dmitry: yes it still crashes.

@Rik:

Here is the bt output before and after it crashes:
#0  0x00007f2749052363 in patch::properties::update_vertex_normals (
    this=0x7f27117c2c30, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10125
#1  0x00007f2749097a22 in patch::properties::update_normals (
    this=0x7f27117c2c30, reset=false, force=false)
    at libinterp/corefcn/graphics.h:9299
#2  0x00007f274904a55f in axes::properties::trigger_normals_calc (
    this=0x7f2711738f20) at libinterp/corefcn/graphics.cc:9292
#3  0x00007f274904da82 in light::initialize (this=0x7f271182b4e0, go=...)
    at libinterp/corefcn/graphics.cc:9590
#4  0x00007f274907bc33 in graphics_object::initialize (this=0x7f271f270c30)
    at libinterp/corefcn/graphics.h:3110
#5  0x00007f2748f40c8d in xinitialize (h=...)
    at libinterp/corefcn/graphics.cc:3194
#6  0x00007f27490685be in make_graphics_object (go_name="light",
    integer_figure_handle=false, args=...)
    at libinterp/corefcn/graphics.cc:13124
#7  0x00007f274906a36d in F__go_light__ (interp=..., args=...)
    at libinterp/corefcn/graphics.cc:13346
#8  0x00007f2748b9b38a in octave_builtin::call (this=0x7f271007b820, tw=...,
    nargout=1, args=...) at libinterp/octave-value/ov-builtin.cc:68
#9  0x00007f2748d68d3b in octave::tree_index_expression::evaluate_n (
    this=0x7f271181ef40, tw=..., nargout=1)
    at libinterp/parse-tree/pt-idx.cc:518
#10 0x00007f2748d6a66e in octave::tree_index_expression::evaluate (
    this=0x7f271181ef40, tw=..., nargout=1)
    at libinterp/parse-tree/pt-idx.h:106
#11 0x00007f2748d36788 in octave::tree_simple_assignment::evaluate (
    this=0x7f27117d1230, tw=...) at libinterp/parse-tree/pt-assign.cc:98
#12 0x00007f2748d4af78 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2724
#13 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f2711808b50, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#14 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#15 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f271180d940, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#16 0x00007f2748d4a035 in octave::tree_evaluator::execute_user_function (
    this=0x7f27100057f0, user_function=..., nargout=1, xargs=...,
    closure_frames=0x0) at libinterp/parse-tree/pt-eval.cc:2444
#17 0x00007f2748c5b3cd in octave_user_function::call (this=0x7f2711824a20,
    tw=..., nargout=1, args=..., closure_frames=0x0)
    at libinterp/octave-value/ov-usr-fcn.cc:464
#18 0x00007f2748c5e96b in octave_user_function::call (this=0x7f2711824a20,
    tw=..., nargout=1, args=...) at libinterp/octave-value/ov-usr-fcn.h:376
#19 0x00007f2748d68d3b in octave::tree_index_expression::evaluate_n (
    this=0x7f2711819ed0, tw=..., nargout=1)
    at libinterp/parse-tree/pt-idx.cc:518
#20 0x00007f2748d6a66e in octave::tree_index_expression::evaluate (
    this=0x7f2711819ed0, tw=..., nargout=1)
    at libinterp/parse-tree/pt-idx.h:106
#21 0x00007f2748d36788 in octave::tree_simple_assignment::evaluate (
    this=0x7f271181a090, tw=...) at libinterp/parse-tree/pt-assign.cc:98
---Type <return> to continue, or q <return> to quit---
#22 0x00007f2748d4af78 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2724
#23 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f271181a0d0, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#24 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#25 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f27118186f0, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#26 0x00007f2748d4a9ae in octave::tree_evaluator::visit_if_command_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2577
#27 0x00007f2748d53130 in octave::tree_if_command_list::accept (
    this=0x7f271181a1f0, tw=...) at libinterp/parse-tree/pt-select.h:115
#28 0x00007f2748d4a7ce in octave::tree_evaluator::visit_if_command (
    this=0x7f27100057f0, cmd=...) at libinterp/parse-tree/pt-eval.cc:2555
#29 0x00007f2748d741ee in octave::tree_if_command::accept (
    this=0x7f271181af30, tw=...) at libinterp/parse-tree/pt-select.h:148
#30 0x00007f2748d4aec6 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2702
#31 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f271181af70, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#32 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#33 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f271017fb70, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#34 0x00007f2748d4a035 in octave::tree_evaluator::execute_user_function (
    this=0x7f27100057f0, user_function=..., nargout=0, xargs=...,
    closure_frames=0x0) at libinterp/parse-tree/pt-eval.cc:2444
#35 0x00007f2748c5b3cd in octave_user_function::call (this=0x7f2711804870,
    tw=..., nargout=0, args=..., closure_frames=0x0)
    at libinterp/octave-value/ov-usr-fcn.cc:464
#36 0x00007f2748c5e96b in octave_user_function::call (this=0x7f2711804870,
    tw=..., nargout=0, args=...) at libinterp/octave-value/ov-usr-fcn.h:376
#37 0x00007f2748d68d3b in octave::tree_index_expression::evaluate_n (
    this=0x7f271046d720, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.cc:518
#38 0x00007f2748d6a66e in octave::tree_index_expression::evaluate (
    this=0x7f271046d720, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.h:106
#39 0x00007f2748d4af78 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2724
#40 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f271045c110, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#41 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#42 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f271041f330, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#43 0x00007f2748d49786 in octave::tree_evaluator::execute_user_script (
    this=0x7f27100057f0, user_script=..., nargout=0, args=...)
    at libinterp/parse-tree/pt-eval.cc:2303
#44 0x00007f2748c59a88 in octave_user_script::call (this=0x7f27103ef6a0,
    tw=..., nargout=0, args=...) at libinterp/octave-value/ov-usr-fcn.cc:177
#45 0x00007f2748d44f59 in octave::tree_evaluator::source_file (
    this=0x7f27100057f0,
---Type <return> to continue, or q <return> to quit---
    file_name="/home/marcel/development/octave/STLRead/STLRead/stldemo.m",
    context="", verbose=false, require_file=true)
    at libinterp/parse-tree/pt-eval.cc:1207
#46 0x00007f27490e614b in octave::interpreter::source_file (
    this=0x7f2710004a60,
    file_name="/home/marcel/development/octave/STLRead/STLRead/stldemo.m",
    context="", verbose=false, require_file=true)
    at libinterp/corefcn/interpreter.cc:1601
#47 0x00007f2748d18f44 in Fsource (interp=..., args=...)
    at libinterp/parse-tree/oct-parse.yy:5125
#48 0x00007f2748b9b38a in octave_builtin::call (this=0x7f27100367f0, tw=...,
    nargout=0, args=...) at libinterp/octave-value/ov-builtin.cc:68
#49 0x00007f2748d68d3b in octave::tree_index_expression::evaluate_n (
    this=0x7f271046ca00, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.cc:518
#50 0x00007f2748d42344 in octave::tree_evaluator::eval_string (
    this=0x7f27100057f0,
    eval_str="source ('/home/marcel/development/octave/STLRead/STLRead/stldemo.m');", silent=false, parse_status=@0x7f271f27310c: 0, nargout=0)
    at libinterp/parse-tree/pt-eval.cc:502
#51 0x00007f2748d430ed in octave::tree_evaluator::evalin (
    this=0x7f27100057f0, context="caller",
    try_code="source ('/home/marcel/development/octave/STLRead/STLRead/stldemo.m');", catch_code="rethrow (lasterror ())", nargout=0)
    at libinterp/parse-tree/pt-eval.cc:661
#52 0x00007f27490e5798 in octave::interpreter::evalin (this=0x7f2710004a60,
    context="caller",
    try_code="source ('/home/marcel/development/octave/STLRead/STLRead/stldemo.m');", catch_code="rethrow (lasterror ())", nargout=0)
    at libinterp/corefcn/interpreter.cc:1430
#53 0x00007f2748d19f15 in Fevalin (interp=..., args=..., nargout=0)
    at libinterp/parse-tree/oct-parse.yy:5472
#54 0x00007f2748b9b38a in octave_builtin::call (this=0x7f27100377e0, tw=...,
    nargout=0, args=...) at libinterp/octave-value/ov-builtin.cc:68
#55 0x00007f2748d68d3b in octave::tree_index_expression::evaluate_n (
    this=0x7f27103e3c10, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.cc:518
#56 0x00007f2748d6a66e in octave::tree_index_expression::evaluate (
    this=0x7f27103e3c10, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.h:106
#57 0x00007f2748d4af78 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2724
#58 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f27103e3db0, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#59 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#60 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f27103e2e90, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#61 0x00007f2748d4a9ae in octave::tree_evaluator::visit_if_command_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2577
#62 0x00007f2748d53130 in octave::tree_if_command_list::accept (
    this=0x7f27103e0ab0, tw=...) at libinterp/parse-tree/pt-select.h:115
#63 0x00007f2748d4a7ce in octave::tree_evaluator::visit_if_command (
---Type <return> to continue, or q <return> to quit---
    this=0x7f27100057f0, cmd=...) at libinterp/parse-tree/pt-eval.cc:2555
#64 0x00007f2748d741ee in octave::tree_if_command::accept (
    this=0x7f27103e3f10, tw=...) at libinterp/parse-tree/pt-select.h:148
#65 0x00007f2748d4aec6 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2702
#66 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f27103e3f50, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#67 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#68 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f271016cae0, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#69 0x00007f2748d4a035 in octave::tree_evaluator::execute_user_function (
    this=0x7f27100057f0, user_function=..., nargout=0, xargs=...,
    closure_frames=0x0) at libinterp/parse-tree/pt-eval.cc:2444
#70 0x00007f2748c5b3cd in octave_user_function::call (this=0x7f27103e4150,
    tw=..., nargout=0, args=..., closure_frames=0x0)
    at libinterp/octave-value/ov-usr-fcn.cc:464
#71 0x00007f2748c5e96b in octave_user_function::call (this=0x7f27103e4150,
    tw=..., nargout=0, args=...) at libinterp/octave-value/ov-usr-fcn.h:376
#72 0x00007f2748d68d3b in octave::tree_index_expression::evaluate_n (
    this=0x7f2710492250, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.cc:518
#73 0x00007f2748d6a66e in octave::tree_index_expression::evaluate (
    this=0x7f2710492250, tw=..., nargout=0)
    at libinterp/parse-tree/pt-idx.h:106
#74 0x00007f2748d4af78 in octave::tree_evaluator::visit_statement (
    this=0x7f27100057f0, stmt=...) at libinterp/parse-tree/pt-eval.cc:2724
#75 0x00007f2748d75702 in octave::tree_statement::accept (
    this=0x7f2710343790, tw=...) at libinterp/parse-tree/pt-stmt.h:121
#76 0x00007f2748d4b1c9 in octave::tree_evaluator::visit_statement_list (
    this=0x7f27100057f0, lst=...) at libinterp/parse-tree/pt-eval.cc:2783
#77 0x00007f2748b46486 in octave::tree_statement_list::accept (
    this=0x7f2710461fb0, tw=...) at libinterp/parse-tree/pt-stmt.h:198
#78 0x00007f2748d41df4 in octave::tree_evaluator::eval (this=0x7f27100057f0,
    stmt_list=std::shared_ptr<octave::tree_statement_list> (use count 2, weak count 0) = {...}, interactive=true) at libinterp/parse-tree/pt-eval.cc:398
#79 0x00007f27490e2928 in octave::interpreter::main_loop (
    this=0x7f2710004a60) at libinterp/corefcn/interpreter.cc:1113
#80 0x00007f27490e14e4 in octave::interpreter::execute (this=0x7f2710004a60)
    at libinterp/corefcn/interpreter.cc:795
#81 0x00007f2749ab2422 in octave::interpreter_qobject::execute (
    this=0x55c18e927240) at libgui/src/interpreter-qobject.cc:85
#82 0x00007f2749ba38c0 in octave::interpreter_qobject::qt_static_metacall (
    _o=0x55c18e927240, _c=QMetaObject::InvokeMetaMethod, _id=2,
    _a=0x55c18ea4b090) at libgui/src/moc-interpreter-qobject.cc:88
#83 0x00007f27442ad1b2 in QObject::event(QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#84 0x00007f2744ffb83c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#85 0x00007f2745003104 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#86 0x00007f2749b0e0e4 in octave::octave_qapplication::notify (
    this=0x55c18e89a6f0, receiver=0x55c18e927240, ev=0x55c18ea556a0)
---Type <return> to continue, or q <return> to quit---
    at libgui/src/octave-qobject.cc:130
#87 0x00007f274427d9c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#88 0x00007f274428013d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#89 0x00007f27442d7353 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#90 0x00007f273d0e6417 in g_main_context_dispatch ()
   from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#91 0x00007f273d0e6650 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#92 0x00007f273d0e66dc in g_main_context_iteration ()
   from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#93 0x00007f27442d697f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#94 0x00007f274427b9fa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#95 0x00007f274409a23a in QThread::exec() ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#96 0x00007f274409f17d in ?? ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#97 0x00007f274383a6db in start_thread (arg=0x7f271f27c700)
    at pthread_create.c:463
#98 0x00007f274673088f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.

Thread 4 "QThread" received signal SIGSEGV, Segmentation fault.
0x00007f2749052363 in patch::properties::update_vertex_normals (
    this=0x7f27117c2c30, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10125
10125         std::vector<RowVector> vec_vn [num_v];  // list of normals for vertices
(gdb) c
Continuing.

Marcel Hell <marcel756>
Thu 05 Dec 2019 12:31:59 AM UTC, comment #14: 

Does it crash if you start octave as :


LIBGL_ALWAYS_SOFTWARE=1 octave -f -q

?

Dmitri
--

Dmitri A. Sergatskov <dasergatskov>
Thu 05 Dec 2019 12:27:01 AM UTC, comment #13: 

That's odd.  I think you will need to run octave under a debugger and obtain a backtrace to find out where the segfault is coming from.

These instructions assume a tcsh shell, but you can translate them pretty easily to another syntax if you use a Bourne shell derivative.

setenv CFLAGS "-g -O0 -pipe"
setenv CXXFLAGS "${CFLAGS}"
setenv FFLAGS "${CFLAGS}"
./configure --prefix=/usr/local --disable-docs
make
run-octave -f

In another shell, find the process ID of the running Octave.

ps auxww | grep octave
sudo gdb -p XXXX  # substitute process ID for XXX
c<RETURN>

Back in Octave, run the script that causes the problem.  When it segfaults, go te the window with gdb and execute

bt<RETURN>

Post the backtrace to this bug report.  Probably only need the first 10 or so lines. 

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 04 Dec 2019 11:35:13 PM UTC, comment #12: 

now   _octave_config_info_ ("hg_id") returns ans = 54767f6a93f5

The result of trying to using the below patch command is still

octave exited with signal 11

Marcel Hell <marcel756>
Wed 04 Dec 2019 11:25:00 PM UTC, comment #11: 

That explains it.  The hg id of your build is for cset 27771.  You need to be at cset 27773 in order to see the fix.   Try

hg pull; hg update; hg summary

which should show at least the following

parent: 27773:54767f6a93f5 tip
maint: merge stable to default.
branch: default

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 04 Dec 2019 11:15:30 PM UTC, comment #10: 

ans = cd566153edd6

Marcel Hell <marcel756>
Wed 04 Dec 2019 10:19:38 PM UTC, comment #9: 

What does this return?

 __octave_config_info__ ("hg_id")

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 04 Dec 2019 10:17:37 PM UTC, comment #8: 

I downloaded and build octave from the Mercurial repo, and it shows as version 6.0.

The problem unfortunately is still there.

Marcel Hell <marcel756>
Wed 04 Dec 2019 08:05:01 PM UTC, comment #7: 

Fixed on the stable branch in this changeset: https://hg.savannah.gnu.org/hgweb/octave/rev/2d1af61d8f5e.

In order to see the fix you would need to download the code from the Mercurial repository and build from source.  Alternatively, the next release of Octave, version 6.1, will probably be release in late December, early January.

Marking as fixed and closing report.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 04 Dec 2019 07:50:50 PM UTC, comment #6: 

Yes, that was the problem.  I found another instance of the same construct as well.  Will have a fix shortly.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 04 Dec 2019 07:29:49 PM UTC, comment #5: 

Confirmed.  I just tested the MWE on the development tip with a debug version of Octave and obtained the following backtrace.

#0  0x00007fc47c623ee3 in patch::properties::update_vertex_normals (this=0x7fc444e1c640, reset=false, force=false)
    at libinterp/corefcn/graphics.cc:10132
#1  0x00007fc47c668f36 in patch::properties::update_normals (this=0x7fc444e1c640, reset=false, force=false)
    at libinterp/corefcn/graphics.h:9299
#2  0x00007fc47c669d70 in patch::properties::update_facelighting (this=0x7fc444e1c640)
    at libinterp/corefcn/graphics.h:9384
#3  0x00007fc47c666c03 in patch::properties::set_facelighting (this=0x7fc444e1c640, val=...)
    at libinterp/corefcn/graphics.h:8958
#4  0x00007fc47c590328 in patch::properties::set (this=0x7fc444e1c640, pname_arg=..., val=...)
    at libinterp/corefcn/graphics-props.cc:4498
#5  0x00007fc47c64b7a5 in base_graphics_object::set (this=0x7fc444e1c630, pname=..., pval=...)
    at libinterp/corefcn/graphics.h:2703
#6  0x00007fc47c5109d4 in graphics_object::set_value_or_default (this=0x7fc4527dee40, pname=..., val=...)
    at libinterp/corefcn/graphics.cc:2754
#7  0x00007fc47c5103e3 in graphics_object::set (this=0x7fc4527dee40, args=...) at libinterp/corefcn/graphics.cc:2537
#8  0x00007fc47c638140 in Fset (interp=..., args=..., nargout=0) at libinterp/corefcn/graphics.cc:12855

The code in question in graphics.cc is

while (! octave::math::isnan (f(i,nc)) && nc < max_nc)
  nc++;

It sure looks like the test for "nc < max_nc" should appear before nc gets used to index the faces "f(i,nc)".

Testing that now.

Rik <rik5>
Project AdministratorIn charge of this item.
Wed 04 Dec 2019 05:47:46 PM UTC, comment #4: 

I was able to reproduce and to simplify. MWE is attached.

Sometimes the MWE crashes on my laptop. Sometimes not. MWE does not need any stl file because its generating some random tube patch data itself.

What i have observed:

  • Big patch data necessary
  • Gouraud shading

If debug then exits with 11 at light.m line 115 when gouraud is set

 set (hlist(! is_mesh), "facelighting", mode, "edgelighting", "none");

(file #47997)

Hg200 <hg200>
Wed 04 Dec 2019 04:40:06 PM UTC, comment #3: 

comment #1:

> To reproduce the issue, can you attach "upper.stl" to this item?


Here is the link to my one drive:
https://1drv.ms/u/s!AjC0-dowXEKLhIwGbjY2qJNAb8D4SQ?e=nulcOD

Marcel Hell <marcel756>
Wed 04 Dec 2019 04:33:35 PM UTC, comment #2: 

I cannot upload the file, due to its size of 38m.
Even when I split it, I get the error that no group was chosen... Is there any other way to upload?

Marcel Hell <marcel756>
Wed 04 Dec 2019 07:00:05 AM UTC, comment #1: 

To reproduce the issue, can you attach "upper.stl" to this item?

Kai Torben Ohlhus <siko1056>
Project Member
Tue 03 Dec 2019 10:32:14 PM UTC, original submission:  

Hello, I am trying to display a 24 MB stl file using stlread and then patch()

[c,q,v]=stlread('upper.stl');
patch('Faces',q,'Vertices', c);

Then octave get closed with signal 11, without any additional error messages.

Smaller binary stl files do work without any problem.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #48019:  bug57353_patch_face_normals_comment.patch added by mmuetzel (1KiB - application/octet-stream)
file #48005:  test_patch_v2.m added by hg200 (1KiB - text/x-objcsrc)
file #47997:  test_patch.m added by hg200 (1KiB - text/x-objcsrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hg200
  • -email is unavailable- added by hg200 (Updated the item)
  • -email is unavailable- added by marcel756 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 23 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-06 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-12-06 mmuetzel Attached File- => Added bug57353_patch_face_normals_comment.patch, #48019
        StatusFixed => Ready For Test
        Open/ClosedClosed => Open
    2019-12-05 rik5 StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-12-05 mmuetzel StatusFixed => Ready For Test
        Open/ClosedClosed => Open
    2019-12-05 hg200 Attached File- => Added test_patch_v2.m, #48005
    2019-12-04 rik5 StatusIn Progress => Fixed
        Open/ClosedOpen => Closed
    2019-12-04 rik5 Severity3 - Normal => 4 - Important
        Item GroupUnexpected Error => Segfault, Bus Error, etc.
        StatusConfirmed => In Progress
        Assigned toNone => rik5
        Releasedev => 5.1.0
    2019-12-04 rik5 CategoryNone => Plotting
        StatusNeed Info => Confirmed
        Release5.1.0 => dev
    2019-12-04 hg200 Carbon-Copy- => Added hg200
    2019-12-04 hg200 Attached File- => Added test_patch.m, #47997
    2019-12-04 siko1056 StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5