Various new tests for CreateProcess showing a couple of issues
in current implementation.
--
v4: kernelbase: Reset std handles gotten by GetStartupInfo().
ntdll: Restrict cases for std handle inheritance in CreateProcess().
kernel32/tests: Add more tests about CreateProcess.
kernel32/tests: Enable CreateProcess() tests on 64bit compilation.
kernel32/tests: Introduce a new infrastructure for testing CreateProcess().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4441
--
v3: wined3d: Set d3d 1-9 textures in the state as SRVs.
d3d9: Use wined3d_texture_acquire_identity_srv().
wined3d: Introduce an API for creating an identity SRV on a texture.
wined3d: Release the view's resource after destroying the view.
wined3d: Explicitly bind 0 for a NULL SRV.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4436
When running wineserver under valgrind there is a bunch of uninitialised bytes warnings when sending the req_get_mapping_info reply.
This warning can easily be reproduced by running `valgrind wineserver -f` and then `winecfg`.
Tested using self compiled wine.
Reason is the `pe_image_info_t` struct having bitfields:
```
unsigned char contains_code : 1;
unsigned char wine_builtin : 1;
unsigned char wine_fakedll : 1;
```
The last 5 bits are never initialized. This MR fixes this by zeroing the entire struct before it is filled.
I hope "issues" like this are allowed to be fixed so valgrind has less false positives.
Valgrind message for reference:
```
==628662== 716 errors in context 3 of 3:
==628662== Syscall param writev(vector[1]) points to uninitialised byte(s)
==628662== at 0x49C3A87: writev (writev.c:26)
==628662== by 0x14C2F3: send_reply (request.c:268)
==628662== by 0x14C50F: call_req_handler (request.c:316)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Address 0x53ec56e is 62 bytes inside a block of size 88 alloc'd
==628662== at 0x48416D4: malloc (vg_replace_malloc.c:431)
==628662== by 0x1348D0: mem_alloc (object.c:119)
==628662== by 0x14BEB9: set_reply_data_size (request.c:160)
==628662== by 0x1301C1: req_get_mapping_info (mapping.c:1291)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Uninitialised value was created by a client request
==628662== at 0x134873: mark_block_uninitialized (object.c:110)
==628662== by 0x1348EA: mem_alloc (object.c:120)
==628662== by 0x134B87: alloc_object (object.c:199)
==628662== by 0x134F92: create_named_object (object.c:337)
==628662== by 0x12F12B: create_mapping (mapping.c:939)
==628662== by 0x12FFE9: req_create_mapping (mapping.c:1250)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
```
--
v2: server: Fully initialize pe mapping struct to avoid uninitialized memory when sending req_get_mapping_info reply (valgrind)
https://gitlab.winehq.org/wine/wine/-/merge_requests/4414
On Thu Nov 30 19:20:58 2023 +0000, Piotr Caban wrote:
> I still don't get it - the same tests are failing on wine with the patch.
Yes, you're right, I'm sorry, I misread which tests are failing. Now things makes sense to me.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54434
On Thu Nov 30 19:20:58 2023 +0000, Zebediah Figura wrote:
> > I don't see such behavior. Could you please describe in more detail
> what have you tested (preferably attaching tests diff)? It's unlikely
> that native restores to initial environment in such case.
> I... seem to have drastically misread my results somehow.
> The attached diff does make some tests fail on Windows 10, though.
> [scratch.diff](/uploads/894d1ae22c846a46b60f74af79b0f1f7/scratch.diff)
I still don't get it - the same tests are failing on wine with the patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54428
> I don't see such behavior. Could you please describe in more detail what have you tested (preferably attaching tests diff)? It's unlikely that native restores to initial environment in such case.
I... seem to have drastically misread my results somehow.
The attached diff does make some tests fail on Windows 10, though.
[scratch.diff](/uploads/894d1ae22c846a46b60f74af79b0f1f7/scratch.diff)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54426