This is an archive of the discontinued LLVM Phabricator instance.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan
ClosedPublic

Authored by fixathon on Jul 19 2022, 9:37 AM.

Details

Summary

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1094796 1095721 1095728 1095737 1095741
1095756 1095779 1095789 1095805 1214552
1229457 1232475 1274006 1274010 1293427
1364800 1364802 1364804 1364812 1364816
1374902 1374909 1384975 1399312 1420451
1431704 1454230 1454554 1454615 1454579
1454594 1454832 1457759 1458696 1461909
1467658 1487814 1487830 1487845

Diff Detail

Event Timeline

fixathon created this revision.Jul 19 2022, 9:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 19 2022, 9:37 AM
fixathon requested review of this revision.Jul 19 2022, 9:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 19 2022, 9:37 AM
fixathon retitled this revision from [LLDB][Reliability] Fix uninitialized variables from Coverity scan to [LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan.Jul 19 2022, 9:54 AM
jingham requested changes to this revision.Jul 19 2022, 10:04 AM
jingham added a subscriber: jingham.

Thanks for finding these uninitialized variables. That's a valuable exercise. Couple of comments;

Most of the time you set lldb::addr_t's to 0, they probably should have been set to LLDB_INVALID_ADDRESS. Also as I said above, any ivars of CommandObject subclasses actually get initialized before use by the OptionParsingStarting method, so the initialized values don't actually matter, but to avoid confusion if set they should be the same as the values given in that method. I found one that was different but didn't do an exhaustive check.

You are also inconsistent in setting int variables either to {} or 0. I think you set the ones you could tell were int's to 0 and the ones you couldn't tell off the bat to {}? But for all the ones that are typedef's to some kind of scalar, and explicit 0 (or LLDB_INVALID_ADDRESS in a bunch of places) would be easier to read.

lldb/source/Commands/CommandObjectTarget.cpp
4646

Because of the way CommandObjects work, the constructed values of its ivars are never used. You have to call OptionParsingStarting before doing any work with the object, so the values set in that function are the real ones. There's no actual point in initializing these variables, but it mostly doesn't hurt except if you set them to different values from the ones in OptionParsingStarting, in which case they could cause confusion in people reading the code. Here you've set m_thread_index to 0 but the correct starting value is actually UINT32_MAX as you can see from the OptionParsingStarting just above.

Can you go through all of the CommandObject subclass ivars that you've given values to and make sure they are the ones in the class's OptionParsingStarting? Thanks.

lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
140

Invalid addresses in lldb are indicated by the value LLDB_INVALID_ADDRESS. Not sure what {} does for an int value, but probably not that.

lldb/source/Plugins/Language/ObjC/NSSet.cpp
79

Again, this should be LLDB_INVALID_ADDRESS

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.h
163 ↗(On Diff #445854)

The other ones here are also all intialized to LLDB_INVALID_ADDRESS in the constructor, so this one should be too. I also find it confusing to have some variables initialized in the class definition and some in the constructor definition. Since all the other ivars are initialized in the constructor in the .cpp file, it would be better to either switch all the ivars over to in-class initialization or to add the missing ones to the constructor. Either way is fine, but the mixed method seems confusing.

lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
274–275

These are all typedef to int types. Putting {} for the initializer seems overly mysterious. And the address should be LLDB_INVALID_ADDRESS anyway.

This revision now requires changes to proceed.Jul 19 2022, 10:04 AM
jingham added inline comments.Jul 19 2022, 10:06 AM
lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
140

Zero, which is in this case wrong.

clayborg requested changes to this revision.Jul 19 2022, 10:29 AM
clayborg added inline comments.
lldb/include/lldb/Core/EmulateInstruction.h
182

This doesn't fall into the un initialized variable case, I would revert this. You can always submit a new patch if you want to fix this.

lldb/source/Commands/CommandObjectTarget.cpp
4646

yeah, I would like to get everything initialized if we can to limit our static analysis warnings.

lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
412

set to nullptr instead of empty string? Check the code to see if they check this variable for NULL and use nullptr if they do.

lldb/source/Plugins/Language/ObjC/NSDictionary.cpp
140

yes, for lldb::addr_t the LLDB_INVALID_ADDRESS is the value we need to use

lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
1305–1306

There are more members than just "cmdsize" that should be initialized to zero. Hopefully adding "= {};" will init everything to zero and avoid us having to say "= {0,0};"

5424–5425
5491–5492

Ditto, and please apply to all other places where you only initialize "cmdsize" to zero. llvm::MachO::load_command only has two entries, but the other definitions below have more members.

lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
274–275

I would set any "lldb::offset_t" values to zero instead of {} for clarity

275

LLDB_INVALID_ADDRESS

lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
416–417

Looking at the header file, we define our own copy of these types, so we should add a bunch of "= 0;" to each member just like coff_opt_header_t does.

Then we can remove this memset stuff.

416–417
425–426

Remove these memsets after we fix the constructors for all types we define in the ObjectFilePECOFF.h header file.

425–426
fixathon updated this revision to Diff 445937.Jul 19 2022, 2:04 PM

Update code based on revew comments

clayborg requested changes to this revision.Jul 19 2022, 2:14 PM

You missed a few comments. It would also be nice to remove the memset from the ObjectFilePECOFF by adding "= 0;" to all of the struct definitions in ObjectFilePECOFF.h that would be great as well.

lldb/include/lldb/Core/EmulateInstruction.h
182

I would revert this change as it isn't related to uninitialized vars.

lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
416–417

m_image_base should be set to LLDB_INVALID_ADDRESS, I had a suggested code edit, but not sure if you saw it above.

425–426

m_image_base should be set to LLDB_INVALID_ADDRESS, I had a suggested code edit, but not sure if you saw it above.

This revision now requires changes to proceed.Jul 19 2022, 2:14 PM
fixathon updated this revision to Diff 445943.Jul 19 2022, 2:15 PM
fixathon marked 13 inline comments as done.

Update the init value in ObjectFilePECOFF.cpp

Adding review comments

lldb/include/lldb/Core/EmulateInstruction.h
182

This is fixing Coverity scan warning 1094796 "Uninitialized scalar field".
"Non-static class member InfoType is not initialized in this constructor nor in any functions that it calls"

lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
412

An empty string literal is a reasonable and safe init value for what is semantically a string (C-string). The warning related to this fix is triggered by line 403:
Written += From.size();
I am not sure that nullptr += (llvm::StringRef type) will pay nice, but I am not opposed to changing it to nullptr if you feel strongly about it.

clayborg added inline comments.Jul 19 2022, 2:21 PM
lldb/include/lldb/Core/EmulateInstruction.h
182

Gotcha, ok to leave this in then!

jingham added inline comments.Jul 19 2022, 2:34 PM
lldb/source/Commands/CommandObjectTarget.cpp
4646

If we just called OptionParsingStarting in the constructor would your static analysis tools be smart enough to see that they were initialized? That's the initialization that actually matters so it would be better not to have to write the values in two places (one of which looks like it matters but actually doesn't...)

lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
284

If you use

llvm-project/clang/tools/clang-format/git-clang-format

to clang-format your changes, then it will only apply to your diff, and you won't pick up spurious changes like this that make diffs harder to read.

fixathon marked 6 inline comments as done.Jul 19 2022, 3:01 PM

Respond to comments

lldb/source/Commands/CommandObjectTarget.cpp
4646

I believe so. Would you like to make that change then?

lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
284

Thank you for that. Should I attempt to undo the spurious changes for this commit or just keep it in mind for the future?

fixathon updated this revision to Diff 445966.Jul 19 2022, 3:44 PM

Addressing comments

Updating D130098: [LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan # # Enter a

brief description of the changes included in this update. # The first line is used as subject, next lines
as comment. # # If you intended to create a new revision, use: # $ arc diff --create

fixathon marked 3 inline comments as done.Jul 19 2022, 3:49 PM

Replied to comments

lldb/source/Commands/CommandObjectTarget.cpp
4646

On a second thought, OptionParsingStarting() is a virtual function override. Calling virtual functions from constructor is bad practice.

Looks good to me. Jim, anything you still want fixed?

JDevlieghere accepted this revision.Jul 20 2022, 9:35 AM

The changes themselves look good, but please undo the formatting/unrelated changes before landing this. When I've been in a situation like this where I accidentally formatted unrelated things, I usually unstage my changes and use git add -p to interactively pick the chunks I want to stage.

There's a script called git-clang-format that allows you to format only the lines that have been changed: https://clang.llvm.org/docs/ClangFormat.html#git-integration. Once you've added it to your PATH, you can run git clang-format after staging your changes (but before committing).

lldb/source/Commands/CommandObjectTarget.cpp
4640

LLDB_INVALID_LINE_NUMBER

fixathon updated this revision to Diff 446262.Jul 20 2022, 2:13 PM

Remove formatting for unrelated lines

fixathon marked 3 inline comments as done.Jul 20 2022, 2:16 PM

Address the comments: revert the formatting for lines unrelated to my changes

clayborg accepted this revision.Jul 20 2022, 2:38 PM
This revision was not accepted when it landed; it landed in state Needs Review.Jul 20 2022, 2:51 PM
This revision was automatically updated to reflect the committed changes.