This War of Mine

This War of Mine

View Stats:
InHave Mar 2, 2015 @ 3:49am
Broken loading on linux
Hello everyone, I have a small problem. When the game loads it often freezes hard. At this time in the logs there are such lines: "Loading of templates/UI/MainMenuUI is causing delay!" or "Loading of templates/UI/ScenarioSelectorUI is causing delay!" or something else. This line is repeated too many times ... In general, my question: may be somebody already encountered with this problem and knows how to solve it? My system is arch linux.

By the way after a huge amount of restarting the game, it works fine ... until next loadscreen.

P.S. Sorry for my broken English ^)
< >
Showing 46-60 of 116 comments
truethrash88 Jun 13, 2015 @ 5:17am 
Originally posted by Isbjoern:
Originally posted by eadword:

Download lib32-glibc-2.20-6... from http://seblu.net/a/arm/packages/l/lib32-glibc/

Open with an archive manager and then go into user, lib32 (in archive)

Now copy the following (out of the archive) and put them in the root of This War of Mine's installation directory (~/.local/share/Steam/steamapps/common/This\ War\ of\ Mine is the default I think, I use a separate hard drive so make your best judgement)

libc.so.6
libc-2.20.so
libpthread.so.0
libpthread-2.20.so
librt.so.1
librt-2.20.so

That *should* do it

Thanks that fixed it for me.
fixed for me :)
ton Jun 15, 2015 @ 4:26am 
Originally posted by sam.garathor:
I was able to fix this problem on my Arch system running Gnome 3 without downgrading my lib32-glibc. I used this workaround (with one slight adjustment):

http://steamcommunity.com/app/282070/discussions/1/613956964581607081/

The workaround needs an old version of lib32-glibc. Mine (version 2.20-6) was still present in "/var/cache/pacman/pkg/". Copy this package and extract it to whatever destination, so it can be deleted safely when you're done. Navigate to its "usr" subfolder and find the following files (partly symlinks):

libc.so.6
libc-2.20.so
libpthread.so.0
libpthread-2.20.so
librt.so.1
librt-2.20.so

The workaround states that these files should be copied to the root folder of "This War of Mine", but this didn't work for me. I had to drop the files into "This War of Mine/lib/" instead. Then, the game starts and seems to run just fine. The copy of lib32-glibc can be deleted as soon as you copied the relevant files.
I should note that I tried this using the version of This War of Mine that I bought on GOG.com. It may be a tad different for the Steam version.

I'm on Ubuntu 15.04 with glibc 2.21. You explained this perfectly, but mine worked when I placed the .so files in the game's root folder, just as the op suggested.

The game works now. I really do hope they fix this soon.
jug Jun 15, 2015 @ 8:10am 
Originally posted by Ton:
The game works now. I really do hope they fix this soon.
I contacted them yesterday about this issue and got a reply today. They are aware of this issue and they are working on a fix, but apparently it is not an "easy fix". I hope they will do it properly, so it doesn't immediately break again with future glibc-updates.
They did not give an ETA. Let's be patient and give them the time they need.

In the meantime, just copy the three files to the games install folder like described in various places, but do not downgrade your system libraries.
Nibodhika Jun 15, 2015 @ 8:14am 
Originally posted by frustbox:
Originally posted by Ton:
The game works now. I really do hope they fix this soon.
I contacted them yesterday about this issue and got a reply today. They are aware of this issue and they are working on a fix, but apparently it is not an "easy fix". I hope they will do it properly, so it doesn't immediately break again with future glibc-updates.
They did not give an ETA. Let's be patient and give them the time they need.

In the meantime, just copy the three files to the games install folder like described in various places, but do not downgrade your system libraries.

Just don't hold your breath, I contacted them on the begining of april about this, and they responded with a "we don't support arch", when I explained that this would happen after april 23 for everybody who installed ubuntu 15.04 they responded with a "we are aware of the problem, and the next update should fix it"
tectux Jun 15, 2015 @ 1:15pm 
Originally posted by eadword:
Originally posted by Claudio84:
Can you please explain all the steps you did?
I am also Archlinux-Steam user, 64 bit.
Thanks.

