t-engine executable won't run

[drmarkandersen]

I'm running t-engine 4, TOME 1.2.2, under Ubuntu 14.04 (32-bit). As of yesterday, t-engine won't start. If I click on the t-engine executable file in Nautilus (my usual way of starting the game), nothing happens. Likewise if I right-click on the file and select "Run", or if I try to run the file from the command line. I downloaded and extracted TOME 1.2.4, and the same thing happens, or rather fails to happen. I tried installing TOME 1.2.4 64-bit on a 64-bit Ubuntu system on another machine (clean brand-new install of Ubuntu 14.04.01 LTS 64-bit), with the same outcome. Opening a terminal window and entering "pidof t-engine" returns nothing, so it's not just running in some non-visible way. I'd appreciate any clues as to how to proceed.

[tilkau]

I was gonna say 'If it won't run, you should whip it'.

More seriously, at least on my system (Arch Linux, 64bit) you're not supposed to run t-engine directly, there is a wrapper script 'tome4' which changes to the right directory (/opt/tome4 for me) and executes './t-engine'. This suggests to me that t-engine is sensitive to the current working directory.

Have you tried

a) Running this wrapper script in a terminal, if it exists
b) Manually executing the steps I listed in a terminal (chdir to the tome install directory, then execute './t-engine')

In general you should be doing -everything- in a terminal if things are going wrong, so you can see the output.

[drmarkandersen]

I've always started TOME by navigating to the directory the compressed download (t-engine4-linux32-1.2.2-nomusic.tar.bz) creates (./t-engine4-linux32-1.2.2 on my system) and clicking on t-engine. If I navigate to that directory in a terminal window and type in t-engine, it says "t-engine: command not found". Trying sudo t-engine yields the same result. I've checked the properties on t-engine and it is definitely an executable file as far as the system is concerned, it just for some reason won't execute.
I just installed an upgrade to the generic linux kernel; I think that may be when the problem started. So it's possible that some package that t-engine depends on got updated and broke t-engine, but I really don't know enough about linux to be able to track that down.

[tilkau]

I've always started TOME by navigating to the directory the compressed download (t-engine4-linux32-1.2.2-nomusic.tar.bz) creates (./t-engine4-linux32-1.2.2 on my system) and clicking on t-engine. If I navigate to that directory in a terminal window and type in t-engine, it says "t-engine: command not found". Trying sudo t-engine yields the same result. I've checked the properties on t-engine and it is definitely an executable file as far as the system is concerned, it just for some reason won't execute.

Here's the problem (with running it in the terminal) : You think you are trying to run the command in that directory called 't-engine', but you are actually attempting to run a nonexistent command that's in the global path called 't-engine'. t-engine never gets a look in because you haven't yet actually started it.

This is why the tome4 script looks like this:

Code: Select all

#!/bin/sh
cd "/opt/tome4"
./t-engine

And not like this:

Code: Select all

#!/bin/sh
cd "/opt/tome4"
t-engine

Note the './'. If you give a command with no path component, the shell tries to look it up in the global PATH. You can check that with 'which t-engine' -- it will report 't-engine not found', because almost all Linux systems do not have . in the PATH by default (for very good security reasons). You have to tell it that you want to run the executable that is in the current directory (./) called t-engine.

Clicking on t-engine in Nautilus should work if your install is sound, so there probably are some other problems involved. But you'll probably need to run ./t-engine in a terminal to see what they are.

[drmarkandersen]

Thanks for the quick replay on that. Here's what I get when I try to run t-engine (correctly this time) from a terminal window:

manderse@manderse-ThinkPad-T430s:~/t-engine4-linux32-1.2.2$ ./t-engine
WebCore config: library(/home/manderse/t-engine4-linux32-1.2.2/lib/libte4-web.so) spawn(/home/manderse/t-engine4-linux32-1.2.2/cef3spawn32)
Loading WebCore: Failed loading /home/manderse/t-engine4-linux32-1.2.2/lib/libte4-web.so: libudev.so.0: cannot open shared object file: No such file or directory
[CPU] Detected 4 CPUs
ALSA lib pcm.c(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
libgcc_s.so.1 must be installed for pthread_cancel to work
Aborted (core dumped)

Again, the program was working just fine until two days ago. I don't know anything about WebCore, and I can't imagine why it would suddenly decide it needed to use ALSA and jack, since other apps that use the sound card continue to work.

[tilkau]

Hmm. IME the webcore message is misleading -- it's entirely nonfatal, I still get it every time I start ToME but I can play just fine.

I can't imagine why it would suddenly decide it needed to use ALSA and jack, since other apps that use the sound card continue to work.

.. It was probably already using ALSA anyway.IME that's the usual situation on Linux machines -- Ubuntu's favored PulseAudio library is just a wrapper that can run on various backends, the most commonly used of which is ALSA. A kernel upgrade could indeed affect ALSA's functionality.
Anyway, the sound messages are quite inconclusive (in terms of whether they are supposed to be describing a warning or an error condition, and even about whether it ultimately decided to use ALSA or not).

What is really important here is "Aborted (core dumped)", indicating definitively that t-engine crashed. You could try to get a backtrace from that, which would be useful in making a bug report. That would involve using gdb, roughly like this:

Code: Select all

gdb ./t-engine
run
bt
quit

If the output is just numbers, that's not very useful for debugging. If the output includes symbol names (like for example bt_audio_service_open), that could provide a good clue to exactly what it's trying to do when it crashes.

In any case, the crash you describe (and indeed any crash involving a core-dump) is serious and probably reflects an oversight in T-Engine's code or one of its dependencies. It may be possible to work around, but I'd suggest contacting DarkGod in any case.

[drmarkandersen]

Here's what I got when I ran gdb as suggested:

manderse@manderse-ThinkPad-T430s:~/t-engine4-linux32-1.2.2$ gdb ./t-engine
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./t-engine...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/manderse/t-engine4-linux32-1.2.2/t-engine
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
WebCore config: library(/home/manderse/t-engine4-linux32-1.2.2/lib/libte4-web.so) spawn(/home/manderse/t-engine4-linux32-1.2.2/cef3spawn32)
Loading WebCore: Failed loading /home/manderse/t-engine4-linux32-1.2.2/lib/libte4-web.so: libudev.so.0: cannot open shared object file: No such file or directory
[CPU] Detected 4 CPUs
ALSA lib pcm.c(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
[New Thread 0xb7254b40 (LWP 15102)]
[Thread 0xb7254b40 (LWP 15102) exited]
[New Thread 0xb7254b40 (LWP 15103)]
[Thread 0xb7254b40 (LWP 15103) exited]
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
[New Thread 0xb7254b40 (LWP 15104)]
[Thread 0xb7254b40 (LWP 15104) exited]
[New Thread 0xb7254b40 (LWP 15105)]
[Thread 0xb7254b40 (LWP 15105) exited]
[New Thread 0xb68ffb40 (LWP 15106)]
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
libgcc_s.so.1 must be installed for pthread_cancel to work

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb68ffb40 (LWP 15106)]
0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7b35577 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2 0xb7b389a3 in __GI_abort () at abort.c:89
#3 0xb7b706e3 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0xb7c6ad7d "%s")
at ../sysdeps/posix/libc_fatal.c:175
#4 0xb7b70724 in __GI___libc_fatal (
message=message@entry=0xb7ce6f84 "libgcc_s.so.1 must be installed for pthread_cancel to work\n")
at ../sysdeps/posix/libc_fatal.c:186
#5 0xb7ce4ab5 in pthread_cancel_init () at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:64
#6 0xb7ce4bcc in _Unwind_ForcedUnwind (exc=0xb68ffd90, stop=0xb7ce2680 <unwind_stop>, stop_argument=0xb68ff390)
at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:129
#7 0xb7ce27f3 in __GI___pthread_unwind (buf=0xb68ff390) at unwind.c:129
#8 0xb7cdd041 in __do_cancel () at pthreadP.h:280
#9 __pthread_exit (value=0x0) at pthread_exit.c:29
#10 0xb72b68bf in ?? () from /usr/lib/i386-linux-gnu/libjack.so.0
#11 0xb7cdbf70 in start_thread (arg=0xb68ffb40) at pthread_create.c:312
#12 0xb7bf34ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
(gdb) quit
A debugging session is active.

