bugGNU Octave - Bugs: bug #50014, Octave segmentation violation when...


bug #50014: Octave segmentation violation when duplicate nested functions exist

Submitter:  None
Submitted:  Tue 10 Jan 2017 01:50:37 PM UTC
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  miloserus Originator Email:  -email is unavailable-
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

Sat 21 Jan 2017 08:30:59 PM UTC, comment #17: 

After a new clone / rebuild / re-cross-build Octave passes all bug50014 tests on Windows.

Closing again.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 18 Jan 2017 06:42:51 PM UTC, comment #16: 

Changing the OS to Windows on the bug report.

Rik <rik5>
Group administrator
Wed 18 Jan 2017 05:46:14 PM UTC, comment #15: 

Reopening this bug for Windows.

On Win7, Octave-4.3.0+ reliably crashes upon the very first test in the share/octave/4.3.0+/etc/tests/fixed/bug-50014 subdir (= duplicate_nested_function.m).
Running this manually (from the subdir of F9 in the editor) also crashes Octave.

hg id Octave: 7c7a61c2e0ed (Replace out-of-date ...)
hg id mxe-octave: 52d2410929f4 (src/fftw ....)

mxe-octave configured with --enable-windows-64

Philip Nienhuis <philipnienhuis>
Group Member
Mon 16 Jan 2017 10:14:00 PM UTC, comment #14: 

Seems fine to me.  Thanks.

John W. Eaton <jwe>
Group administrator
Mon 16 Jan 2017 09:36:59 PM UTC, comment #13: 

Although I hate segfaults, I think this is a pretty rare case, and if this were never backported to stable it would be alright.  Certainly anyone using this will discover the problem immediately as it segfaults during the parse step.  I'm going to close the report for now.

Rik <rik5>
Group administrator
Mon 16 Jan 2017 09:12:03 PM UTC, comment #12: 

I pushed a fix to default so I think this bug is fixed there.  I'm not sure whether we should fix on stable (see comment #11).  If so, then we can either graft the change from default to stable, or come up with some other solution (I don't know what though, as I don't see a way to do it without changing a public interface).


John W. Eaton <jwe>
Group administrator
Sat 14 Jan 2017 03:48:54 PM UTC, comment #11: 

I added some additional tests (pushed to savannah).

My current iteration on a fix for the bug is attached here.  It is technically a modification of a public interface because it changes the data type of a public data member (base_parser::function_scopes).  So, should this only go on default, or is it OK for stable?  I doubt that anyone is using this data member directly, but I don't know if the change will cause trouble for other things.  Our goal is to allow .oct files compiled for 4.0.0 to be used with any 4.0.x Octave binary, but maybe this fix is more important than that?  I don't know.

Although the final fix is relatively small and straightforward, it took me a long time to get there and I'm still not really satisfied that it is the best fix, but it seems to work.

