64 bit linux compiled - Runtime crashes

[Crinkelite]

First I'd like to apologise for my lack of contribution in this forum in the last few months

I am grateful to Hamlet and Nightstalker and many others for their efforts to get the linux version compiling and running.

 

I would have liked to have provided more help but I'm a complete amateur with no formal training and it seems like every time I tried to write something contributory, I found I was unsure of what I was trying to say or lacking in basic understanding.

For these reasons, I decided to remain silent rather than muddy the waters.

 

Ok with that out of the way I'll explain my current problem.

 

I'm still having trouble getting things working on 64-bit linux. (Currently -r6775)

It compiles fine but crashes out at runtime with an error which I believe to be something to do with libboost_filesystem.a

I've attached The full gdb session log as `gdb-packaged-libs.log.txt`

 

After faffing around for days wondering what it could all mean, I decided to obtain the Boost source and compile my own 32 bit libraries.

I placed the files in /usr/lib32/ and made the necessary edits to the scons files.

 

Miraculously, I had caught a break and the game compiled and ran without issue... Or so I thought.

 

I've now discovered that pressing the lean key causes the game to crash. I have posted the record of the gdb session in the attached file "gdb-system-libs.log.txt"

 

A backtrace reveals that a problem develops after the call to idCollisionModelManagerLocal::Rotation() (frame 5)

 

I have also done an `info args` and an `info locals` to show the state of the data.

Presumably, this data causes the assertion in /usr/lib32/libc.so.6 (frame 4) to fail somehow.

 

Anyway I've exhausted all avenues that I can think of so please help if you can.

 

Don't hesitate to ask for more info/testing.

 

ps. congrats on the steam greenlight thingy.

 

gdb-packaged-libs.log.txt

gdb-system-libs.log.txt

[freyk]

I dont know if the current snapshot tdm is a 64 or 32 bit(still??)

The compiled binary from the updater is 32 bit.

For this and your described errors you need 32 libs.

http://wiki.thedarkmod.com/index.php?title=Installer_and_Manual_Installation#Installing_TDM_Manually_on_a_Linux_Distribution

 

 

 

from the wiki

sudo dpkg --add-architecture i386
sudo apt-get install libc6:i386 libstdc++6:i386 libx11-6:i386 libxext6:i386 libxxf86vm1:i386 libpng12-0:i386 libasound2-plugins:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 wget unzip
sudo mkdir -p /usr/share/games/darkmod
sudo chown -R nobody:users /usr/share/games/darkmod
sudo chmod uga+w /usr/share/games/darkmod
exit

 

Edited March 20, 2017 by freyk

[Crinkelite]

I have all my dependencies in place and the game is compiling fine. It produces 32 bit binaries which runs as expected for the most part.

/home/joe/games/tdm/darkmod/thedarkmod.x86: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b0a31110c49260cde4db9c3c6e14e32516a44536, not stripped, with debug_info

There is something subtle going awry here. As I've said, the game loads and is playable.

It runs very well in fact but something goes wrong when the game tries to rotate the player model for the lean command.

 

I'll try to provide more info later and possibly open a bug report. Got to go do some taffing work now.

[NightStalker]

Glad to see you back, Crinkelite!

A minor point to be sure, but please be careful with the terminology. I know that you're compiling a 32-bit TDM under a 64-bit OS but I want to clearly distinguish that case from the very different case of compiling a 64-bit TDM, which is what your subject line had me assuming initially.

As for the 1st problem...

[...] I decided to obtain the Boost source and compile my own 32 bit libraries.

This is a very wise choice, IMHO. I've taken a similar (more extensive, in fact) approach, with positive results.

As for the 2nd error log you posted, which "lean" key are you referring to? Left? Right? Forward? All 3?

Is this happening consistently, literally every time you lean (left, right, forward)?

Is it happening on "The Outpost" (per your log) only or on other missions too?

Looking over my old notes, running one of the late-December-era TDM 2.05 beta releases but under a 32-bit OS, I've encountered a failed 'assert' in the 'idCollisionModelManagerLocal::Rotation180()' routine (coincidentally?) on "The Outpost" when I was trying to move an ordinary bottle to get to the golden (loot) bottle behind it on a shelf in the kitchen. But I could not duplicate the crash on subsequent tests. That's the closest thing to your problem I've encountered.

