Assassin's Creed Origins clobbers rbx in its main module (second of three) TLS callbacks. That is apparent right in the beginning of the TLS callback disassembly when rbx is set to '4' unconditionally without any prior save. That leads to a fault in call_tls_callbacks() which is still in __TRY block and gets handled. However the third TLS callback is not executed and that leads to intermittent hangs later on.
It is rather involved to make a TLS callback test in Wine testsuite as there is no portable way to generate a custom TLS callback. I've made a test program (based on the example here: https://lallouslab.net/2017/05/30/using-cc-tls-callbacks-in-visual-studio-w…) and compiled it with MSVC. The source code is here: https://gist.github.com/gofman/3287a953bcab3a5c888a8d494461cb8a. The program calls all the callbacks on Windows 10 here.
There is also a similar wrapper already there for i386 on another occasion.
--
v2: ntdll: Preserve rbx register when calling DLL entry point on x64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/427
Jinoh Kang (@iamahuman) commented about dlls/user32/tests/msg.c:
> DeleteObject( hrgn2 );
> }
>
> +static void visualize_region_differences( HWND hwnd, HWND hother, HRGN hrgn_expect, HRGN hrgn_actual )
I included this function since it was really helpful for me while testing debugging the implementation--it eliminates the need to interpret the rectangle list manually. I can remove this if it clutters the test, though.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/363#note_4317
Jinoh Kang (@iamahuman) commented about server/async.c:
> return woken;
> }
>
> +static int cancel_blocking( struct process *process, struct thread *thread, client_ptr_t iosb )
> +{
> + struct async *async;
> + int woken = 0;
> +
> +restart:
> + LIST_FOR_EACH_ENTRY( async, &process->asyncs, struct async, process_entry )
> + {
> + if (async->terminated || async->canceled) continue;
There is a pre-existing bug where cancellation requests are ignored for alerted asyncs (i.e. async instances that are not actually completed and can go back from the "terminated" state to the pending state). Perhaps it's worth addressing that bug first? https://www.winehq.org/pipermail/wine-devel/2022-March/210053.html
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_3836
On Thu Jul 14 06:48:37 2022 +0000, Daniel Lehman wrote:
> in the exchange, it sounded like you had or were working on a fix. were
> you asking me to fix it or wait for your fix?
Well, it was actually more of a question than a suggestion. I just wondered if it would be a good idea to get I/O cancellation right first, lest rolling in another cancellation function would result in some unknown regression due to falsely indicated success from that function.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/47#note_4299