Download lib32-glibc-2.20-6... from http://seblu.net/a/arm/packages/l/lib32-glibc/

Open with an archive manager and then go into user, lib32 (in archive)

Now copy the following (out of the archive) and put them in the root of This War of Mine's installation directory (~/.local/share/Steam/steamapps/common/This\ War\ of\ Mine is the default I think, I use a separate hard drive so make your best judgement)

libc.so.6
libc-2.20.so
libpthread.so.0
libpthread-2.20.so
librt.so.1
librt-2.20.so

That *should* do it

Thanks, this helped me out on Fedora 22.

For any other Fedora users out there:
On Fedora the package is called glibc (without the lib32 prefix) and the files can be found in the lib directory (in the archive). link[mirror2.hs-esslingen.de]
Last edited by tectux; Jun 15, 2015 @ 1:17pm
Avatar Jun 17, 2015 @ 12:20pm 
Originally posted by ;594820656457496884:
Originally posted by frustbox:
I contacted them yesterday about this issue and got a reply today. They are aware of this issue and they are working on a fix, but apparently it is not an "easy fix". I hope they will do it properly, so it doesn't immediately break again with future glibc-updates.
They did not give an ETA. Let's be patient and give them the time they need.

In the meantime, just copy the three files to the games install folder like described in various places, but do not downgrade your system libraries.

Just don't hold your breath, I contacted them on the begining of april about this, and they responded with a "we don't support arch", when I explained that this would happen after april 23 for everybody who installed ubuntu 15.04 they responded with a "we are aware of the problem, and the next update should fix it"

I am using Ubuntu 15.04 and this bug affects me.
Magbed@Linux! Jul 4, 2015 @ 9:41am 
Just bought the game and im affected by this bug as well. Workaround solves it
MikePearce Jul 8, 2015 @ 11:17pm 
Originally posted by eadword:
Originally posted by Claudio84:
Can you please explain all the steps you did?
I am also Archlinux-Steam user, 64 bit.
Thanks.

Download lib32-glibc-2.20-6... from http://seblu.net/a/arm/packages/l/lib32-glibc/

Open with an archive manager and then go into user, lib32 (in archive)

Now copy the following (out of the archive) and put them in the root of This War of Mine's installation directory (~/.local/share/Steam/steamapps/common/This\ War\ of\ Mine is the default I think, I use a separate hard drive so make your best judgement)

libc.so.6
libc-2.20.so
libpthread.so.0
libpthread-2.20.so
librt.so.1
librt-2.20.so

That *should* do it


This worked for more on Ubuntu 15.04. Thanks man
de.nagical[linux] Jul 13, 2015 @ 2:13am 
Bug in the game. Broken usage of sem_timedwait and/or absolute time waiting. Basically they call clock_gettime() and add 10000000 to the nanosecs, but they don't check for the nanosecs getting bigger than 1000000000 (1s), which glibc checks for. The returned error condition (-1/EINVAL) isn't handled by the game and instead it tries to wait even longer (until 0 is returned). Thus it just hangs.

Breakpoint 2, sem_timedwait (sem=0xed079c4c, abstime=0xed079b40) at sem_timedwait.c:26
26 in sem_timedwait.c
(gdb) p *abstime
$18 = {
tv_sec = 1436776731,
tv_nsec = 1001326413
}

Additionally, it seems that if the absolute time is already passed, the returned ETIMEDOUT would be also ignored.
Additionally 2, usleep() gets called with argument 0 most of the time oO


EDIT: hacky preloadable .so to make it start up for me (the fedore libs didn't work)
EDIT2: fix some brainfarts

#define _GNU_SOURCE #include <dlfcn.h> #include <semaphore.h> #include <stdio.h> #include <time.h> #include <unistd.h> static int (*_realSemTimedWait)(sem_t *, const struct timespec *) = NULL; int sem_timedwait(sem_t *sem, const struct timespec *abs_timeout) { if (abs_timeout->tv_nsec >= 1000000000) { //fprintf(stderr, "to: %lu:%lu\n", abs_timeout->tv_sec, abs_timeout->tv_nsec); ((struct timespec *)abs_timeout)->tv_nsec -= 1000000000; ((struct timespec *)abs_timeout)->tv_sec++; } return _realSemTimedWait(sem, abs_timeout); } __attribute__((constructor)) void init(void) { _realSemTimedWait = dlsym(RTLD_NEXT, "sem_timedwait"); }
Compile with
gcc -m32 -o test.so test.c -ldl -shared -fPIC -Wall -Wextra
Run with
env LD_PRELOAD=./test.so %command%
Last edited by de.nagical[linux]; Jul 16, 2015 @ 5:45am
directhex Jul 15, 2015 @ 4:49pm 
Originally posted by de.nagicallinux:
Bug in the game. Broken usage of sem_timedwait and/or absolute time waiting. Basically they call clock_gettime() and add 10000000 to the nanosecs, but they don't check for the nanosecs getting bigger than 1000000000 (1s), which glibc checks for. The returned error condition (-1/EINVAL) isn't handled by the game and instead it tries to wait even longer (until 0 is returned). Thus it just hangs.

Breakpoint 2, sem_timedwait (sem=0xed079c4c, abstime=0xed079b40) at sem_timedwait.c:26
26 in sem_timedwait.c
(gdb) p *abstime
$18 = {
tv_sec = 1436776731,
tv_nsec = 1001326413
}

Additionally, it seems that if the absolute time is already passed, the returned ETIMEDOUT would be also ignored.
Additionally 2, usleep() gets called with argument 0 most of the time oO


EDIT: hacky preloadable .so to make it start up for me (the fedore libs didn't work)

#define _GNU_SOURCE #include <dlfcn.h> #include <semaphore.h> #include <stdio.h> #include <time.h> #include <unistd.h> static int (*_realSemTimedWait)() = NULL; int sem_timedwait(sem_t *sem, const struct timespec *abs_timeout) { if (abs_timeout->tv_nsec >= 1000000000) { //fprintf(stderr, "to: %lu:%lu\n", abs_timeout->tv_sec, abs_timeout->tv_nsec); ((struct timespec *)abs_timeout)->tv_nsec -= 1000000000; ((struct timespec *)abs_timeout)->tv_sec++; } _realSemTimedWait(sem, abs_timeout); } __attribute__((constructor)) int init(void) { _realSemTimedWait = dlsym(RTLD_NEXT, "sem_timedwait"); }
Compile with
gcc -m32 -o test.so test.c -ldl -shared -fPIC
Run with
env LD_PRELOAD=./test.so %command%

You're a hero.

Y'all want libc6-dev-i386 for this to build, kids.
JonnyJD Jul 22, 2015 @ 2:55am 
This is fixed for me now without fiddling with libc (with the recent steam runtime update).
Avatar Jul 22, 2015 @ 10:25am 
Originally posted by JonnyJD:
This is fixed for me now without fiddling with libc (with the recent steam runtime update).

Same here.
onlurking Jul 22, 2015 @ 7:28pm 
I've included the workaround to the Arch Wiki Game Specific Troubleshooting: https://wiki.archlinux.org/index.php/Steam/Game-specific_troubleshooting#This_War_of_Mine
JonnyJD Jul 22, 2015 @ 11:50pm 
@fex:
Do you still have the problem?

Like I said: this was fixed for me with the latest steam runtime update.
Avatar Jul 23, 2015 @ 4:50am 
Originally posted by JonnyJD:
@fex:
Do you still have the problem?

Like I said: this was fixed for me with the latest steam runtime update.

Steam just updated again and the problem has reappeared, the game won't start.
< >
Showing 46-60 of 116 comments
Per page: 15 30 50