Mercurial > octave
diff libgui/graphics/Object.h @ 25044:b6aea95a7bf9 stable
store graphics object in Qt backend to avoid crash (bug #53487, #53500)
* Figure.cc (Figure::update): Return early if window doesn't exist.
* Object.h, Object.cc (Object::m_go): New data member.
(Object::object): Return m_go instead of using gh_manager to find it.
| author | John W. Eaton <jwe@octave.org> |
|---|---|
| date | Wed, 28 Mar 2018 17:36:40 -0400 |
| parents | 194eb4bd202b |
| children | 6652d3823428 |
line wrap: on
line diff
--- a/libgui/graphics/Object.h Wed Mar 28 21:46:11 2018 +0200 +++ b/libgui/graphics/Object.h Wed Mar 28 17:36:40 2018 -0400 @@ -97,7 +97,23 @@ virtual void beingDeleted (void); protected: + + // Store the graphics object directly so that it will exist when + // we need it. Previously, it was possible for the graphics + // backend to get a handle to a figure, then have the interpreter + // thread delete the corresponding object before the backend (GUI) + // thread had a chance to display it. It should be OK to store + // this object and use it in both threads (graphics_object uses a + // std::shared_ptr) provided that we protect access with mutex locks. + graphics_object m_go; + + // Handle to the graphics object. This may be redundant now. + // Also, the whole ObjectProxy thing may not need to store a + // pointer now? Maybe we can just have a lookup table from figure + // handle to Object? What does the FLTK toolkit do? Why does + // this seem to be so complicated? graphics_handle m_handle; + QObject *m_qobject; };