I have tried to setup Vulkan validation layers, and after running vulkaninfoSDK.exe indeed have multiple validation layers, but I get a message in VS Code "unable to open 'stateless_validation.h': Unable to read file 'c:\j\msdk\build\vulkan-validationlayers\repo\layers\stateless_validation.h".
This message is very strange to me, as I do not even have a folder "j" on my c drive, and have in fact installed Vulkan somewhere on a completely different drive. I am running Windows, the MSVC compiler, have installed the latest Vulkan SDK from LunarG, and have set the environment variable "VK_LAYER_PATH" as recommended here: https://vulkan.lunarg.com/doc/view/1.2.131.1/windows/layer_configuration.html but indeed, the folder I have installed the SDK to does not contain a "stateless_validation.h".
My call stack is 3 functions in VkLayer_khronos_validation.dll: "StatelessValidation::validate_struct_pnext", then "StatelessValidation::PreCallValidateCreateShaderModule,", then "vulkan_layer_chassis::CreateShaderModule" called from my own function.
I notice the file "stateless_validation.h" is on the Github repo here: https://github.com/KhronosGroup/Vulkan-ValidationLayers but I would think downloading the SDK would be enough.
How can I solve this?
It seems that the error was an exception thrown inside the actual validation layer source code itself, and was due to the pNext member of my VkShaderModuleCreateInfo structure instance I was passing to vkCreateShaderModule being uninitialized.
Simply setting this to nullptr solved my issue. It seems that since the exception was thrown from inside the dll itself, my exception handling code was not catching it, which confused me.
Related
In relation to this post:
After upgrading from revit 21 to 22 in my company, we can no longer view anything else than the default 3D model in our forge viewer. Initially, i thought the issue arose due to this warning:
"Deprecated API usage: No "GlobalWorkerOptions.workerSrc" specified.".
However, i got that same message in the console of a working implementation i made today, leading me to believe that it has nothing to do with this warning at all.
However, i also see another warning:
"Warning: getOperatorList - ignoring errors during "GetOperatorList: page 0" task: "r: Cannot read properties of undefined (reading 'X')"."
I have tried creating a new nuxt app on Node version 14.9.0, implemented a forge viewer in accordance with the official v7 documentation, and the bug is no longer present.
I then tried to mimic that in my actual production app where the problem exists, by running it on Node version 14.9.0 instead of 10.0.0, getting rid of my entire forge implementation and implemented a simple viewer like above. That did not solve the problem, and i still see above warnings in the console.
The warning is thrown in pdf.worker.jss, which is loaded in via "webpack://adsk/node_modules/#adsk/pdfjs-dist/legacy/build/pdf.worker.jss".
I hope someone has a suggestion.
What I have tried (running Tcl and Tk 8.6.0 on Windows):
load D:/toot/bar/em.dll
load "D:/toot/bar/em.dll"
load D://toot//bar//em.dll
load "D://toot//bar//em.dll"
load D:\toot\bar\em.dll
load "D:\toot\bar\em.dll"
load D:\\toot\\bar\\em.dll
load "D:\\toot\\bar\\em.dll"
All of which return one of these two errors:
couldn't load library [what I put after 'load']: invalid argument
couldn't load library [what I put after 'load', rendered]: this library or a dependent library could not be found in library path
Assuming that file exists D:/toot/bar/em.dll returns truea, load D:/toot/bar/em.dll should work. However, it sounds like you've got problems with things (i.e., other DLLs) that the library depends on.
This is a general problem on Windows that has been asked elsewhere on Stack Overflow; the answers there are relevant to this question. You should also be aware that if the DLL has been linked against a specific version of the Tcl DLL (not recommended on Windows for Tcl extensions) then you need to have the same version of Tcl installed as it was linked against. Stub-enabled extensions do not have this problem at all (though they can still run into problems with other required libraries being absent).
It's a shame that the load command doesn't tell you what DLL is missing in its error message, but IIRC the underlying OS API doesn't report it either. You're stuck with using an external tool to diagnose these things…
a Don't worry about backslash/forward-slash issues; Tcl handles those for you.
I have this problem, too,couldn't load library "ChariotExt": invalid argument.
And sovled it by change tcl version x64 to x86.
I'm trying to work with the Java sample Database program from the CardScan SDK.
I am working with files located in Java/JNI and Java/Database. The program must be run with a 32 bit JRE. I was able to do so on a 64 bit machine by uninstalling Java and installing the 32 bit version, then re-adding the system path for Java. I can run the program and interface with a CardScan database file (.cdb) successfully by double clicking the SDKData.bat file, but when I open the source files for editing and edit the Java.library.path to include the required library (CRTK_JNI.dll), I get UnsatisfiedLinkErrors everywhere:
Exception in thread "main" java.lang.UnsatisfiedLinkError: sdkdata.CRTK.CRTK_Init([I)I
at sdkdata.CRTK.CRTK_Init(Native Method)
at sdkdata.CRTK.(CRTK.java:239)
at sdkdata.SDKData.(SDKData.java:97)
at sdkdata.SDKData.main(SDKData.java:643)
Java Result: 1
Presumably this is happening because the library is not loading properly.
What do I need to do to run and edit the program at full capacity (with all the native functions from CRTK_JNI in working order)?
Presumably this is happening because the library is not loading properly.
On the contrary. The library load is complete. You aren't getting that from a System.load()/loadLibrary() call, you are getting the error when calling your native method, the one that should have the signature:
package sdkdata;
public class CRTK
{
public native int CRTK_Init(int[]);
}
So it isn't there, or you have changed the signature without regenerating the .h and .c files, or you have manually mangled the declaration some other way.
Post your code.
To clarify, this Java sample program is officially unsupported by the CardScan API - it was a bad idea to try to use the API with an unsupported language relying solely on an experimental implementation. I ended up using one of the supported languages (Visual Basic) to work with the SDK; if anyone looking at this question happens to be struggling with using the CardScan API, here is my VB implementation on Github.
I just changed my sandboxed app's bundle identifier, and ran it. I get a runtime exception before main() even runs. The top of the stack trace is runtime_init. I tried running the app outside of Xcode and got the standard crash report dialog. Scrolling through the information presented, I noticed:
Application Specific Information:
dyld: launch, running initializers
/usr/lib/libSystem.B.dylib
xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The operation couldn’t be completed. (Cocoa error 13.)
As soon as I run another time, there's no problem. I see that the container exists. As soon as I remove the container, though, the exception gets thrown again. I don't want my users' first experience with my app to be a crash. How can I fix this?
I tried repairing permissions, which made no difference. I also noticed that by the time Xcode breaks on the exception, the container has already been created. Also, Craig Hockenberry mentioned this error in a blog post, but he blamed symlinks in the user's Home directory. I don't have any symlinks there (not in the top level, at least, which is what I assume he means).
Additional input on Twitter suggests that it can be a symlink anywhere, in which case I definitely do have some. Has anyone discovered a workaround for it? I suppose that would be tough, as no application code executes before the exception. Hopefully Mountain Lion will fix it...?
Finally solved this crash by removing everything from the Desktop, Documents, Downloads, Movies, and Pictures user directories. I assume it's related to the sym link issue mentioned in other threads.
When you link to an unmanaged library (say 'A.dll') which in turn links to another library ('B.dll'), and B.dll is missing, you will get a run-time error message about failing to load 'B.dll'.
But when you P/Invoke into 'A.dll' from managed code, you'll get a general exception of this form:
Unhandled Exception: System.DllNotFoundException: Unable to load DLL 'A.dll': The specified module could not be found.
How can I get an error message that pinpoints the specific unmanaged dll file that failed to load, when p/invoking from managed code ?
I don't think there's any specific API you can use to pinpoint why LoadLibrary (the underlying Win32 API) failed for 'A.dll'. I recommend the use of a tool like Dependency Walker to troubleshoot DLL loading errors.
I'm not sure how you can get this in the form of an exception. When I run into this problem I usually try and open the DLL with depends.exe. It's pretty good and reporting missing dependencies that exist if the DLL is simply loaded from it's current location.
You won't be able to get an answer from the exception, but you can do it (with a lot of work) through Process Monitor. This article discusses how and also includes a tool to scan Process Monitor logs to find the specific problem.
http://tech.blinemedical.com/debug-could-not-load-file-or-assembly-or-one-of-its-dependencies/
The Fusion Log Viewer is a good tool to debug assembly loading problems in .NET apps.
For identifying general file-load problems, you can use Process Monitor.