godot 🚀 - Breakpoints do not work in Thread

debugging only works on the main thread, thread debugging will be
implemented soon

On Mon, Sep 7, 2015 at 10:30 AM, ret80 [email protected] wrote:

Breakpoints do not work in Thread!

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446.

reduz on 7 Sep 2015

😄1

as soon as it is when? and a version?

ret80 on 7 Sep 2015

soon to me is 2.1 likely (it's on my list for that version), early next year

On Mon, Sep 7, 2015 at 12:29 PM, ret80 [email protected] wrote:

as soon as it is when? and a version?

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446#issuecomment-138325522.

reduz on 7 Sep 2015

This is a very long time, given that the possibility of debugging is the most important feature.
Maybe we should reconsider the priority of this task?

ret80 on 7 Sep 2015

Generally, I manage feature priorities according to amount of users
requesting them. I try to not ignore anyone, but we are almost close to a
beta now and you are the first that asked for this. Can't you use prints
for now until this is available?

On Mon, Sep 7, 2015 at 12:41 PM, ret80 [email protected] wrote:

This is a very long time, given that the possibility of debugging is the
most important feature.
Maybe we should reconsider the priority of this task?

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446#issuecomment-138327223.

reduz on 7 Sep 2015

I was looking a bit that users ask for. They ask, "Unreal". But it already exists! Here is a link "https://www.unrealengine.com/blog". And to be honest, very surprised why no one is asking what really facilitate the work of programmers. I was just wondering how to "okamstudio" debug game? With prints ?! It's a nightmare. Today I was setting on all code print and watched what was going on there for me. And it's just hell.
By the way you have in this version there is a clause that says that debaging will be improved. I was hoping that it would improve not partially but completely.
As for the next release. What to do with this release, even if there is not a full debug ?! It would just be the next release which will make demos like my shooter. Because it is difficult to do something else. The more the more difficult to debug code. Godot is already quite suitable for creating 2D games. It remains only to fix bugs and debaging tie. You do not need the new features and new technologies. It's plenty of time.

ret80 on 7 Sep 2015

Dude just be patient and wait a few months, Godot development is already
very fast and I really have a huge amount of work on my plate. Soon you
will be able to fund development so I can dedicate more time to it and get
things done faster, I hope you contribute :)

On Mon, Sep 7, 2015 at 5:09 PM, ret80 [email protected] wrote:

I was looking a bit that users ask for. They ask, "Unreal". But it already
exists! Here is a link "https://www.unrealengine.com/blog". And to be
honest, very surprised why no one is asking what really facilitate the work
of programmers. I was just wondering how to "okamstudio" debug game? With
prints ?! It's a nightmare. Today I was setting on all code print and
watched what was going on there for me. And it's just hell.
By the way you have in this version there is a clause that says that
debaging will be improved. I was hoping that it would improve not partially
but completely.
As for the next release. What to do with this release, even if there is
not a full debug ?! It would just be the next release which will make demos
like my shooter. Because it is difficult to do something else. The more the
more difficult to debug code. Godot is already quite suitable for creating
2D games. It remains only to fix bugs and debaging tie. You do not need the
new features and new technologies. It's plenty of time.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446#issuecomment-138369395.

reduz on 7 Sep 2015

I can not say to people that make a project that you need to wait until next year. Most of all, I just have to change the engine. It takes less time. I will follow the developments.

ret80 on 7 Sep 2015

It's a shame that Godot does not currently provide a feature you need and
that there is no way for you to do a workaround.
I hope you understand that you are not the only Godot user and being that
every user has different needs, I have to attend the most requested ones
first. If you want to accelerate or prioritize some parts of the
development, you will soon be able to use funds for this :)

On Mon, Sep 7, 2015 at 5:49 PM, ret80 [email protected] wrote:

I can not say to people that make a project that you need to wait until
next year. Most of all, I just have to change the engine. It takes less
time. I will follow the developments.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446#issuecomment-138375860.

_OkamStudio_

godotengine on 7 Sep 2015

I think very few people use threads, that's why it's not a very requested
feature, and we have a habit of using prints to debug instead of
breakpoints, even on the main thread (I don't think I've ever used them,
although I rely on the debugger breaking when there's an error, and I miss
that when my threads need to break). On Android (and other closed
platforms) there's not even a good debugger for native code, and you have
to debug stupid dangerous shit like jni with prints. Which is not an excuse
to not have a better debugger, I'm just saying it's possible.

On 7 September 2015 at 23:05, Okam Studio [email protected] wrote:

It's a shame that Godot does not currently provide a feature you need and
that there is no way for you to do a workaround.
I hope you understand that you are not the only Godot user and being that
every user has different needs, I have to attend the most requested ones
first. If you want to accelerate or prioritize some parts of the
development, you will soon be able to use funds for this :)

On Mon, Sep 7, 2015 at 5:49 PM, ret80 [email protected] wrote:

I can not say to people that make a project that you need to wait until
next year. Most of all, I just have to change the engine. It takes less
time. I will follow the developments.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/2446#issuecomment-138375860
.

