WWWWolf 0 Posted September 4, 2011 Report Share Posted September 4, 2011 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 ). 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? Quote Link to post Share on other sites
PranQster 457 Posted September 5, 2011 Report Share Posted September 5, 2011 (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 Did you try moving/deleting your darkmod directory and start TDM with a fresh install, or only the upgrade to your older TDM? Edited September 5, 2011 by PranQster Quote System: Mageia Linux Cauldron, aka Mageia 8 Link to post Share on other sites
WWWWolf 0 Posted September 5, 2011 Author Report Share Posted September 5, 2011 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. Quote Link to post Share on other sites
WWWWolf 0 Posted September 5, 2011 Author Report Share Posted September 5, 2011 Disclaimer: I'm a java/scripting guy and not exactly a GDB guru so I have only vague idea of what I'm doing 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. Quote Link to post Share on other sites
WWWWolf 0 Posted September 5, 2011 Author Report Share Posted September 5, 2011 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. ) Quote Link to post Share on other sites
Tels 278 Posted September 5, 2011 Report Share Posted September 5, 2011 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. Quote "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
WWWWolf 0 Posted January 21, 2012 Author Report Share Posted January 21, 2012 OK, I just upgraded to The Dark Mod 1.07. Exact same error messages, I'm afraid. Please, please fix it. Quote Link to post Share on other sites
Yodle 0 Posted July 9, 2012 Report Share Posted July 9, 2012 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. Quote Link to post Share on other sites
PranQster 457 Posted July 9, 2012 Report Share Posted July 9, 2012 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. ) 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 Quote System: Mageia Linux Cauldron, aka Mageia 8 Link to post Share on other sites
Tels 278 Posted July 9, 2012 Report Share Posted July 9, 2012 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 * 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! 2 Quote "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
i30817 24 Posted July 9, 2012 Report Share Posted July 9, 2012 (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 July 9, 2012 by i30817 Quote Link to post Share on other sites
Yodle 0 Posted July 10, 2012 Report Share Posted July 10, 2012 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! 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) Quote Link to post Share on other sites
i30817 24 Posted July 10, 2012 Report Share Posted July 10, 2012 they ARE integrated with the doom 3 code base now. Quote Link to post Share on other sites
Tels 278 Posted July 10, 2012 Report Share Posted July 10, 2012 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. Quote "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
Yodle 0 Posted July 12, 2012 Report Share Posted July 12, 2012 Yes, we integrate the D3 source already. I am confused. I'm running dark mod as a mod to doom 3. Is there another way to run it? Quote Link to post Share on other sites
Yodle 0 Posted July 12, 2012 Report Share Posted July 12, 2012 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. Quote Link to post Share on other sites
Tels 278 Posted July 12, 2012 Report Share Posted July 12, 2012 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) Quote "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
Tels 278 Posted July 12, 2012 Report Share Posted July 12, 2012 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? Quote "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
Tels 278 Posted July 12, 2012 Report Share Posted July 12, 2012 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? Quote "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
Yodle 0 Posted July 12, 2012 Report Share Posted July 12, 2012 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. Quote Link to post Share on other sites
MoroseTroll 24 Posted July 16, 2012 Report Share Posted July 16, 2012 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.cpplocal_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? Quote Link to post Share on other sites
Tels 278 Posted July 16, 2012 Report Share Posted July 16, 2012 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? Quote "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
MoroseTroll 24 Posted July 17, 2012 Report Share Posted July 17, 2012 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. Quote Link to post Share on other sites
Tels 278 Posted July 17, 2012 Report Share Posted July 17, 2012 We do have anonymous SVN access, tho. See if you can checkout https://213.239.221.59/svn/darkmod_src/trunk 1 Quote "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
MoroseTroll 24 Posted July 18, 2012 Report Share Posted July 18, 2012 Sorry, but I haven't managed to get access to the SVN . Am I doing this all right: User is "Anonymous", password is empty? Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.