Re: Problems with drawing text in 1.3.29
Thanks for the suggestions. I've narrowed one of the issues down to WineEngGetGlyphOutline in dlls/gdi32/freetype.c. The pitch is 6640 and the height is 53003. This means that a buffer of ~335Mb has been allocated and then memset. This is where the slow down is occurring (because of the memset). I suspect the resultant crash is also because of this. I would suggest that limits need to be placed on the maximum pitch and height. I do not however believe that this is the root cause just one of the symptoms. On 5 October 2011 18:37, Marcus Meissner mar...@jet.franken.de wrote: On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. To get a backtrace and be able to dump some datastructures, run with WINEDEBUG=+synchronous wine foo.exe This will bring it into the debugger once the condition happens. CIao, MArcus
DLLCanUnloadNow Question
Hi, The Following sample code causes a crash under WINE, but not in windows. IUnknown *p LoadLibrary(mscoree.dll) GetProcAddress(CreateDebuggingInterfaceFromVersion) CreateDebuggingInterfaceFromVersion(..., (void**)p) -- Com Reference FreeLibrary(mscoree.dll) p-QueryInterface();-- Cause Crash under WINE. The DLL shouldn't be unloaded since mscoree.DLLCanUnloadNow() return S_FALSE; Is this a bug with the unloading of DLL's? Is there way to stop the unloading of a DLL? I know the logic isn't the best, but I'm seeing this type of behavior in an application. Best Regards Alistair Leslie-Hughes
Re: Wine Gecko 1.4-beta1
I'm unable to apply the patch: patching file dlls/appwiz.cpl/addons.c patching file dlls/mshtml/editor.c patching file dlls/mshtml/htmldoc.c patching file dlls/mshtml/htmldoc3.c patching file dlls/mshtml/htmldoc5.c patching file dlls/mshtml/htmlimg.c patching file dlls/mshtml/htmlwindow.c patching file dlls/mshtml/nsevents.c patching file dlls/mshtml/nsiface.idl Hunk #1 FAILED at 16. 1 out of 47 hunks FAILED -- saving rejects to file dlls/mshtml/nsiface.idl.rej patching file dlls/mshtml/nsio.c patch unexpectedly ends in middle of line Hunk #2 succeeded at 2579 with fuzz 1. On Thu, Oct 6, 2011 at 8:57 PM, Jacek Caban ja...@codeweavers.com wrote: Hi all, I've just uploaded new Gecko builds [1]. To use it, you need the attached patch and the build installed to the right place [2]. As usually, everything that uses MSHTML is worth testing. All testing and feedback will be appreciated. Thanks, Jacek [1] http://sourceforge.net/projects/wine/files/Wine%20Gecko/1.4-beta1/ [2] http://wiki.winehq.org/Gecko
Re: DLLCanUnloadNow Question
On Friday 07 October 2011 11:50:17 am Alistair Leslie-Hughes wrote: Hi, The Following sample code causes a crash under WINE, but not in windows. IUnknown *p LoadLibrary(mscoree.dll) GetProcAddress(CreateDebuggingInterfaceFromVersion) CreateDebuggingInterfaceFromVersion(..., (void**)p) -- Com Reference FreeLibrary(mscoree.dll) p-QueryInterface();-- Cause Crash under WINE. The DLL shouldn't be unloaded since mscoree.DLLCanUnloadNow() return S_FALSE; Is this a bug with the unloading of DLL's? Is there way to stop the unloading of a DLL? I know the logic isn't the best, but I'm seeing this type of behavior in an application. Best Regards Alistair Leslie-Hughes Hi! It doesn't seem your test is correct. You are not supposed to use LoadLibrary directly but use COM methods that will call FreeLibrary internally when DLLCanUnloadNow returns true. The fact it doesn't crash on Windows is probably caused by mscoree.dll being kept loaded by some other components. I don't know, maybe on Windows mscoree is never unloaded - this can be verified easily. If there are actually programs that crash that way because they depend on the Windows behavior we can work around by making internally a LoadLibrary call when the first object is created and a FreeLibrary call after the last object is destroyed. Paul
Re: mmdevapi/tests: Add format tests.
Hi J�rg,
Thanks for adding these tests. It would have been nicer to split the
patch up into discrete chunks. That would make the patch much easier
to review. Overall it looks pretty good. Some remarks follow...
BTW, I've not touched
render.c:223: Test failed: IsFormatSupported(0x) call returns 8889000e
capture.ok has a similar random failure. I believe that test is bogus. It
should avoid ending up calling the exclusive mode audio endpoint and
hope/show
that the shared mode mixer aka. audio engine reports E_INVALIDARG. Perhaps
using ~AUDCLNT_SHAREMODE_EXCLUSIVE is a means to enforce this, even though
that's actually an enum, not a flag.
Yeah, that's a pretty uninteresting test. If it's flaky, I don't see
any compelling reason to keep it around.
+unk = (void*)0xDEADF00D;
hr = IAudioClient_GetService(ac, IID_IAudioStreamVolume, (void**)unk);
ok(hr == AUDCLNT_E_NOT_INITIALIZED, Uninitialized GetService call
returns %08x\n, hr);
+todo_wine ok(broken(unk != NULL), GetService %08x out pointer %p\n,
hr, unk);
This test is strange. broken() basically means should fail on
Windows, should not fail in Wine. It's used when some particular
version of Windows does something unexpected which we are uninterested
in duplicating. Do you expect unk to always be non-NULL? If so, then
just test for that without the broken() macro.
+static void test_formats(AUDCLNT_SHAREMODE mode)
The code in this function is very difficult to follow. I wonder if it
couldn't be written more clearly with explicit conditions and a bit
more code duplication.
+ok((hr == S_FALSE)^(pwfx2 == NULL), hr %x-suggest %p\n, hr,
pwfx2);
+if (pwfx2 == (WAVEFORMATEX*)0xDEADF00D) /* bug in Wine */
+pwfx2 = NULL;
Would be nicer to both fix the bug in Wine and have a test showing the
correct behavior.
@@ -1378,7 +1535,7 @@ START_TEST(render)
hr = CoCreateInstance(CLSID_MMDeviceEnumerator, NULL,
CLSCTX_INPROC_SERVER, IID_IMMDeviceEnumerator, (void**)mme);
if (FAILED(hr))
{
-skip(mmdevapi not available: 0x%08x\n, hr);
+win_skip(mmdevapi not available: 0x%08x\n, hr);
If the user has an invalid driver, CoCreateInstance() will fail to
create the enumerator object. I think that's valid behavior, so we
shouldn't fail.
Andrew
The major mmdevapi and winmm audio bugs
Hi, Bugzilla admins, please set the 1.4 milestone on all bugs mentioned here. I'm not yet looking at dsound issues since I first want a correct foundation upon which to build to upper layers. o #28039 IAudioClock_GetPosition must ignore underruns (MacOS) Here I've no idea how to solve this. My initial query remained unanswered: http://lists.apple.com/archives/coreaudio-api//2011/Sep/msg00024.html Ken? Andrew's yesterday patch (using GetCurrentPadding) is an interim work-around. GetPosition (speaker) is unrelated to padding which is solely about buffering. o #28093 GetCurrentPadding must slowly decrease (MacOS) may cause an app to play audio using a single buffer, causing underruns and audio drop outs. o #28056 Problems with sound under FreeBSD which became blocking calls with OSS recently addressed by Andrew. o snd_pcm_drop causes incorrect GetPosition after mmdevapi Stop which I believe to be the cause of: #27901 winmm tests timing out waiting for hevent after waveOutRestart May get solved by Andrew's work in: #28517 Pikachu Volleyball stops playing sound effects Every snd_pcm_drop and reset must be inspected with care w.r.t. its effect on GetPosition. Wine must ensure that after playing ends, GetPosition == sum of written samples for both mmdevapi and winmm. o #27937 winmm kept busy playing silence after play finishes IIRC because winmm writes silence. Once mmdevapi handles underruns correctly, my patch winmm: Never write silence, mmdevapi must handle underruns. will become applicable: http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html Playing silence causes: #28027 μ-law rendering with pauses and repetitions (MacOS) as well as presumably: #28413 Sound play in games and programs causes brief pauses at the time dsound used winmm prior to 1.3.29. o #28047 IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse) ALSA must derive GetPosition from snd_pcm_delay, not snd_pcm_avail_update There are other issues not associated with a bug entry. I'm off for vacation, but here's a snippet from my TODO list: - OSS GetPosition from DSP_GETODELAY - ALSA+OSS: ReleaseBuffer: check method ordering and max size - GetStreamLatency = Xms + SHAREDMODE:period Stream latency is a static property of the audio graph's components. - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY is only usable once running - Check WHDR_BEGIN/ENDLOOP code and write tests - WINMM_GetPosition is simply written_frames, not even minus padding (as the old alsa driver did), later use mmdevapi:GetPosition. - winmm PushData without IAC_Reset or last_clock_pos=0 in case of underrun - Investigate OSS4 underrun behaviour - Align wineOSS on newest ALSA code improvements - Submit CoreAudio memory leak fix to #28023; Write error handling patch - Check ALSA laptop suspend w.r.t. GetPosition - Add run-time consistency checks in renderer and abort audio stream (GetData) upon trouble instead of hanging. and finally: - Test compatibility with native DSound and file bug if unusable. There are several reports in bugzilla mentioning that this work-around ceased to work since 1.3.25. Loss of interoperability is not acceptable. Regards, Jörg Höhle
mmdevapi/tests: Add format tests.
Hi, Andrew Eikum wrote: +todo_wine ok(broken(unk != NULL), ... I'll comment on that separately. +static void test_formats(AUDCLNT_SHAREMODE mode) The code in this function is very difficult to follow. Indeed, it became more and more convoluted as I dug into native's exclusive mode disabled and other exceptions to the rule. And it's not even handling 5:1 cards correctly! Luckily, I needn't add todo_wine on top of that... For instance, winmm:wave.ok is so convoluted that one cannot tell any more what it actually checks. I'll think about a different approach with better expressiveness. For now, I consider it's time to get more tests into git and to gather results on test.winehq.org. +ok((hr == S_FALSE)^(pwfx2 == NULL), hr %x-suggest %p\n, hr, pwfx2); +if (pwfx2 == (WAVEFORMATEX*)0xDEADF00D) /* bug in Wine */ Would be nicer to both fix the bug in Wine and have a test showing the correct behavior. That is the correct behavior AFAICT: S_FALSE = set pwfx2 I've not yet submitted all of my patches about IsFormatSupported but you're right, that's an easy patch away. I forgot that one. For sure 5:1 needs more testing and I have no such HW. You have. +win_skip(mmdevapi not available: 0x%08x\n, hr); I think that's valid behavior, so we shouldn't fail. Ouch. I thought Wine has dlls/mmdevapi, so it should always load, but test.winehq.org shows that Solaris doesn't appear to have mmdevapi. Why? Regards, Jörg Höhle
todo_wine, broken() and a SW anti-pattern
Hi,
The question about how to use todo_wine and broken() comes up from
time to time. Here's new light on it, as I'm suggesting in
mmdevapi/tests/render.c:
hr = IAudioClient_GetService(ac, IID_IAudioStreamVolume, (void**)out);
ok(hr == AUDCLNT_E_NOT_INITIALIZED, ... call returns %08x\n, hr);
todo_wine ok(broken(out != NULL), GetService %08x out pointer %p\n, hr, out);
1. broken() documents that I consider native's observable behaviour
broken because I judge it unsafe not to zero the out pointer in case
of failure. Furthermore, MSDN documents that it should be zeroed.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=vs.85%29.aspx
2. Not writing ok(broken(...) || other condition)
allows to detect should MS ever change behaviour. Currently,
neither Vista, w2k8 nor w7 implement the documented behavior.
3. By using todo_wine, I acknowledge that Wine should continue to
disagree with native's behavior and safely reset the out pointer.
I mentioned wine_dont in
http://www.winehq.org/pipermail/wine-devel/2011-August/091764.html
That's not 100% bug compatible, but there's a small chance that
it helps apps *not* crash in Wine when Wine's GetService returns
E_NOTIMPL or some such that might never occur in native, hence the
app is not prepared for it.
More generally, a function with both a return code and an out pointer
is often misused. Typically, the specification says:
The out pointer is only set when the return code indicates success.
But actually, many program(mer)s use:
The pointer is non-NULL if and only if the return code indicates success.
Here's an example of broken code that follows:
/* When FAILED(hr), it is *not* the case that out == NULL.
* Hence the anti-pattern:
*/
hr = GetService(..., out);
if (SUCCEEDED(hr)) {
...
if (!...) goto exit;
...
}
exit:
if (out) { Release(out); } /* bogus */
I once found such a case in Wine but I forgot where...
(not just in mmdevapi/tests/render.c which after all is only test code)
Michael, a challenge for your static analysis tools?
Bogus too: set out = NULL prior to calling the function, because
you don't know whether the function may write something initially,
only to bail out later with an error code such as OUTOFMEMORY.
Regards,
Jörg Höhle
Re: todo_wine, broken() and a SW anti-pattern
Hi Joerg, hr = IAudioClient_GetService(ac, IID_IAudioStreamVolume, (void**)out); ok(hr == AUDCLNT_E_NOT_INITIALIZED, ... call returns %08x\n, hr); todo_wine ok(broken(out != NULL), GetService %08x out pointer %p\n, hr, out); 1. broken() documents that I consider native's observable behaviour broken because I judge it unsafe not to zero the out pointer in case of failure. Furthermore, MSDN documents that it should be zeroed. http://msdn.microsoft.com/en-us/library/windows/desktop/dd370873%28v=vs.85%29.aspx I think, philosophically, you're correct. On the other hand, Wine isn't meant to be a philosophically correct implementation of the Win32 API. And, the whole point of regression tests is that MSDN isn't to be trusted. So, while Microsoft says that the out pointer must be NULL on failure, both in this case and more generally for COM (specifically for QueryInterface), our guide has always been to trust what Microsoft does more than what it says. Our guideline for using broken() is to mark as broken the things that Microsoft has changed. Older implementations often had bugs that have subsequently been fixed, so we mark those as broken and conform to the newer behavior. On the other hand, if Windows has always had a specific behavior, than that behavior is, by definition, correct. broken() isn't appropriate in this case. Again, we must do as Microsoft does, not as it says. So I believe the correct behavior here is not to use broken(), irrespective of what MSDN says. A comment stating that MSDN is incorrect might be in order. --Juan
Re: [2/5] urlmon: Improved MapUrlToZone{Ex2} and GetSecurityId support
Hi Thomas,
On 10/6/11 6:42 PM, Thomas Mullaly wrote:
---
dlls/urlmon/sec_mgr.c | 41 +++--
dlls/urlmon/tests/sec_mgr.c | 30 +-
2 files changed, 68 insertions(+), 3 deletions(-)
+if(hres == S_FALSE){
+DWORD scheme_type;
+BOOL has_host;
+
+hres = IUri_GetScheme(uri,scheme_type);
+if(FAILED(hres)) {
+SysFreeString(scheme);
+return hres;
+}
+
+hres = IUri_HasProperty(uri, Uri_PROPERTY_HOST,has_host);
+if(FAILED(hres)) {
+SysFreeString(scheme);
+return hres;
+}
+
+/* Known hierarchical scheme types must have a host. If they don't
Windows
+ * assigns URLZONE_INVALID to the zone.
+ */
+if((scheme_type != URL_SCHEME_UNKNOWN scheme_type !=
URL_SCHEME_FILE)
+ is_hierarchical_scheme(scheme_type) !has_host) {
+*zone = URLZONE_INVALID;
It looks like get_zone_from_domains would be more logical place for
this. It already does GetScheme call and you could just handle
differently GetHost returning empty host.
if(FAILED(hres))
return hres == 0x80041001 ? E_INVALIDARG : hres;
+else if(zone == URLZONE_INVALID)
+return E_INVALIDARG;
You don't need 'else' here since if the previous if expression is true, we
return anyways.
Jacek
Re: mshtml: Implement IHTMLDOMNode replaceChild
Hi Alistair,
On 10/7/11 4:50 AM, Alistair Leslie-Hughes wrote:
+HTMLDOMNode *nodeNew;
+HTMLDOMNode *nodeOld;
Please use names consistent with the rest of the file.
+if(NS_FAILED(nsres)) {
+nsnode = nodeNew-nsnode;
+}
That seems questionable, why do you pretend to success on failure?
Jacek
Re: Wine Gecko 1.4-beta1
On 10/7/11 3:57 AM, Jerome Leclanche wrote: I'm unable to apply the patch: patching file dlls/appwiz.cpl/addons.c patching file dlls/mshtml/editor.c patching file dlls/mshtml/htmldoc.c patching file dlls/mshtml/htmldoc3.c patching file dlls/mshtml/htmldoc5.c patching file dlls/mshtml/htmlimg.c patching file dlls/mshtml/htmlwindow.c patching file dlls/mshtml/nsevents.c patching file dlls/mshtml/nsiface.idl Hunk #1 FAILED at 16. 1 out of 47 hunks FAILED -- saving rejects to file dlls/mshtml/nsiface.idl.rej patching file dlls/mshtml/nsio.c patch unexpectedly ends in middle of line Hunk #2 succeeded at 2579 with fuzz 1. I've retested and it works fine here. Are you using current Wine Git version? Which part of nsiface.idl conflict (look at the content of dlls/mshtml/nsiface.idl.rej file)? Jacek
Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
Not that I have any problems with our benevolent overlords, and not that I would likely achieve franchise with a scant 2 patches under my belt, but I can't help wondering how such a revolt would succeed seeing as the only method to achieve franchise-hood is controlled by the same people one would be revolting against. On Thu, Oct 6, 2011 at 4:30 PM, Jeremy White jwh...@codeweavers.com wrote: Hi Folks, I try to send out a periodic message to the wine-devel mailing list outlining the 'corporate' structure of Wine and how some decisions are made. We work with the Software Freedom Conservancy. They manage the pieces of Wine that benefit from a formal organization, such as managing money, holding Trademarks, and so on. The primary activity we have conducted with them over the past several years is managing money - about $3,000 each year. They manage all funds donated to Wine - the donate button goes into a bank account they manage and any larger private donations go there as well. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, we have a decision group and we require a majority of members to approve any spending. Alexandre and I are the current members of that group. We also claim the right to appoint anyone else to replace or augment the decision group. We CC all decisions to an auditor. We have recently asked Michael Stefanuic to replace Zachary Goldberg in that role. A critical requirement, we feel, is that a non CodeWeavers staff member be fully aware of all decisions made. We choose this strategy rather than a fully public process so that we can apply discretion and protect privacy of people that ask for help with travel funding. The SFC will recognize a 'revolt' by the Wine project. That is, the designated decision group can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has primarily been to help defray travel costs for Wine contributors to come to Wineconf. Wine's income has been around $3,000 / year for the past few years; we tend to spend down much of the balance each year for Wineconf. Cheers, Jeremy p.s. One note - the SFC also manages the GSOC payments, although I believe that they ostensibly manage that on behalf of Google, not really Wine. That is generally coordinated by Wine's GSOC coordinator, and Alexandre and I have nothing to do with it.
Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
Hi Michael, Not that I have any problems with our benevolent overlords, and not that I would likely achieve franchise with a scant 2 patches under my belt, but I can't help wondering how such a revolt would succeed seeing as the only method to achieve franchise-hood is controlled by the same people one would be revolting against. You are new around here, we bottom-post ;) Not true, of course. Alexandre is at the top of the list of contributors, naturally, but he doesn't constitute a controlling majority. (I'm discounting Jeremy's contributions, which is correct within tolerable error snarky grin.) --Juan
Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
On Fri, Oct 7, 2011 at 1:27 PM, Juan Lang juan.l...@gmail.com wrote: Hi Michael, Not that I have any problems with our benevolent overlords, and not that I would likely achieve franchise with a scant 2 patches under my belt, but I can't help wondering how such a revolt would succeed seeing as the only method to achieve franchise-hood is controlled by the same people one would be revolting against. You are new around here, we bottom-post ;) Not true, of course. Alexandre is at the top of the list of contributors, naturally, but he doesn't constitute a controlling majority. (I'm discounting Jeremy's contributions, which is correct within tolerable error snarky grin.) --Juan My bad, gmail makes it easy to make that mistake. ;) As I said, our overlords are kind and benevolent and I'm sure that the mention of evil plans was simply a joke as such wise and noble developers could need harbor a malevolent thought. But, unless I've been misreading this mailing list, all patches have to go through our current enlightened leader before becoming part of the patch count in the wine tree. Not that the powers that be are susceptible to temptation, but lesser mortals might find that being more selective about whose patches are accepted during periods of discontent as an easy way to influence such a vote. Likewise, even if such a mortal didn't give into temptation, if the usurpers lose the vote they could always claim such impropriety did take place. I only bring it up because tempers tend to run pretty hot over topics like ousting a project's leadership in open revolt and the last thing you want is the losing side posting ream after ream of git commit logs trying to show to that several of their supporters should have received franchise, but their patches were blocked to prevent it. Rules like that should be designed to end a conflict with creating new sources of it. .
Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.
Fails tests on x86_64? On Fri, Oct 7, 2011 at 11:52 AM, build...@kegel.com wrote: This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot 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/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_3 Errors: alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq Lfoo err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented make: *** [rpc.ok] Error 1
Re: Governance of Wine with respect to the Software Freedom Conservancy (update October 2011)
As I said, our overlords are kind and benevolent and I'm sure that the mention of evil plans was simply a joke as such wise and noble developers could need harbor a malevolent thought. But, unless I've been misreading this mailing list, all patches have to go through our current enlightened leader before becoming part of the patch count in the wine tree. Not that the powers that be are susceptible to temptation, but lesser mortals might find that being more selective about whose patches are accepted during periods of discontent as an easy way to influence such a vote. Likewise, even if such a mortal didn't give into temptation, if the usurpers lose the vote they could always claim such impropriety did take place. My point is that the math isn't in your argument's favor. It would take a long period of rejection by the current overlords before being able to squelch any hypothetical usurpers, given that a) the current overlords' contributions consist of Alexandre's, and b) he does not constitute a controlling majority of contributions, nor anywhere close to it. --Juan
Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.
Probably a spurious failure - I was running rpcrt4 tests on that machine, and they may both have wanted the same port number. Shame on me. On Fri, Oct 7, 2011 at 12:48 PM, Dan Kegel d...@kegel.com wrote: Fails tests on x86_64? On Fri, Oct 7, 2011 at 11:52 AM, build...@kegel.com wrote: This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot 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/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_3 Errors: alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq Lfoo err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented make: *** [rpc.ok] Error 1
Solved: Problems with drawing text in 1.3.29
I have narrowed the issue down to a difference in behaviour between Windows and Wine. The problem boils down to the following code: NONCLIENTMETRICS ncm; memset(ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), ncm, 0)); I used the font's returned from this call for drawing text and this caused the crash. The problem is that I upgraded to VS2010 and changed the target to WINVER=0x600. This means that I needed to change my code to the following. NONCLIENTMETRICS ncm; memset(ncm, 0, sizeof(NONCLIENTMETRICS)); ncm.cbSize = sizeof(NONCLIENTMETRICS); #if(WINVER = 0x0600) OSVERSIONINFO osvi; memset(osvi,0,sizeof(osvi)); osvi.dwOSVersionInfoSize = sizeof(osvi); GetVersionEx(osvi); if (osvi.dwMajorVersion 6) ncm.cbSize -= sizeof(ncm.iPaddedBorderWidth); #endif VERIFY(SystemParametersInfo(SPI_GETNONCLIENTMETRICS, sizeof(NONCLIENTMETRICS), ncm, 0)); Note: On windows my application does not actually crash or stop working with my original code and the text is displayed at a size I would kind of expect it to be. I will raise a bug for this one... as a difference in behaviour. On 7 October 2011 08:50, Damian Dixon damian.di...@gmail.com wrote: Thanks for the suggestions. I've narrowed one of the issues down to WineEngGetGlyphOutline in dlls/gdi32/freetype.c. The pitch is 6640 and the height is 53003. This means that a buffer of ~335Mb has been allocated and then memset. This is where the slow down is occurring (because of the memset). I suspect the resultant crash is also because of this. I would suggest that limits need to be placed on the maximum pitch and height. I do not however believe that this is the root cause just one of the symptoms. On 5 October 2011 18:37, Marcus Meissner mar...@jet.franken.de wrote: On Wed, Oct 05, 2011 at 04:53:18PM +0100, Damian Dixon wrote: Hi, I was attempting to use Wine 1.3.29 (in OpenSUSE 11.4 x86) and because of issues pulled the source from git last night and still have problems. I am having performance issues with DrawText (5 odd seconds to draw a simple string) and the occasional X Error and crash. The X Error is consistent and is as follows: fixme:advapi:SetSecurityInfo stub X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 151 (RENDER) Minor opcode of failed request: 17 (RenderCreateGlyphSet) Serial number of failed request: 41091 Current serial number in output stream: 41571 Process of pid=0023 has terminated The crash less consistent but is dependent upon the amount of text I attempt to draw. The last version I know this worked in was 1.1.39. I've a few things to still try out before I attempt to create an RBT. To get a backtrace and be able to dump some datastructures, run with WINEDEBUG=+synchronous wine foo.exe This will bring it into the debugger once the condition happens. CIao, MArcus
Re: [PATCH] server: Use syscall(2) instead of inline assembly on Mac OS; too.
On Oct 7, 2011, at 1:50 PM, Dan Kegel wrote: Probably a spurious failure Yeah... especially considering that: - That change only affects Mac OS X, and I haven't added my buildslave yet ;). (That file shouldn't even get built on non-Darwin.) - Wine won't even build 64-bit on Mac OS yet (and might never). Chip - I was running rpcrt4 tests on that machine, and they may both have wanted the same port number. Shame on me. On Fri, Oct 7, 2011 at 12:48 PM, Dan Kegel d...@kegel.com wrote: Fails tests on x86_64? On Fri, Oct 7, 2011 at 11:52 AM, build...@kegel.com wrote: This is an experimental automated build and test service. Please feel free to ignore this email while we work the kinks out. For more info about this message, see http://wiki.winehq.org/BuildBot 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/35 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) BUILD FAILED: failed shell_3 Errors: alarum: failed command was ../../../wine rpcrt4_test.exe.so rpc.c fixme:rpc:RpcNetworkIsProtseqValidW Unknown protseq Lfoo err:rpc:rpcrt4_protseq_ncacn_ip_tcp_open_endpoint couldn't listen on port 4114 rpc.c:238: Test failed: RpcServerUseProtseqEp failed (1740) fixme:rpc:RpcBindingInqAuthInfoExW authorization service not implemented make: *** [rpc.ok] Error 1
Re: [PATCH] server: if a debugger is attached to a process, child processes shouldn't get debugged (resend)
On Fri, Oct 07, 2011 at 11:44:24AM +0900, Dmitry Timoshkov wrote: Bernhard Loos bernhardl...@googlemail.com wrote: +int debug_childs:1; /* also debug all child processes */ 'debug_children' would be a better name. also unsigned intfoo:1; please. (int foo:1 works, but is semidefined only ;) Ciao, Marcus
