[Qt-interest] help tracking down memory corruption on Mac Qt 4.7.3 Cocoa (64 bit)

[Konrad Rosenbaum]

On Tue, May 24, 2011 15:44, Paul Miller wrote:
> Thanks Dair for suggesting valgrind - it helped me narrow down the
> problem.
>
> Valgrind reported several invalid writes to bools I had in a widget
> subclass. It reported them as writes after an allocation of a certain
> size. I guess the compiler was not aligning them properly or not
> computing the size of the memory allocation for the class properly. I
> moved the bool variables to the top of the list of member variables and
> the problem went away. valgrind no longer reports invalid writes.
>
> This problem didn't exist on Windows, nor in 32 bit mode on Mac, so I
> suspect a bug in the 64 bit compiler. Unfortunately this happened with
> gcc 4.2 and llvm 1.7. Spent literally 2 days tracking this one down. :-(

Since it is quite unlikely that the same problem occurs in two different
compilers on one platform but not in the same compile on a different
platform, I suspect something else:

do a "make clean" and then a full "make" - I'd bet the problem goes away.
If I'm right you still have this problem, you just shifted it slightly to
other properties or to the next time you change a class.

Here is what I suspect happened:
Some modules that instantiate your class were compiled against an old
version of the header file in which the booleans were not there yet. The
module of the class itself was recompiled with the new version. So those
other modules instantiate this class by allocating a few bytes less than
necessary and then calling the constructor. Some routines in the class
itself of course expect those bytes to be there and write outside the
allocated memory and crash.

One of the problems of C++ is that memory allocation happens in a
different place than initialization and handling. Namely: memory gets
allocated where the variable is defined or new is called. Handling happens
where the methods are defined. The handling side has to rely on the
allocating side to allocate enough memory.

Reason it happens frequently:
In order for make to recompile all modules that instantiate a class, it
needs to know about all the include files that it uses. Qmake is pretty
intelligent about this and creates dependencies for everything that is in
the same directory, but everything outside is assumed to be stable.

Permanent fix:
See DEPENDPATH in the qmake documentation. Add all paths that you draw
include files from which may change at some point.



    Konrad