Overriding the global new and delete operators I'm afraid I've seen
lots of situations like this --although in Tiger (haven't received
Leopard yet).
The mismatch between new[] and delete seems indeed to occur quite
often in the system libraries, but obviously I wouldn't know where...
Sorry,
Dario
On 31 Oct 2007, at 15:40, Sam Deane wrote:
When I call aglDestroyContext as part of my shut down, our memory
debugging is getting triggered in a number of places where it spots
that an allocation has been made with new[] but is getting disposed
with delete (as opposed to delete[]).
Has anyone else see similar behaviour? A typical call stack is...
#4 ... my memory debug code here...
#5 0x0012687b in operator delete at memory_manager.cpp:710
#6 0x969a80c9 in BindingTable::~BindingTable
#7 0x969ae1cf in TGenericLinker::~TGenericLinker
#8 0x9696b7ec in ShDestruct
#9 0x17ec9647 in gleFreeProgramObject
#10 0x17dc3861 in gleReleaseSharedState
#11 0x17dc2383 in gliDestroyContext
#12 0x91041463 in cglDestroyContext
#13 0x910410f1 in CGLDestroyContext
#14 0x917a571b in aglDestroyContext
#15 ... my cleanup code here...
The annoying thing is that this code is presumably in a library, so
I can't do anything about it - but I don't really want to turn off
my memory checks.
The code is compiled under XCode 3.0, with the MacOSX10.4u.sdk base
SDK path, but the deployment target set to Mac OS X 10.3.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/mac-opengl/adario%
40softhome.net
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
