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

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_typesVSTGUI::CRect > >::operator*()
std::_Vector_iterator<std::_Vector_val<std::_Simple_typesVSTGUI::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::_DeallocateVSTGUI::CRect(VSTGUI::CRect * _Ptr, unsigned __int64 _Count)
std::allocatorVSTGUI::CRect::deallocate(VSTGUI::CRect * _Ptr, unsigned __int64 _Count)
std::_Wrap_alloc<std::allocatorVSTGUI::CRect >::deallocate(VSTGUI::CRect * _Ptr, unsigned __int64 Count)
std::vector<VSTGUI::CRect,std::allocatorVSTGUI::CRect >::Tidy()
std::vector<VSTGUI::CRect,std::allocatorVSTGUI::CRect >::~vector<VSTGUI::CRect,std::allocatorVSTGUI::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!

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.

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

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.

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!