Re: ***[Possible UCE]*** Re: GUI doesn't appear when using ./run-octave

[Daniel J Sebald]

On 09/16/2012 04:37 AM, Daniel J Sebald wrote:
> On 09/16/2012 04:07 AM, Philip Nienhuis wrote:
> > marco atzeri-2 wrote
> > > On 9/16/2012 1:05 AM, Philip Nienhuis wrote:
> > > > The last days . /run-octave (with or without --force-gui) doesn't start
> > > > the
> > > > GUI but simply returns to the prompt..
> > > > octave --no-gui starts up the good old CLI.
> > > > Just to be sure I wiped all source and build dirs and started anew
> > > > with a
> > > > fresh clone, with the same result.
> > > >
> > > > Where can I start searching for the cause?
> > > >
> > > > Linux Mageia 2, gcc 4.6.3, Pentium-M
> > > >
> > > > Philip
> > >
> > > eventually, same root cause of
> > > https://savannah.gnu.org/bugs/?37359
> > >
> > > Now the error message at start is:
> > >
> > > QCoreApplication::sendPostedEvents: Cannot send posted events for
> > > objects in another thread
> > >
> > > and the GUI frozes and is not anymore usable.
> > > Kill -9 is needed to close the program.
> >
> > At least you do get error messages.
> >
> > On my (linux) box simply nothing happens (apart from a little spike in
> > the
> > CPU applet on some desktop panel) and nothing seems broken. It just won't
> > work - kill -9 isn't even needed.
> >
> > The error message in your case seems related to one I posted a while ago
> > "QObject::startTimer: timers cannot be started from another thread" (2X)
> > here:
> >
> > https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-August/029811.html
> >
> > (which in my case didn't hang the GUI - I just had to click in the
> > terminal
> > to get focus there, and then hit<Enter>)
> >
> > Maybe a red herring, but do you have win32/moc-QWinTerminalImpl.cc or
> > unix/moc-QUnixTerminalImpl.cc
> > in<BUILDDIR>/libgui/ libqterminal ?
>
> I don't think it is a red herring. I've been searching around for a bug
> in which the GUIDE+O won't appear when the editor tab files are present
> in the configuration file, i.e., "savedSessionTabs=/home/sebald...". But
> I've isolated the problem to the QTerminal. That is, I put some
> fprintf's around the instruction that is failing:
>
> // Octave Terminal subwindow.
> fprintf(stderr,"construct: before QTerminal\n");
> _terminal = new QTerminal (this);
> fprintf(stderr,"construct: after QTerminal\n");
>
> All along I've noticed that the terminal doesn't work properly either.
> Text will appear but if switching between Qt windows, the text will
> stop, unless I move the position bar up and down back to the command
> line. Then text will appear.
>
> That's where I am right now, and I will resume searching for the bug
> tomorrow.

Just an update.  I was fooled on that QTerminal has a set of 
instructions that redirect stdin, stdout, stderr to the terminal in 
GUIDE+O.  I suspect that is why none of us is getting much information 
as far as error messages.  That's a bit of a problem here: if error 
messages are directed inside the GUIDE+O and GUIDE+O crashes, we don't 
see those error messages.  I've allowed stderr to continue and I've not 
traced things to the routine:

void
main_window::read_settings ()
{
  QSettings *settings = resource_manager::get_settings ();

fprintf(stderr,"settings = %lu\n",settings);
  // FIXME -- what should happen if settings is 0?

  restoreState (settings->value ("MainWindow/windowState").toByteArray ());
  settings->beginGroup ("DockWidgets");
  // restoring the geometry of all widgets
  foreach (QObject *obj, children ())
    {
      QString name = obj->objectName ();
      if (obj->isWidgetType () && ! name.isEmpty ())
        {
          QWidget *widget = qobject_cast<QWidget *> (obj);
          QVariant val = settings->value (name);
          widget->restoreGeometry (val.toByteArray ());
        }
    }
  settings->endGroup();
  restoreGeometry (settings->value ("MainWindow/geometry").toByteArray ());
  emit settings_changed ();
}

I wondered if settings was NULL (one should get in a habit of checking 
for NULL pointers in C++ even if it is just some error message...but 
again, we wouldn't see the error message if GUIDE+O crashed right 
there).  But my putting that fprintf() there now causes GUIDE+O to run 
consistently.  However, because I've reactivated STDERR, I now get:

QMainWindow::saveState(): 'objectName' not set for QToolBar 0x22fe0c0 'Main'

Definitely some strange behavior right around this area of code.

I'll probably set this aside for a day or so.  Couple things though:

1) Should we be redirecting STDERR away from the console?  I can see 
redirecting STDIN and STDOUT to make the Octave terminal window function 
properly.  But I think I'd prefer to have STDERR stay directed to the 
console.  With all the GUI unix things I'm often seeing verbose error 
messages appearing on the console, like "This font not found/that font 
not found/etc."

2) Is there a description of how to edit and work with the GUI code?  I 
see there is a project file.  Usually in the code appears "Don't edit 
this manually" kind of thing.

Dan