Re: [Interest] L Word

[Ben Haller via Interest]

+1.

I am mostly a lurker on this list, but I have asked a few questions and 
learned a bunch of things.  I would like to remain subscribed to it; it 
is useful to me.  But Roland is destroying the list.  As Benjamin writes 
below, at least some of the issues Roland raises are valid, and the 
larger discussion (what is Qt for, what should the future of it be, how 
are its licensing terms affecting its usability, etc.) has often been 
interesting.  I have even learned things from Roland's posts, in fact. 
The problem is not Roland's viewpoint as such (although I agree with 
those who are puzzled that he doesn't simply leave the group, since Qt 
is clearly not the tool he wants it to be), nor the discussion topic, 
but the fact that Roland behaves like a troll: posting endlessly making 
essentially the same points over and over, being rude and insulting 
rather than constructive, and attempting not just to make his point, but 
to completely dominate the conversation.


That is unacceptable behavior, and if it isn't against the CoC, perhaps 
it should be.  Tuukka, I recognize the difficult position here, but I 
vote that something needs to be done.  If you don't want to ban someone 
who is not in clear violation of the CoC, then the CoC should be revised 
to disallow this type of behavior.  This needs to stop.  People who are 
good, constructive contributors to the list are leaving, and I will soon 
follow them if this doesn't change.  If I'm not mistaken, not a single 
person has posted to this "L Word" thread in defense of Roland's right 
to act as he has been acting, have they?  It feels like the community is 
pretty much unanimous on this (except, of course, Roland): it needs to 
stop.  It seems clear that it won't stop of Roland's own volition, so 
the moderators need to act.


Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University



Benjamin TERRIER wrote on 4/29/21 11:26 AM:



On Thu, 29 Apr 2021 at 15:15, Bob Hood > wrote:


On 4/29/2021 4:02 AM, Bernhard Lindner wrote:

Obviously, Qt has nothing to do with this type of software engineering. And 
it's obviously
not suitable for functional safety (at least not if you take it seriously).


If this statement is true /and/ Roland's statement that TQC
actively courted that industry is also true, then it seems to me
that he has a valid grievance, regardless of how he presents it.


TQC actively courted that industry, but it does not mean that they 
intended Qt to be part of the functional safety stack.


As a proof to my above statement I bring you the Qt Safe Renderer. It 
is a commercial product from TQC targeted to functional safety 
industry, so yes TQC has courted this industry.
However, it also means that Qt itself was never meant to be a part of 
the functional safety stack and is not supposed to mess with it.


The issue at hand here is not that Roland has a valid grievance or 
not. At least some of the issues he raised are valid.
The issue is that his emails are numerous and have a very low 
signal/noise ratio, that he is borderline insulting to anyone who is 
out of his industry and that in the end it lowers the value users are 
getting from this mailing list.


And personally I'd add that he is so badly advocating for his 
grievance that I'd prefer him not to advocate for the points where I 
agree with him.



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] More than one type of main window

[Ben Haller via Interest]

Hi all.  I have a Qt Widgets based app that runs on both macOS and Linux.  So 
far, it has only had one kind of “main window”, with a menu bar of its own.  On 
macOS I want the app to look native, with a global menu bar at the top of the 
screen; on Linux, at least on the Linux variants I’m familiar with, each main 
window has its own menus.  I’ve got all of this working nicely, after a bit of 
struggle.

Now, however, I’d like to add a second type of “main window”, representing a 
different type of document that the app can also open/edit.  On macOS changing 
the contents of the global menu bar is frowned upon; you’re supposed to just 
enable/disable menu items depending upon whether they apply in the current 
context.  I’d like to do things that way, although it might feel a little bit 
odd on Linux.  So I want the menu bar of the new document type to be the same 
as the menu bar of the original document type, just enabled/disabled 
differently (mostly disabled).

My question is what the graceful way is to do this.  At present, the .ui file 
for the original document window contains a QMenuBar inside it, representing 
the global menu bar.  The new document type will have its own .ui file, though, 
since its window will be quite different.  One option would be to just 
duplicate the whole menu bar across the two nib files, so both .ui files have 
identical menu bar setups.  That’s ugly, and a maintenance headache, though.  
Other options would perhaps be:

- Have both main windows inherit from a common superclass that provides the 
menu bar, read from a separate .ui file.  I’m not sure how to do this, though.

- Have both main windows read in a .ui file containing the menu bar, and 
integrate it into their window (similar to the first option, but without the 
common superclass).  Not sure how to do this either.

- Maybe some other approach that I haven’t thought of?

It does make sense to me for both main windows to inherit from a common base 
class; there is a fair amount of app-level logic that needs to 
find/query/message the current main window, whichever type of main window it 
might happen to be.  (For a modeless Find panel in my app, for example.)  But 
how should I handle reading in a menu-bar-only .ui file and integrating that 
menu bar into the window read from a different .ui file?

Thanks for any help.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Will a Qt 5.x release support macOS 11?

[Ben Haller via Interest]

Hi all.  Just wondering whether there is any plan for any Qt 5.x release to 
support macOS 11.  At present, Qt 5.15 supports only through macOS 10.15 
(https://doc.qt.io/qt-5/macos.html#supported-versions), as far as I can tell, 
and my app built on macOS 10.15 apparently does not run properly on macOS 11 
(so my users inform me).  Since it looks like it will be a little while before 
a Qt 6 release is really solid (I just saw on the list that the first LTS 
release of Qt 6 is expected in September 2021, almost a year from now), it 
would be really nice if macOS 11 were added to the list of supported releases 
for 5.15.  Any chance of that?  I have users who are already on macOS 11 now; 
I’d like to have a better story for them.  Thanks for any info!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

> Hi Ben,

Hi Tony,

Lot’s of questions here!  Let’s see:

> There may indeed be an issue with fonts being tied to having at least one 
> window present, which causes you grief when you delete the main window.
> 
> Have you tried the suggestion from your other thread to just hide the main 
> window instead?

  Actually, that is what I tried – that’s the case where the crash occurs.  If 
I don’t set my main windows to delete on close, then they just close (no 
delete, just hide), and then the app crashes on quit.  If I set them to delete 
on close, then the app doesn’t crash on quit, interestingly; but then the 
global menubar problem I described happens instead.  :-<  So it seems like 
perhaps whatever font cache exists gets dealloced when the last main window 
*closes*, not when the last main window *deallocs*; and then when the app 
quits, the code tries to dealloc it again, and boom.  I’m not certain of those 
details, but that’s my hypothesis.

> Where is the tick font used?  Does your main menu that you want to persist 
> without any windows use it?

  It’s only used in that one spot that was in the snippet of code I posted – I 
set it as the font on a painter that I use to draw in the paintGL() method of 
my widget.  That’s the only spot it’s used.  So it’s not needed when there’s no 
main window visible, no.  But the second variant of the code just constructs a 
stack-allocated local QFont and uses that, so the QFont goes out of scope as 
soon as paintGL() is done, and that still crashes on quit.  So even if the 
lifetime of the QFont that I’m using is very short (local scope), it’s the 
lifetime of QApplication’s internal font cache that is the issue, and I have no 
control over how that is handled.

> Have you tried a cut-down app that creates a plain QMainWindow, a plain main 
> menu, then destroys the main window to see if persisting the main menu is 
> actually doable on Mac?

  No, I haven’t tried constructing a minimal test case.  I’m not super fluent 
in Qt, so that’s more daunting than it might sound; I’m not really sure what’s 
essential for a minimal Qt app and what isn’t, etc.  It definitely does seem 
like this usage pattern, of trying to keep the app running after the last main 
window closes using a global menubar, has maybe not gotten a lot of testing, 
since I’ve found two bugs so far and have been unable to get it to work.  It 
may be that there are unusual things about my app, though; my usage of OpenGL 
views is probably somewhat unusual, and that’s clearly linked to the crash on 
quit.

  Sorry if my descriptions of the bugs in these emails have been a bit hard to 
follow; I was writing the emails as I was figuring things out.  I’ve tried to 
present all the info more clearly in the two bugs I filed (QTBUG-86874 and 
QTBUG-86875).  :->

  Thanks for your followup!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

I have just filed bugs on the two problems discovered here:

QTBUG-86874
QTBUG-86875

I have not found a way to get menu item relocation in the global menubar to 
work properly on macOS without triggering a crash on quit as a side effect, and 
I think I’m going to give up on it for the time being.  Oh well.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 12:40 PM, Ben Haller via Interest 
>  wrote:
> 
> Sorry for all the emails; this is proving to be quite a difficult problem and 
> I’m really hoping somebody has insight into it.
> 
> This code also produces the same crash as the static QFont usage I posted in 
> my previous email, and this code seems very clearly innocent:
> 
> 
> 
> QFont tickFont;
> #ifdef __APPLE__
> tickFont.setPointSize(9);
> #else
> tickFont.setPointSize(7);
> #endif
> painter.setFont(tickFont);
> 
> 
> 
> So now I’m starting to think this may actually be a Qt bug, perhaps related 
> to caching of fonts internally in QOpenGLWidget.
> 
> But here’s the interesting bit: there is one other change in my app that is 
> also causal.  I’m trying to get my app on macOS to stay running after the 
> last window has closed, and to get the global menu bar to work properly in 
> that mode of operation, I need to keep my main window alive after it’s closed 
> (see the previous discussion thread on Qt-Interest).  To achieve that, I’m 
> commenting out the call to:
> 
> setAttribute(Qt::WA_DeleteOnClose);
> 
> in my main window’s initialization.  With that call commented out, I can 
> close the window, the global menubar remains correct because the main window 
> is still alive in the background, BUT the app crashes on quit due to the font 
> issue above.  With that setAttribute() call in place (not commented out), I 
> can close the window, the app does not crash on quit, BUT the global menubar 
> is screwed up because there’s no main window (see previous thread).
> 
> My closeEvent() just calls event->accept(); and returns.  With the 
> setAttribute() call commented out, the window does not get deleted any more, 
> it just closes (I have a qDebug() in its destructor to confirm that).  But 
> then quitting crashes.  Putting the setAttribute() call back in fixes the 
> crash; OR, commenting out the use of QFont in my QOpenGLWidget subclass fixes 
> the crash.
> 
> Anybody know what’s going on, and how I might fix it or work around it?  I 
> need to change the font in my widget, of course; and I seem to need to avoid 
> deleting my main window, in order to keep the global menubar working when the 
> last main window closes.  So I’m stuck.
> 
> Cheers,
> -B.
> 
> Benjamin C. Haller
> Messer Lab
> Cornell University
> 
> 
>> On Sep 23, 2020, at 12:04 PM, Ben Haller via Interest 
>>  wrote:
>> 
>> Hi all.  I’m starting a new thread since the focal question has completely 
>> changed.  I’ve tracked down the cause of the crash that I discussed in the 
>> previous thread, to a specific bit of code:
>> 
>> 
>> 
>> static QFont *tickFont = nullptr;
>> 
>> if (!tickFont)
>> {
>>  tickFont = new QFont();
>>  tickFont->setPointSize(9);
>> }
>> painter.setFont(*tickFont);
>> 
>> 
>> 
>> I do this inside a QOpenGLWidget subclass, in my paintGL() override.  If I 
>> comment this code out, no more crash on quit.  I figured this out because 
>> the backtrace for my crash seemed to involve private font cache teardown in 
>> QApplication, so I figured maybe I was doing something naughty involved 
>> QFonts, so I commented out every usage of QFont in my app, and then started 
>> uncommenting them one by one; when I uncommented this one, it crashes on 
>> quit.  (I got AddressSanitizer working, but it didn’t provide any additional 
>> info; I’m still working on getting Valgrind working on macOS 10.15.)
>> 
>> So.  What is wrong with the pattern above?  I’m surprised that this crashes. 
>>  My intent is simply to keep this QFont instance permanently allocated, so 
>> that whatever overhead is associated with making a new one doesn’t occur 
>> each time my view repaints (which happens at ~60Hz, ideally).  That is 
>> perhaps premature optimization, which is the root of all evil, I realize.  
>> But I want to understand *why* this pattern is bad, and what I might do 
>> instead, if the font creation were to indeed be a bottleneck.  Obviously 
>> there’s something about memory management in Qt that I don’t understand, 
>> because I don’t see anything wrong with this code!  :->  Thanks for any help.
>> 
>> Cheers,
>&g

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

Sorry for all the emails; this is proving to be quite a difficult problem and 
I’m really hoping somebody has insight into it.

This code also produces the same crash as the static QFont usage I posted in my 
previous email, and this code seems very clearly innocent:



QFont tickFont;
#ifdef __APPLE__
tickFont.setPointSize(9);
#else
tickFont.setPointSize(7);
#endif
painter.setFont(tickFont);



So now I’m starting to think this may actually be a Qt bug, perhaps related to 
caching of fonts internally in QOpenGLWidget.

But here’s the interesting bit: there is one other change in my app that is 
also causal.  I’m trying to get my app on macOS to stay running after the last 
window has closed, and to get the global menu bar to work properly in that mode 
of operation, I need to keep my main window alive after it’s closed (see the 
previous discussion thread on Qt-Interest).  To achieve that, I’m commenting 
out the call to:

setAttribute(Qt::WA_DeleteOnClose);

in my main window’s initialization.  With that call commented out, I can close 
the window, the global menubar remains correct because the main window is still 
alive in the background, BUT the app crashes on quit due to the font issue 
above.  With that setAttribute() call in place (not commented out), I can close 
the window, the app does not crash on quit, BUT the global menubar is screwed 
up because there’s no main window (see previous thread).

My closeEvent() just calls event->accept(); and returns.  With the 
setAttribute() call commented out, the window does not get deleted any more, it 
just closes (I have a qDebug() in its destructor to confirm that).  But then 
quitting crashes.  Putting the setAttribute() call back in fixes the crash; OR, 
commenting out the use of QFont in my QOpenGLWidget subclass fixes the crash.

Anybody know what’s going on, and how I might fix it or work around it?  I need 
to change the font in my widget, of course; and I seem to need to avoid 
deleting my main window, in order to keep the global menubar working when the 
last main window closes.  So I’m stuck.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 12:04 PM, Ben Haller via Interest 
>  wrote:
> 
> Hi all.  I’m starting a new thread since the focal question has completely 
> changed.  I’ve tracked down the cause of the crash that I discussed in the 
> previous thread, to a specific bit of code:
> 
> 
> 
> static QFont *tickFont = nullptr;
> 
> if (!tickFont)
> {
>   tickFont = new QFont();
>   tickFont->setPointSize(9);
> }
> painter.setFont(*tickFont);
> 
> 
> 
> I do this inside a QOpenGLWidget subclass, in my paintGL() override.  If I 
> comment this code out, no more crash on quit.  I figured this out because the 
> backtrace for my crash seemed to involve private font cache teardown in 
> QApplication, so I figured maybe I was doing something naughty involved 
> QFonts, so I commented out every usage of QFont in my app, and then started 
> uncommenting them one by one; when I uncommented this one, it crashes on 
> quit.  (I got AddressSanitizer working, but it didn’t provide any additional 
> info; I’m still working on getting Valgrind working on macOS 10.15.)
> 
> So.  What is wrong with the pattern above?  I’m surprised that this crashes.  
> My intent is simply to keep this QFont instance permanently allocated, so 
> that whatever overhead is associated with making a new one doesn’t occur each 
> time my view repaints (which happens at ~60Hz, ideally).  That is perhaps 
> premature optimization, which is the root of all evil, I realize.  But I want 
> to understand *why* this pattern is bad, and what I might do instead, if the 
> font creation were to indeed be a bottleneck.  Obviously there’s something 
> about memory management in Qt that I don’t understand, because I don’t see 
> anything wrong with this code!  :->  Thanks for any help.
> 
> Cheers,
> -B.
> 
> Benjamin C. Haller
> Messer Lab
> Cornell University
> 
> 
>> On Sep 23, 2020, at 7:50 AM, Ben Haller via Interest 
>>  wrote:
>> 
>> Hi all.  I’m trying to figure out what appears to be a double dealloc 
>> problem of some sort.  I’m sure the actual bug is in my code (I’m trying to 
>> get a window with complex subsidiary windows, etc., to disassemble and free 
>> the things it owns, without freeing itself), but the backtrace at the point 
>> that the crash happens doesn’t have any of my code in it at all.  I’ve 
>> appended the full backtrace below my signature, in case it is informative; 
>> maybe somebody has seen this pattern before and knows what I’m likely to be 
>> doing wrong.  My code does not use QFontCache or QScopedPointer at all, so 
>> it’s hard to guess where my bug might be.

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

Hi all.  I’m starting a new thread since the focal question has completely 
changed.  I’ve tracked down the cause of the crash that I discussed in the 
previous thread, to a specific bit of code:



static QFont *tickFont = nullptr;

if (!tickFont)
{
tickFont = new QFont();
tickFont->setPointSize(9);
}
painter.setFont(*tickFont);



I do this inside a QOpenGLWidget subclass, in my paintGL() override.  If I 
comment this code out, no more crash on quit.  I figured this out because the 
backtrace for my crash seemed to involve private font cache teardown in 
QApplication, so I figured maybe I was doing something naughty involved QFonts, 
so I commented out every usage of QFont in my app, and then started 
uncommenting them one by one; when I uncommented this one, it crashes on quit.  
(I got AddressSanitizer working, but it didn’t provide any additional info; I’m 
still working on getting Valgrind working on macOS 10.15.)

So.  What is wrong with the pattern above?  I’m surprised that this crashes.  
My intent is simply to keep this QFont instance permanently allocated, so that 
whatever overhead is associated with making a new one doesn’t occur each time 
my view repaints (which happens at ~60Hz, ideally).  That is perhaps premature 
optimization, which is the root of all evil, I realize.  But I want to 
understand *why* this pattern is bad, and what I might do instead, if the font 
creation were to indeed be a bottleneck.  Obviously there’s something about 
memory management in Qt that I don’t understand, because I don’t see anything 
wrong with this code!  :->  Thanks for any help.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 7:50 AM, Ben Haller via Interest 
>  wrote:
> 
> Hi all.  I’m trying to figure out what appears to be a double dealloc problem 
> of some sort.  I’m sure the actual bug is in my code (I’m trying to get a 
> window with complex subsidiary windows, etc., to disassemble and free the 
> things it owns, without freeing itself), but the backtrace at the point that 
> the crash happens doesn’t have any of my code in it at all.  I’ve appended 
> the full backtrace below my signature, in case it is informative; maybe 
> somebody has seen this pattern before and knows what I’m likely to be doing 
> wrong.  My code does not use QFontCache or QScopedPointer at all, so it’s 
> hard to guess where my bug might be.
> 
> My question, though, is bigger: how would folks here recommend debugging a 
> double dealloc in a Qt-based app, running under Qt Creator?  I’m coming from 
> the Cocoa/Xcode world, and in that world there’s a very nice tool called 
> NSZombie: you set a flag, and then whenever an object would be deallocated, 
> it instead turns into an NSZombie object that produces nice console logs if 
> anybody ever tries to use that memory as an object again.  But that’s for 
> NSObject.  Is there something similar in the Qt world, such that I could get 
> a console log or a break in the debugger at the point where a C++/Qt object 
> that has been dealloced gets touched again?  Or if not, how would you 
> recommend approaching this?  Thanks for any help.
> 
> Cheers,
> -B.
> 
> Benjamin C. Haller
> Messer Lab
> Cornell University
> 
> 
> 1  QScopedPointer QScopedPointerDeleter>::operator->() const   
>   
>   
> qscopedpointer.h   118  0x10201b594   
>  
> 2  decltype(fp.operator->()) qGetPtrHelper QScopedPointerDeleter> const>(QScopedPointer QScopedPointerDeleter> const&)   
>  qglobal.h
>   1133 0x10201b594
> 3  QObject::d_func() const
>   
>   
>qobject.h  
> 132  0x10201b594
> 4  QObject::thread() const
>   
>   
>qobject.cpp
> 1512 0x10201b594
> 5  QOpenGLVertexArrayObjectPrivate::destroy() 
>   
>

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

Thanks Giuseppe; this looks very interesting.  I’d love to be able to run 
Valgrind.

Thanks also to Mitch; I see your email now, and it also looks very useful.  To 
avoid spamming the list with thank-yous, I’ll just say in advance, thanks to 
all others who might respond with helpful suggestions.  :->

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 8:41 AM, Giuseppe D'Angelo via Interest 
>  wrote:
> 
> Il 23/09/20 14:08, Ben Haller via Interest ha scritto:
>> Thanks for the suggestion.  However, this problem is only on macOS, and 
>> Valgrind doesn’t appear to run on any macOS later than 10.12 (“preliminary” 
>> support for 10.13, according to their website; I’m not sure what that 
>> means).  I’m on macOS 10.15.6, and I’m using Qt 5.14.2 which has a minimum 
>> macOS version of 10.13, so Valgrind seems to be a no-go for at least one 
>> reason, perhaps two reasons (depending on “preliminary”).
> 
> There is a fork of Valgrind to support more modern macOS versions
> 
> https://github.com/LouisBrunner/valgrind-macos/
> 
> (Note: never used it myself, not a mac user).
> 
> Another option is getting a recent Clang version and rebuilding Qt and your 
> app with AddressSanitizer.
> 
> HTH,
> 
> -- 
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

(To be more clear: my hardware, a “Late 2019” MacBook Pro, can’t even run macOS 
10.13 – or 10.14, for that matter.  10.15 is required on my hardware, so 
Valgrind is out of the question, at least on this machine.  If I can find 
hardware that can run 10.13, then I can see whether Valgrind’s “preliminary” 
support will work on it, I guess.  But if there is another debugging technique 
that doesn’t depend on Valgrind, it would make my life much easier...)

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 8:08 AM, Ben Haller via Interest 
>  wrote:
> 
> Thanks for the suggestion.  However, this problem is only on macOS, and 
> Valgrind doesn’t appear to run on any macOS later than 10.12 (“preliminary” 
> support for 10.13, according to their website; I’m not sure what that means). 
>  I’m on macOS 10.15.6, and I’m using Qt 5.14.2 which has a minimum macOS 
> version of 10.13, so Valgrind seems to be a no-go for at least one reason, 
> perhaps two reasons (depending on “preliminary”).
> 
> Are there other approaches?
> 
> Cheers,
> -B.
> 
> Benjamin C. Haller
> Messer Lab
> Cornell University
> 
> 
>> On Sep 23, 2020, at 7:55 AM, Crocker, William  
>> wrote:
>> 
>> Valgrind.
>> 
>>> -Original Message-
>>> From: Interest  On Behalf Of Ben Haller via
>>> Interest
>>> Sent: Wednesday, September 23, 2020 7:50 AM
>>> To: qt qt 
>>> Subject: [Interest] Debugging a double dealloc
>>> 
>>> [External]
>>> 
>>> Hi all.  I’m trying to figure out what appears to be a double dealloc 
>>> problem of some
>>> sort.  I’m sure the actual bug is in my code (I’m trying to get a window 
>>> with complex
>>> subsidiary windows, etc., to disassemble and free the things it owns, 
>>> without freeing
>>> itself), but the backtrace at the point that the crash happens doesn’t have 
>>> any of my
>>> code in it at all.  I’ve appended the full backtrace below my signature, in 
>>> case it is
>>> informative; maybe somebody has seen this pattern before and knows what I’m
>>> likely to be doing wrong.  My code does not use QFontCache or 
>>> QScopedPointer at
>>> all, so it’s hard to guess where my bug might be.
>>> 
>>> My question, though, is bigger: how would folks here recommend debugging a
>>> double dealloc in a Qt-based app, running under Qt Creator?  I’m coming 
>>> from the
>>> Cocoa/Xcode world, and in that world there’s a very nice tool called 
>>> NSZombie: you
>>> set a flag, and then whenever an object would be deallocated, it instead 
>>> turns into an
>>> NSZombie object that produces nice console logs if anybody ever tries to 
>>> use that
>>> memory as an object again.  But that’s for NSObject.  Is there something 
>>> similar in
>>> the Qt world, such that I could get a console log or a break in the 
>>> debugger at the
>>> point where a C++/Qt object that has been dealloced gets touched again?  Or 
>>> if not,
>>> how would you recommend approaching this?  Thanks for any help.
>>> 
>>> Cheers,
>>> -B.
>>> 
>>> Benjamin C. Haller
>>> Messer Lab
>>> Cornell University
>>> 
>>> 
>>> 1  QScopedPointer>> QScopedPointerDeleter>::operator->() const
>>> qscopedpointer.h   118  0x10201b594
>>> 2  decltype(fp.operator->()) qGetPtrHelper>> QScopedPointerDeleter> const>(QScopedPointer>> QScopedPointerDeleter> const&)
>>> qglobal.h  1133 0x10201b594
>>> 3  QObject::d_func() const
>>> qobject.h  132  0x10201b594
>>> 4  QObject::thread() const
>>> qobject.cpp1512 0x10201b594
>>> 5  QOpenGLVertexArrayObjectPrivate::destroy()
>>> qopenglvertexarrayobject.cpp   212  0x101b21481
>>> 6  QOpenGLVertexArrayObject::destroy()
>>> qopenglvertexarrayobject.cpp   424  0x101b217cc
>>> 7  QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
>>> qopenglvertexarrayobject.cpp   392  0x101b217c3
>>> 8  QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
>>> qopenglvertexarrayobject.cpp   391  0x101b217b9
>>> 9  QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
>>> qopengltextureglyphcache.cpp   93   0x101b1cacd
>>> 10 QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
>>> qopengltextureglyphcache.cpp 

Re: [Interest] Debugging a double dealloc

[Ben Haller via Interest]

Thanks for the suggestion.  However, this problem is only on macOS, and 
Valgrind doesn’t appear to run on any macOS later than 10.12 (“preliminary” 
support for 10.13, according to their website; I’m not sure what that means).  
I’m on macOS 10.15.6, and I’m using Qt 5.14.2 which has a minimum macOS version 
of 10.13, so Valgrind seems to be a no-go for at least one reason, perhaps two 
reasons (depending on “preliminary”).

Are there other approaches?

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 23, 2020, at 7:55 AM, Crocker, William  
> wrote:
> 
> Valgrind.
> 
>> -Original Message-
>> From: Interest  On Behalf Of Ben Haller via
>> Interest
>> Sent: Wednesday, September 23, 2020 7:50 AM
>> To: qt qt 
>> Subject: [Interest] Debugging a double dealloc
>> 
>> [External]
>> 
>> Hi all.  I’m trying to figure out what appears to be a double dealloc 
>> problem of some
>> sort.  I’m sure the actual bug is in my code (I’m trying to get a window 
>> with complex
>> subsidiary windows, etc., to disassemble and free the things it owns, 
>> without freeing
>> itself), but the backtrace at the point that the crash happens doesn’t have 
>> any of my
>> code in it at all.  I’ve appended the full backtrace below my signature, in 
>> case it is
>> informative; maybe somebody has seen this pattern before and knows what I’m
>> likely to be doing wrong.  My code does not use QFontCache or QScopedPointer 
>> at
>> all, so it’s hard to guess where my bug might be.
>> 
>> My question, though, is bigger: how would folks here recommend debugging a
>> double dealloc in a Qt-based app, running under Qt Creator?  I’m coming from 
>> the
>> Cocoa/Xcode world, and in that world there’s a very nice tool called 
>> NSZombie: you
>> set a flag, and then whenever an object would be deallocated, it instead 
>> turns into an
>> NSZombie object that produces nice console logs if anybody ever tries to use 
>> that
>> memory as an object again.  But that’s for NSObject.  Is there something 
>> similar in
>> the Qt world, such that I could get a console log or a break in the debugger 
>> at the
>> point where a C++/Qt object that has been dealloced gets touched again?  Or 
>> if not,
>> how would you recommend approaching this?  Thanks for any help.
>> 
>> Cheers,
>> -B.
>> 
>> Benjamin C. Haller
>> Messer Lab
>> Cornell University
>> 
>> 
>> 1  QScopedPointer> QScopedPointerDeleter>::operator->() const
>> qscopedpointer.h   118  0x10201b594
>> 2  decltype(fp.operator->()) qGetPtrHelper> QScopedPointerDeleter> const>(QScopedPointer> QScopedPointerDeleter> const&)
>> qglobal.h  1133 0x10201b594
>> 3  QObject::d_func() const
>> qobject.h  132  0x10201b594
>> 4  QObject::thread() const
>> qobject.cpp1512 0x10201b594
>> 5  QOpenGLVertexArrayObjectPrivate::destroy()
>> qopenglvertexarrayobject.cpp   212  0x101b21481
>> 6  QOpenGLVertexArrayObject::destroy()
>> qopenglvertexarrayobject.cpp   424  0x101b217cc
>> 7  QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
>> qopenglvertexarrayobject.cpp   392  0x101b217c3
>> 8  QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
>> qopenglvertexarrayobject.cpp   391  0x101b217b9
>> 9  QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
>> qopengltextureglyphcache.cpp   93   0x101b1cacd
>> 10 QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
>> qopengltextureglyphcache.cpp   88   0x101b1cbce
>> 11 QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
>> qopengltextureglyphcache.cpp   88   0x101b1cbc9
>> 12
>> QExplicitlySharedDataPointer::~QExplicitlySharedData
>> Pointer()
>> qshareddata.h  184  0x101883c92
>> 13
>> QExplicitlySharedDataPointer::~QExplicitlySharedData
>> Pointer()
>> qshareddata.h  184  0x101883c74
>> 14 QFontEngine::GlyphCacheEntry::~GlyphCacheEntry()
>> qfontengine.cpp1570 0x101883c74
>> 15 QFontEngine::GlyphCacheEntry::~GlyphCacheEntry()
>> qfontengine.cpp1569 0x101883c74
>> 16 void
>> std::allocator_traits> , void
>> *>>>::__destroy(std::integral_constant> false>, std::allocator> *>>&,
>> QFontEngine::GlyphCacheEntry *) memory 1732 
>> 0x101883c74
>> 1

[Interest] Debugging a double dealloc

[Ben Haller via Interest]

Hi all.  I’m trying to figure out what appears to be a double dealloc problem 
of some sort.  I’m sure the actual bug is in my code (I’m trying to get a 
window with complex subsidiary windows, etc., to disassemble and free the 
things it owns, without freeing itself), but the backtrace at the point that 
the crash happens doesn’t have any of my code in it at all.  I’ve appended the 
full backtrace below my signature, in case it is informative; maybe somebody 
has seen this pattern before and knows what I’m likely to be doing wrong.  My 
code does not use QFontCache or QScopedPointer at all, so it’s hard to guess 
where my bug might be.

My question, though, is bigger: how would folks here recommend debugging a 
double dealloc in a Qt-based app, running under Qt Creator?  I’m coming from 
the Cocoa/Xcode world, and in that world there’s a very nice tool called 
NSZombie: you set a flag, and then whenever an object would be deallocated, it 
instead turns into an NSZombie object that produces nice console logs if 
anybody ever tries to use that memory as an object again.  But that’s for 
NSObject.  Is there something similar in the Qt world, such that I could get a 
console log or a break in the debugger at the point where a C++/Qt object that 
has been dealloced gets touched again?  Or if not, how would you recommend 
approaching this?  Thanks for any help.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


1  QScopedPointer>::operator->() const 


  qscopedpointer.h   118  0x10201b594
2  decltype(fp.operator->()) qGetPtrHelper> const>(QScopedPointer> const&) 
   qglobal.h
  1133 0x10201b594
3  QObject::d_func() const  


 qobject.h  
132  0x10201b594
4  QObject::thread() const  


 qobject.cpp
1512 0x10201b594
5  QOpenGLVertexArrayObjectPrivate::destroy()   


 qopenglvertexarrayobject.cpp   
212  0x101b21481
6  QOpenGLVertexArrayObject::destroy()  


 qopenglvertexarrayobject.cpp   
424  0x101b217cc
7  QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()


 qopenglvertexarrayobject.cpp   
392  0x101b217c3
8  QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()


 qopenglvertexarrayobject.cpp   
391  0x101b217b9
9  QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()


 qopengltextureglyphcache.cpp   
93   0x101b1cacd
10 QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()


 qopengltextureglyphcache.cpp   
88   0x101b1cbce
11 QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()

 

Re: [Interest] QActions not moved to application menu properly

[Ben Haller via Interest]

You are a good guesser, Sean!

I tried commenting out the call I make to:

setAttribute(Qt::WA_DeleteOnClose);

when I’m setting up my main windows.  With that commented out, things work 
fine.  I’m leaking the document window and everything it owns, of course, so 
that isn’t great; but it works.  So perhaps I can make a minimal document 
window at startup, which I never show, just to make Qt happy.

The other quirk I’ve just noticed is that even *without* commenting out that 
call, there is a usage pattern where everything works, and a different usage 
pattern where it doesn’t.  In my testing, I had been following the pattern that 
doesn’t work.  In summary:

WORKS: pressing command-W to trigger my Close menu item, which just calls 
close() on the active window; my guess is that something about the processing 
of the shortcut, or a different order of operations internally, makes this 
usage pattern work properly.  The Quit menu item, etc., appear after the window 
is closed.

DOESN’T WORK: closing the active window by clicking its title bar close button 
instead.  The Quit menu item, etc., just vanish.

If there were something about the usage pattern that works that I could trigger 
in the case of the usage pattern that doesn’t work, perhaps that would 
constitute a workaround.  However, Sean’s idea presently appears that it will 
provide a workaround too, so I’ll try that first.

Thanks Sean!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 22, 2020, at 2:56 PM, Murphy, Sean  wrote:
> 
> I'm not on a Mac right now, so I can't try this, so I don’t know if this will 
> work:
> 
> As each window (I assume these are QMainWindow, or at least inherit from 
> one) is closed, are you deleting them? If so, when you get to the last one, 
> could 
> you hide it instead of deleting it? Or when you've deleted the last one, then 
> immediately create a new one and hide it?
> 
> My theory being that maybe for Qt to do it's Mac menu magic, there needs 
> to always be a QMainWindow present (but not necessarily shown)?
> 
> Just a total guess on my part...
> Sean
> 
> 
> This message has been scanned for malware by Forcepoint. www.forcepoint.com

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QActions not moved to application menu properly

[Ben Haller via Interest]

A little followup; sorry, this should have been  in my first email.  It would 
probably be useful to show more code; here’s the method where I create the 
global menu bar:

 void QtSLiMAppDelegate::makeGlobalMenuBar(void)
{
#ifdef __APPLE__
if (!windowlessMenuBar)
{
windowlessMenuBar = new QMenuBar(nullptr);
QMenu *fileMenu = new QMenu("File", windowlessMenuBar);

windowlessMenuBar->addMenu(fileMenu);

fileMenu->addAction("About SLiMgui", this, 
::dispatch_about);
fileMenu->addAction("Preferences...", this, 
::dispatch_preferences, Qt::CTRL + Qt::Key_Comma);
fileMenu->addSeparator();
fileMenu->addAction("New", this, ::dispatch_newWF, 
Qt::CTRL + Qt::Key_N);
fileMenu->addAction("New (nonWF)", this, 
::dispatch_newNonWF, Qt::CTRL + Qt::SHIFT + Qt::Key_N);
fileMenu->addAction("Open...", this, ::dispatch_open, 
Qt::CTRL + Qt::Key_O);
fileMenu->addSeparator();
fileMenu->addAction("Quit SLiMgui", this, 
::dispatch_quit, Qt::CTRL + Qt::Key_Q);
}
#endif
}

This is more minimal than the working version of the code I’m using, but this 
minimal code still reproduces the bug, for me: the about, preferences, and quit 
item disappear from the File menu, and are not added to the application menu.  
Note that the other menu items present (“New”, etc.) remain in the File menu 
and work fine, and appear as expected when the app has no main window open.  
Note also that if I then create a new window (by selecting “New”), the app 
switches back to the menu bar coded in the .ui file for the main window, and 
the Quit menu item, and others, are back in the application menu where they 
belong.  So there is something wrong specifically with the repositioning of 
menu items in the global menu bar.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Sep 22, 2020, at 2:24 PM, Ben Haller  wrote:
> 
> Hi all.  I’m on Qt 5.14.2, with a Qt Widgets based app that runs on both 
> macOS and Linux.  I’m having trouble getting my menu bar to work.
> 
> So that things work smoothly on Linux platforms where there is a menu bar in 
> each main window, I have a menu bar in the .ui file that contains my main 
> window.  That design works fine, on both platforms.  Where things have gotten 
> bumpy is when I decided to try to make it so my app stays running even when 
> the last document window is closed, as is fairly typical for macOS apps; this 
> definitely makes sense for my app, where it would be common to close one 
> window and then create a new window to continue working.  To make this 
> happen, I call setQuitOnLastWindowClosed(false), at startup in main(), after 
> creating QApplication and before parsing the command line and creating the 
> initial main window.  This, in itself, seems to work fine; now the app 
> doesn’t quit when the last window is closed.  I do this on macOS only, and 
> the remainder of this question applies solely to macOS; on Linux the app 
> quits when the last window is closed, and there is no problem.
> 
> Since the menu bar is owned by the main windows in my app, when the last 
> window is closed the menu bar reverts to a very minimal default state; all of 
> the other menus disappear.  I want to have a full menu bar (perhaps minus a 
> couple of main-window-specific menus) in that mode, so I’ve been trying to 
> get a “global menu bar” working, as described in the QMenuBar doc (by making 
> a QMenuBar object that has no parent).  I’ve tried this a couple of different 
> ways, but I can’t get it to work completely.  The problem is always that some 
> of the menu items that need to be moved into the application menu on macOS 
> don’t move – they disappear.  Specifically, this happens to the About, 
> Preferences, and Quit menu items.  The menu bar appears fine whenever a main 
> window is open; the menu bar that gets created by that .ui file seems to work 
> perfectly.  But the “global” menu bar that I create myself is missing those 
> items.
> 
> I’ve tried creating the global menu bar either when the last window closes 
> (i.e., on demand), or at startup before the first main window is created; the 
> behavior is the same either way.  I’ve tried creating the Quit menu item the 
> easy way, with:
> 
> fileMenu->addAction("Quit SLiMgui", this, ::dispatch_quit, 
> Qt::CTRL + Qt::Key_Q);
> 
> or the long way, creating the QAction and then setting its shortcut, 
> connecting it, and finally adding it to fileMenu; the behavior is the same 
> either way.  I’ve tried poking the menu bar after I’ve finished creating it, 
> by calling toNSMenu(); makes no difference.  I’ve tried setting the menu role 
> for the Quit item to QuitRole, before adding it to fileMenu, or leaving it as 
> the default; makes no difference.
> 
> In all cases, I can output the structure of the menu bar immediately after I 
> create it and I see (showing just the File menu, where the Quit item gets 
> added by my 

[Interest] QActions not moved to application menu properly

[Ben Haller via Interest]

Hi all.  I’m on Qt 5.14.2, with a Qt Widgets based app that runs on both macOS 
and Linux.  I’m having trouble getting my menu bar to work.

So that things work smoothly on Linux platforms where there is a menu bar in 
each main window, I have a menu bar in the .ui file that contains my main 
window.  That design works fine, on both platforms.  Where things have gotten 
bumpy is when I decided to try to make it so my app stays running even when the 
last document window is closed, as is fairly typical for macOS apps; this 
definitely makes sense for my app, where it would be common to close one window 
and then create a new window to continue working.  To make this happen, I call 
setQuitOnLastWindowClosed(false), at startup in main(), after creating 
QApplication and before parsing the command line and creating the initial main 
window.  This, in itself, seems to work fine; now the app doesn’t quit when the 
last window is closed.  I do this on macOS only, and the remainder of this 
question applies solely to macOS; on Linux the app quits when the last window 
is closed, and there is no problem.

Since the menu bar is owned by the main windows in my app, when the last window 
is closed the menu bar reverts to a very minimal default state; all of the 
other menus disappear.  I want to have a full menu bar (perhaps minus a couple 
of main-window-specific menus) in that mode, so I’ve been trying to get a 
“global menu bar” working, as described in the QMenuBar doc (by making a 
QMenuBar object that has no parent).  I’ve tried this a couple of different 
ways, but I can’t get it to work completely.  The problem is always that some 
of the menu items that need to be moved into the application menu on macOS 
don’t move – they disappear.  Specifically, this happens to the About, 
Preferences, and Quit menu items.  The menu bar appears fine whenever a main 
window is open; the menu bar that gets created by that .ui file seems to work 
perfectly.  But the “global” menu bar that I create myself is missing those 
items.

I’ve tried creating the global menu bar either when the last window closes 
(i.e., on demand), or at startup before the first main window is created; the 
behavior is the same either way.  I’ve tried creating the Quit menu item the 
easy way, with:

 fileMenu->addAction("Quit SLiMgui", this, ::dispatch_quit, 
Qt::CTRL + Qt::Key_Q);

or the long way, creating the QAction and then setting its shortcut, connecting 
it, and finally adding it to fileMenu; the behavior is the same either way.  
I’ve tried poking the menu bar after I’ve finished creating it, by calling 
toNSMenu(); makes no difference.  I’ve tried setting the menu role for the Quit 
item to QuitRole, before adding it to fileMenu, or leaving it as the default; 
makes no difference.

In all cases, I can output the structure of the menu bar immediately after I 
create it and I see (showing just the File menu, where the Quit item gets added 
by my code):

"File"
  "About SLiMgui"
  "Preferences..."
  ""
...
  ""
  "Quit SLiMgui"

So the items in question are present, in the File menu where I put them.  But 
then when I click on the menu bar in my app, these menu items – about, 
preferences, and quit – are not in the File menu, nor are they in the 
application menu; they’re just gone.  They have been filtered out, somewhere 
down the road.

Since this global menu bar stuff is macOS-specific code anyway, I would happily 
just add the menu items to the application menu myself, avoiding Qt’s 
relocation logic.  However, as far as I can tell the QMenuBar object that I 
create doesn’t have an application menu in it; that seems to be private.  So 
Qt’s migration code isn’t doing the right thing, and I can find no way to just 
do the right thing on my own.  I’m running out of ideas.  Is this just a bug, 
or am I doing something wrong?  If it’s a bug, is there a way to trigger the 
menu item migration myself in a way that would work?

Thanks for any help; I’m at my wit’s end.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable automatic shortcuts for certain widgets?

[Ben Haller via Interest]

Why not just replace ‘&’ with ‘&&’ in the string the user inputs, before 
setting it as the name on the tab?

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Jun 9, 2020, at 11:39 AM, Murphy, Sean  wrote:
> 
> In our application, we have a QTabWidget. We allow the users to rename the 
> tabs. One of our users discovered that if they put an '&' in the string, it 
> isn't displayed, and if they put two together in sequence ("&&"), a single 
> '&' is displayed on the tab widget.
> 
> I completely understand what's happening, the text they are entering is being 
> evaluated by the native widgets for the presence of the '&' character to 
> automatically create shortcuts as described here: 
> https://doc.qt.io/qt-5/qabstractbutton.html#text-prop.
> 
> In other parts of our application, I do want the automatic shortcut 
> functionality (i.e. having the  for the File menu is something I'd like 
> to keep), but for this specific tab widget I'd like to disable that 
> functionality since our users aren't software developers and they find it 
> weird that the ampersand character behaves differently than other characters 
> in the string.
> 
> I don't see any way to disable that functionality though, is there one that 
> I'm missing?
> 
> Sean
> 
> 
> 
> 
> This message has been scanned for malware by Forcepoint. www.forcepoint.com
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash due to missing symbol

[Ben Haller via Interest]

Hi Alex.  Do you have the “deployment target” set to 10.10, not 10.14, in your 
project?  In Xcode this is in the project settings; in Qt Creator it’s a 
setting in the .pro file.  You can’t set it to be any earlier than the Qt 
version you are running against, however, or precisely this sort of thing will 
happen.  If you need to run on older OS X versions, you need to make sure the 
Qt version you’re using is compatible with those older versions.  (I forget 
where this information is, but Google always finds it for me.  :->)

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Jun 5, 2020, at 3:55 PM, Alexander Carôt  wrote:
> 
> Hi all,
> 
> when running my Qt app (compiled on Catalona with SDK10.15) on older OSX < 
> 10.14 down to 10.10 I get the following crash when initializing the audio 
> interface:
> 
> Termination Reason: DYLD, [0x4] Symbol missing
> 
> Dyld Error Message:
> Symbol not found: chkstk_darwin
> Referenced from: /Applications/soundjack.app/Contents/MacOS/soundjack
> Expected in: /usr/lib/libSystem.B.dylib
> 
> Does anyone know how to debug this ?
> 
> Thanks in advance,
> best
> 
> Alex
> 
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Link failure with undefined references, on Ubuntu but not macOS

[Ben Haller via Interest]

Hi Thiago.  Thanks for this.  My link dependencies do presently obey this 
constraint (directed acyclic graph), but I’ll add the setting you suggest to 
enforce that!  :->

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Apr 29, 2020, at 11:43 PM, Thiago Macieira  
> wrote:
> 
> On Wednesday, 29 April 2020 18:57:24 PDT Ben Haller via Interest wrote:
>>  Aha!  And I figured out that the order in which I declare the dependencies
>> in my .pro file determines the order in which those dependencies appear in
>> the link command.  I fixed that, and now it builds.
>> 
>>  I guess this was not biting me before because I used to link these
>> internal libraries dynamically instead; perhaps the link order is not
>> important with dynamic linking? 
> 
> Correct, searching for symbols in dynamic libraries is different because the 
> linker searches all of them. It doesn't need to solve from one to the other, 
> since that was resolved when each library was itself linked.
> 
> Hint: make sure you're using -Wl,--no-undefined. In your .pro file, for each 
> library and plugin:
> 
> QMAKE_LFLAGS += $$QMAKE_LFLAGS_NOUNDEF
> 
>> So when I recently changed to static
>> linking for these internal libraries, the link order suddenly mattered, and
>> my build broke.  And I guess perhaps the linker on macOS doesn’t have this
>> requirement, and so the build continued to work there?
> 
> I don't know how the Apple linker works.
> 
> The traditional linker works sequentially to avoid a very long link time. 
> After it's created the list of all outstanding undefined symbols from your 
> binary's .o files, it iterates over the library list. For each one, it checks 
> if the library solves some symbols and then each individual .o in the static 
> library to the build. After that, it promptly forgets about the library and 
> moves on to the next one. That's why libB.a can't depend on libA.a: the 
> linker 
> won't search it again.
> 
> If it did, you could write:
>  -lA -lB -lA
> 
> Then the linker will search libA.a again for other .o that have symbols that 
> libB requires.
> 
> Note that this may add .o that need more symbols from libB.a that haven't 
> been 
> added to the build yet. That means your linker line would need to be:
> 
>  -lA -lB -lA -lB
> 
> This isn't infinite because there's a finite number of .o files in each 
> library. The GNU linker has a shorthand for this but I won't mention it here. 
> Read the docs if needed.
> 
> Conclusion: break the cycle. The library dependency graph should be one way 
> (directed acyclic graph). That's why I recommended that --no-undefined for 
> dynamic linking: it'll prevent you from making the cycles.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Link failure with undefined references, on Ubuntu but not macOS

[Ben Haller via Interest]

Hi Thiago,

> On Apr 29, 2020, at 8:48 PM, Thiago Macieira  
> wrote:
> 
> On Wednesday, 29 April 2020 15:16:49 PDT Ben Haller via Interest wrote:
>> -ltskit -lQt5OpenGL -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread
>> 
>> And here’s the beginning of the link errors, of which there are a fair
>> number:
>> 
>> /home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos//libeidos.a(eidos_glob
>> als.o): In function `_Eidos_FlushZipBuffer(std::__cxx11::basic_string> std::char_traits, std::allocator > const&,
>> std::__cxx11::basic_string,
>> std::allocator > const&)': 
>> eidos_globals.cpp:(.text+0x432): undefined reference to `z_gzopen'
>> eidos_globals.cpp:(.text+0x44f): undefined reference to `z_gzbuffer'
>> eidos_globals.cpp:(.text+0x461): undefined reference to `z_gzwrite'
>> eidos_globals.cpp:(.text+0x474): undefined reference to `z_gzclose_w'
> 
> -lz is missing on your linker command-line.

  These symbols are brought in with -leidos_zlib, an internal library.

>> chromosome.cpp:(.text+0x3f): undefined reference to `gsl_ran_discrete_free'
>> chromosome.cpp:(.text+0x4d): undefined reference to `gsl_ran_discrete_free'
>> chromosome.cpp:(.text+0x5b): undefined reference to `gsl_ran_discrete_free'
>> chromosome.cpp:(.text+0x69): undefined reference to `gsl_ran_discrete_free'
>> chromosome.cpp:(.text+0x77): undefined reference to `gsl_ran_discrete_free’
> 
> Some other library also missing. I don't have this symbol in any library on 
> my 
> system so I can't offer you a suggestion. Please consult the its 
> documentation 
> (since you're using it, you must know it) and figure out what it is called so 
> you can link.
> 
> Though I do note you have -lgsl on your linker line. If this is the right 
> library, then check if the library has those symbols (nm -D if it's an .so, 
> nm 
> if it's .a).

  These are brought in with -lgsl, another internal library.

>> gsl: a statically linked C library (an edited version of the GNU GSL
>> library)
>> eidos_zlib: a statically linked C library (an edited version of the standard
>> zlib library)
> 
> If libraries are static, the order in the linker command-line matters. The 
> library must appear after the object that requires it.
> 
> For example, for:
>   obj.o -lA -lB
> 
> obj.o can depend on libA.a and libB.a; libA.a can depend on libB.a.
> 
> libB.a cannot depend on libA.a

  Aha!  And I figured out that the order in which I declare the dependencies in 
my .pro file determines the order in which those dependencies appear in the 
link command.  I fixed that, and now it builds.

  I guess this was not biting me before because I used to link these internal 
libraries dynamically instead; perhaps the link order is not important with 
dynamic linking?  So when I recently changed to static linking for these 
internal libraries, the link order suddenly mattered, and my build broke.  And 
I guess perhaps the linker on macOS doesn’t have this requirement, and so the 
build continued to work there?

  Anyway, problem solved, wonderful.  Thank you, Thiago!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Link failure with undefined references, on Ubuntu but not macOS

[Ben Haller via Interest]

Hi folks.  I’ve got a subdirs-type Qt Widgets project that lives here:

https://github.com/MesserLab/SLiM/tree/qtslim

(Note that’s the qtslim branch of a project named SLiM; the Qt stuff is all on 
the branch until I get it completely working.)

I build it with qmake and then make, with no further command-line flags.  I 
build it for two platforms: Linux (Ubuntu 18.04 LTS, specifically) and macOS 
(10.15.3).  In both cases I’m using Qt 5.14.2.

On Linux, but not on macOS, the build fails.  Here’s the link command:

g++ -Wl,-O1 -o QtSLiM main.o QtSLiMWindow.o QtSLiMAppDelegate.o 
QtSLiMWindow_glue.o QtSLiMChromosomeWidget.o QtSLiMExtras.o 
QtSLiMPopulationTable.o QtSLiMIndividualsWidget.o QtSLiMEidosPrettyprinter.o 
QtSLiMAbout.o QtSLiMPreferences.o QtSLiMSyntaxHighlighting.o QtSLiMFindRecipe.o 
QtSLiMHelpWindow.o QtSLiMScriptTextEdit.o QtSLiMEidosConsole.o 
QtSLiMEidosConsole_glue.o QtSLiMConsoleTextEdit.o QtSLiM_SLiMgui.o 
QtSLiMTablesDrawer.o QtSLiMFindPanel.o QtSLiMGraphView.o 
QtSLiMGraphView_FixationTimeHistogram.o QtSLiMGraphView_FrequencySpectra.o 
QtSLiMGraphView_LossTimeHistogram.o QtSLiMGraphView_PopulationVisualization.o 
QtSLiMGraphView_FitnessOverTime.o QtSLiMGraphView_FrequencyTrajectory.o 
QtSLiMHaplotypeManager.o QtSLiMHaplotypeOptions.o QtSLiMHaplotypeProgress.o 
QtSLiMVariableBrowser.o qrc_buttons.o qrc_icons.o qrc_recipes.o qrc_help.o 
moc_QtSLiMWindow.o moc_QtSLiMAppDelegate.o moc_QtSLiMChromosomeWidget.o 
moc_QtSLiMExtras.o moc_QtSLiMPopulationTable.o moc_QtSLiMIndividualsWidget.o 
moc_QtSLiMAbout.o moc_QtSLiMPreferences.o moc_QtSLiMSyntaxHighlighting.o 
moc_QtSLiMFindRecipe.o moc_QtSLiMHelpWindow.o moc_QtSLiMScriptTextEdit.o 
moc_QtSLiMEidosConsole.o moc_QtSLiMConsoleTextEdit.o moc_QtSLiMTablesDrawer.o 
moc_QtSLiMFindPanel.o moc_QtSLiMGraphView.o 
moc_QtSLiMGraphView_FixationTimeHistogram.o 
moc_QtSLiMGraphView_FrequencySpectra.o moc_QtSLiMGraphView_LossTimeHistogram.o 
moc_QtSLiMGraphView_PopulationVisualization.o 
moc_QtSLiMGraphView_FitnessOverTime.o moc_QtSLiMGraphView_FrequencyTrajectory.o 
moc_QtSLiMHaplotypeManager.o moc_QtSLiMHaplotypeOptions.o 
moc_QtSLiMHaplotypeProgress.o moc_QtSLiMVariableBrowser.o   
-L/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../gsl/ -lgsl 
-L/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos_zlib/ -leidos_zlib 
-L/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos/ -leidos 
-L/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../core/ -lcore 
-L/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../treerec/tskit/ -ltskit 
-lQt5OpenGL -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread 

And here’s the beginning of the link errors, of which there are a fair number:

/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos//libeidos.a(eidos_globals.o):
 In function `_Eidos_FlushZipBuffer(std::__cxx11::basic_string, std::allocator > const&, 
std::__cxx11::basic_string, std::allocator > 
const&)':
eidos_globals.cpp:(.text+0x432): undefined reference to `z_gzopen'
eidos_globals.cpp:(.text+0x44f): undefined reference to `z_gzbuffer'
eidos_globals.cpp:(.text+0x461): undefined reference to `z_gzwrite'
eidos_globals.cpp:(.text+0x474): undefined reference to `z_gzclose_w'
/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos//libeidos.a(eidos_globals.o):
 In function `Eidos_TTest_TwoSampleWelch(double const*, int, double const*, 
int, double*, double*)':
eidos_globals.cpp:(.text+0x3f99): undefined reference to `gsl_cdf_tdist_Q'
/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../eidos//libeidos.a(eidos_globals.o):
 In function `Eidos_TTest_OneSample(double const*, int, double, double*)':
eidos_globals.cpp:(.text+0x4195): undefined reference to `gsl_cdf_tdist_Q'
/home/bhaller/Desktop/SLiM_QMAKE_5142/QtSLiM/../core//libcore.a(chromosome.o): 
In function `Chromosome::~Chromosome()':
chromosome.cpp:(.text+0x3f): undefined reference to `gsl_ran_discrete_free'
chromosome.cpp:(.text+0x4d): undefined reference to `gsl_ran_discrete_free'
chromosome.cpp:(.text+0x5b): undefined reference to `gsl_ran_discrete_free'
chromosome.cpp:(.text+0x69): undefined reference to `gsl_ran_discrete_free'
chromosome.cpp:(.text+0x77): undefined reference to `gsl_ran_discrete_free’
…

The complete errors are listed in the GitHub issue, at 
https://github.com/MesserLab/SLiM/issues/90.

I’m not terribly good at qmake, but I have gone over the .pro files with a 
fine-toothed comb and can’t find anything wrong.  I also actually constructed 
the whole project again from scratch in Qt Creator, to see whether I had 
screwed up some modification I had previously done to the .pro files, but the 
newly created .pro files for the reconstructed project seemed to be identical 
in all relevant respects to the existing .pro files.

The subdirs-style project contains several subprojects:

QtSLiM: the Qt Widgets app
gsl: a statically linked C library (an edited version of the GNU GSL library)
eidos_zlib: a statically linked C library (an edited version of the standard 
zlib library)
eidos: a statically linked C++ library

Re: [Interest] Crash when signal fires

[Ben Haller via Interest]

> On Apr 22, 2020, at 11:19 AM, Thiago Macieira  
> wrote:
> 
> On Tuesday, 21 April 2020 17:09:45 PDT Ben Haller via Interest wrote:
>>  Unfortunately, I’m on macOS 10.15.3 and Valgrind is not there yet (I think
>> at present they have “preliminary” support for macOS 10.13).
> 
> Then install a Linux VM and use Valgrind there. Valgrind is useful enough to 
> warrant a VM just for it.

  Ah, that is a good idea!  I shall do so.

>>  I suspect this is a really dumb question, but what is “ASAN”?  Is that
>> another Valgrind-like tool?
> 
> -fsanitize=address in your compilation and linking flags.
> 
> With qmake, you can also get that by doing:
> 
> CONFIG += sanitizer sanitize_address

  Aha, very interesting.  I’ll try this as well.  Thanks for the help.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when signal fires

[Ben Haller via Interest]

> On Apr 22, 2020, at 11:17 AM, Thiago Macieira  
> wrote:
> 
> On Tuesday, 21 April 2020 16:44:19 PDT Ben Haller via Interest wrote:
>>connect(qApp, ::focusChanged, [this]() {
>> updateUIEnabling(); });
> 
> Your object probably outlived QApplication.

  Other way around, right?

> Add a third argument of "this" to the connect() call.

  Yes, Giuseppe D’Angelo set me on the right path on this, and I’ve just gone 
through all the connect() calls in my app and made them all safe.  Thanks!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when signal fires

[Ben Haller via Interest]

> On Apr 21, 2020, at 7:51 PM, Giuseppe D'Angelo via Interest 
>  wrote:
> 
> On 4/22/20 1:44 AM, Ben Haller via Interest wrote:
>> Hi folks.  I’m seeing something weird that I don’t understand.  I have a 
>> connection defined for the main window of my Qt Widgets app, like so:
>> connect(qApp, ::focusChanged, [this]() { 
>> updateUIEnabling(); });
>> I’m seeing a 100% reproducible crash as a result of this.  When the 
>> focusChanged signal fires, I end up in updateUIEnabling() as expected, but I 
>> immediately crash because something about the state of things is corrupted; 
>> the immediate symptom, according to the debugger, is that the ui pointer for 
>> my main window is equal to 0x1 (yuck).  I try to access a button,  
>> ui->playOneStepButton, and it crashes.  As I said, 100% reproducible.
>> The weird thing is that this does*not*  happen if I change the connect 
>> statement to this:
>> connect(qApp, ::focusChanged, this, 
>> ::updateUIEnabling);
>> Now, 100% of the time, there is no problem, no crash, and my app chugs along 
>> happily.  No other code changes involved.  I can literally flip this connect 
>> definition back and forth in my code and go from 100% crashing to 100% fine.
> 
> A quick checklist:
> 
> 0) I hope threads are not involved (you're not really allowed to do any GUI 
> work from any other thread).

  No threads.

> 1) Never use the 3-arguments connect(). If you want to use the lambda, pass 
> "this" as 3rd parameter and lambda as fourth. Why: if "this" has been 
> destroyed, the first version won't disconnect automatically and crash. The 
> second will disconnect and not crash.
> 
> More info: https://stackoverflow.com/a/27954502

  Ah, I see!  I was assuming it was my first window’s focusChanged connection 
that was crashing, but it was probably the second (closed) window’s connection 
that was crashing, in fact, because the window was gone but the connection 
remained.

> 2) ASAN, Valgrind and friends will help you locate the source of the crash if 
> it's due to memory corruption. Use them.

  Unfortunately, I’m on macOS 10.15.3 and Valgrind is not there yet (I think at 
present they have “preliminary” support for macOS 10.13).

  I suspect this is a really dumb question, but what is “ASAN”?  Is that 
another Valgrind-like tool?

  Well, in any case, I think you have explained my bug.  Thanks very much!

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Crash when signal fires

[Ben Haller via Interest]

[ I realized I ought to supply the crash backtrace; I have appended it below my 
signature. ]

Hi folks.  I’m seeing something weird that I don’t understand.  I have a 
connection defined for the main window of my Qt Widgets app, like so:

   connect(qApp, ::focusChanged, [this]() { updateUIEnabling(); });

I’m seeing a 100% reproducible crash as a result of this.  When the 
focusChanged signal fires, I end up in updateUIEnabling() as expected, but I 
immediately crash because something about the state of things is corrupted; the 
immediate symptom, according to the debugger, is that the ui pointer for my 
main window is equal to 0x1 (yuck).  I try to access a button,  
ui->playOneStepButton, and it crashes.  As I said, 100% reproducible.

The weird thing is that this does *not* happen if I change the connect 
statement to this:

   connect(qApp, ::focusChanged, this, 
::updateUIEnabling);

Now, 100% of the time, there is no problem, no crash, and my app chugs along 
happily.  No other code changes involved.  I can literally flip this connect 
definition back and forth in my code and go from 100% crashing to 100% fine.

I’m pretty new to Qt and maybe I’m just being clueless somehow; but I thought 
that the two definitions above would be essentially identical in their effect.  
Why does the first one crash?  Note that it works fine in general; it seems to 
crash specifically when I open a *second* main window (which makes its own 
connection to focusChanged in the same way), and then close that second main 
window.  Now the first main window’s connection is somehow unhappy, and the 
next time I trigger the focusChanged() signal, boom.  It’s as if the connection 
for the second window somehow interferes with the connection for the first 
window, and closing the second window leads to a corruption in the connection 
state.

Naturally, I am now nervous about using the first type of connection anywhere 
in my code, since I don’t understand what the issue is.  Can anyone shed light 
on this?

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.sticksoftware.QtSLiM0x0001003c84b1 
QtSLiMWindow::updateUIEnabling() + 17 (QtSLiMWindow.cpp:1589)
1   com.sticksoftware.QtSLiM0x0001003d224e 
QtPrivate::FunctorCall, QtPrivate::List<>, void, 
QtSLiMWindow::init()::$_3>::call(QtSLiMWindow::init()::$_3&, void**) + 14 
(qobjectdefs_impl.h:146)
2   org.qt-project.QtCore   0x00010228ca95 void 
doActivate(QObject*, int, void**) + 1157 (memory:2597)
3   org.qt-project.QtWidgets0x0001013d67de 
QApplicationPrivate::setFocusWidget(QWidget*, Qt::FocusReason) + 510
4   org.qt-project.QtWidgets0x00010140f6fd 
QWidget::setFocus(Qt::FocusReason) + 637 (qwidget.cpp:6356)
5   org.qt-project.QtWidgets0x0001013d7dd8 
QApplication::setActiveWindow(QWidget*) + 1160
6   org.qt-project.QtWidgets0x0001013d8333 
QApplicationPrivate::notifyActiveWindowChange(QWindow*) + 51 
(qapplication.cpp:2101)
7   org.qt-project.QtGui0x000101a35623 
QGuiApplicationPrivate::processActivatedEvent(QWindowSystemInterfacePrivate::ActivatedWindowEvent*)
 + 675 (qguiapplication.cpp:2438)
8   org.qt-project.QtGui0x000101a12cc3 bool 
QWindowSystemInterfacePrivate::handleWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
 + 115 (qwindowsysteminterface.cpp:106)
9   libqcocoa.dylib 0x0001063511ee 
QCocoaWindow::windowDidBecomeKey() + 238 (qcocoawindow.mm:1194)
10  org.qt-project.QtCore   0x0001022648d6 
QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument) const + 1270
11  libqcocoa.dylib 0x000106354830 invocation function 
for block in qRegisterNotificationCallbacks() + 1936 (qcocoawindow.mm:131)
12  com.apple.Foundation0x7fff3860cfab -[__NSObserver 
_doit:] + 296
13  com.apple.CoreFoundation0x7fff35f8c35f 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
14  com.apple.CoreFoundation0x7fff35f8c2f3 
___CFXRegistrationPost1_block_invoke + 63
15  com.apple.CoreFoundation0x7fff35f8c268 
_CFXRegistrationPost1 + 372
16  com.apple.CoreFoundation0x7fff35f8bebe 
___CFXNotificationPost_block_invoke + 97
17  com.apple.CoreFoundation0x7fff35f5b7e2 
-[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1575
18  com.apple.CoreFoundation0x7fff35f5ac82 _CFXNotificationPost 
+ 1351
19  com.apple.Foundation0x7fff385e0a22 
-[NSNotificationCenter postNotificationName:object:userInfo:] + 59
20  com.apple.AppKit

[Interest] Crash when signal fires

[Ben Haller via Interest]

Hi folks.  I’m seeing something weird that I don’t understand.  I have a 
connection defined for the main window of my Qt Widgets app, like so:

connect(qApp, ::focusChanged, [this]() { updateUIEnabling(); 
});

I’m seeing a 100% reproducible crash as a result of this.  When the 
focusChanged signal fires, I end up in updateUIEnabling() as expected, but I 
immediately crash because something about the state of things is corrupted; the 
immediate symptom, according to the debugger, is that the ui pointer for my 
main window is equal to 0x1 (yuck).  I try to access a button,  
ui->playOneStepButton, and it crashes.  As I said, 100% reproducible.

The weird thing is that this does *not* happen if I change the connect 
statement to this:

connect(qApp, ::focusChanged, this, 
::updateUIEnabling);

Now, 100% of the time, there is no problem, no crash, and my app chugs along 
happily.  No other code changes involved.  I can literally flip this connect 
definition back and forth in my code and go from 100% crashing to 100% fine.

I’m pretty new to Qt and maybe I’m just being clueless somehow; but I thought 
that the two definitions above would be essentially identical in their effect.  
Why does the first one crash?  Note that it works fine in general; it seems to 
crash specifically when I open a *second* main window (which makes its own 
connection to focusChanged in the same way), and then close that second main 
window.  Now the first main window’s connection is somehow unhappy, and the 
next time I trigger the focusChanged() signal, boom.  It’s as if the connection 
for the second window somehow interferes with the connection for the first 
window, and closing the second window leads to a corruption in the connection 
state.

Naturally, I am now nervous about using the first type of connection anywhere 
in my code, since I don’t understand what the issue is.  Can anyone shed light 
on this?

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Mac Qt Creator 4.11.2 consistently periodically hangs

[Ben Haller via Interest]

Well, it’s the first time I’ve looked at a sample from a Qt app, so I don’t 
really know what’s typical, but I do see that the app is running with several 
threads and more than one is sitting in a function named qt_safe_poll().  I 
wonder if there could be some kind of thread deadlock issue, or resource 
contention, or something like that, and it times out eventually and recovers, 
only to have the same thing happen again a little later.  I’m not sure why that 
would lock up the whole machine, but if calls to the kernel were involved in 
the deadlock/contention, maybe that would lock up the kernel as well until the 
problem resolves?  I don’t know.  But I’d definitely give the sample to the Qt 
folks, if you’ve logged a bug.  Good luck.

Cheers,
-B.


> On Apr 6, 2020, at 3:44 PM, David M. Cotter  wrote:
> 
> i've created a sample, but i've no idea how to read it
> there were two instances of the hang during the 30 second sample, but i don't 
> know if the sample shows that?
> 
> 
> 
>> On Apr 6, 2020, at 10:29 AM, Ben Haller  wrote:
>> 
>> Normally one can sample a process to see what it’s doing
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Mac Qt Creator 4.11.2 consistently periodically hangs

[Ben Haller via Interest]

I’m running Qt Creator 4.11.2 on macOS 10.15.4 without any problems with hangs. 
 Normally one can sample a process to see what it’s doing, like:

sample “Qt Creator” 10

in Terminal, but if your whole machine is hung maybe that won’t work.  Still, 
it might be worth a try starting a sample before it hangs and getting a 
cross-hang sample of the process.

Cheers,
-B.

Benjamin C. Haller
Messer Lab
Cornell University


> On Apr 6, 2020, at 1:10 PM, Kevin Ushey  wrote:
> 
> In the Security & Privacy preference pane, does Qt Creator have (or is it 
> blocked from) one of the requisite permissions? Users have reported similar 
> issues with Xcode; e.g. here: 
> https://apple.stackexchange.com/questions/332342/tccd-stuck-and-taking-up-lots-of-cpu
>  
> 
> 
> On Sat, Apr 4, 2020 at 9:46 AM David M. Cotter  > wrote:
> please see this description:
> https://forum.qt.io/topic/113278/mac-qt-creator-4-11-2-consistently-periodically-hangs
>  
> 
> 
> i'm stymied.  it must be something in my system?
> i tried this on another computer and no problem.
> 
> -dave
> ___
> Interest mailing list
> Interest@qt-project.org 
> https://lists.qt-project.org/listinfo/interest 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest