This change is ready for review.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
If we don't have crashes in code below that does ptr->..., perhaps we should just delete the null checks instead? Maybe replacing with DCHECKs()?
Patch Set 1:
If we don't have crashes in code below that does ptr->..., perhaps we should just delete the null checks instead? Maybe replacing with DCHECKs()?
Not sure about not having crashes.
Chrome has crash reporting and crashes are routinely addressed. So I think given crash reporting has not alerted us to crashes in these places, it's safe to assume that these pointers cannot be null currently.
6 comments:
File base/metrics/field_trial.cc:
Patch Set #1, Line 1447: if (allocator->IsReadonly()))
Nit: Simpler:
if (!allocator || allocator->IsReadOnly())
I don't know this code, so I can't tell you whether |allocator| can actually be null. AddToAllocatorWhileLocked() handles the case of a null allocator, which supports the idea that it can be.
Patch Set #1, Line 1454: AddToAllocatorWhileLocked(global_->field_trial_allocator_.get(),
Nit: While here: change the first arg of this to |allocator| (since that's what it is)
File chrome/browser/search/search.cc:
Patch Set #1, Line 382: if (!profile)
I think |profile| cannot be null here, so I'd remove this check.
File chrome/browser/ui/browser_commands.cc:
Patch Set #1, Line 876: if (!current_tab)
Various other commands in this file assume an active web contents. I think it's safe to remove this check.
File content/browser/renderer_host/render_widget_host_impl.cc:
Patch Set #1, Line 1712: if (!delegate_)
Functions like OnStartDragging() assume a delegate, so I think it's OK to remove this check.
File third_party/WebKit/Source/core/dom/Document.cpp:
Patch Set #1, Line 2332: if (!frame_view) {
Nit: Change to:
DCHECK(frame_view);
DCHECK(!frame_view->IsInPerformLayout()) << "View Layout should not be re-entrant";
(The old code violated the style guide by handling DCHECK failure)
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Patch Set 1:
(6 comments)
Thanks! Updated the patch.
Patch Set 2:
Patch Set 1:
(6 comments)
Thanks! Updated the patch.
Gentle ping for this trivial patch.
Patch Set 2:
Patch Set 2:
Patch Set 1:
(6 comments)
Thanks! Updated the patch.
Gentle ping for this trivial patch.
Note that it's the weekend and most of us aren't working -- will take a look at your patch when back in the office.
LGTM % comment
Patch set 2:Code-Review +1
1 comment:
File third_party/WebKit/Source/core/dom/Document.cpp:
Nit: I think putting the message as a comment above the DCHECK() is better, since then the extra text doesn't get compiled into builds and bloat the binary or compile/link times - while still available when someone goes to investigate what's wrong.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Nit: I think putting the message as a comment above the DCHECK() is better, since then the extra tex […]
DCHECK << "" shouldn't cause release-mode binary bloat, should it? If it does it seems like we have larger problems.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Patch Set 2: Code-Review+1
(1 comment)
Alexei and Peter, thanks for LGTMs!
I added few more similar fixes not to bloat additional reviews. Hope you don't mind.
1 comment:
DCHECK << "" shouldn't cause release-mode binary bloat, should it? If it does it seems like we have […]
There a lot of uses of <DCHECK() << "String"> in Chromium code and I don't think it poses any perf issue.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
1 comment:
DCHECK << "" shouldn't cause release-mode binary bloat, should it? If it does it seems like we have […]
That's correct. But it does for debug binaries (which will slow down compiles, bots, etc).
And the benefit don't seem worth the bloat there given whoever investigates this will look at this code.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
1 comment:
That's correct. But it does for debug binaries (which will slow down compiles, bots, etc). […]
I don't think we should discourage people from adding log messages on failed DCHECKs; in fact I'd prefer more of our comments became log messages. This would often help track down failures on bots faster.
I don't think there's significant impact on compile speed/bot runtime from this. Binary size can take an aggregate hit, but for debug, it's not so severe as to cause problems we care about.
If you still disagree, I suggest raising this with a larger audience (e.g. chromium-dev) to see if there's more consensus that reviewers should discourage explanatory messages on DCHECKs.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Patch set 6:Commit-Queue +2
CQ is trying the patch.
Note: The patchset sent to CQ was uploaded after this CL was approved.
"[clang-tidy] Fix access via null pointer to objects" https://chromium-review.googlesource.com/c/955852/6
Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/chromium-review.googlesource.com/955852/6
Bot data: {"action": "start", "triggered_at": "2018-03-14T05:11:00.0Z", "cq_cfg_revision": "b6c5f044c073ae207081077d3fd1ff808549a7e0", "revision": "326006ec2417cded71e1b536d71d9180b3460481"}
only full committers or CL owner with tryjob access are allowed to trigger CQ
1 comment:
That's correct. But it does for debug binaries (which will slow down compiles, bots, etc). […]
Well, I restored the text message passed to DCHECK stream. Please have a look at new version.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
CQ is trying the patch.
Note: The patchset sent to CQ was uploaded after this CL was approved.
"[clang-tidy] Fix access via null pointer to objects" https://chromium-review.googlesource.com/c/955852/6
Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/chromium-review.googlesource.com/955852/6
Bot data: {"action": "start", "triggered_at": "2018-03-14T10:56:32.0Z", "cq_cfg_revision": "b6c5f044c073ae207081077d3fd1ff808549a7e0", "revision": "326006ec2417cded71e1b536d71d9180b3460481"}
Patch set 6:Commit-Queue +2
CQ is trying the patch.
Note: The patchset sent to CQ was uploaded after this CL was approved.
"[clang-tidy] Fix access via null pointer to objects" https://chromium-review.googlesource.com/c/955852/6
Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/chromium-review.googlesource.com/955852/6
Bot data: {"action": "start", "triggered_at": "2018-03-14T15:06:01.0Z", "cq_cfg_revision": "b6c5f044c073ae207081077d3fd1ff808549a7e0", "revision": "326006ec2417cded71e1b536d71d9180b3460481"}
Try jobs failed on following builders:
chromium_presubmit on luci.chromium.try (JOB_FAILED, https://ci.chromium.org/p/chromium/builders/luci.chromium.try/chromium_presubmit/57593)
Patch Set 6: Commit-Queue+2
No LGTM from owners of some files yet ((
Zinovy Nis would like Jochen Eisinger to review this change.
[clang-tidy] Fix access via null pointer to objects
Found with clang-tidy [clang-analyzer-core.CallAndMessage].
Fixed few cases with an incorrect access pattern:
if (ptr && ptr->HasSomeFeature())
return;
ptr->... // ptr here can be null!
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I004c92a6335c9d9c0c7fa14b7e8e83279cb431e6
---
M base/metrics/field_trial.cc
M chrome/browser/extensions/api/tabs/tabs_api.cc
M chrome/browser/search/search.cc
M chrome/browser/ui/browser_commands.cc
M content/browser/renderer_host/render_widget_host_impl.cc
M extensions/browser/api/web_request/web_request_api.cc
M net/quic/chromium/quic_stream_factory.cc
M third_party/WebKit/Source/core/dom/Document.cpp
M third_party/WebKit/Source/core/editing/EditingStyle.cpp
M third_party/WebKit/Source/core/page/PageWidgetDelegate.cpp
M third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp
M third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp
M ui/compositor/layer_animation_element.cc
M ui/views/widget/widget.cc
14 files changed, 37 insertions(+), 31 deletions(-)
Fixed a typo
which files do you want me to look at?
1 comment:
File net/quic/chromium/quic_stream_factory.cc:
Minor nit, prefer to change
if (session_) {
}
to
if (!session_)
return OK;
to avoid indentation.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Patch Set 7:
which files do you want me to look at?
chrome/* please. And all other if possible - changes are trivial and tiny. Thanks in advance.
Patch Set 7:
Patch Set 7:
which files do you want me to look at?
chrome/* please. And all other if possible - changes are trivial and tiny. Thanks in advance.
Sorry. I meant third_party/*, not chrome/*
1 comment:
Minor nit, prefer to change […]
Done
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Patch set 8:Code-Review +1
Patch set 8:Commit-Queue +2
2 comments:
File chrome/browser/search/search.cc:
Patch Set #8, Line 382: DCHECK(profile);
why is that safe? why not if (browser_context) return false at the beginning of this method?
File chrome/browser/ui/browser_commands.cc:
Patch Set #8, Line 876: DCHECK(current_tab);
same here, why not early return?
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
2 comments:
Patch Set #8, Line 382: DCHECK(profile);
why is that safe? why not if (browser_context) return false at the beginning of this method?
Sounds reasonable. thanks!
File chrome/browser/ui/browser_commands.cc:
Patch Set #8, Line 876: DCHECK(current_tab);
same here, why not early return?
IMO current_tab should not be NULL in commands handlers.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
1 comment:
Patch Set #8, Line 876: DCHECK(current_tab);
IMO current_tab should not be NULL in commands handlers.
Done
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
2 comments:
Patch Set #8, Line 382: DCHECK(profile);
Sounds reasonable. […]
I asked for there to be no null check in this function. I think the DCHECK is correct.
File chrome/browser/ui/browser_commands.cc:
Patch Set #8, Line 876: DCHECK(current_tab);
Done
Similarly, I asked for this.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
3 comments:
File chrome/browser/search/search.cc:
Patch Set #1, Line 382: DCHECK(profile);
I think |profile| cannot be null here, so I'd remove this check.
Done
File chrome/browser/search/search.cc:
Patch Set #8, Line 382: DCHECK(profile);
I asked for there to be no null check in this function. I think the DCHECK is correct.
Done
File chrome/browser/ui/browser_commands.cc:
Patch Set #8, Line 876: DCHECK(current_tab);
Similarly, I asked for this.
Done
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Patch set 9:Commit-Queue +2
CQ is trying the patch.
Note: The patchset sent to CQ was uploaded after this CL was approved.
"Rebase" https://chromium-review.googlesource.com/c/955852/9
Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/chromium-review.googlesource.com/955852/9
Bot data: {"action": "start", "triggered_at": "2018-03-19T18:22:52.0Z", "cq_cfg_revision": "b6c5f044c073ae207081077d3fd1ff808549a7e0", "revision": "7da43d56804ff1f4b83a9f8dbdad29d23441ba4e"}
Try jobs failed on following builders:
chromium_presubmit on luci.chromium.try (JOB_FAILED, https://ci.chromium.org/p/chromium/builders/luci.chromium.try/chromium_presubmit/61271)
6 comments:
File base/metrics/field_trial.cc:
Patch Set #1, Line 1447: return;
Nit: Simpler: […]
Done
Patch Set #1, Line 1454: } else {
Nit: While here: change the first arg of this to |allocator| (since that's what it is)
Done
File chrome/browser/search/search.cc:
Patch Set #1, Line 382: DCHECK(profile);
Done
Done
File chrome/browser/ui/browser_commands.cc:
Patch Set #1, Line 876: DCHECK(current_tab);
Various other commands in this file assume an active web contents. […]
Done
File content/browser/renderer_host/render_widget_host_impl.cc:
Patch Set #1, Line 1712: RenderViewHostDelegateView* view = delegate_->GetDelegateView();
Functions like OnStartDragging() assume a delegate, so I think it's OK to remove this check.
Done
File third_party/WebKit/Source/core/dom/Document.cpp:
Patch Set #1, Line 2332: return;
Nit: Change to: […]
Done
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
Added owners for:
Missing LGTM from an OWNER for these files:
chrome/browser/extensions/api/tabs/tabs_api.cc
chrome/browser/search/search.cc
extensions/browser/api/web_request/web_request_api.cc
third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp
third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp
ui/compositor/layer_animation_element.cc
ui/views/widget/widget.cc
3 comments:
File third_party/WebKit/Source/core/dom/Document.cpp:
Presumably this code was there to work around a call stack that we couldn't reproduce.
Is there any reason to suspect that this is no longer the case?
File third_party/WebKit/Source/core/editing/EditingStyle.cpp:
Patch Set #9, Line 1490: if (style_from_matched_rules &&
It could be that style_from_matched_rules is guaranteed non-null at this point.
File third_party/WebKit/Source/core/page/PageWidgetDelegate.cpp:
Patch Set #9, Line 140: if (root && event.GetModifiers() & WebInputEvent::kIsTouchAccessibility &&
Ditto. I'm not in favor of adding more null checks just because.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
since Peter already reviewed the files in //chrome you asked me to look at, I guess you don't need me?
widget.cc lgtm - there's some repeated logic, but I don't see a neat way to combine it :/
Patch set 9:Code-Review +1
3 comments:
Presumably this code was there to work around a call stack that we couldn't reproduce. […]
Peter Kasting suggested to change "if" to DCHECK. Do you think it worth to fall back to "if" instead?
File third_party/WebKit/Source/core/editing/EditingStyle.cpp:
Patch Set #9, Line 1490: if (style_from_matched_rules &&
It could be that style_from_matched_rules is guaranteed non-null at this point.
But 30 lines above there's a check
if (style_from_matched_rules && !style_from_matched_rules->IsEmpty()) {
File third_party/WebKit/Source/core/page/PageWidgetDelegate.cpp:
Patch Set #9, Line 140: if (root && event.GetModifiers() & WebInputEvent::kIsTouchAccessibility &&
Ditto. I'm not in favor of adding more null checks just because.
But why? root can be null here - see
127 if (root) {
128 Document* document = root->GetDocument();
129 DCHECK(document);
and later
168 case WebInputEvent::kMouseMove:
169 if (!root || !root->View())
170 return WebInputEventResult::kHandledSuppressed;
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
1 comment:
Peter Kasting suggested to change "if" to DCHECK. […]
Well, you are right. DCHECK make test fail:
[ RUN ] WebViewTests/WebViewTest.SelectShowHide/1
...
[5044:2616:0319/115747.993:FATAL:Document.cpp(2343)] Check failed: frame_view.
Backtrace:
base::debug::StackTrace::StackTrace [0x03AF3560+32]
base::debug::StackTrace::StackTrace [0x03ABAA9D+13]
logging::LogMessage::~LogMessage [0x03A61653+83]
blink::Document::UpdateStyleAndLayout [0x05FABACE+164]
blink::Document::UpdateStyleAndLayoutIgnorePendingStylesheets [0x05FABA06+22]
1 comment:
Well, you are right. DCHECK make test fail: […]
I was attempting a non-functional change and mis-rewrote the code. The proposal should presumably have been:
// |frame_view| can be null when <describe how>.
DCHECK(!frame_view || !frame_view->IsInPerformLayout())
<< "View layout should not be re-entrant";
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
1 comment:
I was attempting a non-functional change and mis-rewrote the code. […]
In your code if |frame_view| is nullptr, then DCHECK is satisfied while "if (frame_view->NeedsLayout())" acceesses via nullptr.
Please explain what you'd like reviewers to review when you add them, there's 11 people reviewing this CL right now.
1 comment:
In your code if |frame_view| is nullptr, then DCHECK is satisfied while "if (frame_view->NeedsLayout […]
That's not different from today. Today when |frame_view| is null, the conditional here won't be taken, so we will neither NOTREACHED nor early-return. Your test stack proves we can get a null frame_view here. Therefore it must be true that when |frame_view| is null, IsActive() is also false, and we return before the frame_view->NeedsLayout() conditional.
The point of rewriting the existing code here as the DCHECK I did is to bring it into compliance with the style guide, which bans handling DCHECK failure. "if (x) { NOTREACHED(); ...do anything }" is a form of handling assertion failure, so I'm trying to avoid that. The resulting DCHECK is also more immediately obvious (to me) about saying that a null |frame_view| is possible; the comment should be even more so.
+rdevlin.cronin, since this impacts core extensions APIs (rather than platform apps APIs)
Also, splitting this into smaller cls would have been a good idea.
1 comment:
File extensions/browser/api/web_request/web_request_api.cc:
Patch Set #11, Line 2097: extension
I think !web_view_instance_id might imply that |extension| is not null, so DCHECK(extension) would be a better option here.
To view, visit change 955852. To unsubscribe, or for help writing mail filters, visit settings.
2 comments:
File chrome/browser/extensions/api/tabs/tabs_api.cc:
Patch Set #11, Line 628: bool set_self_as_opener = create_data &&
|urls| is populated only if |create_data| is non-null, so this is unnecessary.
File extensions/browser/api/web_request/web_request_api.cc:
Patch Set #11, Line 2097: extension
I think !web_view_instance_id might imply that |extension| is not null, so DCHECK(extension) would b […]
agreed, please make this a DCHECK()
I'm confused how you're going about this change. It seems you're continually adding more files and more reviewers after receiving L-G-T-M's.
That doesn't seem to be the right way to go about this. I think once you have a CL fully reviewed and approved, you should land it and if you want to make further changes, do so in separate CLs.
Patch Set 11:
I'm confused how you're going about this change. It seems you're continually adding more files and more reviewers after receiving L-G-T-M's.
That doesn't seem to be the right way to go about this. I think once you have a CL fully reviewed and approved, you should land it and if you want to make further changes, do so in separate CLs.
Sorry. But I got an error from the building system that some changes are not reviewed by their owners.
Can you please advice me a better way?
Patch Set 11:
Patch Set 11:
I'm confused how you're going about this change. It seems you're continually adding more files and more reviewers after receiving L-G-T-M's.
That doesn't seem to be the right way to go about this. I think once you have a CL fully reviewed and approved, you should land it and if you want to make further changes, do so in separate CLs.
Sorry. But I got an error from the building system that some changes are not reviewed by their owners.
Can you please advice me a better way?
I think this was mostly about the delta between patch set 2 and 3, where it looked like we went from a state of "mostly reviewed" to "lots more files".
It's correct to add reviewers for files you need OWNERS permission for.
But my comment is around the fact that in patchset 1, which Peter and I reviewed, you had 5 files changed. Now you have 14 files changed.
I think you should split off the new files to a new CL (or multiple) and keep this CL limited to the original 5 files.
Patch Set 11:
It's correct to add reviewers for files you need OWNERS permission for.
But my comment is around the fact that in patchset 1, which Peter and I reviewed, you had 5 files changed. Now you have 14 files changed.
I think you should split off the new files to a new CL (or multiple) and keep this CL limited to the original 5 files.
OK, thanks. Yes, it was my fault to add new files here, but the changes were so trivial that I did want to make a lot of tiny CLs.
Patch Set 11:
Patch Set 11:
It's correct to add reviewers for files you need OWNERS permission for.
But my comment is around the fact that in patchset 1, which Peter and I reviewed, you had 5 files changed. Now you have 14 files changed.
I think you should split off the new files to a new CL (or multiple) and keep this CL limited to the original 5 files.
OK, thanks. Yes, it was my fault to add new files here, but the changes were so trivial that I did want to make a lot of tiny CLs.
So, I'll fall back this CL to original 5 files.
The CL was reduced to original 5 files.
The remaining files will be uploaded as separate CLs a bit later with all the remarks considered.
Thanks you all for the feedback!
Chris, please review search.cc from this CL. Thanks.
1 comment:
That's not different from today. […]
Done
LGTM
(proper LGTM from committer account)
Patch set 12:Code-Review +1
Patch set 12:Commit-Queue +2
only full committers or CL owner with tryjob access are allowed to trigger CQ
Commit Bot merged this change.
[clang-tidy] Fix access via null pointer to objects
Found with clang-tidy [clang-analyzer-core.CallAndMessage].
Fixed few cases with an incorrect access pattern:
if (ptr && ptr->HasSomeFeature())
return;
ptr->... // ptr here can be null!
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I004c92a6335c9d9c0c7fa14b7e8e83279cb431e6
Reviewed-on: https://chromium-review.googlesource.com/955852
Reviewed-by: Chris Pickel <sfi...@chromium.org>
Reviewed-by: Trent Apted <tap...@chromium.org>
Reviewed-by: Buck Krasic <ckr...@chromium.org>
Reviewed-by: Alexei Svitkine <asvi...@chromium.org>
Reviewed-by: Peter Kasting <pkas...@chromium.org>
Commit-Queue: Peter Kasting <pkas...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545199}
---
M base/metrics/field_trial.cc
M chrome/browser/search/search.cc
M chrome/browser/ui/browser_commands.cc
M content/browser/renderer_host/render_widget_host_impl.cc
M third_party/WebKit/Source/core/dom/Document.cpp
5 files changed, 13 insertions(+), 15 deletions(-)
This change is ready for review.
To view, visit change 979438. To unsubscribe, or for help writing mail filters, visit settings.
Zinovy Nis would like Justin Novosad to review this change.
[clang-tidy] Fix access via null pointer to objects
Found with clang-tidy [clang-analyzer-core.CallAndMessage].
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I90792d9d1d39bd5d029dfb50df34d7af45d317e8
---
M third_party/WebKit/Source/core/editing/EditingStyle.cpp
M third_party/WebKit/Source/core/page/PageWidgetDelegate.cpp
M third_party/WebKit/Source/platform/feature_policy/FeaturePolicy.cpp
M third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp
4 files changed, 6 insertions(+), 4 deletions(-)
Gentle ping)
Gentle ping)
I'd actually change this the other way round. Since we have the unprotected calls without known problems, I'd remove the null checks further up instead.
Patch Set 6:
I'd actually change this the other way round. Since we have the unprotected calls without known problems, I'd remove the null checks further up instead.
Maybe replace them with DCHECKs?
If you want – but an unqualified method call on a pointer is almost the same as a DCHECK even in release builds (exception: methods that could be marked static but aren't), so personally I would just delete the check.