-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Freezing while drawing the initial fractal #177
Comments
It's possible that in the tests we never have the GIL already but in this normal usage, we do when the cleanup code is run |
I also had some trouble (deadlocks) with the GIL lock in #175. Actually I had to disable it for the "continuous mode", see https://github.com/fract4d/gnofract4d/pull/175/files#diff-046a50aa52e99568daf19d67df90afa7R136 Couldn't figure out the reason though. |
Would switching over to the new controller code avoid this? |
The new controller interface uses a different approach for the reference counting problem: pfo and site instances are owned by the controller instance, image and colormap are kept until replaced (by a new calculation process) or the instance is disposed. I was working on switching gnofract4d to this new interface but I couldn't continue due to the lack of time: https://github.com/HyveInnovate/gnofract4d/commit/2fda447db3665f010f4da0ea1f5237fcdd47eeda I'm not sure if this would solve the problem, but I like the idea of using python extension types because they help creating better interfaces in my opinion. In the PR #85 there's more info about this. |
Thanks for the pointers. I was wondering if the problem was something to do with site owning the thread and being part of the cargs being deleted (but that is an uneducated guess, and it may well be the GIL being held somewhere completely different, there is a lot of GIL locking in PySite though...). The new interface seemed to separate site off. Looks like it would help with the problems with testfdsite (#173) and worked around in fract4dgui.gtkfractal.Hidden.onData(). |
I cloned HyveInnovate@2fda447 and rebased on master (no big deal). Then spent a while trying to understand the test failures (just the new API I think, more later), and finally decided to get on and install it. My test for the segfault and freezing has simply been to start the program, wait for the initial fractal, close and repeat.
and that is a lot fewer problems than with master. There aren't many test failures, only two causes I think: fract4d.fractal.T.drawpoint(): > result = fract4dc.pf_calc(
self.pfunc, self.params[0:4], self.maxiter, 0, 0, 0, repeats)
E ValueError: Not a valid handle Although And in fract4d/tests/test_3d.py, multiple failures in Setup(): self.fw = fract4dc.fw_create(
> 1, self.pfunc, self.cmap, self.im._img, self.f.site)
E AttributeError: 'T' object has no attribute 'site' What happens to those tests of fract4d/c/fract4dc/functions.cpp? |
As I see it, switching Gnofract4d to use the new controller is an ambitious long term task.
That's exactly the point and the idea behind all of this, and it's all explained in #110. But basically, in my opinion, we should move those tests to C++, because some (actually many of them) fract4dc interfaces exist just to do those tests in python. As a middle-term solution, if we want to use this new controller, we could expose the site entity from inside the controller so the |
OK, good to have found out a bit more.
I'll see if I can reproduce it. (It is a lot less frequent than with the current code, but yes it would be preferable to find - could even be something unrelated from GTK...) For me current master is the worst of all, freezing is the most frequent problem. No easy options. |
Might have something to do with #154 as well (I was also suspicious about GKT) I can reproduce the problem in my environment (python 3.8.6 - MacOS 10.15.7) I'll try also to check the sanitizers as I did here I'll keep this posted if I find anything |
Another interesting thing:
That is something that is annoying me a lot while working on #175 Of course this is not the cause of the problem, but I think it's worth to check if it's making it worse |
Trying to find something in the Python I got curious about: Lines 66 to 70 in 0930ad1
And in investigating that saw It's not the root cause but it does seem to be what is exposing the problem at startup. #182 appears to fix this issue for me, so far... (I still like the controller interface though). |
I think I might have found the actual problem and, hopefully, the solution (PR coming soon). With the information already provided in this issue I think it's pretty clear we have a deadlock here: gnofract4d/fract4d/c/fract4dc/calcs.cpp Lines 97 to 99 in 0930ad1
Basically what we are trying to do there is to acquire the interpreter lock before deleting the gnofract4d/fract4d/c/fract4dc/calcs.cpp Line 51 in 0930ad1
That's because pycalc is executed in the interpreter thread.So when 2 calls to fract4dc.calc happen in a very short time interval we have them waiting for each other to release the interpreter lock and thus a deadlock.
Honestly I'm not 100% sure how GIL works and if this is really the problem but, following my guessing I came up with this solution that is working for me: PyObject * pycalc([[maybe_unused]] PyObject *self, PyObject *args, PyObject *kwds)
{
calc_args *cargs = parse_calc_args(args, kwds);
if (NULL == cargs)
{
return NULL;
}
if (cargs->asynchronous)
{
std::thread t([cargs](){
auto &site = *cargs->site;
site.interrupt();
site.wait();
site.start();
site.set_thread(std::thread(calculation_thread, cargs));
});
t.detach();
}
else
...
Py_INCREF(Py_None);
return Py_None;
} Basically here I'm releasing the interpreter lock immediately instead of waiting for what do you think? |
Moving the fractal around by using the cursor keys (a lot) is another way I can get master to freeze - this change stops that happening. |
47752e0 (#164) does stop segfaults but for me it appears to be often causing the application to freeze soon after start-up when the application is shown but before the initial fractal has completed drawing (often before there is anything visible of the fractal).
Tests pass fine.
This is with Python 3.8.6 and Python 3.8.5. I've only recently noticed, although possibly I just haven't run it much since first applying the patch. If I revert it this issue goes away.
The text was updated successfully, but these errors were encountered: