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.
|
Wed 18 Jan 2017 06:42:51 PM UTC, comment #16:
Changing the OS to Windows on the bug report.
|
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
|
Mon 16 Jan 2017 10:14:00 PM UTC, comment #14:
Seems fine to me. Thanks.
|
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.
|
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).
http://hg.savannah.gnu.org/hgweb/octave/rev/564e959a0e89
|
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)
|
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).
|
Fri 13 Jan 2017 02:31:02 PM UTC, comment #9:
Thanks.
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.
|
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)
|
Thu 12 Jan 2017 04:28:13 PM UTC, comment #7:
Try this patch instead.
(file #39450)
|
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
Unpatched development branch
The parser used to give an indication of where in the line the problem was.
|
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)
|
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.
|
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:
Then execute
|
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.
|
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.
Code:
|
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()
endfunction
function [] = bug()
endfunction
bug()
endfunction
|