Scenario:
create a .gd script (i.e. in GDScript)
Make it so that the script outputs an error to the Godot console.
More specifically: Make it so that the error is not a crash inside the low-level c++ code, but strictly something in the GDscript. For example, this kind of instruction: assert(false) .
This does not need to involve c++ in any way. Therefore in my opinion the location of this game error in the c++ codebase is irrelevant. All I want to know is in which GDScript this happened.
Yet, Godot says in which cpp file the error "occurred". Every time, it creates an extra line in the logs.
It slows down my work a lot: Every time, I need to read twice: First my brain makes me read that incorrect location (muscle memory: if the logs give you a stack trace, you look at the stack trace!). It takes one or two seconds for me to discard that line and read what's above: The "real" error with the "real" location of the problem (the GDscript).
Is there a way to not display the cpp file location whenever an error occurs in a GDScript?
It's not possible at the moment.
Related
Here is my torch.profiler output:
Some of the names I put myself, using record_function. However, things like aten::ne, I don't know what exact Python lines are calling this operation and taking up the time. Is there a way to reveal which lines are calling aten::ne, SelectBackward etc?
For aten::ne, I found through the docs that this is torch.not_equals, but I don't have it in my code anymore. It would be best if I can reveal exactly where the operations in the profiler are being called.
I am facing a problem with a program i am developing in Python 3.6 under Windows 10.
One particular command generates an unknown error, windows throws a 'program.exe has stopped working' message and the program exits.
The command is a 3d-model loader that is part of another python package (Panda3D). The crash is always associated with this command (and more particularly with a specific dll of the loader) and a particular file that it tries to open.
Since i cannot locate and therefore solve the faults in the dll (probably there is a bug there) i would like to just pass the problematic file and continue to the next one. But since python exits and i do not know the error type, the typical try, except does not work.
So, i would like to know if there is a way to predict this type of behavior in my code and prevent the program from exiting.
Many thanks for any help.
The pop-up "Program.exe has stopped working." can be caused by a variety of things and therefor there is no "one size fits all" type solution. But if you're certain that your problem is cause by a specific line of code you can always try something along the lines of :
try:
loader.loadModel("c/path/to/your/file")
except Exception as e:
print(e.message, e.args)
# your error-handling code here
Make sure the file path that you're giving to loadModel respects the following :
# WRONG:
loader.loadModel("c:\\Program Files\\My Game\\Models\\Model1.egg")
# RIGHT:
loader.loadModel("/c/Program Files/My Game/Models/Model1.egg")
Source : pandas3d official documentation
So Flow only works correctly the first time I run it, and then I have to restart my computer before it'll work correctly again.
Specifically, the problem I'm seeing is that we are using the Flow language to add type annotations to our JS code. Our linter script is setup to run flow type checking among other things. However, when I fix an issue in my code and then rerun the linter script, it still comes back with the exact same errors... BUT when it shows the piece of code where the error is supposed to be, it actually shows my updated code that's fixed.
So as an example, I had a file I copied into the project, that I didn't think I really needed, but maybe I would. So I copied it in just in case. Well then it came up with a bunch of linter errors, so I decided to just delete the file since I didn't really need it. So then I run "yarn lint --fix" again, but it's still complaining about that file, EVEN THOUGH THE FILE DOESN"T EXIST! Now interestingly, where the linter output is supposed to show the code for those errors it's just blank.
Or another example, let's say I had a couple of functions in my code:
100: function foo() {}
...
150: function bar() {}
And foo has a lot of errors because it was some throw away code I don't need anymore and so I just delete it. So the new code looks like:
100: function bar() {}
Well I rerun the linter and get an error like:
Error ------------------------ function foo has incorrect
something...blah blah
src/.../file.js
100| function bar() {}
I also tested this out on a coworker's machine and they got the same behavior that I did. So it's not something specific to my machine, although it could be specific to our project?
Note: There doesn't appear to be a tag for Flow, but I couldn't post without including at least one tag, so I used flowlang even though that's actually a different language :-( I'm assuming that anyone looking for flow would also use that tag since it's the closest.
The first time you launch Flow it starts up a background process that is then used for subsequent type checking. Unfortunately this background process is extremely slow, and buggy to boot. In linux you can run:
killall flow
To stop the background process. Then if you rerun the flow type checker, it will actually see all your latest changes.
My app seems to be leaking some allocations, at least instruments says so, but it points me to the wrong line of code.
The stack trace in the image bellow, says that btAllignedAllocDefault is leaking, but it is just a fancy malloc, so the offending line of code must be in initEngine, the problem is that double-ckicling initEngine shows the file containing iniEngine's definition but always point to some arbitrary line in the first function definition it finds in that file.
No mather where I put the supposed offending function initEngine(), Instruments points to some arbitrary line of code always in the first function it finds in the file that contains the offendig code.
I tryied deleting all the DerivedData, and building both the Release and Debug build configurations.
I've noticed, though, that Xcode never puts the .app bundle and .dSYM file in Debug-iphoneos, but always in Release-iphoneos, even when the Build location settings tell it to do so.
I'm working on a Windows Store app and I'm getting a WinRT error that doesn't really give me any information so I would like to know how to understand these sorts of errors.
Basically I get the error on the following line which is called inside OnPointerPressed:
m_gestureRecognizer->ProcessDownEvent(args->GetCurrentPoint(nullptr));
The error is:
First-chance exception at 0x76F54B32 (KernelBase.dll) in DXAML2.exe: 0x40080201: WinRT originate error (parameters: 0x80070057, 0x00000044, 0x03CEE72C).
This error didn't used to appear, the only thing I've changed is that this line is now wrapped in an if clause which tests if the current pointer's PointerId is the same as one I've stored just using == such as:
if(args->GetCurrentPoint(nullptr)->PointerId == m_UIPointerID)
I have no idea why this has started happening.
So my question is in two parts:
More generally, how do I understand what an error such as the above means?
And does anyone know this error has suddenly started happening now that I check the pointerId?
Thanks for your time.
P.S. I guess another thing that has changed is that there will already be 2 pointers on the screen (the one that gets pushed into this GestureRecognizer) as well as another one, hence the PointerId check.
"How to Decipher such an error"...
For any WinRT originate error, you can take the third address in the parameters list (in your example, 0x03CEE72C), and find a description of your error in the memory window.
While debugging, break when your error is thrown and open the memory window via Debug -> Windows -> Memory -> Memory 1
Copy and paste the address to get your "easy-to-find" error message.
As Raman said - it's good to look up the hex values shown. The first one is the memory location which won't tell you much without the symbols/source, which in this case is reported directly by Windows. Perhaps the public symbols can shed some more light on where the error came from, but the error code lookups are more helpful.
If you Bing for 0x80070057 you will find an MSDN article on Common HRESULT Values which lists
E_INVALIDARG : One or more arguments are not valid : 0x80070057
It doesn't give you all the details of course, so you're off to theorize. Perhaps you can only call args->GetCurrentPoint(nullptr) once and you should store/reuse the value? Maybe gesture recognizer is not configured correctly? Maybe the app window is not visible at the time the exception is thrown or the thread is wrong. Maybe some expected calls to gesture recognizer were missed due to filtering those out with these "if" statements.