_OkamStudio_

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446#issuecomment-138377136.

punto- on 7 Sep 2015

Correct least https://github.com/okamstudio/godot/issues/2418 && watch https://github.com/okamstudio/godot/issues/2438
please!
very necessary

ret80 on 8 Sep 2015

sorry, you are pretty bad at reporting bugs. I really wish you added more
context, as I'm not a magician that can read your mind

On Tue, Sep 8, 2015 at 9:42 AM, ret80 [email protected] wrote:

Correct least #2418 https://github.com/okamstudio/godot/issues/2418 &&
watch #2438 https://github.com/okamstudio/godot/issues/2438
please!
very necessary

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/2446#issuecomment-138548361.

_OkamStudio_

godotengine on 8 Sep 2015

Not critical for the upcoming 2.1, so moving to the next milestone.

akien-mga on 15 Jul 2016

Working with threads and TCP here, please bump this feature request. I can't program in C++ so I will not be able to contribute in this one.

jahd2602 on 9 Aug 2016

I never bothered to say anything, but after seeing how long this issue has been around, I decided to write in just to let developers know there are people who care about this issue greatly (But may not have been vocal about it).

I think we can all agree that multi-threading in applications is notoriously tricky, even in the best of times. Not having proper debug/breakpoints just makes it that much more difficult to work with. Sure you can add "print" statements everywhere, but it won't help you if you can't easily inspect variables at runtime, or if for some reason your "print" doesn't render because something else is causing a problem and blocking it.

Essentially the only workaround we have right now is to just add "prints", wait until it doesn't render anymore, and then try to look at the lines which are causing it to die. And if you want to inspect variables or objects, cram them all out to console before your code dies.

supercom32 on 25 Apr 2017

👍2

Should make the debugger multithreaded.. I guess it does need to be done..
will add to todo list for 3.1

On Apr 25, 2017 5:29 PM, "supercom32" notifications@github.com wrote:

I never bothered to say anything, but after seeing how long this issue has
been around, I decided to write in just to let developers know there are
people who care about this issue greatly (But may not have been vocal about
it).

I think we can all agree that multi-threading in applications is
notoriously tricky, even in the best of times. Not having proper
debug/breakpoints just makes it that much more difficult to work with. Sure
you can add "print" statements everywhere, but it won't help you if you
can't easily inspect variables at runtime, or if for some reason your
"print" doesn't render because something else is causing a problem and
blocking it.

Essentially the only workaround we have right now is to just add "prints",
wait until it doesn't render anymore, and then try to look at the lines
which are causing it to die. And if you want to inspect variables or
objects, cram them all out to console before your code dies.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/2446#issuecomment-297068469,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21daddK2C6iP82fWckFpG4H6gZxHks5rzhFigaJpZM4F4-f3
.

reduz on 25 Apr 2017

Do not panic! This problem will be solved a little earlier than never! (Sarcasm) :)

ret80 on 25 Apr 2017

😕5

I dunno if this is the same issue or not, but I also noted that if your thread has an exception, such as you misspelt a method name, it just quietly does nothing and doesn't give you an error.

It took a lot of "prints" to find out where it was getting killed. :-)

supercom32 on 7 May 2017

@supercom32 It's the same issue.

neikeq on 7 May 2017

I really don't want to be toxic or anything - but how is GoDot supposed to be more than a Snake-Game-Engine? It's 2018, single thread architectures are not even a good idea for a calc.exe anymore. No errors raised, no debugging, just prints for other threads than the main thread? Would switchting to C# and VS help me or should I just switch to a different engine (serious question, I'm afraid)?

letmejustfixthat on 10 Mar 2018

This is a GDScript limitation, should not be difficult to workaround, but
first needs fixing the thread ID problem. Was not prioritized due to other
more important things having more priority, but it would be nice to fix for
the upcoming version.

Also, C# should not have this problem.

On Sat, Mar 10, 2018 at 11:35 AM, letmejustfixthat <[email protected]

wrote:

