October 2009 - Wine-devel - list.winehq.org

Re: msvcrt: dont overlap in strcpy (valgrind)
by Vitaliy Margolen 30 Oct '09

30 Oct '09

André Hentschel wrote: > here is a case where valgrind claims about "Source and destination overlap in strcpy". > snprintf(data->efcvt_buffer, 80, "%.*le", prec - 1, number); > /* take the decimal "point away */ > if( prec != 1) > - strcpy( data->efcvt_buffer + 1, data->efcvt_buffer + 2); > + { > + char *src = data->efcvt_buffer + 2, *dest = data->efcvt_buffer + 1; > + while ((*dest++=*src++) != 0); > + } You should use memmove instead. Vitaliy.

1 0

Re: [Bug 20505] After winetricks comctl32, wine does not work completely
by James Mckenzie 29 Oct '09

29 Oct '09

> >wine-bugs(a)winehq.org ha scritto: >> http://bugs.winehq.org/show_bug.cgi?id=20505 >> >> >> Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: >> >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Status|RESOLVED |CLOSED >> >> >> >> >> --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-10-28 23:53:57 --- >> Closing invalid. >> > >This one happens here too, and it used to work before, so IMHO is a regression. > I beg to differ. The use of winetricks to get around shortcomings of Wine is not a Wine developer issue and should be addressed to Dan Kegel and Austin English. James McKenzie

3 2

Re: New valgrind results for Oct 26, 2009
by André Hentschel 29 Oct '09

29 Oct '09

Dan Kegel schrieb: > 2009/10/28 André Hentschel <nerv(a)dawncrow.de>: >> I think i found a false postitv. its http://kegel.com/wine/valgrind/logs/2009-10-26-08.26/vg-ntdll_env.txt >> the code in ntdll/tests/env.c looks like: >> ... >> name.Buffer = bn; >> ... >> value.Buffer = bv; >> ... >> nts = pRtlQueryEnvironmentVariable_U(small_env, &name, &value); >> ... >> if(memcmp(bv, bn, test->len*sizeof(WCHAR)) == 0) >> >> So valgrind thinks bn and bv are uninitialised, but thats wrong. >> Do you agree with me? > > I actually looked at this one for an hour the other day. > I think valgrind's probably right, but the test is confusingly written. So i send this issue to wine-devel to know what other devs think about it. -- Best Regards, André Hentschel

1 0

Re: crypt32: CryptUnprotectData: test zero-length payload
by Paul Vriens 29 Oct '09

29 Oct '09

On 10/28/2009 02:40 AM, Dan Kegel wrote: > Passes on Vista and on Wine (with one todo_wine). > Exposes http://bugs.winehq.org/show_bug.cgi?id=20495 > > (Note: 'make crosstest' doesn't work stunningly well in > crypt32 for me -- there were lots of undefined symbols -- > but fortunately the file this test is in compiles ok standalone. > Had to use LoadLibrary rather than GetModuleHandle, > else it failed to run standalone.) > > Hi Dan, Some testfailures on everything below W2K. Some tests were already skipped because of this. I tried several things but the last error is always set to RPC_X_WRONG_STUB_VERSION. Maybe we should test for that before we do any tests and bail out? Does this error make sense on 9x/Me/NT4? -- Cheers, Paul.

2 2

Re: [Bug 20505] After winetricks comctl32, wine does not work completely
by Massimo Del Fedele 29 Oct '09

29 Oct '09

wine-bugs(a)winehq.org ha scritto: > http://bugs.winehq.org/show_bug.cgi?id=20505 > > > Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |CLOSED > > > > > --- Comment #3 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-10-28 23:53:57 --- > Closing invalid. > This one happens here too, and it used to work before, so IMHO is a regression. Max

1 0

Debug help needed : Unhandled page fault on read access to 0xffffffff]
by Philippe De Muyter 29 Oct '09

29 Oct '09

