Processor::init() segfaults (linux)
by Tim Doty · in Torque Game Builder · 03/19/2005 (11:51 am) · 7 replies
Okay, I didn't notice this until now because it wasn't until using the OO resource that I tried to recompile the executable. However, the problem is present in v1.0.0 of the SDK. The debug version works fine, but the release version segfaults upon entry to the Processor::init() function.
Sorry, its been a while since I've used gdb so I can't be as informative as I would like, but AFAICT it is on entry to the function, before doing anything in the function itself.
Platform: SuSE 9.1 (2.6.5-7.147-smp)
Compiler: gcc 3.3.3 (SuSE)
Hardware: 2x AMD AthlonMP 2400 (Gigabyte GA-7DPXDW-P, AMD 762-768 chipset)
I configured the SDK with
I'll keep digging, but I figured someone else could probably sort it out quicker if I let them know.
Sorry, its been a while since I've used gdb so I can't be as informative as I would like, but AFAICT it is on entry to the function, before doing anything in the function itself.
Platform: SuSE 9.1 (2.6.5-7.147-smp)
Compiler: gcc 3.3.3 (SuSE)
Hardware: 2x AMD AthlonMP 2400 (Gigabyte GA-7DPXDW-P, AMD 762-768 chipset)
I configured the SDK with
make -f mk/configure.mk OS=LINUX COMPILER=GCC3 BUILD=RELEASE
I'll keep digging, but I figured someone else could probably sort it out quicker if I let them know.
About the author
#2
03/19/2005 (12:21 pm)
Sorry for the confusion: until I saw where it was segfaulting it didn't occur to me that I hadn't compiled the release version from the vanilla source, just the debug. Through the process of elimination it looks to be the -O2 optimization, or the optimization in combination with one or both of the other flags (inline and omit frame pointer).
#4
03/20/2005 (3:22 pm)
Then its a shame I don't have access to it.
#5
This has also been fixed in Torque 1.4, so it will be updated into T2D when 1.4 is released.
03/20/2005 (3:33 pm)
Reposted from that thread...This has also been fixed in Torque 1.4, so it will be updated into T2D when 1.4 is released.
--- x86UNIXCPUInfo.old.cc 2004-11-15 22:11:32.000000000 -0500
+++ x86UNIXCPUInfo.cc 2004-11-15 22:13:07.000000000 -0500
@@ -29,6 +29,8 @@
static char vendor[13] = {0,};
static U32 properties = 0;
static U32 processor = 0;
+static U32 timeLo;
+static U32 timeHi;
void Processor::init()
{
@@ -55,6 +57,9 @@
Platform::SystemInfo.processor.properties & CPU_PROP_FPU)
{
const U32 MS_INTERVAL = 750;
+#if defined(TORQUE_COMPILER_GCC) && ((__GNUC__ >= 3) && (__GNUC_MINOR__ >= 4))
+ asm ("rdtsc" : "=a" (timeLo), "=d" (timeHi));
+#else
__asm__(
"pushl %eax\n"
"pushl %edx\n"
@@ -64,10 +69,23 @@
"popl %edx\n"
"popl %eax\n"
);
+#endif
U32 ms = Platform::getRealMilliseconds();
while ( Platform::getRealMilliseconds() < ms+MS_INTERVAL )
{ /* empty */ }
ms = Platform::getRealMilliseconds()-ms;
+#if defined(TORQUE_COMPILER_GCC) && ((__GNUC__ >= 3) && (__GNUC_MINOR__ >= 4))
+ asm(
+ "pushl %eax\n"
+ "pushl %edx\n"
+ "rdtsc\n"
+ "sub (timeHi), %edx\n"
+ "sbb (timeLo), %eax\n"
+ "mov %eax, (clockticks)\n"
+ "popl %edx\n"
+ "popl %eax\n"
+ );
+#else
asm(
"pushl %eax\n"
"pushl %edx\n"
@@ -78,6 +96,7 @@
"popl %edx\n"
"popl %eax\n"
);
+#endif
U32 mhz = static_cast<U32>(F32(clockticks) / F32(ms) / 1000.0f);
// catch-22 the timing method used above to calc Mhz is generally
#6
03/20/2005 (3:49 pm)
Thanks!
#7
I never got around to patching because I was using the debug as modified by the OO resource. I noticed that release 1.0.2 doesn't incorporate the fix (presumably Torque 1.4 hasn't been released yet) so I patched it myself and observe the same behavior as previously. So checking version numbers I've got (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) -- so the patch is expecting gcc 3.4+ ? Incidentally, the altered code works with the version of gcc shipped with SuSE.
I don't pretend to be familiar with what SuSE has done with gcc, why they aren't using 3.4, nor do I know why the patch thinks its needs 3.4+ -- but regardless for anyone using SuSE (including a completely patched 9.3) the patch as shown won't help. I may be the only linux user of T2D using SuSE, but just in case someone else is...
05/01/2005 (7:14 pm)
This is just FYI:I never got around to patching because I was using the debug as modified by the OO resource. I noticed that release 1.0.2 doesn't incorporate the fix (presumably Torque 1.4 hasn't been released yet) so I patched it myself and observe the same behavior as previously. So checking version numbers I've got (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) -- so the patch is expecting gcc 3.4+ ? Incidentally, the altered code works with the version of gcc shipped with SuSE.
I don't pretend to be familiar with what SuSE has done with gcc, why they aren't using 3.4, nor do I know why the patch thinks its needs 3.4+ -- but regardless for anyone using SuSE (including a completely patched 9.3) the patch as shown won't help. I may be the only linux user of T2D using SuSE, but just in case someone else is...
Torque Owner Bryan Edds