RESOLVED FIXED 144924
Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread
https://bugs.webkit.org/show_bug.cgi?id=144924
Summary Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of anot...
Mark Lam
Reported 2015-05-12 12:41:58 PDT
The present stack scanning code in the Windows port is expecting that the GetCurrentThread() API will provide a unique HANDLE for each thread. The code then saves and later uses that HANDLE with GetThreadContext() to get the runtime state of the target thread from the GC thread. According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx, GetCurrentThread() does not provide this unique HANDLE that we expect: "The function cannot be used by one thread to create a handle that can be used by other threads to refer to the first thread. The handle is always interpreted as referring to the thread that is using it. A thread can create a "real" handle to itself that can be used by other threads, or inherited by other processes, by specifying the pseudo handle as the source handle in a call to the DuplicateHandle function.” As a result of this, GetCurrentThread() always returns the same HANDLE value, and we end up never scanning the stacks of other threads because we wrongly think that they are all equal (in identity) to the scanning thread. This, in turn, results in crashes due objects that are incorrectly collected.
Attachments
the patch. (5.33 KB, patch)
2015-05-12 14:48 PDT, Mark Lam
no flags
patch 2: fixed Windows build problem. (5.33 KB, patch)
2015-05-12 15:11 PDT, Mark Lam
no flags
patch 3: Fixed a ChangeLog comment. (5.33 KB, patch)
2015-05-12 18:27 PDT, Mark Lam
achristensen: review+
Mark Lam
Comment 1 2015-05-12 12:54:53 PDT
Radar WebKit Bug Importer
Comment 2 2015-05-12 12:55:26 PDT
Mark Lam
Comment 3 2015-05-12 14:48:14 PDT
Created attachment 252987 [details] the patch. Uploading the patch for testing. Not ready for review yet.
Mark Lam
Comment 4 2015-05-12 15:11:26 PDT
Created attachment 252991 [details] patch 2: fixed Windows build problem.
Mark Lam
Comment 5 2015-05-12 18:27:03 PDT
Created attachment 253001 [details] patch 3: Fixed a ChangeLog comment. It's ready for review now.
Mark Lam
Comment 6 2015-05-12 18:27:47 PDT
Mark Lam
Comment 7 2015-05-12 18:27:58 PDT
Alex Christensen
Comment 8 2015-05-12 18:45:43 PDT
Comment on attachment 253001 [details] patch 3: Fixed a ChangeLog comment. View in context: https://bugs.webkit.org/attachment.cgi?id=253001&action=review > Source/JavaScriptCore/ChangeLog:20 > + handle as the source handle in a call to the DuplicateHandle function.â non-ASCII character
Mark Lam
Comment 9 2015-05-12 18:49:45 PDT
Thanks for the review. Landed in r184229: <http://trac.webkit.org/r184229>.
Geoffrey Garen
Comment 10 2015-05-13 10:22:34 PDT
Comment on attachment 253001 [details] patch 3: Fixed a ChangeLog comment. View in context: https://bugs.webkit.org/attachment.cgi?id=253001&action=review > Source/JavaScriptCore/heap/MachineStackMarker.cpp:246 > +#if OS(WINDOWS) > + HANDLE platformThreadHandle; > +#endif Should we change the type of PlatformThread in WTF? Might other uses of PlatformThread have this bug?
Mark Lam
Comment 11 2015-05-13 11:04:09 PDT
(In reply to comment #10) > Comment on attachment 253001 [details] > patch 3: Fixed a ChangeLog comment. > > View in context: > https://bugs.webkit.org/attachment.cgi?id=253001&action=review > > > Source/JavaScriptCore/heap/MachineStackMarker.cpp:246 > > +#if OS(WINDOWS) > > + HANDLE platformThreadHandle; > > +#endif > > Should we change the type of PlatformThread in WTF? Might other uses of > PlatformThread have this bug? I just did a grep throughout Source and didn’t see any references to any PlatformThread other than in MachineStackMarker. In WTF, there’s a PlatformThreadSpecificKey, but that’s a different mechanism. I also grep’ed for uses of the problematic GetCurrentThread(), and the only other use of it is in WTF/wtf/CurrentTime.cpp, and it’s using it correctly. So, I think there’s no outstanding issue.
Note You need to log in before you can comment on or make changes to this bug.