Threads do not output errors to debugger

[krogank9]

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'

[akien-mga]

Might be related to #2446.

[supercom32]

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.

[KoBeWi]

Still valid in 02f7908

The provided example code throws parsing errors, here's a better one to test:

var t = Thread.new()

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

func _ready():
    t.start(self, "called_from_thread")

[Calinou]

I heard reduz wants to implement debugging support for threads in 4.0. It will probably require significant changes and most likely won't be cherry-pickable for 3.2.

Edit: It's not planned for 4.0 in the end.

[pseidemann]

bug still exists in v3.5.1.stable.official [6fed1ffa3]

[isaaccp]

Just ran into this and it made debugging pretty hard. Now that I am aware of this it won't be as bad, but still wish this was better.

[BigZaphod]

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.

[AThousandShips]

@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.

[YuriSizov]

@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]

@YuriSizov thanks. This is the second time I've butted heads with @AThousandShips (and you've had to step in) over what amounts to the tone of feedback, I guess?

I'm aware of the nature of software development and how bugs can sit for years unaddressed (I'm guilty of plenty of that myself). My above comment may have sounded like I felt I was entitled to a bug fix immediately or something. I understand that's not possible or practical, of course. What I was trying to bring to light, perhaps badly, was that there really hasn't been any discussion on this bug about how such an old and devious issue be affecting the user experience. That, I think, is the feedback I was trying to provide. My own bug was closed and so no further discussion could happen there, so I came here to try to note that.

Instead what I see as having happened is that my usability feedback was rejected. There wasn't even an acknowledgement (initially) that I did actually include some constructive feedback: I suggested to print an error in the console, at least! Instead I was accused of code of conduct violations. This feels to me that perhaps the project doesn't care how users feel or how much time they waste when using the engine which comes across as a bit callous, but I'm sure that's not the intent.

I get that most of us are here doing things with Godot without getting paid for it, but IMO it's important to remember that includes people like myself who are trying to help by taking time to document and identify issues so they can get logged, tracked, discussed, and hopefully fixed someday. Even worse - I was pretty proud to have found this bug at all, but now I'm shattered and discouraged and thinking about never filling an issue again.

My feedback here is that this issue has swallowed up dozens of hours of my time - and it was first identified years ago! In that time I can't imagine how many other people have encountered this knowingly or unknowingly and how demotivating it may have been. I believe it's important to acknowledge that fact. It might not be a flashy bug, but it has ramifications that shouldn't be ignored. Indeed, how is a bug like this supposed to gain any traction or get on roadmaps if people can't talk about how it affects them? The nature of this bug isn't going to change - it's just going to stay and silently affect people unless someone points it out.

[AThousandShips]

I am sorry that my tone felt bad, I was trying to point out that your attitude was not constructive and violated the quoted paragraph in the code, and that it's not constructive to react this way to being told that a bug had already been reported, I did not feel that we were butting heads but rather that I was asking nicely that you follow the code, and I am sorry that my tone was too blunt, it is the way I speak, as you have your way of speaking

[YuriSizov]

@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?

[KoBeWi]

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.

[Calinou]

Regarding printing from a thread, it may not be trivial to do this, especially if you want the printed message to show up in the editor Output panel. Otherwise, it'll only be visible when running Godot from a terminal/command prompt – which isn't easy to discover for users.

It may still be worth looking into – maybe it's easy to just show a generic "A Thread has crashed" message, but anything more may be difficult.

PS: Is there a way to give a thread a name to improve debuggability? I think operating systems provide something similar for native threads.

[Leshy-YA]

This has been a thing since 2015. Now that Godot is getting more support for multi threaded operation this would be really nice to have fixed. Is there anyone left who makes single threaded projects nowadays?

[akien-mga]

This is in progress, see #76582.