On Wed Nov 22 13:00:08 2023 +0000, Alexandre Julliard wrote:
To quicker get up to speed on what to fix here, I presume that the
functions that are edited might need corresponding changes with `__ASM_EHABI()` directives. To test the change, is there anything specific to do, or is it enough to just check that processes shut down cleanly etc? Yes, make sure that threads exit cleanly, particularly when they receive a SIGQUIT from the server.
What I'm doing to check this is:
1) Comment out `if (InterlockedDecrement( &nb_threads ) <= 0) abort_process( status );` in `abort_thread`. 2) Call `pthread_exit( UIntToPtr(status) );` before closing the fds in `pthread_exit_wrapper`. 3) Add `if (sigaction( SIGUSR2, &sig_act, NULL ) == -1) goto error;` next to `SIGQUIT` handler. 4) Run wine in Gdb (could use !1074 but that's not required if you don't care having symbols). 5) Break anywhere you want to test, call `queue-signal SIGUSR2` then `continue`.
To make sure it also works with cleanup handlers and condition variables, or if running Gdb is an issue, I also have a local change somewhere on the unix side that gets eventually called which blocks forever waiting for a USR2:
```c static void cleanup(void *arg) { fprintf(stderr, "*** cleanup called\n"); }
/* ... */ { pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_cleanup_push(cleanup, 0); pthread_cleanup_push(cleanup, 0); pthread_mutex_lock(&mutex); pthread_cond_wait(&cond, &mutex); pthread_mutex_unlock(&mutex); pthread_cleanup_pop(0); pthread_cleanup_pop(0); } ```