7D takes two minutes to launch from steam, locks up on exit.

Status
Not open for further replies.
zootal

zootal

Refugee
1) Starting the game often takes several minutes. I start it from steam, and nothing happens. The process is in the task list, but there is no music and no visual indication that it has started. A couple of minutes later it appears and works fine.

2) When done, I exit by clicking QUIT, and it stops responding but does not exit. I've waited a half hour - and it's still stuck there. I have to forcibly terminate the process to get rid of it.

I can start it from a terminal, and when I do it starts up immediately, but still freezes on exit.

The log shows nothing. For the two minute delay while starting, no log file gets created. After a few minutes, a log file appears and the game itself appears and runs normally. This could be a steam problem of some sort since I can start it immediately from the console, but in either case it still won't exit.

Slackware 15 64 bit 4.19.50 kernel

32GB ram

SSD with about 150GB free space

nVidia 1060 with proprietary drivers

xfce

Up to several weeks ago this worked fine. I'm not sure if this started with A17.4 because i did not pay that much attention to it at first and wasn;t playing much when A17.4 first came out.

Yes I validated files.

I also deleted all files found under ~/.local/share/7DaysToDie and ~/.config/unity3d/The Fun Pimps/7 Days To Die

 
1) Starting the game often takes several minutes. I start it from steam, and nothing happens. The process is in the task list, but there is no music and no visual indication that it has started. A couple of minutes later it appears and works fine.
2) When done, I exit by clicking QUIT, and it stops responding but does not exit. I've waited a half hour - and it's still stuck there. I have to forcibly terminate the process to get rid of it.

I can start it from a terminal, and when I do it starts up immediately, but still freezes on exit.

The log shows nothing. For the two minute delay while starting, no log file gets created. After a few minutes, a log file appears and the game itself appears and runs normally. This could be a steam problem of some sort since I can start it immediately from the console, but in either case it still won't exit.

Slackware 15 64 bit 4.19.50 kernel

32GB ram

SSD with about 150GB free space

nVidia 1060 with proprietary drivers

xfce

Up to several weeks ago this worked fine. I'm not sure if this started with A17.4 because i did not pay that much attention to it at first and wasn;t playing much when A17.4 first came out.

Yes I validated files.

I also deleted all files found under ~/.local/share/7DaysToDie and ~/.config/unity3d/The Fun Pimps/7 Days To Die
Click to expand...
And just to make things more interesting - I switched to the "beta" version of steam, and the problem goes away....

Anyone else seen this?

 
I see the effect that after I had started and stopped 72d2 again, a new start without reboot takes some time (similar to what you experience). But the first start-up and exiting the game is always unproblematic and fast.

You could install "strace" and use it to try to find out the system call the game hangs on.

 
One day after I said this I experienced a start-up delay even on a freshly booted machine. Tried strace and I can see that he is waiting on an open file descriptor but didn't use "lsof" on time to find out more. The machine seemed to hang in the launcher.

