bugGNU Octave - Bugs: bug #57245, "mlock" inside a...

 
 

bug #57245: "mlock" inside a compiled function locks the calling function instead

Submitter:  Carlo de Falco <cdf>
Submitted:  Sat 16 Nov 2019 09:18:43 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 16 Dec 2019 10:53:17 PM UTC, comment #42: 


comment #41:

> I pushed the following changeset:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/e06ce39f78ad
>
> Does this fix the original problem for you?
>


Yes! It does look it's fixed now :


octave:1> __octave_config_info__ hg_id
ans = e06ce39f78ad
octave:2> graphics_toolkit gnuplot
octave:3> clear all
octave:4> plot (randn (5))
octave:5> clear all
octave:6> plot (randn (5))
octave:7> exit
 $


Carlo de Falco <cdf>
Group Member
Mon 16 Dec 2019 07:57:04 PM UTC, comment #41: 

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/e06ce39f78ad

Does this fix the original problem for you?

John W. Eaton <jwe>
Group administrator
Mon 16 Dec 2019 05:57:53 AM UTC, comment #40: 

I'll take a look at it.  It's probably due to the symbol table and call stack refactoring that was done for version 6.

John W. Eaton <jwe>
Group administrator
Sun 15 Dec 2019 05:54:26 PM UTC, comment #39: 

That is consistent with the "mlock" issue.
Let's wait and see if jwe or another developer has an idea how to fix it.
The crash on exit might be related or it might also be a different error. If it persists after this bug is fixed, we can look into it again (maybe in a new report).

Markus Mützel <mmuetzel>
Group administrator
Sun 15 Dec 2019 05:04:51 PM UTC, comment #38: 


comment #37:


> > graphics_toolkit gnuplot
> > clear functions
> > plot (randn (5))


>
>
> this crashes with the usual trace
>
> > or:


> > graphics_toolkit gnuplot
> > clear global
> > plot (randn (5))


> >
>
> this doesn't


well, it doesn't crash immediately in the second case but I do get a crash on exit :


octave:2> graphics_toolkit gnuplot
octave:3> clear global
octave:4> plot (randn (5))
octave:5> exit
fatal: caught signal Hangup: 1 -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
error: ignoring const exit_exception& while preparing to exit



Carlo de Falco <cdf>
Group Member
Sun 15 Dec 2019 05:02:34 PM UTC, comment #37: 

thanks @mmuetzel for looking into this!

comment #34:

> I assume the stop reason was still the same with the patch applied?
>
> To narrow down the cause a little bit, could you please try which of the following causes the error (if any):


> graphics_toolkit gnuplot
> clear functions
> plot (randn (5))



this crashes with the usual trace

> or:


> graphics_toolkit gnuplot
> clear global
> plot (randn (5))


>


this doesn't


Carlo de Falco <cdf>
Group Member
Sun 15 Dec 2019 03:24:40 PM UTC, comment #36: 

Re-titling to reflect the probable cause of the error.

Markus Mützel <mmuetzel>
Group administrator
Sun 15 Dec 2019 03:22:48 PM UTC, comment #35: 

There might be something broken with the locking mechanism for builtin functions.
In Octave 5.1:

octave:1> __init_gnuplot__
octave:2>


In Octave 6.0:

octave:1> __init_gnuplot__
error: mlock: invalid use outside a function
octave:2>


If I call "__init_gnuplot__" from inside a function, that function is locked instead.

The "clear all" probably deletes the toolkit that should have been protected by the mlock in F__init_gnuplot__.

jwe is already in the CC list. He'll probably understand why this is failing now.

Markus Mützel <mmuetzel>
Group administrator
Sun 15 Dec 2019 02:39:01 PM UTC, comment #34: 

I assume the stop reason was still the same with the patch applied?

To narrow down the cause a little bit, could you please try which of the following causes the error (if any):

graphics_toolkit gnuplot
clear functions
plot (randn (5))

or:

graphics_toolkit gnuplot
clear global
plot (randn (5))


Markus Mützel <mmuetzel>
Group administrator
Sun 15 Dec 2019 10:00:07 AM UTC, comment #33: 


comment #31:

> Thanks. Was this with or without the patch from comment #28?


results in comment #29 and comment #30 are without the patch.
comment #32 is with the patch applied.


Carlo de Falco <cdf>
Group Member
Sun 15 Dec 2019 09:57:38 AM UTC, comment #32: 

comment #28:

> Could you please try if you still see the error with the attached patch (with little hope it will fix anything)?
>
> (file #48060)



Here's the result of running with your patch applied :


frame #0: 0x000000010ba2d89b liboctinterp.7.dylib`octave::graphics_toolkit::initialize(this=0x00007ffee4f33e90, go=0x00007ffee4f33f18) at graphics-toolkit.h:252:21
   249             // Notifies graphics toolkit that new object was created.
   250             bool initialize (const graphics_object& go)
   251             {
-> 252               return m_rep->initialize (go);
   253             }
   254
   255             bool initialize (const graphics_handle& h)
(lldb) up
frame #1: 0x000000010b9d178d liboctinterp.7.dylib`base_graphics_object::initialize(this=0x00007fa93386da00, go=0x00007ffee4f33f18) at graphics.h:2886:27
   2883            if (! toolkit_flag)
   2884              {
   2885                octave::graphics_toolkit tk = get_toolkit ();
-> 2886                toolkit_flag = tk.initialize (go);
   2887              }
   2888          }
   2889
(lldb) down
frame #0: 0x000000010ba2d89b liboctinterp.7.dylib`octave::graphics_toolkit::initialize(this=0x00007ffee4f33e90, go=0x00007ffee4f33f18) at graphics-toolkit.h:252:21
   249             // Notifies graphics toolkit that new object was created.
   250             bool initialize (const graphics_object& go)
   251             {
-> 252               return m_rep->initialize (go);
   253             }
   254
   255             bool initialize (const graphics_handle& h)
(lldb) p m_rep
(std::__1::shared_ptr<octave::base_graphics_toolkit>) $0 = std::__1::shared_ptr<octave::base_graphics_toolkit>::element_type @ 0x00007fa9358d1d20 strong=3 weak=1 {
  __ptr_ = 0x00007fa9358d1d20
}
(lldb) p go
(const graphics_object) $1 = {
  rep = std::__1::shared_ptr<base_graphics_object>::element_type @ 0x00007fa93386da00 strong=2 weak=1 {
    __ptr_ = 0x00007fa93386da00
  }
}


Carlo de Falco <cdf>
Group Member
Sun 15 Dec 2019 09:39:13 AM UTC, comment #31: 

Thanks. Was this with or without the patch from comment #28?

Markus Mützel <mmuetzel>
Group administrator
Sun 15 Dec 2019 09:32:12 AM UTC, comment #30: 

Something rather surprising that I found out while testing
for bug #56908

if I build with fltk enabled (by adding the "--without-qt" but omitting the "--without-fltk" option for configure)

the segfault when plotting with gnuplot does not occur, i.e.


>> available_graphics_toolkits
ans =
{
  [1,1] = fltk
  [1,2] = gnuplot
}
>> graphics_toolkit gnuplot
>> clear all
>> plot (randn (5))
>> clear all
>> plot (randn (5))

 
produces no segfault

Carlo de Falco <cdf>
Group Member
Sun 15 Dec 2019 09:20:04 AM UTC, comment #29: 

comment #28:


> This time, the access error occurred in a different function than in the other backtraces.


sorry that is because I triggered the segfault with a different
sequence of commands, i.e. "plot (randn (5)); clear all; plot (randn (5))"

This is instead what I get with the same commands as in comment #23 :


Process 26762 resuming
Process 26762 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x11a9bd6e8)
    frame #0: 0x000000011001889b liboctinterp.7.dylib`octave::graphics_toolkit::initialize(this=0x00007ffee094ce90, go=0x00007ffee094cf18) at graphics-toolkit.h:252:21
   249             // Notifies graphics toolkit that new object was created.
   250             bool initialize (const graphics_object& go)
   251             {
-> 252               return m_rep->initialize (go);
   253             }
   254
   255             bool initialize (const graphics_handle& h)
Target 0: (octave-cli) stopped.


and here is the result for inspecting the variables :


(lldb) p m_rep
(std::__1::shared_ptr<octave::base_graphics_toolkit>) $0 = std::__1::shared_ptr<octave::base_graphics_toolkit>::element_type @ 0x00007fc93b785fe0 strong=3 weak=1 {
  __ptr_ = 0x00007fc93b785fe0
}
(lldb) p go
(const graphics_object) $1 = {
  rep = std::__1::shared_ptr<base_graphics_object>::element_type @ 0x00007fc93d00f600 strong=2 weak=1 {
    __ptr_ = 0x00007fc93d00f600
  }
}
(lldb)


Carlo de Falco <cdf>
Group Member
Sat 14 Dec 2019 11:17:17 AM UTC, comment #28: 

That doesn't look immediately like an invalid pointer to me. Also the reference counts are > 0. So it shouldn't have been deleted.

This time, the access error occurred in a different function than in the other backtraces.
Looking at what the functions have in common, I wonder if this could be a lifetime issue. Could you please try if you still see the error with the attached patch (with little hope it will fix anything)?

Could you please also inspect the other objects when the error occurred (also execute "p go" ...)? Tbh, I don't understand yet why this fails.

(file #48060)

Markus Mützel <mmuetzel>
Group administrator
Sat 14 Dec 2019 09:53:29 AM UTC, comment #27: 

comment #26:

> Could you please check the value of m_rep when lldb stops with the error (see jwe's comment #12)?
> Write "p m_rep" at the lldb prompt and show the results. Is it a very low or very high number?



Here it is :


Process 10441 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1107b06e0)
    frame #0: 0x0000000105d9c2d1 liboctinterp.7.dylib`octave::graphics_toolkit::update(this=0x00007ffeeabccdc8, go=0x00007ffeeabcce60, id=20) at graphics-toolkit.h:241:14
   238             // Notifies graphics toolkit that object't property has changed.
   239             void update (const graphics_object& go, int id)
   240             {
-> 241               m_rep->update (go, id);
   242             }
   243
   244             void update (const graphics_handle& h, int id)
Target 0: (octave-cli) stopped.
(lldb) p m_rep
(std::__1::shared_ptr<octave::base_graphics_toolkit>) $0 = std::__1::shared_ptr<octave::base_graphics_toolkit>::element_type @ 0x00007f813de27cf0 strong=3 weak=1 {
  __ptr_ = 0x00007f813de27cf0
}
(lldb)


Carlo de Falco <cdf>
Group Member
Fri 13 Dec 2019 04:00:18 PM UTC, comment #26: 

Could you please check the value of m_rep when lldb stops with the error (see jwe's comment #12)?
Write "p m_rep" at the lldb prompt and show the results. Is it a very low or very high number?

Markus Mützel <mmuetzel>
Group administrator
Fri 13 Dec 2019 03:13:30 PM UTC, comment #25: 

I guess it is no surprise given the massive amount of changes in the development branch, but I just checked and found that this problem does not affect the stable branch.

Carlo de Falco <cdf>
Group Member
Fri 22 Nov 2019 10:46:07 AM UTC, comment #24: 

the stack trace looks unchanged to me


* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x11421b6e8)
    frame #0: 0x000000010900532b liboctinterp.7.dylib`octave::graphics_toolkit::initialize(this=0x00007ffee7960f20, go=0x00007ffee7960fa8) at graphics-toolkit.h:252:21
   249             // Notifies graphics toolkit that new object was created.
   250             bool initialize (const graphics_object& go)
   251             {
-> 252               return m_rep->initialize (go);
   253             }
   254
   255             bool initialize (const graphics_handle& h)
Target 0: (octave-cli) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x11421b6e8)
  * frame #0: 0x000000010900532b liboctinterp.7.dylib`octave::graphics_toolkit::initialize(this=0x00007ffee7960f20, go=0x00007ffee7960fa8) at graphics-toolkit.h:252:21
    frame #1: 0x0000000108fa8b0d liboctinterp.7.dylib`base_graphics_object::initialize(this=0x00007fccc1044400, go=0x00007ffee7960fa8) at graphics.h:2883:37
    frame #2: 0x0000000108fc1a11 liboctinterp.7.dylib`graphics_object::initialize(this=0x00007ffee7960fa8) at graphics.h:3110:33
    frame #3: 0x0000000108fa8be5 liboctinterp.7.dylib`xinitialize(h=0x00007ffee7961268) at graphics.cc:3194:8
    frame #4: 0x0000000108fc8dac liboctinterp.7.dylib`F__go_figure__(interp=0x00007fccc1007c00, args=0x00007ffee7961d58, (null)=1) at graphics.cc:13212:7
    frame #5: 0x00000001087c484f liboctinterp.7.dylib`octave_builtin::call(this=0x00007fccbfe3f860, tw=0x00007fccc1008740, nargout=1, args=0x00007ffee7961d58) at ov-builtin.cc:68:16
    frame #6: 0x0000000108b72db8 liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fccbfeab040, tw=0x00007fccc1008740, nargout=1) at pt-idx.cc:518:35
    frame #7: 0x0000000108b74552 liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=0x00007fccbfeab040, tw=0x00007fccc1008740, nargout=1) at pt-idx.h:106:34
    frame #8: 0x0000000108aebeee liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(this=0x00007fccbfeab210, tw=0x00007fccc1008740, (null)=0) at pt-assign.cc:98:43
    frame #9: 0x0000000108b1c478 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfec32d0) at pt-eval.cc:2724:49
    frame #10: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfec32d0, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #11: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfeab250) at pt-eval.cc:2783:18
    frame #12: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfeab250, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #13: 0x0000000108b1bcee liboctinterp.7.dylib`octave::tree_evaluator::visit_if_command_list(this=0x00007fccc1008740, lst=0x00007fccbfedb1f0) at pt-eval.cc:2577:25
    frame #14: 0x0000000108b1bb71 liboctinterp.7.dylib`octave::tree_if_command_list::accept(this=0x00007fccbfedb1f0, tw=0x00007fccc1008740) at pt-select.h:115:10
    frame #15: 0x0000000108b1bb24 liboctinterp.7.dylib`octave::tree_evaluator::visit_if_command(this=0x00007fccc1008740, cmd=0x00007fccbfedbd80) at pt-eval.cc:2555:12
    frame #16: 0x0000000108b90611 liboctinterp.7.dylib`octave::tree_if_command::accept(this=0x00007fccbfedbd80, tw=0x00007fccc1008740) at pt-select.h:148:10
    frame #17: 0x0000000108b1c38f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfedbdb0) at pt-eval.cc:2702:20
    frame #18: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfedbdb0, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #19: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfeb1b10) at pt-eval.cc:2783:18
    frame #20: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfeb1b10, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #21: 0x0000000108b1ada4 liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(this=0x00007fccc1008740, user_function=0x00007fccbfeadfa0, nargout=1, xargs=0x00007ffee7963298, closure_frames=0x0000000000000000) at pt-eval.cc:2444:19
    frame #22: 0x000000010895e24a liboctinterp.7.dylib`octave_user_function::call(this=0x00007fccbfeadfa0, tw=0x00007fccc1008740, nargout=1, args=0x00007ffee7963298, closure_frames=0x0000000000000000) at ov-usr-fcn.cc:467:13
    frame #23: 0x0000000108961555 liboctinterp.7.dylib`octave_user_function::call(this=0x00007fccbfeadfa0, tw=0x00007fccc1008740, nargout=1, args=0x00007ffee7963298) at ov-usr-fcn.h:373:12
    frame #24: 0x0000000108b72db8 liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fccbfeb8d30, tw=0x00007fccc1008740, nargout=1) at pt-idx.cc:518:35
    frame #25: 0x0000000108b74552 liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=0x00007fccbfeb8d30, tw=0x00007fccc1008740, nargout=1) at pt-idx.h:106:34
    frame #26: 0x0000000108aebeee liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(this=0x00007fccbfec56e0, tw=0x00007fccc1008740, (null)=0) at pt-assign.cc:98:43
    frame #27: 0x0000000108b1c478 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfeb8b50) at pt-eval.cc:2724:49
    frame #28: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfeb8b50, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #29: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfec5720) at pt-eval.cc:2783:18
    frame #30: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfec5720, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #31: 0x0000000108b1bcee liboctinterp.7.dylib`octave::tree_evaluator::visit_if_command_list(this=0x00007fccc1008740, lst=0x00007fccbfec5800) at pt-eval.cc:2577:25
    frame #32: 0x0000000108b1bb71 liboctinterp.7.dylib`octave::tree_if_command_list::accept(this=0x00007fccbfec5800, tw=0x00007fccc1008740) at pt-select.h:115:10
    frame #33: 0x0000000108b1bb24 liboctinterp.7.dylib`octave::tree_evaluator::visit_if_command(this=0x00007fccc1008740, cmd=0x00007fccbfec5af0) at pt-eval.cc:2555:12
    frame #34: 0x0000000108b90611 liboctinterp.7.dylib`octave::tree_if_command::accept(this=0x00007fccbfec5af0, tw=0x00007fccc1008740) at pt-select.h:148:10
    frame #35: 0x0000000108b1c38f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfec5b20) at pt-eval.cc:2702:20
    frame #36: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfec5b20, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #37: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfeb85d0) at pt-eval.cc:2783:18
    frame #38: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfeb85d0, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #39: 0x0000000108b1bcee liboctinterp.7.dylib`octave::tree_evaluator::visit_if_command_list(this=0x00007fccc1008740, lst=0x00007fccbfec5c20) at pt-eval.cc:2577:25
    frame #40: 0x0000000108b1bb71 liboctinterp.7.dylib`octave::tree_if_command_list::accept(this=0x00007fccbfec5c20, tw=0x00007fccc1008740) at pt-select.h:115:10
    frame #41: 0x0000000108b1bb24 liboctinterp.7.dylib`octave::tree_evaluator::visit_if_command(this=0x00007fccc1008740, cmd=0x00007fccbfec6540) at pt-eval.cc:2555:12
    frame #42: 0x0000000108b90611 liboctinterp.7.dylib`octave::tree_if_command::accept(this=0x00007fccbfec6540, tw=0x00007fccc1008740) at pt-select.h:148:10
    frame #43: 0x0000000108b1c38f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfec6570) at pt-eval.cc:2702:20
    frame #44: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfec6570, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #45: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfeda340) at pt-eval.cc:2783:18
    frame #46: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfeda340, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #47: 0x0000000108b1ada4 liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(this=0x00007fccc1008740, user_function=0x00007fccbff0a1d0, nargout=1, xargs=0x00007ffee7964a08, closure_frames=0x0000000000000000) at pt-eval.cc:2444:19
    frame #48: 0x000000010895e24a liboctinterp.7.dylib`octave_user_function::call(this=0x00007fccbff0a1d0, tw=0x00007fccc1008740, nargout=1, args=0x00007ffee7964a08, closure_frames=0x0000000000000000) at ov-usr-fcn.cc:467:13
    frame #49: 0x0000000108961555 liboctinterp.7.dylib`octave_user_function::call(this=0x00007fccbff0a1d0, tw=0x00007fccc1008740, nargout=1, args=0x00007ffee7964a08) at ov-usr-fcn.h:373:12
    frame #50: 0x0000000108b72db8 liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fccbfed43e0, tw=0x00007fccc1008740, nargout=1) at pt-idx.cc:518:35
    frame #51: 0x0000000108b74552 liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=0x00007fccbfed43e0, tw=0x00007fccc1008740, nargout=1) at pt-idx.h:106:34
    frame #52: 0x0000000108aebeee liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(this=0x00007fccbfed44f0, tw=0x00007fccc1008740, (null)=0) at pt-assign.cc:98:43
    frame #53: 0x0000000108b1c478 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfed41a0) at pt-eval.cc:2724:49
    frame #54: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfed41a0, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #55: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfed4530) at pt-eval.cc:2783:18
    frame #56: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfed4530, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #57: 0x0000000108b1d92e liboctinterp.7.dylib`octave::tree_evaluator::visit_unwind_protect_command(this=0x00007fccc1008740, cmd=0x00007fccbfed66a0) at pt-eval.cc:3036:34
    frame #58: 0x0000000108b5c901 liboctinterp.7.dylib`octave::tree_unwind_protect_command::accept(this=0x00007fccbfed66a0, tw=0x00007fccc1008740) at pt-except.h:148:10
    frame #59: 0x0000000108b1c38f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfed66e0) at pt-eval.cc:2702:20
    frame #60: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfed66e0, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #61: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfed2a20) at pt-eval.cc:2783:18
    frame #62: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfed2a20, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #63: 0x0000000108b1ada4 liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(this=0x00007fccc1008740, user_function=0x00007fccbfed6fc0, nargout=0, xargs=0x00007ffee7965ef8, closure_frames=0x0000000000000000) at pt-eval.cc:2444:19
    frame #64: 0x000000010895e24a liboctinterp.7.dylib`octave_user_function::call(this=0x00007fccbfed6fc0, tw=0x00007fccc1008740, nargout=0, args=0x00007ffee7965ef8, closure_frames=0x0000000000000000) at ov-usr-fcn.cc:467:13
    frame #65: 0x0000000108961555 liboctinterp.7.dylib`octave_user_function::call(this=0x00007fccbfed6fc0, tw=0x00007fccc1008740, nargout=0, args=0x00007ffee7965ef8) at ov-usr-fcn.h:373:12
    frame #66: 0x0000000108b72db8 liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fccbfed09b0, tw=0x00007fccc1008740, nargout=0) at pt-idx.cc:518:35
    frame #67: 0x0000000108b74552 liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=0x00007fccbfed09b0, tw=0x00007fccc1008740, nargout=0) at pt-idx.h:106:34
    frame #68: 0x0000000108b1c478 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fccc1008740, stmt=0x00007fccbfed0ac0) at pt-eval.cc:2724:49
    frame #69: 0x0000000108b91e71 liboctinterp.7.dylib`octave::tree_statement::accept(this=0x00007fccbfed0ac0, tw=0x00007fccc1008740) at pt-stmt.h:121:10
    frame #70: 0x0000000108b1c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fccc1008740, lst=0x00007fccbfed0af0) at pt-eval.cc:2783:18
    frame #71: 0x000000010871acc1 liboctinterp.7.dylib`octave::tree_statement_list::accept(this=0x00007fccbfed0af0, tw=0x00007fccc1008740) at pt-stmt.h:198:10
    frame #72: 0x0000000108b0f3c4 liboctinterp.7.dylib`octave::tree_evaluator::eval(this=0x00007fccc1008740, stmt_list=std::__1::shared_ptr<octave::tree_statement_list>::element_type @ 0x00007fccbfed0af0 strong=2 weak=1, interactive=true) at pt-eval.cc:398:20
    frame #73: 0x0000000109075fad liboctinterp.7.dylib`octave::interpreter::main_loop(this=0x00007fccc1007c00) at interpreter.cc:1113:33
    frame #74: 0x0000000109074957 liboctinterp.7.dylib`octave::interpreter::execute(this=0x00007fccc1007c00) at interpreter.cc:795:27
    frame #75: 0x00000001082ab39d liboctinterp.7.dylib`octave::cli_application::execute(this=0x00007ffee7966740) at octave.cc:376:25
    frame #76: 0x00000001082988ad octave-cli`main(argc=9, argv=0x00007ffee7966940) at main-cli.cc:92:14
    frame #77: 0x00007fff759d73d5 libdyld.dylib`start + 1
(lldb)


Carlo de Falco <cdf>
Group Member
Fri 22 Nov 2019 10:42:28 AM UTC, comment #23: 

@jwe

Your change does unfortunately not fix the issue


octave:1> __octave_config_info__ hg_id
ans = 8600f5ea1ec1
octave:2> graphics_toolkit gnuplot
octave:3> clear all
octave:4> plot (randn (5))
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11


But I agree with Rik that it is a nice change anyway, I'll
get a new stack trace to see if anything has changed there.

Thanks,
c.

Carlo de Falco <cdf>
Group Member
Thu 21 Nov 2019 11:25:45 PM UTC, comment #22: 

Even if it doesn't fix this issue, I'm excited whenever we can move bits of the Octave core on to the standard C++ libraries.  I tested on Linux and no regressions.

Rik <rik5>
Group administrator
Thu 21 Nov 2019 10:25:42 PM UTC, comment #21: 

From looking at the stack trace in comment #11, it seems like the graphics_toolkit::rep pointer is invalid.  Does the following changeset help?

  http://hg.savannah.gnu.org/hgweb/octave/rev/da163456abb3

If this change doesn't solve the problem, maybe it will point more clearly at where the invalid pointer is coming from?  In any case, it's a change that should probably be made since using std::shared_ptr is a better solution than using our own reference counting.

