Summary: | REGRESSION (r212929): WKSnapshotConfiguration may leak an NSNumber when deallocated | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> | ||||
Component: | WebKit2 | Assignee: | David Kilzer (:ddkilzer) <ddkilzer> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, commit-queue, jbedard, joepeck, thorton, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Other | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | 161450 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
David Kilzer (:ddkilzer)
2018-01-03 20:19:40 PST
Created attachment 330439 [details]
Patch v1
If the NSNumber object isn't set, or if it's a tagged pointer, there's probably no leak in practice, but there isn't a guarantee that a tagged pointer will always be used. Comment on attachment 330439 [details]
Patch v1
r=me! Nice
Comment on attachment 330439 [details] Patch v1 Clearing flags on attachment: 330439 Committed r226391: <https://trac.webkit.org/changeset/226391> All reviewed patches have been landed. Closing bug. Did our leak checker not identify this? (In reply to Jonathan Bedard from comment #7) > Did our leak checker not identify this? This bug was not a leak, it was an over-released object, so the leak checker wouldn't have caught it. Our internal static analysis bot would have caught it, but it's using a build of macOS prior to 10.13.2, so this particular code would not have been compiled or analyzed. (In reply to David Kilzer (:ddkilzer) from comment #8) > (In reply to Jonathan Bedard from comment #7) > > Did our leak checker not identify this? > > This bug was not a leak, it was an over-released object, so the leak checker > wouldn't have caught it. Hmm, I think this was a leak and not an over-released object. ddkilzer has been a strong proponent of having the static analyzer catch these kinds of issues, and I think the ability to 'detect leaks of strong/copy/retain properties not released in dealloc' was added to the analyzer a couple years ago: https://reviews.llvm.org/D17511 (In reply to Joseph Pecoraro from comment #9) > (In reply to David Kilzer (:ddkilzer) from comment #8) > > (In reply to Jonathan Bedard from comment #7) > > > Did our leak checker not identify this? > > > > This bug was not a leak, it was an over-released object, so the leak checker > > wouldn't have caught it. > > Hmm, I think this was a leak and not an over-released object. > > ddkilzer has been a strong proponent of having the static analyzer catch > these kinds of issues, and I think the ability to 'detect leaks of > strong/copy/retain properties not released in dealloc' was added to the > analyzer a couple years ago: > https://reviews.llvm.org/D17511 Oops! Sorry, I was thinking of a different bug (Bug 181272) that was an over-release. This was a leak! However, this leak may not have been caught by the leaks bot if this code path was not exercised in our (layout) tests, or if the NSNumber was a tagged pointer (I think). As Joseph mentioned, though, the clang static analyzer should have caught this (assuming it runs the Objective-C dealloc checker). (In reply to David Kilzer (:ddkilzer) from comment #10) > .... > > However, this leak may not have been caught by the leaks bot if this code > path was not exercised in our (layout) tests, or if the NSNumber was a > tagged pointer (I think). > > As Joseph mentioned, though, the clang static analyzer should have caught > this (assuming it runs the Objective-C dealloc checker). I have the answer to my own question. We DO use this when running layout tests, added here: <https://trac.webkit.org/changeset/216462/webkit>. But, this code path is only used when running WebKit2 tests (which we don't run leak checking on) and is only used when we have a real IOSURFACE, meaning on-device testing (which we also don't run leak checking on) |