August 2002 - Wine-Devel - list.winehq.org

Re: Recent patches introduced a regression error

by Sylvain Petreolle

make test sudenly pass a minute ago, without reason. rerunning make testclean ; make test freezes. then i ctrl-c, rerun make test and the test randomly freezes/ fails on line 176. --- Sylvain Petreolle <spetreolle(a)yahoo.fr> a écrit : > > > So, Sylvain, when you run the tests now, does it eventually > time-out > > returning a error, or does it freeze forever? > > > it freezes forever now. (just updated/recompiled CVS 10 min ago) > also running it under gdb gives this result: > > (gdb) run test > Starting program: /usr/bin/make test > (no debugging symbols found)...(no debugging symbols found)... > ../../programs/winetest/runtest -q -P wine -M wininet.dll -T ../.. -p > tests/wininet_test.exe.so tests/http.c && touch tests/http.ok > tests/http.c:176: Test failed: InternetCloseHandle failed > make: *** [tests/http.ok] Erreur 1 > (no debugging symbols found)... > Program exited with code 02. > (gdb) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 2, 2002

Re: Recent patches introduced a regression error

by Sylvain Petreolle

> So, Sylvain, when you run the tests now, does it eventually time-out > returning a error, or does it freeze forever? > it freezes forever now. (just updated/recompiled CVS 10 min ago) also running it under gdb gives this result: (gdb) run test Starting program: /usr/bin/make test (no debugging symbols found)...(no debugging symbols found)... ../../programs/winetest/runtest -q -P wine -M wininet.dll -T ../.. -p tests/wininet_test.exe.so tests/http.c && touch tests/http.ok tests/http.c:176: Test failed: InternetCloseHandle failed make: *** [tests/http.ok] Erreur 1 (no debugging symbols found)... Program exited with code 02. (gdb) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 1, 2002

[breakage] Set the correct permissions on the PE image sections.

by Uwe Bonnes

