Re: [Interest] Debugging a double dealloc
> 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
Hi Ben, 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? Where is the tick font used? Does your main menu that you want to persist without any windows use it? 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? Regards, Tony ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Debugging a double dealloc
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,
>> -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),
Re: [Interest] Debugging a double dealloc
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.
>>
>> 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
Re: [Interest] Debugging a double dealloc
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()
>
>
>
> qopenglvertexarrayobject.cpp 212 0x101b21481
> 6
Re: [Interest] Debugging a double dealloc
AddressSanitizer. (Except on macOS it will not find memory leaks) You should be able to find the double free quite quickly. You do NOT Have to rebuild Qt with the address sanitizer flags, just your own codes. We just got done using ASAN on our own code base and it was able to pinpoint the same kind of issue. The issue was in our code but it didn't die until deep inside of Qt code which was never helpful. I'm 100% behind ASAN as an excellent code quality tool. We now have a nightly CI build with ASAN running to help find new codes that might have the same issues as before. -- Mike Jackson On 9/23/20, 8:56 AM, "Interest on behalf of Ben Haller via Interest" wrote: 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 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Debugging a double dealloc
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
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 smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Debugging a double dealloc
(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
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
Re: [Interest] Debugging a double dealloc
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 > 17 void > std::allocator_traits , void > *>>>::destroy(std::allocator ontEngine::GlyphCacheEntry, void *>>&, QFontEngine::GlyphCacheEntry *) > memory 1595 0x101883c74 > 18 std::__list_imp std::allocator>::clear() > list 733 0x101883c74 > 19 std::__list_imp std::allocator>::~__list_imp() > list 712 0x101883c24 > 20 std::list::~list() > list 805 0x101883c24 > 21 std::list::~list() > list 805 0x101883c24 > 22 QHashNode std::list>::~QHashNode() > qhash.h147 0x101883c24 > 23 QHashNode std::list>::~QHashNode() > qhash.h147 0x101883c24 > 24 QHash std::list>::deleteNode2(QHashData::Node *) > qhash.h563 0x101883c24 > 25 QHash
[Interest] Debugging a double dealloc
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()
