[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
segfaults in graphics code (likely threading issues?)
From: |
John W. Eaton |
Subject: |
segfaults in graphics code (likely threading issues?) |
Date: |
Thu, 11 Jun 2020 10:26:20 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 |
We have two bug reports about random crashes during the build or when
running the tests:
https://savannah.gnu.org/bugs/?57591
https://savannah.gnu.org/bugs/?56952
The crashes usually happen when executing some graphics code and my
guess is that they are all related to threading issues with the Qt
graphics toolkit.
We manage the graphics handle data in libinterp/corefcn/graphics.{h,cc}
and the Qt code is in the libgui/graphics directory. The Qt graphics
display runs in the GUI thread, separate from the thread where the
interpreter runs. To safely access data from one thread in the other,
we need some kind of thread safe queue or locking. Currently, I think
all we are doing is using some fairly coarse locking on the gh_manager
object. Is that sufficient? Are there cases where we lock to obtain a
graphics_object in the GUI thread but then unlock while still using the
object?
There are also some questionable calls to unlock the mutex. For
example, in qt_graphics_toolkit::initialize and
qt_graphics_toolkit::finalize, I see
// FIXME: We need to unlock the mutex here but we have no way
to know if
// if it was previously locked by this thread, and thus if we
should
// re-lock it.
gh_manager& gh_mgr = m_interpreter.get_gh_manager ();
gh_mgr.unlock ();
Even if that is not the cause of the trouble, it seems worth
eliminating. It seems to me that locks should be managed automatically
based on scope, not explicitly unlocked in functions separate from where
they are initially locked.
Is there a better way to pass data between the separate interpreter and
graphics toolkit threads? Can we simply lock a mutex in graphics_object
methods so that we can safely access them in multiple threads? Or do we
need a whole new way of passing data between the interpreter and the
graphics toolkit?
jwe
- segfaults in graphics code (likely threading issues?),
John W. Eaton <=