thr3ads.net - llvm dev - [llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM [Apr 2020]

If this information is useful, please help other people find it:
Share via:

Shishir V Jessu via llvm-dev

2020-Apr-30 16:51 UTC

[llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

Hello,

I am editing the LowerTypeTests pass in LLVM, and part of my additions
include the following 3 lines of code:

// newTypeName is a std::string
MDString* newMD = MDString::get(M.getContext(), newTypeName);
ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD};
auto* node = MDTuple::get(M.getContext(), mdArray);

Thus far, I have been developing on a version of Clang with debugging
symbols enabled, and this code has worked. However, on the Release+Asserts
version, the third line results in a segmentation fault. The backtrace for
the error, up to the method I'm working on, is as follows:

// signal handling...
 #4 0x00005556e48d6120
llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&)
(/home/sjessu/build-no-debug/bin/clang-10+0x2787120)
 #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*,
llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*,
llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/clang-10+0x278c8c2)
 #6 0x00005556e48dbc12 llvm::MDNode::MDNode(llvm::LLVMContext&, unsigned
int, llvm::Metadata::StorageType, llvm::ArrayRef<llvm::Metadata*>,
llvm::ArrayRef<llvm::Metadata*>)
(/home/sjessu/build-no-debug/bin/clang-10+0x278cc12)
 #7 0x00005556e48dd70d llvm::MDTuple::getImpl(llvm::LLVMContext&,
llvm::ArrayRef<llvm::Metadata*>, llvm::Metadata::StorageType, bool)
(/home/sjessu/build-no-debug/bin/clang-10+0x278e70d)
 #8 0x00005556e4a4b293 (anonymous namespace)::LowerTypeTestsModule::lower()
(.part.1843) (/home/sjessu/build-no-debug/bin/clang-10+0x28fc293)


Crucially, *this error does not occur in the Debug version*, so I am lost
as to how to diagnose it. I have checked that newMD is non-null and
contains the value I expect. Are there any discrepancies in the Debug
version as compared to the Release + Asserts version that would cause such
an error? Thanks for your help!

Best,
Shishir Jessu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200430/e40566db/attachment.html>

David Blaikie via llvm-dev

2020-Apr-30 16:55 UTC

head link

[llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

On Thu, Apr 30, 2020 at 9:51 AM Shishir V Jessu via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I am editing the LowerTypeTests pass in LLVM, and part of my additions
> include the following 3 lines of code:
>
> // newTypeName is a std::string
> MDString* newMD = MDString::get(M.getContext(), newTypeName);
> ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0), newMD};
> auto* node = MDTuple::get(M.getContext(), mdArray);
>
If I had to hazard a guess, it's that mdArray is left with dangling
pointers to an array (initializer list) that ceases to exist once the
';'
on line 2 is reached. So when the elements the ArrayRef references are
accessed, it gets crashy.

I'd say try writing it like:

auto *node = MDTuple::get(M.getContext(), {ConstantInt::get(Int64Ty, 0),
newMD});

Also try testing with ASan or MSan, perhaps?

>
> Thus far, I have been developing on a version of Clang with debugging
> symbols enabled, and this code has worked. However, on the Release+Asserts
> version, the third line results in a segmentation fault. The backtrace for
> the error, up to the method I'm working on, is as follows:
>
> // signal handling...
>  #4 0x00005556e48d6120
> llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&)
> (/home/sjessu/build-no-debug/bin/clang-10+0x2787120)
>  #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*,
> llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*,
> llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/clang-10+0x278c8c2)
>  #6 0x00005556e48dbc12 llvm::MDNode::MDNode(llvm::LLVMContext&,
unsigned
> int, llvm::Metadata::StorageType, llvm::ArrayRef<llvm::Metadata*>,
> llvm::ArrayRef<llvm::Metadata*>)
> (/home/sjessu/build-no-debug/bin/clang-10+0x278cc12)
>  #7 0x00005556e48dd70d llvm::MDTuple::getImpl(llvm::LLVMContext&,
> llvm::ArrayRef<llvm::Metadata*>, llvm::Metadata::StorageType, bool)
> (/home/sjessu/build-no-debug/bin/clang-10+0x278e70d)
>  #8 0x00005556e4a4b293 (anonymous
> namespace)::LowerTypeTestsModule::lower() (.part.1843)
> (/home/sjessu/build-no-debug/bin/clang-10+0x28fc293)
>
>
> Crucially, *this error does not occur in the Debug version*, so I am lost
> as to how to diagnose it. I have checked that newMD is non-null and
> contains the value I expect. Are there any discrepancies in the Debug
> version as compared to the Release + Asserts version that would cause such
> an error? Thanks for your help!
>
> Best,
> Shishir Jessu
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200430/58ad7eac/attachment.html>

