Debug assertion in CFrame::CollectInvalidRects::addRect()

A user interface toolkit mainly for audio plug-ins (VST, AudioUnit, etc).
ray
Posts: 73
Joined: Fri Sep 02, 2016 9:37 am

Debug assertion in CFrame::CollectInvalidRects::addRect()

Postby ray » Fri Mar 23, 2018 3:41 pm

I am encountering sporadic _SCL_SECURE_OUT_OF_RANGE assertions in CFrame::CollectInvalidRects::addRect() on Windows with Direct2D as the backend.

The relevant part of the callstack, after calling invalid() on e.g. a CTextEdit, looks like this:

std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<VSTGUI::CRect> > >::operator*()
std::_Vector_iterator<std::_Vector_val<std::_Simple_types<VSTGUI::CRect> > >::operator*()
VSTGUI::CFrame::CollectInvalidRects::addRect(const VSTGUI::CRect & rect)
VSTGUI::CFrame::invalidRect(const VSTGUI::CRect & rect)
VSTGUI::CView::invalidRect(const VSTGUI::CRect & rect)

Another callstack that also has something to do with CFrame::CollectInvalidRects looks like this

std::_Deallocate<VSTGUI::CRect>(VSTGUI::CRect * _Ptr, unsigned __int64 _Count)
std::allocator<VSTGUI::CRect>::deallocate(VSTGUI::CRect * _Ptr, unsigned __int64 _Count)
std::_Wrap_alloc<std::allocator<VSTGUI::CRect> >::deallocate(VSTGUI::CRect * _Ptr, unsigned __int64 _Count)
std::vector<VSTGUI::CRect,std::allocator<VSTGUI::CRect> >::_Tidy()
std::vector<VSTGUI::CRect,std::allocator<VSTGUI::CRect> >::~vector<VSTGUI::CRect,std::allocator<VSTGUI::CRect> >()
VSTGUI::CFrame::CollectInvalidRects::~CollectInvalidRects()
VSTGUI::CFrame::platformOnMouseMoved(VSTGUI::CPoint & where, const VSTGUI::CButtonState & buttons)
VSTGUI::Win32Frame::WindowProc(HWND__ * hwnd, unsigned int message, unsigned __int64 wParam, __int64 lParam)

The issue doesn't occur if I define VSTGUI_DIRECT2D_SUPPORT as 0 and use Gdiplus as the backend. This however isn't a possible solution in my case, because I rely on Direct2D's ability to scale CBitmaps on the fly.

EDIT: I was wrong about the idea that it doesn't occur in Gdiplus, but I get a _SCL_SECURE_INVALID_ARGUMENT assertion here instead.

Is this a known issue and if so, what can I do about it?

Thanks!

ray
Posts: 73
Joined: Fri Sep 02, 2016 9:37 am

Re: Debug assertion in CFrame::CollectInvalidRects::addRect()

Postby ray » Tue Mar 27, 2018 1:24 pm

The issue disappears if I remove the line "CollectInvalidRects cir (this);" from CFrame::platformOnMouseDown(), CFrame::platformOnMouseMoved(), CFrame::platformOnMouseUp() etc.

What interesting about this is that GUI remains fully functional in this case. Can you explain the convept of the invalid rects collector a little and give some hints on why it may be thread-unsafe?

It's also interesting that it only appears on Windows.

Thank you.

Arne Scheffler
Posts: 201
Joined: Mon Jun 20, 2016 7:53 am

Re: Debug assertion in CFrame::CollectInvalidRects::addRect()

Postby Arne Scheffler » Tue Mar 27, 2018 5:03 pm

Hi,
VSTGUI is designed to only operate on one thread (with one exception and that is the call to setDirty() which may be called from other threads if CView::kDirtyCallAlwaysOnMainThread is not set to 'true'). You have to make sure that this principle is not violated.

Cheers
Arne

ray
Posts: 73
Joined: Fri Sep 02, 2016 9:37 am

Re: Debug assertion in CFrame::CollectInvalidRects::addRect()

Postby ray » Wed Mar 28, 2018 11:26 am

Hi Arne,

Thanks for your feedback. So if I understand things correctly, the issue should go away if I replace all my invalid() calls that are potentially reached from different threads into setDirty() ensuring a "scheduled" update in the WM_PAINT handler?

Thanks.

Arne Scheffler
Posts: 201
Joined: Mon Jun 20, 2016 7:53 am

Re: Debug assertion in CFrame::CollectInvalidRects::addRect()

Postby Arne Scheffler » Wed Mar 28, 2018 12:29 pm

Yes, but much better would be if you just don't call into VSTGUI from different threads. One potential issue with setDirty is that you cannot use overlapping views. Performance may also be worse.

ray
Posts: 73
Joined: Fri Sep 02, 2016 9:37 am

Re: Debug assertion in CFrame::CollectInvalidRects::addRect()

Postby ray » Wed Mar 28, 2018 2:55 pm

Arne Scheffler wrote:Yes, but much better would be if you just don't call into VSTGUI from different threads. One potential issue with setDirty is that you cannot use overlapping views. Performance may also be worse.


Hi Arne,

that was already very helpful. Unfortunately, I'm in an environment where the fact that UI-Updates are potentially and implicitly triggered from other threads is a given. I'm pretty confident though that using setDirty() in those cases helped to tackle the reported issue. invalid() can still be used in other cases where it's obvious that they are coming from the main thread. Overlapping views aren't an issue for us anyway. Thanks again!


Return to “VSTGUI”

Who is online

Users browsing this forum: No registered users and 1 guest