I am developing an Android application using NDK. The application blows up with "SIGSEGV" error which I believe a segmentation fault error.
I looked at my code and I think memcopy and memmove might cause this error. I was wondering if there is a safe way to call these functions.
Also please let me know any well described NDK debugging tutorials or anything related. Thanks in advance.
The rule with those 2 is that you use memcpy when you're copying a block of bytes from one place to another, and the source and destination don't overlap. If they do overlap, you have to use memmove. However, using them incorrectly results in corrupted data, not segfaults. Segfaults happen when you try to read or write to a memory location that is invalid - its analogous to Java's NullPointerException. You want to triple check that you have destination, source and size in the correct order. Beyond that, we'll need to see some code.
You can use Android's "logcat" logging facility within NDK code, so if you need to understand where things are going bad, that can be pretty helpful (unless you're able to run gdb / gdbserver).
It's very possible that memcpy or memmov can cause a SIGSEGV. You need to be sure all your pointers are correct, and the buffer sizes are correct as well. If you make a mistake there, the best that can happen is your SIGSEGV and program crash. On the worse end, you could overwrite other memory in your application and not know until some time later (making it difficult to find the cause of the corruption).
Related
I'm getting this error in some ARM code I'm trying to compile for armeabi-v7a - clearly pre-v7a stuff.
jni/6502asm_arm.S:108:2: error: invalid instruction, did you mean: strexh, strh?
streqh r1,[ r4, #28]
The last time I programmed ARM assembly was ARM3 on an Archimedes, but it was fairly obvious that streqh is a half-word store-if-equal.
I'm completely perplexed by it causing that error message: When did all instructions stop being conditional in ARM? That makes me sad. (I know something about Thumb, but I don't think this is Thumb code.)
I gather that ex means 'exclusive' and needs me to get some sort of lock - this application is a BBC emulator for Android, and it's unlikely to be emulating two 6502s at the same time, so I presume I'm OK with strh but what do I do about the eq?
Do I need to use the 'if then else' thumb instruction, or jump over it with bne or what? I thought the whole 'everything has a condition' idea was central to ARM.
(While I'm writing, I suspect I need to make this code PIC, and there's a table of absolute references to functions implementing 6502 instructions at the end of the source. I presume PC-relative addressing is still complicated by the pipeline length? Is the offset the same for all ARM flavours I'm likely to encounter? Is it still 3 words? :)
Thanks in advance!
There has been a revision in ASM syntax from divided syntax into unified syntax (UAL). In the new syntax, the execution condition is always last, so the new mnemonic is strheq.
These other instructions are just instructions with a name similar to the one you typed. They have nothing to do with what you want.
Note that if you are programming in thumb mode, you need to have an appropriate it instruction in front to set up conditional execution. Refer to the manual for details.
If you are writing an assembly file for the GNU assembler, you might need to provide a
.syntax unified
directive to set up unified syntax. This might be the default for clang's built in assembler, but I'm not sure.
Your other questions were answered by #fuz
When did all instructions stop being conditional in ARM?
Only in Aarch64; it's not your problem here.
I presume PC-relative addressing is still complicated by the pipeline length?
There is the historical fixed offset for pipeline addressing from "back when", but its architected behavior so you can rely on it being the same across implementations. (IIRC, also gone in Aarch64 as it was a slightly random quirk which served no real purpose).
I'm getting into Vulkan development on Android and am finding that some of the validation layers reported by vkEnumerateInstanceLayerProperties() cause vkCreateInstance() to return VK_ERROR_LAYER_NOT_PRESENT.
I'm working from Google's validation layer example, as well as the validation chapter from Vulkan-Tutorial.com. Through trial and error, I've found that I'm able to create a VkInstance when requesting some of the SDK's provided layers but not others.
After following the setup steps in Google's guide above, my APK contains seven libVkLayer_foo.so files for each architecture and vkEnumerateInstanceLayerProperties() lists seven layers, as expected. But when I try to create a VkInstance with any of the layers below, vkCreateInstance() returns VK_ERROR_LAYER_NOT_PRESENT:
VK_LAYER_LUNARG_parameter_validation
VK_LAYER_LUNARG_object_tracker
VK_LAYER_GOOGLE_unique_objects
Does anyone know what might cause this? I assumed that if vkEnumerateInstanceLayerProperties() knows about a layer, vkCreateInstance() should too. Although, I do see a crash occurring in libvulkan.so immediately after vkCreateInstance() returns. I'm not sure if that is the cause of the VK_ERROR_LAYER_NOT_PRESENT or a result.
If it makes any difference, this is running on an nVidia Shield TV.
Update Oddly enough, the layers that cause a crash seem to be changing. Now I'm able to use VK_LAYER_LUNARG_parameter_validation, even though requesting that layer used to cause a crash.
And just to clarify, I only experience crashes when I use certain validation layers provided in the LunarG SDK on Android. I am able to create a VkInstance with the other validation layers and my callback function does get called.
The problem ended up being a more general C/C++ "undefined behavior" issue, which might also explain why the "trouble" layer changed at one point. Consider a block of code like this, where extensions is a std::vector:
VkInstanceCreateInfo createInfo = {};
...
createInfo.enabledExtensionCount = (uint32_t) extensions.size();
createInfo.ppEnabledExtensionNames = extensions.data();
In general, this works fine. But the code to create the VkInstanceCreateInfo is in a helper method and extensions goes out of scope (i.e., is destroyed) before createInfo is used. So vkCreateInstance ends up with a pointer to memory that's been deallocated.
I'm trying to port a game to Android, and I've been using boost for the saving / loading behaviour. The App now crashes when the save code is called. The crash occurs while trying to make text_oarchives, as with the following sample code:
void OHRMapArchiver::saveMap()
{
// copy some boost-incompatible data structures into ivar vectors
mapInstance->preSave();
CCLog("preSave");
std::ofstream outStream(MAP_SAVE_FILE);
CCLog("creating archive");
boost::archive::text_oarchive outputArchive(outStream);
CCLog("Outputting archive");
outputArchive << mapInstance;
// destroy all that stuff copied during pre-save
mapInstance->tileLoader.erase(mapInstance->tileLoader.begin(), mapInstance->tileLoader.end());
}
I sure could use some advice on why this might not be the case. I've given up on being able to debug on device, but the specific error I'm getting when
boost::archive::text_oarchive outputArchive(outStream);
is called is "Fatal signal 11 (SIGSEGV) at 0xdead (code=1), thread 1969 (Thread-112)". So segfault, but I can't imagine why, when as far as I know, it's only creating a wrapper around an ostream.
Other helpful clues... hm, I know I can create objects that implement serialize( Archive &ar, int version ), although I can't say for sure any objects have called it successfully yet. Possible linkage problems?
Also, file access permissions are enabled for App. At least, "uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" " has been added to the manifest, and I can make and output files using std::ostream.write without crash. Also, as title implies, the win32 version works perfectly, outputting data as expected and reading back in without crash.
Using crystaX ndk r7, on device using Jelly Bean.
Any thoughts on why this crashes on Android?
EDIT: Update to this. According to boost aficionados, I was wrong in my assumption that Boost is incompatible with the most recent official release of the Android NDK. If user config files are properly defined, boost ought to compile just fine against the latest.
Instead, I hear rumblings that boost iostreams routinely crash with the Kit.
This really isn't an answer; I haven't found / can't find one of those. All I can recommend is that you simply not try to do what I am doing. At least, not with android NDK r8d.
After looking into ways to properly configure Boost to build without wchar support, which the NDK somewhat half-asses, code that works on windows crashes somewhere within the serialization / archive library in boost. I don't know where.
So yes, the answer is 'give up, preferably before wasting four months tracking solutions'.
Why and when should I use the android Logging? Should it be used only for debugging purposes? It seems to me that if kept in a production application, it would slow it down considerably.
One key part of my question, is WHEN it should be used...in what cases should I need it? Are there any 'best practices' for using this?
This may be a very stupid or amateur question, but I've never understood the need or felt compelled to use it. I may be missing something.
http://developer.android.com/reference/android/util/Log.html
Also - I already know that logging for errors/verbose/info/etc are different, and some are discarded when not debugging. Please don't reiterate the information that's in the class overview without giving me an explanation why. Thanks!
I agree with you, I never really used it either. I much prefer debugging over log reading (and unit-testing over debugging), when trying to figure out what's happening and getting an error.
Some people argue it can be useful to log "additional details" when your application crashes and get an exception, but I usually reply to them that the exception itself should hold that additional details when necessary, and expose them in its getMessage. Thus, the default stack trace that's included in the LogCat is more than enough to see what's going on.
But anyway, it's always nice to have the possibility to log something, even though I haven't found it really useful so far, you never know when it might help :)
Regarding my comment, see Preparing for Release. (Showing logging should be removed before release, hence not being used in production).
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option before you build your
application for release. You can deactivate logging by removing calls to Log methods
in your source files.
I used logging the other day, I fired off another thread to do some work but I needed to check some data being produced in the thread, without logging or displaying Toast's, how could I get the values? I'm tried debugging/stepping through code in Eclipse before and just run into several problems.
With logging, I can log each value, view the logcat and know exactly what my code is doing.
You usually debug only when you know there is something wrong. (And when you know, you might write additional test cases.)
With logging (at the INFO level, for example), you can add some additional information to trace the data in the app. This allows you to find out that there is something wrong.
Thus, it adds a higher-level overview.
Additionally, it can be easily disabled, does not slow the app down significantly (if done right), and might thus offer another avenue of approach to see if everything works correctly, with few disadvantages and some advantages. (See also Logging vs. Debugging, especially the links in #smonff's answer.)
any best way to debug exception unless using logcat since the overall code are very big? do u think using break point to view the value if installing apk into actual android phone and running it on the phone via usb cable?
do u think using break point to view the value if installing apk into actual android phone
If this means, 'can you debug using breakpoints on the actual phone?'. The answer is Yes
Here is a tutorial you can follow
The size of the codebase is mostly irrelevant when trying to find the cause of an exception (It might complicate things a little, but in general the procedure is the same as debugging a small application). Debugging is the most efficient way of finding bugs, because you're running directly inside your application and you will not have to speculate about the current state of your application (you can actually look at it).
I suggest that you...
Get familiar with Eclipse debugging
Read the stacktrace
Try to find the exact line in the code where the exception happened (according to the stacktrace)
Set a breakpoint at the exact line or at the beginning of the method
Restart you application and wait until you hit the breakpoint
Inspect the variables using the tools in Eclipse
Hope that helps.