(file #39474)

John W. Eaton <jwe>
Group administrator
Fri 13 Jan 2017 05:21:19 PM UTC, comment #10: 

I added four tests in a new directory test/bug-50014 (http://hg.savannah.gnu.org/hgweb/octave/rev/28668bfd5b63).  You may have to adjust the error message that the tests check for after completing your fix.

The tests are in place, which means 'make check' will segfault for developers.  With your current patch applied I get no segfaults and 2/4 tests pass (the ones related to a duplicate between primary function name and either nested or subfunction fail).

Rik <rik5>
Group administrator
Fri 13 Jan 2017 02:31:02 PM UTC, comment #9: 


I have another idea about how to fix this problem that might not require a change in an external interface.

Could you turn these test cases into tests suitable for the test suite and go ahead and install them?  They can just cause test suite failures as I expect to be able to fix this problem today.

John W. Eaton <jwe>
Group administrator
Fri 13 Jan 2017 05:00:59 AM UTC, comment #8: 

The new patch works just fine for the original nested function example, and fixes the regression introduced around an ordinary parser error.  However, it still fails testbug2.m in comment #3.

The issue is that while duplicate nested functions and duplicate subfunctions are detected, any nested function or subfunction can still duplicate the primary function name.

For ease, I've uploaded testbug.m, testbug2.m, testbug3.m, testbug4.m which all test a different combination.  See the comment line at the top of each.

(file #39460, file #39461, file #39462, file #39463)

Rik <rik5>
Group administrator
Thu 12 Jan 2017 04:28:13 PM UTC, comment #7: 

Try this patch instead.

(file #39450)

John W. Eaton <jwe>
Group administrator
Thu 12 Jan 2017 01:41:32 AM UTC, comment #6: 

I checked the patch.  It solves the reported segfault with duplicate nested functions.  However, it introduces a difference for a regular parsing error.

With patch applied

octave:1> x = \1
parse error:

  syntax error


Unpatched development branch

octave:1> x = \1
parse error:

  syntax error

>>> x = \1


The parser used to give an indication of where in the line the problem was.

Rik <rik5>
Group administrator
Tue 10 Jan 2017 07:23:58 PM UTC, comment #5: 

I'm attaching a fix for this problem, including a change that fixes the error reporting to use the correct line from the file rather than the current input line where the lexer is currently reading.  I can split those two things into separate patches, but I don't see a good way to fix the bug without changing a public interface.  Although the patch adds some methods to the symbol table classes, those could be eliminated.  The real problem is that base_parser::finish_function may already return 0, but that doesn't necessarily indicate an error.  So I added a status flag as an argument.  It's still not as neat and clean as I would like, but it appears to work.

(file #39429)

John W. Eaton <jwe>
Group administrator
Tue 10 Jan 2017 05:22:43 PM UTC, comment #4: 

Another tangentially related bug was just reported (bug #50011: failure to report error on conflicting methods for classdef).  In this case, a class inherits the same method from two different parents.  The Matlab parser emits an error because there are two methods with the same name and no way to distinguish which one to call.  This seems similar to the issue with subfunctions reported in comment #3 in that the Octave parser is not checking for existing nested functions, subfunctions, or methods before attempting to place the names in the symbol table.

Rik <rik5>
Group administrator
Tue 10 Jan 2017 05:11:21 PM UTC, comment #3: 

Also of interest, the parser accepts duplicate subfunction names, but uses the first definition of the function.  It seems like it would be helpful if the parser were to issue a warning or an error on encountering the second duplicate subfunction.

Test case in the file testbug2.m:

function x = testbug2()

  x = 1;


function y = testbug2()

  y = 2;


Then execute

octave:1> testbug2
ans =  1

Rik <rik5>
Group administrator
Tue 10 Jan 2017 05:08:26 PM UTC, comment #2: 

Just created a backtrace to help debug things.  This is on the development branch with cset f2456a17490c.

#0  std::local_Rb_tree_increment (__x=0x1e70370)
    at ../../../../../src/libstdc++-v3/src/c++98/tree.cc:71
#1  std::_Rb_tree_increment (__x=0x1e70370)
    at ../../../../../src/libstdc++-v3/src/c++98/tree.cc:91
#2  0x00007fdcc4bbe3cd in std::_Rb_tree_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, symbol_table::symbol_record> >::operator++ (this=0x7ffd64fc47e0)
    at /usr/include/c++/5/bits/stl_tree.h:205
#3  0x00007fdcc55f0049 in symbol_table::do_update_nest (this=0x1e6ff60)
    at libinterp/corefcn/symtab.cc:1618
#4  0x00007fdcc55f017d in symbol_table::do_update_nest (this=0x1e6f810)
    at libinterp/corefcn/symtab.cc:1646
#5  0x00007fdcc5131a30 in symbol_table::update_nest (scope=35)
    at libinterp/corefcn/symtab.h:1575
#6  0x00007fdcc51286f3 in octave::base_parser::finish_function (
    this=0x7ffd64fc4da0, ret_list=0x1dd3350, fcn=0x1e6aa10, lc=0x0, l=1,
    c=1) at libinterp/parse-tree/oct-parse.yy:3293
#7  0x00007fdcc5121dc1 in octave_push_parse (yyps=0x1e6ec50,
    yypushed_char=297, yypushed_val=0x7ffd64fc4c30, parser=...)
    at libinterp/parse-tree/oct-parse.yy:1457
#8  0x00007fdcc511d300 in octave_pull_parse (yyps=0x1e6ec50, parser=...)
    at libinterp/parse-tree/oct-parse.cc:2973
#9  0x00007fdcc512b317 in octave::parser::run (this=0x7ffd64fc4da0)
    at libinterp/parse-tree/oct-parse.yy:4039
#10 0x00007fdcc512ba08 in parse_fcn_file (
    file="testbug", dispatch_type="", package_name="",
    force_script=false, autoload=false, relative_lookup=true, warn_for="") at libinterp/parse-tree/oct-parse.yy:4188
#11 0x00007fdcc512ce2f in load_fcn_from_file (file_name="./testbug.m", dir_name=".", dispatch_type="", package_name="", fcn_name="", autoload=false)
    at libinterp/parse-tree/oct-parse.yy:4392
#12 0x00007fdcc55ecfc2 in symbol_table::fcn_info::fcn_info_rep::find_user_function (this=0x1b52130) at libinterp/corefcn/symtab.cc:1049
#13 0x00007fdcc55eab77 in symbol_table::fcn_info::fcn_info_rep::load_class_constructor (this=0x1b52130) at libinterp/corefcn/symtab.cc:453
#14 0x00007fdcc55ebf0a in symbol_table::fcn_info::fcn_info_rep::xfind (this=0x1b52130, args=..., local_funcs=true) at libinterp/corefcn/symtab.cc:786
#15 0x00007fdcc55eb9fd in symbol_table::fcn_info::fcn_info_rep::find (this=0x1b52130, args=..., local_funcs=true) at libinterp/corefcn/symtab.cc:685
#16 0x00007fdcc55f1791 in symbol_table::fcn_info::find (this=0x7ffd64fc5590, args=..., local_funcs=true) at libinterp/corefcn/symtab.h:993
#17 0x00007fdcc55ef19f in symbol_table::do_find (this=0x1b28bc0, name="testbug", args=..., skip_variables=true, local_funcs=true)
    at libinterp/corefcn/symtab.cc:1465
#18 0x00007fdcc55edee7 in symbol_table::find (name="testbug", args=..., skip_variables=true, local_funcs=true) at libinterp/corefcn/symtab.cc:1229
#19 0x00007fdcc55ee1d3 in symbol_table::find_function (name="testbug", args=..., local_funcs=true) at libinterp/corefcn/symtab.cc:1265
#20 0x00007fdcc55e9653 in symbol_table::symbol_record::find (this=0x1d9bdf8, args=...) at libinterp/corefcn/symtab.cc:145
#21 0x00007fdcc5154505 in tree_identifier::rvalue (this=0x1d9bdd0, nargout=0, lvalue_list=0x0) at libinterp/parse-tree/pt-id.cc:66
#22 0x00007fdcc5133214 in tree_identifier::rvalue (this=0x1d9bdd0, nargout=0) at libinterp/parse-tree/pt-id.h:117
#23 0x00007fdcc5154a1e in tree_identifier::rvalue1 (this=0x1d9bdd0, nargout=0) at libinterp/parse-tree/pt-id.cc:124
#24 0x00007fdcc514f6c9 in octave::tree_evaluator::visit_statement (this=0x19c7dc0, stmt=...) at libinterp/parse-tree/pt-eval.cc:685
#25 0x00007fdcc5171bea in tree_statement::accept (this=0x1d9bec0, tw=...) at libinterp/parse-tree/pt-stmt.cc:187
#26 0x00007fdcc514f86d in octave::tree_evaluator::visit_statement_list (this=0x19c7dc0, lst=...) at libinterp/parse-tree/pt-eval.cc:727
#27 0x00007fdcc5172650 in tree_statement_list::accept (this=0x1b4f910, tw=...) at libinterp/parse-tree/pt-stmt.cc:322
#28 0x00007fdcc548af2c in octave::interpreter::main_loop (this=0x1a0f660) at libinterp/corefcn/interpreter.cc:887
#29 0x00007fdcc548a70c in octave::interpreter::execute (this=0x1a0f660) at libinterp/corefcn/interpreter.cc:755
#30 0x00007fdcc4bbad03 in octave::application::execute_interpreter (this=0x7ffd64fc6040) at libinterp/octave.cc:382
#31 0x00007fdcc4bbaf6e in octave::cli_application::execute (this=0x7ffd64fc6040) at libinterp/octave.cc:426
#32 0x0000000000401854 in main (argc=9, argv=0x7ffd64fc6298) at src/main-cli.cc:90

Rik <rik5>
Group administrator
Tue 10 Jan 2017 04:55:14 PM UTC, comment #1: 

Confirmed.  This is present on the current stable release version 4.2.0.

To reproduce, either copy and paste the following code into the Command Window, or put the set of commands in a file testbug.m and then execute testbug.


function [] = testbug()

function [] = bug()

function [] = bug()

Rik <rik5>
Group administrator
Tue 10 Jan 2017 01:50:37 PM UTC, original submission:  

Octave GUI shuts down with no error. Except "The program has stopped working" from windows.

When running the code in CLI i get the following error: panic: Segmentation violation --stopping myuself...
attempting to save cariables to 'octave-workspace'...
save to octave-workspace' complete.

Should give an error instead of just crashing.

Code to reproduce error:

function [] = testbug()

  function [] = bug()
  function [] = bug()



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

Attach Files:

Attached Files
file #39474:  diffs.txt added by jwe (7KiB - text/plain)
file #39462:  testbug2.m added by rik5 (139B - d2l/unknowntype)
file #39460:  testbug.m added by rik5 (158B - d2l/unknowntype)
file #39461:  testbug3.m added by rik5 (176B - d2l/unknowntype)
file #39463:  testbug4.m added by rik5 (129B - d2l/unknowntype)
file #39450:  diffs.txt added by jwe (6KiB - text/plain)
file #39429:  diffs.txt added by jwe (6KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)

    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 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-01-21 philipnienhuis StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Operating SystemMicrosoft Windows Any
    2017-01-18 rik5 Operating SystemAny Microsoft Windows
    2017-01-18 philipnienhuis StatusFixed In Progress
        Open/ClosedClosed Open
    2017-01-16 rik5 CategoryNone Interpreter
        StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Release4.2.0 dev
    2017-01-14 jwe Attached File- Added diffs.txt, #39474
    2017-01-13 rik5 Attached File- Added testbug.m, #39460
        Attached File- Added testbug3.m, #39461
        Attached File- Added testbug2.m, #39462
        Attached File- Added testbug4.m, #39463
    2017-01-12 jwe Attached File- Added diffs.txt, #39450
    2017-01-10 jwe Attached File- Added diffs.txt, #39429
    2017-01-10 rik5 Severity3 - Normal 4 - Important
        StatusNone Confirmed
        Release4.0.3 4.2.0
        Operating SystemMicrosoft Windows Any
        SummaryOctave segmentation voilation when calling duplicate function Octave segmentation violation when duplicate nested functions exist

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code