Hallo, the patch http://cvs.winehq.com/patch.py?id=1027987166850574216879071 "Set the correct permissions on the PE image sections" breaks the propsheet handling on the xilinx webpack suite. When a propsheet should be opened, appended backtrace appears. PROPSHEET_CreatePage writes to ppshpage->u.pResource when PSP_DLGINDIRECT is set. MSDN also tells that applications will break if pResource is not writable. It seems that above patch maps the resource section write protected. Info segments doesn't tell about a range including 0x00467390, info maps tells about VirtualQueryEx Unsupported . Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- First chance exception: page fault on write access to 0x00467390 in 32-bit code (0x408c888c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:408c888c ESP:405c6080 EBP:405c60c4 EFLAGS:00010202( R- 00 I - - 1 ) EAX:40000440 EBX:409203dc ECX:00000000 EDX:4092021d ESI:00467390 EDI:41552098 Stack dump: 0x405c6080 (_end+0x117800): 409203dc 00000000 00000000 00010056 0x405c6090 (_end+0x117810): 405c60c4 00000000 00010056 0000130c 0x405c60a0 (_end+0x117820): 00000000 41552070 00000000 ffffffff 0x405c60b0 (_end+0x117830): 405c60c0 409203dc 4092021d 00000000 0x405c60c0 (_end+0x117840): 00000000 405c6108 408c9587 00020051 0x405c60d0 (_end+0x117850): 00000000 40400788 41552098 409203dc 0x405c60e0 (_end+0x117860): 0011: sel=008f base=4010f1c0 limit=00000fff 32-bit rw- Backtrace: =>0 0x408c888c (PROPSHEET_CreatePage+0xec(hwndParent=0x20051, index=0x0, psInfo=0x40400788, ppshpage=0x41552098) [propsheet.c:1239] in comctl32.dll.so) (ebp=405c60c4) 1 0x408c9587 (PROPSHEET_SetCurSel+0x127(hwndDlg=0x20051, index=0x0, skipdir=0x1, hpage=0x41552098) [propsheet.c:1773] in comctl32.dll.so) (ebp=405c6108) 2 0x408cabc0 (PROPSHEET_DialogProc+0x320(hwnd=0x20051, uMsg=0x110, wParam=0x10052, lParam=0x40400788) [propsheet.c:2591] in comctl32.dll.so) (ebp=405c6330) 3 0x40755cfb (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=405c6354) 4 0x40755d9f (WINPROC_CallWndProc+0x8f(proc=0x408ca8a0, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:183] in user32.dll.so) (ebp=405c6384) 5 0x4075c3b7 (CallWindowProcW+0xa7(func=0x414012f8, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2836] in user32.dll.so) (ebp=405c63ac) 6 0x4072ce71 (DefDlgProcW+0x51(hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788, hwnd=0x20051) [defdlg.c:405] in user32.dll.so) (ebp=405c63d8) 7 0x40755cfb (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=405c63fc) 8 0x40755d9f (WINPROC_CallWndProc+0x8f(proc=0x4072ce20, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:183] in user32.dll.so) (ebp=405c642c) 9 0x4075bd26 (WINPROC_CallProc32ATo32W+0xc6(func=0x4072ce20, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2592] in user32.dll.so) (ebp=405c6458) 10 0x4075c2d7 (CallWindowProcA+0xa7(func=0x414001f6, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2800] in user32.dll.so) (ebp=405c6480) 11 0x5f446f6b (MFC42.DLL.?DefWindowProcA(a)CWnd@@MAEJIIJ(a)Z+0x42 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c64a0) 12 0x5f446603 (MFC42.DLL.?Default(a)CWnd@@IAEJXZ+0x25 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c64f4) 13 0x0042b8ef (_pn.exe.??4RticStore@@QAEAAV0(a)ABV0@@Z+0xa8af in I:\xilinx\bin\nt\_pn.exe) (ebp=405c6594) 14 0x5f447664 (MFC42.DLL.?WindowProc(a)CWnd@@MAEJIIJ(a)Z+0x45 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c65bc) 15 0x5f446546 (MFC42.DLL.?AfxCallWndProc@@YGJPAVCWnd@@PAUHWND__@@IIJ(a)Z+0x90 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c661c) 16 0x5f446749 (MFC42.DLL.?AfxWndProc@@YGJPAUHWND__@@IIJ(a)Z+0x2b in I:\XILINX\MFC\MFC42.DLL) (ebp=405c6638) 17 0x5f46f12b (MFC42.DLL.?AfxWndProcBase@@YGJPAUHWND__@@IIJ(a)Z+0x39 in I:\XILINX\MFC\MFC42.DLL) (ebp=405c6664) 18 0x40755cfb (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=405c6688) 19 0x40755d9f (WINPROC_CallWndProc+0x8f(proc=0x5f46f0f2, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:183] in user32.dll.so) (ebp=405c66b8) 20 0x4075c26b (CallWindowProcA+0x3b(func=0x5f46f0f2, hwnd=0x20051, msg=0x110, wParam=0x10052, lParam=0x40400788) [winproc.c:2781] in user32.dll.so) (ebp=405c66e0) 21 0x4076bd00 (call_window_proc+0x100(hwnd=0x20051, msg=0x110, wparam=0x10052, lparam=0x40400788, unicode=0x0) [message.c:1372] in user32.dll.so) (ebp=405c6730) 22 0x4076c9d9 (SendMessageTimeoutA+0xe9(hwnd=0x20051, msg=0x110, wparam=0x10052, lparam=0x40400788, flags=0x0, timeout=0xffffffff, res_ptr=0x405c67b8, hwnd=0x20051) [message.c:1784] in user32.dll.so) (ebp=405c6788) 23 0x4076cb59 (SendMessageA+0x39(hwnd=0x20051, msg=0x110, wparam=0x10052, lparam=0x40400788) [message.c:1829] in user32.dll.so) (ebp=405c67bc) 24 0x40730695 (DIALOG_CreateIndirect+0x525(hInst=0x0, dlgTemplate=0x41552244, owner=0x20025, dlgProc=0x408ca8a0, param=0x40400788, procType=0x3, modal=0x0, hwnd=0x20025) [dialog.c:860] in user32.dll.so) (ebp=405c683c) 25 0x40730a6f (CreateDialogIndirectParamW+0x2f(hInst=0x0, dlgTemplate=0x415521e8, owner=0x20025, dlgProc=0x408ca8a0, param=0x40400788) [dialog.c:1011] in user32.dll.so) (ebp=405c686c) 26 0x408c7adc (PROPSHEET_CreateDialog+0xfc(psInfo=0x40400788) [propsheet.c:581] in comctl32.dll.so) (ebp=405c6898) 27 0x408ca21c (PropertySheetA+0x11c(lppsh=0x4113d250) [propsheet.c:2245] in comctl32.dll.so) (ebp=405c68bc) 28 0x5f4661eb (MFC42.DLL.?DoModal(a)CPropertySheet@@UAEHXZ+0xbc in I:\XILINX\MFC\MFC42.DLL) (ebp=00000000)

