I've been doing some tests with the odd Dreamweaver problem that I originally thought was a regression and discovered the following:
1) If I compile the current CVS on my Mandriva 2005LE machine with gcc v.3.4.3, then install it to my Mandriva 2006 desktop, Dreamweaver works fine.
2) If I compile the current CVS on my Mandriva 2006 desktop with gcc v.4.0.1, then install it to that same machine, Dreamweaver hangs at the splash screen (with the app window in background). Other apps, like Steam and Counter-Strike: Source work fine under this install.
This is using the same .wine config directory and everything. I used "make clean" and "wineserver -k" between compiles.
When I was originally troubleshooting it as a Dreamweaver problem, I recall checking out a fresh copy of CVS and getting the same hangup symptoms under 4.0.1.
So, it appears that this might be caused by either a gcc 4.0.1 bug, or a bug in the WINE source that only becomes evident when compiled under gcc 4.0.1.
When I get home from work tonight I can do some traces to try to narrow the scope of investigation. Are there any trace options that would be particularly helpful to you devs?
Thanks, Jesse
On Tue, Nov 15, 2005 at 07:32:37AM -0600, Evil wrote:
I've been doing some tests with the odd Dreamweaver problem that I originally thought was a regression and discovered the following:
- If I compile the current CVS on my Mandriva 2005LE machine with gcc
v.3.4.3, then install it to my Mandriva 2006 desktop, Dreamweaver works fine.
- If I compile the current CVS on my Mandriva 2006 desktop with gcc
v.4.0.1, then install it to that same machine, Dreamweaver hangs at the splash screen (with the app window in background). Other apps, like Steam and Counter-Strike: Source work fine under this install.
This is using the same .wine config directory and everything. I used "make clean" and "wineserver -k" between compiles.
When I was originally troubleshooting it as a Dreamweaver problem, I recall checking out a fresh copy of CVS and getting the same hangup symptoms under 4.0.1.
So, it appears that this might be caused by either a gcc 4.0.1 bug, or a bug in the WINE source that only becomes evident when compiled under gcc 4.0.1.
When I get home from work tonight I can do some traces to try to narrow the scope of investigation. Are there any trace options that would be particularly helpful to you devs?
Such a miscompilation is either found by debugging the problem (which might be difficult here), or by reducing the testcase.
You could compile parts of WINE with gcc 4.0.1 and parts of it with gcc 3.4.3 and try to find out which part of WINE is miscompiled.
For instance, try to compilere everything with 3.4.3, except: dlls/ntdll and then check again.
Prime suspects: dlls/ntddl, server/, dlls/kernel, dlls/user
If you spotted it to one directory, you can reduce it to a file level.
Ciao, Marcus
Thanks for the direction, Marcus!
Following your suggestion, I've quickly narrowed the problem to user32.dll.so. If I can steal some time in the next few days, I'll see if I can get it down to the specific object file.
-Jesse Litton
Marcus Meissner wrote:
On Tue, Nov 15, 2005 at 07:32:37AM -0600, Evil wrote:
I've been doing some tests with the odd Dreamweaver problem that I originally thought was a regression and discovered the following:
- If I compile the current CVS on my Mandriva 2005LE machine with gcc
v.3.4.3, then install it to my Mandriva 2006 desktop, Dreamweaver works fine.
- If I compile the current CVS on my Mandriva 2006 desktop with gcc
v.4.0.1, then install it to that same machine, Dreamweaver hangs at the splash screen (with the app window in background). Other apps, like Steam and Counter-Strike: Source work fine under this install.
This is using the same .wine config directory and everything. I used "make clean" and "wineserver -k" between compiles.
When I was originally troubleshooting it as a Dreamweaver problem, I recall checking out a fresh copy of CVS and getting the same hangup symptoms under 4.0.1.
So, it appears that this might be caused by either a gcc 4.0.1 bug, or a bug in the WINE source that only becomes evident when compiled under gcc 4.0.1.
When I get home from work tonight I can do some traces to try to narrow the scope of investigation. Are there any trace options that would be particularly helpful to you devs?
Such a miscompilation is either found by debugging the problem (which might be difficult here), or by reducing the testcase.
You could compile parts of WINE with gcc 4.0.1 and parts of it with gcc 3.4.3 and try to find out which part of WINE is miscompiled.
For instance, try to compilere everything with 3.4.3, except: dlls/ntdll and then check again.
Prime suspects: dlls/ntddl, server/, dlls/kernel, dlls/user
If you spotted it to one directory, you can reduce it to a file level.
Ciao, Marcus
I've narrowed it down to dlls/user/win.c. If I link the gcc3.4.3 version of the object file (win.o) with all other objects being the gcc4.0.1 versions, Dreamweaver MX (v6.1) does not leave the splash screen hanging.
I ran a +win trace against both versions, but it's not immediately apparent to me exactly which function is behaving in a different manner on the newer compiler. I've uploaded the traces to http://www.eternaldusk.com/programming/win.c.debug.tar.gz, in case someone with a bit more understanding of win.c wants to take a look at them. "good" is the trace using the 3.4.3 object, and "bad" is the one using 4.0.1.
Below are the lines that immediately precede the hangup when using 4.0.1. I've not been able to easily identify the corresponding section of the "good" file, because these functions are all very common.
... trace:win:SetForegroundWindow 0x101ca trace:win:WIN_SetWindowLong 0x101ca 0 0 3 trace:win:GetWindowRect hwnd 0x101ca (429,468)-(851,556) trace:win:RedrawWindow 0x10154 rect (0,0)-(40,40) flags: RDW_INVALIDATE trace:win:RedrawWindow 0x10154 rect (0,0)-(40,40) flags: RDW_INVALIDATE trace:win:WIN_SetWindowLong 0x101ca 0 0 3 trace:win:SetForegroundWindow (nil) trace:win:WIN_SetWindowLong 0x101ca 0 0 3 trace:win:WIN_SetWindowLong 0x101ca 0 0 3 trace:win:WIN_SetWindowLong 0x101ca 0 0 3 trace:win:WIN_SetWindowLong 0x101ca 0 0 3 trace:win:WIN_SetWindowLong 0x10028 0 0 3 trace:win:WIN_SetWindowLong 0x101d0 0 0 3 trace:win:WIN_SetWindowLong 0x101ca 0 0 3
-Jesse Litton
Marcus Meissner wrote:
If you spotted it to one directory, you can reduce it to a file level.
Ciao, Marcus
"Evil" wine@eternaldusk.com wrote:
I've narrowed it down to dlls/user/win.c. If I link the gcc3.4.3 version of the object file (win.o) with all other objects being the gcc4.0.1 versions, Dreamweaver MX (v6.1) does not leave the splash screen hanging.
I ran a +win trace against both versions, but it's not immediately apparent to me exactly which function is behaving in a different manner on the newer compiler. I've uploaded the traces to http://www.eternaldusk.com/programming/win.c.debug.tar.gz, in case someone with a bit more understanding of win.c wants to take a look at them. "good" is the trace using the 3.4.3 object, and "bad" is the one using 4.0.1.
Does compiling with -O0 fix the problem?
Dmitry Timoshkov wrote:
Does compiling with -O0 fix the problem?
Unfortunately not. I disabled athlon-xp tuning, then compiled with -O0... first just win.c, then the entirety of WINE in case it was related to passed parameters... but get the exact same problem.
I've opened bug 3852 for tracking this, since I'm still unsure whether it's a compiler issue or a wine issue that only presents itself under the newer compiler.
I played with winedbg a little last night, but I'm not so familiar with WINE that I actually made any headway. When Dreamweaver hangs, It seems to just be stuck looping on WaitForMultipleObjects, expecting signals that never come. If anyone has suggestions for anything else I can try, or information I can provide, please let me know.
Thanks,
-Jesse
On Thu, Nov 17, 2005 at 07:32:19AM -0600, Evil wrote:
Dmitry Timoshkov wrote:
Does compiling with -O0 fix the problem?
Unfortunately not. I disabled athlon-xp tuning, then compiled with -O0... first just win.c, then the entirety of WINE in case it was related to passed parameters... but get the exact same problem.
Are you passing any other compiler flags?
I've opened bug 3852 for tracking this, since I'm still unsure whether it's a compiler issue or a wine issue that only presents itself under the newer compiler.
I played with winedbg a little last night, but I'm not so familiar with WINE that I actually made any headway. When Dreamweaver hangs, It seems to just be stuck looping on WaitForMultipleObjects, expecting signals that never come. If anyone has suggestions for anything else I can try, or information I can provide, please let me know.
It would need some hands-on debugging I am afraid.
Ciao, Marcus
Marcus Meissner wrote:
Are you passing any other compiler flags?
I've not configured anything beyond the defaults, it's pretty plain at this point:
gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_USER32_ -D_WINABLE_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -O0 -o win.o win.c
-Jesse
On Thu, 17 Nov 2005 14:32:19 +0100, Evil wine@eternaldusk.com wrote:
Dmitry Timoshkov wrote:
Does compiling with -O0 fix the problem?
Unfortunately not. I disabled athlon-xp tuning, then compiled with -O0... first just win.c, then the entirety of WINE in case it was related to passed parameters... but get the exact same problem.
I've opened bug 3852 for tracking this, since I'm still unsure whether it's a compiler issue or a wine issue that only presents itself under the newer compiler.
I played with winedbg a little last night, but I'm not so familiar with WINE that I actually made any headway. When Dreamweaver hangs, It seems to just be stuck looping on WaitForMultipleObjects, expecting signals that never come. If anyone has suggestions for anything else I can try, or information I can provide, please let me know.
Thanks,
-Jesse
Does this apply to all gcc-4.x ?
On Thu, 17 Nov 2005 14:32:19 +0100, Evil wine@eternaldusk.com wrote:
Dmitry Timoshkov wrote:
Does compiling with -O0 fix the problem?
Unfortunately not. I disabled athlon-xp tuning, then compiled with -O0... first just win.c, then the entirety of WINE in case it was related to passed parameters... but get the exact same problem.
I've opened bug 3852 for tracking this, since I'm still unsure whether it's a compiler issue or a wine issue that only presents itself under the newer compiler.
I played with winedbg a little last night, but I'm not so familiar with WINE that I actually made any headway. When Dreamweaver hangs, It seems to just be stuck looping on WaitForMultipleObjects, expecting signals that never come. If anyone has suggestions for anything else I can try, or information I can provide, please let me know.
Thanks,
-Jesse
Have you tried 4.0.2 ? This seems to be the version adopted by distros using gcc4.
I am rebuilding Gentoo with 4.1-beta . When I get to wine I'll post if I get the bug.
regards.
wino@piments.com wrote:
Have you tried 4.0.2 ? This seems to be the version adopted by distros using gcc4.
I am rebuilding Gentoo with 4.1-beta . When I get to wine I'll post if I get the bug.
regards.
Mandriva 2006 ships with 4.0.1 and does not have an official package for 4.0.2 as of yet.
-Jesse
Anyone working on getting wine to work on gcc-4.xx?
On Wed, 23 Nov 2005 01:14:17 +0100, Evil wine@eternaldusk.com wrote:
wino@piments.com wrote:
Have you tried 4.0.2 ? This seems to be the version adopted by distros using gcc4.
I am rebuilding Gentoo with 4.1-beta . When I get to wine I'll post if I get the bug.
regards.
Mandriva 2006 ships with 4.0.1 and does not have an official package for 4.0.2 as of yet.
-Jesse
On Sat, Dec 10, 2005 at 11:43:38AM +0100, peter@piments.com wrote:
Anyone working on getting wine to work on gcc-4.xx?
It works fine on gcc 4.0, gcc 4.1 and also current 4.2 development branch.
Ciao, Marcus
peter@piments.com wrote:
Anyone working on getting wine to work on gcc-4.xx?
Not I. It's not really a showstopper for me since it only affects Dreamweaver and I can compile with 3.4 to get around it at the moment. I wouldn't be worried about it unless other apps have problems too.
I'll retest when newer gcc (to determine if it's strictly a 4.01 bug) sometime down the road when I have more time, but it won't be anytime soon.
-J