Welcome to The Bug Genie

Hi, thanks for reporting this. Because we cannot reproduce this, you'll need to help us out a bit to get it fixed:

First enable a 'Debug' build by running

    cmake .. -DCMAKE_BUILD_TYPE=Debug

instead of just 'cmake ..' and then rebuild (run 'make' again). Without this, the debug information generated by the following steps will not be as useful, but it will also make the game run a bit slower. So remember to switch back to the 'Release' build once this is fixed.

Next, switch the game to windowed mode. You can toggle windowed and fullscreen mode in the game by pressing Alt+Enter. In windowed mode we will not needlessly grab all keys and you will be able to use other windows or kill arx much easier. Grabbing all keys in fullscreen mode is unfortunately forced by the windowing library we currently use.

Make sure you have gdb installed and then load a level and wait until the game locks up. If this brings up a crash reporter, submit the report from that (it should have worked with fullscreen mode too, but you never know). If it doesn't then you'll need to generate a backtrace manually. To do this, run the following command in another terminal while arx is hung:

    gdb ./arx $(ps -A | grep "arx$" | sed 's/ [^0-9].*//')

Replace './arx' with the command you used to run arx, including the path. If all goes well this will print a lot of messages about loading symbols and then end at a prompt starting with '(gdb)'. Here enter the following commands:

    set print frame-arguments all
    thread apply all bt full

This should print lots of debug info. Please submit all of it - you might need to press Enter a few times to get to the end.

Also a side note: it seems you are missing some files of the 1.21 patch: there should also be a "graph" folder besides the "misc" folder and the .pak files. Remember that you need to rename the files to lowercase, including all files/folders in the graph and misc folders and their subdirs. You can use the `install-copy` script from the `scripts` directory to do that for you. This should however not be related to your bug.

Thanks for the quick reply.

I tried

cmake .. -DCMAKE_BUILD_TYPE=Debug

but then it produced an executable, which gives "Illegal instruction" error

$ ./arx

Illegal instruction

On another hand, I 'strace'd the Release build executable, and noticed something interesting. This is how it looks around the time the game hangs and after:

lseek(17, 203408114, SEEK_SET) = 203408114

read(17, "\377\330\377\340\0\20JFIF\0\1\1\0\0\1\0\1\0\0\377\333\0C\0\1\1\1\1\1\1\1"..., 21162) = 21162

lseek(17, 203429276, SEEK_SET) = 203429276

read(17, "\377\330\377\340\0\20JFIF\0\1\1\0\0\1\0\1\0\0\377\333\0C\0\1\1\1\1\1\1\1"..., 20866) = 20866

sched_yield() = 0

sched_yield() = 0

getpid() = 5436

clock_gettime(CLOCK_MONOTONIC, {61903, 482645642}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 482679015}) = 0

poll( events=POLLIN|POLLPRI}, 1, 1000) = 1 ( revents=POLLIN|POLLPRI})

ioctl(10, 0xc0104652, 0x7fffa6a2f6a0) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 482800144}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 482826898}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 482852820}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 482879017}) = 0

sched_yield() = 0

sched_yield() = 0

sched_yield() = 0

sched_yield() = 0

getpid() = 5436

clock_gettime(CLOCK_MONOTONIC, {61903, 512497190}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 512530918}) = 0

poll( events=POLLIN|POLLPRI}, 1, 1000) = 1 ( revents=POLLIN|POLLPRI})

ioctl(10, 0xc0104652, 0x7fffa6a2f6a0) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 512652308}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 512678816}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 512704988}) = 0

clock_gettime(CLOCK_MONOTONIC, {61903, 512731331}) = 0

sched_yield() = 0

sched_yield() = 0

sched_yield() = 0

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 1

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 1

futex(0x7fa5984a3ec0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 0

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 1

...

futex(0x7fa5984a3ec0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 0

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 1

futex(0x7fa5984a3ec0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 0

futex(0x7fa5984a3ec0, FUTEX_WAKE_PRIVATE, 1) = 1

futex(0x7fa5984a3ec0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable)

... several hundreds lines of this kind, until I manually killed it

--- {si_signo=SIGINT, si_code=SI_KERNEL, si_value={int=2847962146, ptr=0x7fb4a9c07422}} (Interrupt) ---

I'm not a programmer, but I know a bit about concepts. I know what a futex is (FastUserspaceMUTualEXclusion). A thread race condition or unreleased lock? A bug in the glibc? A buggy GCC? (This "Illegal instruction" stuff - I see it for the first time in my 6 years of using linux) At the moment I'm still hadn't checked all of my suspicions, e. g. a mismatched versions of the "-devel" header files or tried a debug build of another project to see if it will give "Illegal instruction" again. I'll continue investigating and will write it here if I discover something.

That "Illegal instruction" does look like it could be a problem with the compiler setup, but could also mean that there is some memory corruption or other bug in arx, any of the libraries or your drivers - although it is unlikely that you'd be the first to catch it.

There was another "Illegal instruction" recently that turned out to be a problem with the devil library compiled for SSE3 when the cpu didn't support it: https://bugs.arx-libertatis.org/arx/issues/218

You could try running

    VERBOSE=1 make

to instead of just make to see the compiler flags used. (Run `make clean` to force re-building) If there are any -march or -msse* flags make sure your cpu supports that.

Also look at the output of

    gcc -v

and check if the 'Target' is too new for your cpu.

Alternatively try the portable linux binaries for rc4 or openSUSE 12.1 packages for rc4 (i'll add those to the wiki once we release 1.0).

The lockup is interesting though - there aren't that many locks in arx yet. We had a problem a long time ago where OpenAL soft would enter an infinite loop, but that has been fixed in newer versions of OpenAL Soft and we added a workaround to prevent arx from triggering it. A backtrace would give much more information about where the problem lies though - you could try the gdb commands from my last comment with the release build. While the debug build would provide more information, with the release build there should be at least something.

There have been a lot of changes to AL since this was reported - does it still happen?

Adding to milestone so that I'll remember to close it if there isn't any update.