SFML community forums
General => General discussions => Topic started by: alaterale on August 30, 2009, 10:51:29 pm
-
Hi,
I've been using SFML for a while now, and I noticed that with the Cocoa port building, I always got errors about VideoMode in AppController and now GLKit. I'm not really an objective c coder by any stretch (prefer C++), but I was kind of sick of seeing the warnings about incomplete definitions and such, so I fixed a couple things that were causing that (mainly turning 3 variables into variable pointers and adding new/deletes to init/deallocs). I also found a better way of fixing that apple menu warning too (based off of SDL's way of fixing the warning).
I am unsure about how to submit patches to this system here, so I guess I can just attach it to this thread? From what I've seen of the svn for 2.0 it looks like these things are still there (and I like to have a clean build log if I can help it :P).
The other question I have is: what is the cause of these errors?
2009-08-30 16:18:00.290 gamestone[4626:10b] *** _NSAutoreleaseNoPool(): Object 0xa20260 of class NSMenu autoreleased with no pool in place - just leaking
Stack: (0x9152af4f 0x91437432 0x950d5e21 0x95144d79 0x317b4e 0x318458 0x31d459 0x91f52dbc 0x91f52cb0 0x9529432b 0x951b4e8f 0x95263b64 0x95263869 0x952634ef 0x95261d94 0x9517eac7 0x316ae8 0x319077 0x31c6af 0x3c6375 0x399d4d 0x3a16b3 0x1a954 0x1bfd5 0xbbda 0x1832f 0x1a57a5 0x1d4092 0x1d7115 0x1d7903 0x1d7b07 0x2966c8 0x2975b3 0x3c6dd6 0x3c6a34 0x5a36)
2009-08-30 16:18:00.291 gamestone[4626:10b] *** _NSAutoreleaseNoPool(): Object 0xa0a620 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x9152af4f 0x91437432 0x950c4394 0x951b76e2 0x95144fbd 0x317b4e 0x318458 0x31d459 0x91f52dbc 0x91f52cb0 0x9529432b 0x951b4e8f 0x95263b64 0x95263869 0x952634ef 0x95261d94 0x9517eac7 0x316ae8 0x319077 0x31c6af 0x3c6375 0x399d4d 0x3a16b3 0x1a954 0x1bfd5 0xbbda 0x1832f 0x1a57a5 0x1d4092 0x1d7115 0x1d7903 0x1d7b07 0x2966c8 0x2975b3 0x3c6dd6 0x3c6a34 0x5a36)
2009-08-30 16:18:00.292 gamestone[4626:10b] *** _NSAutoreleaseNoPool(): Object 0xaa0c90 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking
Stack: (0x9152af4f 0x91437432 0x9511231d 0x951121b2 0x95112159 0x951b776c 0x951b773b 0x95144fbd 0x317b4e 0x318458 0x31d459 0x91f52dbc 0x91f52cb0 0x9529432b 0x951b4e8f 0x95263b64 0x95263869 0x952634ef 0x95261d94 0x9517eac7 0x316ae8 0x319077 0x31c6af 0x3c6375 0x399d4d 0x3a16b3 0x1a954 0x1bfd5 0xbbda 0x1832f 0x1a57a5 0x1d4092 0x1d7115 0x1d7903 0x1d7b07 0x2966c8 0x2975b3 0x3c6dd6 0x3c6a34 0x5a36)
2009-08-30 16:18:00.293 gamestone[4626:10b] *** _NSAutoreleaseNoPool(): Object 0xa99830 of class _NSThemeCloseWidget autoreleased with no pool in place - just leaking
Stack: (0x9152af4f 0x91437432 0x950cd696 0x950c33d1 0x950ccf86 0x95146695 0x905f3676 0x950d9adc 0x950d97e8 0x951b780a 0x951b778d 0x951b773b 0x95144fbd 0x317b4e 0x318458 0x31d459 0x91f52dbc 0x91f52cb0 0x9529432b 0x951b4e8f 0x95263b64 0x95263869 0x952634ef 0x95261d94 0x9517eac7 0x316ae8 0x319077 0x31c6af 0x3c6375 0x399d4d 0x3a16b3 0x1a954 0x1bfd5 0xbbda 0x1832f 0x1a57a5 0x1d4092 0x1d7115 0x1d7903 0x1d7b07 0x2966c8 0x2975b3 0x3c6dd6 0x3c6a34 0x5a36)
2009-08-30 16:18:00.293 gamestone[4626:10b] *** _NSAutoreleaseNoPool(): Object 0xa9c910 of class _NSThemeWidget autoreleased with no pool in place - just leaking
There are more of those, but I don't know how to fix those on my own. Been looking around online for similar problems and finding what I could fix. Is this the case in the latest 2.0 svn edition?
Thanks for any help, and if I can I will attach my edits so you can see whether its worthy enough to post as an official patch :)
-
I guess I can't attach the patch files on this forum (maybe based on how new I am here)?
Well, here's my edit for the setAppleMenu thing, which is pretty similar to how I saw SDL handle it and get rid of the warning.
// MYEDITS
// For some reaon, Apple removed setAppleMenu from the headers in 10.4,
// but the method still is there and works. To avoid warnings, we declare
// it ourselves here.
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
@interface NSApplication(SFML_Missing_Methods)
- (void)setAppleMenu:(NSMenu *)menu;
@end
#endif
// MYEDITS
/* setAppleMenu disappeared from the headers in 10.4 */
//#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_4
//@interface NSApplication (SFML)
//- (void)setAppleMenu:(NSMenu *)menu;
//@end
//#endif
So I guess it's really just one line of change, and maybe you need it to be SFML there for objective C? But this way removes the warning and my app still runs (though with those previous memory leaks or whatever).
-
This declaration is there on purpose. AppController uses it so I don't understand why you want to comment it out ? The declaration allows the compiler to performs checks when I call this method.
As for the sfml2 branch, the Mac OS X port is absolutely not up to date. It's currently unusable.
And for the leaks... do you use the latest SVN sources ? (trunk)
If so, could you provide a minimal example producing these error messages ?
Thanks for your reports,
Ceylo
-
Well, all I really changed in that part was the "@interface NSApplication (SFML)" part. It may be used, but the code as it is says that if you leave this in, it's "incomplete". I didn't make up the part about Missing_methods. I got that right from SDLMain.m, and it makes the warning go away, and my app still runs the same. Though it might mess up the user menu or something, I dunno, I'm not really great at objectivec. But I would imagine its giving a warning for a reason and what would be a better improvement to get rid of it?
If the SFML2 branch has a broken OSX port then I guess I can't use the SVN branch to see if the leaks go away, since I'm developing this on my mac. As for what causes it, a minimal window opening does apparently. I use SFML mainly for window/opengl contexts and input detection, and more recently the Audio stuff. But I write my own opengl. I don't have a specific example since its not a small codebase, but I just upgraded my engine to 1.5 and after the app finishes is where I get those errors.
Here's the link to the SVN repo I have if you want:
http://code.google.com/p/gamestone/source/browse/
-
Here are the other changes too I did:
http://code.google.com/p/gamestone/source/detail?r=600
I probably screwed up with the whole making those variables pointers, but I read online that the whole "user defined constructor" thing could be fixed by changing a C++ class variable to a pointer and adding init/dealloc stuff.
You're obviously more of a seasoned objc coder than me, does that make things worse or is basically the same? Worked in 1.4 for me fine, and I didn't see those memory leak errors before. I'll try to do some research on what could be causing that. Learn more about objc all the time this way I guess :P
-
I don't really understand. Are you saying that using "@interface NSApplication(SFML_Missing_Methods)" instead of "@interface NSApplication (SFML)" drops the warning away ?
If the warning is here, it is because the method is DEFINED but not DECLARED. If I ever redefine it, the original defined method will no more work.
As for the SVN repository, you can still use the sources of the trunk directory. These are the sources of SFML 1.6.
-
Here are the other changes too I did:
http://code.google.com/p/gamestone/source/detail?r=600
I probably screwed up with the whole making those variables pointers, but I read online that the whole "user defined constructor" thing could be fixed by changing a C++ class variable to a pointer and adding init/dealloc stuff.
You're obviously more of a seasoned objc coder than me, does that make things worse or is basically the same? Worked in 1.4 for me fine, and I didn't see those memory leak errors before. I'll try to do some research on what could be causing that. Learn more about objc all the time this way I guess :P
Things can indeed be fixed using new/delete stuff, but here it is useless and implies checking that the pointers being used are valid. By the way, the C++ constructors can be called when an Obj-C object declares a C++ member if a specific GCC option is used. But here again.. it's useless.
-
Yeah, rewriting that drops the warning away. I knew it was probably more of a hack, so I'm not surprised there's a logical reason for it. Well, either way, I'll probably keep my local hack of it to get rid of that annoying message popping up :P What about the other additions? The user defined constructor thing. The only part about that which I'm unsure of, is that I don't know all the places where the variables would be constructed, so I might have missed a new or a delete, but it seems GCC likes having a pointer there instead of a regular variable.
Sorry about the confusion about the svn tree you have. Here I thought the svn trunk was the stuff being prepared for 2.0. Hehe, sorry bout that :lol: I will get on that and see if the leak is still there (hopefully not). Thanks!
-
Ok, sorry about the other fixes too. Didn't know that there was a specific GCC flag for that kind of thing. Sorry for bringing up useless ideas, just thought I'd help somehow. Sorry for wasting your time :( I will try the latest svn version too. Thanks.
-
Don't worry about bringing ideas ^^ . Just try to think why the things are what they are before changing everything to fit your ideas :P .
I'm waiting for your feedback with the sources of the latest svn version :) .
-
Heh, I understand. I wasn't expecting others to change just to fit my ideas, but I like the idea of fixing warnings in the system. It just seems weird to ignore warnings when you can find ways to fix them. And I never thought my fixes were really good, since I'm still very unfamiliar with Objc :-P Working on testing the latest svn trunk now, will get post back here when I get some results.
-
Okay thanks !
-
Yes, updating to SVN does fix that weird pool/leak error, but now I get a different one:
2009-08-30 21:11:48.311 gamestone[1520:10b] CGSAddSurface failed - error 1001 (windowID:70)
But at least it's not a couple pages of huge error codes.
-
Can you provide a minimal code producing this error ?
-
I'm already up really late and tired, but I think I've pinned it down further as to what might be causing it (if my brain could be considered functional now :P). A "minimal" code sample is not that easy as the engine is running python scripts, and it can be a bit large to understand the whole layout. But here is a portion my main loop:
// Create the window
Create(title, width, height, bpp, depth, stencil, antialiasing);
// Check that it opened correctly
if (!IsOpened())
{
printf("ERROR: Window could not be opened\n");
return;
}
// Set maximum framerate
SetFramerateLimit(maxfps);
// Enable VSync
EnableVerticalSync(true);
// Enable key repeat
EnableKeyRepeat(false);
// Initialize OpenGL
InitializeGL();
// Initialize state
InitializeState();
// Swap buffers
Display();
// Start main loop
while (IsRunning())
{
// Process events
while (IsEventFull())
{
// Window close
if (GetEventType() == SCREEN_EVENT_CLOSED)
{
// End game
EndGame();
}
// Check input from controllers
CheckInput();
}
// Update State
InputState();
UpdateState();
// Swap buffers
Display();
Now, I have a thin wrapper around SFML stuff, so that's why those methods are different than the standard ones. The error pops up only when closing the program with Command Q. If I close it with checking the red close button, or do a command W and then command Q, it doesn't occur. So it might be something in the registered quit command (the apple menu one, that is autogenerated, because I know I didn't code it :P). A program on my end that is just a simple print hello world still does it (just an empty graphical window). With the above input checking code commented out still creates the error. When the IsEventFull (which just calls window.GetEvent(event)) part commented out, it becomes impossible to close the app without hard forcing it.
I hope this info is useful. Of course the source code is online too in those previous links I gave you in case you need to look at something else.
Now off to sleep (hate insomnia) :P
-
Hum ok thanks. I'll have look at it.
-
I've tried to build your program, but I failed.
The OpenAL and SFML frameworks can be used for the ppc and i386 architectures. And when running "cmake -LH" I can read this:
// Build architectures for OSX
CMAKE_OSX_ARCHITECTURES:STRING=i386
But at link time, the build process shows this :
Linking CXX executable gamestone
ld: warning: in /Library/Frameworks/OpenAL.framework/OpenAL, missing required architecture x86_64 in file
And then I can read there are loads of undefined symbols from the OpenAL and sfml-window libraries.
This happens because the sources have actually been compiled for the x86_64 architecture instead of i386 ! I dunno how to fix this as the environment variable already looks to be set up fine.
And the SFML Window-based project does not show me any error when using Command+Q.
Thus until I can get a full and minimal working code producing the "leaks" errors, I may not be able to fix the issue.
I've had a look at the quit menu settings: it calls -[NSApplication terminate:] which is the default behavior for a Cocoa application. Besides there should still remain the NSAutoreleasePool object of the AppController singleton, which probably means it has been destroyed externally. This can happen if you made an autorelease pool before before the one used by SFML and release yours (see Memory Management Programming Guide for Cocoa : Autorelease Pools (http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html#//apple_ref/doc/uid/20000047-997594)). I've some ideas, but I need to know one thing first : does the application you make explicitly use Cocoa ? (thus not through SFML)
Ceylo
-
Interesting. I've not seen those kinds of build errors before. I've built this on 32 and 64 bit systems (x86 and ppc) before without seeing that kind of stuff. How did you start the build process? Typically its something like this(after the svn retrieval):
> cd gamestone/Build/CMake
> cmake .
> make
Did you get any cmake errors for missing libraries (at the cmake . step)? Except for OpenGL and OpenAL (and whatever cocoa needs), all the dependencies should be included, and be the same on your system. What version of OSX are you using? What version of GCC are you compiling with? I'm still trying to perfect the build process (as well as the build documentation), so it would be a big help to figure out why it didn't work for you. I haven't tried to build with 10.6 or with 10.2 or below yet, so I dunno if that could be it. Could you give me a listing of all the errors at the beginning (not the missing symbol ones, since I imagine that there's an error earlier on that would cause those).
As for other uses of Cocoa, SFML Window is the only thing for that. All of the stuff I wrote is purely C/C++. I think the pool and leak issues are gone, just that weird surface error remains, unless that's also a memory leaking issue. Not sure what svn version you tested, but recently I was updating a few things, so I hope you didn't get it inbetween that. It should build as is from svn now, and I'm curious exactly what kind of library issues you're having.
-
I did the build process as you wrote.
I'm using Mac OS X 10.6 (the default architecture is x86_64) and I use GCC 4.2.
There is absolutely no error while compiling, only at link time.
Here is the full log (only rebuilding what failed) if you want it : gamestone-log.txt (http://pagesperso-orange.fr/c.sobecki/ceylo/data/gamestone-log.txt).
As for other uses of Cocoa, SFML Window is the only thing for that. All of the stuff I wrote is purely C/C++. I think the pool and leak issues are gone, just that weird surface error remains, unless that's also a memory leaking issue. Not sure what svn version you tested, but recently I was updating a few things, so I hope you didn't get it inbetween that. It should build as is from svn now, and I'm curious exactly what kind of library issues you're having.
Nothing in the Mac OS X port has been changed recently, so I don't think it should be the point. And... I didn't understand you provide the sources of libraries that the SFML website already provides compiled.
-
Thanks for posting that info, it helps a lot. So far, I see that you're not using Cmake 2.6, which could be a problem if the 2.4 modules aren't providing the right path or environment information. I set the minimum version in the cmakefile to 2.6, but for some reason it still lets you continue after that warning :P
If you're using 10.6, that could be it too (esp combined with an old version of cmake). I have a friend who just got 10.6 and I will ask him to try this out as well. At least the GCC version is 4 and above, which is another requirement.
Well, something has to have changed in SVN, since the 1.5 release I originally used had a ton of pooling issues, where 1.4 worked perfectly fine. With 1.6 from svn, as you said earlier, there's no more huge piles of pool warnings, just that one particular one, so something had to have changed since 1.5. All I did was copy over the same files from svn to what I had from 1.5.
If you're referring to the precompiled libraries, I never liked doing things that way, then you get into dependencies the user has, etc, different versions, packaging, and so on. It's just easier to include the exact versions necessary, compile from source, and link it all together then. And besides, this is something I'm going to be using for iphone and other embedded development too. The people I've had test this so far haven't had any problems (aside from the weird thing from 1.5 and now this in 1.6 that we're discussing now), aside from getting the right build environment set up to begin with, so that could be the problem here.
-
I had actually also installed CMake 2.6 but I was also having CMake 2.4 and it was the one being used.
Actually... using CMake 2.6 produces loads of errors at compile time because of missing files. See gamestone-log-2.6.txt (http://pagesperso-orange.fr/c.sobecki/ceylo/data/gamestone-log-2.6.txt).
Well you're right: a lot of things have changed since SFML 1.5. I misunderstood a few points... :oops: I never saw your CGSAddSurface message and I wonder whether it's related to your graphic card's driver.
Now about the precompiled libraries, I still don't understand why you just don't provide compiled versions of the libraries you need. You can still provide binaries of the version YOU need. This prevents every user from having to rebuild the whole stuff and you can still be positive the user is using the right version. The only reason I could see is if you added your own changes to theses libraries (and need to make other changes easily). Did you ?
-
That is a pretty weird error log, but it seems like the first error has something to do with your setup and headers/frameworks. Since it's referencing a standard header (in a 10.4 location) and it's missing... Not sure exactly how that happened. But again I've never seen those kinds of errors. Does the dev tools package have a default setting for where headers are found?
I just talked to my friend who got 10.6 and it compiled (with a few regular warnings that python always gives off, since his version of GCC is higher than mine and at some point they stopped going easy on non ansi stuff). Still awaiting more testing, but it seemed like he didn't run into the same errors.
Well, like I said, I prefer source compilation (and most of the people testing for me haven't had many problems other than setting up the right build environment, which again seems to be the problem here, unless they were building on windows, which is special case). But in any case, it just gets more complicated when dealing with binary libraries, etc, when just compiling from source is easier for developers. And, this really isn't the view that the average user will see anyway, since I'm going to be offering built executables that they just download and can use instantly without any kind of building. I do also want to provide official xcode project files, but it's much more of a complicated tool than cmake is to get working right. The trouble is, I never really know any fellow programmers using osx who want to contribute that kind of help.
I haven't changed the libraries too much, aside from updating where some external libraries were, and adding my own files to simplify the build process, but that's it. All of my changes are documented in Docs/Libraries.txt.
I wish I could figure out why your build environment is referencing standard C++ headers that don't exist for you though. I'll try to do some research into any special cmake changes I need to address to deal with multiple macosx sdk's installed at once.
-
I think I know why this is happening. Every time I try to use the Mac OS X 10.4 SDK with GCC 4.2 and Xcode, it tells me the 10.4 SDK is not compatible with GCC 4.2. But GCC 4.0 is.
I dunno how to tell CMake to use GCC 4.0 though.
-
Just found out some info that might shed light on why cmake is doing this.
http://bugs.mysql.com/bug.php?id=38608
http://www.cmake.org/pipermail/cmake/2006-October/011538.html
Basically, I might have to do some kind of setting of MACOSX_DEPLOYMENT_TARGET or something... which I kind of hoped I could avoid so I could make the scripts more general (not to mention I also don't know yet how to get your osx version from cmake in order to set this..). I'll try to think of something that will work out.
-
I don't thing it's related to the MACOSX_DEPLOYMENT_TARGET environment variable in any way (until you wish to no more support old Mac OS X versions). What I don't understand is why CMAKE_OSX_ARCHITECTURE is ignored.