February 2017 - Wine-devel - list.winehq.org

Re: [PATCH] oledb32/tests: Fix a use-after-free in test_converttobyrefwstr.
by Alistair Leslie-Hughes 28 Feb '17

28 Feb '17

Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>

1 0

Re: [v2] Use CP 1200 (Unicode) for Win32/Win64 version info.
by Alexandre Julliard 28 Feb '17

28 Feb '17

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > [v2] Fix test failures in mshtml.dll caused by npmshtml.dll. > According to Gecko Plugin API Reference[1], plugin's version stamp must > be set to English US and Windows Multilingual, i.e. "040904E4". > [1] https://developer.mozilla.org/en-US/docs/Plugins/Guide/Plug-in_Development_… > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/npmshtml/rsrc.rc | 1 + > dlls/version/tests/info.c | 2 -- > include/wine/wine_common_ver.rc | 24 ++++++++++++++++++++++-- > 3 files changed, 23 insertions(+), 4 deletions(-) It's still failing here: ../../../tools/runtest -q -P wine -T ../../.. -M mshtml.dll -p mshtml_test.exe.so htmldoc && touch htmldoc.ok htmldoc.c:6287: Test failed: open failed: 80040152 wine: Unhandled page fault on read access to 0xdeadbeef at address 0x7ed051dd (thread 0154), starting debugger... Unhandled exception: page fault on read access to 0xdeadbeef in 32-bit code (0x7ed051dd). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7ed051dd ESP:0033fc20 EBP:0033fc78 EFLAGS:00010202( R- -- I - - - ) EAX:deadbeef EBX:7ed6a000 ECX:00000001 EDX:7ed80f00 ESI:0000188d EDI:7ed4388a Stack dump: 0x0033fc20: 00000001 7ed449d1 80040152 7ed050ad 0x0033fc30: 005e0000 00689650 005e8de8 00000000 0x0033fc40: 7ed39473 7ed7f1a0 80040152 7ed4388a 0x0033fc50: 005b4d80 7ed4388a 005e8de8 deadbeef 0x0033fc60: 7ed4521a 00000000 7ed04f0e 7ed6a000 0x0033fc70: 005b4d80 7ed4388a 0033fcd8 7ed0ddd9 Backtrace: =>0 0x7ed051dd test_open_window+0x2dd(doc=<is not available>, do_block=0) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/mshtml.h:51848] in mshtml_test (0x0033fc78) 1 0x7ed0ddd9 test_HTMLDocument_http+0x678(with_wbapp=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/htmldoc.c:7877] in mshtml_test (0x0033fcd8) 2 0x7ed128d9 func_htmldoc+0xda8() [/home/julliard/wine/wine/dlls/mshtml/tests/htmldoc.c:8742] in mshtml_test (0x0033fd58) 3 0x7ecc305d main+0x25c(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:589] in mshtml_test (0x0033fe08) 4 0x7ed38d8b __wine_spec_exe_entry+0x4a(peb=<couldn't compute location>) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mshtml_test (0x0033fe48) 5 0x7b45e56c call_process_entry+0xb() in kernel32 (0x0033fe68) 6 0x7b45f4a9 start_process+0x68(entry=<couldn't compute location>) [/home/julliard/wine/wine/dlls/kernel32/process.c:1116] in kernel32 (0x0033fea8) 7 0x7bc8071c call_thread_func_wrapper+0xb() in ntdll (0x0033fec8) 8 0x7bc834d9 call_thread_func+0xa8(entry=0x7b45f440, arg=0x7ed38d40, frame=0x33ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2759] in ntdll (0x0033ffa8) 9 0x7bc806fa call_thread_entry_point+0x11() in ntdll (0x0033ffc8) 10 0x7bc53f73 start_process+0x12(arg=0xffcb6418) [/home/julliard/wine/wine/dlls/ntdll/loader.c:3054] in ntdll (0x0033ffe8) 11 0xf756d8dd __x86.get_pc_thunk.di+0x2a() in libwine.so.1 (0x00000000) 12 0xf756da40 wine_switch_to_stack+0x1f(func=0x7bc53f60, arg=0xffcb6418, stack=0x340000) [/home/julliard/wine/wine/libs/wine/port.c:77] in libwine.so.1 (0xffcb63e8) 13 0x7bc59b26 LdrInitializeThunk+0x235(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:3115] in ntdll (0xffcb6438) 14 0x7b4653af __wine_kernel_init+0xa4e() [/home/julliard/wine/wine/dlls/kernel32/process.c:1310] in kernel32 (0xffcb7328) 15 0x7bc5a983 __wine_process_init+0x152() [/home/julliard/wine/wine/dlls/ntdll/loader.c:3324] in ntdll (0xffcb7398) 16 0xf756bb43 wine_init+0x2a2(argc=0x3, argv=0xffcb78e4, error="", error_size=0x400) [/home/julliard/wine/wine/libs/wine/loader.c:956] in libwine.so.1 (0xffcb73e8) 17 0x7c000b58 main+0x97(argc=<is not available>, argv=<is not available>) [/home/julliard/wine/wine/loader/main.c:254] in <wine-loader> (0xffcb7838) 18 0xf7375276 __libc_start_main+0xf5() in libc.so.6 (0x00000000) 0x7ed051dd test_open_window+0x2dd [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/mshtml.h:51848] in mshtml_test: movl 0x0(%eax),%edx 51848 return This->lpVtbl->close(This); -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/6] wined3d: Handle raw thread group shared memory declarations.
by Henri Verbeet 28 Feb '17

28 Feb '17

On 28 February 2017 at 14:42, Józef Kucia <jkucia(a)codeweavers.com> wrote: > @@ -1047,6 +1047,31 @@ static HRESULT shader_get_registers_used(struct wined3d_shader *shader, const st > { > reg_maps->temporary_count = ins.declaration.count; > } > + else if (ins.handler_idx == WINED3DSIH_DCL_TGSM_RAW) > + { > + unsigned int reg_idx = ins.declaration.tgsm_raw.reg.reg.idx[0].offset; > + if (reg_idx >= MAX_TGSM_REGISTERS) > + { > + ERR("Invalid TGSM register index %u.\n", reg_idx); > + break; > + } > + if (shader_version.type == WINED3D_SHADER_TYPE_COMPUTE) > + { > + struct wined3d_shader_tgsm *tgsm; > + > + if (!wined3d_array_reserve((void **)&reg_maps->tgsm, &reg_maps->tgsm_capacity, > + reg_idx + 1, sizeof(*reg_maps->tgsm))) I'm not sure about this. I guess the expectation is that these will get allocated consecutively and starting from 0, while even starting at MAX_TGSM_REGISTERS-1 and going down wouldn't be terrible. Still, I'm wondering if it wouldn't be worth it to only allocate space for the number of declarations, and use e.g. bsearch().

2 1

Re: [PATCH 1/5] wined3d: Use the command stream state in wined3d_cs_exec_draw().
by Sebastian Lackner 28 Feb '17

28 Feb '17

On 28.02.2017 06:11, Henri Verbeet wrote: > Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com> > --- > dlls/wined3d/cs.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > This patch causes corrupted graphics in multiple games. The problem is caused by uninitialized memory in the wined3d_state structs. Currently the struct is only cleared in wined3d_cs_exec_reset_state, but it probably should be cleared always when WINED3D_STATE_INIT_DEFAULT is passed, otherwise the CS and the main state can go out of sync. Could you please take a look? Example app (~40 MB): https://archive.org/download/MotoRacer2Demo/MotoRacer2Demo.zip (sha256: 02c8523d61619b9f65d874e15af9838ebf78938a720c5b61504d97c0b7cc68c9) Best regards, Sebastian

2 2

Re: tools: remove wineinstall
by Dmitry Timoshkov 28 Feb '17

28 Feb '17

Austin English <austinenglish(a)gmail.com> wrote: > -2. QUICK START > - > -Whenever you compile from source, it is recommended to use the Wine > -Installer to build and install Wine. From the top-level directory > -of the Wine source (which contains this file), run: > - > -./tools/wineinstall > - > -Run programs as "wine program". For more information and problem > -resolution, read the rest of this file, the Wine man page, and > -especially the wealth of information found at http://www.winehq.org. Perhaps the 2nd part of this section should stay since it doesn't have anything to do with the wineinstall script. And regarding compilation it's worth to at least mention wiki/docs/forums I'd guess. -- Dmitry.

1 0

Re: Proposal: winetest 'context'
by Sebastian Lackner 27 Feb '17

27 Feb '17

On 27.02.2017 20:19, Mark Jansen wrote: > This syntax is a lot better, > however it will break when ':' is used in the format string. > It might be a better idea to keep a list of indexes alongside the > context buffer? Not sure if its required. I think it would be a bit confusing when ":" is used inside of a context string. If devs want to use ":" as separator for variables they could also do something like: with_context("i=%d", i) with_context("j=%d", j) { // here some tests } > > As for the name, use_context or set_context ? That would also be fine, but I don't think its much better than with_context(). > > regards, > > Mark Jansen > > On Mon, Feb 27, 2017 at 12:06 AM, Sebastian Lackner > <sebastian(a)fds-team.de> wrote: >> On 25.02.2017 13:34, Józef Kucia wrote: >>> On Tue, Feb 14, 2017 at 5:04 PM, Mark Jansen <learn0more+wine(a)gmail.com> wrote: >>>> Hello, >>>> >>>> Often when testing something, helper functions are introduced that are >>>> called with different data (for example when iterating over tables). >>>> >>>> Attached patch (winetest_set_context.diff) is a proposal that allows >>>> tests to specify a 'context', that will be printed in the failure >>>> message. >>>> This way, the actual test code does not have to prefix every case with >>>> a trace, or include the data in every test macro. >>>> The patch is written so that tests do not have to use this mechanism, >>>> so there is no need to convert all tests at once. >>>> Second attachment (winetest_ctx_example.diff) shows how an existing >>>> test could be converted to use this new technique. >>> >>> For what it's worth, if we had a mechanism to set a context for test >>> messages, I would gladly use it in d3d11 tests. >>> >>> Cheers, >>> Józef >> >> I would also like to see such a feature, however I'm not really happy with >> a single context string which has to be set and reset manually. So, here is >> an alternative proposal which allows to use a block-syntax like: >> >> --- snip --- >> with_context("i = %d, j = %d", i, j) >> { >> // here some tests >> } >> --- snip --- >> >> Blocks can also be nested, and its easy to combine them with a loop: >> >> --- snip --- >> for (i = 0; i < 100; i++) with_context("test %d", i) >> { >> // here some tests (don't use break!) >> } >> --- snip --- >> >> The only disadvantage is that we need variadic macros (__VA_ARGS__), but it >> looks like they are already used in a bunch of other tests, so thats probably >> not a real problem. Please let me know what you think about this method, and >> also if you have suggestions for a better name. >> >> Best regards, >> Sebastian >>

1 0

The Wine Project has been accepted as a GSoC 2017 mentor organization!
by André Hentschel 27 Feb '17

27 Feb '17

I just invited a lot of possible Mentors, if I missed someone, please let me know

1 0

Re: [1/4] dinput: Keep username same between device objects.
by Bruno Jesus 27 Feb '17

27 Feb '17

On Wed, Feb 22, 2017 at 8:22 PM, Jetro Jormalainen <jje-wine(a)jv.jetro.fi> wrote: > Tested on Windows 10, Windows XP and Arch Linux. Hi, thanks for the patches. In order to help testing do you mind explaining how to test them? Like is there any game demo/freeware that is able to benefit from the patches?

2 1

Re: [PATCH 3/5] winebus.sys: Process device reports for linux event devices
by Sebastian Lackner 27 Feb '17

27 Feb '17

On 27.02.2017 16:09, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/winebus.sys/bus_udev.c | 163 +++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 162 insertions(+), 1 deletion(-) > > > > 0003-winebus.sys-Process-device-reports-for-linux-event-dev.txt > > > diff --git a/dlls/winebus.sys/bus_udev.c b/dlls/winebus.sys/bus_udev.c > index e2a475ccd8..2f198c7d4f 100644 > --- a/dlls/winebus.sys/bus_udev.c > +++ b/dlls/winebus.sys/bus_udev.c > @@ -242,6 +242,9 @@ struct wine_input_absinfo { > struct wine_input_private { > struct platform_private base; > > + int buffer_length; > + BYTE *report_buffer; > + > int report_descriptor_size; > BYTE *report_descriptor; > > @@ -340,6 +343,87 @@ static const BYTE* what_am_I(struct udev_device *dev) > return Unknown; > } > > +static BOOL set_button_value(struct wine_input_private *ext, int code, int value) > +{ > + int index = ext->button_map[code]; > + int bindex = index / 8; > + int b = index % 8; > + BYTE mask; > + > + mask = 1<<b; > + if (value) > + ext->report_buffer[bindex] = ext->report_buffer[bindex] | mask; > + else > + { > + mask = ~mask; > + ext->report_buffer[bindex] = ext->report_buffer[bindex] & mask; > + } > + return TRUE; > +} > + > +static BOOL set_abs_axis_value(struct wine_input_private *ext, int code, int value) > +{ > + int index; > + /* check for hatswitches */ > + if (code <= ABS_HAT3Y && code >= ABS_HAT0X) > + { > + index = code - ABS_HAT0X; > + ext->hat_values[index] = value; > + if ((code - ABS_HAT0X) % 2) > + index--; > + if (ext->hat_values[index] == 0) > + { > + if (ext->hat_values[index+1] == 0) > + value = 8; > + else if (ext->hat_values[index+1] < 0) > + value = 0; > + else > + value = 4; > + } > + else if (ext->hat_values[index] > 0) > + { > + if (ext->hat_values[index+1] == 0) > + value = 2; > + else if (ext->hat_values[index+1] < 0) > + value = 1; > + else > + value = 3; > + } > + else > + { > + if (ext->hat_values[index+1] == 0) > + value = 6; > + else if (ext->hat_values[index+1] < 0) > + value = 7; > + else > + value = 5; > + } > + ext->report_buffer[ext->hat_map[index]] = value; > + return TRUE; > + } > + else if (code < HID_ABS_MAX && ABS_to_HID_map[code][0] != 0) > + { > + index = ext->abs_map[code].report_index; > + *((WORD*)&ext->report_buffer[index]) = MulDiv(value, 0xff, ext->abs_map[code].info.maximum - ext->abs_map[code].info.minimum); > + return TRUE; > + } > + return FALSE; > +} > + > +static BOOL set_rel_axis_value(struct wine_input_private *ext, int code, int value) > +{ > + int index; > + if (code < HID_REL_MAX && REL_to_HID_map[code][0] != 0) > + { > + index = ext->rel_map[code]; > + if (value > 127) value = 127; > + if (value < -127) value = -127; > + ext->report_buffer[index] = value; > + return TRUE; > + } > + return FALSE; > +} > + > static VOID build_report_descriptor(struct wine_input_private *ext, struct udev_device *dev) > { > int abs_pages[TOP_ABS_PAGE][HID_ABS_MAX+1]; > @@ -510,6 +594,37 @@ static VOID build_report_descriptor(struct wine_input_private *ext, struct udev_ > memcpy(report_ptr, report_tail, sizeof(report_tail)); > > ext->report_descriptor_size = descript_size; > + ext->buffer_length = report_size; > + ext->report_buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, report_size); > + > + /* Initialize axis in the report */ > + for (i = 0; i < HID_ABS_MAX; i++) > + if (test_bit(absbits, i)) > + set_abs_axis_value(ext, i, ext->abs_map[i].info.value); > +} > + > +static BOOL set_report_from_event(struct wine_input_private *ext, struct input_event *ie) > +{ > + switch(ie->type) > + { > +#ifdef EV_SYN > + case EV_SYN: > + return FALSE; > +#endif > +#ifdef EV_MSC > + case EV_MSC: > + return FALSE; > +#endif > + case EV_KEY: > + return set_button_value(ext, ie->code, ie->value); > + case EV_ABS: > + return set_abs_axis_value(ext, ie->code, ie->value); > + case EV_REL: > + return set_rel_axis_value(ext, ie->code, ie->value); > + default: > + ERR("TODO: Process Report (%i, %i)\n",ie->type, ie->code); > + return FALSE; > + } > } > #endif > > @@ -846,9 +961,52 @@ static NTSTATUS lnxev_get_string(DEVICE_OBJECT *device, DWORD index, WCHAR *buff > return STATUS_NOT_IMPLEMENTED; > } > > +static DWORD CALLBACK lnxev_device_report_thread(void *args) > +{ > + DEVICE_OBJECT *device = (DEVICE_OBJECT*)args; > + struct wine_input_private *private = input_impl_from_DEVICE_OBJECT(device); > + struct pollfd plfds[2]; > + > + plfds[0].fd = private->base.device_fd; > + plfds[0].events = POLLIN; > + plfds[0].revents = 0; > + plfds[1].fd = private->base.control_pipe[0]; > + plfds[1].events = POLLIN; > + plfds[1].revents = 0; > + > + while (1) > + { > + int size; > + struct input_event ie; > + > + if (poll(plfds, 2, -1) <= 0) continue; > + if (plfds[1].revents || !private->report_buffer || private->buffer_length == 0) It would be better to catch memory allocation failures earlier than while processing device reports. > + break; > + size = read(plfds[0].fd, &ie, sizeof(ie)); > + if (size == -1) > + TRACE_(hid_report)("Read failed. Likely an unplugged device\n"); > + else if (size == 0) > + TRACE_(hid_report)("Failed to read report\n"); > + else if (set_report_from_event(private, &ie)) > + process_hid_report(device, private->report_buffer, private->buffer_length); > + } > + return 0; > +} > + > static NTSTATUS lnxev_begin_report_processing(DEVICE_OBJECT *device) > { > - return STATUS_NOT_IMPLEMENTED; > + struct wine_input_private *private = input_impl_from_DEVICE_OBJECT(device); > + You have to check that the thread was not started yet. > + pipe(private->base.control_pipe); Some error handling wouldn't hurt. > + private->base.report_thread = CreateThread(NULL, 0, lnxev_device_report_thread, device, 0, NULL); > + if (!private->base.report_thread) > + { > + ERR("Unable to create device report thread\n"); > + close(private->base.control_pipe[0]); > + close(private->base.control_pipe[1]); > + return STATUS_UNSUCCESSFUL; > + } > + return STATUS_SUCCESS; > } > > static NTSTATUS lnxev_set_output_report(DEVICE_OBJECT *device, UCHAR id, BYTE *report, DWORD length, ULONG_PTR *written) > @@ -990,6 +1148,9 @@ static void try_remove_device(struct udev_device *dev) > close(private->control_pipe[0]); > close(private->control_pipe[1]); > CloseHandle(private->report_thread); > +#ifdef HAS_PROPER_INPUT_HEADER > + HeapFree(GetProcessHeap(), 0, ((struct wine_input_private*)private)->report_buffer); It looks like this will attempt to release an invalid pointer for hidraw devices. > +#endif > } > > dev = private->udev_device; > > >

1 0

Re: [2/4] dinput: Handle username in EnumDevicesBySemantics.
by Andrew Eikum 27 Feb '17

27 Feb '17

On Thu, Feb 23, 2017 at 01:22:19AM +0200, Jetro Jormalainen wrote: > @@ -955,6 +998,14 @@ static HRESULT WINAPI IDirectInput8AImpl_EnumDevicesBySemantics( > > didevi.dwSize = sizeof(didevi); > > + if (ptszUserName) > + { > + username_size = MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, 0, 0); > + MultiByteToWideChar(CP_ACP, 0, ptszUserName, -1, username_w, username_size); Normally, we use the return from MultiByteToWideChar to allocate the destination buffer. You could switch to that. I'm not opposed to doing it on the stack like this, but then there's no need for username_size. You can just pass the size of the buffer in WCHARs as the last param of MultiByteToWideChar. Andrew

1 0