This is an archive of the discontinued LLVM Phabricator instance.

Fix crash in ObjC codegen introduced with 5ab6ee75994d645725264e757d67bbb1c96fb2b6
ClosedPublic

Authored by theraven on Apr 16 2022, 9:00 AM.

Details

Summary

5ab6ee75994d645725264e757d67bbb1c96fb2b6 assumed that if RValue::isScalar() returns true then RValue::getScalarVal will return a valid value. This is not the case when the return value is void and so void message returns would crash if they hit this path. This is triggered only for cases where the nil-handling path needs to do something non-trivial (destroy arguments that should be consumed by the callee).

Diff Detail

Event Timeline

theraven created this revision.Apr 16 2022, 9:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2022, 9:00 AM
theraven requested review of this revision.Apr 16 2022, 9:00 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 16 2022, 9:00 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

LGTM. Could you add a test case?

I'd like to. The test case from the original bug report was very large but I'm not sure how to trigger this with anything comprehensibly small. You need something where the callee is responsible for destroying the argument and I'm not sure what combination of properties / ABIs results in that. The original test was -(void)foo:(std::string)aString on the MSVC ABI, but I don't know how much of the Visual Studio std::string implementation is necessary to trigger this behaviour. Is it just a non-trivial destructor?

I'd like to. The test case from the original bug report was very large but I'm not sure how to trigger this with anything comprehensibly small. You need something where the callee is responsible for destroying the argument and I'm not sure what combination of properties / ABIs results in that. The original test was -(void)foo:(std::string)aString on the MSVC ABI, but I don't know how much of the Visual Studio std::string implementation is necessary to trigger this behaviour. Is it just a non-trivial destructor?

Yeah, a non-trivial destructor should be good enough. Or a consumed ObjC pointer argument in ARC might also work, although I don't know if that takes the same path.

triplef accepted this revision.Apr 26 2022, 1:53 AM

Thanks, LGTM!

I tested these changes with our app’s code base, which was triggering the bug in a couple of places, and it all builds fine with the patch.

This revision is now accepted and ready to land.Apr 26 2022, 1:53 AM
This revision was landed with ongoing or failed builds.Jul 24 2022, 6:02 AM
This revision was automatically updated to reflect the committed changes.