Inferior 1 [process 15098] will be killed.

Quit anyway? (y or n) y

I'm planning to send an email to darkgod as well, just pointing to this discussion thread.

[tilkau]

Well, my read of that backtrace says that one of ToME's compiled-in dependencies is intentionally triggering that crash when it finds no libgcc_s.so.1, so presumably pthread_cancel is an absolutely vital function.

Personally, when I run 'find /lib /usr -iname "*gcc_s.so*" |xargs ls -l',
I get

Code: Select all

lrwxrwxrwx 1 root root     13 Jan  4  2014 /lib/gcc-lib/x86_64-unknown-linux-gnu/4.0.3/libgcc_s.so -> libgcc_s.so.1
-rwxr-xr-x 1 root root  55352 Jan  4  2014 /lib/gcc-lib/x86_64-unknown-linux-gnu/4.0.3/libgcc_s.so.1
lrwxrwxrwx 1 root root     13 Sep 10 06:31 /lib/libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 root root 547436 Sep 10 06:31 /lib/libgcc_s.so.1
lrwxrwxrwx 1 root root     13 Sep 10 06:31 /usr/lib32/libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 root root 459316 Sep 10 06:31 /usr/lib32/libgcc_s.so.1
lrwxrwxrwx 1 root root     13 Jan  4  2014 /usr/lib/gcc-lib/x86_64-unknown-linux-gnu/4.0.3/libgcc_s.so -> libgcc_s.so.1
-rwxr-xr-x 1 root root  55352 Jan  4  2014 /usr/lib/gcc-lib/x86_64-unknown-linux-gnu/4.0.3/libgcc_s.so.1
lrwxrwxrwx 1 root root     13 Sep 10 06:31 /usr/lib/libgcc_s.so -> libgcc_s.so.1
-rw-r--r-- 1 root root 547436 Sep 10 06:31 /usr/lib/libgcc_s.so.1

Which is as expected -- that libgcc_s.so.1 would be in /usr/lib, and libgcc_s.so was a symbolic link to it. The gcc-lib result is an internal compiler thing as I understand, and should probably be ignored. On Arch Linux, /lib/ is just a symbolic link to /usr/lib, so I also ignore the /lib/ results -- but this is specific to Arch.

Anyway if you want to narrow down things further, you could run the command I listed above.

I've just done a little research and it looks like this is a bug in ubuntu.
This link suggests that it is because Ubuntu places libgcc_s.so.1 in a nonstandard location. and proposes that you can fix this by adding a line '/lib' to /etc/ld.so.conf and then rerunning ldconfig. Both of those actions would need to be taken with root privileges, so I would use sudo:
'sudo gedit /etc/ld.so.conf'* , followed by 'sudo ldconfig' after the conf file has been edited and saved. Only after running the find command I listed above to verify the actual location of libgcc_s.so.1.

* I'm guessing as to what editor you have installed -- probably either geany or gedit are available.

It's not clear to me why this has suddenly come up when it was working okay before, but when in doubt, investigate.

[douther]

I've been having the same problem with the same backtrace in Ubuntu 14.04. I tried the solution proposed by tilkau but it seemed to do nothing. I will try to compile the game from source and see what happens.

[drmarkandersen]

Still no luck.

