GDB screws up drawing behaviour under Guard Malloc
GDB screws up drawing behaviour under Guard Malloc
- Subject: GDB screws up drawing behaviour under Guard Malloc
- From: Rippit the Ogg Frog <email@hidden>
- Date: Sun, 16 Jul 2006 19:54:32 -0300
I'm not certain, but I may have found a bug in GDB, Guard Malloc or some
other OS X component. I'll file a bug report if you think I really have.
This is on a MacBook Pro running OS X 10.4.6 and XCode 2.3.
If I set the environment variables to use Guard Malloc, then launch my
app from the terminal, it works correctly in every way, no matter how I
set the different options to guard malloc (strict size, detect overruns
or underruns, whether or not I fill free space).
But if I use Guard Malloc under GDB, whether XCode's GDB or the command
line one, my window's contents are always drawn in the top-left corner
of the screen, out over the desktop and not in the window.
I just spent a couple days examining our source before I discovered this
difference, so I'm pretty confident our code is correct. Some of it's
new code, so I can't be completely certain it's not our bug, but if it
were, it should be stimulated when Guard Malloc is used from the
terminal, and it's not.
Also if there were a guard malloc problem, I should get a crash and not
erroneous behaviour. In general, initializing the free space can effect
behaviour without crashing, but I get the same behaviour whether or not
I initialize the free space. Also it's necessary to set
MALLOC_STRICT_SIZE to stimulate the bug, which shouldn't effect drawing
behavior, just maybe cause a crash.
If you'd like to try for yourself, it shows up in the two demo apps that
come with ZooLib, an Open Source cross-platform application framework.
Get the sources from CVS, as the code in question is not in our release
tarball. To do so, use the following commands:
cvs -d:pserver:email@hidden:/cvsroot/zoolib login
(the above should be all one one line - my mailer wrapped the text)
cvs -z3 -d:pserver:email@hidden:/cvsroot/zoolib
co -P zoolib
(again all one line).
Build the project in zoolib/samples/buttonmessage/buttonmessage_build_xcode
You need to set MALLOC_STRICT_SIZE in the executable's environment, then
enable Guard Malloc from XCode's debug menu.
with the command line GDB, you can enable Guard Malloc with the "set
env" command:
set env DYLD_INSERT_LIBRARIES /usr/lib/libgmalloc.dylib
set env MALLOC_STRICT_SIZE
Note that it doesn't make a difference whether you set MALLOC_FILL_SPACE.
But if you set the environment variables in a Terminal window, then say:
./ButtonMessage.app/Contents/MacOS/ButtonMessage
the drawing bug doesn't occur.
Even if there is no workaround for this, I'd appreciate knowing whether
or not it is our bug. It's been driving me bananas.
The actual drawing takes place in
zoolib/src/platform/macos/ZOSWindow_MacOSX.cpp, in
ZOSWindow_MacOSX::EventHandler_Content. The following line prepares to
draw in the window's grafport:
ZDC theDC(this->GetCanvas(), ZPoint::sZero);
then the actual drawing takes place in:
fOwner->OwnerUpdate(theDC);
If you set a breakpoint on that line then step over it each time its
hit, you can see the bits of the window appearing on the desktop one by
one, rather than where they should be in the window.
ZOSWindow_MacOSX.cpp is very new, largely untested code. So there could
well be bugs in it. But I wouldn't expect the behaviour I'm seeing,
where Guard Malloc only causes bugs when used under GDB.
The window has some buttons in it which are drawn with the Appearance
Manager. Normal behavior is to click a button, then the number of the
button is sent in a ZMessage to the other window, which displays the
number. It's meant as an illustration of a very minimal ZooLib application.
Thanks for your help.
Rippit the Ogg Frog
email@hidden
http://www.oggfrog.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden