Game Development Community

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
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.

#1
03/19/2005 (12:13 pm)
So you don't think it's a problem with the OO script resource then? I'll see what develops with this thread before I look into it much further.
#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).
#3
03/20/2005 (2:19 pm)
This is the thread you need to fix this issue.
#4
03/20/2005 (3:22 pm)
Then its a shame I don't have access to it.
#5
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
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...