Hello Alexandre, It's a long time now since my last contrib to the wine project (1997), and I try to run a proprietary W31/W95 program without any success : It fails immediately with : wine: Unhandled page fault on read access to 0xffffffff at address 0x124f:0x000090f7 (thread 001c), starting debugger... At that stage I do not have any window of the windows program, only a window from wine stating : The program winevdm.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience. After I close this window, I get debug output from wine (appended below). I do not remember how I could find where the crash happens, and hence why, in the hope of fixing it. Could give me some hint ? Philippe Unhandled exception: page fault on read access to 0xffffffff in 16-bit code (124f:90f7). fixme:dbghelp:addr_to_linear Failed to linearize address 0112:0000674d (mode 0) fixme:dbghelp:addr_to_linear Failed to linearize address 0111:0000ef00 (mode 0) In 16 bit mode. Register dump: CS:124f SS:13bf DS:13bf ES:0000 FS:0033 GS:003b IP:90f7 SP:962c BP:9634 FLAGS:0202( R- -- I - - - ) AX:0c4e BX:0000 CX:16ff DX:19df SI:0c3b DI:ab5f Stack dump: 0x13bf:0x962c: ab5f 0001 0000 13bf 96e3 b3af 1217 9688 0x13bf:0x963c: 13bf 0000 0000 4eb2 4cf6 b811 0004 0000 0x13bf:0x964c: 036f 1457 0000 0001 aac9 1217 145f 018c 0277: sel=13bf base=0091c738 limit=0000fcdf 16-bit rw- Backtrace: =>0 0x124f:0x90f7 (0x13bf:0x9634) 1 0x1217:0xb3af (0x13bf:0x96e2) 2 0x0112:0x674d (0x13bf:0x96fc) 3 0x0111:0xef00 (0x13bf:0x0000) 0x124f:0x90f7: movb %es:0x0(%bx),%bl Modules: Module Address Debug info Name (101 modules) ELF 7b800000-7b96f000 Deferred kernel32<elf> \-PE 7b820000-7b96f000 \ kernel32 ELF 7bc00000-7bcaf000 Deferred ntdll<elf> \-PE 7bc10000-7bcaf000 \ ntdll ELF 7bf00000-7bf04000 Deferred <wine-loader> ELF 7dd50000-7dd82000 Deferred libcrypt.so.1 ELF 7dd82000-7dec7000 Deferred libcrypto.so.0.9.8 ELF 7dec7000-7df0a000 Deferred libssl.so.0.9.8 ELF 7df0a000-7df3c000 Deferred libcups.so.2 ELF 7df44000-7df5a000 Deferred shell.dll16.so PE 7df50000-7df5a000 Deferred shell.dll16 ELF 7df5a000-7df73000 Deferred spoolss<elf> \-PE 7df60000-7df73000 \ spoolss ELF 7df73000-7df92000 Deferred localspl<elf> \-PE 7df80000-7df92000 \ localspl ELF 7dfb6000-7e021000 Deferred rpcrt4<elf> \-PE 7dfc0000-7e021000 \ rpcrt4 ELF 7e021000-7e11a000 Deferred ole32<elf> \-PE 7e040000-7e11a000 \ ole32 ELF 7e144000-7e178000 Deferred uxtheme<elf> \-PE 7e150000-7e178000 \ uxtheme ELF 7e178000-7e1ac000 Deferred winspool<elf> \-PE 7e180000-7e1ac000 \ winspool ELF 7e1ac000-7e273000 Deferred comctl32<elf> \-PE 7e1c0000-7e273000 \ comctl32 ELF 7e273000-7e2cf000 Deferred shlwapi<elf> \-PE 7e280000-7e2cf000 \ shlwapi ELF 7e2cf000-7e45f000 Deferred shell32<elf> \-PE 7e2e0000-7e45f000 \ shell32 ELF 7e45f000-7e511000 Deferred comdlg32<elf> \-PE 7e470000-7e511000 \ comdlg32 ELF 7e511000-7e525000 Deferred win87em.dll16.so PE 7e520000-7e525000 Deferred win87em.dll16 ELF 7e525000-7e550000 Deferred ws2_32<elf> \-PE 7e530000-7e550000 \ ws2_32 ELF 7e550000-7e568000 Deferred winsock.dll16.so PE 7e560000-7e568000 Deferred winsock.dll16 ELF 7e568000-7e57d000 Deferred sound.drv16.so PE 7e570000-7e57d000 Deferred sound.drv16 ELF 7e57d000-7e591000 Deferred mouse.drv16.so PE 7e580000-7e591000 Deferred mouse.drv16 ELF 7e591000-7e5a6000 Deferred keyboard.drv16.so PE 7e5a0000-7e5a6000 Deferred keyboard.drv16 ELF 7e5a6000-7e5bb000 Deferred display.drv16.so PE 7e5b0000-7e5bb000 Deferred display.drv16 ELF 7e5bb000-7e5cf000 Deferred comm.drv16.so PE 7e5c0000-7e5cf000 Deferred comm.drv16 ELF 7e5cf000-7e5f5000 Deferred msacm32<elf> \-PE 7e5e0000-7e5f5000 \ msacm32 ELF 7e5f5000-7e6b1000 Deferred libasound.so.2 ELF 7e6ba000-7e6cf000 Deferred midimap<elf> \-PE 7e6c0000-7e6cf000 \ midimap ELF 7e6cf000-7e706000 Deferred winealsa<elf> \-PE 7e6e0000-7e706000 \ winealsa ELF 7e706000-7e7a1000 Deferred winmm<elf> \-PE 7e710000-7e7a1000 \ winmm ELF 7e7a1000-7e803000 Deferred winedos<elf> \-PE 7e7b0000-7e803000 \ winedos ELF 7e803000-7e809000 Deferred libxfixes.so.3 ELF 7e809000-7e813000 Deferred libxcursor.so.1 ELF 7e813000-7e81a000 Deferred libxrandr.so.2 ELF 7e81a000-7e823000 Deferred libxrender.so.1 ELF 7e823000-7e829000 Deferred libxxf86vm.so.1 ELF 7e829000-7e82d000 Deferred libxinerama.so.1 ELF 7e82d000-7e84e000 Deferred imm32<elf> \-PE 7e830000-7e84e000 \ imm32 ELF 7e84e000-7e867000 Deferred libxcb.so.1 ELF 7e867000-7e982000 Deferred libx11.so.6 ELF 7e982000-7e991000 Deferred libxext.so.6 ELF 7e991000-7e9aa000 Deferred libice.so.6 ELF 7e9aa000-7e9b3000 Deferred libsm.so.6 ELF 7e9b7000-7e9cf000 Deferred msacm32<elf> \-PE 7e9c0000-7e9cf000 \ msacm32 ELF 7e9d1000-7ea6d000 Deferred winex11<elf> \-PE 7e9e0000-7ea6d000 \ winex11 ELF 7eb25000-7eb46000 Deferred libexpat.so.1 ELF 7eb46000-7eb72000 Deferred libfontconfig.so.1 ELF 7eb72000-7eb85000 Deferred libz.so.1 ELF 7eb85000-7ebf4000 Deferred libfreetype.so.6 ELF 7ebf4000-7ebf7000 Deferred libxcb-xlib.so.0 ELF 7ebf7000-7ebfb000 Deferred libxau.so.6 ELF 7ec12000-7ec27000 Deferred system.drv16.so PE 7ec20000-7ec27000 Deferred system.drv16 ELF 7ec27000-7ec7d000 Deferred advapi32<elf> \-PE 7ec30000-7ec7d000 \ advapi32 ELF 7ec7d000-7ed1c000 Deferred gdi32<elf> \-PE 7ec90000-7ed1c000 \ gdi32 ELF 7ed1c000-7ee64000 Deferred user32<elf> \-PE 7ed40000-7ee64000 \ user32 ELF 7ee64000-7ee6e000 Deferred libnss_files.so.2 ELF 7ee6e000-7ee78000 Deferred libnss_nis.so.2 ELF 7ee78000-7ee80000 Deferred libnss_compat.so.2 ELF 7ee88000-7ee9e000 Deferred winevdm<elf> \-PE 7ee90000-7ee9e000 \ winevdm ELF 7efbd000-7efe2000 Deferred libm.so.6 ELF 7efe8000-7efff000 Deferred libnsl.so.1 ELF b7c84000-b7c88000 Deferred libdl.so.2 ELF b7c88000-b7dbb000 Deferred libc.so.6 ELF b7dbb000-b7dd2000 Deferred libpthread.so.0 ELF b7df0000-b7f2b000 Deferred libwine.so.1 ELF b7f2c000-b7f48000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000e 00000014 0 00000010 0 0000000f 0 00000011 00000018 0 00000017 0 00000013 0 00000012 0 00000019 (D) C:\windows\system32\winevdm.exe 0000001c 0 <== 0000001b 0 0000001a 0 0000001d 0000001e 0 Backtrace: =>0 0x124f:0x90f7 (0x13bf:0x9634) 1 0x1217:0xb3af (0x13bf:0x96e2) 2 0x0112:0x674d (0x13bf:0x96fc) 3 0x0111:0xef00 (0x13bf:0x0000)

