Android C++: uncaught exception from loaded shared library











up vote
2
down vote

favorite












I'm new to stackoverflow and I wish to ask for some help on Android C++.



I'm trying to implement a very simple Android test program in C++ which calls a function in a loaded shared library implemented in C++ as well.



Here is my main JNI implemenation (native-lib.cpp):



#include <jni.h>
#include <string>
#include <dlfcn.h>
#include "external.hpp"

extern "C" JNIEXPORT jstring JNICALL
Java_com_useless_myapplication_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
void* handle;
void (*funcext)();
handle = dlopen("libexternal.so",RTLD_LAZY);
funcext = (void (*)(void))dlsym(handle, "_Z5func2v");
try {
funcext();
}
catch (MyException &err)
{
std::string hello = "MyException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException &err)
{
std::string hello = "GenericException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException* err)
{
std::string hello = "GenericException* from C++";
return env->NewStringUTF(hello.c_str());
}

std::string hello = "Hello from C++";
return env->NewStringUTF(hello.c_str());
}


And here is my libexternal.so implementation (external.cpp):



#include <jni.h>
#include <string.h>
#include "external.hpp"
GenericException::GenericException(){};
GenericException::GenericException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

MyException::MyException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

void func()
{
throw MyException(10,"Error1!");
}
bool func3()
{
try {
func();
}
catch (GenericException &err)
{
return false;
}
return true;
}

void func2()
{
if (!func3())
throw MyException(11,"Error2!");
}


The external.hpp file is defined as follows:



void func();
void func2();
bool func3();
class GenericException
{
public:
GenericException();
GenericException(int errcode,char* msg);
protected:
int errorcode;
char message[256];
};

class MyException : public GenericException
{
public:
MyException(int errcode,char* msg);
};


The program compiles and links clean however when I run it my android application crashes whith the following message in the logcat:



2018-11-14 09:57:42.058 6519-6519/com.useless.myapplication A/libc: /usr/local/google/buildbot/src/android/ndk-release-r18/external/libcxx/../../external/libcxxabi/src/abort_message.cpp:73: abort_message: assertion "terminating with uncaught exception of type MyException" failed


The error rises when I try to execute external.cpp line 41:



throw MyException(11,"Error2!");


As suggested by other posts I've found I've tried to enable the -frtti flag in my app build.gradle cppflgs but this doesn't solved the error.



I've tried to run the same code (without the Java top layer honestly) on Linux and MacOS but on these platforms the exception is caught by the native-lib.cpp code.



Is there something I'm not aware of about C++ exceptions in Android?
How can I be able to catche the exception thrown by a library I loaded with dlopen on Android?



Thanks










share|improve this question
























  • Is there any particular reason why your GenericException class does not derive from std::exception?
    – Michael
    Nov 14 at 9:58










  • In fact I'm working in porting a multi-platform C++ proprietary project on Android. Since I'm not authorized to show the code I wrote this sample to be consistent with the original project I'm porting: since the original project exceptions are not derived from std::exception I decided to not derive my sample's exceptions as well.
    – ss900ie
    Nov 14 at 10:03















up vote
2
down vote

favorite












I'm new to stackoverflow and I wish to ask for some help on Android C++.



I'm trying to implement a very simple Android test program in C++ which calls a function in a loaded shared library implemented in C++ as well.



Here is my main JNI implemenation (native-lib.cpp):



#include <jni.h>
#include <string>
#include <dlfcn.h>
#include "external.hpp"

extern "C" JNIEXPORT jstring JNICALL
Java_com_useless_myapplication_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
void* handle;
void (*funcext)();
handle = dlopen("libexternal.so",RTLD_LAZY);
funcext = (void (*)(void))dlsym(handle, "_Z5func2v");
try {
funcext();
}
catch (MyException &err)
{
std::string hello = "MyException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException &err)
{
std::string hello = "GenericException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException* err)
{
std::string hello = "GenericException* from C++";
return env->NewStringUTF(hello.c_str());
}

std::string hello = "Hello from C++";
return env->NewStringUTF(hello.c_str());
}


And here is my libexternal.so implementation (external.cpp):



#include <jni.h>
#include <string.h>
#include "external.hpp"
GenericException::GenericException(){};
GenericException::GenericException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

MyException::MyException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

void func()
{
throw MyException(10,"Error1!");
}
bool func3()
{
try {
func();
}
catch (GenericException &err)
{
return false;
}
return true;
}

void func2()
{
if (!func3())
throw MyException(11,"Error2!");
}


The external.hpp file is defined as follows:



void func();
void func2();
bool func3();
class GenericException
{
public:
GenericException();
GenericException(int errcode,char* msg);
protected:
int errorcode;
char message[256];
};

class MyException : public GenericException
{
public:
MyException(int errcode,char* msg);
};


The program compiles and links clean however when I run it my android application crashes whith the following message in the logcat:



2018-11-14 09:57:42.058 6519-6519/com.useless.myapplication A/libc: /usr/local/google/buildbot/src/android/ndk-release-r18/external/libcxx/../../external/libcxxabi/src/abort_message.cpp:73: abort_message: assertion "terminating with uncaught exception of type MyException" failed


The error rises when I try to execute external.cpp line 41:



throw MyException(11,"Error2!");


As suggested by other posts I've found I've tried to enable the -frtti flag in my app build.gradle cppflgs but this doesn't solved the error.



I've tried to run the same code (without the Java top layer honestly) on Linux and MacOS but on these platforms the exception is caught by the native-lib.cpp code.



Is there something I'm not aware of about C++ exceptions in Android?
How can I be able to catche the exception thrown by a library I loaded with dlopen on Android?



Thanks










share|improve this question
























  • Is there any particular reason why your GenericException class does not derive from std::exception?
    – Michael
    Nov 14 at 9:58










  • In fact I'm working in porting a multi-platform C++ proprietary project on Android. Since I'm not authorized to show the code I wrote this sample to be consistent with the original project I'm porting: since the original project exceptions are not derived from std::exception I decided to not derive my sample's exceptions as well.
    – ss900ie
    Nov 14 at 10:03













up vote
2
down vote

favorite









up vote
2
down vote

favorite











I'm new to stackoverflow and I wish to ask for some help on Android C++.



I'm trying to implement a very simple Android test program in C++ which calls a function in a loaded shared library implemented in C++ as well.



Here is my main JNI implemenation (native-lib.cpp):



#include <jni.h>
#include <string>
#include <dlfcn.h>
#include "external.hpp"

extern "C" JNIEXPORT jstring JNICALL
Java_com_useless_myapplication_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
void* handle;
void (*funcext)();
handle = dlopen("libexternal.so",RTLD_LAZY);
funcext = (void (*)(void))dlsym(handle, "_Z5func2v");
try {
funcext();
}
catch (MyException &err)
{
std::string hello = "MyException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException &err)
{
std::string hello = "GenericException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException* err)
{
std::string hello = "GenericException* from C++";
return env->NewStringUTF(hello.c_str());
}

std::string hello = "Hello from C++";
return env->NewStringUTF(hello.c_str());
}


And here is my libexternal.so implementation (external.cpp):



#include <jni.h>
#include <string.h>
#include "external.hpp"
GenericException::GenericException(){};
GenericException::GenericException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

MyException::MyException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

void func()
{
throw MyException(10,"Error1!");
}
bool func3()
{
try {
func();
}
catch (GenericException &err)
{
return false;
}
return true;
}

void func2()
{
if (!func3())
throw MyException(11,"Error2!");
}


The external.hpp file is defined as follows:



void func();
void func2();
bool func3();
class GenericException
{
public:
GenericException();
GenericException(int errcode,char* msg);
protected:
int errorcode;
char message[256];
};

class MyException : public GenericException
{
public:
MyException(int errcode,char* msg);
};


The program compiles and links clean however when I run it my android application crashes whith the following message in the logcat:



2018-11-14 09:57:42.058 6519-6519/com.useless.myapplication A/libc: /usr/local/google/buildbot/src/android/ndk-release-r18/external/libcxx/../../external/libcxxabi/src/abort_message.cpp:73: abort_message: assertion "terminating with uncaught exception of type MyException" failed


The error rises when I try to execute external.cpp line 41:



throw MyException(11,"Error2!");


As suggested by other posts I've found I've tried to enable the -frtti flag in my app build.gradle cppflgs but this doesn't solved the error.



I've tried to run the same code (without the Java top layer honestly) on Linux and MacOS but on these platforms the exception is caught by the native-lib.cpp code.



Is there something I'm not aware of about C++ exceptions in Android?
How can I be able to catche the exception thrown by a library I loaded with dlopen on Android?



Thanks










share|improve this question















I'm new to stackoverflow and I wish to ask for some help on Android C++.



I'm trying to implement a very simple Android test program in C++ which calls a function in a loaded shared library implemented in C++ as well.



Here is my main JNI implemenation (native-lib.cpp):



#include <jni.h>
#include <string>
#include <dlfcn.h>
#include "external.hpp"

extern "C" JNIEXPORT jstring JNICALL
Java_com_useless_myapplication_MainActivity_stringFromJNI(
JNIEnv *env,
jobject /* this */) {
void* handle;
void (*funcext)();
handle = dlopen("libexternal.so",RTLD_LAZY);
funcext = (void (*)(void))dlsym(handle, "_Z5func2v");
try {
funcext();
}
catch (MyException &err)
{
std::string hello = "MyException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException &err)
{
std::string hello = "GenericException from C++";
return env->NewStringUTF(hello.c_str());
}
catch (GenericException* err)
{
std::string hello = "GenericException* from C++";
return env->NewStringUTF(hello.c_str());
}

std::string hello = "Hello from C++";
return env->NewStringUTF(hello.c_str());
}


And here is my libexternal.so implementation (external.cpp):



#include <jni.h>
#include <string.h>
#include "external.hpp"
GenericException::GenericException(){};
GenericException::GenericException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

MyException::MyException(int errcode,char* msg)
{
errorcode = errcode;
memset(message,0,256);
strcpy(message,msg);
}

void func()
{
throw MyException(10,"Error1!");
}
bool func3()
{
try {
func();
}
catch (GenericException &err)
{
return false;
}
return true;
}

void func2()
{
if (!func3())
throw MyException(11,"Error2!");
}


The external.hpp file is defined as follows:



void func();
void func2();
bool func3();
class GenericException
{
public:
GenericException();
GenericException(int errcode,char* msg);
protected:
int errorcode;
char message[256];
};

class MyException : public GenericException
{
public:
MyException(int errcode,char* msg);
};


The program compiles and links clean however when I run it my android application crashes whith the following message in the logcat:



2018-11-14 09:57:42.058 6519-6519/com.useless.myapplication A/libc: /usr/local/google/buildbot/src/android/ndk-release-r18/external/libcxx/../../external/libcxxabi/src/abort_message.cpp:73: abort_message: assertion "terminating with uncaught exception of type MyException" failed


The error rises when I try to execute external.cpp line 41:



throw MyException(11,"Error2!");


As suggested by other posts I've found I've tried to enable the -frtti flag in my app build.gradle cppflgs but this doesn't solved the error.



I've tried to run the same code (without the Java top layer honestly) on Linux and MacOS but on these platforms the exception is caught by the native-lib.cpp code.



Is there something I'm not aware of about C++ exceptions in Android?
How can I be able to catche the exception thrown by a library I loaded with dlopen on Android?



Thanks







android c++ android-ndk shared-libraries dlopen






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 at 1:20









shizhen

2,4963727




2,4963727










asked Nov 14 at 9:52









ss900ie

111




111












  • Is there any particular reason why your GenericException class does not derive from std::exception?
    – Michael
    Nov 14 at 9:58










  • In fact I'm working in porting a multi-platform C++ proprietary project on Android. Since I'm not authorized to show the code I wrote this sample to be consistent with the original project I'm porting: since the original project exceptions are not derived from std::exception I decided to not derive my sample's exceptions as well.
    – ss900ie
    Nov 14 at 10:03


















  • Is there any particular reason why your GenericException class does not derive from std::exception?
    – Michael
    Nov 14 at 9:58










  • In fact I'm working in porting a multi-platform C++ proprietary project on Android. Since I'm not authorized to show the code I wrote this sample to be consistent with the original project I'm porting: since the original project exceptions are not derived from std::exception I decided to not derive my sample's exceptions as well.
    – ss900ie
    Nov 14 at 10:03
















Is there any particular reason why your GenericException class does not derive from std::exception?
– Michael
Nov 14 at 9:58




Is there any particular reason why your GenericException class does not derive from std::exception?
– Michael
Nov 14 at 9:58












In fact I'm working in porting a multi-platform C++ proprietary project on Android. Since I'm not authorized to show the code I wrote this sample to be consistent with the original project I'm porting: since the original project exceptions are not derived from std::exception I decided to not derive my sample's exceptions as well.
– ss900ie
Nov 14 at 10:03




In fact I'm working in porting a multi-platform C++ proprietary project on Android. Since I'm not authorized to show the code I wrote this sample to be consistent with the original project I'm porting: since the original project exceptions are not derived from std::exception I decided to not derive my sample's exceptions as well.
– ss900ie
Nov 14 at 10:03












1 Answer
1






active

oldest

votes

















up vote
0
down vote













You exception type does not have a key function, so it's typeinfo is emitted with vague linkage. The means it is a weak symbol in every library in which it is used.



Your JNI library loads and resolves its own typeinfo. Your dlopened library is then loaded and also resolves its own typeinfo because it cannot access the parent scope (System.loadLibrary uses RTLD_LOCAL). Because of this, there are two separate typeinfo objects for your exception type. RTTI equality is checked by comparing the addresses of the typeinfo object (see the C++ ABI spec).



I'm not certain if this can be resolved without directly linking your JNI code to libexternal.so. If you add the key function necessary to make this work (which would be defined in libexternal.so), then I believe you'd need to link to it for your JNI code to link.






share|improve this answer





















  • Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
    – ss900ie
    Nov 15 at 13:54












  • If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
    – Dan Albert
    Nov 15 at 19:14











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297295%2fandroid-c-uncaught-exception-from-loaded-shared-library%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote













You exception type does not have a key function, so it's typeinfo is emitted with vague linkage. The means it is a weak symbol in every library in which it is used.



Your JNI library loads and resolves its own typeinfo. Your dlopened library is then loaded and also resolves its own typeinfo because it cannot access the parent scope (System.loadLibrary uses RTLD_LOCAL). Because of this, there are two separate typeinfo objects for your exception type. RTTI equality is checked by comparing the addresses of the typeinfo object (see the C++ ABI spec).



I'm not certain if this can be resolved without directly linking your JNI code to libexternal.so. If you add the key function necessary to make this work (which would be defined in libexternal.so), then I believe you'd need to link to it for your JNI code to link.






share|improve this answer





















  • Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
    – ss900ie
    Nov 15 at 13:54












  • If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
    – Dan Albert
    Nov 15 at 19:14















up vote
0
down vote













You exception type does not have a key function, so it's typeinfo is emitted with vague linkage. The means it is a weak symbol in every library in which it is used.



Your JNI library loads and resolves its own typeinfo. Your dlopened library is then loaded and also resolves its own typeinfo because it cannot access the parent scope (System.loadLibrary uses RTLD_LOCAL). Because of this, there are two separate typeinfo objects for your exception type. RTTI equality is checked by comparing the addresses of the typeinfo object (see the C++ ABI spec).



I'm not certain if this can be resolved without directly linking your JNI code to libexternal.so. If you add the key function necessary to make this work (which would be defined in libexternal.so), then I believe you'd need to link to it for your JNI code to link.






share|improve this answer





















  • Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
    – ss900ie
    Nov 15 at 13:54












  • If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
    – Dan Albert
    Nov 15 at 19:14













up vote
0
down vote










up vote
0
down vote









You exception type does not have a key function, so it's typeinfo is emitted with vague linkage. The means it is a weak symbol in every library in which it is used.



Your JNI library loads and resolves its own typeinfo. Your dlopened library is then loaded and also resolves its own typeinfo because it cannot access the parent scope (System.loadLibrary uses RTLD_LOCAL). Because of this, there are two separate typeinfo objects for your exception type. RTTI equality is checked by comparing the addresses of the typeinfo object (see the C++ ABI spec).



I'm not certain if this can be resolved without directly linking your JNI code to libexternal.so. If you add the key function necessary to make this work (which would be defined in libexternal.so), then I believe you'd need to link to it for your JNI code to link.






share|improve this answer












You exception type does not have a key function, so it's typeinfo is emitted with vague linkage. The means it is a weak symbol in every library in which it is used.



Your JNI library loads and resolves its own typeinfo. Your dlopened library is then loaded and also resolves its own typeinfo because it cannot access the parent scope (System.loadLibrary uses RTLD_LOCAL). Because of this, there are two separate typeinfo objects for your exception type. RTTI equality is checked by comparing the addresses of the typeinfo object (see the C++ ABI spec).



I'm not certain if this can be resolved without directly linking your JNI code to libexternal.so. If you add the key function necessary to make this work (which would be defined in libexternal.so), then I believe you'd need to link to it for your JNI code to link.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 14 at 21:02









Dan Albert

4,95711447




4,95711447












  • Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
    – ss900ie
    Nov 15 at 13:54












  • If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
    – Dan Albert
    Nov 15 at 19:14


















  • Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
    – ss900ie
    Nov 15 at 13:54












  • If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
    – Dan Albert
    Nov 15 at 19:14
















Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
– ss900ie
Nov 15 at 13:54






Thank you very much for your answer Dan. You are right if I insert a key function in my classes I need to link with libexternal.so in order to obtain my native-lib.so linked correctly: of course if I link native-lib with libexternal the Android sample runs correctly. In the meantime I've also tried to implement the described behavior under Linux by putting a java wrapper on top and calling via JNI: unfortunately this seems to be an Android only behavior since on Linux the exception is correctly caught even if everything is run from a Java wrapper.
– ss900ie
Nov 15 at 13:54














If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
– Dan Albert
Nov 15 at 19:14




If that's the case then your system is not compliant with the C++ ABI. Presumably you're using GNU's libstdc++ on your system, which performs a name string equality check for RTTI comparisons. This can lead to two completely unrelated but identically named types being considered equal, which is why the spec does not use this method.
– Dan Albert
Nov 15 at 19:14


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297295%2fandroid-c-uncaught-exception-from-loaded-shared-library%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How to send String Array data to Server using php in android

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Is anime1.com a legal site for watching anime?