RESOLVED FIXED 226561
Stop using a RefPtr<IPC::Connection> as HashMap key in DisplayLink
https://bugs.webkit.org/show_bug.cgi?id=226561
Summary Stop using a RefPtr<IPC::Connection> as HashMap key in DisplayLink
Chris Dumez
Reported 2021-06-02 17:01:15 PDT
Stop using a RefPtr<IPC::Connection> as HashMap key in DisplayLink. Using a RefPtr as key is suboptimal and could leak to memory leaks. We now store IPC::Connection::UniqueID instead and look up the IPC::Connection from its identifier when we need to send an IPC.
Attachments
Patch (12.00 KB, patch)
2021-06-02 17:24 PDT, Chris Dumez
no flags
Chris Dumez
Comment 1 2021-06-02 17:24:34 PDT
Simon Fraser (smfr)
Comment 2 2021-06-02 21:15:05 PDT
Comment on attachment 430421 [details] Patch Great!
EWS
Comment 3 2021-06-02 22:09:09 PDT
Committed r278395 (238420@main): <https://commits.webkit.org/238420@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 430421 [details].
Radar WebKit Bug Importer
Comment 4 2021-06-02 22:10:17 PDT
Kimmo Kinnunen
Comment 5 2022-03-29 01:07:22 PDT
This patch is not defined C++. Single-threaded id to instance lookup can be implemented by maintaining the id map in constructor and destructor. Multi-threaded id to instance lookup cannot be implemented by maintaining the id map in the constructor and destructor. One thread might do a lookup while other thread might have already entered into the destructor, ending the life-time of the object.
Kimmo Kinnunen
Comment 6 2022-03-29 01:08:23 PDT
Comment on attachment 430421 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=430421&action=review > Source/WebKit/Platform/IPC/Connection.cpp:309 > one thread here, object life time has ended > Source/WebKit/Platform/IPC/Connection.h:530 > + return connection->send(WTFMove(message), destinationID, sendOptions); other thread here, using object that is not alive anymore
Note You need to log in before you can comment on or make changes to this bug.