John W. Eaton <jwe>
Group administrator
Thu 21 Nov 2019 04:46:26 PM UTC, comment #20: 

I don't see any access errors for


graphics_toolkit gnuplot
clear all
plot (randn (5))


using a copy of  Octave build with the address sanitizer enabled.  But I'm on a Debian system, so I suppose there could still be a mac-specific problem here.

Since this crash is happening with gnuplot, I would not expect it to be a threading issue because gnuplot executes as a separate process rather than using threads.

John W. Eaton <jwe>
Group administrator
Thu 21 Nov 2019 07:37:31 AM UTC, comment #19: 

comment #18:

> Did changeset 27709 have any effect?  It seemed to clear up some occasional failures of the buildbots when running Fedora, and I was hoping it might also resolve this issue.



Unfortunately it seems it did not:


>> __octave_config_info__ hg_id
ans = 718845eb3c7a
>> graphics_toolkit gnuplot
>> clear all
>> plot (randn (5))
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11



Carlo de Falco <cdf>
Group Member
Wed 20 Nov 2019 03:28:51 PM UTC, comment #18: 

Did changeset 27709 have any effect?  It seemed to clear up some occasional failures of the buildbots when running Fedora, and I was hoping it might also resolve this issue.

Rik <rik5>
Group administrator
Wed 20 Nov 2019 09:35:10 AM UTC, comment #17: 

Rik,

The sequence to reproduce the crash is either


octave:1> graphics_toolkit gnuplot
octave:2> clear all
octave:3> plot (randn (5))
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11


or


octave:1> plot (randn (5))
octave:2> clear all
octave:3> plot (randn (5))
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11


In the meanwhile I have understood better how to attach lldb to a running octave, so if there is anything I could try from within the debugger to provide more info please let me know

Carlo de Falco <cdf>
Group Member
Tue 19 Nov 2019 05:02:26 PM UTC, comment #16: 

Just to make sure, the sequence to cause the segfault is now


./run-octave -f
graphics_toolkit gnuplot
clear all
plot (randn (5))
plot (randn (5))


Did changeset 27709 (mutable keyword for graphics toolkit) change anything?

Rik <rik5>
Group administrator
Mon 18 Nov 2019 04:37:20 PM UTC, comment #15: 


comment #14:

> @jwe
>
> actually if I run "./run-octave -f" I need to do "clear all"
> twice to get the crash.
>


actually its the plot that has to be repeated, not the clear all.



Carlo de Falco <cdf>
Group Member
Mon 18 Nov 2019 04:36:15 PM UTC, comment #14: 

@jwe

actually if I run "./run-octave -f" I need to do "clear all"
twice to get the crash.

This is probably because my ~/.octaverc has
"graphics_toolkit gnuplot" in it

indeed with "./run-octave -f" I need to do either


octave:1> graphics_toolkit gnuplot
octave:2> clear all
octave:3> plot (randn (5))


or


ooctave:1> plot (randn (5))
octave:2> clear all
octave:3> plot (randn (5))


to get the segfault

Carlo de Falco <cdf>
Group Member
Mon 18 Nov 2019 04:15:26 PM UTC, comment #13: 

@jwe

I am running with "./run-octave -f" is this enough to ensure .octaverc is not being run?

I do have some packages installed but 'pkg list' reports that none has been loaded


Carlo de Falco <cdf>
Group Member
Mon 18 Nov 2019 03:34:43 PM UTC, comment #12: 

What is the value of rep at that point?

I built without fltk or qt and don't see the problem on my debian system.

Are you loading any packages or executing any code that could create new new data types?  Judging from the location of the crash, I don't think new data types are the issue, but I want to eliminate any issues other than plotting.



John W. Eaton <jwe>
Group administrator
Mon 18 Nov 2019 03:16:58 PM UTC, comment #11: 

actually, by running in the source directory rather than from installation directory I do see source code references in lldb

here's what I get with 'clear all; plot (randn (5))'


Process 34130 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1059ed350)
    frame #0: 0x0000000100c2f831 liboctinterp.7.dylib`base_graphics_object::initialize(graphics_object const&) [inlined] graphics_toolkit::initialize(this=0x00007fd320f10b80, go=0x00007ffeef76c810) at graphics-toolkit.h:219:17 [opt]
   216
   217           // Notifies graphics toolkit that new object was created.
   218           bool initialize (const graphics_object& go)
-> 219           { return rep->initialize (go); }
   220
   221           bool initialize (const graphics_handle& h)
   222           { return rep->initialize (h); }
Target 0: (octave-cli) stopped.