3 2

Re: [1/2] shell32/tests: Program Manager DDE Conformance Tests
by Vitaliy Margolen 29 Oct '09

29 Oct '09

Mike wrote: > Vitaliy, > > Thanks for the quick feedback. I'll make the changes you've suggested and > repost, probably next week. A couple quick questions about your comments: > > Indentation: >> Tabs should always be set to 8 spaces, not 4. For Wine >> please use 4-space >> indentations, no tabs please. >> > Your response was not clear. Is the correct indentation 8 spaces, no Ctrl-I (ascii 0x09)? No. Tab character (0x09) is 8 positions long, not 4. Please do not use it at all in Wine, unless it's a Makefile. Wine's default indentation is 4 spaces (0x20). > > Detecting Windows Version: >>> +int IsWin9x(void) >>> +{ >>> + return (GetVersion() & >> 0x80000000); >>> +} >> Don't add this sort of functions. All tests should work on >> all Windows >> versions. Or you should detect differences by other means. CSIDL_PROGRAM_FILES_COMMON is not supported in Win 95, 98, or ME and so the directory where things are created changes. What is the correct method to determine whether to use this or not for Wine Conformance Tests? If I recall correctly, this was the only change needed to make the test run in Win 98. If a call to SHGetSpecialFolderPath with CSIDL_PROGRAM_FILES_COMMON failes assume it's win9x and use the CSIDL_PROGRAMS. Or check both places. Or something along these lines. Vitaliy.

