November 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 1/5] winepulse: Add initial stub for pulseaudio support
by Alexandre Julliard Nov. 3, 2015

Nov. 3, 2015

Andrew Eikum <aeikum(a)codeweavers.com> writes: > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > > Includes API compatibility patch by Juergen Tretthahn <orson(a)orson.at>. > > Synchronous static data initialization by Andrew Eikum <aeikum(a)codeweavers.com> > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> I know that this code is not supposed to be used yet, but if I try to use it, it's crashing all over the place. Is that really how it's supposed to be? ../../../tools/runtest -q -P wine -T ../../.. -M mmdevapi.dll -p mmdevapi_test.exe.so capture && touch capture.ok capture.c:247: Test succeeded inside todo block: HPC after ReleaseBuffer(0) 102136526 vs. 102136526 capture.c:310: Test succeeded inside todo block: expect DISCONTINUITY 1 capture.c:316: Test succeeded inside todo block: Position 1323 gap 441 wine: Unhandled page fault on write access to 0x00000004 at address 0x7e468d8d (thread 0009), starting debugger... Unhandled exception: page fault on write access to 0x00000004 in 32-bit code (0x7e468d8d). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e468d8d ESP:0032fb70 EBP:0032fba8 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:7e4741e0 ECX:00000000 EDX:00000000 ESI:00000000 EDI:00125ff0 Stack dump: 0x0032fb70: 7c608058 7e4747f0 0032fba8 7e465a8d 0x0032fb80: 00000001 00000000 7e4747c0 7e4747f0 0x0032fb90: 00125ff0 7e468d0b 0032fbc0 7ed5b16c 0x0032fba0: 00000001 00000000 0032fcb8 7ed40e3e 0x0032fbb0: 00000001 7ed52189 00005b4d 7ed40e3e 0x0032fbc0: 00125ff0 000001b9 00000000 7ed41bc6 Backtrace: =>0 0x7e468d8d AudioClient_Release+0x9d() in winepulse (0x0032fba8) 1 0x7ed40e3e test_audioclient+0xa8d() [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/audioclient.h:365] in mmdevapi_test (0x0032fcb8) 2 0x7ed42e45 func_capture+0x114() [/home/julliard/wine/wine/dlls/mmdevapi/tests/capture.c:1076] in mmdevapi_test (0x0032fd68) 3 0x7ed40014 main+0x393(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/mmdevapi/tests/../../../include/wine/test.h:584] in mmdevapi_test (0x0032fe18) 4 0x7ed5195b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mmdevapi_test (0x0032fe58) 5 0x7b85bc9c call_process_entry+0xb() in kernel32 (0x0032fe78) 6 0x7b85cc1a start_process+0x59(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1104] in kernel32 (0x0032fea8) 7 0x7bc7eaa0 call_thread_func_wrapper+0xb() in ntdll (0x0032fec8) 8 0x7bc8180f call_thread_func+0xde(entry=0x7b85cbc0, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2732] in ntdll (0x0032ffa8) 9 0x7bc7ea7e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 10 0x7bc53a47 start_process+0x16(kernel_start=0x7b85cbc0) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3040] in ntdll (0x0032ffe8) 11 0xf75c239d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 12 0xf75c2500 wine_switch_to_stack+0x1f(func=0x7bc53a30, arg=0x7b85cbc0, stack=0x330000) [/home/julliard/wine/wine/libs/wine/port.c:59] in libwine.so.1 (0xffb19868) 13 0x7bc596c1 LdrInitializeThunk+0x1f0(kernel_start=<couldn't compute location>, unknown2=<couldn't compute location>, unknown3=<couldn't compute location>, unknown4=<couldn't compute location>) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3094] in ntdll (0xffb198a8) 14 0x7b862849 __wine_kernel_init+0x888() [/home/julliard/wine/wine/dlls/kernel32/process.c:1276] in kernel32 (0xffb1a798) 15 0x7bc5a533 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3303] in ntdll (0xffb1a808) 16 0xf75bfe9b wine_init+0x2ca(argc=0x3, argv=0xffb1ad44, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:959] in libwine.so.1 (0xffb1a858) 17 0x7bf00d6a main+0x79(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:247] in <wine-loader> (0xffb1ac98) 18 0xf73dfa63 __libc_start_main+0xf2() in libc.so.6 (0x00000000) 0x7e468d8d AudioClient_Release+0x9d in winepulse: movl %ecx,0x4(%eax) -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: [PATCH 3/5] winepulse: Add audioclient
by Sebastian Lackner Nov. 3, 2015

Nov. 3, 2015

