godot: Threads do not output errors to debugger

Godot version: v3.0.2.stable.official

OS/device including version: Linux/Ubuntu 1710

Issue description:

When a Thread encounters an error it silently fails, killing the thread without outputting any error to the debugger.

Steps to reproduce:

  1. Start a new thread
  2. Do something to produce a runtime error (not a parser error)

Minimal reproduction project:

var t = Thread.new()

class abc:
	func _init(param):
		pass

func called_from_thread(userdata):
	print("producing errors")
	nonexistent_func()
	abc.new()
	print("this will not print. thread is dead without outputting errors.")

func _ready():
	t.start(self, "called_from_thread")
	#abc.new() #Normally outputs to debugger: Invalid call to function 'new'

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 6
  • Comments: 16 (11 by maintainers)

Most upvoted comments

@BigZaphod Hey there.

First of all, I understand why you choose this tone and how frustrating it is to debug something for hours. We all appreciate the effort, and it seems to be a good and thorough research. Closing duplicate reports, though, is a necessity. It avoids diluting the attention and the discussion across multiple threads, and it also points you, the reporter, to the right place to put your report in.

It’s important to keep things in one place. One issue with many upvotes from other users, with more reports, with good reports is better than multiple issues that get lost in the sea of issues. We don’t hold it against you if you open a duplicate issue. Nobody is blaming you, you have not made a mistake. Maybe the closing comment was a bit curt (and we’re working on that), but its purpose was solely to help you and everyone else affected to build a really good case for this issue that plagues you.

As for not fixing an issue in multiple years, well, that’s the nature of development, any development. Things get different priorities, different areas receive interest. This is true even in private companies and their products. Some bugs get stale and stranded for years. Godot’s development is very liberal as we value the enthusiasm of our contributors. So on top of that we also don’t pressure anyone to work on anything they don’t want to work on. Some people are hired to work on various areas, by the organization or by third parties, and they have obligations to their employers. But most are here because they want to, and they dedicate as much time as they want to, and they focus on areas that they want to.

I think what @AThousandShips wanted to point out is that the tone of entitlement to a fix is not appropriate here. Godot is provided as is, as per license and per common sense. We can’t guarantee that issues affecting you personally are going to be solved in a timely manner, unless you want to work on it yourself. But we also can’t guarantee that we will review it in a timely manner, or that we will accept your work, even if you’ve spent many hours on it. It sucks, but it’s why we ask to discuss solutions before working on them. In any case, nobody can guarantee you a fix. And I don’t believe that in good faith you can provide me with an example of a software or a product that can guarantee you that.

So, in short, I’m sorry for the curt reply, and I’m sorry for our project giving you frustrations. I hope there can be a solution found for the reported issue. But in the mean time, take care and I hope you can find what you are looking for.

@BigZaphod Please follow the code of conduct

Feedback is always welcome but keep your criticism constructive. We encourage you to open discussions, proposals, issues, and bug reports. Use the community platforms to discuss improvements, not to vent out frustration. Similarly, when other users offer you feedback please accept it gracefully.

I just filed a bug #76030 that was almost immediately marked as “duplicate” and linked to this one. This bug is FIVE YEARS OLD. I can’t believe how much extra time this bug helped me waste while hunting down a different threading bug (#75873). It’s consumed most of a week! The fact that this has been known this long and has apparently seen no action is pretty discouraging. Could we at least print something to the console when there’s a GDScript error on a thread? An imperfect solution such as that would have saved me (and probably lots of others) so many hours as we wait on the “perfect” implementation.

Debugger not supporting threads is a long-known bug that was supposed to be fixed long time ago, but gets delayed for reasons. There was more discussion here: #2446

There’s a PR that solves this (#64364), but there is a disagreement about the implementation.

@BigZaphod If you want my feedback, then I think that a constructive thing to do in this situation would’ve been to copy all this information that you’ve laid out there to this issue, as a new comment. We can close a duplicate issue, but we can’t move comments or merge issues together. There are just no such moderation capabilities on GitHub. So it’s up to you to do that, unfortunately.

So you could’ve just copied over that report, and the discussion could’ve continued here. Instead you posted an angry comment about how you were unappreciated and how the issue is neglected. That right there, IMO, was unnecessary, didn’t help the discussion and prompted this chain of replies instead.

You were referred to the Code of Conduct because it asks everyone to act professionally and be respectful. I understand, that some users see GitHub as just another platform to lay out their frustrations, but for maintainers and contributors this is a work platform. Angry complaints are not helpful or constructive. Unlike many other users you actually had a constructive thing to add to this issue here. It’s unfortunate that you didn’t see this as an opportunity to reinvigorate the discussion.

Again, I understand why you had an emotional response to your report being closed. But the only way forward here is to not take such situations close to heart and to find a way to continue the dialog. A closed issue is not a closed and locked door. It’s a formality for us to maintain the project. It is not a reflection of your actions.


So, how about I hide all this discussion as offtopic and you repost your report from the other thread here?

I can also confirm this issue on my end. I’m pretty sure it’s related to #2446 as they all hit the same debugger issue. It’s too bad that it’s taken so long to get resolved. This is a pretty big problem in my honest opinion. Having threads die silently is a pretty hard issue to troubleshoot.