[Linux] Game won't stop :: Disgaea 2 PC Troubleshooting

商店页面

Disgaea 2 PC

全部讨论截图艺术作品实况直播视频新闻指南评测

Disgaea 2 PC > Troubleshooting > 主题详情

3zekiel

2017 年 4 月 4 日上午 7:26

[Linux] Game won't stop

Hey, so far experience has been quite great. However, there is one nagging bug, the game just does not want to stop correctly. Whether I use alt+f4 or "quit", game will begin to stop, show a black screen and then freeze, I can force stop it, but it will not die on its own.

I am on archlinux Latest.
CPU core i7-6500U with its integrated gpu(520). I run gnome on wayland.

Thanks a bunch in advance for reading this post,
Yours sincerly,
3zekiel.

< >

正在显示第 1 - 3 条，共 3 条留言

SimicEngineer 拥有 Disgaea 2 PC

2017 年 10 月 28 日下午 6:53

I'm also seeing this on Arch Linux. A pair of threads seems to be stuck with one waiting for a condition variable and the other destroying a condition variable (no symbols, so I can't tell if they're the same variable or not; that would be a bug in the game, but I think glibc normally returns an error in that case rather than just hanging):

Thread 2 (Thread 0x7f82fdab4700 (LWP 1893)): #0 0x00007f831fcae38d in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x000000000046520d in CEventFlag::wait() () #2 0x00000000004742f8 in CFileMgrMlt::checkAsyncEnd() () #3 0x0000000000474395 in CFileMgrMlt::s_asyncEndCheckThread(void*) () #4 0x00007f831fca808a in start_thread () from /usr/lib/libpthread.so.0 #5 0x00007f831ecea24f in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7f8322478740 (LWP 1890)): #0 0x00007f831fcade39 in pthread_cond_destroy@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00000000004651a9 in CEventFlag::~CEventFlag() () #2 0x000000000046ed58 in CFileMgrMlt::~CFileMgrMlt() () #3 0x000000000045b820 in SteamLibFinalize() () #4 0x00000000004597be in main ()

Edit: switched to a distro that actually ships debug symbols (Ubuntu 17.10) to get a non-stupid backtrace, incidentally proving that this bug is not specific to Arch:

Thread 2 (Thread 0x7f0a0df5d700 (LWP 15659)): #0 0x00007f0a337ea072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7f0a2df5df70) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7f0a2df5df78, cond=0x7f0a2df5df48) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x7f0a2df5df48, mutex=0x7f0a2df5df78) at pthread_cond_wait.c:655 #3 0x000000000046520d in CEventFlag::wait() () #4 0x00000000004742f8 in CFileMgrMlt::checkAsyncEnd() () #5 0x0000000000474395 in CFileMgrMlt::s_asyncEndCheckThread(void*) () #6 0x00007f0a337e37fc in start_thread (arg=0x7f0a0df5d700) at pthread_create.c:465 #7 0x00007f0a32811b0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f0a361f1f40 (LWP 15656)): #0 0x00007f0a337e9b51 in futex_wait (private=<optimized out>, expected=12, futex_word=0x7f0a2df5df6c) at ../sysdeps/unix/sysv/linux/futex-internal.h:61 #1 futex_wait_simple (private=<optimized out>, expected=12, futex_word=0x7f0a2df5df6c) at ../sysdeps/nptl/futex-internal.h:135 #2 __pthread_cond_destroy (cond=0x7f0a2df5df48) at pthread_cond_destroy.c:54 #3 0x00000000004651a9 in CEventFlag::~CEventFlag() () #4 0x000000000046ed58 in CFileMgrMlt::~CFileMgrMlt() () #5 0x000000000045b820 in SteamLibFinalize() () #6 0x00000000004597be in main ()

So they are both blocked on the same condition variable, but not the same futex_word (though those are presumably pthreads guts that are well outside of my expertise).

Edit 2: There might have been a change in glibc 2.25 that causes a deadlock in this situation where older versions returned from pthread_cond_destroy(). See https://sourceware.org/bugzilla/show_bug.cgi?id=21374 and
https://github.com/pytorch/pytorch/issues/1233

This would explain why the problem was first seen in Arch, but it will presumably become more common as more people upgrade to Ubuntu 17.10, Fedora 26/27, etc..

最后由 SimicEngineer 编辑于; 2017 年 11 月 1 日下午 7:55

Countersync 拥有 Disgaea 2 PC

2017 年 11 月 25 日上午 12:38

Thank you for that wonderful work. Though it is a change in glibc, I agree that this is a bug in Disgaea 2. It seems like the behavior that now exists is proper and that some race condition exists.

Unfortunately using taskset to pin the executable to a single core does not fix the issue, so the issue exists even with no hardware race conditions. There's just some literal bug.

SimicEngineer 拥有 Disgaea 2 PC

2017 年 11 月 25 日下午 4:00

Yeah, this falls into what Unix/C nerds call undefined behavior:

It shall be safe to destroy an initialized condition variable upon which no threads are currently blocked. Attempting to destroy a condition variable upon which other threads are currently blocked results in undefined behavior.

That term has a special meaning in these kinds of standards that means something along the lines of: you have invoked bad magic and torn a hole in the universe, and literally anything can happen. In standards conformance terms, the system is within its rights to reformat your hard drive and install Windows 3.1.

< >

正在显示第 1 - 3 条，共 3 条留言

每页显示数： 1530 50

Disgaea 2 PC > Troubleshooting > 主题详情

发帖日期： 2017 年 4 月 4 日上午 7:26

回复数： 3