Re: [Interest] valgrind --tool=helgrind and Qt 5.3.2 on Linux: "lock order violated"

2014-12-11 Thread Thiago Macieira
On Thursday 11 December 2014 15:29:58 Rainer Wiesenfarth wrote: > (qorderedmutexlocker_p.h:83) > ==26941==by 0x6E0F677: QObject::connect(QObject const*, char const*, > QObject const*, > char const*, Qt::ConnectionType) (qobject.cpp:2713) > ==26941==[...] >

[Interest] valgrind --tool=helgrind and Qt 5.3.2 on Linux: "lock order violated"

2014-12-11 Thread Rainer Wiesenfarth
I am not yet very familiar with helgrind, but if I use it on my application I get a couple of messages like this: ==26941== ==26941== ==26941== Thread #1: lock order "0x723FA50 before 0x723FA90" violated ==26941== ==26941== Observe

Re: [Interest] valgrind

2013-07-09 Thread Thiago Macieira
On terça-feira, 9 de julho de 2013 15.13.55, Jonathan Greig wrote: > Off of the top of my head, Qt typically doesn't allocate memory that the > programmer is then explicitly required to free as long as the object is > assigned a parent. If it does allocate memory that the programmer needs to > free

Re: [Interest] valgrind

2013-07-09 Thread Jonathan Greig
Thiago, Show reachable is typically considered not a problem in most cases but it's still good to know it's there. In the case of the unicode stuff it is reporting, I do not want to see it and would be a possible candidate for suppression. An example of what I am interested in seeing is this: I had

Re: [Interest] valgrind

2013-07-08 Thread Thiago Macieira
On segunda-feira, 8 de julho de 2013 10.55.02, Jonathan Greig wrote: > ==25878== LEAK SUMMARY: > > ==25878== definitely lost: 40 bytes in 1 blocks > > ==25878== indirectly lost: 40 bytes in 1 blocks > > ==25878== possibly lost: 0 bytes in 0 blocks > > ==25878== still reachable: 3,424 bytes in 5 blo

Re: [Interest] valgrind

2013-07-08 Thread Thiago Macieira
On segunda-feira, 8 de julho de 2013 10.55.02, Jonathan Greig wrote: > Can you please explain your reasoning or how it might go wrong as "barely > more" sounds exactly what I want and what Alex is asking for. My reasoning > is that it catches all of MY memory leaks, but supresses the gazillions of

Re: [Interest] valgrind

2013-07-07 Thread Thiago Macieira
On domingo, 7 de julho de 2013 22.36.35, Alex Strickland wrote: > On 2013/07/07 09:53 PM, Thiago Macieira wrote: > >> Are there any "official" valgrind suppression files kept anywhere? > > > > No. No suppression is known to be necessary for memcheck. > > Oh, will you tell my computer? Seriously,

Re: [Interest] valgrind

2013-07-07 Thread Jonathan Greig
Alex, Supposedly QtCreator uses one internally or something but I haven't been able to locate it. I asked about this awhile back and thats the general consensus. I'm pretty sure that what you are looking for is what I have here: http://sourceforge.net/p/embroidermodder/code/178/tree/valgrind-supp/

Re: [Interest] valgrind

2013-07-07 Thread Thiago Macieira
On domingo, 7 de julho de 2013 21.48.33, Alex Strickland wrote: > Hi > > Are there any "official" valgrind suppression files kept anywhere? No. No suppression is known to be necessary for memcheck. I have some unfinished work for helgrind, but work by David Faure in upstream Valgrind have made