I tried to start pcsx2, and it just crashed. It locked up hard with the only clickable button to close everything. No pause, no debug logs, just close. See attached screenshots.
Created attachment 442818 [details] what little I could get from the console screen (no pun intended)
Created attachment 442820 [details] The lone clickable dialog box, also apparently has some information.
Also got this error about the recompiler: * microVU1 Thread creation failure. An unspecified error occurred while trying to create the MTVU thread.
Please post your emerge --info games-emulation/pcsx2
Created attachment 442892 [details] emerge --info
Live (9999) version of ebuild works for you?
Nope, my next step was to upgrade to 9999 and I got the exact same problem, actually.
Try to run /usr/bin/PCSX2 from console and paste output here
Interface is initializing. Entering Pcsx2App::OnInit! Applying operating system default language... Command line parsing... Command line parsed! Thread creation failure. An unspecified error occurred while trying to create the Redirect_Stderr thread. Trace/breakpoint trap (core dumped)
I reported this issue upstream.
(In reply to shentino from comment #9) > Thread creation failure. An unspecified error occurred while trying to > create the Redirect_Stderr thread. > Trace/breakpoint trap (core dumped) From upstream report: > How to debug this issue properly? Since you have a coredump, I recommend these two articles to begin with https://wiki.gentoo.org/wiki/Bugzilla/Guide#Debugging_using_GDB https://wiki.gentoo.org/wiki/Debugging
From upstream: "So it feels like a security policy is set somewhere to avoid fork bomb, however the limit is too low for PCSX2 which use lots of thread." Please post this info: 1. ulimit -a 2. cat /proc/sys/kernel/threads-max 3. cat /proc/sys/kernel/pid_max 4. ps -eLf | wc -l Also please add vortex overlay and try pcsx2 build from debug upstream branch: 1. layman -a vortex (or add it via repos.conf - instructions: https://github.com/nE0sIghT/vortex-overlay) 2. emerge -1av =games-emulation/pcsx2-9999-r1 3. Run PCSX2 and post all error messages (from console and from PCSX2 windows)
Ulimit -a: core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 62911 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 1048576 cpu time (seconds, -t) unlimited max user processes (-u) 62911 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ---- cat /proc/sys/kernel/threads-max: 125823 ---- cat /proc/sys/kernel/pid_max 32768 ---- ps -eLf | wc -l (without pcsx2) 409 (with pcsx2) 411
emerged and ran the upstream version you requested. Console output: Interface is initializing. Entering Pcsx2App::OnInit! Applying operating system default language... Command line parsing... Command line parsed! Thread creation error: Cannot allocate memory Trace/breakpoint trap (core dumped)
Created attachment 443182 [details] updated screenshot of debug console
Created attachment 443184 [details] Backtrace I'm not sure this backtrace will actually help much, because it bugs out a couple of dialogs before it dumps core.
I will not have access to my Gentoo PC until monday, however ulimit looks good for me. Indeed, there is some (mb kernel?) limit in place. Please post your kernel config
Created attachment 443226 [details] /proc/config.gz
I noticed upstream was concerned about my stack size. I have my stack ulimit set to 1G instead of the default 8M.
I have reproduced this problem with stack size set to your value - 1048576. With default value of 8192 there is not problem.
From `man pthread_create`: "Under the NPTL threading implementation, if the RLIMIT_STACK soft resource limit at the time the program started has any value other than "unlimited", then it determines the default stack size of new threads." If I understand this correctly any posix thread (with default stack size) in your system will consume at least 1 GiB of RAM. I do not think you do correct things with such settings. There is also same bug report in Mozilla BT: https://bugzilla.mozilla.org/show_bug.cgi?id=423663 with comment: "The administrator should not increase the maximum stack size system limits to the high values mentioned in this bug (1GB, 0.5GB, and 0.2 GB). Applications should not need to defend against such administrator mistakes. Many other programs will crash or fail to run on these misconfigured systems". So I think this is "WONTFIX".
I noticed that upstream closed it already.
That said, having NPTL set its default stack size to the soft ulimit was a surprise. Is there any place this behavior should be documented?
I saw notice in `man pthread_create` only. I think you can find most correct answer in Glibc (or Kernel?) mailing lists.
