i have this function :
-(void)blink:(CCSprite *)sprite
{
CCSprite *blinker=[sprite copy]; // i have add that to prevent sprite from change.
it gets a sprite and do animation on it, but sprite is keep changing all time cause its a pointer, so my function keep get a different sprites -WHICH I DONT WANT.
i was trying to copy it to another ccsprite, but its crashes.
whats wrong here ?
is that because i havnt release it ?
thanks alot
Can you post the code where call the blink method?
Maybe you can try this:
-(void) blink:(CCSprite*)sprite {
[sprite retain];
// Do some stuff with the sprite here
[sprite release];
}
However, functions should be called with thread-safe parameters so they don't get deallocated during the functions execution.
Related
I come from a C/C++ background and am currently learning a bit about Cocoa and Objective-C.
I have a weird behavior involving lazy initialization (unless I'm mistaken) and feel like I'm missing something very basic.
Setup:
Xcode 10.1 (10B61)
macOS High Sierra 10.13.6
started from a scratch Cocoa project
uses Storyboard
add files TestMainView.m/.h
under the View Controller in main.storyboard, set the NSView custom class as TestMainView
tested under debug and release builds
Basically, I create an NSTextView inside a view controller to be able to write some text.
In TestMainView.m, I create the chain of objects programmatically as decribed here
There are two paths:
first one is enabled by setting USE_FUNCTION_CALL to 0, it makes the entire code run inside awakeFromNib().
second path is enabled by setting USE_FUNCTION_CALL to 1. It makes the text container and text view to be allocated from the function call addNewPage() and returns the text container for further usage.
First code path works just as expected: I can write some text.
However second code path just doesn't work because upon return, textContainer.textView is nil (textContainer value itself is totally fine).
What's more troubling though (and this is where I suspect lazy init to be the culprit) is that if I "force" the textContainer.textView value while inside the function call, then everything works just fine. You can try this by setting FORCE_VALUE_LOAD to 1.
It doesn't have to be an if(), it works with NSLog() as well. It even works if you set a breakpoint at the return line and use the debugger to print the value ("p textContainer.textView")
So my questions are:
is this related to lazy initialization ?
is that a bug ? is there a workaround ?
am I thinking about Cocoa/ObjC programming the wrong way ?
I really hope I am missing something here because I cannot be expected to randomly check variables here and there inside Cocoa classes, hoping that they would not turn nil. It even fails silently (no error message, nothing).
TestMainView.m
#import "TestMainView.h"
#define USE_FUNCTION_CALL 1
#define FORCE_VALUE_LOAD 0
#implementation TestMainView
NSTextStorage* m_mainStorage;
- (void)awakeFromNib
{
[super awakeFromNib];
m_mainStorage = [NSTextStorage new];
NSLayoutManager* layoutManager = [[NSLayoutManager alloc] init];
#if USE_FUNCTION_CALL == 1
NSTextContainer* textContainer = [self addNewPage:self.bounds];
#else
NSTextContainer* textContainer = [[NSTextContainer alloc] initWithSize:NSMakeSize(FLT_MAX, FLT_MAX)];
NSTextView* textView = [[NSTextView alloc] initWithFrame:self.bounds textContainer:textContainer];
#endif
[layoutManager addTextContainer:textContainer];
[m_mainStorage addLayoutManager:layoutManager];
// textContainer.textView is nil unless forced inside function call
[self addSubview:textContainer.textView];
}
#if USE_FUNCTION_CALL == 1
- (NSTextContainer*)addNewPage:(NSRect)containerFrame
{
NSTextContainer* textContainer = [[NSTextContainer alloc] initWithSize:NSMakeSize(FLT_MAX, FLT_MAX)];
NSTextView* textView = [[NSTextView alloc] initWithFrame:containerFrame textContainer:textContainer];
[textView setMaxSize:NSMakeSize(FLT_MAX, FLT_MAX)];
#if FORCE_VALUE_LOAD == 1
// Lazy init ? textContainer.textView is nil unless we force it
if (textContainer.textView)
{
}
#endif
return textContainer;
}
#endif
- (void)drawRect:(NSRect)dirtyRect {
[super drawRect:dirtyRect];
// Drawing code here.
}
#end
TestMainView.h
#import <Cocoa/Cocoa.h>
NS_ASSUME_NONNULL_BEGIN
#interface TestMainView : NSView
#end
NS_ASSUME_NONNULL_END
I am not familiar with cocoa that much but I think the problem is ARC (Automatic reference counting).
NSTextView* textView = [[NSTextView alloc] initWithFrame:containerFrame textContainer:textContainer];
In the .h file of NSTextContainer you can see NSTextView is a weak reference type.
So after returning from the function it gets deallocated
But if you make the textView an instance variable of TestMainView it works as expected.
Not really sure why it also works if you force it though. ~~(Maybe compiler optimisation?)~~
It seems forcing i.e calling
if (textContainer.textView) {
is triggering retain/autorelease calls so until the next autorelease drain call, textview is still alive.(I am guessing it does not get drained until awakeFromNib function returns). The reason why it works is that you are adding the textView to the view hierarchy(a strong reference) before autorelease pool releases it.
cekisakurek's answer is correct. Objects are deallocated if there is no owning (/"strong") reference to them. Neither the text container nor the text view have owning references to each other. The container has a weak reference to the view, which means that it's set to nil automatically when the view dies. (The view has an non-nilling reference to the container, which means you will have a dangling pointer in textView.textContainer if the container is deallocated while the view is still alive.)
The text container is kept alive because it's returned from the method and assigned to a variable, which creates an owning reference as long as that variable is in scope. The view's only owning reference was inside the addNewPage: method, so it does not outlive that scope.
The "force load" has nothing to do with lazy initialization; as bbum commented, that it "works" is most likely to be accidental. I strongly suspect it wouldn't in an optimized build.
Let me assure you that you do not need to go around poking properties willy-nilly in Cocoa programming. But you do need to consider ownership relations between your objects. In this case, something else needs to own both container and view. That can be your class here, via an ivar/property, or another object that's appropriate given the NSText{Whatever} API (which is not familiar to me).
I recently posted a question here about some memory issues I was having. I've got that fixed now thanks to this wonderful community but I'm facing another problem. I'm using Cocos2d to develop a game and I'm trying to remove a Sprite from and array. The problem arises when I try and release the temporary array I'm using to keep track of the sprites to remove.
NSMutableArray *spritesToRemove = [[NSMutableArray alloc] init];
// Loop through all sprites
for(CSSprite *sprite in _sprites){
if(sprite.toRemove){
[spritesToRemove addObject: sprite];
}
}
// loop through sprites to be removed
for(CSSprite *removeableSprite in spritesToRemove){
[_sprites removeObject: removeableSprite];
// Cocos2d code to remove a sprite
[self removeChild: removeableSprite cleanup: YES];
}
[spritesToRemove release]; // EXC_BAD_ACCESS error
I get a feeling the reason I'm getting the error is because I'm releasing the sprite object in [self removeChild: removeableSprite cleanup: YES]; before actually releasing the array. It all works fine if I remove the line [spritesToRemove release] but I obviously then have a memory leak on my hands.
I've tried moving the removal of the sprites around and I can get the memory thing sorted by completely omitting the line [self removeChild: removeableSprite cleanup: YES]; but then Cocos2d throws the same EXC_BAD_ACCESS error from within CCNode at [child visit]; of -(void) visit
Thanks again for your help :-)
EDIT: I enabled NSZombie and I got this message:
*** -[Sprite release]: message sent to deallocated instance 0xfa94cf0
Which to me kind of suggests my initial thought, somewhere an entry in the array is being released to soon. Would that be correct? If so is there anyway for me to find out where?
I managed to find the issue (and to be honest I feel a little silly :-P ). I was releasing the sprite manually once I added it to the array, which wasn't in the code provided so you guys couldn't have found it. The sprite was already set up to be autoreleased and thus was being cleared twice - causing my error.
I'm probably over-thinking this, but I've been stuck on it a while, so I figured I'd reach out for some advice/help.
I'm using GameKitHelper (http://www.learn-cocos2d.com/tag/gamekithelper/), thus far, it's been pretty helpful. So, I have the helper initialized on in my "MainMenu" with the protocol implemented, etc:
#interface MainMenu : CCLayer <GameKitHelperProtocol> {
...
GameKitHelper *gkHelper;
}
In the main menu code, I have this:
gkHelper = [GameKitHelper sharedGameKitHelper];
gkHelper.delegate = self;
[gkHelper authenticateLocalPlayer];
Seems pretty strait forward. In fact, it works, exactly as I expect it to. I have the methods it's looking to be in place there (even though most don't have code associated with them (yet?)). My issue is when I actually want to start my game. So, I'm using the onMatchFound() to start the game, which basically works:
-(void) onMatchFound:(GKMatch*)match
{
[[CCDirector sharedDirector] replaceScene:[CCTransitionFade transitionWithDuration:1.2f scene: [[MultiplayerLoading initWithData:Multiplayer withMultiplayerType:gameTypeToPlay andInitiator:false] scene]]];
}
My issue is when I'm attempting to play the game, the receive delete method fires in the MainMenu NOT the game class, so things aren't being calculated properly.
Is there a way to pass the control to the game layer from the main menu when the onMatchFound fires?
Hopefully this gives enough info, let me know if not.
Thanks everyone!
There's two ways you can make this work. One way is to have a global Singleton class as the GameKitHelper delegate. You can then relay messages via this Singleton class.
Or simply assign the new scene as the GameKitHelper delegate:
-(void) onMatchFound:(GKMatch*)match
{
CCScene* newScene = [MyNewScene scene];
[GameKitHelper sharedGameKitHelper].delegate = newScene;
[[CCDirector sharedDirector] replaceScene:newScene];
}
Also, there seems to be something wrong with how you create the new scene:
[[MultiplayerLoading initWithData:Multiplayer
withMultiplayerType:gameTypeToPlay
andInitiator:false] scene];
It appears you are first calling the init method, then the class method scene which allocates the instance (see the scene implementation). It looks to me like it should rather be:
[[[MultiplayerLoading alloc] initWithData:Multiplayer
withMultiplayerType:gameTypeToPlay
andInitiator:false] autorelease];
Btw, the Cocoa Coding Guidelines recommend not to "link" method parameters with the "and" keyword and using "with" more than once is also quite odd. Cleaned up it should rather be:
[[[MultiplayerLoading alloc] initWithData:Multiplayer
multiplayerType:gameTypeToPlay
initiator:false] autorelease];
Excuse me for being picky. :)
Could this be because your MainMenu is set as the delegate in your GameKitHelper? I'd try setting the delegate to the game inside onMatchFound. Give that a try.
In objective-c, is there some way to check a variable hasn't been released by the time a lambda is called?
-(void) loadImageIntoImageView:(UIImageView*) imgView
{
[MyLibrary getImageFromWebSlowly complete:^(UIImage *img, BOOL success) {
// What if this bit of code is called 50 seconds later,
// and by that time the imgView was dealloc'd or released?
// Eg by that time the user closed the view with the image view on it.
imgView.image = img;
}];
}
Any suggestions?
(edited for clarity)
In short, don't use __block or, more complexly, assign nil to the __block variable when it is deallocated.
As written, there is no need for the __block keyword in that code unless you explicitly want a weak reference to imgView (which you probably don't).
I think you mean "deallocated" rather than released, and with no garbage collection on iOS, this isn't possible. You should use some other method to determine whether the UIImageView has gone away.
Also, I don't think __block does what you think it does; consider reading about how block variables work.
Stick with me. I'm visually impaired, have never used this site before, and will probably not post this in precisely the format that you are all used to. I apologize for any unintentional faux pas's herein.
Using Objective-C in an iOS project…
I have a singleton class, set up in what appears to be the usual way for Objective-C. It is, in the main, a series of methods which accept NSString values, interprets them, and return something else. In the code below, I'm simplifying things to the barest minimum, to emphasize the problem I am having.
From the singleton class:
- (NSUInteger) assignControlState:(NSString *)state {
// excerpted for clarity...
return UIControlStateNormal; // an example of what might be returned
}
Now, an instance of another class tries to use this method like so:
- (void) buttonSetup:(UIButton*)button {
[button setTitle:#"something" forState:[[SingletonClass accessToInstance] assignControlState:#"normal"]];
}
This code actually works. HOwever, when the system goes to draw the UI which includes the button whose title was set in this way, an EXC_BAD_ACCESS error occurs.
If the assignControlState method is moved into the same class as the buttonSetup method, no error is generated.
I'm guessing this is something about Apple's memory management that I'm not fully understanding, and how things go in and out of scope, but for the life of me, I can't figure out where I'm going wrong.
HOpe someone can help. Thanks.
The problem is in your accessToInstance method. I'll bet you are under-retaining. The implementation should be more like this:
static SingletonClass *sSingletonClass = nil;
#implementation
+ (id)accessToInstance {
if (sSingletonClass == nil) {
sSingletonClass = [[[self class] alloc] init];
}
return sSingletonClass;
}
#end
Now, if your program is following normal memory management rules, the singleton will stay around. You can check by writing:
- (void)dealloc {
[super dealloc]; // <-- set a breakpoint here.
}
If the debugger ever stops at this breakpoint, you know something in your program has over-released the singleton.
You know that bit you excerpted for clarity? I think you need to show us what it is because there's probably an over release in it somewhere.
Specifically, I think you release an autoreleased object. If you do that and don't use the object again, everything will carry on normally until the autorelease pool gets drained. The autorelease pool gets drained automatically at the end of the event at about the same time as the drawing normally occurs.
That would also explain the delayed crash following the NSLogs.