September 2011 - Wine-Devel

Re: Complaint about mmdevapi (COM?) logging

by Henri Verbeet

On 27 September 2011 13:49, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > snippet. It looks like a +relay log, not showing what I want to see. That's mostly intentional, for COM traces in general at least. The main purpose of the initial trace in COM calls is to show that a function gets called at all, since these don't show up in +relay. You can of course add extra traces for interesting things further down in a function, but it pretty much depends on the specific function what makes sense and what doesn't. I'm pretty sure the idea isn't to always trace as much as possible.

Sept. 27, 2011

Re: [PATCH] kernel32: make it possible to create a backtrace from a RaiseException exception in gdb

by Alexandre Julliard

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -60,6 +60,17 @@ static PTOP_LEVEL_EXCEPTION_FILTER top_filter; > typedef INT (WINAPI *MessageBoxA_funcptr)(HWND,LPCSTR,LPCSTR,UINT); > typedef INT (WINAPI *MessageBoxW_funcptr)(HWND,LPCWSTR,LPCWSTR,UINT); > > +#ifdef __i386__ > +/* without this, it's impossible to get a backtrace from the raised > + * exception in winedbg in gdb mode */ > +void RaiseException_helper(EXCEPTION_RECORD *r, void *f) DECLSPEC_HIDDEN; > +__ASM_GLOBAL_FUNC(RaiseException_helper, > + "mov 0x4(%esp),%eax\n\t" > + "push %eax\n\t" > + "mov 0xc(%esp),%eax\n\t" > + "call *%eax\n\t" > + "ret") > +#endif You shouldn't need anything like that. -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2011

