__NSAutoreleaseNoPool(): ... autoreleased ...- just leaking

By erisdiscord Date 2011-04-16 04:30 Edited 2011-04-16 04:39

Huh, I know exactly what causes it in the general case, but I've never seen it with Gosu. Are you using any Cocoa APIs directly?

You tend to see this a lot with SDL games when they interact with the window server (setting the window title, querying window geometry) because Cocoa makes extensive use of autorelease and SDL is sloppy and doesn't set up autorelease pools around native operating system functions, but Gosu uses Cocoa's native application run-loop so autorelease pools are allocated automatically. That makes this error kinda mysterious.

I notice you seem to be using multiple Window classes. I don't think this is really supported and it could be the indirect source of your NSAutoreleasePool woes. Do you see this warning when the first window (MenuWindow from the looks of it) is open before you start a game?

And finally: I recommend you look into the state pattern—instead of having multiple Window classes, have a single Window object that delegates its draw, update, &c methods to a GameState object and put the code you currently have in your Window subclasses into GameState subclasses instead. When you want to go from menu to game or game to game over, switch out your state instead of your window.

By tjbladez Date 2011-04-16 06:13

Thank you for a prompt reply.
I am not using cocoa api directly and I do get a warning for first window open before I start a game.
Previously I was thinking about the delegate pattern and pushing everything to the states, but due to the amount of completely different behavior (different set of goals, functionality and availability to the rest of the objects) sticked with window subclassing.
Note that I dont need multiple windows at any point in time I should only care about 1 window (which works fine for GameWindow - GameOverWindow transition) and I would imagine MenuWindow to fully close prior to start of new run loop on the GameWindow. Implementing a delegate when you are straight up dealing with different windows each responsible for its unrelated set of functionality seems like a hack. Even if you call that a state object (which is disagree with since it is not close to what traditional state and state machine represent). However if there are no solution to support smooth window-window transactions (as in close 1 window, open another one) I will change it.

By erisdiscord Date 2011-04-16 22:49

Call them "modes" if you want; I don't see where delegating calls to different objects for different modes of operation is a hack any more than closing one window and opening another is, especially since Gosu's Window is really meant to be instantiated once and only once. Most of your code would not need to change—just create one new class that your "windows" inherit from (not strictly necessary), one Window subclass that just does the delegation, then make sure that you pass your single window instance to any image or sample constructors.

I don't see anything immediately obvious that should be causing leaked autoreleases, but from my observations I'm gonna say it's probably caused by your use of multiple windows. It's also worth noting that the additional windows stay open behind, so at the game over screen you've got the menu and the game window hanging out behind it. It seems like there are probably multiple Cocoa run loops going at this point and I'm pretty sure run loops other than the main don't have autorelease pools unless you explicitly allocate them.

By jlnr (dev) Date 2011-04-17 05:51

And one more bit, the "State" sounds a bit weird if you think of it as a delegate. But it stems from the fact that most oldschool games will have a global "int state" which can then be STATE_GAME, STATE_MENU, STATE_GAME_OVER etc. But having a switch/case in draw, update, button_down,... is very messy. So Gosu games traditionally use object delegates: GameState, MenuState, GameOverState, .... They're practically the same, which is why the name stuck. It's a common pattern with Gosu, the Chingu library includes a framework for just that.

By jlnr (dev) Date 2011-04-16 12:09

Can you say which class is leaking? I am usually careful to set up a pool wherever it makes sense. Maybe I have forgotten one place that can be called before the window construction is finished, which would circumvent Cocoa's safety net, I suppose. E.g., a global SOUND = Gosu::Sample.new(...)
Also, Gosu uses slightly different subsets of Cocoa depending on the OS version, so it is very possible that it only happens on some computers.
-
In any case, Gosu was not designed to open several windows. For one thing, the GC is by design not completely reliable. But also, I didn't really take it into account when writing all three Window implementations. (I should really have put an exception in place for that, since it works on some systems, many Gosu games do it...)

The idea is that Window should get #resize pretty soon—the glfw branch is aimed at that—and then the need will disappear :)

By tjbladez Date 2011-04-16 22:56

I am changing to code shortly to use just one Window. Thank you very much for your feedback erisdiscord and jlnr. I am curious to see if leaking will stop once it will be single window

By tjbladez Date 2011-04-19 17:52

Fixed. Thank you for your input jlnr, erisdiscord.