Craziest bug by far...
by Gonzo T. Clown · in Torque Game Engine · 03/10/2006 (11:44 pm) · 11 replies
If you can call it a bug. Here's the deal...
At line 40 of MacCarbFileio.cc you find the function...
bool dFileDelete(const char * name)
When using this function, I found it to work perfectly, except when it didn't. After enough success and failures, I finally figured out why it sometimes worked, and sometimes didn't. When you use "Build and Run" or even just "Run" while you are loaded into X-code, it works perfectly, BUT, if you simply launch your application via a standard double click(as you would expect the end user of your program to do) it does not work at all.
This would not appear to be an error in the TGE code, but some kind of wicked glitch in the Mac platform, one which I have no clue how to get around so I'm wondering if anyone else has experienced this problem or has found a solution to make it work correctly.
Any tips or advice would be greatly appreciated.
Gonzo
At line 40 of MacCarbFileio.cc you find the function...
bool dFileDelete(const char * name)
When using this function, I found it to work perfectly, except when it didn't. After enough success and failures, I finally figured out why it sometimes worked, and sometimes didn't. When you use "Build and Run" or even just "Run" while you are loaded into X-code, it works perfectly, BUT, if you simply launch your application via a standard double click(as you would expect the end user of your program to do) it does not work at all.
This would not appear to be an error in the TGE code, but some kind of wicked glitch in the Mac platform, one which I have no clue how to get around so I'm wondering if anyone else has experienced this problem or has found a solution to make it work correctly.
Any tips or advice would be greatly appreciated.
Gonzo
About the author
#2
03/11/2006 (4:58 pm)
I'm starting to feel like I'm the only one supporting Macs, lol 
#3
03/11/2006 (5:10 pm)
I support them emotionally! Actually I really hope to release my game on the mac too, but so much work todo before I even get there.
#5
03/12/2006 (1:38 am)
We're just very heads down getting ready for GDC the last several weeks Gonzo, that's all! I sent Paul a message on this thread, and when he can get to it he will for sure. 
#6
03/12/2006 (9:12 am)
Look at your path that dFileDelete is being passed... is it relative to the app package or is it absolute? When running a built .app the file path needed may be different (mygame.app > Contents > MacOS > ...) rather than passed straight to the executable as happens when Run straight from XCode. 
#7
Last week I just discovered A VERY STUPID BUG when I initialized a structured with a variable called num_imputs instead of one called num_nodes. Strange thing : I only saw this bug when I recompiled the engine for universal binaries.
Check to see if the variable used to hold the pathname is large enough for that.
03/12/2006 (5:22 pm)
I would go with Clint's tip. I already lost some nights tracing a bug because I defined a filename (8.3) with [12] characters instead of [13]. Last week I just discovered A VERY STUPID BUG when I initialized a structured with a variable called num_imputs instead of one called num_nodes. Strange thing : I only saw this bug when I recompiled the engine for universal binaries.
Check to see if the variable used to hold the pathname is large enough for that.
#8
I was passing the relative path to the function, such as "common/client/MyTempFile.cs" which works perfectly in Windows, and works perfectly when launching your Mac .app from X-code. However it will not work at all when running the .app without X-code. So to get a Mac to delete the same file you have to feed it the full path to the file. In my case it's "//volumes/work/torque/pb/build/Deployment/common/client/MyTestFile.cs". Using this method the file deletes exactly as it should. My best guess is that X-code sets the working directory to "Deployment" because thats the directory the .app is located in and it can find the file using the relative path from that directory, but without X-code the working directory remains "Desktop" and thus no file exists from the Desktop using the relative path.
So, in the future, if you should need to delete a file within your TGE directory using a Mac, you will need to supply the absolute path to the file.
Hope this helps, and thanks to all for your responses and suggestions.
03/13/2006 (1:56 am)
Sorry I couldn't respond sooner but my youmgest has pneumonia(sp?) and I have ben trying to get her to get some decent sleep. I managed to find the key to this early this morning and it turns out Jameson was very close in his assesment. Here's what I figured out...I was passing the relative path to the function, such as "common/client/MyTempFile.cs" which works perfectly in Windows, and works perfectly when launching your Mac .app from X-code. However it will not work at all when running the .app without X-code. So to get a Mac to delete the same file you have to feed it the full path to the file. In my case it's "//volumes/work/torque/pb/build/Deployment/common/client/MyTestFile.cs". Using this method the file deletes exactly as it should. My best guess is that X-code sets the working directory to "Deployment" because thats the directory the .app is located in and it can find the file using the relative path from that directory, but without X-code the working directory remains "Desktop" and thus no file exists from the Desktop using the relative path.
So, in the future, if you should need to delete a file within your TGE directory using a Mac, you will need to supply the absolute path to the file.
Hope this helps, and thanks to all for your responses and suggestions.
#9
@All: If you'll look in Platform::getWorkingDirectory(), around line 553, you'll see that we're setting the working directory ourselves. This is specifically there to work around working dir strangeness with Xcode and the Finder.
I tried to reproduce the bug using testFileDelete() from the console in a debug build, run both from Xcode and from the Finder. Both times I was able to delete arbitrary files, using relative paths or using absolute paths. So, basically, I cannot reproduce this bug, using stock 1.4.0u. There were no changes at all in engine/platformMacCarb/ between 1.4.0 and 1.4.0u, so 1.4.0 will also work correctly.
My guess is that you're using a release candidate version of 1.4 . I think there were working dir probs up until 1.4.0.
You'll also see working dir probs if you are building a command line tool, instead of a macosx bundled application.
See this thread for a fix for command line tool working directory problems.
@Gonzo: Check the version of TGE you're using, be sure it's at least 1.4.0 .
Share and Enjoy.
/Paul
03/13/2006 (8:19 pm)
This almost certainly has nothing to do with uninitialized variables.@All: If you'll look in Platform::getWorkingDirectory(), around line 553, you'll see that we're setting the working directory ourselves. This is specifically there to work around working dir strangeness with Xcode and the Finder.
I tried to reproduce the bug using testFileDelete() from the console in a debug build, run both from Xcode and from the Finder. Both times I was able to delete arbitrary files, using relative paths or using absolute paths. So, basically, I cannot reproduce this bug, using stock 1.4.0u. There were no changes at all in engine/platformMacCarb/ between 1.4.0 and 1.4.0u, so 1.4.0 will also work correctly.
My guess is that you're using a release candidate version of 1.4 . I think there were working dir probs up until 1.4.0.
You'll also see working dir probs if you are building a command line tool, instead of a macosx bundled application.
See this thread for a fix for command line tool working directory problems.
@Gonzo: Check the version of TGE you're using, be sure it's at least 1.4.0 .
Share and Enjoy.
/Paul
#10
The version I'm working with is 1.3.0. The project has been in the works since 2004 and I have done many an engine modification to get features that TGE does not come with in it's stock form. We tried at one point to port into 1.4.0 and found that there had been to many changes that directly clashed with the modifications I had done to our engine so we have had to stick it out with what we are running.
Thanks for your input and insights
Gonzo
03/14/2006 (8:51 pm)
PaulThe version I'm working with is 1.3.0. The project has been in the works since 2004 and I have done many an engine modification to get features that TGE does not come with in it's stock form. We tried at one point to port into 1.4.0 and found that there had been to many changes that directly clashed with the modifications I had done to our engine so we have had to stick it out with what we are running.
Thanks for your input and insights
Gonzo
#11
There will be some conflicts, that will require special porting. You'll need to disable the new font code, and use the old font code, for example. There are a few new methods in the Platform:: namespace that you'll need to comment out.
The bug fixes and improvements in the newer platform code is well worth a couple of days of back-porting. I really recommend you give porting up to at least the new platform layer a whirl.
/Paul
03/16/2006 (5:58 pm)
I highly recommend using at least the mac platform layer from 1.4 . There will be some conflicts, that will require special porting. You'll need to disable the new font code, and use the old font code, for example. There are a few new methods in the Platform:: namespace that you'll need to comment out.
The bug fixes and improvements in the newer platform code is well worth a couple of days of back-porting. I really recommend you give porting up to at least the new platform layer a whirl.
/Paul
Torque Owner Clint S. Brewer
I hope it's not in the mac system and something you can easily fix yourself. good luck, I know bugs like this are a pain. At least you can reproduce it!