Help solving Bug 434

Rick Romero rick at valeoinc.com
Tue Sep 3 14:04:04 CDT 2002


Hello all,

I'm taking yet another look at bug 434, where a left mouse click won't 
release in Visual FoxPro.

Alexandre applied a patch on 6/13/02 that fixed the issue for the opener 
of the bug, but is general issue still exists for me, I havn't heard from the 
submitter of the Illustrator 8 report.

First question:
Since the original report has been resolved, should a new report be opened?

Second:
I feel like the solution is pretty close, but I'm probably treading water 
in deep fog, FEELING like I'm getting close to shore :)

The one weird thing that I can't figure out is why I can run 
wine --debugmsg +scroll,+event,+toolbar,+gdi,+heap /mnt/windows/DevStu
dio/vfp/vfp.exe
and have the button up WORK for a few clicks.  If I hold the button down, then 
release, the issue occurs.  Since the mouse issue started when input functions
were moved into the wine server, it makes sense to me that there might be some 
issue related to synchro.c as shown below in gdb output.

------- Additional Comments From rick at havokmon.com  2002-08-31 21:22 -------
Ok - ivanovich at menta.net determined the fix for Flash 5 to 
be patch at:
http://www.winehq.com/hypermail/wine-cvs/2002/06/0098.html
from 6/14/02.

This patch does not affect the mousebutton issue in Visual FoxPro, but his posts
on using gdb now make sense to me..
Using Wine-20020804.

wine test.exe (using vfp5test.zip - Installer works now!) 
	- available from Bug Report

Here's my output of GDB:
(gdb) bt
#0  0x402ddfe4 in read () from /lib/i686/libc.so.6
#1  0x40102130 in __JCR_LIST__ () from /usr/local/lib/libntdll.dll.so
#2  0x400c6cac in WaitForMultipleObjectsEx (count=1095856128, handles=0x0,
wait_all=0, timeout=220, alertable=0)
    at ../../scheduler/synchro.c:265
#3  0x400c69e1 in Sleep (timeout=220) at ../../scheduler/synchro.c:178
#4  0x10001011 in ?? ()
#5  0x400c704e in SYSDEPS_StartThread (teb=0x41517000) at
../../scheduler/sysdeps.c:158
(gdb) n
Single stepping until exit from function read,
which has no line number information.
wait_reply (cookie=0x41506e58) at ../../scheduler/synchro.c:96
96              if (ret == sizeof(reply))
(gdb) n
98                  if (!reply.cookie) break;  /* thread got killed */
(gdb) n
99                  if (reply.cookie == cookie) return reply.signaled;
(gdb) n
0x400c6cac in WaitForMultipleObjectsEx (count=259, handles=0x0, wait_all=0,
timeout=220, alertable=0)
    at ../../scheduler/synchro.c:265
265             ret = WAIT_FAILED;
(gdb) n
258             if (ret != STATUS_USER_APC) break;
(gdb) n
262         if (HIWORD(ret))  /* is it an error code? */
(gdb) n
267         return ret;
(gdb) n
268     }
(gdb) n
Sleep (timeout=220) at ../../scheduler/synchro.c:179
179     }
(gdb) n

Here, just like ivanovich at menta.net's post, the gdb hangs and the wine process
takes 100% cpu.  If the scheduler is not working properly
with FoxPro, that might explain the weird 'Slowness Solution' I described above,
with extra debug info delaying the button up issue.

If I ctrl-C and detach from that process, and attach to a second wine process, 
I get:

(gdb) bt
#0  0x402de024 in write () from /lib/i686/libc.so.6
#1  0x40997d48 in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6
#2  0x4092122f in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6
#3  0x40904bc2 in _XScreenOfWindow () from /usr/X11R6/lib/libX11.so.6
#4  0x40902717 in _XReply () from /usr/X11R6/lib/libX11.so.6
#5  0x408f881b in XQueryPointer () from /usr/X11R6/lib/libX11.so.6
#6  0x40893452 in TSXQueryPointer (a0=0x809e030, a1=70, a2=0x405a5cbc,
a3=0x405a5cc0, a4=0x405a5cc4,
    a5=0x405a5cc8, a6=0x405a5ccc, a7=0x405a5cd0, a8=0x405a5cd4) at ts_xlib.c:846
