http://bugs.winehq.org/show_bug.cgi?id=30307
--- Comment #5 from jbherman@gmail.com 2012-03-29 23:20:07 CDT --- after spending the greater part of a week investigating this issue, i can say most certainly it's not strictly external to wine. it's clearly an issue of wine interacting with the environment. The operating system has no limits on memory allocation and the problem in reproducible on multiple schedulers. My best guess is that some aspect of the environment influences the way wine loads libraries into memory in such a way that fragments the available space into small pieces or loads duplicate or unnecessary libraries. There is just no evidence that linux OS is actually refusing to provide memory.
this suggests debug messages regarding failed memory allocation would be invaluable, but I haven't found a way to produce or find them. ( debugging produced gigs of logs)
In my experience interaction issues can be some of the hardest to pin down.
From reading wine forums and bug dialogues it seems like this kind of issue is
more common with wine because of the nature of the beast OS+wine+app in the context of attempting to replicate windows, not just get it right. tough task!
i'm not experienced with filing bugs. it was blocking my work so i filed it as a blocker. In my opinion it's not minor because running on the scheduler is essential for my application as is ram >1GB. but whatever, major, minor i don't mind....
workaround: i think i have a way around the problem. Instead of just running the scheduled job, I schedule a script which ssh's right back to the machine and runs the job. This ssh session is apparently identical (in whatever respect is impacting wine) to the interactive shell, thus i get up to ~1.5GB ram. ugly, but easy enough and it seems to be working in early tests..
j