This is an archive of the discontinued LLVM Phabricator instance.

[clang][dataflow] Fix nullptr dereferencing error.
ClosedPublic

Authored by ymandel on Mar 7 2022, 1:45 PM.

Details

Summary

When pre-initializing fields in the environment, the code assumed that all
fields of a struct would be initialized. However, given limits on value
construction, that assumption is incorrect. This patch changes the code to drop
that assumption and thereby avoid dereferencing a nullptr.

Diff Detail

Event Timeline

ymandel created this revision.Mar 7 2022, 1:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2022, 1:45 PM
ymandel requested review of this revision.Mar 7 2022, 1:45 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 7 2022, 1:45 PM
xazax.hun accepted this revision.Mar 7 2022, 1:48 PM
This revision is now accepted and ready to land.Mar 7 2022, 1:48 PM

When pre-initializing fields in the environment, the code assumed that all fields of a struct would be initialized

Was this assumption ever correct given that it was already skipping the initialization of recursive cases?

Thanks for the review! That was impressively fast... :)

When pre-initializing fields in the environment, the code assumed that all fields of a struct would be initialized

Was this assumption ever correct given that it was already skipping the initialization of recursive cases?

Yeah, I had that thought of that and I'm pretty sure it wasn't. But that does provide a way to test this without creating a very large struct. Let me see if I can add a test to this patch. Otherwise, I'll write a followup.

ymandel updated this revision to Diff 413673.Mar 7 2022, 6:19 PM

Add test for recursive type case.

ymandel updated this revision to Diff 413674.Mar 7 2022, 6:21 PM

switch to c++11 for test.

When pre-initializing fields in the environment, the code assumed that all fields of a struct would be initialized

Was this assumption ever correct given that it was already skipping the initialization of recursive cases?

Yeah, I had that thought of that and I'm pretty sure it wasn't. But that does provide a way to test this without creating a very large struct. Let me see if I can add a test to this patch. Otherwise, I'll write a followup.

I added a test for the recursive case and tested (a variant of) it on the code before this patch to verify that it triggered a failure. Interestingly, it triggers a different failure mode in getChild -- the assertion that the field will be present. The guard on the recursive case prevents the field from being added at all, so you don't have a nullptr added to the map. But, you also don't have the field added, so the (old) assert would fail. The patch addresses this by allowing for lack of field presence.

xazax.hun accepted this revision.Mar 7 2022, 6:30 PM

Wonderful, thanks!

This revision was landed with ongoing or failed builds.Mar 7 2022, 7:09 PM
This revision was automatically updated to reflect the committed changes.