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.
Related
I'm trying to call ffmpeg.c to trim a video based on this code 'video-trimmer'. So when I try to run the activity (that loads and uses the native lib) the first time I click trin it works and I could trim the video but when I try to run it again it crashes (and it only work with the application restarts).
So I spend three days looking for a solution for this issue, most of the answers says the issue with the static variables in ffmpeg.c and creating a lib that loads and unload the class fixes the issue (answer1, answer2). So I tried to apply the solution that is based on the answers and this github repo on the video-trimmer project but all my attempts failed.
Is there any one knows about a fork of the 'video-trimmer' project that fixes the issue?. or can anybody provide step by step answer of how to implement the solution in the 'video-trimmer' project (because I tried to follow all the solution on the web and apply them in that project but with no luck).
the problem seems to be with the initialized values (some variables are declared as global static vars, presumably for ease of access but breaks OOP principles and causes us problems like you're facing), however, there are a few ways round this that I can think of:
write a quick function to manually set the static vars back to their correct init values (quick and dirty but works). A list of methods which should not be allowed to fire off as and when they please follows:
avcodec_register_all(), avdevice_register_all(), av_register_all()
avcodec_find_encoder(), avcodec_find_decoder(), av_find_stream_info()
avcodec_open(), avcodec_close()
these could be wrapped in a boolean controlled method for example so that if they have run previously they cannot run again.
another way to control things is to manually force the variable values (by use of a class or struct to control the ffmpeg global vars) that are being re-initialised on subsequent runs, for example on running the method which currently causes the code to fail, the first step could be to manually set the variables back to their default settings so that they run correctly as at the moment I suspect you have data remaining resident between iterations, and thats what is causing problems.
you could utilse mutexes to ensure that the aforementioned methods behave more responsibly when used with threads.
Addendum:
also (at the C level) use libffmpeginvoke in preference to libffmpeg if you are going to invoke main() multiple times
forcibly invoke Garbage Collection (yep this is another 'ugly' fix) on the call to load the ffmpeg lib, which would then clean things up allowing you to call another instance
Let me know if you need something more in-depth: I can try making a test framework to replicate your problems and see where I get, although that needs access to my home PC as when I am at work I have no Android SDK.
Help us help you, please provide your implemented code or a part of it. Also Crash Log will be helpful.
Hint: Initialise ffmpeg object/thread.
Then use a call back interface. Once the VideoTrimmer gets over, give a callback.
In that callback call the destroy/kill of the ffmpeg object/thread.
May be this link can help you.
I have recently used the "android-ffmpeg-java" project from github, this is a working library, I can guarantee. You just have to implement a wrapper (test application) which will do the work.
Check this link for Source : android-ffmpeg-java
Check this link for example : android-ffmpeg-cmdline. See if you can solve on with this.
I am not sure if this will help, but C files typically have a header where you can use
ifndef
Please see the following:
http://www.cprogramming.com/reference/preprocessor/ifndef.html
Use that syntax to sandwhich the declaration in the associated .h file to ensure multiple imports don't cause a crash in the importing code.
Good Luck!
Edit: Ok, looks like that would mean recompiling ffmpeg to the .so file. You should just try to verify that it has a mechanism as described above in the codebase and try to confirm it isn't somehow being loaded twice.
While somewhat crude, a potential workaround could be to utilize/link to ffmpeg from a Service (you had better be doing that anyway) which is declared in the manifest to run in its own process rather than that of client Activities. Then have that process terminate itself - calling native exit() if needed - when the task is completely finished. Android won't particularly like that happening - it's not good practice - but you can probably make it work.
Re-engineering the library to be able to reset itself to a fresh state (or even make it entirely contextual) would be better, but for a huge legacy codebase may prove to be a large project.
Obviously with code, errors can occur anywhere. So without having try/catch blocks all over the place (which as I understand it is major overhead) how do I allow errors to bubble up to the application level and then handle them there? Or at the very least, record the error somehow for troubleshooting? I found information on an product called ACRA, but the setup instructions are geared for Eclipse projects. I am using Mono for Android in Visual Studio 2010.
That's a bit of an "It depends" question.
The appropriate handling of an errors is going to depend on what the recovery strategy needs to be, how much information you want the user to see etc.
I wouldn't worry how many Try/Catch blocks you use - just use them wherever you need to handle an error that gets thrown - if they're everywhere, your strategy is probably wrong.
It terms of logging and later interrogation, you can log caught errors using the Android.Util.Log class.
These can be interrogated (provided you're debugging on your own device) using Logcat.
There's some more info on logging and Logcat here.
Found this project that writes crash info to google docs. Android Crasher
Its pretty clear that
System.setProperty("javax.net.debug", "SSL");
does not work on Android. One uses it and gets no error. There is no documentation about what works and what doesn't. One only finds out by simply trying it and seeing that nothing happens.
What other standard SSL-related System.setProperty() methods don't work?
Clearly these don't work
System.setProperty("javax.net.ssl.trustStore", trustStoreFileName);
System.setProperty("javax.net.ssl.keyStore", keyStoreFileName);
System.setProperty("javax.net.ssl.keyStorePassword",
keyStorePassword);
System.setProperty("javax.net.ssl.trustStorePassword",
trustStorePassword);
for if they did there would not be all the frustrations with certificates and keystores that Android users have shown in this forum.
This property may not work either, but I am not sure.
System.setProperty("javax.net.ssl.keyStoreType", "BKS");
Does anyone know just what the list of SSL-related property methods that DO work on Android are? Perhaps none?
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.)
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).