Jump to content
System downtime for updates - Sunday 13 July 2025 ×
The Dark Mod Forums

Illegal instruction

WWWWolf

By WWWWolf
in TDM Tech Support

 Share

Recommended Posts

WWWWolf

WWWWolf

Posted
Posted

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?

PranQster

PranQster

Posted
Posted (edited)

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

WWWWolf

WWWWolf

Posted
  • Author
Posted

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

 

Only the upgrade. Now I've done a fresh install too. Didn't help, got the exact same error.

WWWWolf

WWWWolf

Posted
  • Author
Posted

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.

WWWWolf

WWWWolf

Posted
  • Author
Posted

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:)

Tels

Tels

Posted
Posted

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

  • 4 months later...
  • 5 months later...
Yodle

Yodle

Posted
Posted

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.

PranQster

PranQster

Posted
Posted

 

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

Tels

Tels

Posted
Posted 

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

i30817

i30817

Posted
Posted (edited)

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
Yodle

Yodle

Posted
Posted

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)

Tels

Tels

Posted
Posted

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

Yodle

Yodle

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

Tels

Tels

Posted
Posted

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

Tels

Tels

Posted
Posted

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

Tels

Tels

Posted
Posted

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

Yodle

Yodle

Posted
Posted

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

MoroseTroll

MoroseTroll

Posted
Posted

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?

Tels

Tels

Posted
Posted

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

MoroseTroll

MoroseTroll

Posted
Posted

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.

Tels

Tels

Posted
Posted

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

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.

×
 Share
Go to topic listing

  • Recent Status Updates

    • JackFarmer

      JackFarmer

      "The Year of the Rat." 
      😄

      Al Stewart must be proud of you!
      Happy testing!
      @MirceaKitsune
      · 1 reply
    • datiswous

      datiswous

      I posted about it before, but I think the default tdm logo video looks outdated. For a (i.m.o.) better looking version, you can download the pk4 attached to this post and plonk it in your tdm root folder. Every mission that starts with the tdm logo then starts with the better looking one. Try for example mission COS1 Pearls and Swine.
      tdm_logo_video.pk4
      · 2 replies
    • JackFarmer

      JackFarmer

      Kill the bots! (see the "Who is online" bar)
      · 3 replies
    • STiFU

      STiFU

      I finished DOOM - The Dark Ages the other day. It is a decent shooter, but not as great as its predecessors, especially because of the soundtrack.
      · 5 replies
    • JackFarmer

      JackFarmer

      What do you know about a 40 degree day?
      @demagogue
      · 4 replies
×
×
  • Create New...