bugGNU Octave - Bugs: bug #46877, Unreachable return statement after...

 
 

bug #46877: Unreachable return statement after error call in lex.ll

Submitted by:  Rik <rik5>
Submitted on:  Mon 11 Jan 2016 09:34:05 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Other
Status: FixedAssigned to: John W. Eaton <jwe>
Originator Name: Open/Closed: Closed
Release: devOperating System: Any

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 Jump to the original submission)

Thu 14 Jan 2016 09:58:40 PM UTC, comment #8:

I also checked in the following changeset for the problem with the fatal error handler for flex:

http://hg.savannah.gnu.org/hgweb/octave/rev/9ff2ae6cd5b0

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Thu 14 Jan 2016 09:46:20 PM UTC, comment #7:

I also checked in some additional changesets that improve error handling:

http://hg.savannah.gnu.org/hgweb/octave/rev/f7cc48f601d2
http://hg.savannah.gnu.org/hgweb/octave/rev/f25c14056b7c
http://hg.savannah.gnu.org/hgweb/octave/rev/e1ee2203efe0

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Thu 14 Jan 2016 02:54:46 PM UTC, comment #6:

The only FIXME I see left that is along these lines is

But, I assume fatal really is fatal and Octave will be exiting immediately. In that case, cleaning up and memory leaks can be damned.

Closing report.

Rik <rik5>
Project Administrator
Thu 14 Jan 2016 10:41:50 AM UTC, comment #5:

The following changeset fixes the immediate problem of unreachable statements for lexical errors:

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

This change doesn't fix the problem of losing track of memory allocated in the parser in the event of an error.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Tue 12 Jan 2016 09:31:20 PM UTC, comment #4:

OK, I have a potential fix, but it is a bit of a kluge. Not only was the internal state not deleted properly, but any partially constructed parse tree was also not deleted. Still thinking about what would be the best short-term fix. Longer term, we may want to switch to having Bison generate the parser as a C++ class instead and I think that could also help with this problem.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Tue 12 Jan 2016 06:50:03 PM UTC, comment #3:

I think I found the problem. The internal state of the parser was no longer being deleted because yyparse wasn't returning. It should be possible to fix this by managing the parser state for the push parser the same as we already do for the pull parser. I'm trying that now.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Tue 12 Jan 2016 06:14:42 PM UTC, comment #2:

Ugh, memory leaks. Maybe the lexer also needs to be executing pop_start_state to return the lexer to the original start condition?

Rik <rik5>
Project Administrator
Tue 12 Jan 2016 05:18:20 PM UTC, comment #1:

I think the right thing to do is to change LEXICAL_ERROR to be a token that can return the error message back to the parser. Then we can properly report lexical errors as "parse errors".

Also, I noticed a memory leak. I can reproduce it by creating a script with an unterminated string constant (that will trigger one of these LEXICAL_ERROR conditions) and then call that script in a loop like this:

Simply calling a valid script in the loop doesn't show a leak. Changing the error message in the lexer to be a warning doesn't fix the problem either, so I think it is something other than missing error cleanup code if the LEXICAL_ERROR token is not returned. I'll see if I can also track down why this leak is happening.

John W. Eaton <jwe>
Project AdministratorIn charge of this item.
Mon 11 Jan 2016 09:34:05 PM UTC, original submission:

The code in lex.ll uses return statements after error statements. Now that Octave uses exceptions in error processing this code is unreachable and should--probably--be removed.

There are 7 instances:

For reference, the first instance near line 1021 is

The question at hand is whether the unreachable code should just be deleted? Or whethere the error should be downgraded to a warning and lex should return LEXICAL_ERROR and let the calling program, presumably Bison, deal with it.

Rik <rik5>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 14 Jan 2016 02:54:46 PM UTCrik5CategoryNone=>Interpreter
      StatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1