[BUG] False positive vptr errors with shared ubsan runtimes(which is the default)

[CoolCaicaixian]

Description

Env Info:

【Compile Sdk Version】33
【NDK Version】R21e
【JDK】Java 8

Error Info:

2024-08-29 09:55:10.324 18568-18568 app_process64           com.cwx.inanna_android             I  /Users/cwx/work/codes/gitCodes/inanna/inanna-framework/demos/android/inanna-android/app/src/main/cpp/native-lib.cpp:42:22: runtime error: member call on address 0x0041793d7bf0 which does not point to an object of type 'Base'
2024-08-29 09:55:10.324 18568-18568 app_process64           com.cwx.inanna_android             I  0x0041793d7bf0: note: object is of type 'Derived'
2024-08-29 09:55:10.324 18568-18568 app_process64           com.cwx.inanna_android             I   00 00 00 00  f0 95 db 13 71 00 00 00  00 00 00 00 be be be be  02 11 00 00 10 00 00 00  5b 27 00 00
2024-08-29 09:55:10.324 18568-18568 app_process64           com.cwx.inanna_android             I                ^~~~~~~~~~~~~~~~~~~~~~~
2024-08-29 09:55:10.324 18568-18568 app_process64           com.cwx.inanna_android             I                vptr for 'Derived'

C++ Code：

// Base.h
class Base {
public:
    virtual ~Base();
    virtual int foo();  
    int bar();         
};

// Base.cpp
Base::~Base()
{
}
int Base::foo()
{
    return 1;
}
int Base::bar() {
    return 2;
}

// Derived.h
class Derived : public Base {
public:
    int foo() override; 
};

// Derived.cpp
int Derived::foo() {
    return bar() + Base::foo();
}

int init() {
    Base *pBase = new Derived();
    int ret = pBase->foo();
    delete pBase;
    return ret;
}

### cmake options:

target_compile_options(inanna_android PUBLIC -fsanitize=address -fno-omit-frame-pointer)
target_link_options(inanna_android PUBLIC -fsanitize=address)
target_compile_options(inanna_android PUBLIC -fsanitize=undefined -fno-sanitize-recover=undefined)
target_link_options(inanna_android PUBLIC -fsanitize=undefined -fno-sanitize-recover=undefined)

described:

When I turned on one of the options separately, it worked well.Or if I turn off the vptr check, it can work well,but when i both open ASAN and UBASAN,the error coming...

Affected versions

Canary

Canary version

NDKr21e

Host OS

Mac

Host OS version

14.2.1

Affected ABIs

arm64-v8a

Build system

CMake

Other build system

No response

minSdkVersion

24

Device API level

No response

[appujee]

vptr check is part of ubsan, not sure why enabling ubsan doesn't trigger it. You might want to open a bug in llvm-project/issues for clarification

[CoolCaicaixian]

vptr check is part of ubsan, not sure why enabling ubsan doesn't trigger it. You might want to open a bug in llvm-project/issues for clarification

but asan*.so is in NDK

[CoolCaicaixian]

vptr check is part of ubsan, not sure why enabling ubsan doesn't trigger it. You might want to open a bug in llvm-project/issues for clarification

can i make vpt check no crash in android by use wrap.sh?

[DanAlbert]

NDKr21e