(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1059ed350)
  * frame #0: 0x0000000100c2f831 liboctinterp.7.dylib`base_graphics_object::initialize(graphics_object const&) [inlined] graphics_toolkit::initialize(this=0x00007fd320f10b80, go=0x00007ffeef76c810) at graphics-toolkit.h:219:17 [opt]
    frame #1: 0x0000000100c2f827 liboctinterp.7.dylib`base_graphics_object::initialize(this=0x00007fd321884a00, go=0x00007ffeef76c810) at graphics.h:2883 [opt]
    frame #2: 0x0000000100c2f9a2 liboctinterp.7.dylib`xinitialize(octave_handle const&) [inlined] graphics_object::initialize(this=0x00007fd321884a00) at graphics.h:3110:33 [opt]
    frame #3: 0x0000000100c2f992 liboctinterp.7.dylib`xinitialize(h=0x00007ffeef76c9c0) at graphics.cc:3194 [opt]
    frame #4: 0x0000000100c4eabe liboctinterp.7.dylib`F__go_figure__(interp=<unavailable>, args=<unavailable>, (null)=<unavailable>) at graphics.cc:13158:7 [opt]
    frame #5: 0x000000010079a4e7 liboctinterp.7.dylib`octave_builtin::call(this=0x00007fd320e76ec0, tw=<unavailable>, nargout=1, args=0x00007ffeef76cbe0) at ov-builtin.cc:68:16 [opt]
    frame #6: 0x00000001009588db liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fd3231ca890, tw=0x00007fd32180d340, nargout=1) at pt-idx.cc:518:35 [opt]
    frame #7: 0x000000010095ab9d liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>) at pt-idx.h:106:34 [opt]
    frame #8: 0x00000001009353bd liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(this=0x00007fd3231caa60, tw=0x00007fd32180d340, (null)=<unavailable>) at pt-assign.cc:98:43 [opt]
    frame #9: 0x000000010094b8db liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2734:49 [opt]
    frame #10: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #11: 0x000000010094b85f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2712:20 [opt]
    frame #12: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #13: 0x000000010094a0ed liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) [inlined] octave::tree_statement_list::accept(this=0x00007fd3231de340, tw=0x00007fd32180d340) at pt-stmt.h:198:10 [opt]
    frame #14: 0x000000010094a0da liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(this=<unavailable>, user_function=0x00007fd3231d7a80, nargout=1, xargs=<unavailable>, closure_frames=0x0000000101066668) at pt-eval.cc:2454 [opt]
    frame #15: 0x00000001008773a7 liboctinterp.7.dylib`octave_user_function::call(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>, args=<unavailable>, closure_frames=<unavailable>) at ov-usr-fcn.cc:467:13 [opt]
    frame #16: 0x000000010087a455 liboctinterp.7.dylib`octave_user_function::call(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>, args=<unavailable>) at ov-usr-fcn.h:373:12 [opt]
    frame #17: 0x00000001009588db liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fd320d64f60, tw=0x00007fd32180d340, nargout=1) at pt-idx.cc:518:35 [opt]
    frame #18: 0x000000010095ab9d liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>) at pt-idx.h:106:34 [opt]
    frame #19: 0x00000001009353bd liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(this=0x00007fd320d65090, tw=0x00007fd32180d340, (null)=<unavailable>) at pt-assign.cc:98:43 [opt]
    frame #20: 0x000000010094b8db liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2734:49 [opt]
    frame #21: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #22: 0x000000010094b85f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2712:20 [opt]
    frame #23: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #24: 0x000000010094b85f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2712:20 [opt]
    frame #25: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #26: 0x000000010094a0ed liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) [inlined] octave::tree_statement_list::accept(this=0x00007fd320d5db10, tw=0x00007fd32180d340) at pt-stmt.h:198:10 [opt]
    frame #27: 0x000000010094a0da liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(this=<unavailable>, user_function=0x00007fd320da1d90, nargout=1, xargs=<unavailable>, closure_frames=0x0000000101066668) at pt-eval.cc:2454 [opt]
    frame #28: 0x00000001008773a7 liboctinterp.7.dylib`octave_user_function::call(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>, args=<unavailable>, closure_frames=<unavailable>) at ov-usr-fcn.cc:467:13 [opt]
    frame #29: 0x000000010087a455 liboctinterp.7.dylib`octave_user_function::call(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>, args=<unavailable>) at ov-usr-fcn.h:373:12 [opt]
    frame #30: 0x00000001009588db liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fd320d4f330, tw=0x00007fd32180d340, nargout=1) at pt-idx.cc:518:35 [opt]
    frame #31: 0x000000010095ab9d liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>) at pt-idx.h:106:34 [opt]
    frame #32: 0x00000001009353bd liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(this=0x00007fd320d4f440, tw=0x00007fd32180d340, (null)=<unavailable>) at pt-assign.cc:98:43 [opt]
    frame #33: 0x000000010094b8db liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2734:49 [opt]
    frame #34: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #35: 0x000000010094c786 liboctinterp.7.dylib`octave::tree_evaluator::visit_unwind_protect_command(octave::tree_unwind_protect_command&) [inlined] octave::tree_statement_list::accept(this=<unavailable>, tw=<unavailable>) at pt-stmt.h:198:10 [opt]
    frame #36: 0x000000010094c779 liboctinterp.7.dylib`octave::tree_evaluator::visit_unwind_protect_command(this=0x00007fd32180d340, cmd=<unavailable>) at pt-eval.cc:3046 [opt]
    frame #37: 0x000000010094b85f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2712:20 [opt]
    frame #38: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #39: 0x000000010094a0ed liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) [inlined] octave::tree_statement_list::accept(this=0x00007fd320d4d9d0, tw=0x00007fd32180d340) at pt-stmt.h:198:10 [opt]
    frame #40: 0x000000010094a0da liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(this=<unavailable>, user_function=0x00007fd320d503e0, nargout=0, xargs=<unavailable>, closure_frames=0x0000000101066668) at pt-eval.cc:2454 [opt]
    frame #41: 0x00000001008773a7 liboctinterp.7.dylib`octave_user_function::call(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>, args=<unavailable>, closure_frames=<unavailable>) at ov-usr-fcn.cc:467:13 [opt]
    frame #42: 0x000000010087a455 liboctinterp.7.dylib`octave_user_function::call(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>, args=<unavailable>) at ov-usr-fcn.h:373:12 [opt]
    frame #43: 0x00000001009588db liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(this=0x00007fd320d75570, tw=0x00007fd32180d340, nargout=0) at pt-idx.cc:518:35 [opt]
    frame #44: 0x000000010095ab9d liboctinterp.7.dylib`octave::tree_index_expression::evaluate(this=<unavailable>, tw=<unavailable>, nargout=<unavailable>) at pt-idx.h:106:34 [opt]
    frame #45: 0x000000010094b8db liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(this=0x00007fd32180d340, stmt=<unavailable>) at pt-eval.cc:2734:49 [opt]
    frame #46: 0x000000010094ba8f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(this=0x00007fd32180d340, lst=<unavailable>) at pt-eval.cc:2793:18 [opt]
    frame #47: 0x000000010093fc99 liboctinterp.7.dylib`octave::tree_evaluator::eval(std::__1::shared_ptr<octave::tree_statement_list>&, bool) [inlined] octave::tree_statement_list::accept(this=<unavailable>, tw=<unavailable>) at pt-stmt.h:198:10 [opt]
    frame #48: 0x000000010093fc90 liboctinterp.7.dylib`octave::tree_evaluator::eval(this=0x00007fd32180d340, stmt_list=<unavailable>, interactive=<unavailable>) at pt-eval.cc:398 [opt]
    frame #49: 0x0000000100ca6581 liboctinterp.7.dylib`octave::interpreter::main_loop(this=0x00007fd32180c800) at interpreter.cc:1113:33 [opt]
    frame #50: 0x0000000100ca51a8 liboctinterp.7.dylib`octave::interpreter::execute(this=0x00007fd32180c800) at interpreter.cc:795:27 [opt]
    frame #51: 0x000000010049b838 liboctinterp.7.dylib`octave::cli_application::execute(this=0x00007ffeef76e680) at octave.cc:376:25 [opt]
    frame #52: 0x00000001004907ed octave-cli`main(argc=8, argv=0x00007ffeef76e8c0) at main-cli.cc:92:14 [opt]
    frame #53: 0x00007fff759d73d5 libdyld.dylib`start + 1
(lldb)


Carlo de Falco <cdf>
Group Member
Mon 18 Nov 2019 03:06:47 PM UTC, comment #10: 

comment #9:

> What does "graphics_toolkit" return before and after "clear all"?



>> graphics_toolkit
ans = gnuplot
>> clear all
>> graphics_toolkit
ans = gnuplot


comment #9:

> What is get (0, "defaultfigure__graphics_toolkit__") before and after "clear all"?



>> get (0, "defaultfigure__graphics_toolkit__")
ans = gnuplot
>> clear all
>> get (0, "defaultfigure__graphics_toolkit__")
ans = gnuplot
>> exit


comment #9:

> What does "available_graphics_toolkits" return?



>> clear all
>> available_graphics_toolkits
ans =
{
  [1,1] = gnuplot
}


comment #9:

> Does it also cause a segfault after "clear all"?


No, it doesn't. But I do get a segfault if I type 'exit' after 'clear all' and any of the above commands

comment #9:

> Can you compile without stripping the symbols and get the backtrace from the error again?


Actually I think I have, I compiled everything with '-g -O0' and disabled stripping (which does not work on macos anyway) so I don't know exactly why references to source code are missing but debugging Octave on macos is notoriously difficult

Carlo de Falco <cdf>
Group Member
Mon 18 Nov 2019 02:14:50 PM UTC, comment #9: 

What does "graphics_toolkit" return before and after "clear all"? What is get (0, "defaultfigure__graphics_toolkit__") before and after "clear all"?
What does "available_graphics_toolkits" return? Does it also cause a segfault after "clear all"?

Can you compile without stripping the symbols and get the backtrace from the error again?

Markus Mützel <mmuetzel>
Group administrator
Mon 18 Nov 2019 01:28:49 PM UTC, comment #8: 

If nobody with other OSes is seing anything similar this must be a mac specific issue.

Can anyone else with a mac confirm the same issue?

In the meanwhile, I think I managed to run Octave within lldb to get a backtrace of the crash:


(lldb) bt
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1065f4300)
  * frame #0: 0x0000000100748c60 liboctinterp.7.dylib`figure::properties::set_toolkit(graphics_toolkit const&) + 368
    frame #1: 0x0000000100770014 liboctinterp.7.dylib`figure::properties::set___graphics_toolkit__(octave_value const&) + 660
    frame #2: 0x000000010076ddcb liboctinterp.7.dylib`figure::properties::set(caseless_str const&, octave_value const&) + 6011
    frame #3: 0x0000000100893b8f liboctinterp.7.dylib`figure::set(caseless_str const&, octave_value const&) + 447
    frame #4: 0x0000000100750f19 liboctinterp.7.dylib`base_properties::set_from_list(base_graphics_object&, property_list&) + 153
    frame #5: 0x00000001007522c5 liboctinterp.7.dylib`base_properties::override_defaults(base_graphics_object&) + 341
    frame #6: 0x00000001008939b6 liboctinterp.7.dylib`figure::override_defaults(base_graphics_object&) + 22
    frame #7: 0x000000010084e4ba liboctinterp.7.dylib`gh_manager::make_graphics_handle(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, octave_handle const&, bool, bool, bool) + 266
    frame #8: 0x00000001008856ee liboctinterp.7.dylib`F__go_figure__(octave::interpreter&, octave_value_list const&, int) + 1246
    frame #9: 0x00000001003d13d7 liboctinterp.7.dylib`octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) + 487
    frame #10: 0x000000010058f7fb liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) + 1355
    frame #11: 0x0000000100591abd liboctinterp.7.dylib`octave::tree_index_expression::evaluate(octave::tree_evaluator&, int) + 29
    frame #12: 0x000000010056c2dd liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(octave::tree_evaluator&, int) + 269
    frame #13: 0x00000001005827fb liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 267
    frame #14: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #15: 0x000000010058277f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 143
    frame #16: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #17: 0x000000010058100d liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) + 2205
    frame #18: 0x00000001004ae2c7 liboctinterp.7.dylib`octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&, octave::stack_frame*) + 23
    frame #19: 0x00000001004b1375 liboctinterp.7.dylib`octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&) + 21
    frame #20: 0x000000010058f7fb liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) + 1355
    frame #21: 0x0000000100591abd liboctinterp.7.dylib`octave::tree_index_expression::evaluate(octave::tree_evaluator&, int) + 29
    frame #22: 0x000000010056c2dd liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(octave::tree_evaluator&, int) + 269
    frame #23: 0x00000001005827fb liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 267
    frame #24: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #25: 0x000000010058277f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 143
    frame #26: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #27: 0x000000010058277f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 143
    frame #28: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #29: 0x000000010058100d liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) + 2205
    frame #30: 0x00000001004ae2c7 liboctinterp.7.dylib`octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&, octave::stack_frame*) + 23
    frame #31: 0x00000001004b1375 liboctinterp.7.dylib`octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&) + 21
    frame #32: 0x000000010058f7fb liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) + 1355
    frame #33: 0x0000000100591abd liboctinterp.7.dylib`octave::tree_index_expression::evaluate(octave::tree_evaluator&, int) + 29
    frame #34: 0x000000010056c2dd liboctinterp.7.dylib`octave::tree_simple_assignment::evaluate(octave::tree_evaluator&, int) + 269
    frame #35: 0x00000001005827fb liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 267
    frame #36: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #37: 0x00000001005836a6 liboctinterp.7.dylib`octave::tree_evaluator::visit_unwind_protect_command(octave::tree_unwind_protect_command&) + 86
    frame #38: 0x000000010058277f liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 143
    frame #39: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #40: 0x000000010058100d liboctinterp.7.dylib`octave::tree_evaluator::execute_user_function(octave_user_function&, int, octave_value_list const&, octave::stack_frame*) + 2205
    frame #41: 0x00000001004ae2c7 liboctinterp.7.dylib`octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&, octave::stack_frame*) + 23
    frame #42: 0x00000001004b1375 liboctinterp.7.dylib`octave_user_function::call(octave::tree_evaluator&, int, octave_value_list const&) + 21
    frame #43: 0x000000010058f7fb liboctinterp.7.dylib`octave::tree_index_expression::evaluate_n(octave::tree_evaluator&, int) + 1355
    frame #44: 0x0000000100591abd liboctinterp.7.dylib`octave::tree_index_expression::evaluate(octave::tree_evaluator&, int) + 29
    frame #45: 0x00000001005827fb liboctinterp.7.dylib`octave::tree_evaluator::visit_statement(octave::tree_statement&) + 267
    frame #46: 0x00000001005829af liboctinterp.7.dylib`octave::tree_evaluator::visit_statement_list(octave::tree_statement_list&) + 95
    frame #47: 0x0000000100576bb9 liboctinterp.7.dylib`octave::tree_evaluator::eval(std::__1::shared_ptr<octave::tree_statement_list>&, bool) + 25
    frame #48: 0x00000001008dd4a1 liboctinterp.7.dylib`octave::interpreter::main_loop() + 641
    frame #49: 0x00000001008dc0c8 liboctinterp.7.dylib`octave::interpreter::execute() + 264
    frame #50: 0x00000001000d2728 liboctinterp.7.dylib`octave::cli_application::execute() + 24
    frame #51: 0x00000001000017ed octave-cli-6.0.0`main + 957
    frame #52: 0x00007fff759d73d5 libdyld.dylib`start + 1
    frame #53: 0x00007fff759d73d5 libdyld.dylib`start + 1
(lldb)


Carlo de Falco <cdf>
Group Member
Sun 17 Nov 2019 11:45:08 PM UTC, comment #7: 

I tried


./configure --without-qt


and


./configure --without-qt --without-fltk


In both cases, I used


run-octave -f
clear all
plot (randn (5))
exit


without problems.  The '-f' option was to skip reading any initialization files in case there was a customization I had made that would influence results.

I think this is a Mac-specific issue.

Rik <rik5>
Group administrator
Sun 17 Nov 2019 11:07:13 PM UTC, comment #6: 

Bulding without Qt is rare.  I will try that combination and see if I can reproduce on Linux.

Rik <rik5>
Group administrator
Sun 17 Nov 2019 10:45:04 PM UTC, comment #5: 

I finished the build and still get


>> version
ans = 6.0.0
>> __octave_config_info__ hg_id
ans = 377f069841c1
>> clear all
>> plot (randn (5))
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11


it is important to note that I am building with Qt disabled
and using the gnuplot backend for the plot.

Has anyone tested with gnuplot? If this works for everyone else also with gnuplot maybe it is Mac specific?

Carlo de Falco <cdf>
Group Member
Sun 17 Nov 2019 10:10:32 PM UTC, comment #4: 

Rik, Markus,

you are right, my repo had a local patch applied implementing the changeset I had posted on bug #56752

I removed the patch and thus reverted to


 changeset:   27727:bd7decacf32e
 user:        Torsten Lilge <ttl-octave@mailbox.org>
 date:        Sun Nov 10 14:05:23 2019 +0100
 summary:     avoid unnecessary includes of gui-preferenceheader files


and I still see the same behavior.

I have now updated to 377f069841c1 and I am building again.

Carlo de Falco <cdf>
Group Member
Sun 17 Nov 2019 03:46:24 PM UTC, comment #3: 

This also works for me on Linux so, if anything, it is Mac-specific.

However, I can't find the changeset ID you are using.  I tried


hg log -r 7b15c8bded6f
abort: unknown revision '7b15c8bded6f'!


It is possible that you have a set of extra patches applied that are causing problems.


Rik <rik5>
Group administrator
Sun 17 Nov 2019 06:07:08 AM UTC, comment #2: 

I cannot reproduce either on Ubuntu with hg id d30fcff9bad3.
Seems to be Mac OS only.

I can't find the hg id you show in comment #0. Are there some additional patches applied? Do you know which "official" revision this was based on?

Markus Mützel <mmuetzel>
Group administrator
Sat 16 Nov 2019 11:34:38 PM UTC, comment #1: 

FTR, works fine for me on Windows.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 16 Nov 2019 09:18:43 PM UTC, original submission:  

I get this error consistently if I do either


>> plot (randn (5))
>> clear all
>> close all
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11


or



>> clear all
>> plot (randn (5))
fatal: caught signal Segmentation fault: 11 -- stopping myself...
Segmentation fault: 11


I am using


>> version
ans = 6.0.0
>> __octave_config_info__ hg_id
ans = 7b15c8bded6f
>>



built on macos mojave using macports for dependencies, but I wonder whether this occurs on other systems

Carlo de Falco <cdf>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48060:  bug57245_gtk.patch added by mmuetzel (1KiB - application/octet-stream)

 

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 rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by cdf (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-17 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-12-16 jwe StatusNone Ready For Test
    2019-12-15 mmuetzel CategoryPlotting with gnuplot Interpreter
        Operating SystemMac OS Any
        Summary&quot;clear all&quot; generates segfault if run before or after a plot "mlock" inside a compiled function locks the calling function instead
    2019-12-15 mmuetzel CategoryNone Plotting with gnuplot
    2019-12-14 mmuetzel Attached File- Added bug57245_gtk.patch, #48060

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code