Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 966da8693f4b60deedaa3226f3641530ff7d5f0a
https://github.com/WebKit/WebKit/commit/966da8693f4b60deedaa3226f3641530ff7d5f0a
Author: Geoffrey Garen <gga...@apple.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M Source/WebKit/Shared/API/APIObject.cpp
M Source/WebKit/Shared/API/APIObject.h
M Source/WebKit/Shared/Cocoa/APIObject.mm
Log Message:
-----------
API objects should be safe to ref() inside their constructors
https://bugs.webkit.org/show_bug.cgi?id=280278
rdar://136599625
Reviewed by Chris Dumez and Ryosuke Niwa.
284023@main caused a crash because it instantiated a RefPtr inside an API
object's constructor.
API objects delegate refcounting to their ObjC wrappers. However, the wrapper
data member is not initialized until after construction is over, so RefPtr
inside a constructor is use of uninitialized memory.
Fix this by initializing the wrapper data member in our base class
constructor.
For now, we use a ThreadSpecific to avoid having to update all API
constructors and #ifdef them for COCOA vs non-COCOA. Longer term, it
would be nice to find a way to just pass the wrapper as a constructor
argument.
(Note: We can't just assign the wrapper before invoking the constructor
because that's Undefined Behavior, and an API test seems to demonstrate
that clang does in fact trip over it, at least some of the time.)
* Source/WebKit/Shared/API/APIObject.h:
(API::Object::constructInWrapper):
Canonical link: https://commits.webkit.org/284236@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
