Illegal instruction on dedicated server & UNIXFileio bug
by Patrik Persson · in Torque Game Engine · 08/24/2002 (12:30 pm) · 7 replies
Two things are going wrong here:
1) I get illegal instructions in the SSE matrix mult functions (i don't know exactly where, i'm not used to debugging with gdb) when i try to run a dedicated server on linux. If i use the inline asm versions of said functions it starts. but..
2) The server is trying to send .wav files with no name when a client connects;
"No such file .wav." and therefore the client never gets into the game. (this is with 1.1.2 and the example fps game)
Oh and by the way.. i've ported the dedicated server to FreeBSD 4.6 and it shows the same behaviour on both linux and fbsd.
Now about the bug. in x86UNIXFileio.cc on line 202 there is a "closedir(dir);" this should have a != null check on the dir variable, otherwise it causes a segmentation fault when it is null (atleast with fbsd).
I hope someone can help me with 1 & 2 above. Any suggestions appriciated.
1) I get illegal instructions in the SSE matrix mult functions (i don't know exactly where, i'm not used to debugging with gdb) when i try to run a dedicated server on linux. If i use the inline asm versions of said functions it starts. but..
2) The server is trying to send .wav files with no name when a client connects;
"No such file .wav." and therefore the client never gets into the game. (this is with 1.1.2 and the example fps game)
Oh and by the way.. i've ported the dedicated server to FreeBSD 4.6 and it shows the same behaviour on both linux and fbsd.
Now about the bug. in x86UNIXFileio.cc on line 202 there is a "closedir(dir);" this should have a != null check on the dir variable, otherwise it causes a segmentation fault when it is null (atleast with fbsd).
I hope someone can help me with 1 & 2 above. Any suggestions appriciated.
#2
08/27/2002 (2:00 pm)
tried on amd xp 1600, p3 600, p3 650, p3 750. same results on all.
#3
I'm assuming that you are using unmodified Release 1.1.2 code, except that you have made the change described in this thread:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=6674
Without this fix the dedicated server in R112 doesn't compile properly.
Is this assumption correct?
Are you connecting with a windows or linux client? Is that client running off the same codebase?
You mention that if you use the inline version of the SSE matrix functions, it works. Are you talking about the SSE_MatrixF_x_MatrixF function in mMathSSE.cc? I don't see how that inline function would even compile under gcc, since it doesn't use gcc asm syntax.
08/27/2002 (7:09 pm)
The fileio problem is definitely a bug and I will fix that. However, I cannot reproduce the crash or the client not being able to get in the game. I do see the "cannot find .wav" messages, but my client is able to connect to the server. I'm assuming that you are using unmodified Release 1.1.2 code, except that you have made the change described in this thread:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=6674
Without this fix the dedicated server in R112 doesn't compile properly.
Is this assumption correct?
Are you connecting with a windows or linux client? Is that client running off the same codebase?
You mention that if you use the inline version of the SSE matrix functions, it works. Are you talking about the SSE_MatrixF_x_MatrixF function in mMathSSE.cc? I don't see how that inline function would even compile under gcc, since it doesn't use gcc asm syntax.
#4
This fixed it for me (resManager.cc line 66):
void ResManager::fileIsMissing(const char *fileName)
{
if (dStrlen(fileName) <= 0)
return;
...
>Is this assumption correct?
Yes almost, see below.
>Are you connecting with a windows or linux client? Is
>that client running off the same codebase?
Windows and yes.
>Are you talking about the SSE_MatrixF_x_MatrixF function in mMathSSE.cc?
That's the one that works (after we made a gcc inline-asm compatible one) and the mMathSSE_ASM.asm one is the one that crashes.
(gdb) where
#0 0x81d6a4c in SSE_MatrixF_x_MatrixF () at math/mathUtils.cc:15
#1 0x82dc3ff in MatrixF::mul (this=0x89bef10, a=@0x89beed0, b=@0xbfbfa84c) at math/mMatrix.h:228
#2 0x8258b6f in TSShape::computeBounds (this=0x89be120, dl=1, bounds=@0x89bdf64) at ts/tsShape.cc:514
#3 0x81405bd in ShapeBaseData::preload (this=0x89bdd40, server=true, errorBuffer=0x8514400 "") at game/shapeBase.cc:210
>I don't see how that inline function would even compile under gcc, since it doesn't use gcc asm syntax.
We rewrote it to work with gcc.
08/28/2002 (7:31 am)
>I do see the "cannot find .wav" messages, but my client >is able to connect to the server. This fixed it for me (resManager.cc line 66):
void ResManager::fileIsMissing(const char *fileName)
{
if (dStrlen(fileName) <= 0)
return;
...
>Is this assumption correct?
Yes almost, see below.
>Are you connecting with a windows or linux client? Is
>that client running off the same codebase?
Windows and yes.
>Are you talking about the SSE_MatrixF_x_MatrixF function in mMathSSE.cc?
That's the one that works (after we made a gcc inline-asm compatible one) and the mMathSSE_ASM.asm one is the one that crashes.
(gdb) where
#0 0x81d6a4c in SSE_MatrixF_x_MatrixF () at math/mathUtils.cc:15
#1 0x82dc3ff in MatrixF::mul (this=0x89bef10, a=@0x89beed0, b=@0xbfbfa84c) at math/mMatrix.h:228
#2 0x8258b6f in TSShape::computeBounds (this=0x89be120, dl=1, bounds=@0x89bdf64) at ts/tsShape.cc:514
#3 0x81405bd in ShapeBaseData::preload (this=0x89bdd40, server=true, errorBuffer=0x8514400 "") at game/shapeBase.cc:210
>I don't see how that inline function would even compile under gcc, since it doesn't use gcc asm syntax.
We rewrote it to work with gcc.
#5
I'm leaving for vacation today and won't be back until 9/9; unfortunately I don't have any time to look in to this before I leave, but I'll follow up when I get back.
08/28/2002 (9:15 am)
For the nasm SSE function, I noticed that it doesn't do the normal push/pop for register saving as required by the i386 spec. You might try taking the prologue and epilogue macros from blender_asm.asm, and call them at the beginning and end of the function, to see if that prevents the crash.I'm leaving for vacation today and won't be back until 9/9; unfortunately I don't have any time to look in to this before I leave, but I'll follow up when I get back.
#6
08/28/2002 (1:51 pm)
pushing and poping didn't fix it :(
#7
01/13/2003 (10:10 am)
What kernel version are you using on your linux system? We've discovered that torque in its current state may be incompatible with some or all 2.2 kernels... 
Torque Owner John Quigley