[Webkit-unassigned] [Bug 141614] New: [iOS] Possible Block Leak WKAutoCorrectionData.autocorrectionContextHandler

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=141614

            Bug ID: 141614
           Summary: [iOS] Possible Block Leak
                    WKAutoCorrectionData.autocorrectionContextHandler
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: joepeck at webkit.org
                CC: enrica at apple.com, simon.fraser at apple.com

* SUMMARY
Possible Block Leak WKAutoCorrectionData.autocorrectionContextHandler.

Auditing the code, it looks like this block can be assigned a copy that is never released by anyone:

        _autocorrectionData.autocorrectionContextHandler = [completionHandler copy];
        _page->requestAutocorrectionContext([self](...) {
            _autocorrectionData.autocorrectionContextHandler([WKAutocorrectionContext autocorrectionContextWithData:beforeText markedText:markedText selectedText:selectedText afterText:afterText selectedRangeInMarkedText:NSMakeRange(location, length)]);
        });

Looks like we should be releasing (and probably niling) _autocorrectionData.autocorrectionContextHandler. Or better yet, don't store these on the struct at all, and just capture them inside the block/lambda.

All of the blocks assigned to WKAutoCorrectionData have sketchy lifetimes. They can are always set on the struct without clearing any possible value that may have been there before. Is there a guarantee that they won't be overwritten?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150215/200e500a/attachment-0002.html>