I am writing native code on Android and CPP exceptions are disabled by default.
I could simply enable them but I love leaving settings to default.
So I wonder if I can use all features of libc++ if exceptions are disabled?
Here is one code example:
std::__fs::filesystem::directory_iterator it("/does/not/exist");
The libc++ is compiled with exceptions. So this line will throw an exception. But I cannot catch it because my code is compiled without exceptions. My program will crash because an exception of type filesystem_error is thrown and I did not catch it:
terminating with uncaught exception of type std::__ndk1::__fs::filesystem::filesystem_error: filesystem error: in directory_iterator::directory_iterator(...): No such file or directory [/does/not/exist]
/buildbot/src/android/ndk-release-r23/toolchain/llvm-project/libcxx/../../../toolchain/llvm-project/libcxxabi/src/abort_message.cpp:72: abort_message: assertion "terminating with uncaught exception of type std::__ndk1::__fs::filesystem::filesystem_error: filesystem error: in directory_iterator::directory_iterator(...): No such file or directory [/does/not/exist]" failed
Aborted
So my question is if it is possible to use full libc++ if exceptions are disabled in my code?
Edit:
I am building a native standalone executable using ndk-build.
Related
I have a library with ndk code library which is throwing a sigdev on a particular device I have, which kills my app. Is it possible to catch this sigdev and throw a Java exception? The catch must be done without modification to the library which is throwing the exception.
The exception looks like so:
01-26 09:09:38.610 19393-19869/com.foo.bar A/libc: /Volumes/Android/buildbot/src/android/ndk-r12-release/ndk/sources/cxx-stl/llvm-libc++abi/libcxxabi/src/abort_message.cpp:74: void abort_message(const char *, ...): assertion "terminating with uncaught exception of type char const*" failed
01-26 09:09:38.610 19393-19869/com.foo.bar A/libc: Fatal signal 6 (SIGABRT) at 0x00004bc1 (code=-6), thread 19869 (Thread-9201)
There are similar questions asked elsewhere on SO, however it seems that in those cases they control both the NDK and the Java sourc, and use the ndk code to trigger a java exception. In my situation I do not have any control over the ndk code, it is a closed source library, so I must handle it entirely via the Java code, or additional ndk code of my own creation.
You can't catch native exceptions in Java, but you can catch them from C++ and turn them into Java exceptions via a wrapper library. Call your wrapper from Java rather than the original library and let your wrapper library delegate the work but handle exceptions.
This may not work, as catching exceptions across shared library boundaries most likely requires that both libraries are built with RTTI, exceptions, and are using the same STL.
I'm currently building an android application using ANT on a Jenkins server.
DexGuard is set to run on release in the custom_rules.xml.
Currently there is an issue when DexGuard tries to convert a method:
[dexguard] Unexpected error while converting:
[dexguard] Class = [o/?]
[dexguard] Method = [?(Ljava/lang/String;)Lo/?;]
[dexguard] Exception = [java.lang.IllegalStateException] (Variable v17 too large for instruction [neg-int v17, v17])
[dexguard] java.lang.IllegalStateException: Variable v17 too large for instruction [neg-int v17, v17]
...
Stack trace
...
[dexguard] Not converting this method
My question is, is there a way to get DexGuard to exit with an error status so that either ANT or Jenkins can mark the build as failed?
At the moment it simply prints the stack trace and continues.
I am currently using the Text-finder plugin for Jenkins as a post build step to match a DexGuard exception. If found it downgrades the build to failed.
DexGuard currently ignores methods that it can't convert from Java bytecode to Dalvik bytecode, for any reason -- notably corrupt input code. In this case, it looks more like a bug in DexGuard itself. We'll fix it as soon as possible, and we'll consider adding a flag to stop with an error status.
(I am the lead developer of ProGuard and DexGuard)
I am writing a C++ module for the Nexus 7 Android kernel. Previously I compiled this module successfully with the Goldfish kernel. But now after porting the necessary changes to the Nexus 7 kernel, I am getting a compilation error. The problem seems to be with the headers. Whenever i include the linux/fs.h or linux/debugfs.h in the module, it is giving the following error.
/linux/radix-tree.h: In function 'void* radix_tree_deref_slot(void**)':
/android_kernel_grouper-android-tegra3-grouper-3.1-jb-fr2/include/linux/radix-tree.h:153:9: error: 'void*' is not a pointer-to-object type
The corresponding line in the radix-tree.h has something to do with rcu_dereference().
Is the problem with the headers, or the makefile or due to faulty patching?
To find out the compilation parameters used in gcc (or g++), you should use "make V=1" against the makefile. but the error:
error: 'void*' is not a pointer-to-object type
looked more like a C++ error, which is inherent in your code (Android kernel does not use C++).
This seemed to be solvable by recasting:
Error: ‘void*’ is not a pointer-to-object type
C++. Error: void is not a pointer-to-object type
etc.
I'm porting some C++ code to Android using NDK and GCC. The code basically runs. At one point, when debugging in Eclipse, the call
Dabbler::Android::Factory* pFactory = new Dabbler::Android::Factory;
causes this error:
Thread [1] (Suspended: Signal 'SIGILL' received. Description: Illegal instruction.)
1 <symbol is not available> 0x812feb44
What does that mean? Has the compiler generated illegal code for some reason? I have a breakpoint in the constructor (which does nothing), and it's not hit. I have already done a full rebuild.
What could I be doing wrong to cause this problem?
Make sure that all functions with non-void return type have a return statement.
While some compilers automatically provide a default return value, others will send a SIGILL or SIGTRAP at runtime when trying to leave a function without a return value.
It means the CPU attempted to execute an instruction it didn't understand. This could be caused by corruption I guess, or maybe it's been compiled for the wrong architecture (in which case I would have thought the O/S would refuse to run the executable). Not entirely sure what the root issue is.
It could be some un-initialized function pointer, in particular if you have corrupted memory (then the bogus vtable of C++ bad pointers to invalid objects might give that).
BTW gdb watchpoints & tracepoints, and also valgrind might be useful (if available) to debug such issues. Or some address sanitizer.
LeetCode's online compiler and dev environment generates SIGILL errors for mistakes that do not generate the same error in my desktop IDE.
For example, array access with an out-of-bounds index:
["foo", "bar"][2]
LeetCode's compiler shows only the error:
Runtime Error
process exited with signal SIGILL
in a local Xcode playground this same code instead results in the error:
error: Execution was interrupted, reason: EXC_BREAKPOINT (code=1, subcode=0x18f2ea5d8).
The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation.
Only in a full Xcode project compilation and run does it report the actual error:
Thread 1: Fatal error: Index out of range
I am creating an Android app that includes a third party jar. That third party jar utilizes internal logging that is failing to initialize when I run the app, with this error: "org.apache.commons.logging.LogConfigurationException: No suitable Log implementation".
The 3rd party jar appears to be using org.apache.commons.logging and to depend on log4j, specifically log4j-1.2.14.jar. I have packaged the log4j jar into the Android app. The third party jar was packaged with a log4j.xml configuration file, which I have tried packaging into the app as an XML resource (and also as a raw resource).
The "No suitable Log implementation" error message is not very descriptive, and I have no immediate familiarity with Java logging. So I am looking for likely causes of the problem (what class or configuration resources might I be missing?) or for some debugging technique that will result in a different error message that is more explicit about the problem. I do not have access to source code for the 3rd party jar.
Here is the exception stack trace. When I run the app, I get the following exception as soon as one of the third party jar classes attempts to initialize its internal logging.
DEBUG/AndroidRuntime(15694): Shutting down VM
WARN/dalvikvm(15694): threadid=3: thread exiting with uncaught exception (group=0x4001b180)
ERROR/AndroidRuntime(15694): Uncaught handler: thread main exiting due to uncaught exception
ERROR/AndroidRuntime(15694): java.lang.ExceptionInInitializerError
ERROR/AndroidRuntime(15694): Caused by: org.apache.commons.logging.LogConfigurationException: No suitable Log implementation
ERROR/AndroidRuntime(15694): at org.apache.commons.logging.impl.LogFactoryImpl.discoverLogImplementation(LogFactoryImpl.java:842)
ERROR/AndroidRuntime(15694): at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:601)
ERROR/AndroidRuntime(15694): at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:333)
ERROR/AndroidRuntime(15694): at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:307)
ERROR/AndroidRuntime(15694): at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:645)
ERROR/AndroidRuntime(15694): at org.apache.commons.configuration.ConfigurationFactory.<clinit>(ConfigurationFactory.java:77)
It may help to study the logic around org.apache.commons.logging.impl.LogFactoryImpl
There's probably a way of injecting a Log implementation.
http://google.com/codesearch/p?hl=en#CskViEIa27Y/src/org/apache/commons/logging/impl/LogFactoryImpl.java&l=762
http://google.com/codesearch/p?hl=en#CskViEIa27Y/src/org/apache/commons/logging/impl/LogFactoryImpl.java&l=883