Details
-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.2.4
-
None
Description
The following code serves as a minimal working example
int main(int argc, char** argv) { QCoreApplication a(argc, argv); QUrl url {}; url.setScheme("coap"); url.setHost("127.0.0.1"); url.setPort(1234); url.setPath(QString::fromStdString("/foo/bar")); QCoapRequest request { url, QCoapMessage::Type::NonConfirmable }; a.quit(); }
valgrind will report the following memory leak from QUrl
$ valgrind --leak-check=full ./a.out ==20680== Memcheck, a memory error detector ==20680== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==20680== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==20680== Command: impl/cli/sdn_controller ==20680== ==20680== ==20680== HEAP SUMMARY: ==20680== in use at exit: 19,718 bytes in 27 blocks ==20680== total heap usage: 106 allocs, 79 frees, 135,630 bytes allocated ==20680== ==20680== 306 (192 direct, 114 indirect) bytes in 1 blocks are definitely lost in loss record 25 of 27 ==20680== at 0x4849013: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==20680== by 0x49F2689: QUrl::detach() (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.2.4) ==20680== by 0x49F3032: QUrl::setScheme(QString const&) (in /usr/lib/x86_64-linux-gnu/libQt6Core.so.6.2.4) ==20680== by 0x10A66E: main (in /home/*******) ==20680== ==20680== LEAK SUMMARY: ==20680== definitely lost: 192 bytes in 1 blocks ==20680== indirectly lost: 114 bytes in 3 blocks ==20680== possibly lost: 0 bytes in 0 blocks ==20680== still reachable: 19,412 bytes in 23 blocks ==20680== suppressed: 0 bytes in 0 blocks ==20680== Reachable blocks (those to which a pointer was found) are not shown. ==20680== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==20680== ==20680== For lists of detected and suppressed errors, rerun with: -s ==20680== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
- This does look like a QUrl issue first, but if the QCoapRequest is omitted, no leak is shown.
The leak does not occur when the QCoapRequest with the const char* overload is used.- It seems the issue is also present with the chost char* constructor, as internally a QUrl is used. This might be a hint, that the leak is in the QCoapRequest part.
- compiled with qt 6.2.4, g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, and tested with valgrind-3.18.1