When I stopped and restarted I saw the delay already happening in steams subprocess with parameter "rungameid//251570" (it didn't get to the launcher yet) and also saw unfinished processes of the previous game together with lots of steamwebhelper subprocesses. My guess is 7d2d uses a steam feature that it not correctly closed and blocks steam for a while from starting the launcher. But THIS bug seems to be a different bug than the cold startup bug.

 
I sometimes see it hanging in the launcher, in that Steam runs the launcher and the launcher process runs sits there for a while. What you describe sounds like a variation of what I'm experience, with the same cause - Steam. If I start the game in the console by running the executable directly, it immediately starts - every time.

I didn't post this as a bug report because I'm 95% certain it is a Steam problem. I'm betting a DRM/Steam free version of 7D does not have this problem.

And since I updated to Steam beta, the only problem I'm having is that sometimes after exiting (it starts and exits fine), a 7d process is still running, causing Steam to think the game is still running.

Back around A14 or so we had a similar problem. The game would not start at all from steam, the only way to get it to run was to manually run the executable.

- - - Updated - - -

You The Sims 3 players out there might have noticed that the Sims 3 executable is now Steam free, and will run without Steam. AFAIK, running through Steam caused too many problems, so they removed the Steam dependency. The exception is that you have to start it from Steam one time to get the registry setup properly. After that, it runs without Steam just fine.

/nudges TFP...

 
Edit: Comment Deleted (Windows user here)
Click to expand...
It might happen on Windows under certain circumstances. I can't be the only Linux user here, but not many people are talking about this. hmm maybe I'll crank up the windows version tonight just to see what happens...

 
I have never had a problem starting the game, just exiting the game.

I tried to look into it, but my knowledge in linux debugging of any sort is pretty limited and without a source pretty non-existent.

This is what a strace shows, separated by threads. The remaining threads are in a wait state.

Code: 
Main output at exit.
[code]
futex(0x7f087adbc638, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f087c535d28, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f087c535d28, FUTEX_WAKE_PRIVATE, 1) = 1
inotify_rm_watch(33, 1)                 = 0
close(33)                               = 0
futex(0x315926c, FUTEX_WAKE_PRIVATE, 2147483647) = 1
futex(0x3159218, FUTEX_WAKE_PRIVATE, 1) = 1
write(1, "2019-06-28T09:44:21 31.772 INF O"..., 48) = 48
write(1, "\n", 1)                       = 1
write(1, "2019-06-28T09:44:21 31.773 INF O"..., 48) = 48
write(1, "\n", 1)                       = 1
futex(0x7f087ade8768, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f08400f09d0, FUTEX_WAIT, 14592, NULL) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3576, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3576, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3576, ...}) = 0
futex(0x5613c48, FUTEX_WAKE_PRIVATE, 1) = 1
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5", {st_mode=S_IFDIR|0755, st_size=18, ...}) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5", {st_mode=S_IFDIR|0755, st_size=18, ...}) = 0
access("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5", F_OK) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics", {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
access("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics", F_OK) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics", {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", {st_mode=S_IFREG|0644, st_size=153, ...}) = 0
access("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", F_OK) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", {st_mode=S_IFREG|0644, st_size=153, ...}) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", {st_mode=S_IFREG|0644, st_size=153, ...}) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", {st_mode=S_IFREG|0644, st_size=153, ...}) = 0
stat("/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", {st_mode=S_IFREG|0644, st_size=153, ...}) = 0
openat(AT_FDCWD, "/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/Unity/local.362f0856a1e8486469f0962be8e5e9c5/Analytics/values", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
write(33, "{\"config_etag\":\"\",\"app_info_hash"..., 153) = 153
close(33)                               = 0
futex(0x5613c48, FUTEX_WAKE_PRIVATE, 1) = 1
openat(AT_FDCWD, "/home/chris/.config/unity3d/The Fun Pimps/7 Days To Die/prefs", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33
writev(33, [{iov_base=NULL, iov_len=0}, {iov_base="<unity_prefs version_major=\"1\" v"..., iov_len=17382}], 2) = 17382
futex(0x7f087cb823c0, FUTEX_WAKE_PRIVATE, 1) = 0
close(33)                               = 0
futex(0x7f087add2bf8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = 0
clone(child_stack=0x7f07b77fdfb0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7f07b77fe9d0, tls=0x7f07b77fe700, child_tidptr=0x7f07b77fe9d0) = 14606
futex(0x7f07b77fe9d0, FUTEX_WAIT, 14606, NULL) = 0
munmap(0x7f075c80d000, 8392704)         = 0
futex(0x7f087c535d28, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f07c497d9d0, FUTEX_WAIT, 14595, NULL
Each active thread, that's not in a wait state.

This one just sits.

Code: 
read(0,
The rest repeat.

Code: 
nanosleep({tv_sec=0, tv_nsec=10000000}, NULL) = 0
Code: 
futex(0x3909538, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
getpid()                                = 14083
getpid()                                = 14083
write(37, "W", 1)                       = 1
getpid()                                = 14083
futex(0x39074e0, FUTEX_UNLOCK_PI_PRIVATE) = 0
futex(0x390953c, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
getpid()                                = 14083
getpid()                                = 14083
write(37, "W", 1)                       = 1
futex(0x39074e0, FUTEX_UNLOCK_PI_PRIVATE) = 0
Code: 
poll([{fd=36, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}], 3, 369) = 1 ([{fd=40, revents=POLLIN}])
read(40, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x3909538, FUTEX_WAKE_PRIVATE, 2147483647) = 1
read(36, 0x7f3daf7fdc9e, 10)            = -1 EAGAIN (Resource temporarily unavailable)
futex(0x39074e0, FUTEX_UNLOCK_PI_PRIVATE) = 0
poll([{fd=36, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}], 3, 357) = 1 ([{fd=36, revents=POLLIN}])
write(38, "\1\0\0\0\0\0\0\0", 8)        = 8
read(36, "W", 10)                       = 1
poll([{fd=36, events=POLLIN}, {fd=39, events=POLLIN}, {fd=40, events=POLLIN}], 3, 357) = 1 ([{fd=40, revents=POLLIN}])
read(40, "\1\0\0\0\0\0\0\0", 8)         = 8
read(36, 0x7f3daf7fdc9e, 10)            = -1 EAGAIN (Resource temporarily unavailable)
[/code]

 
Last edited:
I didn't post this as a bug report because I'm 95% certain it is a Steam problem. I'm betting a DRM/Steam free version of 7D does not have this problem.
Click to expand...
While you can point to manual startup to prove steam is to blame, I can point to other games that are started from steam without problems to prove 7D2D is to blame :cocksure:

Not using the interface obviously makes interface problems go away. It could be that steam did not define their (startup) interface well enough or TFP not following that startup interface definition in some aspect.

 
I really need to build another box for Linux to test. Just so happens I have some spare hardware laying around after yesterdays server upgrade.

 
Did you ever find a solution to this? I'm getting it, too, after A18. Also on Slackware, xfce, nvidia proprietary drivers. If I reset Steam, it goes away for a bit, though.

Getting a lot of these in the terminal output, though:

IPC error: LockMgrMutex failed to acquire SysMgrMutex

 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top