I really don't want to be toxic or anything - but how is GoDot supposed to
be more than a Snake-Game-Engine? It's 2018, single thread architectures
are not even a good idea for a calc.exe anymore. No errors raised, no
debugging, just prints for other threads than the main thread? Would
switchting to C# and VS help me or should I just switch to a different
engine (serious question, I'm afraid)?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/2446#issuecomment-372034488,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z26J87DpUsV-MHXSLq5TKkUq3WdTpks5tc-TNgaJpZM4F4-f3
.

reduz on 10 Mar 2018

Wow, that was fast! Thank's - I'll give C# a shot. But seriously: A game engine without solid multi-threading features seems not to be a good idea at all, this should be added/fixed asap imho.
Regards

letmejustfixthat on 10 Mar 2018

I really don't want to be toxic or anything - but how is GoDot supposed to be more than a Snake-Game-Engine?

Sure, that's not being toxic or anything...

A game engine without solid multi-threading features seems not to be a good idea at all, this should be added/fixed asap imho.

Godot has solid multi-threading features. It's just the debugging of GDScript scripts using Thread which is not working. Sure, that's something important to fix, but it doesn't prevent making multithreaded games.

akien-mga on 13 Mar 2018

It's just the debugging

"Just"... Debugging is a fundamental feature in every serious programming language (or to be more precise: in every serious IDE), without which complex code is not maintainable at all, especially when it is running parallel.

letmejustfixthat on 22 Mar 2018

👍14

"Just"... Debugging is a fundamental feature in every serious programming language (or to be more precise: in every serious IDE), without which complex code is not maintainable at all, especially when it is running parallel.

Because no one posted any follow up, I figure I would chime in and voice my support that I strongly agree with this comment. The only reason you would be using threading is _specifically_ because your doing something complicated that you want to separate from the main thread. Deciding to go multi-threaded is a design choice that isn't taken lightly, so people normally will have very strong and compelling reasons to do so. Regardless of how stable or well designed the threading capabilities of Godot is, not having any debugging for those threads is a serious deficiency that negates all but the most compelling reasons to go ahead and use it.

Since the original feature request was logged on Sep 2015, and it's now Aug 2018. Some of us (including myself) have been waiting for years for this key feature to be implemented! Hopefully we can get someone to seriously consider implementing this feature soon. I'm sure a bunch of us would be more than happy to contribute time to help run, test, and verify any feature work that goes in this area.

supercom32 on 27 Aug 2018

Kicked to 3.2, since its a core feature, and we're entering in feature freeze state.

Chaosus on 2 Sep 2018

Has this still not been implemented on master? I was able to set a breakpoint and step over, etc. in a thread just fine in this example project:
multithreaded-debugging.zip

creikey on 10 Aug 2019

Has this still not been implemented on master? I was able to set a breakpoint and step over, etc. in a thread just fine in this example project:
multithreaded-debugging.zip

Your specific example works, but I'm not sure it works under all cases. For example, if you just get rid of all the surrounding code and make an empty thread:

func _ready():
thread = Thread.new()
thread.start(self, "_thread_function")

func _thread_function(userdata):
while true:
print("break here")

Putting a breakpoint on the print line doesn't work. Something about the way you created your project makes breakpoints appear to work, but doesn't work in all cases. Maybe because your using yield?

supercom32 on 11 Aug 2019

It seems as if yielding in a thread allows the debugger to catch up to it... for example this code:

while true:
        exit_thread_mutex.lock()
        if exit_thread:
            break
        exit_thread_mutex.unlock()
        print("test")
        yield(get_tree().create_timer(0.016), "timeout")

in a thread is easily debuggable. My best guess is that because yielding allows the gdscript debugger to "see" the function somehow. Nevertheless, this is a solid workaround to the issue.

creikey on 11 Aug 2019

Your yield code will make the function resume when the timer "timeout" signal is emitted. Timer tick happens in the main thread during idle process, so the signal is emitted there and the function is resumed in the main thread.

neikeq on 11 Aug 2019

Test project included in https://github.com/godotengine/godot/issues/19809#issuecomment-400926371

akien-mga on 7 Jan 2020

Is this going to be implemented anytime soon? This feature request has been open for 5 years now. I can't properly debug my scripts because we use multi-threading to avoid bogging up the main thread with http requests. Please do consider making this a priority feature considering multi-threading is supported by GDSCript.

Favorlock on 16 Apr 2020

👍7

Pleeaaase make this happen, this is invaluable for anybody trying to make more than just a quick game project and is actually serious on development on this engine. Threads are super poorly documented as well, which makes the situation even worse without a working debugger and breakpoint support. Please let this end with 4.0!!

Rriik on 2 Aug 2020

👍1

@Rriik This might be attempted for 4.0, but I can't make any guarantees about it.

Calinou on 2 Aug 2020

😕2

It really would be nice to see. Debugging is such a critical feature for any programmer. Many times have I run into issues and only figured out the issue in a timely manner because of debugging. Multi-threading is becoming more and more common, especially for games that utilize web services and can't afford to allow the main thread to be blocked. Being unable to debug threads means that Godot isn't going to see as much growth in this regard.

Favorlock on 3 Aug 2020

👍1

I just wasted hours trying to debug my threaded code until I asked myself "is debugging threads even supported?" Well, now I know it isn't!

the ability to debug threaded code is super important, please ensure this is added to 4.0.

PerMalmberg on 4 Aug 2020

👍2

I literally spent hours trying to figure out why my code wasn't working, still dunno how to cause the chunk of code I'm trying to debug is enormous. Correct me if I'm wrong, but a feature like this would probably take less time to implement than I've spent getting screwed by it. Godot, I love you, but please don't suck anymore

lord-tomorrow on 29 Aug 2020

@lord-tomorrow Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

Calinou on 29 Aug 2020

Godot: Breakpoints do not work in Thread

Most helpful comment

All 38 comments

Related issues