TGEA 1.8.1 - Seeking in a file can erroneously assert in debug mode
by Konrad Kiss · in Torque Game Engine Advanced · 02/14/2009 (10:44 am) · 2 replies
First of all, Atlas source files are not added to the Example template project in 1.8.1 (tested with VC 2008 only). I'm not sure if this was mentioned already or not.
I've found the below bug through Atlas, but it could cause problems at other places where seeking to a position in a file is required.
File::setPosition(S32 position, bool absolutePos) in platformWin32/winFileIO.cpp asserts in debug mode, when Atlas uses it to seek into a very large file.
When Atlas passes an unsigned variable for absolute position, and it is big enough to use the sign bit for an S32, while the setPosition function is expecting a signed variable, it asserts with "File::setPosition: negative absolute position".
This is done basically everywhere where Atlas needs this functionality... atlasChunk.cpp, atlasDeferredIO.cpp, atlasFile.cpp, and other places I didn't check.
All in all, I think that assert has a better chance of firing during a normal operation than a true negative absolute position.
A good solution would be to handle relative seeking separately, but I was lazy to scan the entire TGEA source for file seeks.. hehe.. so I just threw that assert out.
This has been there in 1.7.1 as well, I don't know about previous versions.
I've found the below bug through Atlas, but it could cause problems at other places where seeking to a position in a file is required.
File::setPosition(S32 position, bool absolutePos) in platformWin32/winFileIO.cpp asserts in debug mode, when Atlas uses it to seek into a very large file.
When Atlas passes an unsigned variable for absolute position, and it is big enough to use the sign bit for an S32, while the setPosition function is expecting a signed variable, it asserts with "File::setPosition: negative absolute position".
This is done basically everywhere where Atlas needs this functionality... atlasChunk.cpp, atlasDeferredIO.cpp, atlasFile.cpp, and other places I didn't check.
All in all, I think that assert has a better chance of firing during a normal operation than a true negative absolute position.
A good solution would be to handle relative seeking separately, but I was lazy to scan the entire TGEA source for file seeks.. hehe.. so I just threw that assert out.
This has been there in 1.7.1 as well, I don't know about previous versions.
About the author
http://about.me/konrad.kiss
#2
About the sign bit, you're right, still, I did have such a file, and that seemed to be the only problem to make that Atlas map work. So I guess that's good news. :)
On the other hand, sending U32s to a function that expects an S32 by function (relative positioning) is not good imho, so thanks for sending that one over.
02/14/2009 (12:07 pm)
@Alex: Sorry for mentioning the Atlas files, I wasn't aware of that thread.About the sign bit, you're right, still, I did have such a file, and that seemed to be the only problem to make that Atlas map work. So I guess that's good news. :)
On the other hand, sending U32s to a function that expects an S32 by function (relative positioning) is not good imho, so thanks for sending that one over.
Associate Alex Scarborough
The sign bit won't be used until you're trying to seek more than two billion bytes into the file. If you have a file that is larger than 2GB that you're trying to seek into I am of the opinion that you have larger issues than that Assert (no pun intended). That being said I'll bounce this to the Torque 3D team, but I suspect that it's going to be very low priority.