Leaks from Qt dynamic link libraries

[Howard727]

I have a Qt C++ application, which is crashing with a corrupted heap. I have installed heob and have been impressed with the output. However, the oddity is that I seem to be getting a very large number of memory leaks from Qt’s dynamic link libraries. I have set-up a program, which simply exits when I run it. This leaks 2000 bytes, from libwinpthread-1.dll, libgcc_s_seh-1.dll, Qt6Core.dll. When I run my full system, I obtain many millions of bytes of leaks.

I have tried two different versions of Qt: 5.15.14 and 6.5.1, with MinGW 64-bit and I get the same basic results with both. I am constrained in the versions of Qt that I can use, due to the code I have inherited.

So, my questions are as follows: 1) Are the leaks I see in my instantaneous exit program real memory leaks or just normal memory allocations;? 2) Could the corrupted heap be caused by these dynamic link libraries? 3) Is there something that I am do wrong, perhaps a flag I should be setting to only pick up leaks?

I can give more information about how I have heob set-up, if that would help.

Many thanks,

H

[ssbssa]

Are the leaks I see in my instantaneous exit program real memory leaks or just normal memory allocations;?

They are probably just some Qt initialization allocations that it needs, so not 'real' memory leaks.

Could the corrupted heap be caused by these dynamic link libraries?

Usually I would say no, but I can't be completely sure since I don't know what your program does.

Is there something that I am do wrong, perhaps a flag I should be setting to only pick up leaks?

So you want to just look for memory leaks, or do you want to find the reason of the corrupted heap?

[Howard727]

Thanks for your response - very useful.

It is the corrupted heap that I need to understand.

[ssbssa]

For heap corruption I suggest you use the following heob parameters:

Handle exceptions: On
Page protection: After
Freed memory protection: On

It should show you the reason of the heap corruption.

Edit: I forgot to mention, you might want to use the latest development build, it's available here: heob.7z

[Howard727]

Thanks for your continued very useful advice.

I installed your new version of heob and applied your settings to it and that did indeed give me a much more focussed output. However, it remains tricky to interpret. The trace I get refers to the executable of my project and calls to methods in Qt dynamic link libraries, Qt5Core.dll, qwindows.dll, Qt5Widgets.dll, etc, but it does not refer to anything in my source code. So, it remains unclear to me where the error is in my code.

Thanks again,

Howard

[ssbssa]

Maybe you could attach the resulting xml file here?

[Howard727]

I do not seem to be able to attach either .xml or .html files to this comment. Although, I could, of course, send these to you in other ways - do specify , if that is a good option.

The best I seem to be able to do is to copy the Memcheck output from the Qt creator window into a word document, which is attached here:

Output of heob for RsvpTwo.docx

Thanks again, Howard

[ssbssa]

You should be able to attach the xml file if it's compressed to ZIP.

From the docx file it looks to me like you don't have debug info available in your release build, otherwise it would also show the source file location in the RsvpTwo.exe frames. Can you rebuild with debug info and try again?

[Howard727]

Thanks again for your input. I have attached the zipped .xml and .html files. I have also tried to add debug info to my release build, by adding, CONFIG += force_debug_info to my .pro file and re-compiling. However, this does not seem to have changed anything when I run heob. The attached files have resulted from running heob with force_debug_info added to the configuration – the .exe entries in the trace still do not indicate source code calls. I’m suspicious that the change to the configuration will not affect anything unless I force the compiler to do a full rebuild (e.g. clean & build). Is there some way that I can know debugging info is being generated and stored, perhaps a particular file is generated? Sorry to bombard you with questions, Howard leaks_xml.zip leaks_html.zip

[ssbssa]

In the XML I see that you use MinGW for building. In that case you should have got a warning like this:

Heob used with MinGW projects needs the Dwarfstack DLLs for proper stacktrace resolution.

Did you put the dwarstack dlls to the same location as the heob exes?

[ssbssa]

Forget my previous entry, of course you have the dwarfstack dlls, otherwise it wouldn't show any source locations for the Qt dlls either.

I have also tried to add debug info to my release build, by adding, CONFIG += force_debug_info to my .pro file and re-compiling. However, this does not seem to have changed anything when I run heob. The attached files have resulted from running heob with force_debug_info added to the configuration – the .exe entries in the trace still do not indicate source code calls. I’m suspicious that the change to the configuration will not affect anything unless I force the compiler to do a full rebuild (e.g. clean & build).

This should have worked, unless qmake wasn't called again.

Is there some way that I can know debugging info is being generated and stored, perhaps a particular file is generated?

You could check with gdb itself, it prints this message if an executable doesn't have debug info: (No debugging symbols found in Some.exe)

Edit: Or even simpler, just try debugging the release build with QtCreator itself.

[Howard727]

Thanks again and sorry for the delay in getting back to you – it is a very busy time. As you have suggested, I have now got the debugger working on the release build. To be sure, I enclose an image of the debugger working, and the project is still in release mode. However, when I run heob, I still get the same output, where the entries associated with the executable are missing.

All the best, H

[ssbssa]

That's weird, I never had this kind of problem. What compiler version do you use?

[ssbssa]

I can only think of one reason why heob might fail, and it would be because you use a relatively new gcc, which defaults to dwarf5 debug info. The last dwarfstack release doesn't understand dwarf5 yet, only current git version does, so please try this build: dwarfstack-dlls.zip

If this also doesn't work, I would need some kind of reproducer.

[ssbssa]

Since there is no further feedback, I'm guessing you gave up (though I would have liked to know if the updated dwarfstack dlls work). If you do have further questions, feel free to reopen this ticket.

[Howard727]

Hi Hannes,

Sorry for not replying earlier. Once I got the debugger going, I managed to find the problem. I'll see if I can try the updated dwarfstack dlls, but it won't be straightaway, as I have a number of deadlines.

Nonetheless, thanks for your assistance - I was able to find the data type associated with the error from heob, even if I could not see a full trace. The data type helped me close in on the problem.

Thanks again, H

---

Howard Bowman (PhD) Professor of Cognitive Neuroscience in Psychology and Computer Science at the University of Birmingham (visiting at Wellcome Centre for Human Neuroimaging, University College London)

Professor of Cognition and Logic, School of Computing, University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, UK email: @.**@.> WWW: http://www.cs.kent.ac.uk/people/staff/hb5/

School of Psychology, University of Birmingham, Edgbaston, Birmingham B15 2TT, UK

From: Hannes Domani @.> Sent: Friday, December 1, 2023 7:30 PM To: ssbssa/heob @.> Cc: Howard Bowman @.>; Author @.> Subject: Re: [ssbssa/heob] Leaks from Qt dynamic link libraries (Issue #29)

CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

Closed #29https://github.com/ssbssa/heob/issues/29 as completed.

- Reply to this email directly, view it on GitHubhttps://github.com/ssbssa/heob/issues/29#event-11125756227, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APLEKBCNWPLZ2PFNTLD2VDDYHIV33AVCNFSM6AAAAAA7GKFOUGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRGEZDKNZVGYZDENY. You are receiving this because you authored the thread.Message ID: @.***>