I have no expertise whatsoever with the 'collision model' code, so I think you may just have to dig into that 'assert' failure and work backwards, unless someone else has good advice.

Wish I had more to suggest and/or more time to experiment...

[nbohr1more]

Not that I'm an expert on this failure point but we should also get the Darkmod.cfg.

There are a few settings in there that may cause crashing.

[Crinkelite]

A minor point to be sure, but please be careful with the terminology. I know that you're compiling a 32-bit TDM under a 64-bit OS but I want to clearly distinguish that case from the very different case of compiling a 64-bit TDM, which is what your subject line had me assuming initially.

 

A very valid point. I'll have to see if I can change the title somehow. - EDIT: I can't

 

 

This is a very wise choice, IMHO. I've taken a similar (more extensive, in fact) approach, with positive results.

 

Oh good. I had a nagging feeling that my non-packaged libs could somehow be the cause of this crash so it's good to know that you're not having problems.

 

 

 

Is this happening consistently, literally every time you lean (left, right, forward)?

 

Is it happening on "The Outpost" (per your log) only or on other missions too?

 

It happens consistently with "Q", "E" and "F" and on all maps.

 

I managed to get some slightly more accurate information about the crash.

The assertion fails at cm/CollisionModel_rotate.cpp:1616

assert( ((byte *)&start) < ((byte *)results) || ((byte *)&start) > (((byte *)results) + sizeof( trace_t )) );

I'll have to have a a look tomorrow with fresh eyes.

 

Thanks to both of you for your replies and sorry for the 64/32 bit ambiguity.

 

UPDATE:

(gdb) p (byte* )&start
$12 = (byte *) 0xffffc304 "w\037\337\302lr\256¨\274\207@\366(\336\302\034\234\257", <incomplete sequence \302>

(gdb) p (byte* )results
$13 = (byte *) 0xffffc298 ""

(gdb) p ((byte *)results + sizeof( trace_t ))
$14 = (byte *) 0xffffc304 "w\037\337\302lr\256¨\274\207@\366(\336\302\034\234\257", <incomplete sequence \302>

It looks like the first part of the assertion is false because results is empty

The second part of the assertion fails because ((byte*)&start and ((byte *)results + sizeof(trace_t)) are equal.

 

Anyway, I'll look again tomorrow.

Edited March 20, 2017 by Crinkelite

[Crinkelite]

Not that I'm an expert on this failure point but we should also get the Darkmod.cfg.

There are a few settings in there that may cause crashing.

 

Sorry nbohr1more, I missed your post somehow.

 

I'm pretty sure this isn't a configuration issue but I'll stick the Darkmod.cfg up anyway.

Darkmod.cfg.txt

autoexec.cfg.txt

[Crinkelite]

I would have liked to have provided more help but I'm a complete amateur with no formal training and it seems like every time I tried to write something contributory, I found I was unsure of what I was trying to say or lacking in basic understanding.

For these reasons, I decided to remain silent rather than muddy the waters.

 

Ok so it seems this issue is a bug that I introduced through editing the code.

I was sure that the bug existed in both my code and the latest SVN revision but this was a mistake.

I had verified this by reverting to, and compiling the svn code and triggering the bug there also.

 

I'm guessing that I may have had a debugging session open when compiling the SVN code which would have prevented the build script from copying the binaries into the run directory. This allowed me to mistakenly believe that I was running the virgin code when I was in fact running my broken code.

 

Basically, a stupid blunder that wasted my time and yours.

Please take everything I write in this forum with a massive pinch of salt.

[nbohr1more]

Glad you got that cleared up.

 

As a side note, I suggest you ensure that:

 

seta com_videoRam "128"

 

is set to the correct video ram amount.

[NightStalker]

Basically, a stupid blunder that wasted my time and yours.

Not a problem whatsoever. You're pushing the boundaries (a good thing to be doing) and you're bound to run into legitimate issues along with a healthy measure of confusion and silly mistakes along the way! Don't ask me how I know this.

 

So don't hesitate to post again if you run into something that's befuddling.

 

Glad to hear you've gotten things fixed up!