I ran into a debugging issue in a prod environment with Unity Unity 2022.1.24f1 and WebGL. When an exception occurs, I get an unreadable stacktrace. Something like this:
Invoking error handler due to
RuntimeError: unreachable
at wasm://wasm/0785b666:wasm-function[985]:0x98818
at wasm://wasm/0785b666:wasm-function[544]:0x89330
at wasm://wasm/0785b666:wasm-function[8670]:0x24dccf
at wasm://wasm/0785b666:wasm-function[1922]:0xbf4e5
at wasm://wasm/0785b666:wasm-function[28368]:0x812a8b
at wasm://wasm/0785b666:wasm-function[86902]:0x14c5d3c
at wasm://wasm/0785b666:wasm-function[557]:0x898ed
at wasm://wasm/0785b666:wasm-function[77488]:0x1326327
at wasm://wasm/0785b666:wasm-function[5230]:0x171c41
at wasm://wasm/0785b666:wasm-function[10658]:0x2feb0d
at wasm://wasm/0785b666:wasm-function[104320]:0x178c493
at invoke_iiii (blob:http://localhost:8080/eef1af57-52ea-407d-b414-b8a770143494:3:408461)
at wasm://wasm/0785b666:wasm-function[2104]:0xc4fc3
at wasm://wasm/0785b666:wasm-function[24046]:0x7aace3
at wasm://wasm/0785b666:wasm-function[990]:0x989d5
at wasm://wasm/0785b666:wasm-function[21506]:0x561c30
at wasm://wasm/0785b666:wasm-function[51389]:0xd496a6
at wasm://wasm/0785b666:wasm-function[109425]:0x18f3801
at wasm://wasm/0785b666:wasm-function[108044]:0x1853d4c
at wasm://wasm/0785b666:wasm-function[23913]:0x79ec70
at wasm://wasm/0785b666:wasm-function[23913]:0x79ece1
at wasm://wasm/0785b666:wasm-function[21361]:0x554206
at wasm://wasm/0785b666:wasm-function[104316]:0x178c45d
at browserIterationFunc (blob:http://localhost:8080/eef1af57-52ea-407d-b414-b8a770143494:3:229388)
at callUserCallback (blob:http://localhost:8080/eef1af57-52ea-407d-b414-b8a770143494:3:182585)
at Object.runIter (blob:http://localhost:8080/eef1af57-52ea-407d-b414-b8a770143494:3:183845)
at Browser_mainLoop_runner (blob:http://localhost:8080/eef1af57-52ea-407d-b414-b8a770143494:3:182120)
I can't enable debug symbols mode for prod environment, is there any algorithm to translate this stack trace to real method names?
I found out, that Library\Bee\artifacts\WebGL\il2cppOutput\cpp\Symbols\MethodMap.tsv file has all method names from my app, but I didn't found any relations between those method names/their serial number and numbers in stacktrace.
MethodMap.tsv contains the relationship between c# and c++ functions. This is the first stage of compiling to WASM. The second step creates in build directory a file .symbols.json (for Unity 2021 and newer, in older versions it has a different name). It contains the relationship between c++ and wasm functions. But to get this file, you need to set "Debug symbols" in "Publishing settings" to "External" value.
Related
I try do debug a blazor webassembly app, that references a shared project named Test.Shared. I've been trying to set breakpoints in that projects code but nothing helped - breakpoints just aren't hit.
When I'm trying to set a breakpoint outside in the calling code and then step into "Test.Shared" source - it just seems to go step by step through the underlying code (I have to hit "step forward" multiple times before it proceeds the debugging to the next line, and the number of hits changes when I reduce/increase the number of lines in the underlying method code) but its not displayed in the debugger window.
So, after some investigation, I figured out that I can make the debugger work when I throw away all the code from the Test.Shared and leave only one simple test static method. Based on this fact I guess there is some specific type of C# code that causes the whole containing library to be invalid for debugging.
Any suggestions what this code type might be?
The environment I use:
Visual Studio Enterprise 2019 16.6.2
NET Standard 2.1 as a target platform for both Blazor app and shared library
NET Core 3.1 as a target platform for the hosting web app that serves webassembly app packages
Microsoft.Components.WebAssembly 3.2.0
The issue is with having attributes that have enum values inside of them.
Many people are having this problem and it's better explained in Blazor Wasm: debugging broken when referencing #attribute with enum contructor argument #25380 by zbecknell:
Here's a simple repro project: https://github.com/zbecknell/Undebuggable.
See Counter.razor:4 for the line that breaks debugging for the project:
#* The following line breaks debugging for the project, no matter how long you wait *#
#attribute [BadAttribute(BadEnum.Default)]
I am working on a legacy Windows Forms application using VS 2008 under C++ and face a weird problem. The form uses an ImageList object, to which two bitmap images have been added. At run-time, I get the following error in Debug mode (in the Release mode, the application just doens't launch):
An unhandled exception of type 'System.Resources.MissingManifestResourceException' occurred in mscorlib.dll
Additional information: Could not find any resources appropriate for the specified culture or the neutral culture.
Make sure "MyApp.Form1.resources" was correctly embedded or linked into assembly "MyApp" at compile time,
or that all the satellite assemblies required are loadable and fully signed.
The crash occurs at the first line of this block:
this->imageList1->ImageStream = (__try_cast<System::Windows::Forms::ImageListStreamer* >(resources->GetObject(S"imageList1.ImageStream")));
this->imageList1->TransparentColor = System::Drawing::Color::Transparent;
this->imageList1->Images->SetKeyName(0, S"Nok32.png");
this->imageList1->Images->SetKeyName(1, S"Ok32.png");
This is pretty puzzling, because I copied the application from an existing one which works fine. I just changed the namespaces. And if I remove the two images from the list, the application works.
I found several posts on forums about this or similar problems, but none could really help me. I don't think that Visual Studio can be blamed. I tried with frameworks 2.0 and 3.0, to no avail. Fully comparing the sources of both applications, I can't see a significant difference.
Any hint ?
Solved: there was an old namespace left in the project file (.vcproj) !
I'm trying to use ros in cpp with Visual Studio 2012. I wrote the publisher and subscriber tutorial (http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber%28c%2B%2B%29) and first, I configure the project as says in the guide (http://wiki.ros.org/win_ros/hydro/Msvc%20SDK%20Projects).
Then i compiled an linked the publisher, but when I tried to run it, ros::init(argc,argv,"talker") throws an exception... The console says that I ROS_MASTER_URI is not defined but I've got it defined
There are 2 images here:
https://www.dropbox.com/s/o12m0l38gaxiugi/error1.png -
https://www.dropbox.com/s/ocdmf0wj6rj0962/error.png
Can anyone helps me?
Thanks in advance
So, I had the same issue, although I didn't set the ROS_MASTER_URI globally.
I managed to get around this specific issue by adding
ROS_MASTER_URI=http://localhost:11311
to the debugging environment variables (Project->Properties->Configuration Properties->Debugging->Environment).
However, after implementing the above I got an uncaught exception (Unhandled exception at 0x768bc41f in ros_demo.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0028f0e4..).
That went away when I built, compiled and ran the project in release mode (which matched my ROS SDK build).
I got the idea for the release/debug build from here:
xstring isn't an OSG specific object, so the error is elsewhere in the
3rd party dependency chain. As I know nothing about your OS and
software setup I can't speculate what this might be.
In general though this type of error could well be a linking issue -
for instance Visual Studio is hopeless at handling different libs
being built debug and release and will crash randomly.
That was fun to discover..
I have a cocos2d-iphone project. When I run the project on simulator I don't get any error. But if I try to profile it I get multiple errors in OpenGl functions found inside CCParticleSystemQuad.m file. To make it clearer I'm posting the snapshot of the error zone.
Here's the link to the image in case you want to see it closely.
Do you have any clues?
offsetof is a macro that resolves to an LLVM compiler builtin function. It's defined in stddef.h, but it's possible your project's headers don't include that file when building for a device.
This I think is related to my use of the nlog C++ API (and my question on the nlog forum is here); the purpose of my asking this question here is to get a wider audience to my problem and perhaps to also get some more general ideas behind the VB6 IDE's failure to build in my particular scenario.
Briefly, the problem that I am having is that I am having trouble building VB6 components which reference unmanaged C++ components which have calls to nlog's C\C++ API (which is defined in NLogC.DLL). The build problems are not occurring during compile time, they are occurring when the binary is being built which suggests to me that it's some kind of linker type problem? Don't know enough about how VB6 binaries are produced to tell. The VB6 binary is produced, but it is corrupted and crashes shortly after it is invoked.
Has anyone had any similar experiences with VB6 (doesn't have to be related to nlog or C++)?
edit: Thanks for all the responses to this rather obscure problem. Still no headway unfortunately; my findings since I posted this:
'Tweaking' the compile options doesn't appear to help in this problem.
Adding a reference to the nlog-enabled C++ component from a 'blank' VB6 project doesn't crash it or cause weird build problems. So it isn't a 'native' VB6 issue, possibly an issue with the interaction between nlog and the various components and 3rd party libraries used by other referenced components?
As for C++ calling conventions: the nlog-enabled C++ component is - as far as I can see - compliant to these conventions and indeed works fine when referenced by VB6 as long as it is not making any nlog API calls. Not sure if the nlogc.DLL itself is VB6 compliant but I would have thought that that is immaterial since the API calls are being made from the C++ component; VB6 shouldn't know or care about what the C++ component is referencing (that's as far as my understanding on this goes...)
edit2: I should also note that the error message obtained during build is: "Errors during load. Please refer to "xxx" for details". When I bring up the log file, all that there is in there is: "Cannot load control xxx". Interestingly, all references to that particular control disappears from that particular project resulting in compile errors if I were to try to build again.
Got around the problem by using NLog's COM interface (NLog.ComInterop.DLL) from my unmanaged C++ code. Not as easy to do as the C\C++ API but at least it doesn't crash my VB6 components.
I would try tweaking some of the Compile options found in the Project, Properties menu, Compile panel to see if they yield any additional hints as to what is going wrong.
For example if you compile the executable to p-code rather than native code does it still crash on startup.
What error message do you get when you run your compiled binary?
I doubt the compiler/linker is the problem: project references in a VB6 project are not linked into the final executable. A project reference in VB6 is actually a reference to a COM type library (which may or may not be embedded in a .dll or other binary file type). Project references primarily serve two purposes:
The IDE extracts type information from the referenced type libraries which it then displays in the Object Browser (and in the Intellisense drop-down)
At compile-time, the compiler extracts the type information stored in the referenced libraries, including the CLSID of each class that you instantiate, and embeds this data into the executable. This allows your executable to create instances of classes contained in the libraries that you referenced.
Note that the compiled binary doesn't link to any code in the referenced libraries, and it doesn't even contain the filenames of the referenced libraries. The final executable only contains the CLSID's and other type information that it needs to instantiate COM objects at run-time.
It is much more likely that the issue is with NLog, or with how you are calling it from your code, rather than something gone awry in the VB6 compile process.
If you think it might be a linker problem, this should crash it the same way:
create a new standard project (of any kind)
add a new module and copy the "declare"-statements into it
compile
If it doesn't crash it is something else.
It would help an exact description of the error or a screenshot of what going on.
One thing to check is wherever NLogC.DLL or the C++ DLL you built have the correct calling convention defined. Basically you can't have the DLL function names mangled or use anything but the STDCALL calling convention. If the C++ DLL has not been created with those two things in mind then it will fail to work with VB6.
MSDN Article on Calling convention.
"Cannot load control xxx" errors can be caused by .oca files which were created from a different version of an .ocx than currently used. If that is the case, deleting the .oca files helps.