bugGNU Octave - Bugs: bug #48494, Current Dev access application...

 
 

bug #48494: Current Dev access application functions before initialization

Submitter:  Lachlan Andrew <lachlan>
Submitted:  Wed 13 Jul 2016 03:25:26 AM UTC
   
 
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  jwe
Originator Name:  Lachlan Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 22 Jul 2016 05:06:49 PM UTC, comment #6: 

This problem seems to be fixed, so I'm closing this report.  Comment to reopen if there is some other problem that I've missed.

John W. Eaton <jwe>
Group administrator
Thu 14 Jul 2016 09:53:06 PM UTC, comment #5: 

The forced_interactive function won't be a problem because it only touches data managed directly by the application object and that is the very first object that is constructed.

Yes, it is currently possible to cause a segfault if you use one of the static functions that dereferences the application::instance pointer before an application object is created, but that is not the way we use this class.

I could make the application class a singleton like others in Octave, but I'm trying to head in the direction of eliminating those, not adding more!

Another option would be to fail a little more gracefully if someone were to attempt using one of the static functions before creating an application object, but I don't think that's necessary at the moment.

John W. Eaton <jwe>
Group administrator
Wed 13 Jul 2016 11:26:20 PM UTC, comment #4: 

Thanks for the prompt response, JWE.

I realised after posting the report that it may have been caused by the warnings I see early on.  (I notice that some sections of code just print directly to stderr instead of calling warning() to avoid problems like this.)

I don't quite understand why application::forced_interactive() won't be a problem, but will take your word for it.

Retagging "ready for test".

Lachlan Andrew <lachlan>
Wed 13 Jul 2016 05:42:13 PM UTC, comment #3: 

OK, I think I see how this can happen if a warning message is printed (or possibly other things happen) before the interpreter is ready.  But if the interpreter isn't ready, I think it's safe for the application::interactive function to just return false.  And for the one that sets the value to do nothing, since it isn't really useful to try to make a nonexistent interpreter interactive...

I checked in the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/4e770056f74a

John W. Eaton <jwe>
Group administrator
Wed 13 Jul 2016 01:32:27 PM UTC, comment #2: 

I don't think there should be a problem with the application::forced_interactive functions because they just access data that is stored in the application object.

The application::interactive functions do currently require that the interpreter is initialized before they can be called.  But, again, I don't see where that can occur and I need to know where that is happening before I can decide how to properly fix the problem.

John W. Eaton <jwe>
Group administrator
Wed 13 Jul 2016 12:48:23 PM UTC, comment #1: 

What is needed to reproduce the error?  I don't see the problem.

To decide how to properly fix this, I need to see where the calls are happening before the interpreter is created.

I don't think we can simply start the interpreter at any random time.  I initially wanted to start it it first and pass it as an argument to the application object, but that caused strange errors later with graphics objects when using the GUI version of Octave.  I didn't fully investigate, but I think it was an issue with threads.

John W. Eaton <jwe>
Group administrator
Wed 13 Jul 2016 03:25:26 AM UTC, original submission:  

The current tip causes a crash on start up.

The problem is that "interactive" and "forced_interactive" are called before the application / interpreter have been properly initialized.

The attached patch works around this, by reporting that the invocation is interactive if initialization is not complete.  I assume that the correct fix is to find this information some other way until the objects are initialized, but this patch allows development to continue.

Lachlan Andrew <lachlan>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

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 lachlan (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-22 jwe StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2016-07-13 lachlan StatusNeed Info Ready For Test
    2016-07-13 jwe StatusPatch Submitted Need Info
    2016-07-13 lachlan Assigned tolachlan jwe
    2016-07-13 lachlan Attached File- Added bug_xxxxx_crash_interperter.cset, #37835

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code