https://bugs.llvm.org/show_bug.cgi?id=43735

            Bug ID: 43735
           Summary: Objective-C block retains and never releases captured
                    parameter under ARC
           Product: clang
           Version: 9.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected], [email protected],
                    [email protected], [email protected]

Created attachment 22692
  --> https://bugs.llvm.org/attachment.cgi?id=22692&action=edit
compile foo.m with -fobjc-arc and see foo.s

In this method, when compiling with -fobjc-arc, the block captures
'someParameter' and clang issues a retain call with no matching release, and
there are no warnings or errors. The compiled code will always cause
'someParameter' to leak, and this kind of memory leak is easy to introduce and
can be very difficult to track down in a large project.

- (void)foo:(Foo*)someParameter {
    [Bar bar:^{
        [someParameter foo2];
    }];
}

The behavior that we were expecting was that when the block is released, that
the block's deallocator would release all captured variables.

If the current behavior is by design or is too difficult to improve, then the
next most desirable result would be that a compile error would be issued,
saying that 'someParameter' can't be used in a block and that either a weak
referencing variable needs to be used instead or the code needs to be compiled
without -fobjc-arc.

clang.exe -dumpversion reports 4.2.1
I tried out Clang 9.0.0 and looked at the generated .s file (using -save-temps)
and it appears that it would have the same problem, as there is only one call
to 'retain' and no calls to 'release'. In production, where we found the
problem, we use Clang 4.2.1.

Here are all the compiler options we use. Please see the generated foo.s.

clang.exe -c --target=i686-pc-windows-msvc -fasm-blocks -fblocks
-fobjc-runtime=ios-6.0.0 -fdiagnostics-format=msvc -fms-extensions
-fms-compatibility -fno-delayed-template-parsing -fexceptions -frtti
-fno-strict-aliasing -fno-omit-frame-pointer -fstack-protector -fno-short-enums
-g -gcodeview  -O0 -fno-inline -D MSVC_LINK -D WIN32 -D _WIN32 -D _CONSOLE
-DMICROSOFT_WINDOWS_WINBASE_H_DEFINE_INTERLOCKED_CPLUSPLUS_OVERLOADS=1
-DFIXME_ASSERTS=0 -DAPPORTABLE=1 -D__APPORTABLE__ -DNO_WRAPS=1
-D_ALLOW_KEYWORD_MACROS -DNOMINMAX -U_DLL -D_MT=1 -Wshorten-64-to-32
-Wno-deprecated-declarations -Wswitch -Wparentheses -Wformat -Wunused-value
-Wunused-variable -Wincompatible-pointer-types -Wno-unknown-pragmas
-Werror=implicit-function-declaration -Wno-unused-local-typedef      
-Wno-newline-eof -Werror-return-type -Wno-newline-eof -Wno-c++11-narrowing
-Wempty-body -Wno-ignored-pragma-intrinsic -Wno-ignored-attributes
-Wno-nonportable-include-path -Wno-pragma-pack -Wno-microsoft-anon-tag
-Wno-missing-prototype-for-cc -Wno-unused-value -g -fobjc-arc -save-temps -o
foo.m.obj -c foo.m

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to