> Actually, did you test this with a custom source?
No. I will look into that. Thanks.
> depending on a the player state it's either Stop->Start->Pause or Stop->Start
IMFMediaSession::Start() always starts the session though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42793
This reverts commit 41cc117b3f37ab4b9b4ac8a815cd2a496d38fb4b.
This commit broke musl support.
With the changes introduced, the following code evaluates
to the #else branch without checking for SO_DEFAULT_HEADERS
resulting in an error.
server/sock.c +1888
```
\#ifdef HAS_IPX
int ipx_type = protocol - WS_NSPROTO_IPX;
\#ifdef SOL_IPX
setsockopt( sockfd, SOL_IPX, IPX_TYPE, &ipx_type, sizeof(ipx_type) );
\#else
struct ipx val;
/* Should we retrieve val using a getsockopt call and then
* set the modified one? */
val.ipx_pt = ipx_type;
setsockopt( sockfd, 0, SO_DEFAULT_HEADERS, &val, sizeof(val) );
\#endif
\#endif
```
I propose reverting the commit, but we could probably alter
the macro in the code section provided to match the changes
relevant github issue:
https://github.com/void-linux/void-packages/pull/45202
Signed-off-by: Fotios Valasiadis <fvalasiad(a)gmail.com>
--
v2: server: Check for SO_DEFAULT_HEADERS before using it.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3403
Actually, did you test this with a custom source? What I see on Windows is that Start(new_position):
* stops the source;
* flushes;
* starts again with new position.
I noticed this extra stop when I tried mfplay API to see what SetPosition() is doing - depending on a the player state it's either Stop->Start->Pause or Stop->Start. Turns out this might be what session does internally.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42791
This is meant to simplify testing conditions that generally hold true
but may occasionally fail due to interference from external factors
(such as processes that start / stop, network connections being
opened / closed, etc).
The trick is loop a few times on the set of flaky conditions until
they succeed. During the last attempt all failures are recorded as
usual, while in the previous runs, tryok() failures are ignored but
cause one more attempt to be run.
The simplest case looks like this:
LOOP_ON_FLAKY_TESTS(3)
{
// ok() failures are never ignored and not retried
ok(..., "check 1", ...);
// tryok() failures are ignored except on the last attempt
tryok(..., "check 2", ...);
}
There is also:
* attempt_retry() which indicate a new attempt is needed without
counting as a failure, and returns true if a new attempt is
possible.
* attempt_failed() which returns true if the current attempt failed.
---
This is independent from the 'flaky' mechanism which adds some naming
constraints. The loop macro is still called LOOP_ON_FLAKY_TESTS()
despite being unrelated to the flaky mechanism. The attempt_retry()
and attempt_failed() macro names also don't make it obvious that they
are related to tryok().
I think this mechanism is better than the flaky one because a flaky test
can go bad without anyone noticing, whereas if a tryok() starts failing
systematically it will cause a real failure.
The other side of that coin is that, unlike flaky, the tryok()
mechanism does not entirely eliminate the possibility of getting a
failure, it just reduces it; though by adjusting the maximum number of
attempts one can achieve an arbitrarily low failure rate. For instance
if an ok() call fails 10% of the time and one wants a maximum of 1 in
a million failure rate, use LOOP_ON_FLAKY_TESTS(6). The cost is an
increased run time in the worst case.
This also limits the use of this mechanism to tests that have a
reasonably low failure rate to start with (otherwise one has to loop
too many times). Also note that there are cases where looping
essentially reduce the failure rate to zero. For instance
ieframe:webbrowser fails if IE creates a net session while the test is
counting them. But IE only creates the one net session on start up so
trying even one more time should guarantee that the test will succeed.
Other cases like scheduling delays and the creation of network
connections are more probabilistic in nature. Maybe a comment in test.h
should offer some guideline as to the target failure rate.
Eventually this may replace the flaky mechanism but that depends on
how well it works in practice and how practical it is to loop on flaky
tests. It seems to be going well in the cases I looked at. I think this
mechanism has value even if the two end up coexisting indefinitely.
In addition to introducing the framework, this MR patches some tests to use uses the tryok() mechanism for illustration and testing purposes. There are more places where this mechanism could be used but I think it's best to see about those later to keep this MR simple and focused on the new mechanism.
--
v6: advapi32/tests: Replace the custom loop with the tryok() mechanism.
ntdll/tests: Use tryok() to fix a free disk space race with other processes.
kernel32/tests: Use tryok() to fix a heap race with other processes.
tests: Add tryok() for tests that sometimes get outside interference.
tests: Update the documentation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3418
---
Note that this code never runs in d3d10+ for a 0 pixelformat.
Dxgi/tests/dxgi.c:2032 has a test that shows it results in an error.
--
v2: dxgi/tests: Test swapchains with zero dimensions.
wined3d: Move zero swapchain parameter fixup to wined3d_swapchain_state_init.
wined3d: Make wined3d_swapchain_desc in wined3d_swapchain_create const.
dxgi: Read back the swapchain size assigned by wined3d.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3538
When the path contains a mountpoint on Unix or a junction point to another drive on Windows, cmd.exe should show free space for the path instead of the root of the drive.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3610
On Fri Aug 18 02:25:13 2023 +0000, Zhiyi Zhang wrote:
> Doesn't the current MR contain only mf changes?
Sure, my comment was for initial patchset. I probably finalized comment/review too late, making this confusing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42739
Gabriel Ivăncescu (@insn) commented about dlls/mshtml/npplugin.c:
> }
>
> instance->pdata = container->plugin_host;
> - IOleClientSite_AddRef(&container->plugin_host->IOleClientSite_iface);
> + if(!err)
> + IOleClientSite_AddRef(&container->plugin_host->IOleClientSite_iface);
I'd personally check for `container->plugin_host` being non-NULL here instead of checking for err, but it doesn't really matter, depends how Jacek feels about it.
Minor nitpick: Please capitalize first word in the commit title (`check`→`Check`) and add a period at the end.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3608#note_42721
Signed-off-by: Torge Matthies <openglfreak(a)googlemail.com>
--
v3: loader: Add Default, Failed, and LastKnownGood values to HKLM\System\Select.
server: Create link from HKLM\System\CurrentControlSet to ControlSet001.
advapi32/tests: Add test for CurrentControlSet link.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3563
Still working in progress.
--
v3: winegstreamer: Implement finalize for media sink.
winestreamer: Implement wg_muxer_finalize.
winegstreamer: Introduce media_sink_write_stream.
winestreamer: Implement wg_muxer_{get,copy,free}_buffer.
winegstreamer: Implement ProcessSample for media sink.
winegstreamer: Implement wg_muxer_push_sample.
winegstreamer: Implement wg_muxer_add_stream.
winegstreamer: Create wg_muxer for media sink.
winegstreamer: Implement wg_muxer_create and wg_muxer_destroy.
winegstreamer: Add stubs for wg_muxer.
winegstreamer: Add enum wg_container_type.
mf/tests: Use h264 and aac in mp4 media sink tests.
winegstreamer: Add codec data to h264 format.
winegstreamer: Add push_event wrapper.
winegstreamer: Make append_element accpet NULL arguments.
winegstreamer: Make find_element accept NULL caps.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3303
On Fri Aug 18 01:22:20 2023 +0000, Nikolay Sivov wrote:
> I think it's better to have media engine patches in a separate MR, after
> making sure they work on Windows first.
Doesn't current MR contain only mf changes?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42670
In my opinion we're far too quiet about mmap and allocation failures that will likely be fatal to the application. It generally takes some close inspection of +virtual or even +relay to detect running out of address space, e.g..
In my testing the added logs here shouldn't be too noisy - I've avoided them in the `try` functions and in cases where an error code is normal. I made the cross-process allocation failure a warning, because the target process itself will presumably log an error if it goes wrong.
I also explicitly logged errno in a few cases where we assume its value. That can help catch some exotic error cases.
--
v3: ntdll: Add error and warning logs in more cases of memory exhaustion.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598
In my opinion we're far too quiet about mmap and allocation failures that will likely be fatal to the application. It generally takes some close inspection of +virtual or even +relay to detect running out of address space, e.g..
In my testing the added logs here shouldn't be too noisy - I've avoided them in the `try` functions and in cases where an error code is normal. I made the cross-process allocation failure a warning, because the target process itself will presumably log an error if it goes wrong.
I also explicitly logged errno in a few cases where we assume its value. That can help catch some exotic error cases.
--
v2: ntdll: Add error and warning logs in more cases of memory exhaustion.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598
Even though the uninitialized values shouldn't be used in the output
binary program, they still show up in it, and affect the checksum, so
we better make them zeroes.
This error was reported by valgrind:
```
libtool --mode=execute valgrind --track-origins=yes vkd3d-build/tests/shader_runner vkd3d/tests/hlsl/static-initializer.shader_test
```
```
==46180== Conditional jump or move depends on uninitialised value(s)
==46180== at 0x48D98C7: parse_dxbc.isra.0 (dxbc.c:182)
==46180== by 0x48DA044: vkd3d_shader_parse_dxbc (dxbc.c:308)
==46180== by 0x488D1B6: vkd3d_shader_parse_dxbc_source_type (vkd3d_shader_utils.h:37)
==46180== by 0x488D1B6: create_shader_stage.isra.0 (state.c:1988)
==46180== by 0x48926B6: d3d12_pipeline_state_init_graphics (state.c:3084)
==46180== by 0x4893A96: d3d12_pipeline_state_create_graphics (state.c:3280)
==46180== by 0x4878498: d3d12_device_CreateGraphicsPipelineState (device.c:2619)
==46180== by 0x1FFEFFECC7: ???
==46180== by 0xE8: ???
==46180== by 0x47: ???
==46180== by 0x61: ???
==46180== by 0x660066000000023: ???
==46180== by 0x661066100000044: ???
==46180== Uninitialised value was created by a stack allocation
==46180== at 0x48F3FF0: hlsl_fold_constant_swizzles (hlsl_constant_ops.c:1010)
```
Thank you valgrind! :smile:
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/308
In my opinion we're far too quiet about mmap and allocation failures that will likely be fatal to the application. It generally takes some close inspection of +virtual or even +relay to detect running out of address space, e.g..
In my testing the added logs here shouldn't be too noisy - I've avoided them in the `try` functions and in cases where an error code is normal. I made the cross-process allocation failure a warning, because the target process itself will presumably log an error if it goes wrong.
I also explicitly logged errno in a few cases where we assume its value. That can help catch some exotic error cases.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3598
Nikolay Sivov (@nsivov) commented about dlls/mf/session.c:
>
> /* fallthrough */
> case SESSION_STATE_PAUSED:
> + case SESSION_STATE_STARTED:
> + if (session->state == SESSION_STATE_STARTED && !(session->caps & MFSESSIONCAP_SEEK))
> + {
> + WARN("Seeking is not supported for this session.\n");
> + session_command_complete(session);
> + return;
> + }
Why does it check for STARTED state?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42632
Nikolay Sivov (@nsivov) commented about dlls/mf/session.c:
> }
> }
>
> + if (session->state == SESSION_STATE_STARTED)
> + {
> + session_flush_transform_output_nodes(session);
> + session_set_source_output_nodes_seeking(session);
> + }
Same here, isn't it possible to seek from paused state too?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42633
Nikolay Sivov (@nsivov) commented about dlls/mf/session.c:
> return hr;
> }
>
> +static void session_flush_transform_output_nodes(struct media_session *session)
This could be call session_flush_nodes(), or flush_topology/flush_pipeline, no need to make the name that specific.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_42631
--
v4: tests: Add a test for fmod() with vector arguments.
vkd3d-shader: Use ternary operator in fmod() implementation.
vkd3d-shader/tpf: Use 'movc' to implement ternary operator.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/268
Win10 introduced the ability for OutputDebugStringW to send
Unicode strings (instead of translating the Unicode string
to ANSI and call OutputDebugStringA).
This series:
- add a couple of tests for covering various aspects
+ how exception with unicode string is constructed,
+ interaction with WaitForDebugEvent and
WaitForDebugEventEx
- implements WaitForDebugEventEx()
- emit unicode string from OutputDebugStringW
- introduce manifest constants to describe stages in
exception testing (this let adding new stages way
easier). Note this has not been tested on ARM.
The tests results are not fully green because of existing issues
in ntdll:exception (see https://bugs.winehq.org/show_bug.cgi?id=55111
for win8 and early win10, and all the failing ones in Win11...).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3596
On Wed Aug 16 21:48:02 2023 +0000, Bartosz Kosiorek wrote:
> How it could be done (set \*result when you return)?
I just mean set *result before you return, just like you do about 5 lines before.
It appears 0 would the appropriate value, in which case you could combine the if blocks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3581#note_42603
Jeffrey Smith (@whydoubt) commented about dlls/gdiplus/tests/pathiterator.c:
> GpPath *path;
> GpPathIterator *iter;
> GpStatus stat;
> - INT start, end, result;
> - BOOL closed;
> + INT start, end, result, closed;
I would leave the type as BOOL, to make it match the 4th parameter of GdipPathIterNextSubpath.
But since it is implemented as an integer (as opposed to an actual boolean that only accepts true/false), it can contain any value that an INT can, so the tests should still be fine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3581#note_42601
I stumbled onto this while using freopen() for debugging purposes.
Basically, freopen() fails if the FILE has been created with
an invalid handle.
So, this MR contains:
- basic tests for freopen (no issue there, just for coverage purposes)
- tests for freopen on FILE with invalid handle
- fix for freopen
--
v3: msvcrt: Fix freopen() on FILE with invalid underlying fd.
msvcrt/tests: Add tests for freopen().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3578
On Wed Aug 16 20:20:19 2023 +0000, Jacek Caban wrote:
> One way or another, tests of a global state like that will always be
> theoretically a subject to race. In essence, my patch reduces problem
> probability, just like your solution.
Which is why a general solution would be better than N different hacks.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3577#note_42592
On Wed Aug 16 13:14:42 2023 +0000, Francois Gouget wrote:
> Well, I did say in bug 54866 that it looks like the extra net session is
> not created after the first SESSION_INCREMENT call so I guess this patch
> could work. But I as far as I can tell that's just how the timing of the
> race condition works and I don't think we should rely on that.
One way or another, tests of a global state like that will always be theoretically a subject to race. In essence, my patch reduces problem probability, just like your solution.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3577#note_42537