http://bugs.winehq.org/show_bug.cgi?id=7140
------- Additional Comments From mook.moz+sites.org.winehq.bugs@gmail.com 2007-08-05 23:25 ------- foo@localhost:~> ulimit -Sa core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 4095 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 438855 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4095 virtual memory (kbytes, -v) 1252080 file locks (-x) unlimited foo@localhost:~> ulimit -Ha core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 4095 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 8192 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 4095 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Of course, I still have no idea why setting the soft stack limit higher broke things :) (Umm, comment #6 was doing from a vanilla bash shell outside of make; I should have specified that clearer, sorry.)
For what it's worth, wine can certainly use large amounts of memory just fine. (Running the MSVC linker trying to build Mozilla Firefox does that... sigh.)
Also, yes, I am running a local workaround that sets stack size before trying to run wine; that helps me, but doesn't exactly fix wine :)