I know this patch is already committed, but still... On 29.10.2015 18:04, Andrew Eikum wrote: > } > if (pulse_ml) > pa_mainloop_quit(pulse_ml, 0); > + if (pulse_thread) { > + WaitForSingleObject(pulse_thread, INFINITE); This can't work. You can't wait for a thread while holding the loader lock. > > +static DWORD CALLBACK pulse_mainloop_thread(void *tmp) { > + int ret; > + pulse_ml = pa_mainloop_new(); I might be wrong, but I see a risk here that the pulse_ml conflicts with the use in pulse_test_connect(). Is it guaranteed that pulse_test_connect() is only called once after loading the DLL? Regards, Sebastian

2 1

Re: [2/2] winepulse.drv: Silence the correct buffer.
by Andrew Eikum Nov. 3, 2015

Nov. 3, 2015

On Tue, Nov 03, 2015 at 01:26:16AM +0100, Sebastian Lackner wrote: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > It seems this was a mistake while rebasing. Please note that different > buffers are used (This->tmp_buffer vs This->locked_ptr). > Good eye. I already have a patch to fix this in the sequence, unsent yet. My version adds a silence_buffer() utility method to avoid the duplicate check for the format. It'll be in the next wave. Andrew > dlls/winepulse.drv/mmdevdrv.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) > > diff --git a/dlls/winepulse.drv/mmdevdrv.c b/dlls/winepulse.drv/mmdevdrv.c > index 4863bb3..47e9b0d 100644 > --- a/dlls/winepulse.drv/mmdevdrv.c > +++ b/dlls/winepulse.drv/mmdevdrv.c > @@ -1738,18 +1738,17 @@ static HRESULT WINAPI AudioRenderClient_ReleaseBuffer( > return AUDCLNT_E_INVALID_SIZE; > } > > - if (flags & AUDCLNT_BUFFERFLAGS_SILENT) { > - if (This->ss.format == PA_SAMPLE_U8) > - memset(This->tmp_buffer, 128, written_bytes); > - else > - memset(This->tmp_buffer, 0, written_bytes); > - } > - > This->locked = 0; > - if (This->locked_ptr) > + if (This->locked_ptr) { > + if (flags & AUDCLNT_BUFFERFLAGS_SILENT) > + memset(This->locked_ptr, This->ss.format == PA_SAMPLE_U8 ? 0x80 : 0, written_bytes); > pa_stream_write(This->stream, This->locked_ptr, written_bytes, NULL, 0, PA_SEEK_RELATIVE); > - else > + } else { > + if (flags & AUDCLNT_BUFFERFLAGS_SILENT) > + memset(This->tmp_buffer, This->ss.format == PA_SAMPLE_U8 ? 0x80 : 0, written_bytes); > pa_stream_write(This->stream, This->tmp_buffer, written_bytes, pulse_free_noop, 0, PA_SEEK_RELATIVE); > + } > + > This->pad += written_bytes; > This->locked_ptr = NULL; > TRACE("Released %u, pad %zu\n", written_frames, This->pad / pa_frame_size(&This->ss)); > -- > 2.6.2

1 0

Re: [PATCH 8/8] ddraw: Mark tests which no longer pass due to reverts as todo_wine.
by Marvin Nov. 2, 2015

Nov. 2, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=17911 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2337: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw2.c:3193: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3195: Test failed: Got unexpected screen width 1024. ddraw2.c:3197: Test failed: Got unexpected screen height 768. ddraw2.c:3210: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3212: Test failed: Got unexpected screen width 1024. ddraw2.c:3214: Test failed: Got unexpected screen height 768. ddraw2.c:3218: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3220: Test failed: Got unexpected screen width 1024. ddraw2.c:3222: Test failed: Got unexpected screen height 768. ddraw2.c:3241: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3243: Test failed: Got unexpected screen width 1024. ddraw2.c:3245: Test failed: Got unexpected screen height 768. ddraw2.c:3249: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3251: Test failed: Got unexpected screen width 1024. ddraw2.c:3253: Test failed: Got unexpected screen height 768. ddraw2.c:3273: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3275: Test failed: Got unexpected screen width 1024. ddraw2.c:3277: Test failed: Got unexpected screen height 768. ddraw2.c:3282: Test failed: Got unexpected screen width 1024. ddraw2.c:3284: Test failed: Got unexpected screen height 768. ddraw2.c:3297: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3299: Test failed: Got unexpected screen width 1024. ddraw2.c:3301: Test failed: Got unexpected screen height 768. ddraw2.c:3305: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3307: Test failed: Got unexpected screen width 1024. ddraw2.c:3309: Test failed: Got unexpected screen height 768. ddraw2.c:3317: Test failed: Got unexpected screen width 1024. ddraw2.c:3319: Test failed: Got unexpected screen height 768. ddraw2.c:3331: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3333: Test failed: Got unexpected screen width 1024. ddraw2.c:3335: Test failed: Got unexpected screen height 768. ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3552: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3565: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3581: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:3600: Test failed: Display mode restored after ddraw1-ddraw2 SetCooperativeLevel() call sequence ddraw2.c:3506: Test failed: Failed to set display mode, hr 0x80004001. ddraw2.c:4757: Test failed: Failed to set display mode, hr 0x80004001. === w1064 (32 bit ddraw1) === ddraw1.c:2186: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw1.c:2931: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:2933: Test failed: Got unexpected screen width 1024. ddraw1.c:2935: Test failed: Got unexpected screen height 768. ddraw1.c:2948: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:2950: Test failed: Got unexpected screen width 1024. ddraw1.c:2952: Test failed: Got unexpected screen height 768. ddraw1.c:2956: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:2958: Test failed: Got unexpected screen width 1024. ddraw1.c:2960: Test failed: Got unexpected screen height 768. ddraw1.c:2979: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:2981: Test failed: Got unexpected screen width 1024. ddraw1.c:2983: Test failed: Got unexpected screen height 768. ddraw1.c:2987: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:2989: Test failed: Got unexpected screen width 1024. ddraw1.c:2991: Test failed: Got unexpected screen height 768. ddraw1.c:3011: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:3013: Test failed: Got unexpected screen width 1024. ddraw1.c:3015: Test failed: Got unexpected screen height 768. ddraw1.c:3020: Test failed: Got unexpected screen width 1024. ddraw1.c:3022: Test failed: Got unexpected screen height 768. ddraw1.c:3035: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:3037: Test failed: Got unexpected screen width 1024. ddraw1.c:3039: Test failed: Got unexpected screen height 768. ddraw1.c:3043: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:3045: Test failed: Got unexpected screen width 1024. ddraw1.c:3047: Test failed: Got unexpected screen height 768. ddraw1.c:3055: Test failed: Got unexpected screen width 1024. ddraw1.c:3057: Test failed: Got unexpected screen height 768. ddraw1.c:3069: Test failed: Failed to set display mode, hr 0x80004001. ddraw1.c:3071: Test failed: Got unexpected screen width 1024. ddraw1.c:3073: Test failed: Got unexpected screen height 768. ddraw1.c:4122: Test failed: Failed to set display mode, hr 0x80004001. === w1064 (32 bit ddraw7) === ddraw7.c:2183: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw7.c:3024: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3026: Test failed: Got unexpected screen width 1024. ddraw7.c:3028: Test failed: Got unexpected screen height 768. ddraw7.c:3041: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3043: Test failed: Got unexpected screen width 1024. ddraw7.c:3045: Test failed: Got unexpected screen height 768. ddraw7.c:3049: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3051: Test failed: Got unexpected screen width 1024. ddraw7.c:3053: Test failed: Got unexpected screen height 768. ddraw7.c:3072: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3074: Test failed: Got unexpected screen width 1024. ddraw7.c:3076: Test failed: Got unexpected screen height 768. ddraw7.c:3080: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3082: Test failed: Got unexpected screen width 1024. ddraw7.c:3084: Test failed: Got unexpected screen height 768. ddraw7.c:3104: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3106: Test failed: Got unexpected screen width 1024. ddraw7.c:3108: Test failed: Got unexpected screen height 768. ddraw7.c:3113: Test failed: Got unexpected screen width 1024. ddraw7.c:3115: Test failed: Got unexpected screen height 768. ddraw7.c:3128: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3130: Test failed: Got unexpected screen width 1024. ddraw7.c:3132: Test failed: Got unexpected screen height 768. ddraw7.c:3136: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3138: Test failed: Got unexpected screen width 1024. ddraw7.c:3140: Test failed: Got unexpected screen height 768. ddraw7.c:3148: Test failed: Got unexpected screen width 1024. ddraw7.c:3150: Test failed: Got unexpected screen height 768. ddraw7.c:3162: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3164: Test failed: Got unexpected screen width 1024. ddraw7.c:3166: Test failed: Got unexpected screen height 768. ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4021: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4034: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4050: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:4069: Test failed: Display mode restored after ddraw1-ddraw7 SetCooperativeLevel() call sequence ddraw7.c:3975: Test failed: Failed to set display mode, hr 0x80004001. ddraw7.c:5877: Test failed: Failed to set display mode, hr 0x80004001. === w864 (64 bit ddraw7) === ddraw7: unhandled exception c0000005 at 0000000000000000 === w1064 (64 bit ddraw7) === The test timed out === w1064 (32 bit ddraw4) === ddraw4.c:2522: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. ddraw4.c:3363: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3365: Test failed: Got unexpected screen width 1024. ddraw4.c:3367: Test failed: Got unexpected screen height 768. ddraw4.c:3380: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3382: Test failed: Got unexpected screen width 1024. ddraw4.c:3384: Test failed: Got unexpected screen height 768. ddraw4.c:3388: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3390: Test failed: Got unexpected screen width 1024. ddraw4.c:3392: Test failed: Got unexpected screen height 768. ddraw4.c:3411: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3413: Test failed: Got unexpected screen width 1024. ddraw4.c:3415: Test failed: Got unexpected screen height 768. ddraw4.c:3419: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3421: Test failed: Got unexpected screen width 1024. ddraw4.c:3423: Test failed: Got unexpected screen height 768. ddraw4.c:3443: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3445: Test failed: Got unexpected screen width 1024. ddraw4.c:3447: Test failed: Got unexpected screen height 768. ddraw4.c:3452: Test failed: Got unexpected screen width 1024. ddraw4.c:3454: Test failed: Got unexpected screen height 768. ddraw4.c:3467: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3469: Test failed: Got unexpected screen width 1024. ddraw4.c:3471: Test failed: Got unexpected screen height 768. ddraw4.c:3475: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3477: Test failed: Got unexpected screen width 1024. ddraw4.c:3479: Test failed: Got unexpected screen height 768. ddraw4.c:3487: Test failed: Got unexpected screen width 1024. ddraw4.c:3489: Test failed: Got unexpected screen height 768. ddraw4.c:3501: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:3503: Test failed: Got unexpected screen width 1024. ddraw4.c:3505: Test failed: Got unexpected screen height 768. ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:4392: Test failed: Display mode restored after good ddraw1::SetCooperativeLevel call ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:4405: Test failed: Display mode restored after ddraw1::SetCooperativeLevel(SETFOCUSWINDOW) call ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:4421: Test failed: Display mode restored after good-bad ddraw1::SetCooperativeLevel() call sequence ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:4440: Test failed: Display mode restored after ddraw1-ddraw4 SetCooperativeLevel() call sequence ddraw4.c:4346: Test failed: Failed to set display mode, hr 0x80004001. ddraw4.c:6081: Test failed: Failed to set display mode, hr 0x80004001.

2 1

Re: [PATCH 2/4] winex11: Avoid inefficiency and overflow in remove_startup_notification.
by Vincent Povirk Nov. 2, 2015

Nov. 2, 2015

It seems like you're doing two unrelated things here? I'd expect the process of building the string to send and sending it to be independent. > if ((src = strstr( id, "_TIME" ))) update_user_time( atol( src + 5 )); > > - pos = snprintf(message, sizeof(message), "remove: ID="); > - message[pos++] = '"'; > - for (i = 0; id[i] && pos < sizeof(message) - 2; i++) > + pos = sprintf(message, "remove: ID=\""); > + for (i = 0; id[i]; i++) > { > if (id[i] == '"' || id[i] == '\\') > + { > + if (pos == sizeof(message) - 3) break; > message[pos++] = '\\'; > + } > + if (pos == sizeof(message) - 2) break; > message[pos++] = id[i]; > } > message[pos++] = '"'; > message[pos++] = '\0'; Your use of == instead of > or >= in these checks makes me uncomfortable. Given that a single iteration can increment pos twice, why can't we have a situation where (pos > sizeof(message) - 3), inside the if statement? As for the memset, I didn't examine that as thoroughly, but it's a good policy to not send uninitialized data over the wire. Still, we could move the memset outside the loop and know that won't happen.

2 3

Re: [PATCH 6/6] mmdevapi/tests: Remove todo_wine on some tests for winepulse
by Marvin Nov. 2, 2015

Nov. 2, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=17908 Your paranoid android. === w7u (32 bit capture) === capture.c:329: Test failed: GCP 11200 vs. BufferSize 21996 === w8 (32 bit capture) === capture.c:325: Test failed: Position 3127 gap 1152 capture.c:349: Test failed: Position 4215 expected 3575 capture.c:374: Test failed: Position 5303 expected 4023 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:263: Test failed: Position 2167 expected 1463 capture.c:325: Test failed: Position 3255 gap 1344 capture.c:349: Test failed: Position 4343 expected 3703 capture.c:374: Test failed: Position 4791 expected 4151 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:263: Test failed: Position 2167 expected 1527 capture.c:325: Test failed: Position 4151 gap 2176 capture.c:329: Test failed: GCP 12992 vs. BufferSize 21996 capture.c:349: Test failed: Position 5239 expected 4599 capture.c:350: Test failed: flags 1 capture.c:374: Test failed: Position 5687 expected 5047 === w864 (64 bit capture) === capture.c:329: Test failed: GCP 13888 vs. BufferSize 21996 === w1064 (64 bit capture) === capture.c:329: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:349: Test failed: Position 5239 expected 4663 capture.c:374: Test failed: Position 5687 expected 5111

1 0

Re: [4/4] dlls/ole32: Add more traces to the storage methods. Take 2.
by Vincent Povirk Nov. 2, 2015

Nov. 2, 2015

> static HRESULT TransactedSnapshotImpl_LockTransaction(StorageBaseImpl *base, BOOL write) > { > + FIXME("stub\n"); > return E_NOTIMPL; > } > > static HRESULT TransactedSnapshotImpl_UnlockTransaction(StorageBaseImpl *base, BOOL write) > { > + FIXME("stub\n"); > return E_NOTIMPL; > } It's the same situation with these two. They are internal functions, and they're not supposed to be implemented.

2 2

Re: [v3 resend] d3d9: call wined3d_device_copy_sub_resource_region instead of wined3d_device_update_surface in d3d9_device_U
by Marvin Nov. 2, 2015

Nov. 2, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=17903 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 1/7] wined3d: Introduce wined3d_device_map_sub_resource().
by Henri Verbeet Nov. 2, 2015

Nov. 2, 2015

On 2 November 2015 at 04:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +HRESULT CDECL wined3d_device_map_sub_resource(struct wined3d_device *device, > + struct wined3d_resource *resource, unsigned int sub_resource_idx, > + struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags) > +{ > + struct wined3d_resource *sub_resource; > + > + TRACE("device %p, resource %p, sub_resource_idx %u, map_desc %p, box %p, flags %#x.\n", > + device, resource, sub_resource_idx, map_desc, box, flags); > + > + if (!(sub_resource = sub_resource_from_resource(resource, sub_resource_idx))) > + { > + WARN("Invalid sub_resource_idx %u.\n", sub_resource_idx); > + return E_INVALIDARG; > + } > + > + return sub_resource->resource_ops->resource_map(sub_resource, map_desc, box, flags); > +} I suppose in d3d11 this is part of ID3D11DeviceContext because of deferred contexts maps. Perhaps once we have those in wined3d it will end up in the device (although I think it's more likely to become part of some interface on top of wined3d_cs), but right now the "device" parameter isn't even used. I think that for the time being the interface we want is just HRESULT CDECL wined3d_resource_map(struct wined3d_resource *resource, unsigned int sub_resource_idx, struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); > diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h > index fd7bbc8..fb296b1 100644 > --- a/dlls/wined3d/wined3d_private.h > +++ b/dlls/wined3d/wined3d_private.h > @@ -2156,6 +2156,8 @@ struct wined3d_resource_ops > ULONG (*resource_incref)(struct wined3d_resource *resource); > ULONG (*resource_decref)(struct wined3d_resource *resource); > void (*resource_unload)(struct wined3d_resource *resource); > + HRESULT (*resource_map)(struct wined3d_resource *resource, struct wined3d_map_desc *map_desc, > + const struct wined3d_box *box, DWORD flags); > }; > Here we'll probably want something like HRESULT (*resource_sub_resource_map)(struct wined3d_resource *resource, unsigned int sub_resource_idx, struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags); That implies having different resource ops for 2D and 3D textures, but that's easy. It also implies returning an error when this is called on a surface or volume. I'm not sure how easy it would be at this point, but we'll probably just want resource ops on sub-resources to print an ERR(). E.g. ideally we'd never call resource_unload() on a surface, but only ever on a texture. But that then means not adding sub-resources to the device's resource list, etc.

2 1

Re: [PATCH 04/10] ucrtbase: Handle the swprintf style termination and return values
by Piotr Caban Nov. 2, 2015

Nov. 2, 2015

Hi, On 11/02/15 11:08, Martin Storsjo wrote: > @@ -724,12 +724,13 @@ int CDECL MSVCRT__stdio_common_vsprintf( unsigned __int64 options, char *str, MS > struct _str_ctx_a ctx = {len, str}; > int ret; > > - if (options != UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION && > - options != UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR) > + if (options & ~UCRTBASE_PRINTF_TERMINATION_MASK) > FIXME("options %s not handled\n", wine_dbgstr_longlong(options)); > - ret = pf_printf_a(options & UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR ? puts_clbk_str_c99_a : puts_clbk_str_a, > + ret = pf_printf_a(options & UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION ? puts_clbk_str_a : puts_clbk_str_c99_a, > &ctx, format, locale, FALSE, FALSE, arg_clbk_valist, NULL, &valist); > puts_clbk_str_a(&ctx, 1, &nullbyte); > + if ((options & UCRTBASE_PRINTF_TERMINATION_MASK) == 0 && ret >= len) > + ret = -2; > return ret; > } This code looks like you're trying to make the things other way around. Shouldn't UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR flag impact the callback being used? On the other hand UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION flag should probably only affect terminating NULL related behavior. Maybe following code makes more sense: ret = pf_printf_a(options & UCRTBASE_PRINTF_STANDARD_SNPRINTF_BEHAVIOUR ? puts_clbk_str_c99_a : puts_clbk_str_a, &ctx, format, locale, FALSE, FALSE, arg_clbk_valist, NULL, &valist); if(puts_clbk_str_a(&ctx, 1, &nullbyte)==-1 && !(options & UCRTBASE_PRINTF_LEGACY_VSPRINTF_NULL_TERMINATION)) { if(len) str[len-1] = 0; return -2; } return ret; What do you think about it? Thanks, Piotr

3 5

Re: [3/7] widl: Ignore assignment of a duplicate uuid. Resend.
by Huw Davies Nov. 2, 2015

Nov. 2, 2015

On Sat, Oct 31, 2015 at 02:31:38PM +0800, Dmitry Timoshkov wrote: > diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c > index daa0366..dc8b124 100644 > --- a/tools/widl/write_msft.c > +++ b/tools/widl/write_msft.c > @@ -494,10 +494,22 @@ static int ctl2_alloc_guid( > MSFT_GuidEntry *guid_space; > int hash_key; > > + chat("adding uuid {%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n", > + guid->guid.Data1, guid->guid.Data2, guid->guid.Data3, > + guid->guid.Data4[0], guid->guid.Data4[1], guid->guid.Data4[2], guid->guid.Data4[3], > + guid->guid.Data4[4], guid->guid.Data4[5], guid->guid.Data4[6], guid->guid.Data4[7]); > + > hash_key = ctl2_hash_guid(&guid->guid); > > offset = ctl2_find_guid(typelib, hash_key, &guid->guid); > - if (offset != -1) return offset; > + if (offset != -1) > + { > + warning("duplicate uuid {%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x}\n", > + guid->guid.Data1, guid->guid.Data2, guid->guid.Data3, > + guid->guid.Data4[0], guid->guid.Data4[1], guid->guid.Data4[2], guid->guid.Data4[3], > + guid->guid.Data4[4], guid->guid.Data4[5], guid->guid.Data4[6], guid->guid.Data4[7]); > + return -1; > + } > > offset = ctl2_alloc_segment(typelib, MSFT_SEG_GUID, sizeof(MSFT_GuidEntry), 0); This still has problems. For example see the idl below. Also note that this is the cause of the warnings in httpresquest.idl . Huw. import "objidl.idl"; [uuid(12345678-0000-0000-0000-000000000000)] library foo { typedef [uuid(12345678-9ab0-0000-0000-000000000000)] struct f {int x;} f; [uuid(12345678-9abc-0000-0000-000000000000)] interface IMy : IUnknown { HRESULT foo([in]f *ptr); } }

2 1

Re: [PATCH 1/7] wined3d: Introduce wined3d_device_map_sub_resource().
by Stefan Dösinger Nov. 2, 2015

Nov. 2, 2015

> Am 02.11.2015 um 04:17 schrieb Józef Kucia <jkucia(a)codeweavers.com>: > > +HRESULT CDECL wined3d_device_map_sub_resource(struct wined3d_device *device, > + struct wined3d_resource *resource, unsigned int sub_resource_idx, > + struct wined3d_map_desc *map_desc, const struct wined3d_box *box, DWORD flags) > +{ > + struct wined3d_resource *sub_resource; > + > + TRACE("device %p, resource %p, sub_resource_idx %u, map_desc %p, box %p, flags %#x.\n", > + device, resource, sub_resource_idx, map_desc, box, flags); > + > + if (!(sub_resource = sub_resource_from_resource(resource, sub_resource_idx))) > + { > + WARN("Invalid sub_resource_idx %u.\n", sub_resource_idx); > + return E_INVALIDARG; > + } > + > + return sub_resource->resource_ops->resource_map(sub_resource, map_desc, box, flags); I don't like the idea of calling the sub resource here. I think this should forward to wined3d_texture_map for textures for now and pass the sub resource index to the resource_map callback. In the long run we obviously want wined3d_texture_map and wined3d_buffer_map to be merged together, but for now (surface,volume)->(texture) is tricky enough. I have some patches in the works for that.

1 0

Re: [PATCH 2/6] wined3d: Keep track of FBOs through the GL names (v2).
by Henri Verbeet Nov. 2, 2015

Nov. 2, 2015

On 28 October 2015 at 15:29, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 2: Don't use fbo_entry->d3d_* for logging, plan for it to go > away. The disadvantage is now that we don't know the d3d properties once > we find out that an FBO doesn't work and need a full TRACE log for this > information, but I think that's something we can live with. > > If there is a prettier way to find the texture target of a GL texture > name please advise. I couldn't find any. > I think I'll hold off on this until the regression from 1ca9dfc8ee25f4ae188fdacd4d3d56046cef8003 is resolved, but you can probably split the logging changes into their own patch. > + char name[32]; > + sprintf(name, "Color attachment %u", i); > + context_dump_fbo_attachment(gl_info, target, GL_COLOR_ATTACHMENT0 + i, name); sprintf() is one of those things that's usually best avoided. In this case the string is mostly redundant as well, since you have the attachment enum. > +static inline void context_create_fbo_key(struct wined3d_fbo_entry_key *key, > + struct wined3d_surface **render_targets, struct wined3d_surface *depth_stencil, > + DWORD color_location, DWORD ds_location, UINT color_buffers) The naming is a bit odd. "create" is usually for things that allocate something, "color_buffers" would normally be called e.g. "rt_count". The "inline" seems speculative. I think modern compilers mostly ignore it, but it does make it harder to notice when a function becomes unused. > - entry = HeapAlloc(GetProcessHeap(), 0, sizeof(*entry)); > - entry->render_targets = HeapAlloc(GetProcessHeap(), 0, gl_info->limits.buffers * sizeof(*entry->render_targets)); > - memcpy(entry->render_targets, render_targets, gl_info->limits.buffers * sizeof(*entry->render_targets)); > - entry->depth_stencil = depth_stencil; > - entry->color_location = color_location; > - entry->ds_location = ds_location; > + UINT object_count = gl_info->limits.buffers + 1; > + > + entry = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + FIELD_OFFSET(struct fbo_entry, key.objects[object_count])); > + entry->d3d_render_targets = HeapAlloc(GetProcessHeap(), 0, > + gl_info->limits.buffers * sizeof(*entry->d3d_render_targets)); > + context_create_fbo_key(&entry->key, render_targets, depth_stencil, color_location, ds_location, > + gl_info->limits.buffers); > + memcpy(entry->d3d_render_targets, render_targets, sizeof(*entry->d3d_render_targets) * gl_info->limits.buffers); > + entry->d3d_depth_stencil = depth_stencil; Why HEAP_ZERO_MEMORY? Do we no longer initialize all fields? > + { > + struct wined3d_fbo_resource resource = {0}; > + context_attach_depth_stencil_fbo(context, target, &resource, FALSE, 0, 0); "resource" should probably be static const. > - if (surface == entry->render_targets[i]) > + if (surface->container->texture_rgb.name == entry->key.objects[i].object || > + surface->container->texture_srgb.name == entry->key.objects[i].object) This is different from the usual style.

2 2

Re: [PATCH 02/4 resend] msvcp110: Add tr2_sys__Read_dir implementation.(try 2)
by Piotr Caban Nov. 2, 2015

Nov. 2, 2015

On 10/31/15 10:29, YongHao Hu wrote: > + TRACE("(%s %p %p)\n", debugstr_a(target), handle, type); Please print the target argument correctly in trace message. Thanks, Piotr

1 0

Re: [v3] d3d9: call wined3d_device_copy_sub_resource_region instead of wined3d_device_update_surface in d3d9_device_UpdateSu
by Marvin Nov. 2, 2015

Nov. 2, 2015

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 https://testbot.winehq.org/JobDetails.pl?Key=17891 Your paranoid android. === build (build) === Patch failed to apply

1 0

loader manpages get installed in wrong build step
by Sebastian Lackner Nov. 2, 2015

Nov. 2, 2015

Hiho, I've noticed another side effect introduced by http://source.winehq.org/git/wine.git/commit/da340169d6518cf42f1cbe169fbf12…, and I'm not sure if its intentional, or if its a bug. For WOW64 builds all manpages were installed in the 64-bit build step before. After the commit, some manpages (those in loader/) also get installed in the 32-bit build step. Here are some logs for comparison: - before: http://repos.wine-staging.com/all/20151021-0141-arch-x64/build.log - after: http://repos.wine-staging.com/all/20151101-0726-arch-x64/build.log (search for "wine.1" for example) When both builds end in the same package (like on Archlinux) this doesn't matter, however there are plenty of distributions which ship the 32-bit and 64-bit parts in different packages. Having a few manpages in one and the rest in the other is at least a bit unusual, but could also lead to package conflicts. Should this be considered a bug, or is it up to package maintainers to workaround this issue? And what would be the preferred solution to fix this? I don't really want to reintroduce install-man-pages just after it was removed... Best regards, Sebastian

3 3

Microsoft shared PDB fileformat
by Marcus Meissner Nov. 2, 2015

Nov. 2, 2015

Hi, just in from the hell-freezes-over department: https://github.com/Microsoft/microsoft-pdb Ciao, Marcus

3 2

Fwd: steam web browsing on OS X
by Theodore Dubois Nov. 2, 2015

Nov. 2, 2015

How exactly does Chromium replace the system calls with its own versions? Not quite sure how that works. ~Theodore On Nov 01, 2015, at 07:18 PM, Sebastian Lackner <sebastian(a)fds-team.de> wrote: On 02.11.2015 04:09, Theodore Dubois wrote: Darn! Forgot to cc the list. Can someone explain exactly why absolute addresses are needed here? I'm new to wine, but eager to learn. The main reasons are: - The code still has to work after Chromium has moved it to a different memory location. A relative jump would not be suitable for that. Also, in our proof of concept patch, we want to avoid huge syscall tables, and instead pass a pointer in %eax. - DRM applications might complain when a function entry point looks too unusual. - In "non-relaxed" mode Chromium refuses to accept the entry point, if it doesn't match exactly the function signature on Windows. I don't think this is used for Steam yet, but its just a matter of time. Regards, Sebastian

1 0

Fwd: steam web browsing on OS X
by Theodore Dubois Nov. 2, 2015

Nov. 2, 2015

Darn! Forgot to cc the list. Can someone explain exactly why absolute addresses are needed here? I'm new to wine, but eager to learn. ~Theodore On Nov 01, 2015, at 04:29 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: Hi Sebastian, On 10/30/15 5:57 PM, Sebastian Lackner wrote: On 30.10.2015 17:42, Theodore Dubois wrote: Wine Staging includes some patches to fix Steam web browsing, but they are deactivated on Mac because they apparently require special build flags. Does anyone know what this refers to? ~Theodore The staged patchset adds thunk wrappers for ntdll functions, but to be compatible with Windows, they have to contain absolute addresses. This requires text relocations, which are not allowed by default on OSX. Since this issue was discovered shortly before the last release, disabling the patchset on OSX was easier than the necessary configure.ac changes, but I'm working on a solution. Unless we hit some impossible to solve problems Wine Staging 1.7.54 will make the Steam fix also available on OSX. ;) I took a look at this problem and the patchset and I think we should be able to avoid text relocation in this case. I should have a proof of concept patch soon. Thanks, Jacek

2 1

Re: [4/4] dlls/ole32: Add more traces to the storage methods.
by Vincent Povirk Nov. 1, 2015

Nov. 1, 2015

Whoops, accidentally dropped wine-devel from my reply. On Sun, Nov 1, 2015 at 6:49 AM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > There's no test that calls these directly because they are internal methods. > I could have used any code to signal that the operation does not make sense > for this object. > > We should have tests that open and commit to a non-toplevel storage object, > which would call them. Sorry, that wasn't quite right. It's not enough to commit to a non-toplevel storage object. What you'd have to do is nest transacted storages and commit to the inner one.

1 0

Re: [4/4] dlls/ole32: Add more traces to the storage methods.
by Vincent Povirk Nov. 1, 2015

Nov. 1, 2015

On Thu, Oct 29, 2015 at 2:41 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > static HRESULT TransactedSnapshotImpl_GetTransactionSig(StorageBaseImpl *base, > ULONG* result, BOOL refresh) > { > + FIXME("stub\n"); > return E_NOTIMPL; > } This is intentional. We don't need transaction signatures because nothing else can have our snapshot open to commit to it. Anything calling these methods should expect and handle E_NOTIMPL.

2 3

Re: [2/4] dlls/ole32: Zero out returned stats when IEnumSTATSTG::Next reaches end of enumeration.
by Vincent Povirk Nov. 1, 2015

Nov. 1, 2015

Are you sure we shouldn't be zeroing the entire remaining buffer? And maybe we should put it after the loop, given there are multiple exits.

2 1