Bug 282998 - devel/qtcreator: Valgrind integration not working
Summary: devel/qtcreator: Valgrind integration not working
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-kde (group)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-27 07:34 UTC by Paul Floyd
Modified: 2024-12-03 00:42 UTC (History)
2 users (show)

See Also:
linimon: maintainer-feedback? (kde)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Floyd 2024-11-27 07:34:38 UTC
Bit of background. I use Qt Creator for Valgrind development (and maintain the FreeBSD port). However I almost never use Valgrind in Creator.

I'm working on a Valgrind Bugzilla item that will change Valgrind's XML output and I want to check that it does not impact GUIs like CLion and Qt Creator.

However it seems as though nothing is working even without any changes to Valgrind.

I'm using this small example which has one Conditional jump and one leak.


#include <iostream>

using namespace std;

int main()
{
    int* pi = new int[10];
    if (pi[0])
        return 1;
    return 0;
}

In a terminal I get

==68245== Conditional jump or move depends on uninitialised value(s)
==68245==    at 0x400631: main (main.cpp:8)
==68245== 
==68245== 
==68245== HEAP SUMMARY:
==68245==     in use at exit: 3,120 bytes in 7 blocks
==68245==   total heap usage: 8 allocs, 1 frees, 76,848 bytes allocated
==68245== 
==68245== 40 bytes in 1 blocks are definitely lost in loss record 1 of 7
==68245==    at 0x484E5C4: operator new[](unsigned long) (vg_replace_malloc.c:743)
==68245==    by 0x400624: main (main.cpp:7)

In Qt Creator if I run Analyze->Valgrind Memory Analyzer then the bar of the Memcheck window shows "Memory Analyzer Tool finished. 2 issues were found.". That's as expected. However the main widget is empty - there are no lines in Memory Issues / Issue | Location.

In Application Output I see

08:23:07: valgrind --child-silent-after-fork=yes --xml-socket=127.0.0.1:16219 --log-socket=127.0.0.1:64635 --xml=yes --smc-check=stack --tool=memcheck --gen-suppressions=all --track-origins=yes --leak-check=summary --num-callers=25 /home/paulf/scratch/errs/build/clang-Debug/errs


If I run Analyze->Valgrind Memory Analyzer with GDB then it works OK if I switch the project to use GDB. It hangs if the default lldb is used - would it be possible to issue a warning if the user is trying to to this? Or is that something that should be done upstream?

I've tried with both the valgrind and valgrind-devel ports. I'm using FreeBSD 14.1 amd64. I'll try the same example on Linux to see if that works.
Comment 1 Paul Floyd 2024-11-27 08:04:26 UTC
It works OK on Linux (Fedora 41 with Qt Creator installed from qt.io

Product: Qt Creator 14.0.2
Based on: Qt 6.7.3 (GCC 10.3.1 20210422 (Red Hat 10.3.1-1), x86_64)
Built on: Sep 27 2024 00:13:58
From revision: 3004ebc0af
Comment 2 Paul Floyd 2024-11-29 06:33:48 UTC
I also tried loading an xml file generated from the same example and still with widget remains empty.

I've had a quick look at the creator source and will build it with debuginfo. Maybe there is an issue with the filter.
Comment 3 Paul Floyd 2024-11-29 21:30:37 UTC
After a bit of looking at the Creator source and debugging a bit I see that I can see error items for a project if the "External Errors" filter is checked.

That seems wrong to me since I've been using a small qmake project. As I understand it "external" should be for non-project executables.

I need to check what was checked by default on Linux.
Comment 4 Paul Floyd 2024-11-30 08:32:12 UTC
I tried again on FreeBSD, this time choosing a CMake project (first time round I made a qmake project since that's first in the list and the default).

With CMake all worked fine.

Does this mean creator no longer fully understands qmake projects? I haven't yet tried qmake on Linux. I'll give that a go next time I boot to Linux.
Comment 5 Florian Walpen 2024-12-03 00:42:48 UTC
(In reply to Paul Floyd from comment #4)

It's not CMake vs qmake, I can reproduce this in a CMake project where memory leaks are only shown as "external". It seems the detection of what is classified "internal" / "external" is unreliable somehow.