742833 - In WindowsDllInterceptor, write to the trampoline value as soon as it's valid

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Justin Lebar (not reading bugmail)]

In bug 741540 comment 0, it was noted that the WindowsDllInterceptor assigns to its return value later than it needs to.

Assigning to the trampoline earlier doesn't make us totally thread-safe, but it does mitigate a large race.

If none of this makes sense, the patch may help.  :)

Comment 1

[Justin Lebar (not reading bugmail)]

https://tbpl.mozilla.org/?tree=Try&rev=0310bf82b978

Comment 2

[Justin Lebar (not reading bugmail)]

Attachment: Patch v1

Comment 3

[Mozilla RelEng Bot]

Try run for 0310bf82b978 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=0310bf82b978
Results (out of 50 total builds):
    success: 44
    warnings: 6
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-0310bf82b978

Comment 4

[Mike Hommey [:glandium]]

Comment on attachment 612708 [details] [diff] [review]
Patch v1

Review of attachment 612708 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/xre/nsWindowsDllInterceptor.h
@@ +350,5 @@
>  
>      memcpy(tramp, origFunction, nBytes);
>  
> +    // The trampoline is now valid.
> +    *outTramp = tramp;

The trampoline is actually not valid at this point. It is only valid after all the tramp[...] assignments that create a jump into the original function. However, it doesn't really matter, because the hook function won't be called before the original function is patched to call the hook function, which is done later than that.

I'd either change the comment or move this assignment for good measure.

Comment 5

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/c3276660b556