octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #57591] Segmentation faults when running the t


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #57591] Segmentation faults when running the test suite (mostly with clang)
Date: Wed, 24 Jun 2020 17:01:34 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Follow-up Comment #42, bug #57591 (project octave):

In answer to the question in comment #37, no, there is no special code that I
know of to detect whether we are using a real display or some framebuffer
thing.

What I was thinking might be happening is that the GUI thread accesses a
graphics object (which belongs to the interpreter) and uses it without
acquiring and holding a lock so that the interpreter could modify or delete
the graphics object while the GUI thread is using it.  Unlike octave_value
objects, the graphics objects do not have copy-on-write semantics, so it seems
there could be trouble.

Here is QtHandles::Figure::slotGetPixels, which is one of the functions that
shows up in the stack trace shown in comment #41:


  uint8NDArray
  Figure::slotGetPixels (void)
  {
    uint8NDArray retval;
    Canvas *canvas = m_container->canvas (m_handle);

    if (canvas)
      {
        gh_manager& gh_mgr = m_interpreter.get_gh_manager ();

        gh_mgr.process_events ();
        octave::autolock guard (gh_mgr.graphics_lock ());
        retval = canvas->getPixels ();
      }

    return retval;
  }


If I understand correctly, m_handle is the figure number for the current
figure and is used to find the graphics object for the figure object.  Is it
possible that processing events could invalidate m_handle?  It doesn't seem
like that's what's happening here because if it were, then I would expect the
call to gh_mgr.get_object in GLCanvas::do_getPixels to fail.

But this is the kind of thing that looks suspect to me.  It seems like the way
the GUI thread is using of graphics handles and objects that belong to the
interpreter thread is not clearly defined.

If the GUI thread stores a handle to a graphics object (or a graphics object
itself) then it seems to me that it should somehow grab a reference to it in a
way that can either be checked later to ensure that it remains valid, or that
will prevent it from being modified/deleted until the GUI thread no longer
needs it.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57591>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]