Bug 1838286 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The race in comment 0 is when execution reaches manages to reach our own function (here, `patched_BaseThreadInitThunk`). But another thread can also start executing the code of the hooked function (here, `BaseThreadInitThunk`) *while* we are altering the code of the hooked function. As far as I can tell, we currently don't do anything to prevent those either. With our `BaseThreadInitThunk` example, this results in crashes in the signature that I am adding, where the instruction pointer is in the middle of `BaseThreadInitThunk` with a bad instruction.
The race in comment 0 is when execution manages to reach our own function (here, `patched_BaseThreadInitThunk`). But another thread can also start executing the code of the hooked function (here, `BaseThreadInitThunk`) *while* we are altering the code of the hooked function. As far as I can tell, we currently don't do anything to prevent those either. With our `BaseThreadInitThunk` example, this results in crashes in the signature that I am adding, where the instruction pointer is in the middle of `BaseThreadInitThunk` with a bad instruction.
The race in comment 0 is when execution manages to reach our own function (here, `patched_BaseThreadInitThunk`). But another thread can also be executing the code of the hooked function (here, `BaseThreadInitThunk`) *while* we are altering the code of the hooked function. As far as I can tell, we currently don't do anything to prevent those either. With our `BaseThreadInitThunk` example, this results in crashes in the signature that I am adding, where the instruction pointer is in the middle of `BaseThreadInitThunk` with a bad instruction.
The race in comment 0 is when execution manages to reach our own function (here, `patched_BaseThreadInitThunk`). But another thread can also be executing the code of the hooked function (here, `BaseThreadInitThunk`) *while* we are altering the code of the hooked function. As far as I can tell, we currently don't do anything to prevent this kind of race either. With our `BaseThreadInitThunk` example, this results in crashes in the signature that I am adding, where the instruction pointer is in the middle of `BaseThreadInitThunk` with a bad instruction.

Back to Bug 1838286 Comment 2