Page MenuHomePhabricator

Add nullptr check in FindLibCppStdFunctionCallableInfo()
Needs ReviewPublic

Authored by shafik on Fri, May 10, 2:29 PM.

Details

Summary

We track down a crash in FindLibCppStdFunctionCallableInfo() to a missing nullptr check for the symbol variable.

Diff Detail

Event Timeline

shafik created this revision.Fri, May 10, 2:29 PM
shafik edited reviewers, added: aprantl; removed: aam.
friss added a comment.Fri, May 10, 4:24 PM

Do you have a testcase triggering this?

davide requested changes to this revision.EditedFri, May 10, 6:31 PM
davide added a subscriber: davide.

What's the scenario that's causing this? Adding a nullptr check is an obviously safe thing to do, but it would be excellent if we could add a comment explaining why the symbol could be nullptr.
I also do believe that the logic for checking whether the symbol is nullptr can be hoisted to the beginning of the function, see comment inline.

source/Target/CPPLanguageRuntime.cpp
219–220

This should probably be nullptr, anyway, my general comment is that this check is scattered all around the function and could be centralized in a single place.

264–277

Here in the if branch you check whether the symbol is nullptr or not, but later you dereference it unconditionally. Are you always guaranteed that you're not dereferencing nullptr ?

This revision now requires changes to proceed.Fri, May 10, 6:31 PM
aprantl added inline comments.Mon, May 13, 10:11 AM
source/Target/CPPLanguageRuntime.cpp
219–220

if (symbol && symbol->GetName() ....

265

this should probably be factored out into a bool variable.

shafik updated this revision to Diff 199649.Wed, May 15, 11:35 AM
shafik marked 4 inline comments as done.

Simplified the checking of symbol being a nullptr

@friss we have several bugs, once of which I can reproduce but I have not been able to reduce it to a minimal case yet and the nullptr check is obviously the right to do.