Qmake: malloc bug? (pointer being freed was not allocated)



  • This is on a Mac OS X (10.6.7) machine, Xcode 3.2.6.

    Has anyone else noticed this while building from latest git source on Mac (or elsewhere)?

    Here is a good example of it from the std output in Terminal. It happens tons of times during compile.

    cd src/opengl/ && gmake -f Makefile
    gmake[1]: Entering directory /Volumes/Disk_4/source/qt/qt-master/qt-build-cocoa/src/opengl' /Volumes/Disk_4/source/qt/qt-master/qt-build-cocoa/bin/qmake -spec /Volumes/Disk_4/source/qt/qt-master/qt/mkspecs/macx-g++ -o Makefile /Volumes/Disk_4/source/qt/qt-master/qt/src/opengl/opengl.pro qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa460: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa6e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa460: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffc280: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffc280: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa2c0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa540: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa2c0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffc0e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffc0e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa2c0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa540: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffa2c0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffc0e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug qmake(48686,0xa0248540) malloc: *** error for object 0xbfffc0e0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug gmake[1]: Leaving directory/Volumes/Disk_4/source/qt/qt-master/qt-build-cocoa/src/opengl'
    gmake[1]: Entering directory `/Volumes/Disk_4/source/qt/qt-master/qt-build-cocoa/src/opengl'
    gmake -f Makefile.Debug all
    gmake -f Makefile.Release all
    ** END SNIPPET**

    This memory bug is in qmake tool, I have looked and looked to see if I could find the culprit, but I don't see anything that is obvious (maybe Im blind) This is gcc, and in clang both. I will try LLVM-GCC next and see if it is there. Clang does not seem to shed any light on the problem.

    If anyone else has seen this behaviour, Let me know, And I will file a Qt-bug.

    If its NOT Happening on anyone else's dev machine, it must be something "weird" on mine that I need to look into and fix. or an Apple OS bug (which I will report) This has been occurring since Jan or so this year. It was NOT happening before this time. I do a git pull of Qt every morning, and a FRESH shadow rebuild.... and low and behold it is still there.



  • Never mind right now, I got to the bottom of this strange behaviour.

    It is NOT a bug in OS X.

    But it boils down to a hardcoded variable in the qmake Makefile...

    It appears that there was a small change in the implementation of the stdlib 'realpath' in OS X 10.5, this change is in 10.5 and later, but in the qmake Makefile, the MACOSX_DEPLOYMENT_VERSION=xx.xxx is hardcoded to =10.4.

    You should be able to change this, especially when doing 64-bit/cocoa work. but not so easy if it is hardcoded into a Makefile. It turned out there WAS a bug already filed, but for some reason I did not find it, so I created a new bug report, which turned out to be a duplicate.

    Its just a small silly thing that can be easily fixed in Qt build system. I think if you want to deploy anything above 10.4, you should be given an option on the configure line with which to do so. for both 32 and 64 bit. (Same OS version)....

    No wonder I had a hard time tracking the problem down !

    I have a FEW ideas to get around this mistake.....

    What do you people think?



  • Could you please supply a link to the relevant bugreport? That may help people in the future.



  • uhh! I knew I missed something!

    Apologies. here is the link, Andre:

    http://bugreports.qt.nokia.com/browse/QTBUG-18947

    Silly me!



  • http://bugreports.qt.nokia.com/browse/QTBUG-18985

    Which I filed yesterday,
    May also be of interest too. It relates to whats causing the issue and 3 or so things that may be done to fix this.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.