That NDK is three and a half years old (and is based on an LLVM that's nearly five). There's a pretty good chance that the bug has been fixed since then. Have a look at https://github.com/android/ndk-samples/tree/main/sanitizers for the recommended way to use ubsan in apps. Note that ASan isn't supported any more, since HWASan is better in almost every way: http://go/android-dev/ndk/guides/memory-debug

If you update to NDK r27 and UBSan still isn't able to catch the bug without ASan, attach a complete test case and we can re-open. It may just be the case that UBSan isn't able to catch this bug in every case though. There are a number of UBSan checks that can't be caught 100% reliably, but idk if this is one of them.

[CoolCaicaixian]

恩德克尔21e

该 NDK 已有三年半历史（并且基于近五年的 LLVM）。从那时起，该错误很有可能已经得到修复。请查看https://github.com/android/ndk-samples/tree/main/sanitizers，了解在应用中使用 ubsan 的推荐方法。请注意，ASan 不再受支持，因为 HWASan 几乎在各个方面都更胜一筹：http://go/android-dev/ndk/guides/memory-debug

如果您更新到 NDK r27 并且 UBSan 仍然无法在没有 ASan 的情况下捕获错误，请附上完整的测试用例，我们可以重新打开。不过，UBSan 可能并不是在所有情况下都能捕获此错误。有许多 UBSan 检查无法 100% 可靠地捕获，但我不知道这是否是其中之一。

I tried to upgrade to NDK r27, but there was still a problem.😢
I'm sorry, there may be problems with my previous statement. This crash has nothing to do with whether to turn on ASan. The main problem is UBSan's vpr check.
If I turn on the compilation options below, a crash will occur：
-fsanitize=undefined -fno-sanitize-recover=undefined
But when I turned off the vpr check, everything was fine：
-fsanitize=undefined -fno-sanitize-recover=undefined -fno-sanitize=vptr

[CoolCaicaixian]

inanna-android.zip

[CoolCaicaixian]

inanna-android.zip

Here is my demo,thanks

[appujee]

If I turn on the compilation options below, a crash will occur：
-fsanitize=undefined -fno-sanitize-recover=undefined
But when I turned off the vpr check, everything was fine：
-fsanitize=undefined -fno-sanitize-recover=undefined -fno-sanitize=vptr

Isn't this is the intended behavior? this bug is specifically caught by vptr sanitizer.

[DanAlbert]

Yeah, that's what -fno-sanitize-recover does: UBSan failures will crash the program.

[CoolCaicaixian]

If I turn on the compilation options below, a crash will occur：
-fsanitize=undefined -fno-sanitize-recover=undefined
But when I turned off the vpr check, everything was fine：
-fsanitize=undefined -fno-sanitize-recover=undefined -fno-sanitize=vptr

Isn't this is the intended behavior? this bug is specifically caught by vptr sanitizer.

You can take a look at the C++ code I attached at the beginning. This is the most common use of C++ polymorphism and should not be detected as an error; and I work normally on other platforms

[CoolCaicaixian]

Yeah, that's what -fno-sanitize-recover does: UBSan failures will crash the program.

But my code should not be detected as errors

[appujee]

Are you using fvisibility flag somewhere? there is a similar bug reported in: https://bugs.llvm.org/show_bug.cgi?id=39191

[CoolCaicaixian]

Are you using fvisibility flag somewhere? there is a similar bug reported in: https://bugs.llvm.org/show_bug.cgi?id=39191

In fact, all my inheritances are in the same library, I didn't make calls across libraries, and I didn't proactively turn off visibility

[CoolCaicaixian]

Are you using fvisibility flag somewhere? there is a similar bug reported in: https://bugs.llvm.org/show_bug.cgi?id=39191

You can download the zip I sent earlier and check my compilation options

[appujee]

As the current behavior of vptr relates to open source implementation of this sanitizer, it is better to create an issue in the llvm-project/issues repo.

[CoolCaicaixian]

As the current behavior of vptr relates to open source implementation of this sanitizer, it is better to create an issue in the llvm-project/issues repo.

I have already asked a question on this page, but no one responded😢

[DanAlbert]

Link?

[CoolCaicaixian]

Link to what?

[DanAlbert]

Link to what?

The other bug you filed that you said has no response. We may be able to help with that.

[CoolCaicaixian]

Link to what?

The other bug you filed that you said has no response. We may be able to help with that.

here:llvm/llvm-project#106933
plz.

[pirama-arumuga-nainar]

Adding some folks from the sanitizer team: @eugenis @fmayer

I was able to reproduce this on Android with the following command (nb: also push libc++_shared.so.)

$ /usr/local/google/work/android-ndk-r27/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android35-clang++ san.cpp -fsanitize=undefined 

Adding -static-libsan to use the static libubsan library seems fine. This did not reproduce on Linux with both shared and static ubsan runtimes.