Re: screen dump crash with out sleep
Re: screen dump crash with out sleep
- Subject: Re: screen dump crash with out sleep
- From: Michael Watson <email@hidden>
- Date: Sat, 23 Jun 2007 01:42:31 -0400
This code has a lot of problems.
FIRST: Post a stack trace from the crash. This is the #1 way to get
help with crashing bugs, when paired with source code.
SECOND:
On Jun 21, 2007, at 3:49 PM, email@hidden wrote:
Hi
I am programming a screen dump. Please see my code. If the sleep
is removed, then the application crashes.
This is a race condition, and the specific behaviour suggests that
you are attempting to use some data that isn't valid when attempting
to use it. See bottom.
The image is in another method directly written to file. So far it
seems to be the sleep that makes it crash or not crash.
It's not the sleep that makes it do anything; the sleep simply
fiddles with the timing of the thread. Your solution lies elsewhere.
Please could somebody explain why?
Please suggestions for better/faster code is much appreciated.
However please not deprecated carbon, or to low level openGL
As stated by Dorian, Carbon is not deprecated. Carbon UI won't make
the 64-bit cut in Leopard (as discussed publicly on the carbon-dev
list), but Carbon itself is not deprecated.
As far as OpenGL is concerned, if you want real performance with what
you want to do, you'll probably have to dive into the frame buffer.
Thank you very much
NSWindow *window;
NSBitmapImageRep *rep;
NSImage *image;
window = [[NSWindow alloc] initWithContentRect:rect
styleMask:NSTitledWindowMask
backing:NSBackingStoreNonretained defer:NO];
What is rect? How do you get this? It sorta looks like this is at the
top of a method, which suggests that rect is an argument passed in
from elsewhere. Is this a method spawned in a separate thread?
If this window is meant to grab its contents beneath, and that's all--
that is, the rect argument is the screen extents--why not
NSBorderlessWindowMask instead?
[window setBackgroundColor:[NSColor blueColor]];
[window setLevel:NSScreenSaverWindowLevel + 1];
NSScreenSaverWindowLevel + 1 is probably not wise. Don't try to put
windows above the screen saver level. I'm pretty sure this is
recommended against. (But I'm not certain about this. It still seems
sketchy.)
[window setHasShadow:NO];
[window setAlphaValue:0.0];
You also need [window setOpaque:YES] here.
[window orderFront:self];
[window setContentView:[[[NSView alloc] initWithFrame:rect]
autorelease]];
Three problems I see here:
1. Why are you setting the content view after you put the window on
the screen when you never use the window before that? Needless
redrawing.
2. Why do you replace the content view in the first place? You're not
doing anything special here, just inserting a normal, blank NSView.
You allocate a new view, initialize it, send it an autorelease
message, then set it as the content view of the window. That's a
performance waste. Just delete that line entirely and leave the
window's content view alone.
3. Even though you should delete that line, here's a better way of
writing it:
NSView *aView = [[NSView alloc] initWithFrame:rect];
[window setContentView:aView];
[aView release];
sleep(1);
Coming back to this. Short story: race condition somewhere.
[[window contentView] lockFocus];
NSRect bRect = [[window contentView] bounds];
rep = [[NSBitmapImageRep alloc] initWithFocusedViewRect:bRect];
[[window contentView] unlockFocus];
[window orderOut:self];
[window close];
image = [[[NSImage alloc] initWithSize:[rep size]] autorelease];
[image addRepresentation:rep];
return image;
You're leaking your NSBitmapImageRep and your NSWindow. Big memory
leaks. You need to issue -release to both of them before your method
returns. Have you read the Cocoa memory management documentation?
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/
index.html
I also don't see a need for -close here. Issue -orderOut: and then
release the window.
So your crash sounds like a race condition. I get the feeling that
you spawn a new thread that invokes this method, but your file
writing command happens on another thread. There are several reasons
the crash would occur in such a scenario, all of which pretty much
boil down to "the data you tried to write was somehow not what you
expected when you attempted to use it". When you issue sleep(1), the
thread on which this method is executed sleeps for 1 second, which
probably ends up making sure the data you later attempt to access is
actually there or what your code otherwise expects. However, and I
stress this with my caps lock key and a happy face:
THIS IS NOT A SOLUTION. :-)
The reason is because you can't guarantee that you need >= 1 second
to get your ducks in a row.
In short, you need to post your crash's stack trace and any other
relevant code. (For example, the part that invokes this method and
the part that performs the file write.)
--
m-s
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden