http://bugs.winehq.org/show_bug.cgi?id=26998
João Ricardo Lourenço jorl17.8@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jorl17.8@gmail.com
--- Comment #10 from João Ricardo Lourenço jorl17.8@gmail.com 2011-07-13 11:03:15 CDT --- I too have seen this bug in many versions of Wine until today. I've bumped into it while running three different machines, each superior to the other. It seems to me that the CPU must be under around 75% usage for FM to start. On my current machine I manage to do that by using a script to launch FM that runs a stress application with "stress -c 24" (I usually compile with -j32, as I have 32 cores; Checking usage, I see it's around 75%). After running stress -c 24 and waiting for a fixed set of time, the script checks to see if FM opened correctly (by checking the title of the active window) and, if it did, it kills stress and leaves FM running, otherwise it kills FM and restarts this process.
On one of my other machines I didn't find the ideal "stress" options so I was about to quit, until I realized that running cat /dev/afrandom (it's made by a kernel module I made that does the same as /dev/urandom but only uses alpha-numeric characters) in the background would allow me to execute FM. When I look at CPU usage during these periods, it is between 60% and 80%, hence reaching the said 75% mark. I never managed to open FM while at ~0% usage or 100%. My third machine (the one were I originally ran FM) was always with a rather high CPU usage so I didn't notice this bug, except for a few times when it wouldn't start -- and those started being recurrent as I moved away from Gnome and KDE.
With these two scripts (they share code, with the exception that the one with /dev/afrandom registers the PID of cat and kills it after, instead of running pkill -sigkill stress), I manage to open FM almost always at the first try. If anyone wants me to share them I'm available.
Cheers, and happy Coaching!
Jorl17