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.

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

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.