#7  0x4086e1a8 in X11DRV_GetCursorPos (pos=0x405a5d20) at mouse.c:514
#8  0x406a55a8 in GetCursorPos (pt=0x8) at ../../windows/input.c:476
#9  0x10008fc7 in ?? ()
#10 0x101aa657 in ?? ()
(gdb) n
Single stepping until exit from function write,
which has no line number information.
0x40922050 in _X11TransGetConnectionNumber () from /usr/X11R6/lib/libX11.so.6
(gdb) n
Single stepping until exit from function _X11TransGetConnectionNumber,
which has no line number information.
0x4092122f in _X11TransWrite () from /usr/X11R6/lib/libX11.so.6
(gdb) n
Single stepping until exit from function _X11TransWrite,
which has no line number information.
0x40904bc2 in _XScreenOfWindow () from /usr/X11R6/lib/libX11.so.6
(gdb) n
Single stepping until exit from function _XScreenOfWindow,
which has no line number information.
0x40902717 in _XReply () from /usr/X11R6/lib/libX11.so.6
(gdb) n
Single stepping until exit from function _XReply,
which has no line number information.
0x408f881b in XQueryPointer () from /usr/X11R6/lib/libX11.so.6
(gdb) n
Single stepping until exit from function XQueryPointer,
which has no line number information.
TSXQueryPointer (a0=0x809e030, a1=70, a2=0x405a5cbc, a3=0x405a5cc0,
a4=0x405a5cc4, a5=0x405a5cc8, a6=0x405a5ccc,
    a7=0x405a5cd0, a8=0x405a5cd4) at ts_xlib.c:847
847       wine_tsx11_unlock();
(gdb) n
846       r = XQueryPointer(a0, a1, a2, a3, a4, a5, a6, a7, a8);
(gdb) n
847       wine_tsx11_unlock();
(gdb) n
849     }
(gdb) n
X11DRV_GetCursorPos (pos=0x405a5d20) at mouse.c:518
518       update_key_state( xstate );
(gdb) n
519       TRACE("pointer at (%d,%d)\n", winX, winY );
(gdb) n
520       pos->x = winX;
(gdb) n
521       pos->y = winY;
(gdb) n
522     }
(gdb) n
0x406a55a8 in GetCursorPos (pt=0x40887b03) at ../../windows/input.c:476
476     }
(gdb) n
475         return 1;
(gdb) n
476     }
(gdb) n

Here, just like ivanovich at menta.net's post, the gdb hangs and the wine process
takes 100% cpu.

I tried putting a while loop in synchro.c, so that it would loop until
!(HIWORD(ret)), but I did something wrong:
--- synchro.c line 231
    int ret, cookie,testparm;
    struct timeval tv;
    testparm = 0;
while (testparm == 0){
    testparm = 1;
    if (count > MAXIMUM_WAIT_OBJECTS)
...
...
    if (HIWORD(ret))  /* is it an error code? */
    {
        SetLastError( RtlNtStatusToDosError(ret) );
        ret = WAIT_FAILED;
        testparm = 0;
    }
}
return ret;
---
I don't know if something like that would actually work, but my last gdb step
through showed testparm set to 0 before returning ret ;) - so I whatever I did,
I didn't do it right.

------- End Comments From rick at havokmon.com  2002-08-31 21:22 -------

Any direction to take would be greatly appreciated.

Thanks

Rick



-- 
--
Rick Romero
IT Manager	
Valeo, Inc.	ph: 262.695.4841
Sussex, WI.	fax: 262.695.4850
Rick at valeoinc.com




More information about the wine-devel mailing list