generated code cause SIGILL when mixing data types

[karimhasebou]

Just assigning integers to variables of floating point or doing arithmetic with mixed data types causes SIGILL.

Even if the variables are casted explicitly it will still crash. I am using gcc since clang produces code that crashes with SIGILL much earlier in code than gcc. In fact clang, crashes in empty constructor

[enh]

example? which target? (we're not going to be able to do anything with this bug without a reproduceable example.)

[karimhasebou]

@enh something as simple as this crashes. I am testing on android oreo emulator for x86_64
int integer = 50;
float x = integer;

[stephenhines]

How are you generating the shared objects? Are you targeting ARM instead of x86/x86_64 with your native code?

[karimhasebou]

@stephenhines Am using the cmake file to build a shared library. I don't think that its an issue of compiling for the wrong architecture since the code am working on actually executes a large significant amount of code before crashing. furthermore just restricting myself to one data-type seems to fix the issue. Also I have tried setting abiFilter to x86 exclusively to make sure that this wasn't the issue.

[karimhasebou]

Am not sure if this helpful or not but also trying float x =(float) atof(some_string) crashes with SIGILL two. so it seems that casting is not handled correctly.

[stephenhines]

I think enh's request for a reproducible example is what we will need to debug this further. Are you executing native code or managed code before crashing? It's possible that the other code is getting optimized away completely and this is still a build configuration issue (as I strongly suspect that it is). It could also be that the flags you are passing to the build are incorrect (like specifying an SSE level or other feature that isn't available).

[karimhasebou]

@stephenhines Unfortunately I do not have the authority to post the actual code am working on here. This is why i am describing things I have tried to narrow done the issue. The code I have written is simply one in the native-lib.cpp that android studio generates automatically it is being called through JNI. With regards to optimization, am not sure that I have any optimization enabled since am running in default settings in debug mode. Find it difficult to think that its simply a build issue since if it were just a wrong target it should have immediately crashes from the first line rather than successfully executing several functions.

[karimhasebou]

Any tips to making sure the built is setup correctly

[DanAlbert]

Can you at least share the cmake configuration command you're using?

[karimhasebou]

Below is the cmake and gradle build files i am using. In the cmakelist I include another library but the crash I experience occurs in the code I have written that doesn't make use of the library code.

CMAKE of android project

cmake_minimum_required(VERSION 3.5.1)
project(native-lib)

set(myrootpath "${PROJECT_SOURCE_DIR}/../../..")

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall -Werror")

include_directories(${myrootpath}/include)


set (SOURCES
    src/main/cpp/native-lib.cpp)
set(CMAKE_BUILD_TYPE Debug)
# Creates and names a library, sets it as either STATIC
# or SHARED, and provides the relative paths to its source code.
# You can define multiple libraries, and CMake builds them for you.
# Gradle automatically packages shared libraries with your APK.

add_library( # Sets the name of the library.
             native-lib
             # Sets the library as a shared library.
             SHARED
             # Provides a relative path to your source file(s).
             ${SOURCES} )

target_compile_definitions(native-lib PRIVATE -DVKS_PQA_EXPORTS)
include(${myrootpath}/common.cmake)

# Searches for a specified prebuilt library and stores the path as a
# variable. Because CMake includes system libraries in the search path by
# default, you only need to specify the name of the public NDK library
# you want to add. CMake verifies that the library exists before
# completing its build.

find_library( # Sets the name of the path variable.
              log-lib

              # Specifies the name of the NDK library that
              # you want CMake to locate.
              log )

set(vksPQAsrcPath ${myrootpath}/PQA/vksPQA)
add_subdirectory(${vksPQAsrcPath} ${PROJECT_BINARY_DIR}/vksPQA)

# Specifies libraries CMake should link to your target library. You
# can link multiple libraries, such as libraries you define in this
# build script, prebuilt third-party libraries, or system libraries.

target_link_libraries( # Specifies the target library.
                       native-lib
                       vksPQA
                       # Links the target library to the log library
                       # included in the NDK.
                       ${log-lib} )

Gradle build

apply plugin: 'com.android.application'

android {
    compileSdkVersion 26
    defaultConfig {
        applicationId ""
        minSdkVersion 24
        targetSdkVersion 26
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
        externalNativeBuild {
            cmake {
                cppFlags "-fexceptions"
                arguments '-DANDROID_STL=c++_shared',
                        '-DANDROID_TOOLCHAIN=gcc'
            }
        }
        ndk {
            // Specifies the ABI configurations of your native
            // libraries Gradle should build and package with your APK.
            abiFilters  'x86', 'x86_64'
        }
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
    externalNativeBuild {
        cmake {
            path "CMakeLists.txt"
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'com.android.support:appcompat-v7:26.1.0'
    implementation 'com.android.support.constraint:constraint-layout:1.0.2'
    implementation 'com.android.support:design:26.1.0'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'com.android.support.test:runner:1.0.1'
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'
}

[DanAlbert]

GCC is no longer supported. Please fill out the issue form rather than deleting it next time.

[karimhasebou]

@DanAlbert i switched to gcc because clang seems to crash in earlier parts of the code

[DanAlbert]

You'll need to file those bugs then (again, with a repro case because we can't fix if there's no indication of what the problem might be).

I'd also recommend making use of a newer NDK (you deleted the part of the form that says which NDK you're using, so we don't know) and trying ubsan to flush out any undefined behavior issues that you may be running in to, since those often account for strange compiler vs compiler bugs.

[karimhasebou]

@DanAlbert I have tried to use ubsan but adding it causes a compilation error error:

undefined reference to '__ubsan_handle_type_mismatch_v1' among many other errors. Also I checked my ndk version its 16.1.4479499 and i switched to clang

[DanAlbert]

Unsan requires at least r17, which is currently in beta. I wouldn't use it for production, but would be worth a try for debugging this.

[karimhasebou]

@DanAlbert I have downloaded it, and added these lines to my cmake from this post #527. However am not sure what should I do afterwards because when I run the application I get this error java.lang.UnsatisfiedLinkError: dlopen failed: library "libclang_rt.ubsan_standalone-x86_64.so". I noticed that you have mentioned that in r17 I still need to bundle it but I have no experience with ndk commandline tools. is there a step by step tutorial for doing so

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=undefined")
add_library(ubsan-rt SHARED IMPORTED)
set_property(TARGET ubsan-rt PROPERTY IMPORTED_LOCATION "${ANDROID_NDK}/toolchains/llvm/prebuilt/linux-x86_64/lib64/clang/5.0/lib/linux/libclang_rt.ubsan_standalone-aarch64-android.so")

target_link_libraries(hello-jni
android
log
ubsan-rt
)

[DanAlbert]

You'll need to add libclang_rt.ubsan_standalone-x86_64.so to your APK. ndk-build does this for you, but CMake does not (I don't know if gradle with actually include it even if you do use ndk-build though).

FYI, you shouldn't need to manually link ubsan like you have. The compiler should be doing that for you.

[karimhasebou]

@DanAlbert I apologize for the inconvenience i have caused so far. I found on stackoverflow that simply putting the library in JniLibs folder in the project will make android studio put the library in the apk. However, now the app crashes because java.lang.UnsatisfiedLinkError: dlopen failed: library "libstdc++.so.6" not found. any workaround that

[DanAlbert]

Hmm, actually there's something wrong there. That's the Linux library rather than the Android one. I'll take a look when I'm back from lunch.

[karimhasebou]

i forgot to mention so far I have been using x86_64 emulator

[rprichard]

It looks like there are four variants of the x86_64 ubsan lib included with r17:

• libclang_rt.ubsan_minimal-x86_64-android.so
• libclang_rt.ubsan_minimal-x86_64.so
• libclang_rt.ubsan_standalone-x86_64-android.so
• libclang_rt.ubsan_standalone-x86_64.so

The ones without "-android.so" have DT_NEEDED entries for the Linux/non-Android libraries like libstdc++.so.6. The ones ending in "-android.so" should work.

[DanAlbert]

java.lang.UnsatisfiedLinkError: dlopen failed: library "libclang_rt.ubsan_standalone-x86_64.so"

I'm not really sure how you managed to cause this without having explicitly linked the wrong library (which you shouldn't need to do; the compiler handles it for you).

CMakeLists.txt:

cmake_minimum_required(VERSION 3.6.0)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=undefined")

add_executable(foo foo.cpp)

$ readelf -dW build/foo | grep ubsan
 0x0000000000000001 (NEEDED)             Shared library: [libclang_rt.ubsan_standalone-x86_64-android.so]

[karimhasebou]

@DanAlbert I have siwtched to the proper ubsan library and once I run the debugger shows A/libc: Fatal signal 31 (SIGSYS), code 1 in tid 15875 .

The stack frame is showing
___lldb_unnamed_symbol202$$libclang_rt.ubsan_standalone-x86_64-android.so 0x0000729134b4a8ae

[DanAlbert]

SIGSYS means you're calling a black listed system call. Is that the full stack trace? Is that the full error message?

[karimhasebou]

@DanAlbert yes thats the whole error message

[DanAlbert]

What about the stack trace?

[karimhasebou]

nothing other than the libc: Fatal signal 31 (SIGSYS), code 1 in tid 4090 i mentioned earlier

[DanAlbert]

No, I mean the stack trace. The part that contained ___lldb_unnamed_symbol202$$libclang_rt.ubsan_standalone-x86_64-android.so 0x0000729134b4a8ae. Is that the only entry?

[karimhasebou]

I have attached screenshots of the stackframe, this isn't even the full list

[DanAlbert]

I'd recommend trying to run outside the debugger, but given that I haven't been able to reproduce any of these problems I'm not sure what else I can do to help. The SIGSYS indicates the something is misbehaving, but it's rather strange that it would be coming from ubsan.

[karimhasebou]

@DanAlbert Have you been testing using android studio or command line tools ? Am starting to think that maybe gradle is responsible for this? I have yet to find a solution to the problem. it seems that the problem isn't any particular line of code because replacing the line that crashes with any code will do the same. it seems some kind of corruption occurs but I can't pin point it since all I am doing at this point is instantiating a class that initializes its member fields .

[DanAlbert]

No, we don't use Gradle. If you think it's a Gradle or Studio issue you'll need to file a bug against Studio at b.android.com since we don't work on either of those.

[DanAlbert]

But note that they're going to tell you the same thing: they can't fix the bug if they can't see the bug.