1 0

for the record, my ole32 binary tree search patch is correct
by Vincent Povirk 29 Oct '09

29 Oct '09

I sent the following patch recently: commit ee6856d874d687c4504914e61bcde3e6b8823bca Author: Vincent Povirk <madewokherd(a)gmail.com> Date: Fri Oct 23 13:57:42 2009 -0500 ole32: Don't use IEnumSTATSTG to search for elements of storages. We use it to do a linear search of a binary tree, which is overkill. Replace it with a simple binary search. It was accepted and caused this bug: http://bugs.winehq.org/show_bug.cgi?id=20477 It actually turned out that the mistake was in a previous patch, but it didn't matter for reading files until we started to depend on the tree to be valid. Nonetheless, I've done a test to make sure we can really rely on the binary trees in storage files to be valid. I wrote two programs: one that reads the directory entries of a storage file and prints some information to stdout (useful for debugging), and one that swaps the left and right child of every directory entry, corrupting the trees in the file. It turns out that corrupting an msi file in this way makes it fail on both windows and on wine (although it crashes on wine; msi's error handling code is broken). Running the program again (thus swapping the children back to their original, correct position) makes it work. However, on an older version of Wine without my change, the corrupted msi file loads fine. This means that Windows does depend on the tree in a storage file to be correct, and Wine's behavior is now closer to Windows, even though it now fails in some cases when it used to succeed. (I think that current Wine without the fix for bug 20477 will load only the corrupted files, but I didn't test this.) I've attached my test programs so they're in the public record. -- Vincent Povirk

2 3

kernel32: add more tests for FormatMessage{A,W}
by Louis Lenders 29 Oct '09

29 Oct '09

>FormatMessage uses the same backend to find the requested resource as >FindResource does, so I'd guess that they both fail in the same way >when a resource id or a language does not exist in the module. I still fail to see how I can call FindResource for a missing message-id. In the end they both use LdrFindResource_U but I guess that's not what you meant to test. I still have tthe problem to first load the messagetable with FindResource, and I cannot use a call to FindResource to ask for a present or missing message-id. I'll resend the patch with your other two suggenstions, if the patch is not accepted i'll leave it to someone else (more experienced) to take this up

1 0

Re: [PATCH 01/12] d3d10: Fix a HeapFree() in d3d10_effect_Release().
by Stefan Dösinger 29 Oct '09

29 Oct '09

Am 27.10.2009 um 20:10 schrieb Rico Schüller: > Hi, > > this patch series implements a couple of ID3D10EffectVariable::As*() > functions (patches 2-11). Do we have any tests for the As* behavior? Most conversions don't make any sense, so if the app wants a constant buffer as a render target view returning a null obj is probably a sane thing. But ::AsString potentially makes sense for all objects, maybe in a similar way Object::ToString is used to obtain a String for debug output in Java. Also, do we know what happens if the object is "converted" back to its original state? E.g. constant_buffer = render_target_view::AsConstantBuffer(); render_target_view2 = constantBuffer::AsRenderTargetView? As far as I understand it, your code would return a null rt view. Is this correct?

4 4