SIGSEV I can trace, but not fix (help needed)

Moderator
Posts: 370
Joined: 2006.08
Post: #1
First off, I'd like to apologize for posting three posts in a row, but they have been posted over the span of three of four days, so I'm hoping that that is okay Smile
I have a program (zipped version, here: http://ghettointeractions.com/MacObjectLoader.zip)
I'm getting a SIGSEV error in it, and the debugger tells me that it is in the destructor for my Object class. If someone could maybe take a look at this and tell me what is going wrong, that would be great Smile
Also: A problem that I think might be related to the one above is that my file I/O has not been working since I ported it from Windows to the Mac.
Thanks again Smile
-wyrmmage

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
Post: #2
Well, I've been working on the code for awhile more, but now I seem to be having more problems than ever. I've posted an updated versio of my code at the same place as the link above.
-wyrmmage

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #3
Your download is corrupt.
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
Post: #4
you're right, sorry. Here's the link to the new version: http://www.ghettointeractions.com/MMORPG.zip

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #5
This one builds a black window that does nothing?
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
Post: #6
OneSadCookie Wrote:This one builds a black window that does nothing?

lol, yes. I'm merely making the underlying code for a custom 3D engine. If you look at the log behind the blank window, you'll see at least 10 SIGSEV errors and the like. (I'm guessing you have to run it under XCODE to see the SIGSEV errors, they aren't displayed when you just run the application. The program is supposed to read the text from the Objects\ObjectManagers.txt file into the Objects\TestWritingFile.txt file. It's also supposed to read the text from the Objects\mainMenu\meshList.txt file and write the contents to the Objects\mainMenu\testWritingFile.txt

Sorry, I probably should have provided this information before.
-wyrmmage

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #7
2 things: are you using \ instead of /? Only Windows uses \, so that's likely an error; you must use /. Also, are you making sure you resolve the directory? When you launch your application, unless it's under Debug mode and launch it from XCode, your current directory is not the one where your application resides. (it's likely either root or your home directory)
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
Post: #8
oh, I see. How would I got about resolving my home directory? I know that I have seen it done before in Objective-C, but what would be the function name in C++?
Do you think that that is what is causing the SIGSEV problems?
Thanks guys, you are really helping Smile
-wyrmmage

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #9
The way I've done it is by taking argv[0] from main and going back 4 slashes. (for getting parentDir from parentDir/MyApp.app/Contents/MacOS/MyApp) For other platforms, you only need to go back 1 slash for the parentDir/MyApp. (or parentDir\MyApp.exe for Windows) And yes, if it can't find the file, fopen would be returning NULL, which would cause segfaults.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
akb825 Wrote:The way I've done it is by taking argv[0] from main and going back 4 slashes. (for getting parentDir from parentDir/MyApp.app/Contents/MacOS/MyApp) For other platforms, you only need to go back 1 slash for the parentDir/MyApp. (or parentDir\MyApp.exe for Windows) And yes, if it can't find the file, fopen would be returning NULL, which would cause segfaults.

This is bad; you have absolutely no guarantee that argv[0] will contain the absolute path to your application.

On Mac OS X, you should use CFBundle or NSBundle to find your application.
On Linux, you should read the symbolic link /proc/<pid>/exe to find your executable.
On Windows, the initial working directory appears always to be the one containing your exe.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #11
Just out of curiosity, under what conditions will it not give you a useable path to your program? My Monkey3D Demo app uses that method, and it's worked fine even when I made an alias or a symbolic link (I'm sure they're the same, though) of either the app bundle or the executable itself and moved it around. The only problem I ran into was if I tried to execute the symbolic link from the command line (without the open command), it would fail saying that there's no Info.plist file.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
Any Finder launch will currently set it up with the correct absolute path (though I'm not certain it'll always canonicalize symbolic links to the executable). As far as I know, though, this behavior is not guaranteed to continue in the future.

Command-line launches, however, will use whatever string you used to execute the program, so as you've discovered, symbolic links mess things up. Having the executable in your path will also mess things up.
Bottom line, why do something hacky that may or may not work now or in the future, when there's a perfectly good API that will always do the right thing?
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #13
OneSadCookie Wrote:Any Finder launch will currently set it up with the correct absolute path (though I'm not certain it'll always canonicalize symbolic links to the executable). As far as I know, though, this behavior is not guaranteed to continue in the future.

Command-line launches, however, will use whatever string you used to execute the program, so as you've discovered, symbolic links mess things up. Having the executable in your path will also mess things up.
Bottom line, why do something hacky that may or may not work now or in the future, when there's a perfectly good API that will always do the right thing?
Because the API isn't cross-platform. Rasp It would be nice if there were a non-hacky non-platform-specific way to do this. Annoyed
Quote this message in a reply
Moderator
Posts: 370
Joined: 2006.08
Post: #14
ok, I'll look into NSBundle (Which I can call from C++, correct?). Thanks for the help guys Smile
-wyrmmage

Oh, also: can I just use the ~ ? Doesn't that always mean that you are starting in the home directory?

Worlds at War (Current Project) - http://www.awkward-games.com/forum/
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #15
If you're in C++, CFBundle's probably easier -- you'd need an ObjC++ source file to use NSBundle.
I don't see how ~ would help you here, but even if it would, it's an illusion provided by the shell. If you want to use it within your program, you'll need to expand it yourself.

akb825, here's a cross-platform API for you:

Code:
void ChangeToSensibleDirectory(void)
{
#if defined(__APPLE__)
    CFBundleRef mainBundle = CFBundleGetMainBundle();
    CFURLRef resourcesURL = CFBundleCopyResourcesDirectoryURL(mainBundle);
    char path[PATH_MAX];
    if (!CFURLGetFileSystemRepresentation(resourcesURL, TRUE, (UInt8 *)path, PATH_MAX))
    {
        fprintf(stderr, "Can't change to Resources direcory; something's seriously wrong\n");
        exit(EXIT_FAILURE);
    }
    CFRelease(resourcesURL);
    chdir(path);
#elif defined(linux)
    pid_t my_pid = getpid();
    char proc_pid_exe_path[PATH_MAX];
    sprintf(proc_pid_exe_path, "/proc/%d/exe", (int)my_pid);
    
    char executable_path[PATH_MAX];
    if (readlink(proc_pid_exe_path, executable_path, PATH_MAX) == -1)
    {
        fprintf(stderr, "Couldn't find executable\n");
        return EXIT_FAILURE;
    }
    
    *(strrchr(executable_path, '/')) = '\0';
    chdir(executable_path);

    /* assume we're in PREFIX/bin */
    chdir("../share");
#elif defined(_WIN32)
    /* we're already in a good place */
#else
    #error Unknown OS
#endif
}
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  What could be causing this SIGSEV? Jones 9 3,365 Jun 3, 2006 10:24 PM
Last Post: PowerMacX