July 2008 - Wine-Devel - list.winehq.org

Hang in user32/tests/dde.c:test_msg_client()
by Dan Kegel July 29, 2008

July 29, 2008

I'm running the tests on a slowish uniprocessor (Athlon XP 2100+, not dual as I mistakenly said in last post), and I'm running into a hang in user32/tests/dde.c. This is a two process test. One process is hung in 8 test_ddeml_server+0x1ad(hproc=0x4c) [dlls/user32/tests/dde.c:797] in user32_test (0x7f21fc68) in a reasonable looking "wait for requests", and the other is hung in 5 X11DRV_MsgWaitForMultipleObjectsEx+0x77(count=0x1, handles=0x7f22fa0c, timeout=0xffffffff, mask=0x40, flags=0x0) [dlls/winex11.drv/event.c:402] in winex11 (0x7f22f968) 6 wait_message_reply+0x11f(flags=0x0) [dlls/user32/message.c:2274] in user32 (0x7f22fa28) 7 send_inter_thread_message+0xf9(info=0x7f22faec, res_ptr=0x7f22fab0) dlls/user32/message.c:2418] in user32 (0x7f22fa78) 8 send_message+0x252(info=0x7f22faec, res_ptr=0x0, unicode=0x0) [dlls/user32/message.c:2480] in user32 (0x7f22fac8) 9 SendMessageTimeoutA+0x52(hwnd=0x84002c, msg=0x3e0, wparam=0xb005c, lparam=0xc09fc09c, flags=0x0, timeout=0x0, res_ptr=0x0) [dlls/user32/message.c:2567] in user32 (0x7f22fb18) 10 broadcast_message_callback+0xfa(hwnd=0x84002c, lparam=0x7f22fc08) [dlls/user32/message.c:363] in user32 (0x7f22fb68) 11 EnumWindows+0x7d(lpEnumFunc=0x4b3d5ba, lParam=0x7f22fc08) [dlls/user32/win.c:2979] in user32 (0x7f22fb98) 12 send_message+0x3b(info=0x7f22fc08, res_ptr=0x7f22fc34, unicode=0x0) [dls/user32/message.c:2450] in user32 (0x7f22fbe8) 13 SendMessageA+0x5b(hwnd=0xffff, msg=0x3e0, wparam=0xb005c, lparam=0xc09fc09c) [dlls/user32/message.c:2609] in user32 (0x7f22fc38) 14 test_msg_client+0x111() [dlls/user32/tests/dde.c:1026] in user32_test (0x7f22fc68) That last frame is on the line SendMessageA(HWND_BROADCAST, WM_DDE_INITIATE, (WPARAM)client_hwnd, MAKELONG(server, topic)); Looking at the code, it seems the client is spawned before the server is started. What happens if the client gets all the way to that SendMessageA(... WM_DDE_INITIATE...) before the server is active? Would that cause the observed hang? The code in question seems to have been added back in October by: commit 9cf7f8c3e21931b52e3da6c5feb701aa9ba4a1f8 Author: James Hawkins <truiken(a)gmail.com> Date: Mon Oct 8 04:06:45 2007 -0500 user32: Test the ddeml server interface. - Dan

1 0

Missed patches concerning valgrind-detected issues
by Kirill K. Smirnov July 29, 2008

July 29, 2008

Hello, Alexandre, Is there anything wrong with this couple of patches: dsound: check error status of waveOutGetVolume() function before using retrieved values (found by valgrind) http://www.winehq.org/pipermail/wine-patches/2008-July/058124.html and cmd: Do not deceive CompareString() passing more characters then we really have (found by valgrind) http://www.winehq.org/pipermail/wine-patches/2008-July/058504.html Thanks -- Kirill

2 1

Re: wined3d: Call apply_fbo_state() from inside ActivateContext()
by Alexandre Julliard July 29, 2008

July 29, 2008

"H. Verbeet" <hverbeet(a)gmail.com> writes: > This should prevent setting an incorrect draw buffer when an FBO is active. It doesn't work here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:8465: Tests skipped: D3DFMT_G16R16F textures not supported visual.c:8465: Tests skipped: D3DFMT_G32R32F textures not supported visual.c:7449: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:8326: Tests skipped: Only 1 simultaneous render target supported, skipping MRT test visual.c:5476: Test failed: vs_3_0 returned color 0x0000ff00, expected 0x00193366 visual.c:5479: Test failed: vs_1_1 returned color 0x00ff0000, expected 0x004c0066 visual.c:5482: Test failed: vs_2_0 returned color 0x0000ff00, expected 0x004c0066 make[2]: *** [visual.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] relay: Avoid reading stack memory on unprotected side of stack pointer
by Alexandre Julliard July 29, 2008

July 29, 2008

John Reiser <jreiser(a)BitWagon.com> writes: > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:0*4(%%eax)\n", CONTEXTOFFSET(Eax) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:1*4(%%eax)\n", CONTEXTOFFSET(Ecx) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:2*4(%%eax)\n", CONTEXTOFFSET(SegDs) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:3*4(%%eax)\n", CONTEXTOFFSET(Eip) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:4*4(%%eax)\n", CONTEXTOFFSET(SegCs) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:5*4(%%eax)\n", CONTEXTOFFSET(EFlags) ); This won't work if the stack is 16-bit, you'd need to truncate the address to 16-bit too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Call apply_fbo_state() from inside ActivateContext()
by Vitaliy Margolen July 29, 2008

July 29, 2008

H. Verbeet wrote: > This should prevent setting an incorrect draw buffer when an FBO is active. > This patch breaks Psychonauts and possibly other multi-threaded games with OffscreenRendering=FBO on Nvidia hardware. Vitaliy.

2 1

Re: rsaenh: Test and correct the maximum allowable salt length
by James Hawkins July 29, 2008

July 29, 2008

On Mon, Jul 28, 2008 at 9:58 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Inspired by a patch by Karsten Elfenbein. + /* What sizes salt can I set? */ + salt.pbData = pbData; + for (i=0; i<24; i++) + { + salt.cbData = i; + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(result, "setting salt failed for size %d: %08x\n", i, GetLastError()); + } + salt.cbData = 25; + SetLastError(0xdeadbeef); + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(!result && GetLastError() == NTE_BAD_DATA, "%08x\n", GetLastError()); + + /* What sizes salt can I set? */ + salt.pbData = pbData; + for (i=0; i<24; i++) + { + salt.cbData = i; + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(result, "setting salt failed for size %d: %08x\n", i, GetLastError()); + } + salt.cbData = 25; + SetLastError(0xdeadbeef); + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(!result && GetLastError() == NTE_BAD_DATA, "%08x\n", GetLastError()); + Did you mean to test that block twice? -- James Hawkins

2 1

Re: [PATCH] ntdll: use symbols, add documentation for i386 page faulterror code
by Dmitry Timoshkov July 29, 2008

July 29, 2008

"John Reiser" <jreiser(a)BitWagon.com> wrote: >> These changes are not compatible with PSDK. >> > > Which "PSDK" is that, and what are the error messages? I'm using Software Development Kit Update for Windows Vista. > The numerical values are identical, > and the new names are the ones used by the hardware documentation. The problem is that you are introducing things not existing in PSDK. -- Dmitry.

1 0

RE: Convert 565 to 0888
by Stefan Dösinger July 29, 2008

July 29, 2008

This patch collides with Victor Eremin's general convertor I think. We may still want both, because the special function is faster than code that attempts to handle all potential formats. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Austin English > Sent: Wednesday, July 23, 2008 9:34 AM > To: wine-patches(a)winehq.org > Subject: Fwd: Convert 565 to 0888 > > ---------- Forwarded message ---------- > From: Einars <einars(a)gmail.com> > Date: Jul 22, 2008 11:22 PM > Subject: Convert 565 to 0888 > To: wine-devel(a)winehq.org > > > I had graphical problems with an online game called Angels Online, when > just a black screen was visible, and complaints about missing converter > from WINED3DFMT_R5G6B5 to WINED3DFMT_X8R8G8B8, so I added a converter > for this format, and the game runs flawlessly now on wine, the 1.1.1 > release as well as git version (at least for me). I hope this was the > right way to fix it. > > Kind regards, > > Einars Lielmanis

3 9

Richedit: fix bug 14280, EM_SETTEXTTEX obeys ST_SELECTION with RTF inputs
by Dustin Brody July 29, 2008

July 29, 2008

I sent the patch at http://www.winehq.org/pipermail/wine-patches/2008-July/058460.html but got neither it applied nor any other comment. As far as I can tell, I complied with all the guidelines at http://www.winehq.org/site/sending_patches. Is it the editing of comments not strictly part of the new test (but, I'd claim, valuable for the future expansion of those test cases to cover the remaining flag option combinations)? The introduction of a new buffer in the test handler? That the test handler maybe should be a patch in itself (although the standard practise seems to be to bundle them)? The code in the new test-cases? That the editor.c patch should adopt a different approach? That aside from my own patch to DC++ (discussed in the numbered bug report) I haven't looked for or found a real-world program using this (in which case, should I first get the DC++ patch in, then point to that as an example of such a real-world program; I have been avoiding that precisely because I primarily use WINE and don't want to break things for myself in the indeterminately long period after such an application to the main DC++ tree)? Something else? Aside from the test cases, this is literally a one-bit change from 0 to 1 and it's been a weeks and a resend and I have no idea what the status is, how likely it is ever to be committed, or how I might have screwed up. Feedback would be appreciated. -Dustin Brody

2 2

Re: [PATCH] gdiplus: Detect integer overflow in GdipCreateBitmapFromScan0. (try 2)
by Lei Zhang July 28, 2008

July 28, 2008

On Mon, Jul 21, 2008 at 5:59 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This patch does a better job of detecting integer overflow. > > The tests added reproduce the behavior in bug 14536, which this patch fixes. > Anything wrong with this patch?

1 0