On jeudi 22 décembre 2016 21:06:04 CET Philippe Waroquiers wrote:
> To be sure: if you just replace in the above setup valgrind 3.13 SVN
> by valgrind 3.12 release, then you do not have the problem anymore ?
Good point. I just tried with /usr/bin/valgrind, which is 3.11, and the same
thing
On jeudi 22 décembre 2016 06:46:44 CET David Chapman wrote:
> If this is new valgrind behavior, I wouldn't discount a bug in its code
It certainly looks like one :)
> but the developers (not me) would need to know what the QVBoxLayout
> constructor is doing. If it's inlined, the call stack
On Thu, 2016-12-22 at 12:22 +0100, David Faure wrote:
> Any idea why this is happening?
>
> gcc (SUSE Linux) 4.8.5
> valgrind-3.13.0.SVN
> glibc-2.22-3.7.x86_64
> `uname -a` = Linux 4.4.36-8-default #1 SMP Fri Dec 9 16:18:38 UTC 2016
> (3ec5648) x86_64 x86_64 x86_64 GNU/Linux
> OpenSuSE Leap
- Original Message -
> On jeudi 22 décembre 2016 06:46:44 CET David Chapman wrote:
> > If this is new valgrind behavior, I wouldn't discount a bug in its
> > code
>
> It certainly looks like one :)
>
> > but the developers (not me) would need to know what the QVBoxLayout
> >
There seems to be a regression in valgrind SVN, where it thinks new[] was used,
while in fact a simple new was used.
I see this all over the place when running valgrind on Qt code.
==4799== Mismatched free() / delete / delete []
==4799==at 0x4C2A65D: operator delete(void*)
I found it.
Using "step" in gdb showed that the new calls that valgrind complains about
go into qtwebengine/src/3rdparty/chromium/base/allocator/allocator_shim.cc
146├>void* ShimCppNew(size_t size) {
147│ const allocator::AllocatorDispatch* const chain_head = GetChainHead();
148│ void*
On 12/22/2016 3:22 AM, David Faure wrote:
> There seems to be a regression in valgrind SVN, where it thinks new[] was
> used, while in fact a simple new was used.
> I see this all over the place when running valgrind on Qt code.
>
> ==4799== Mismatched free() / delete / delete []
> ==4799==at
