wine-devel September 2011

wine-devel@winehq.org

83 participants
387 discussions

re: msi: Properly check for a specified flag combination
by Dan Kegel 10 Sep '11

10 Sep '11

Test failed here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok ... err:msi:env_parse_flags Invalid flags: 00000007 err:msi:ITERATE_Actions Execution halted, action L"RemoveEnvironmentStrings" returned 1627 err:msi:env_parse_flags Invalid flags: 00000007 action.c:5588: Test failed: Expected ERROR_SUCCESS, got 1627 action.c:5594: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5597: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 action.c:5609: Test failed: Expected ERROR_FILE_NOT_FOUND, got 0 fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevationType, ...) semi-stub action.c:5666: Test failed: key not created action.c:5670: Test failed: key not created action.c:5674: Test failed: key not created ... Command exited with non-zero status 7 4.04user 0.50system 0:05.03elapsed 90%CPU (0avgtext+0avgdata 51216maxresident)k 0inputs+7360outputs (0major+17117minor)pagefaults 0swaps make: *** [action.ok] Error 7 ---------- Forwarded message ---------- From: <buildbot(a)kegel.com> Date: Sat, Sep 10, 2011 at 12:33 PM Subject: Re: 78647: Subject: msi: Properly check for a specified flag combination To: dank(a)kegel.com This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. The Buildbot has detected a failed build on builder runtests-default while building Wine. Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/15 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_3 For more info about this message, see http://wiki.winehq.org/BuildBot

1 0

Re: urlmon/tests: Removed a test that causes random failures on some machines
by Marvin 10 Sep '11

10 Sep '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14120 Your paranoid android. === WVISTAADM (32 bit sec_mgr) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

1 0

urlmon:sec_mgr failure on XP
by Francois Gouget 10 Sep '11

10 Sep '11

This test now fails on my Widnows XP VMs that have IE >= 7 with 'All zones reset to default level': http://test.winehq.org/data/3b40c03a8f0e3dcbb236d59125b115b2501086f8/xp_fg-… sec_mgr.c:1695: Test failed: Expected zone 3, but got 1 for 'file/testing/test.test' The patch that introduces the failures is 98d5dfb8 which was committed on the 5th. I did some experiments and I can get this test to pass if I do: * Go to the Internet Properties control panel * Security tab * Select 'Local intranet' * Click on the 'Sites' button * Deselect 'Automatically detect intranet network' * Deselect 'Include all local (intranet) sites not listed in other zones' * Click on 'OK' I also checked on Windows 7 and by default it has the first checkbox checked but the second one unchecked. Disabling 'Automatically detect intranet network' and enabling 'Include all local sites...' to match Windows XP causes the test to fail on Windows 7 too. Finally, on XP even if I deselect all the 'Include XXX' checkboxes but select the 'Automatically detect intranet network' one the test fails while with the same configuration it passes on Windows 7. So I think this reflects a difference in the way the intranet detection works. So I'm hoping that you can fix the test. The easiest fix would be to remove the 'file/testing/test.test' check. An alternative would be to check what the settings are and adjust the expected result or skip the test. But it seems like this would be much more complex. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

2 1

speeding up builds with ext4 and ccache tuning
by Dan Kegel 10 Sep '11

10 Sep '11

Here's a little brain dump about speeding up builds. I ran into two problems today: - disk slowness On a machine where builds were slow, the iozone benchmark showed I/O was half or two thirds as fast as a better machine. The slow system turned out to be ext3, whereas the fast ones were ext4. (It's also using gcc-2.95.3 for wine, whereas the others are using the system compiler.) Adding a 7200rpm disk with an ext4 filesystem, and putting both wine-git and ~/.ccache on it, sped up ./configure so that it matched the faster system... but builds were only sped up by 20%. Nice, but not sufficient. - ccache too strict? ccache helps hugely on most of my systems without any tuning, but wasn't working well on my slow system. After looking at ccache's statistics and log file for a while, I came across the CCACHE_SLOPPINESS environment variable; setting that to maximum sloppiness got the cache hit rate sky-high, and build times dropped by a factor of 2, making the slower box suddenly competitive with the faster system. The sloppy setting is probably inappropriate for general use, but ok for regression testing. Those two tweaks get the buildbot cycle time for the headless subset of tests with gcc-2.95 on my e7300 down under nine minutes, yay.

1 1

Re: gdiplus/tests: Don't fail if Microsoft Sans Serif and Times New Roman are not installed.
by Francois Gouget 10 Sep '11

10 Sep '11

I'm actually not entirely happy with this patch. Wine actually hardcodes the fallback fonts to Liberation Serif and Tahoma. So we could instead check that if on Wine and the Windows fonts are not installed then we get the fallback fonts. It's a bit what the test was trying to do with Microsoft Sans Serif except that I also take exception with the todo_wine since the fix is not to change Wine but to install the missing font. Changing the test as I described would let us detect when Microsoft decides to ship other fonts instead of these. We would also issue an error if neither font was found, such as on FreeBSD 8.1 for instance as it is a hint that we should find some other/additional fallback font. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

4 4

The msctf:inputprocessor test is not reliable
by Francois Gouget 10 Sep '11

10 Sep '11

This test is not reliable on my Debian desktop. http://test.winehq.org/data/3b40c03a8f0e3dcbb236d59125b115b2501086f8/linux_… inputprocessor.c:2117: Test failed: OnSetFocus expected current focus 0x12b070 got 0x12b0d0 inputprocessor.c:538: Test failed: Unexpected ThreadMgrEventSink_OnSetFocus sink inputprocessor.c:549: Test failed: Sink reports wrong previous focus If I run it in a loop it fails about once every twelve times: i=0;while ../../../tools/runtest inputprocessor.c && [ $i -lt 100 ];do i=`expr $i + 1`; echo $i; done Introducing a single Sleep(50) as shown below makes it totally reliable here. ShowWindow(wnd3,SW_SHOWNORMAL); SetFocus(wnd3); + Sleep(50); processPendingMessages(); test_CurrentFocus = FOCUS_SAVE; test_PrevFocus = FOCUS_SAVE; test_OnSetFocus = SINK_SAVE; SetFocus(wnd1); processPendingMessages(); sink_check_saved(&test_OnSetFocus,dm2,dm1,"OnSetFocus"); /* ^^^ Line that fails! */ That seems pretty hacky though. I suspect this is all because processPendingMessages() will exit if there's no pending message right after we call SetFocus() without giving enough time for the asynchronous X event to arrive. But I'm surprised that a single Sleep() fixes the issue, especially where it's placed. Also I don't know anything about msctf so I'm unsure how ThreadMgrEventSink_OnSetFocus() figures in all this. So should I just submit a patch to add that Sleep()? Or would it be better to change processPendingMessages() to look more like user32/tests/msg.c's flush_events() function although it looks like it's overkill for now? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

2 1

Re: Auto-selecting local variable/parameters when 'p'rinting values using winedbg?
by Frédéric Delanoy 10 Sep '11

10 Sep '11

2011/9/9 Eric Pouech <eric.pouech(a)orange.fr>: > WineDbg> set ! symbol_picker scoped > will do what you want > unfortunately, there's no way to store it as a default command (you can > always use --command or --file on command line to help) Thanks for that quick response! Is there some doc on the internal commands, besides the code? http://www.winehq.org/docs/winedev-guide/dbg-config may be a bit out of date Frédéric

2 1

resource_check_usage Unhandled usage flags 0x8
by Luis C. Busquets Pérez 09 Sep '11

09 Sep '11

I do not from which exact version of wine, whenever I run Civilization IV bryond the sword, losts of fixmes appear with the message fixme:d3d:resource_check_usage Unhandled usage flags 0x8. Since those fixmes did not appear before I wonder if this is a bug. I do not understand how it is that the function resource_check_usage uses a flag that before it wasn't, was it? Can anybody clarify the usage of the flag 0x8 and if this is a bug?

2 1

Re: 78632: Subject: po: Update Japanese translation.
by Dan Kegel 09 Sep '11

09 Sep '11

Hi Akihiro, your patch does not apply here, perhaps it's slightly out of date? patching file po/ja.po Hunk #22 FAILED at 8231. Hunk #23 succeeded at 8271 (offset 1 line). Hunk #24 succeeded at 8347 with fuzz 2 (offset 1 line). Hunk #25 succeeded at 8540 (offset 1 line). Hunk #26 succeeded at 8549 (offset 1 line). Hunk #27 succeeded at 8566 (offset 1 line). Hunk #28 succeeded at 8581 (offset 1 line). Hunk #29 succeeded at 8647 (offset 1 line). Hunk #30 succeeded at 8791 (offset 1 line). Hunk #31 succeeded at 8888 (offset 1 line). Hunk #32 succeeded at 8912 (offset 1 line). Hunk #33 succeeded at 9004 (offset 1 line). Hunk #34 succeeded at 9045 (offset 1 line). Hunk #35 succeeded at 9872 (offset 1 line). Hunk #36 succeeded at 10329 (offset 1 line). Hunk #37 succeeded at 10490 (offset 1 line). Hunk #38 succeeded at 10733 (offset 1 line). Hunk #39 succeeded at 10758 (offset 1 line). Hunk #40 succeeded at 11246 (offset 1 line). Hunk #41 succeeded at 11260 (offset 1 line). Hunk #42 succeeded at 11381 (offset 1 line). Hunk #43 succeeded at 11415 (offset 1 line). 1 out of 43 hunks FAILED -- saving rejects to file po/ja.po.rej dank@pantry:~/wine-git$ git reset --hard origin HEAD is now at cb55d2a crypt32/tests: Remove dead assignment (clang). dank@pantry:~/wine-git$ git apply 78632 error: patch failed: po/ja.po:8198 error: po/ja.po: patch does not apply 2011/9/9 <buildbot(a)kegel.com>: > This is an experimental automated build and test service. > Please feel free to ignore this email while we work the kinks out. > > The Buildbot has detected a failed build on builder runtests-default-x86_64 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/0 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed git > > > For more info about this message, see http://wiki.winehq.org/BuildBot > > >

1 0

Re: [2/2] dpnet: return a TCP/IP provider in IDirectPlay8PeerImpl_EnumServiceProviders
by Alexandre Julliard 09 Sep '11

09 Sep '11

Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> writes: > + info = HeapAlloc(GetProcessHeap(), 0, req_size); > + > + info->pwszName = (LPWSTR)(info + 1); > + > + if(!pguidServiceProvider) > + { > + lstrcpyW(info->pwszName, dp_providerW); > + info->guid = CLSID_DP8SP_TCPIP; > + } > + else > + { > + lstrcpyW(info->pwszName, dp_adapterW); > + info->guid = adapter_guid; > + } > + > + *pSPInfoBuffer = *info; > + *pcReturned = 1; > + > + HeapFree(GetProcessHeap(), 0, info); This doesn't make sense, you are returning freed data. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
23
24
25
26
27
28
29
...
39
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2011