http://bugs.winehq.org/show_bug.cgi?id=34070
Bug #: 34070 Summary: 'fixme:win:alloc_winproc too many winprocs' prevents simutronics StormFront.exe from updating widgets Product: Wine Version: unspecified Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: matt@tolton.com Classification: Unclassified
Created attachment 45293 --> http://bugs.winehq.org/attachment.cgi?id=45293 Debug log
This bug is about StormFront.exe from Simutronics. The application works fine for awhile, but at some point certain widgets in the app stop updating. I believe this is due to the message I'm seeing in the debug log (see attached):
fixme:win:alloc_winproc too many winprocs
The time it starts appearing coincides with the widgets not updating. The longer that the application runs, the more messages that are emitted. I ran it for about 4 hours and saw around 20k messages.
I did some code spelunking and tracked it down to this file: https://github.com/mirrors/wine/blob/master/dlls/user32/winproc.c#L298
It seems like MAX_WINPROCS could be increased, and it might alleviate the problem, but would probably just make it take longer to manifest. (Since it only manifests after using the app for a little while, now).
I am using Crossover Mac 12.2.0 (I am not sure which version of wine this is).
My question is twofold: 1) How hard would it be to actually reclaim these winprocs rather than leak them? 2) If that doesn't work, is there some way for me to increase the MAX_WINPROCS constant and recompile user32.dll to use for just one bottle in CrossOver?
http://bugs.winehq.org/show_bug.cgi?id=34070
Matt matt@tolton.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matt@tolton.com
http://bugs.winehq.org/show_bug.cgi?id=34070
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.play.net/softwar | |e/StormFront.exe CC| |dank@kegel.com
--- Comment #1 from Dan Kegel dank@kegel.com 2013-07-15 22:43:27 CDT --- bug 32451 looks similar.
A WINEDEBUG=+win log might be of interest.
http://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #2 from Dan Kegel dank@kegel.com 2013-07-15 22:44:06 CDT --- Oh, but you should do that with plain wine, not crossover, if you want support here. Crossover support is handled by http://codeweavers.com.
http://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #3 from Matt matt@tolton.com 2013-07-16 01:44:32 CDT --- Okay, I reproduced the issue in vanilla wine and captured a log with WINEDEBUG=+win. By the time the problem occurred, the log was about 500M, so I uploaded it to dropbox. If you'd like me to trim it in some way and attach it to the bug, I'd be happy to.
https://www.dropbox.com/s/etwkgtdg8ontzs7/winelog.txt
http://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #4 from Matt matt@tolton.com 2013-07-16 01:48:11 CDT --- Also, one thing to note about the log: The initial binary that is run is not StormFront.exe, it is another binary which ends up launching StormFront.exe. So, the very first part of the log contains alloc_winproc calls for several different binaries.
http://bugs.winehq.org/show_bug.cgi?id=34070
Roland Haeder roland@mxchange.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roland@mxchange.org
http://bugs.winehq.org/show_bug.cgi?id=34070
Mike mrashkovsky@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrashkovsky@gmail.com
--- Comment #5 from Mike mrashkovsky@gmail.com --- Are there any workarounds for this? Finding it pretty difficult to play Gemstone like this when the windows are giving me out-of-date information.
http://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #6 from Mike mrashkovsky@gmail.com --- Having this issue under Wine in Linux by the way.
http://bugs.winehq.org/show_bug.cgi?id=34070
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |focht@gmx.net Version|unspecified |1.6 Summary|'fixme:win:alloc_winproc |Simutronics |too many winprocs' prevents |'StormFront.exe' runs out |simutronics StormFront.exe |of wndproc slots |from updating widgets |(ActiveSkin control) Ever confirmed|0 |1
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
Increasing the number of slots won't help you much.
There is an ActiveX control 'actskin4.ocx' (ActiveSkin) that causes new winproc allocation/leakage on many actions. It's popular with VB6 apps but doesn't add real value besides some fancy skins.
Start the app and do plain menu actions, e.g. open 'about' or other menu items. It will leak wndprocs on every action.
--- snip --- $ WINEDEBUG=+tid,+seh,+loaddll,+win wine ./StormFront.exe /GGS /H127.0.0.1 /P56730 /Kd0d83b8e7bc8b03ae5770673e7dd51be 2>&1 | grep alloc_winproc --- snip ---
--- snip --- Wine-dbg>bt
Backtrace: =>0 0x7ebbf469 alloc_winproc+0x81(func=0xc22d4c, unicode=0) [/home/focht/projects/wine/wine.repo/src/dlls/user32/winproc.c:160] in user32 (0x0033f238) 1 0x7ebbfa15 WINPROC_AllocProc+0x17(func=0xc22d4c, unicode=0) [/home/focht/projects/wine/wine.repo/src/dlls/user32/winproc.c:311] in user32 (0x0033f268) 2 0x7ebb2f55 WIN_SetWindowLong+0x414(hwnd=0x500bc, offset=0xfffffffc, size=0x4, newval=0xc22d4c, unicode=0) [/home/focht/projects/wine/wine.repo/src/dlls/user32/win.c:2384] in user32 (0x0033f378) 3 0x7ebb374f SetWindowLongA+0x2e(hwnd=0x500bc, offset=0xfffffffc, newval=0xc22d4c) [/home/focht/projects/wine/wine.repo/src/dlls/user32/win.c:2595] in user32 (0x0033f3ac) 4 0x0034dc85 in actskin4 (+0xdc84) (0x0033f3e4) 5 0x0036ec30 in actskin4 (+0x2ec2f) (0x0033f42c) 6 0x0035bd21 in actskin4 (+0x1bd20) (0x0033f450) 7 0x0042da01 in stormfront (+0x2da00) (0x000500bc) --- snip ---
Could be a hooking problem (procs should be freed on destruction) or just garbage app code that is worked around by Windows.
$ sha1sum StormFront.exe 52e0de759bfb5592c4ffac3ace5e90bfe6d8cd2c StormFront.exe
$ du -sh StormFront.exe 3.1M StormFront.exe
$ wine --version wine-1.7.20
Regards
https://bugs.winehq.org/show_bug.cgi?id=34070
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com
--- Comment #8 from Piotr Caban piotr.caban@gmail.com --- The bug should be fixed by following commit: c9ae38e4c77023eeb3e3bd49dd4506943e19d37e
Please retest with current git wine or with wine 1.9.6 when it's out.
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #13 from Mike mrashkovsky@gmail.com --- So I just tried this myself and I created a free account. Unfortunately it looks like the website doesn't offer StormFront as a client option. I'm not sure how they are detecting whether or not you have StormFront installed, but I suspect that it's not going to work under Linux.
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #16 from Matt matt@tolton.com --- This is awesome. Thanks much to Piotr (?) for fixing it!
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #9 from Nikolay Sivov bunglehead@gmail.com --- I'm not sure to retest this, on launch StormFront.exe shows a message box telling me I should be using website to login to some game. Was it always like that?
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #10 from Matt matt@tolton.com --- I haven't tried this in awhile and don't currently have a wine installation, but I can do so if needed. I believe that as long as you are able to click on menus and open/close windows, that you would be able to get this problem to manifest. It doesn't matter whether you're logged in or not.
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #11 from Nikolay Sivov bunglehead@gmail.com --- Thing is that I don't get any GUI, if I agree to visit website it opens a browser and exits, if I don't - it exits immediately.
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #12 from Matt matt@tolton.com --- You can sign up for a free account, doesn't require any credit card:
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #14 from Matt matt@tolton.com --- Use this program to login:
http://www.play.net/gs4/play/sge-info.asp
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #15 from Mike mrashkovsky@gmail.com --- Cool I think it may be fixed, then. I walked all around town for a few minutes. Probably cycled through 100 rooms or so, and the box that displays the room description continued to update without issue. I also stowed and unstowed various items and the inventory box updated. I toggled some boxes to display on and off a few times and no problem. Seems to be working pretty well
https://bugs.winehq.org/show_bug.cgi?id=34070
--- Comment #17 from Mike mrashkovsky@gmail.com --- Yeah, awesome work, thanks!!
https://bugs.winehq.org/show_bug.cgi?id=34070
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |c9ae38e4c77023eeb3e3bd49dd4 | |506943e19d37e Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #18 from Piotr Caban piotr.caban@gmail.com --- Marking as fixed. Thanks for testing.
https://bugs.winehq.org/show_bug.cgi?id=34070
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #19 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.8.
https://bugs.winehq.org/show_bug.cgi?id=34070
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@redhat.com Target Milestone|--- |1.8.x
https://bugs.winehq.org/show_bug.cgi?id=34070
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |---
--- Comment #20 from Michael Stefaniuc mstefani@redhat.com --- Removing 1.8.x milestone from bugs included in 1.8.3.