When I run 'sudo ldconfig -v', the output includes the line: libgcc_s.so.1 -> libgcc_s.so.1 (under /lib/i386-linux-gnu:), which indicates to me that the system knows where that file is. In addition, running 'ldd t-engine' yields (among lots of other output) 'libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb741c000)', so it looks to me like t-engine should know where libgcc_s.so.1 is, since /lib/i386-linux-gnu is the actual directory where libgcc_s.so.1 lives.

I'm tempted to just copy libgcc_s.so.1 to the other locations listed in your 'find' output and see if that fixes the problem. On the other hand, I'm not at all tempted to try compiling t-engine from source; I'd be way out of my depth there.

[tilkau]

Still no luck.

When I run 'sudo ldconfig -v', the output includes the line: libgcc_s.so.1 -> libgcc_s.so.1 (under /lib/i386-linux-gnu:), which indicates to me that the system knows where that file is. In addition, running 'ldd t-engine' yields (among lots of other output) 'libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb741c000)', so it looks to me like t-engine should know where libgcc_s.so.1 is, since /lib/i386-linux-gnu is the actual directory where libgcc_s.so.1 lives.

I agree with this, except I'm not sure that it has been verified that /lib/i386-linux-gnu is the actual directory where libgcc_s.so.1 lives.
I mention a way to verify that below.

I'm tempted to just copy libgcc_s.so.1 to the other locations listed in your 'find' output and see if that fixes the problem.

I recommend you don't do that. Quite aside from anything else, copying system files tends to lead to trouble when you upgrade and the copies remain at the old version.
Instead, if you want to pursue that path, I suggest creating a symlink to the actual file. This would involve two steps.

1. Make sure you know what the real path is that you should link to: run realpath /lib/i386-linux-gnu/libgcc_s.so.1. The real path probably -is- /lib/i386-linux-gnu/libgcc_s.so.1 , but I wouldn't guarantee it.
2. cd /usr/lib, then sudo ln -s REALPATH, where REALPATH is the path generated by step 1.

I do not recommend doing anything with directories other than /usr/lib or /lib -- these are generally the only two plausible system directories that libraries are placed in.

That said, since ToME seems to incorporate its own copy of pthreads, you might consider placing a similar symlink in the same directory that you have installed ToME into. (If this fixes the problem, I would strongly suspect that there is something a bit wrong with ToME's copy of pthreads.)

On the other hand, I'm not at all tempted to try compiling t-engine from source; I'd be way out of my depth there.

Personally, I have the policy that it is always worth a try, but in this case I don't believe it's at all likely that recompiling will change anything, since the problem seems to be with the way Ubuntu has set up the system.

[drmarkandersen]

Tried creating symlinks to libgcc_s.so.1 in /usr/lib and in /lib (thanks for the command-line lessons, by the way). Still get the same results when trying to run t-engine. This is very frustrating.

[gareppa]

hi, i had the exact same problem with tome 1.2.4 64 bit on ubuntu 14.04 64 bit.
i've tried also tome 1.2.3 64 bit which worked flawlessly before, and now i have the same problem with that version too.
what solved it for me was this:

Code: Select all

sudo ln -sf /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0

i've played a couple of hours without crashes so far.
however, notice that this is a hack: https://bugs.launchpad.net/ubuntu/+sour ... ug/1241945

Martin Pitt (pitti) wrote on 2013-10-20: #3

Pretending that libudev1 provides the libudev0 ABI is a lie, I won't add that symlink to the official packages (that's bound to cause crashes). Looks like chromium needs to be rebuilt against current udev.
Changed in systemd (Ubuntu):
status: Confirmed ? Won't Fix

[drmarkandersen]

Thanks, gareppa, that fixed it. And, just for the sake of completeness, on a 32-bit system, you would need to run:

Code: Select all

sudo ln -sf /lib/i386-linux-gnu/libudev.so.1 /lib/i386-linux-gnu/libudev.so.0

Looks like "case closed."

[gareppa]

perfect.
but the problem is present and alive in 1.2.5