Jump to content
The Dark Mod Forums

Illegal instruction


Recommended Posts

Hello,

 

I was able to run TDM demos and 1.0 just fine back in the day, but never really had time to play TDM. (Sorry.) But now, I decided to blow the dust off, upgrade TDM to the latest version, and enjoy the new versions.

 

Only TDM doesn't run at all nowadays. I get the loading screen, after which the game shuts down. For the record, other Doom 3 mods seem to work just fine.

 

I'm on Linux. Here's what the log says:

 

-------------------------------
using ARB_vertex_buffer_object memory
using ARB2 renderSystem
found DLL in pak file: /home/wwwwolf/.doom3/darkmod/tdm_game02.pk4/gamex86.so
copy gamex86.so to /home/wwwwolf/.doom3/darkmod/gamex86.so
Found AMD CPU, features: MMX SSE CMOV
game using generic code for SIMD processing.
--------- Initializing Game ----------
The Dark Mod 1.06, code revision 4890
Build date: Jun 15 2011
Initializing event system
...767 event definitions
Initializing class hierarchy
...165 classes, 736320 bytes for event callbacks
Initializing scripts
signal caught: Illegal instruction
si_code 2
Trying to exit gracefully..
--------- Game Map Shutdown ----------
--------------------------------------

 

Now, admittedly I'm using a bit old computer with Athlon XP 3000+ processor, which doesn't do this newfangled SSE2 thing - has never stopped it from running Doom 3 fairly adequately, of course. I'm starting to getting used to seeing "Illegal instruction" - I've been seeing that due to some new applications that use SSE2 code without sniffing that the processor is actually capable of doing SSE2 (because having the application crash is much more polite than actually telling the user to go out and buy a new computer :laugh:). But Doom 3 is apparently properly detecting that the processor doesn't have SSE2 so it won't try any weird SSE2 hokerypokery. So I have no idea what's going on. Is there some weird SSE2ery happening where none should be happening?

 

Is there anything that can be done to get the game running again?

Link to post
Share on other sites

I'm surprised (am I really?) that M$ has not changed "Illegal Instruction" error to something more sane, like "Invalid Instruction", after all these years.

DOH!. You said you're on Linux (I should have looked in your quoted code block to see your /home/* path), LOL. Didn't know we had "Illegal Instruction" errors blush.gif

 

Did you try moving/deleting your darkmod directory and start TDM with a fresh install, or only the upgrade to your older TDM?

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to post
Share on other sites

Disclaimer: I'm a java/scripting guy and not exactly a GDB guru so I have only vague idea of what I'm doing :laugh:

 

Anyway, I attached gdb on the running doom.x86 executable. Since the Doom 3 is launched via a script and not a genuine executable thingy, I actually 1) launched the plain ol' Doom 3, 2) attached the debugger, then 3) went to Mods, selected TDM, and 4) let it load and crash. (Since TDM doesn't need weird startup parameters, launching TDM via the mods menu has generally worked in the past, as far as I can recall...)

 

And here's what gdm said about this. Doom 3 kept producing output right up until "Initializing scripts". Then went crazy:

 

Program received signal SIGILL, Illegal instruction.
[switching to Thread 0xb74478e0 (LWP 20020)]
0xb2cb44f9 in idParser::UnreadSourceToken ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so

 

And then I backtraced it:

 

(gdb) bt
#0 0xb2cb44f9 in idParser::UnreadSourceToken ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so
#1 0xb298978e in idCompiler::CompileFile ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so
#2 0xb2999298 in T.1826 () from /home/wwwwolf/.doom3/darkmod/gamex86.so
#3 0xb2999686 in idProgram::CompileFile ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so
#4 0xb299abd4 in idProgram::Startup ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so
#5 0xb27ce0dd in idGameLocal::Init ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so
#6 0x08055d03 in ?? ()
#7 0x0805e04b in ?? ()
#8 0x0805e5b1 in ?? ()
#9 0x08051f38 in ?? ()
#10 0x0805215e in ?? ()
#11 0x08090713 in ?? ()
#12 0x0805830e in ?? ()
#13 0x082a066d in ?? ()
#14 0xb7480e46 in __libc_start_main ()
from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#15 0x0804c071 in ?? ()

 

So The Dark Mod's gamex86.so appears to crash while parsing the game scripts. Or something like that.

Link to post
Share on other sites

Further clueless elaboration (or "in which this guy who has last programmed anything in assembly in Commodore 64 days discovers the 'disassemble' command in GDB"):

 

Program received signal SIGILL, Illegal instruction.
[switching to Thread 0xb72f98e0 (LWP 20758)]
0xb29654f9 in idParser::UnreadSourceToken ()
from /home/wwwwolf/.doom3/darkmod/gamex86.so

 

OK, I told gdb to disassemble it, and this is what the thing says around that memory location:

 

0xb29654f3 <_ZN8idParser17UnreadSourceTokenEP7idToken+195>: 	mov	0x34(%ebp
),%eax
0xb29654f6 <_ZN8idParser17UnreadSourceTokenEP7idToken+198>: 	mov	%eax,0x34
(%edx)
0xb29654f9 <_ZN8idParser17UnreadSourceTokenEP7idToken+201>: 	movsd 0x38(%ebp),%xmm0
0xb29654fe <_ZN8idParser17UnreadSourceTokenEP7idToken+206>: 	movsd %xmm0,0x38(%edx)
0xb2965503 <_ZN8idParser17UnreadSourceTokenEP7idToken+211>: 	mov	0x40(%ebp),%eax
0xb2965506 <_ZN8idParser17UnreadSourceTokenEP7idToken+214>: 	mov	%eax,0x40(%edx)

 

Looking at Wikipedia's article on x86 instructions, yep, movsd appears to be one of the SSE2 SIMD instructions. (I have no idea what "%xmm0" is. Any processors with more than just A, X and Y registers scare the hell out of me. :laugh:)

Link to post
Share on other sites

I had change the CPU detection and the detection for SSE etc, but AFAIK,linux does still not actually use these instructions, so I am unsure why it would crash.

 

Can make you in a few days a newly-comiled .so file which disables the check, maybe it helps. But can't do this today or tomorrow, sorry.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites
  • 4 months later...
  • 5 months later...

For what it's worth, this error still exists. Installing the software onto an Ubuntu 12.04 system with an Athlon XP 3200+ (32-bit Barton) works fine, but execution of the program halts as WWWWolf described. I am pretty sure WWWWolf's analysis is correct and the binary's trying to use SSE2 instructions when it shouldn't (on a CPU that doesn't have them).

 

The Dark Mod runs fine on the exact same hardware running on Windows XP. Doom3 itself runs fine on both Linux and XP on this machine.

 

I hope that helps.

Link to post
Share on other sites

 

0xb29654f3 <_ZN8idParser17UnreadSourceTokenEP7idToken+195>: 	mov	0x34(%ebp
),%eax
0xb29654f6 <_ZN8idParser17UnreadSourceTokenEP7idToken+198>: 	mov	%eax,0x34
(%edx)
0xb29654f9 <_ZN8idParser17UnreadSourceTokenEP7idToken+201>: 	movsd 0x38(%ebp),%xmm0
0xb29654fe <_ZN8idParser17UnreadSourceTokenEP7idToken+206>: 	movsd %xmm0,0x38(%edx)
0xb2965503 <_ZN8idParser17UnreadSourceTokenEP7idToken+211>: 	mov	0x40(%ebp),%eax
0xb2965506 <_ZN8idParser17UnreadSourceTokenEP7idToken+214>: 	mov	%eax,0x40(%edx)

 

Looking at Wikipedia's article on x86 instructions, yep, movsd appears to be one of the SSE2 SIMD instructions. (I have no idea what "%xmm0" is. Any processors with more than just A, X and Y registers scare the hell out of me. laugh.gif)

 

Looking at that code block, it appears that %xmm0 is audio related, since it is in there among the %eax stuff. I know that xmms isn't used much anymore with modern linux distros, but perhaps TDM is trying to use it instead of ALSA.

I'd start with checking the audio drivers in the cfg file.

This is what I have in ~/.doom3/darkmod/DoomConfig.cfg :

 

seta s_libOpenAL "openal32.dll"
seta s_numberOfSpeakers "6"
seta s_doorDistanceAdd "450"
seta s_globalFraction "0.8"
seta s_subFraction "0.75"
seta s_playDefaultSound "1"
seta s_volume_dB "-4.444445"
seta s_meterTopTime "2000"
seta s_reverse "0"
seta s_spatializationDecay "2"
seta s_maxSoundsPerShader "0"
seta s_dsp "/dev/dsp1"
seta s_driver "alsa"
seta s_alsa_lib "libasound.so.2"
seta s_alsa_pcm "surround51:CARD=halo,DEV=0"

That last line will certainly differ unless you happen to use an HD Omega Halo series sound card. Also, your audio device is likely to be /dev/dsp , not /dev/dsp1

System: Mageia Linux Cauldron, aka Mageia 8

Link to post
Share on other sites

0xb29654f3 <_ZN8idParser17UnreadSourceTokenEP7idToken+195>:	 mov	 0x34(%ebp
),%eax
0xb29654f6 <_ZN8idParser17UnreadSourceTokenEP7idToken+198>:	 mov	 %eax,0x34
(%edx)
0xb29654f9 <_ZN8idParser17UnreadSourceTokenEP7idToken+201>:	 movsd 0x38(%ebp),%xmm0
0xb29654fe <_ZN8idParser17UnreadSourceTokenEP7idToken+206>:	 movsd %xmm0,0x38(%edx)
0xb2965503 <_ZN8idParser17UnreadSourceTokenEP7idToken+211>:	 mov	 0x40(%ebp),%eax
0xb2965506 <_ZN8idParser17UnreadSourceTokenEP7idToken+214>:	 mov	 %eax,0x40(%edx)

 

Looking at that code block, it appears that %xmm0 is audio related, since it is in there among the %eax stuff. I know that xmms isn't used much anymore with modern linux distros, but perhaps TDM is trying to use it instead of ALSA.

 

This is, frankly, such utter nonsense that I am not sure if you are serious, or pulling our legs :huh:

 

* The register is named "EAX" because it is the Extended AX register (a 32bit variant of the 16bit register AX, which is in itself two 8 bit registers named "AH" (high) and "AL" (low). Note that there is also EBX, etc. See: https://en.wikipedia...wiki/X86#32-bit

* XMM0 is the zeroth XMM register. See: https://en.wikipedia.org/wiki/SSE2

 

There is nothing in that disassemble that hints at audio processing at all.

 

As for the crash, I am not sure why the compiler emits SSE2 instructions, these appear in the idParser, and sadly, there is no-one left who could investigate this and/or do something about it. Sorry! :wacko:

  • Like 2

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

when it was compiled, it didn't disable sse.

./configure --disable-sse3 --disable-sse2

 

btw, i suspect the same thing happens in that crash some people with 32 bit computers are seeing with screenshots.

 

You could 'fix' this by having a 32 bit and 64 bit executable (i think all 86_64 bit computers all have SSE1-3) and compiling the 32 bit version without anything except SSE (which is part of the minimum requirements of the doom3 cpu i guess? Not sure)

Edited by i30817
Link to post
Share on other sites

As for the crash, I am not sure why the compiler emits SSE2 instructions, these appear in the idParser, and sadly, there is no-one left who could investigate this and/or do something about it. Sorry! :wacko:

I hear you. I wanted to actually look at the code and provide a fix before commenting, but I'm pretty busy and I'm not sure when I will have time. If you guys really don't have anybody working on Linux right now maybe I should make that a priority. What platforms are the current devs working on?

 

I really think i30817 is right and it's a matter of disabling those instructions at build time. While he's got a good idea, I'd go further than he did and say that you can just disable sse2 arbitrarily, rather than making a separate 64-bit executable. I pretty strongly suspect that having sse2 instructions in there won't make much difference in terms of performance. (in the renderer or something else in doom3 would be a different story, but that's not a concern until you're integrated with the doom3 codebase)

Link to post
Share on other sites

Yes, we integrate the D3 source already. And no, we are not able to build 64bit anyway, it is strictly 32bit.

 

Technically, we could build without SS2, but who knows what breaks then. What we can do, tho, is to try to build an extra executable and .so for 32-with-out-ss2 (if that is even possible with scons) and give it to people who need it. I don't know if there is anybody who could do this kind of work, tho.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites
Technically, we could build without SS2, but who knows what breaks then. What we can do, tho, is to try to build an extra executable and .so for 32-with-out-ss2 (if that is even possible with scons) and give it to people who need it. I don't know if there is anybody who could do this kind of work, tho.

You don't have this problem with the Windows binary (I know this because I can start dark mod on Windows on my XP 3200+ system without crashing) so you're either not using SSE2 instructions on Windows or you are using a separate code path for the different instruction sets.

Link to post
Share on other sites

I am confused. I'm running dark mod as a mod to doom 3. Is there another way to run it?

 

Sorry for the confusion, the integrated source code of D3 and TDM means that from v1.08 (not yet released!) onwards we will not only supply a .dll (or .so on Linux), but also a .exe (or .x86 on Linux again).

 

Technically, this means you can run TDM stand-alone, e.g. w/o D3 at all. Practically, tho, there are a few key assets (the zombie, a skeleton, some heads, some sounds etc, see here for a list http://wiki.thedarkm..._standalone_TDM ) missing. This means you can start TDM, load the menu, and even load and play some missions, but not everything looks right and some missions outright crash. So for the time being, TDM will still require D3 - even tho technically under the hood it is no longer really a "mod" of D3.

 

For generation facebook: TDM changed its relationship status from "In relation with D3" to "It's complicated."

 

For v.107 everything remains the same.

 

SSE2 on Windows/Linux:

 

Windows and Linux use totally different compilers and even build setups, so they will build completely different things. So it is possible that the windows compiler does not add SSE2 instructions, but gcc does.

 

In addition, there are additional SSE (and SSE2 and so on) modules, which are loaded on demand and can optimize some things in the game. However, this only really worrks in Windows. In Linux I fixed the detection of the capabilities, but the actual code path for SSE etc is not existing. So the only place where linux might use SSE2 is when the gcc decides to optimize things. I *think* we might prevent this, but as I said, we really do no longer have anyone who could look into this.

 

(No, just because I post often and long posts here doesn't mean I have the time or skills to do that. Sorry)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Just for reference:

 

This page has this: https://bitbucket.org/paniq/armstrong/issue/10/scons-warning-building-from-mercurial

 

if env['SSE2'] == True:
	if not x86_64:
		env.Append(CCFLAGS=[
			'-march=i686', 
		])
	env.Append(CCFLAGS=[
		'-mfpmath=sse',
		'-msse2',
	])

 

So it seems you need to add -msse2, but we are only using:

 

OPTCPPFLAGS = [ '-O3', '-march=pentium3', '-ffast-math', '-fno-unsafe-math-optimizations', '-fomit-frame-pointer' ]

 

Not sure where this would add SSE2, maybe it is the -march setting?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Further info: I have tracked this issue here: http://bugs.angua.at/view.php?id=3177

 

One idea might be that idParser is in the code compiled by id software - but since we now compile our own executable, it maybe already works. Once v1.08 is ready for beta testing, would one of the affected people be willing to do some tests and see if the issue is already gone or persist?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

I'd be happy to do some testing!

 

I hope to actually dig into your code at some point (I think it's totally awesome that you guys are open source!) but I can't make it happen this week. I have some experience with C and C++ but I'm not familiar with scons yet. As for the gcc flags... I've struggled with that in the past and I'll have to take a look. They're sometimes counterintuitive. :D

Link to post
Share on other sites

I've made a search for the "SSE2" string and found that this file "sys\scons\SConscript.idlib" contains at lines 102..103 something interesting:

# greebo: Need SSE2 instruction set to compile simd_sse2.cpp

local_env.Append(CPPFLAGS = '-msse2')

Could those be the root of the SSE2-problem WWWWolf and Yodle have been encountered with?

BTW, if there will some problem to rebuild non-SSE2 gamex86.so, I can patch it manually - by replacing the SSE2 code with its SSE1 equivalent. Does anybody want it?

Link to post
Share on other sites

I've made a search for the "SSE2" string and found that this file "sys\scons\SConscript.idlib" contains at lines 102..103 something interesting:Could those be the root of the SSE2-problem WWWWolf and Yodle have been encountered with?

 

Could be. Technically this flag should only be used for these modules, but the way scons works it might apply it for every code and then do some smart optimizations. But I am not sure.

 

BTW, if there will some problem to rebuild non-SSE2 gamex86.so, I can patch it manually - by replacing the SSE2 code with its SSE1 equivalent. Does anybody want it?

 

Maybe it would be better if you check out our SVN and fiddle with it?

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

1) You see, I'm no Linux user at all :).

2) I have no access to the TDM SVN.

So, if somebody wants to try my patched gamex86.so v1.07, be my guest, but you should know that there are no warranty comes with this file at all. Heck, I'm even not sure that my gamex86.so will run, because I've patched it in Windows, and due to this fact it can omit some Linux attribute or something.

Link to post
Share on other sites

We do have anonymous SVN access, tho. See if you can checkout https://213.239.221.59/svn/darkmod_src/trunk

  • Like 1

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...