Aug. 1, 2002

Re: Compilation error with newer CVS on glibc -2.1.3

by Martin Cracauer

Martin Cracauer wrote on Thu, Aug 01, 2002 at 03:08:18PM -0400: > Alexandre Julliard wrote on Thu, Aug 01, 2002 at 11:45:27AM -0700: > > Martin Cracauer <cracauer(a)cons.org> writes: > > > > > Unless somebody disagrees with that analysis, I'll submit a patch to > > > rename the struct. Suggestions about a suitable name welcome. > > > > Before doing that it would be interesting to find out why sys/user.h > > gets included. This is not supposed to happen. > > This is the sequence: > > make[2]: Entering directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc' > gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wrc.o wrc.c > In file included from /usr/include/sys/ucontext.h:31, > from /usr/include/ucontext.h:27, > from /usr/include/signal.h:317, > from wrc.c:59: > /usr/include/sys/user.h:26: #error traceme > make[2]: *** [wrc.o] Error 1 > make[2]: Leaving directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc' signal.h only includes ucontext.h when __USE_GNU is defined. That is why a simple test program with its own 'struct user' and #include <signal.h> does not fail. Now, where does __USE_GNU come from? By definign GNU_SOURCE: #define _GNU_SOURCE /* for pread/pwrite */ ./include/wine/port.h #define _GNU_SOURCE /* we may need to override some GNU extensions */ ./scheduler/pthread.c The offending _GNU_SOURCE is in here for some time. 1.18 (julliard 07-Jan-02): #define _GNU_SOURCE /* for pread/pwrite */ I think the julliard 22-Jul-02 commits to this file triggered the error. Have to head for home now, will sniff more later today. Martin

Aug. 1, 2002

DTR/DSR vs RTS/CTS - followup

by lists＠vmn.com.br

Hello All, Last week I sent an email about a problem with a serial printer that used DTS/DTR hardware flow control. I later understood that DTS/DTR was not supported in linux , and therefore not in wine. Linux [and wine] support RTS/CTS hardware flow control. Since the protocols are similar, an ideia that I received was to construct a cable that made the computer think it was using RTS/CTS and the printer think it was using DTR/DTS. Today, I received the cable from the printer manufacturer and the initial tests with wine/linux worked. **************************** RTS - Ready To Send CTS - Clear To Send DTR - Data Terminal Ready DSR - Data Set Ready **************************** Here is a snippet of mytestapp --debugmsg +comm trace:comm:COMM_Init COM1 = /dev/ttyS0 trace:comm:COMM_Init LPT1 = /dev/lp0 trace:comm:COMM_Init COM2 = /dev/ttyS1 trace:comm:COMM_Init COM3 = /dev/ttyS2 trace:comm:COMM_Init COM4 = /dev/modem trace:comm:BuildCommDCBAndTimeoutsA (COM2:9600,N,8,1,0x4002af48,(nil)) trace:comm:COMM_BuildOldCommDCB (COM2:9600,N,8,1), ptr 0x4002af48 trace:comm:COMM_BuildOldCommDCB baudrate (9600) trace:comm:COMM_BuildOldCommDCB parity (N) trace:comm:COMM_BuildOldCommDCB charsize (8) trace:comm:COMM_BuildOldCommDCB stopbits (1) trace:comm:SetCommState handle 52, ptr 0x4002af48 trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0 stopbits 1 trace:comm:SetCommState ~IXON ~IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommMask handle 52, mask 10 Thanks every one from wine-devel for all the prompt answers I received. Miguel Feitosa ------------------------------------------------- This mail sent through IMP: webmail.vmn.com.br

Aug. 1, 2002

Re: Compilation error with newer CVS on glibc -2.0

by Martin Cracauer

Alexandre Julliard wrote on Thu, Aug 01, 2002 at 11:45:27AM -0700: > Martin Cracauer <cracauer(a)cons.org> writes: > > > Unless somebody disagrees with that analysis, I'll submit a patch to > > rename the struct. Suggestions about a suitable name welcome. > > Before doing that it would be interesting to find out why sys/user.h > gets included. This is not supposed to happen. This is the sequence: make[2]: Entering directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -fno-strength-reduce -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o wrc.o wrc.c In file included from /usr/include/sys/ucontext.h:31, from /usr/include/ucontext.h:27, from /usr/include/signal.h:317, from wrc.c:59: /usr/include/sys/user.h:26: #error traceme make[2]: *** [wrc.o] Error 1 make[2]: Leaving directory `/disks/part9/home/cracauer/work/cvs-packages-work/stupids/wine/wine/tools/wrc'

Aug. 1, 2002

Re: Recent patches introduced a regression error

by Sylvain Petreolle

Does this mean our tests aren't thread safe ?(hope i'm saying what I want :/) I wouldn't leave a real hole of black magic (M$) to have an open-source hole of black magic ;) :)). > As the problem didn't immediately resurface after Monday 8th July, I > assumed that it was a low-probability thread contention/deadlock > issue. I > tried conducting just the regression tests for wininet, without being > able > to reproducing the problem, but I didn't think to try the whole tests > (just assumed that the tests were independent). > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 1, 2002

Re: Recent patches introduced a regression error

by Sylvain Petreolle

> So, Sylvain, when you run the tests now, does it eventually time-out > returning a error, or does it freeze forever? Paul, Will try it this evening (I'm currently at work ;)) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Aug. 1, 2002

Re: Recent patches introduced a regression error

by Alexandre Julliard

Paul Millar <paulm(a)astro.gla.ac.uk> writes: > As the problem didn't immediately resurface after Monday 8th July, I > assumed that it was a low-probability thread contention/deadlock issue. I > tried conducting just the regression tests for wininet, without being able > to reproducing the problem, but I didn't think to try the whole tests > (just assumed that the tests were independent). Note that the wininet tests try to connect to www.winehq.com, so the failure could be caused by a network connectivity problem (of course it may also be a bug in our code). -- Alexandre Julliard julliard(a)winehq.com

Aug. 1, 2002

Re: Compilation error with newer CVS on glibc -2.0

by Alexandre Julliard

Martin Cracauer <cracauer(a)cons.org> writes: > Unless somebody disagrees with that analysis, I'll submit a patch to > rename the struct. Suggestions about a suitable name welcome. Before doing that it would be interesting to find out why sys/user.h gets included. This is not supposed to happen. -- Alexandre Julliard julliard(a)winehq.com

Aug. 1, 2002