bugGNU Octave - Bugs: bug #37359, Gui frozen at start

 
 

bug #37359: Gui frozen at start

Submitter:  marco atzeri <matzeri>
Submitted:  Sat 15 Sep 2012 04:08:17 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 21 Sep 2012 09:09:21 PM UTC, comment #9: 

The problem with multiple open editor tabs of the same file is already in the bug list (bug #36869). A related effect is that it is possible to save an open file under the name of another already open file.

Torsten Lilge <ttl>
Group Member
Fri 21 Sep 2012 08:09:24 PM UTC, comment #8: 

OK, I must have just tested "save as", not "save".  The patch looks good.  Thanks.

I do think the editor behavior will need revisiting for a tiny bit of clean up because I notice that multiple copies of files can be opened.  That should be disallowed.  Also, the dialogue boxes shouldn't be static--notice there is some code in file_editor_tab that will check if a file has changed while the dialogue box is on screen.  Instead, a better way is putting the editor into "non-editable" mode, then a new dialogue box is created with slots attached to the dialogue box so that when the dialogue is deleted it signals the slot for the file_editor_tab which reacts accordingly.  This is low priority right now.

Dan Sebald <sebald>
Fri 21 Sep 2012 07:07:36 PM UTC, comment #7: 

Saving an existing file in the editor now produces a modification message from the file watcher. The attached patch fixes this.

(file #26608)

Torsten Lilge <ttl>
Group Member
Thu 20 Sep 2012 02:26:21 PM UTC, comment #6: 

Thanks for the revision, Daniel. I modified the commit message slightly, just breaking long lines, and made the short description shorter. After that, I merged it:

http://hg.savannah.gnu.org/hgweb/octave/graph/a42d69d5a36d

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 20 Sep 2012 09:19:23 AM UTC, comment #5: 

OK, I've created a detailed patch as well as make the file system tracking a bit more robust.  Let's get the GUI guru's review on this one before importing the patch to the repository.  I'll have a few more mods, and it would be nice if everyone stay up-to-date for the near term.

(file #26596)

Dan Sebald <sebald>
Tue 18 Sep 2012 12:53:47 PM UTC, comment #4: 

Thanks for your analysis and patch, Dan.

A small request. Could you rewrite your patch but only edit the commit message in order to adhere to our commit message guidelines?

http://wiki.octave.org/Commit_message_guidelines

Do "hg log -v" to get a sample of other commit messages to follow. If you update to your patch (hg up -r 5b73a9e4dc3) and you have a recent version of Mercurial, you can amend the patch with "hg commit --amend".

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Tue 18 Sep 2012 01:32:13 AM UTC, comment #3: 

You'll have to take this description with a grain of salt because these gui things for which flow goes from the application back to the GUI system and back to the application can always be tricky, but I think the above fix is good.  It doesn't solve everything (see below), but I don't want to do too much at once.  At least it clears the way to work on other related items.

First, I made a slight change to the way in which the settings change notification is done.  In the hunk of code (main_window::read_settings) I posted to maintainers list on 09/16/2012 01:44 PM is the instruction:

emit settings_changed ();

Notice a couple things.  One, "read_settings" is called ultimately from the main_window constructor.  Two, the slots for the signal (i.e., objects to be notified if the signal occurs) are defined in the main_window constructor just prior to the call to read_settings:

  connect (this,                        SIGNAL (settings_changed ()),
           _file_editor,                SLOT   (notice_settings ()));
  connect (this,                        SIGNAL (settings_changed ()),
           _files_dock_widget,          SLOT   (notice_settings ()));
  connect (this,                        SIGNAL (settings_changed ()),
           this,                        SLOT   (notice_settings ()));

and contain objects which include the file editor, dock widget and the main window itself--all objects having association with the main window (i.e, "this").

My way of thinking is that there shouldn't be any signals relayed to an object while it is in the stage of being constructed.  All internal memory/variable definitions might not be complete yet.  Whether this ultimately was one of several launch problems, I'm not sure.  But it is just good practice to not let the GUI core mess with things that aren't yet fully constructed.  Otherwise there could be a race condition, which is what I'm seeing when there are settings for the file_editor within the settings file.  Sometimes the windows would appear, sometimes not.  Again, grain of salt, and I haven't the desire to pinpoint the exact cause and effect.

So, I made the change to move the update of the settings to after the main_window construction is complete.  It's an easy change, and requires making read_settings and write_settings public, but I see no problem with making those public.

...

After that change, I then began getting more descriptive error messages in the STDERR stream, which uncovered a segmentation fault in the file_editor.

I was getting an error upon the

  QsciLexer *lexer =  _edit_area->lexer ();
  delete lexer;

in file_editor_tab::update_lexer ().  (Lexer creation is done twice at start up, but I'm not sure why.)  It was only the m-file editors that were creating problems.  Cut to the chase, I think the pointer for the created QsciAPI, i.e.,

      QsciAPIs *lexer_api = new QsciAPIs (lexer);

was being discarded when it should have been kept for deleting later on.  Because the QsciAPIs wasn't being deleted it was hanging around after the lexer_octave_gui had been deleted.  Hence, it was attached to something that didn't exist anymore.

So, I moved that code for building the QsciAPIs inside the lexer_octave_gui constructor, and the destructor now deletes the QsciAPIs.  That seems to have solved the main problem of launch.

...

Before figuring out the previous bug, I noticed that file_editor_tab::save_file was using

   _file_name = saveFileName;

That is actually a bug because the lexer isn't being updated by just setting the file name.  For example, if a file called foo.m (having Octave lexer) was saved as foo.txt the Octave lexer remained, and text was highlighted as though the file were still foo.m.  This is much cleaner than before and behaves just as expected from an editor.

...

With all that, the problems at launch are solved, but not the following:

1) File editor lexers being created, then destroyed, then created again when only creating once is necessary.

2) All kinds of error messages and system hanging upon exit.

3) The command window still doesn't function just right.  Often commands won't appear until after moving the position cursor around.  It starts acting strange after a large printout is put into the pager.

This patch isn't meant to address everything except the immediate problems.  So, if there are some quirky behaviors, take notice and enter them into the bug tracker separately.



(file #26569)

Dan Sebald <sebald>
Mon 17 Sep 2012 01:39:44 PM UTC, comment #2: 

This suggests the need for an Octave
command argument in the --no-xxx family,
something like --no-qt-settings

But, also a more robust handling of
the qt-settings file would help as
well as:

1. Is the current handling correct if multiple
   instances are using the same qt-settings file?

2. Should there be a way of creating and using a
   designated q-settings file?

3. Is there a need for a "reset_qt_settings" function?

Michael Godfrey <godfrey>
Group Member
Mon 17 Sep 2012 12:35:00 PM UTC, comment #1: 

removing ~/.config/octave/qt-settings

solved the issue and also the message

"QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread "

disappeared

marco atzeri <matzeri>
Sat 15 Sep 2012 04:08:17 PM UTC, original submission:  

cygwin build

$ hg tip
changeset:   15391:1ddf5772fb1a
tag:         tip
user:        John W. Eaton <jwe@octave.org>
date:        Fri Sep 14 22:57:00 2012 -0400
summary:     fix broken libgui build

some versions ago, it was working fine.
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.

marco atzeri <matzeri>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #26608:  disable_tracking.diff added by ttl (929B - text/x-patch)
file #26596:  octave-gui_launch_cleanup-2012sep20.patch added by sebald (10KiB - text/x-patch - Few small changes and detailed import comment)
file #26569:  octave-gui_launch_cleanup-2012sep17.patch added by sebald (8KiB - text/x-patch - Move lexer_api code inside lexer_octave_gui constructor, delete lexer_api in destructor. Make save-file-as reload lexer to match file extension. Update settings only after all window objects created.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Updated the item)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by matzeri (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
    2012-09-21 ttl Attached File- Added disable_tracking.diff, #26608
    2012-09-20 jordigh StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2012-09-20 sebald Attached File- Added octave-gui_launch_cleanup-2012sep20.patch, #26596
    2012-09-18 jordigh StatusNone Patch Submitted
    2012-09-18 sebald Attached File- Added octave-gui_launch_cleanup-2012sep17.patch, #26569

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code