I ran my program in Python 3.4, and it crashed. Stack trace:
Traceback (most recent call last):
[...]
File [...], line 176, in manual_setup
gammas.add((name, group_oid))
KeyError: '5733455d-ba37-48c6-b550-8f53b719310c'
Here's the code at that line. Never mind what the variables are, just that gammas is a set, as you can see:
gammas = set()
for group_oid, name, _ in self.tags:
gammas.add((name, group_oid))
By the way, name and group_oid are both str, but even if they were something unhashable, I'd get a different error.
I'm not excluding the possibility that I have something totally different going on, but before I look into weird causes I haven't even thought of yet, I'd like to know if set.add could possibly be throwing KeyError. The documentation suggests no. My knowledge of how sets work says it shouldn't. Has anyone out there seen this happen?
I checked to see if set was somehow overridden. PyCharm says it's the built-in Python set.
The only set operations that generate a KeyError are pop on an empty set and remove for an element that isn't in the set. add can't generate a KeyError.
My first guess would be that this exception is coming from the __hash__ method of name or group_oid. Inspecting those objects in a debugger could be informative. There's also the possibility it's coming from an __eq__ method.
Somehow, the Python interpreter was outputting the wrong line number and accompanying code for the error. The error was a few lines above. I should've guessed... Maybe I changed the code while it was running (How can the line numbers in my stack traces be wrong?), but I don't think I did. Anyway, it's not happening anymore.
P.S. I didn't immediately re-run and catch it because the script takes a long time to reach that point again.
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'm using Python 3.7.3 and runtime exceptions are suddenly generating the following type of error instead of the usual, handy stack trace.
(<class 'NameError'>, NameError("name 'window' is not defined"), <traceback object at 0x24857260>)
If I can't find the error based on the object name, I'm forced to add a bunch of print statements to isolate it. This is sub-optimum. I initially contacted PyCharm support regarding this but it's related to the Python instance and not the IDE so they were no help other than to tell me to "Google it". Most of what I've found on line tells me how to catch explicit exceptions via a try-catch block. But that would force me to add a bunch of try-catch blocks everywhere which were never required before when runtime errors simply spit out a stack trace complete with module and line numbers. I suspect there is some way of resolving the module/line based on the hex traceback address? But I just want my trusty stack trace back! Thanks!
Simply surrounding the code of the main module as follows fixed the first problem.
try:
app = QApplication(sys.argv)
app.setFont(QFont('SansSerif', 12))
window = MyWindow()
...
except Exception as e:
print(traceback.format_exc())
I now get stack traces on runtime errors.
Thanks,
Jeff
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
I'm trying to use Pygsr, what I'm doing wrong?
from pygsr import Pygsr
speech = Pygsr()
speech.record(3)
phrase, complete_response = speech.speech_to_text('es_ES')
print (phrase)
but I got error:
Traceback (most recent call last):
File "D:/VIV/PyCharm_project/0_WORKFILE_2.py", line 1, in <module>
from pygsr import Pygsr
File "C:\Users\User\AppData\Roaming\Python\Python35\site-packages\pygsr\__init__.py", line 30
print "REC: "
^
SyntaxError: Missing parentheses in call to 'print'
Process finished with exit code 1
The issue is that the Pygsr library seems to be written with some version of Python 2 in mind.
In Python 2, print is a statement and as such allows "softspace" in between the statement itself and the string to be printed. As of Python 3.0, print is a function and as such, requires opening and closing parentheses around the function arguments. Because Pygsr is written with some version of Python 2, it still uses the statement form of print, which is invalid in Python 3. This can be seen in the line that the SyntaxError is pointing to, which is a statement and not a function (print "REC: " vs print("REC: ")).
You've got a few options for fixing this issue:
The first option is to switch back down to using the latest version of Python 2 (which is 2.7.11 at time of writing). This will mean that anything that's not backwards compatible in 3 (but still works in 2) will function, but I don't recommend switching versions just to get a library working, especially because it will affect the code you write. As well as that, the general consensus (to the best of my knowledge) seems to be that new scripts built on 2 should use the function form of print, which is available from 2.6 onwards but can be imported from __future__ for versions before 2.6.
The second option is to use the automatic tool 2to3 to convert the scripts in the library to be compatible with 3. This won't always work 100% due to the complexity and potential edge cases that a Python script may have, but it's usually a good way to get a lot of the simpler changes out of the way quickly.
The third option is to make the changes yourself. This should be as simple as manually going through the library and fixing any references to print, but you could also find the issues by running your script, seeing which file and line number is referenced in the error and then making the required edits.
I have followed Lee Brimelow's tutorials (part 1, part 2), but somehow my project doesn't work as expected.
Currently, publishing "src/Secondary.as" to "www/assets/swf/secondary.swf" works properly, however when trying to run "src/Main.as", an error shows up:
Exception fault: TypeError: Error #1007: Instantiation attempted on a non-constructor.
at Main/init()[/Volumes/DOCUMENTS/Tests/AS3/test-workers/src/Main.as:52]
at Main()[/Volumes/DOCUMENTS/Tests/AS3/test-workers/src/Main.as:32]
If anybody has time, you can look at my code on Github and maybe see where I screwed up? Thanks a bunch!
As your error message says: the problem raised in Line 52 in your Main.init()method. What you try to do there is to create a new instance of SecondarySWF. I would say that your embedment of Secondary class into SecondarySWF doesn't work properly, so it is not available in your init-method. You should set a breakpoint at the first line of your init-method and when the debugger reaches this point check what's in SecondarySWF. I expect that there's nothing in that variable, so what your new SecondarySWF() then means actually is new null().
Because you embed your secondary.swf with a MIME-type specified the Flex compiler ignores it because it is unable to detect the actual type of data in the loaded file. I found this post on Adobe's cookbook page that explains what you have to do in addition to adding the file using [Embed]. Hope this will fit your needs.