<div dir="ltr">Hey Arten,<div><br></div><div>I understand that a fix might take a while, but would it be possible for you to help me suppress the warning?</div><div><br></div><div>Tiago</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 6, 2016 at 11:41 PM, Artem Dergachev <span dir="ltr"><<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for reporting this!! Reproduced.<div><div class="h5"><br>
<br>
On 12/7/16 3:54 AM, Tiago Macarios wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Ok got it. File attached.<br>
<br>
Command line used to generate it:<br>
<br>
/usr/bin/clang++ \<br>
-E \<br>
-isystem /opt/Qt5.7.0/5.7/gcc_64/includ<wbr>e \<br>
-isystem /opt/Qt5.7.0/5.7/gcc_64/includ<wbr>e/QtCore \<br>
-fPIC \<br>
-std=c++14 \<br>
-c main.cpp \<br>
-o preprocessed.cpp<br>
<br>
To compile:<br>
<br>
/usr/bin/clang++ \<br>
--analyze \<br>
-DQT_CORE_LIB \<br>
-DQT_NO_DEBUG \<br>
-fPIC \<br>
-std=c++14 \<br>
-c preprocessed.cpp<br>
<br>
Shows the same warning:<br>
<br>
In file included from main.cpp:2:<br>
In file included from /opt/Qt5.7.0/5.7/gcc_64/includ<wbr>e/QtCore/QObject:1:<br>
/opt/Qt5.7.0/5.7/gcc_64/includ<wbr>e/QtCore/qobject.h:343:16: warning: Potential memory leak<br>
return connectImpl(sender, reinterpret_cast<void **>(&signal), context, nullptr,<br>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~<br>
<br>
<br></div></div><div><div class="h5">
On Tue, Dec 6, 2016 at 2:07 PM, Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a> <mailto:<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>>> wrote:<br>
<br>
Could you run `clang` with flag `-E` to obtain a preprocessed<br>
file, and then demonstrate the problem by running `clang<br>
--analyze` (probably with some flags) on that file? That'd be<br>
really great.<br>
<br>
There must be some pointer-escape that we're missing. Hmm, it's<br>
not the first time Qt turns out to be difficult for the analyzer<br>
to handle.<br>
<br>
I think i should be able to figure out how to suppress the warning<br>
from the preprocessed file even if the fix would take some time.<br>
<br>
<br>
On 12/7/16 12:42 AM, Tiago Macarios wrote:<br>
<br>
Hi Artem,<br>
<br>
Thanks for the email. Could you let me know exactly what you need?<br>
<br>
If I run clang with the --analyze flag I get a simpler log<br>
than the one clang-tidy generates (same problem though):<br>
<br>
...<br>
[ 75%] Building CXX object CMakeFiles/main.dir/main_autom<wbr>oc.cpp.o<br>
In file included from /mnt/e/_working/tidy/main.cpp:<wbr>2:<br>
In file included from<br>
/opt/Qt5.7.0/5.7/gcc_64/includ<wbr>e/QtCore/QObject:1:<br>
/opt/Qt5.7.0/5.7/gcc_64/includ<wbr>e/QtCore/qobject.h:343:16:<br>
warning: Potential memory leak<br>
return connectImpl(sender, reinterpret_cast<void<br>
**>(&signal), context, Q_NULLPTR,<br>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~~~~~~~~~~~~<br>
1 warning generated.<br>
[100%] Linking CXX executable main<br>
clang: warning: CMakeFiles/main.dir/main.cpp.o<wbr>: 'linker' input<br>
unused<br>
clang: warning: CMakeFiles/main.dir/main_autom<wbr>oc.cpp.o:<br>
'linker' input unused<br>
clang: warning:<br>
/opt/Qt5.7.0/5.7/gcc_64/lib/li<wbr>bQt5Core.so.5.7.0: 'linker'<br>
input unused<br>
clang: warning: -Wl,-rpath,/opt/Qt5.7.0/5.7/gc<wbr>c_64/lib:<br>
'linker' input unused<br>
clang: warning: argument unused during compilation: '-rdynamic'<br>
make[3]: Leaving directory '/mnt/e/_working/tidy/build/li<wbr>nux'<br>
...<br>
<br>
<br>
<br>
I modified the original cmake file to this:<br>
<br>
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --analyze")<br>
<br>
set_target_properties(main<br>
PROPERTIES<br>
CXX_STANDARD 14<br>
CXX_EXTENSIONS OFF<br>
AUTOMOC ON<br>
AUTOUIC ON<br>
# CXX_CLANG_TIDY<br>
# "clang-tidy"<br>
# "-checks=modernize-*,readabili<wbr>ty-*,performance-*"<br>
# "-fix"<br>
)<br>
<br>
On Tue, Dec 6, 2016 at 11:59 AM, Artem Dergachev<br>
<<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a> <mailto:<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>><br></div></div><div><div class="h5">
<mailto:<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a> <mailto:<a href="mailto:noqnoqneo@gmail.com" target="_blank">noqnoqneo@gmail.com</a>>>> wrote:<br>
<br>
Whoops sorry missed this message!<br>
<br>
This is (or looks like) a false positive for the clang static<br>
analyzer's MallocChecker (clang-tidy runs the analyzer<br>
internally,<br>
but is not responsible for this checker directly).<br>
<br>
I think we should investigate that, and a preprocessed<br>
file with<br>
an -analyze/--analyze command line would speed us up<br>
significantly :)<br>
<br>
On 12/5/16 9:26 PM, Tiago Macarios via cfe-dev wrote:<br>
<br>
Hi,<br>
<br>
If this is the wrong mail-list could someone point me<br>
to the<br>
correct one please?<br>
<br>
Mac<br>
<br>
On Thu, Dec 1, 2016 at 5:52 PM, Tiago Macarios<br>
<<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.com</a><br>
<mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a>><br>
<mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a> <mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a>>><br>
<mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a><br>
<mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a>><br>
<br>
<mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a><br>
<mailto:<a href="mailto:tiagomacarios@gmail.com" target="_blank">tiagomacarios@gmail.co<wbr>m</a>>>>> wrote:<br>
<br>
Hi,<br>
<br>
First time poster so I hope I get the etiquette right.<br>
<br>
I am trying to use clang-tidy (3.9.1) with a Qt (5.7)<br>
project and<br>
I am getting a false positive memory leak.<br>
<br>
Here is the CMake file:<br>
<br>
cmake_minimum_required(VERSION 3.2)<br>
project(main)<br>
add_executable(main main.cpp)<br>
set_target_properties(main<br>
PROPERTIES<br>
CXX_STANDARD 14<br>
CXX_EXTENSIONS OFF<br>
AUTOMOC ON<br>
AUTOUIC ON<br>
CXX_CLANG_TIDY<br>
"clang-tidy"<br>
"-checks=modernize-*,readabili<wbr>ty-*,performance-*"<br>
"-fix"<br>
)<br>
find_package(Qt5Core)<br>
target_link_libraries(main Qt5::Core)<br>
<br>
<br>
<br>
Here is the main.cpp (it is the minimum amount of<br>
code to<br>
reproduce the issue, the code itself is brain-dead):<br>
<br>
#include <QObject><br>
<br>
int main(int argc, char *argv[])<br>
{<br>
QObject a;<br>
QObject::connect(&a, &QObject::destroyed, []() {});<br>
return 0;<br>
}<br>
<br>
<br>
<br>
clang-tidy will display the following warning:<br>
<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:343:16:<br>
warning:<br>
Potential memory leak<br>
[clang-analyzer-cplusplus.NewD<wbr>eleteLeaks]<br>
return connectImpl(sender,<br>
reinterpret_cast<void<br>
**>(&signal), context, Q_NULLPTR,<br>
^<br>
/mnt/e/_Working/tidy/main.cpp:<wbr>8:5: note: Calling<br>
'QObject::connect'<br>
QObject::connect(&a, &QObject::destroyed, []() {});<br>
^<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:293:16: note:<br>
Calling 'QObject::connect'<br>
return connect(sender, signal, sender, slot,<br>
Qt::DirectConnection);<br>
^<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:308:39:<br>
note: '?'<br>
condition is true<br>
const int SlotArgumentCount =<br>
(FunctorArgumentCount >= 0)<br>
? FunctorArgumentCount : 0;<br>
^<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:340:13: note:<br>
Left side of '||' is false<br>
if (type == Qt::QueuedConnection || type ==<br>
Qt::BlockingQueuedConnection)<br>
^<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:340:9: note:<br>
Taking false branch<br>
if (type == Qt::QueuedConnection || type ==<br>
Qt::BlockingQueuedConnection)<br>
^<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:344:28: note:<br>
Memory is allocated<br>
new QtPrivate::QFunctorSlotObject<<wbr>Func2,<br>
SlotArgumentCount,<br>
^<br>
/opt/Qt5.7.0/5.7/gcc_64/inclu<wbr>de/QtCore/qobject.h:343:16: note:<br>
Potential memory leak<br>
return connectImpl(sender,<br>
reinterpret_cast<void<br>
**>(&signal), context, Q_NULLPTR,<br>
^<br>
<br>
<br>
<br>
Here is the code it refers to QtCore/qobject.h:343:<br>
<br>
return connectImpl(sender, reinterpret_cast<void<br>
**>(&signal),<br>
context, Q_NULLPTR,<br>
new<br>
QtPrivate::QFunctorSlotObject<<wbr>Func2,<br>
SlotArgumentCount,<br>
typename QtPrivate::List_Left<typename<br>
SignalType::Arguments,<br>
SlotArgumentCount>::Value,<br>
typename SignalType::ReturnType>(slot),<br>
type, types,<br>
&SignalType::Object::staticMet<wbr>aObject);<br>
<br>
<br>
<br>
The object created by that new, does get properly<br>
destroyed. This<br>
seems to happen at tCore\qobject_impl.h:168:<br>
<br>
static void impl(int which,<br>
QSlotObjectBase *this_,<br>
QObject *r, void **a, bool *ret)<br>
{<br>
switch (which) {<br>
case Destroy:<br>
delete<br>
static_cast<QFunctorSlotObject<wbr>*>(this_); //HERE<br>
break;<br>
case Call:<br>
FuncType::template call<Args,<br>
R>(static_cast<QFunctorSlotOb<wbr>ject*>(this_)->function, r, a);<br>
break;<br>
case Compare: // not implemented<br>
case NumOperations:<br>
Q_UNUSED(ret);<br>
}<br>
}<br>
<br>
<br>
<br>
From a naive perspective it seems like that false<br>
positive<br>
leak<br>
would be pretty hard to catch. So I guess the best<br>
solution (at<br>
the moment) would be for me to silence the error.<br>
(Please<br>
someone<br>
correct me if I am wrong).<br>
<br>
Googling around I found two different ways to<br>
silence this<br>
false<br>
positives:<br>
// NOLINT<br>
#ifndef __clang_analyzer__<br>
<br>
I tried to use both in multiple ways, see this SO<br>
post:<br>
<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/quest<wbr>ions/40642307/silencing-clang-<wbr>tidy</a><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/ques<wbr>tions/40642307/silencing-clang<wbr>-tidy</a>><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/que<wbr>stions/40642307/silencing-clan<wbr>g-tidy</a><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/ques<wbr>tions/40642307/silencing-clang<wbr>-tidy</a>>><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/ques<wbr>tions/40642307/silencing-clang<wbr>-tidy</a><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/ques<wbr>tions/40642307/silencing-clang<wbr>-tidy</a>><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/que<wbr>stions/40642307/silencing-clan<wbr>g-tidy</a><br>
<<a href="http://stackoverflow.com/questions/40642307/silencing-clang-tidy" rel="noreferrer" target="_blank">http://stackoverflow.com/ques<wbr>tions/40642307/silencing-clang<wbr>-tidy</a>>>><br>
But I still haven't figured out a way to silence this<br>
error. Maybe<br>
someone can help me figure this one out?<br>
<br>
FYI: QObject::connect is used all over Qt code. So<br>
I would<br>
rather<br>
patch the Qt source files, then have to annotate<br>
every call to<br>
that function.<br>
<br>
Mac.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><wbr>><br></div></div>
<mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> <mailto:<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><wbr>>><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a>><br>
<<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bi<wbr>n/mailman/listinfo/cfe-dev</a><br>
<<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin<wbr>/mailman/listinfo/cfe-dev</a>>><br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>