Re: [PATCH] ntdll/signal_i386.c: RtlCaptureContext locals + args are 12 bytes instead of 8 (return address + CONTEXT * arg + %eax local

by Alexandre Julliard

Bernhard Loos <bernhardloos(a)googlemail.com> writes: > @@ -1181,7 +1181,7 @@ __ASM_STDCALL_FUNC( RtlCaptureContext, 4, > __ASM_CFI(".cfi_adjust_cfa_offset 4\n\t") > "popl 0xc0(%eax)\n\t" /* context->EFlags */ > __ASM_CFI(".cfi_adjust_cfa_offset -4\n\t") > - "leal 8(%esp),%edx\n\t" > + "leal 0xc(%esp),%edx\n\t" > "movl %edx,0xc4(%eax)\n\t" /* context->Esp */ That's not really more correct, it's supposed to return the caller frame but there's no good way of doing that. What are you trying to fix? -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2011

Re: mscoree: Add ICorDebug interface support (try 2)

by Alexandre Julliard

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > +#include "initguid.h" > +/* We need to undefine the MACRO CreateProcess since the ICorDebug interface > + has a function with this name. (Stops a compile issue). > + */ > +#undef CreateProcess > +#include "cordebug.h" This should go in the header. Check how other idl files are doing it. -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2011

Re: 79358: mscoree: Add ICorDebug interface support

by Dan Kegel

build failed here - did you forget a file? ../../tools/makedep -C. -S../.. -T../.. assembly.c config.c cordebug.c corruntimehost.c metadata.c metahost.c mscoree_main.c debugging.c: No such file or directory make[1]: *** [depend] Error 1 make[1]: Leaving directory `/home/bob/wineslave.dir/sandbox/slave/runtests-default/build/dlls/mscoree/tests' make: *** [dlls/mscoree/tests/__depend__] Error 2 On Tue, Sep 27, 2011 at 4:20 AM, <buildbot(a)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 while building Wine. > Full details are available at: http://buildbot.kegel.com/builders/runtests-default/builds/109 (though maybe not for long, as I'm still reinstalling the buildbot periodically while experimenting) > BUILD FAILED: failed shell_2 > > Errors: > make[1]: *** [depend] Error 1 > make: *** [dlls/mscoree/tests/__depend__] Error 2 > >

Sept. 27, 2011

Complaint about mmdevapi (COM?) logging

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, I'm not satisfied with the current winmm+mmdevapi logging. I suspect that COM logging of other components is similarly bad. Consider the following snippet. It looks like a +relay log, not showing what I want to see. 0022:trace:winmm:waveOutWrite (0xc000, 0x21f140, 32) 0020:trace:winmm:WOD_PushData (0xc000) 0020:trace:alsa:AudioClient_GetBufferSize (0x48f7700)->(0x4b0e9c4) 0020:trace:alsa:AudioClient_GetCurrentPadding (0x48f7700)->(0x4b0e9c8) 0020:trace:alsa:AudioClock_GetFrequency (0x48f7700)->(0x4b0e930) 0020:trace:alsa:AudioClock_GetPosition (0x48f7700)->(0x4b0e928, (nil)) 0020:trace:alsa:AudioClient_GetCurrentPadding (0x48f7700)->(0x4b0e8b4) 0020:trace:alsa:AudioRenderClient_GetBuffer (0x48f7700)->(256, 0x4b0e9c0) 0020:trace:alsa:AudioClient_GetCurrentPadding (0x48f7700)->(0x4b0e938) 0020:trace:alsa:AudioRenderClient_ReleaseBuffer (0x48f7700)->(256, 0) 0020:trace:winmm:WOD_PushData (0xc000) I don't want those %p pointers, I want values. - What's the position? - What's the low-level driver's padding? - What's the mmdevapi padding? - How many samples did waveOutWrite() supply? - Where's any log line from the intermittent mmdevapi periodic timer callback? + The current log is easily compressible :-) The only concrete data is from GetBuffer/ReleaseBuffer: 256 frames, so GetCurrentPadding probably returned GetBuffersize (whose value I derive from the call to Initialize, not shown here) minus 256. The bad news is that you derive more from what you *don't* see in the log than what's written therein. This costs time and effort. E.g. GetBuffer wasn't called means buffer was full -- wait, perhaps there was no more queued data? Help! Why do I believe that logging of other COM dlls may be similarly bad? The anti-pattern is to have a TRACE at function entry! I'd rather move that down a few lines, after basic checking of parameters. At that time you can TRACE some meaningful values instead of pointers. Then you may even decide to put the TRACE at the end of the function, e.g. for GetCurrentPadding that makes a lot of sense, without the added cost of two TRACE lines. Basically, there's little value in an early TRACE because only in rare case will you want to know that the call may have been aborted by E_INVALIDARG or AUDCLNT_E_NOT_INITIALIZED -- not to mention that those return values are almost never logged, not even with +relay. Actually, the useful amount of logging is a function of code maturity. Initially, you're happy with logging every API call. Once you've tested that the basic input checks work exactly like in native, you want to see more from the inside. IOW, initial stubs contain nothing but TRACE. When you fill the function body, it is an error to leave the TRACE at the top, it should move down to the heart of the function where the interesting stuff happens. Regards, Jörg Höhle

Sept. 27, 2011

Re: mscoree: Add ICorDebug interface support (try 2)

by Marvin

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=14582 Your paranoid android. === W2K3R2SESP2 (32 bit debugging) === debugging.c:82: Test failed: CreateDebuggingInterfaceFromVersion returned 80070057

Sept. 27, 2011

Re: mscoree: Add ICorDebug interface support

by Marvin

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=14581 Your paranoid android. === WINEBUILD (build) === Make failed

Sept. 27, 2011

winmm: waveOutReset returns all buffers.

by Joerg-Cyril.Hoehle＠t-systems.com

Dan, >Fails to apply here. (Requires fuzz, which Alexandre says is verboten.) >error: dlls/winmm/waveform.c: patch does not apply This raises the question about when to use [PATCH X/Y] and/or whether buildbots should apply all precedingly submitted patches that did not fail. I tend to use X/Y subject lines when patches depend on each other in the sense that one should not apply patch #2 without #1. There was no such dependency here, one could commit or reject each individually. The only particularity about yesterday's patches is that there were 2 patches to the same function, waveOutReset. Trying to apply the second one without the first obviously needs a "fuzz", yet the second patch *can* be used stand alone. Luckily, AJ is much smarter than the bot, and all patches went in. Regards, Jörg Höhle

Sept. 27, 2011

Re: msi/tests: Properly preserve pending file renames.

by Marvin

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=14578 Your paranoid android. === WNT4WSSP6 (32 bit install) === install.c:5996: Test failed: Per-user icon file isn't where it's expected (C:\WINNT\Profiles\Default User\Application Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)

Sept. 27, 2011