[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QSettings deleted by singleton-cleanup mechanism

From: Daniel J Sebald
Subject: Re: QSettings deleted by singleton-cleanup mechanism
Date: Sun, 21 Jun 2015 03:33:46 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 06/17/2015 05:05 PM, Mike Miller wrote:
On Wed, Jun 17, 2015 at 16:26:06 -0500, Daniel J Sebald wrote:
On 06/17/2015 03:56 PM, John W. Eaton wrote:

On 06/17/2015 03:43 PM, Daniel J Sebald wrote:

Currently the GUI's QSettings are instantiated and deleted by the Octave
worker thread using the singleton-cleanup mechanism. Can that be
changed? Was there a reason to have the worker, which is in another
thread, do this?

I haven't looked, but was this changed when we tried to make it possible
to open Qt plot widgets when Octave is started with --no-gui (the
command line interface but linked with the Qt libraries)?

Oh, it probably was.  I think there are other ways that could be done, or it
might not even be necessary to have a QSettings in that case if nothing is
being used by it.  I'll investigate.

I looked into it a little bit. I think it was done that way far before
that more recent change.

Both the "welcome wizard" and the Qt plot backend need access to the
settings, so the settings definitely do need to be around and
accessible when the main window is not up yet (or ever).

OK. It turns out there isn't much change needed there. This is all to do with the cleanup stage. I believe I see how this singleton-cleanup came to be used. There was likely segmentation faults when exiting the GUI that proved difficult to solve, so eventually this "very-last-action" approach to cleaning up the GUI memory space was done and it seemed to work for whatever reason.

However, after trying to make the settings save and resource_manager cleanup via qApp aboutToQuit() signal, I eventually tracked down the original source of problems, even though it was pretty hard to do this in such a transient action as exit. Basically, the terminal was not being deleted by the related dock widget. There was a similar bug in another object. Any dynamically-created widget has to be deleted when its parent is deleted. If not, the widget hangs around in the event-processing loop utilizing a parent and resources that no longer exist once everything else is destroyed.

A changeset is attached here:


Look for the words '(bug fix)' in the changeset comments.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]