GimelStudio / Gimel-Studio

Old repo of the node-based image editor. See https://github.com/GimelStudio/GimelStudio for the next generation of Gimel Studio :rocket:

Home Page:https://gimelstudio.github.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Renderer Threading issues causes Crashes

Correct-Syntax opened this issue · comments

@iwoithe, the following is the error (and Gimel Studio crashes) I get on Linux (Mint) when I follow the steps I mentioned in #18. So, #18 might just be a side-effect of this (#19) issue. Unless @Metallicow is right about python 3.8, etc. ??

[xcb] Unknown sequence number while processing reply
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python3: ../../src/xcb_io.c:641: _XReply: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

Note: Testing on Linux Mint (which I haven't done in a while), I can hardly do much of anything (connect nodes, select an image, etc) without crashing and the error message above.

This makes me think that it is indeed due to the threading issues that other segfaults are happening.

After reverting to the v0.4.2 code, it seemed to be a bit better. However, it still crashed quite often. Then, I discovered that if the View>Live Node Previews was disabled in the menu, it crashes far less often.

Basically this puts it back to where we were before in v0.4.2 as far as stability (which wasn't great, but is at least "usable"). The "Live Node Previews" feature is actually a new one in 0.5.0, so it makes sense.

Your nowhere's near "live" updates. This project is still in infancy. You are more at the point of creating a #### of bugs if you are using threads.
When you test something, test it without threads.
And you will crash gracefully. ... and hopefully know where....
When you get to the point you can do that without crash. Add a single thread. Test extensively.
If you are brave, use 2 threads.
Crash your rig. Repeat.
When you grow real balls, add some more threads, and monitor and RECORD YOUR RESULTS.
When you have a database of your own results without problems, Add lots of threads until you find that the extras # are useless and is optimum.

Basically in a nutshell. TEST, Test, test.....

If I haven't released even a basic node graph, then you possibly can't comprehend the problems you will run into in the future.

My dear brother, with what we are toying with we are on basically, "the bleeding edge", and if you expect to have a super hyper responsive program.... well guess again.

So to say... is that you cannot produce or post a full traceback is null at this point.
And if using threads, your traceback results are crap, because they cannot be trusted because of timestamps. Plus many others will generate the same stuff that will bewilder you(and you have to deal with closing issues not me, thus wasting time. hehe :/ ).

Using threads is a hard issue, and please don't try to subject it on the WIPz working repository, because all you will do is create more headaches for yourself that you cannot reproduce yourself.

Ex: I'd rather not deal with the rest of the world bugging me about 1 smallest issue when I have worked on a program for over 10 years. And likely I have my own workaround, but I absolutely WILL NOT deal with billions of users posting the same problems on a github, that they are not sending me donations too.

I am the type of person that works on something a LONG time before doing anything with it. Besides getting lashes on thy bak for occasional whitespace corrections.

Here is a start at the basics(in the docs)
https://docs.python.org/2/library/threading.html
My link is to Py2, so as to be cross compatible in your learning.

I might take a week or moths to decide on an answer, rather than minutes, or days.

And often if I dump a week-long-extravaganza on ya, it will still cause ya nightmares in records, just have balls and run it.

@Metallicow,

Your nowhere's near "live" updates.

Technically the Live Node Previews was really a "live" thing (the previews would update as each node rendered)...saying the threading worked all the time. I agree the rest of the program isn't exactly what could be called "live updates". Though, at times it seems to get pretty close on my PC.

This project is still in infancy. You are more at the point of creating a #### of bugs if you are using threads.

You're very right @Metallicow.

Actually the text node issue doesn't seem to be a problem with threads at all, but rather something with the font loading, etc. Therefore, not all the errors have to do with threading, it would seem.

When you test something, test it without threads.
And you will crash gracefully. ... and hopefully know where....
When you get to the point you can do that without crash. Add a single thread. Test extensively.
If you are brave, use 2 threads.
Crash your rig. Repeat.
When you grow real balls, add some more threads, and monitor and RECORD YOUR RESULTS.
When you have a database of your own results without problems, Add lots of threads until you find that the extras # are useless and is optimum.

Good advice. This is what I am doing from now on.

If I haven't released even a basic node graph, then you possibly can't comprehend the problems you will run into in the future.

True, but every program's development is going to have problems in some way, shape or form. As far as your node graph, it's hard to say what you're doing so I am not sure that's a fair comparison.

My dear brother, with what we are toying with we are on basically, "the bleeding edge", and if you expect to have a super hyper responsive program.... well guess again.
So to say... is that you cannot produce or post a full traceback is null at this point.
And if using threads, your traceback results are crap, because they cannot be trusted because of timestamps. Plus many others will generate the same stuff that will bewilder you(and you have to deal with closing issues not me, thus wasting time. hehe :/ ).
Using threads is a hard issue, and please don't try to subject it on the WIPz working repository, because all you will do is create more headaches for yourself that you cannot reproduce yourself.

Yes. Though I have to wonder how it CAN be done...

Ex: I'd rather not deal with the rest of the world bugging me about 1 smallest issue when I have worked on a program for over 10 years. And likely I have my own workaround, but I absolutely WILL NOT deal with billions of users posting the same problems on a github, that they are not sending me donations too.

O.k. Now I understand why your repos don't have many (if any) issues. Understandable though.

I am the type of person that works on something a LONG time before doing anything with it. Besides getting lashes on thy bak for occasional whitespace corrections.

O.k.

Here is a start at the basics(in the docs)
https://docs.python.org/2/library/threading.html
My link is to Py2, so as to be cross compatible in your learning.

Thanks.

I might take a week or moths to decide on an answer, rather than minutes, or days.
And often if I dump a week-long-extravaganza on ya, it will still cause ya nightmares in records, just have balls and run it.

O.k. Well thanks for the warning. Your code doesn't seem that bad. :)

The threading has been disabled for now. Thus, I am closing this issue.