Crash in CallExpr::getCallReturnType

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Crash in CallExpr::getCallReturnType

Deep Majumder via cfe-dev
Hi!
I encountered a case when function CallExpr::getCallReturnType is called and crashes because a null type pointer. Should this function return a value in any case and not crash?

 #0 0x00007f8cbb81baef llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:564:0
 #1 0x00007f8cbb81bb82 PrintStackTraceSignalHandler(void*) llvm/lib/Support/Unix/Signals.inc:625:0
 #2 0x00007f8cbb81991d llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:68:0
 #3 0x00007f8cbb81b32e llvm::sys::CleanupOnSignal(unsigned long) llvm/lib/Support/Unix/Signals.inc:361:0
 #4 0x00007f8cbb69074a (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) llvm/lib/Support/CrashRecoveryContext.cpp:77:0
 #5 0x00007f8cbb690c22 CrashRecoverySignalHandler(int) llvm/lib/Support/CrashRecoveryContext.cpp:383:0
 #6 0x00007f8cbacce040 (/lib/x86_64-linux-gnu/libc.so.6+0x3f040)
 #7 0x00007f8cbaccdfb7 raise /build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
 #8 0x00007f8cbaccf921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
 #9 0x00007f8cbacbf48a __assert_fail_base /build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
#10 0x00007f8cbacbf502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#11 0x00007f8cc4e8fdd2 clang::FunctionType const* clang::Type::castAs<clang::FunctionType>() const clang/include/clang/AST/Type.h:7060:0
#12 0x00007f8cb533b3e9 clang::CallExpr::getCallReturnType(clang::ASTContext const&) const clang/lib/AST/Expr.cpp:1453:0

The following AST node (CallExpr, for function "to_string") causes the problem:
              `-CompoundStmt <col:81, line:9:3>
                `-CallExpr <line:8:5, col:27> '<dependent type>'
                  |-UnresolvedLookupExpr <col:5, col:10> '<overloaded function type>' lvalue (no ADL) = 'to_string' 0x562191753998 0x562191755ac8 0x562191756418 0x562191756d68 0x5621917576b8 0x562191758008 0x5621917599a8 0x56219175c928 0x56219175f888
                  `-DeclRefExpr <col:20> 'const auto' lvalue ParmVar 0x56219197d868 'element' 'const auto &'

This is the source code:

#include <algorithm>
#include <string>
#include <vector>

void f() {
  const std::vector<unsigned char> buffer;
  std::for_each(std::cbegin(buffer), std::cend(buffer), [](const auto& element) {
    std::to_string(element);
  });
}

---
Balázs

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Crash in CallExpr::getCallReturnType

Deep Majumder via cfe-dev
Hi Balázs,

I think it is normal to give a Null type in this case:
The CallExpr refers to an overloaded function and that is not resolved yet, because the overload resolution has not happened yet at this point.

However, this could happen only if the enclosing class template (the generic lambda) is not yet instantiated. But I'd expect that the lambda class template is instantiated since for_each is instantiated with a concrete type (the iterator of std::vector<unsigned char>). Could you please check if the lambda class template is instantiated?

Gabor

On Wed, Jan 20, 2021 at 4:43 PM Balázs Kéri via cfe-dev <[hidden email]> wrote:
Hi!
I encountered a case when function CallExpr::getCallReturnType is called and crashes because a null type pointer. Should this function return a value in any case and not crash?

 #0 0x00007f8cbb81baef llvm::sys::PrintStackTrace(llvm::raw_ostream&) llvm/lib/Support/Unix/Signals.inc:564:0
 #1 0x00007f8cbb81bb82 PrintStackTraceSignalHandler(void*) llvm/lib/Support/Unix/Signals.inc:625:0
 #2 0x00007f8cbb81991d llvm::sys::RunSignalHandlers() llvm/lib/Support/Signals.cpp:68:0
 #3 0x00007f8cbb81b32e llvm::sys::CleanupOnSignal(unsigned long) llvm/lib/Support/Unix/Signals.inc:361:0
 #4 0x00007f8cbb69074a (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) llvm/lib/Support/CrashRecoveryContext.cpp:77:0
 #5 0x00007f8cbb690c22 CrashRecoverySignalHandler(int) llvm/lib/Support/CrashRecoveryContext.cpp:383:0
 #6 0x00007f8cbacce040 (/lib/x86_64-linux-gnu/libc.so.6+0x3f040)
 #7 0x00007f8cbaccdfb7 raise /build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
 #8 0x00007f8cbaccf921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
 #9 0x00007f8cbacbf48a __assert_fail_base /build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
#10 0x00007f8cbacbf502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#11 0x00007f8cc4e8fdd2 clang::FunctionType const* clang::Type::castAs<clang::FunctionType>() const clang/include/clang/AST/Type.h:7060:0
#12 0x00007f8cb533b3e9 clang::CallExpr::getCallReturnType(clang::ASTContext const&) const clang/lib/AST/Expr.cpp:1453:0

The following AST node (CallExpr, for function "to_string") causes the problem:
              `-CompoundStmt <col:81, line:9:3>
                `-CallExpr <line:8:5, col:27> '<dependent type>'
                  |-UnresolvedLookupExpr <col:5, col:10> '<overloaded function type>' lvalue (no ADL) = 'to_string' 0x562191753998 0x562191755ac8 0x562191756418 0x562191756d68 0x5621917576b8 0x562191758008 0x5621917599a8 0x56219175c928 0x56219175f888
                  `-DeclRefExpr <col:20> 'const auto' lvalue ParmVar 0x56219197d868 'element' 'const auto &'

This is the source code:

#include <algorithm>
#include <string>
#include <vector>

void f() {
  const std::vector<unsigned char> buffer;
  std::for_each(std::cbegin(buffer), std::cend(buffer), [](const auto& element) {
    std::to_string(element);
  });
}

---
Balázs
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev