patchGNU Octave - Patches: patch #7949, octave-gui freezes for 30+ seconds...


patch #7949: octave-gui freezes for 30+ seconds when trying to display a new documentation tab

Submitter:  None
Submitted:  Sat 09 Feb 2013 06:39:54 PM UTC
Category:  None Priority:  5 - Normal
Status:  Duplicate Privacy:  Public
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Sun 07 Jul 2013 05:41:31 PM UTC, comment #13: 

The issue described here obviously has the same cause as the freezes reported in bug #38305 with file dialogs in KDE. From now on the long term solution (correctly handling signals) will be tracked in bug #38305.

Torsten Lilge <ttl>
Project Member
Fri 07 Jun 2013 09:34:24 PM UTC, comment #12: 

I just added cset
as a first step.

It adds "help xxx" to the editors context menu where xxx is the word at the current mouse or text cursor position. Whether the mouse or text cursor is used depends on how the context menu was called (by mouse or keyboard). By now, the menu just executes "help xxx" in the terminal.

Torsten Lilge <ttl>
Project Member
Mon 03 Jun 2013 03:19:48 AM UTC, comment #11: 

For all I read, the easiest way to avoid the kde messages is to detect octave is running under it and initialize its structures before octave virtual terminal kicks in or force octave to use pure Qt dialogs, would like to skip the later solution though. It is not a big deal but I am kind of busy right now. Perhaps, I could provide patches on coming days.

Torsten, if you are reading this, could you please add a very nice feature? With a word selected in "Command Window" or "Editor" the right click would have an "Definitions", "Look for" or something like option and once clicked would display the octave quick reference help in a pop-up for that item. Any subsequent action/event would destroy it. Nice thing for beginners and seasoned users as well. May you need some help, I would be able to assist you on a couple of days from now.


Andre da Costa Barros <andrecbarros>
Sun 02 Jun 2013 09:23:48 AM UTC, comment #10: 

Good idea. I have added "Clear all" to the context menu with cset

Torsten Lilge <ttl>
Project Member
Sun 02 Jun 2013 03:23:44 AM UTC, comment #9: 

Great!  We located that issue then.  It may take a while to incorporate a fix for this in Octave because developers will have to think about how to setup signals in this situation.

The "i18n" messages is starting to show up with a number of KDE users.  Definitely should be fixed somehow.

The right mouse click isn't a bad idea.  If you want to try doing that sometime, it really isn't too difficult to add such a thing with the Qt environment.  Something else I've wanted to add to right click is "help" run on whatever text is highlighted and displayed in a separate window.  That would prevent the help contents going to the pager.  I lack time for programming at the moment though.

Dan Sebald <sebald>
Sat 01 Jun 2013 06:58:30 AM UTC, comment #8: 


Sorry to answer so late, was on a hurry to recover data from a failing machine.

Build the whole package without patches. Running latest version from repository. The good part is that there is no more lockups, everything seems to be running 'fine', except for some weird messages on "Command Window" when I try to read/open files, like:

'Global::locale(): Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work
"/org/freedesktop/UDisks2/drives/Generic_USB_SM_Reader_058F312D81B" : property "Drive" does not exist'

They all are related to kde environment and are redirected to console (stderr) what happens to be the octave virtual terminal. Would be good to get rid of them, though.

The files open properly. Debugging and all functionalities seems to be working properly too.

May I suggest to add a right click option to "Command Window" (and inside it) to clear the mess, instead of just by Edit->Clear? (same for "Command History" and "Workspace")

Loving to work on graphical environment. Many thanks to all.

Andre da Costa Barros <andrecbarros>
Tue 28 May 2013 09:56:29 PM UTC, comment #7: 

OK.  Although I've not read that article all the way through, it does sound at least related to the bug report I referenced earlier.  You could try the following from that bug report: with a relatively recent clone of Octave, comment out the following line and rebuild:

Lines 472-474 (

#ifdef SIGCHLD
// octave_set_signal_handler (SIGCHLD, sigchld_handler);

See if that stops the suspended GUI when displaying a new documentation tab.

Dan Sebald <sebald>
Tue 28 May 2013 09:03:40 AM UTC, comment #6: 

I am still waiting for Qt 5.1 to see if it fixes problems related to "wait for pid" SIGNCHLD signal processing.

If you need a more in depth discussion, take a look at: "" or browse for many problems. There you will find how it should be handled on unix too.

I have right now 3 "solutions":
..1) an improved version of my first patches (i.e., saving
.... expanded info files before the fork phase);
..2) patches linking to libz on linux so that we can uncompress
.... the info files directly;
..3) an still incipient and kind of rough combination of the
.... expansion phases present on 7zip libs (it can be compiled
.... to support tar, zip, rar, gzip and bzip2 formats). The
.... advantage been a kind of multi-platform support at the cost
.... of requiring more libs;

I would pick solution 2 on linux, but I don't know what is happening on MS Windows or OSX, i.e., if they are affected by freezing for ~30 seconds.

Anyway, I still hope that the problem will be fixed where it should, on Qt.

Andre da Costa Barros <andrecbarros>
Mon 27 May 2013 12:18:31 AM UTC, comment #5: 

Any new developments on 5.1 and the QProcess signal handling?  I'm cross-referencing here a bug report in which some of us are looking a little more closely at this error as it pertains to Octave.

Dan Sebald <sebald>
Wed 03 Apr 2013 09:53:50 PM UTC, comment #4: 

We can wait for 5.1, but the initial setup before your mod didn't look that good.

I too noticed that the destructor is working properly now.  Someone removed "delete _terminal" from

delete _terminal_dock_widget;
delete _terminal;

The _terminal was contained inside _terminal_dock_widget, so it was as though calling the destructor on _terminal twice.  Someone must have caught this in the past week or so.  I just wrote a patch that removes _terminal so that confusion won't arise again.

The thing is, although there was a crash, it went unnoticed because error messages were in the terminal window, which consequently is removed from the screen.  I've also written a patch that restores the STDERR at shutdown so that the messages go to the shell window and not the GUI terminal.

Dan Sebald <sebald>
Wed 03 Apr 2013 09:29:38 PM UTC, comment #3: 

Answering your question, yes, there should be a better solution but the way I see, it depends on what will come with Qt5. If they find a better way to handle signals on unix, there will be no need to change octave code. If I would vote, it would be to wait a bit (Qt 5.1 is coming this month).


Andre da Costa Barros <andrecbarros>
Wed 03 Apr 2013 09:18:17 PM UTC, comment #2: 

I have new patches versions that improves the situation a bit but, from what I gathered about the source of the problem, it comes from the way QProcess handle signals on unix. I am kind of playing wait-and-see as Qt 5.1 is close to be released and I am not sure if the effort to correct the problem, like what vlc team did, is worth the time spending.

Also, I am not sure when it happened, but the destructor is working fine now so, I guess, whatever was killing the octave process before all cleaning code could be triggered it is gone now. The bad side of it is that octave starts a bit slower now that it has to generate the temporary files at startup. Perhaps, I will change the code and leave the temporaries alone. ;-)

Besides all that, the documentation is working fine (no delays) inside KDE for me and the qt interface is really nice to work with.

It should be noted that the problem with QFileDialog is also related to this it seems (again, QProcess).

Andre da Costa Barros <andrecbarros>
Tue 02 Apr 2013 08:33:31 AM UTC, comment #1: 

Well, this one looks a tad messy.  Do you think your solution is a good one?  Is it going somewhere?  Or is it a convoluted solution to an inadequate original design?  If it is related to the sleep(30) in

void SelfListener::run()

we'd be better off revamping this code.  There should be a more elegant design to this whole terminal/thread setup.  Do you agree?

Dan Sebald <sebald>
Sat 09 Feb 2013 06:39:54 PM UTC, original submission:  

I am still investigating the source of the problem. For what I gathered, seems to me that the origin of it is related on how events are handled and transferred between the various components after creating a detached/dissociated terminal.

If someone has more information about it please feel free to send a detailed explanation to my email.

The patches here provide a workaround. As the webinfo/parse structure is created before the octave interpreter running on a detached/dissociated terminal is created, the unpacked documentation is redirected to a temporary file from where it can be read without errors.

For some strange reason, the cleanup provided on parser class destructor is never performed. My suspect is that the process is killed before it get a chance to roll. An error code is always returned from octave-gui run so, perhaps, there is something to be checked there also.

It should be noted that if you run octave from the development dir with ./run-octave, this problem will not show up as from there the parser routine get the unpacked *.info files. Compact them before a ./run-octave issue and it will be displayed.



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

Attach Files:

Attached Files
file #27763: added by andrecbarros (5KiB - text/x-patch - improved versions)
file #27764:  octave-parser.h.diff added by andrecbarros (1KiB - text/x-patch - improved versions)
file #27765:  octave-documentation-dockwidget.h.diff added by andrecbarros (427B - text/x-patch - improved versions)
file #27431:  octave-documentation-dockwidget.h.diff added by None (427B - text/x-diff - Paches carry the name of the affected files)
file #27432:  octave-parser.h.diff added by None (1KiB - text/x-diff - Paches carry the name of the affected files)
file #27433: added by None (5KiB - text/x-diff - Paches carry the name of the affected files)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by andrecbarros (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by None (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 logged-in users can vote.





    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-07-07 ttl StatusNone Duplicate
        Open/ClosedOpen Closed
    2013-04-03 andrecbarros Attached File- Added, #27763
        Attached File- Added octave-parser.h.diff, #27764
        Attached File- Added octave-documentation-dockwidget.h.diff, #27765
    2013-02-09 None Attached File- Added octave-documentation-dockwidget.h.diff, #27431
        Attached File- Added octave-parser.h.diff, #27432
        Attached File- Added, #27433

    Back to the top

    Powered by Savane 3.9