Craig Topper via llvm-dev

2020-Apr-30 17:00 UTC

head link

[llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

I agree that the ArrayRef is likely the issue. I've debugged a crash caused
by a temporary ArrayRef like that a couple times.

Either do what David suggested or use a normal array:

Metadata *mdArray[] =  {ConstantInt::get(Int64Ty, 0), newMD};

~Craig


On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Thu, Apr 30, 2020 at 9:51 AM Shishir V Jessu via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello,
>>
>> I am editing the LowerTypeTests pass in LLVM, and part of my additions
>> include the following 3 lines of code:
>>
>> // newTypeName is a std::string
>> MDString* newMD = MDString::get(M.getContext(), newTypeName);
>> ArrayRef<Metadata*> mdArray {ConstantInt::get(Int64Ty, 0),
newMD};
>> auto* node = MDTuple::get(M.getContext(), mdArray);
>>
>
> If I had to hazard a guess, it's that mdArray is left with dangling
> pointers to an array (initializer list) that ceases to exist once the
';'
> on line 2 is reached. So when the elements the ArrayRef references are
> accessed, it gets crashy.
>
> I'd say try writing it like:
>
> auto *node = MDTuple::get(M.getContext(), {ConstantInt::get(Int64Ty, 0),
> newMD});
>
> Also try testing with ASan or MSan, perhaps?
>
>
>>
>> Thus far, I have been developing on a version of Clang with debugging
>> symbols enabled, and this code has worked. However, on the
Release+Asserts
>> version, the third line results in a segmentation fault. The backtrace
for
>> the error, up to the method I'm working on, is as follows:
>>
>> // signal handling...
>>  #4 0x00005556e48d6120
>> llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&)
>> (/home/sjessu/build-no-debug/bin/clang-10+0x2787120)
>>  #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*,
>> llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*,
>> llvm::Metadata*>)
(/home/sjessu/build-no-debug/bin/clang-10+0x278c8c2)
>>  #6 0x00005556e48dbc12 llvm::MDNode::MDNode(llvm::LLVMContext&,
unsigned
>> int, llvm::Metadata::StorageType,
llvm::ArrayRef<llvm::Metadata*>,
>> llvm::ArrayRef<llvm::Metadata*>)
>> (/home/sjessu/build-no-debug/bin/clang-10+0x278cc12)
>>  #7 0x00005556e48dd70d llvm::MDTuple::getImpl(llvm::LLVMContext&,
>> llvm::ArrayRef<llvm::Metadata*>, llvm::Metadata::StorageType,
bool)
>> (/home/sjessu/build-no-debug/bin/clang-10+0x278e70d)
>>  #8 0x00005556e4a4b293 (anonymous
>> namespace)::LowerTypeTestsModule::lower() (.part.1843)
>> (/home/sjessu/build-no-debug/bin/clang-10+0x28fc293)
>>
>>
>> Crucially, *this error does not occur in the Debug version*, so I am
>> lost as to how to diagnose it. I have checked that newMD is non-null
and
>> contains the value I expect. Are there any discrepancies in the Debug
>> version as compared to the Release + Asserts version that would cause
such
>> an error? Thanks for your help!
>>
>> Best,
>> Shishir Jessu
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200430/130f1bbf/attachment.html>

Reasonably Related Threads

Search for more maybe matching threads

llvm dev - Apr 2020 - Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

[llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

[llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

[llvm-dev] Discrepancy between Debug and Release+Asserts versions of Clang/LLVM

Reasonably Related Threads