Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: portej05 on July 24, 2009, 03:55:39 am
-
This is Antipodes build #1
Antipodes is a staging ground for changes that will eventually make their way into trunk. Antipodes should not be considered stable.
About this build:
This build incorporates Trunk to 5485 and has had safe_strings applied across the entire codebase to any statically declared array.
There are approximately 1000 new uses of the safe_strings code.
Buffers declared dynamically have, for the most part, been left alone. There have been two changes to make dynamic buffers in scripting.cpp use safe_strings.
This build will pick up if you're overrunning a static buffer (or one of the changed dynamic buffers).
Any safe_strings errors should be reported!
Thanks, portej05.
EDIT: Updated filenames
Antipodes (normal):
FSO:
fs2_ant_1d - Debug (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fs2_ant_1d.exe)
fs2_ant_1r - Release (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fs2_ant_1r.exe)
FRED2:
fred2_ant_1d - Debug (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fred2_ant_1d.exe)
fred2_ant_1r - Release (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fred2_ant_1r.exe)
Antipodes (INF):
FSO:
fs2_ant_1d_INF - Debug (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fs2_ant_1d_INF.exe)
fs2_ant_1r_INF - Release (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fs2_ant_1r_INF.exe)
FRED2:
fred2_ant_1d_INF - Debug (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fred2_ant_1d_INF.exe)
fred2_ant_1r_INF - Release (http://porteous.no-ip.org/FS2Files/Antipodes/Antipodes1/fred2_ant_1r_INF.exe)
-
And OS X builds for those interested:
FS2_Open Antipodes 1 (http://members.iinet.net.au/~tjkidd/fs2open/build/mac/FS2_Open%20Antipodes%201.zip) (includes Release and Debug builds)
-
portej: Combine the FSO and FRED into one ZIP with the INF EXE and FRED into another ZIP.
Saves space, links and is less cumbersome.
I'd like to make some Antipodes Icons to have the exes show, any objection?
-
I'd like to make some Antipodes Icons to have the exes show, any objection?
None whatsoever.
-
Curious, what do you use to make the icons?
-
Curious, what do you use to make the icons?
stubby crayons
-
Heh. That would actually look really cool if I scanned them right. Or hell, I'll just draw on the scanner glass.
Failing that, Photoshop with an ICO format plug-in.
Oh, right. Actual reporting: So, my first run on regular shows nearly equivalent to SSE builds in terms of performance, and no anomalous behavior that I can accredit to the exe.
-
Zacam, I'd already pointed out to him on IRC that a 7z of the full set is smaller than any individual exe :)
-
Yeah, but I figured here would help too. Less likely to forget a static post that won't go anywhere. :D
-
Don't worry folks, message received :P
The next build will be done like that.
-
i'm getting error with the two antipodes build with my mod for now :
Assert: 0
File: safe_strings.cpp
Line: 70
ERANGE: String error @ c:\users\hery\desktop\fs2_open\code\cfile\cfilesystem.cpp (570). Please Report
Trying to put into 32 byte buffer:
MetalBrossMaterial-littledark.dds
ntdll.dll! NtWaitForSingleObject + 21 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
fs2_open_3_6_11d.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
Tha't s a 256*256 dds texture for now and i wonder why i got an error with it?
-
Filename too long, I'd guess.
-
Ok that was the problem (dropbox conflict was another source of problem too)
-
Also, any texture basename should probably not have hyphens in it. Those are normally used when denoting a texture as a normal, shine, etc with *-normal, *-shine, respectively. That's also a concern when naming textures because -normal takes up 7 characters in the 32 char filename buffer, the extension takes up 4, the null terminator takes up one, so you're only left with 20 for a texture base name if it might ever have a shine, normal, etc counterpart.
-
Ok, something odd went on for Mac OS X and the Debug builds.
- Testing Antipodes 1 Debug build, everything works fine.
- However, due to a change occurring between r5491 and r5493 in trunk - which should just be the Antipodes 1 changes - Debug builds (using standard mediavp data and the same install) now opens and then closes rapidly, with the fs2_open.log looking like this:
==========================================================================
DEBUG SPEW: No debug_filter.cfg found, so only general, error, and warning
categories can be shown and no debug_filter.cfg info will be saved.
==========================================================================
Opened log '/Users/rhyskidd/Library/FS2_Open/data/fs2_open.log', Sun Aug 23 20:11:57 2009 ...
FreeSpace version: 3.6.11
Passed cmdline options:
<none>
Funny thing is that all Retail builds since r5493 work fine on Mac OS X (hence why it hasn't been noticed until now).
-
OK, 5492 is the commit that's most likely to have caused this (5491 is restrict semantics - not actually used anywhere set, 5493 is REMOVING some instances of safe_strings)
Will update here if I find anything
E9: I'm assuming it was a crash, but got any ideas where?
I've checked cmdline.cpp and the only changes from 5491 in there were to linux builds only.
-
Yup, I'm sure it's caused by something in r5492 - it's just r5493 with the small changes is the first that builds successfully with GCC.
$ gdb FS2_Open\ r5493\ \(debug\).app/
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ................. done
(gdb) r
Starting program: /Applications/Freespace 2 Open/FS2_Open r5493 (debug).app/Contents/MacOS/FS2_Open (debug)
Reading symbols for shared libraries +++++++++++++++............................................................................... done
Reading symbols for shared libraries .. done
Future debug output directed to: /Users/xxxx/Library/FS2_Open/data/fs2_open.log
Error: "FreeSpace2/Fred2 cannot be run from a drive root directory!"
Program exited with code 01.
(gdb)
So it looks like the code around cfile.cpp:183 is being hit, and cfile_init() gets called at freespace.cpp:1973. I looked earlier at the code block peculiar to OS X between freespace.cpp:1953-1963, especially what's being done by safe_strings functions to char whee[MAX_PATH_LEN]. Your thoughts on that?
-
It wouldn't be getting as far as cfile_init if it was a safe_strings issue.
That strncpy(whee, full_path, MAX_PATH_LEN-1); should probably be strcpy_s(whee, full_path) (there's a lot of places this could be done).
cfile_in_root_dir is a bit hacky...
Is it possible to get the contents of the variables passed to cfile_init?
-
Using this applied patch:
Index: code/cfile/cfile.cpp
===================================================================
--- code/cfile/cfile.cpp (revision 5532)
+++ code/cfile/cfile.cpp (working copy)
@@ -164,6 +164,8 @@
//
int cfile_init(char *exe_dir, char *cdrom_dir)
{
+ mprintf(( "cfile_int(): exe_dir '%s'\n", exe_dir ));
+ mprintf(( "cfile_int(): cdrom_dir '%s'\n", cdrom_dir ));
int i;
// initialize encryption
...a Debug run causes fs2_open.log to looks like this:
==========================================================================
DEBUG SPEW: No debug_filter.cfg found, so only general, error, and warning
categories can be shown and no debug_filter.cfg info will be saved.
==========================================================================
Opened log '/Users/xxxxx/Library/FS2_Open/data/fs2_open.log', Mon Aug 24 23:10:51 2009 ...
FreeSpace version: 3.6.11
Passed cmdline options:
<none>
cfile_int(): exe_dir 'fs2.exe'
cfile_int(): cdrom_dir '(null)'
-
That's a little weird, gotta say fs2.exe?
It's also why it thinks it's in a root directory.
We probably need to figure out why this is the case :P
-
I'd say that strncpy() followed by a strcat_s() is playing up:
Index: code/cfile/cfile.cpp
===================================================================
--- code/cfile/cfile.cpp (revision 5532)
+++ code/cfile/cfile.cpp (working copy)
@@ -164,6 +164,8 @@
//
int cfile_init(char *exe_dir, char *cdrom_dir)
{
+ mprintf(( "cfile_int(): exe_dir '%s'\n", exe_dir ));
+ mprintf(( "cfile_int(): cdrom_dir '%s'\n", cdrom_dir ));
int i;
// initialize encryption
Index: code/freespace2/freespace.cpp
===================================================================
--- code/freespace2/freespace.cpp (revision 5532)
+++ code/freespace2/freespace.cpp (working copy)
@@ -1951,6 +1951,7 @@
#endif
#ifdef APPLE_APP
+ mprintf(( "game_init(): full_path '%s'\n", full_path ));
// some OSX hackery to drop us out of the APP the binary is run from
char *c = NULL;
c = strstr(full_path, ".app");
@@ -1961,11 +1962,14 @@
*c = '\0';
}
strncpy(whee, full_path, MAX_PATH_LEN-1);
+ mprintf(( "game_init(): whee 1 '%s'\n", whee ));
#else
GetCurrentDirectory(MAX_PATH_LEN-1, whee);
#endif
strcat_s(whee, DIR_SEPARATOR_STR);
+ mprintf(( "game_init(): whee 2 '%s'\n", whee ));
strcat_s(whee, EXE_FNAME);
+ mprintf(( "game_init(): whee 3 '%s'\n", whee ));
//Initialize the libraries
s1 = timer_get_milliseconds();
fs2_open.log
==========================================================================
DEBUG SPEW: No debug_filter.cfg found, so only general, error, and warning
categories can be shown and no debug_filter.cfg info will be saved.
==========================================================================
Opened log '/Users/rhyskidd/Library/FS2_Open/data/fs2_open.log', Tue Aug 25 00:07:58 2009 ...
FreeSpace version: 3.6.11
Passed cmdline options:
<none>
game_init(): full_path '/Applications/Freespace 2 Open'
game_init(): whee 1 '/Applications/Freespace 2 Open'
game_init(): whee 2 '/'
game_init(): whee 3 'fs2.exe'
cfile_int(): exe_dir 'fs2.exe'
cfile_int(): cdrom_dir '(null)'
... and yes, it does seem a little contrived that we add EXE_FNAME ("fs2.exe") to the path string on ALL platforms.
-
Found it:
Line 100 of safe_strings.h
#define strcpy_s( ... ) scp_strcpy_s( __FILE__, __LINE__, __VA_ARGS__ )
#define strcat_s( ... ) scp_strcpy_s( __FILE__, __LINE__, __VA_ARGS__ )
should be
#define strcpy_s( ... ) scp_strcpy_s( __FILE__, __LINE__, __VA_ARGS__ )
#define strcat_s( ... ) scp_strcat_s( __FILE__, __LINE__, __VA_ARGS__ )
This wasn't caught in Antipodes #1 for some reason (it really is ifdef hell in there - can we stop supporting VC6 at some point? :P ).
(I'm not on a fast enough connection to update/commit atm, can someone else do it?)
-
I thought that was fixed a while back, was this screwed up in more than one place?
Anyway, committed.
-
Updated to revision 5534.
I can confirm it is fixored. :)
-
I thought that was fixed a while back, was this screwed up in more than one place?
Anyway, committed.
Me too, me too.