You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a bug in VS C++ 2010 compiler, which kills the whole application (sometimes!) when std::deque breaks down.
In EventCenter::processEvents(..) at line 248 (development branch) the code says: events.pop_front();
What happens sometimes in VC++, is that it invalidates everything in the (events) deque. This leads to a nasty divide by zero situation, or actually even VC++ does not know what in the world just happened..
This bug started to appear (very often, like in 2-3 min intervals!) when I created enough dynamic dialogs & buttons (poObjects listening for mouse down events) and attached four TUIO screens, imitating those mouse down events (by hacking the TUIO events in as mouse down events via applicationCurrentWindow()->mouseDown(x, y, 0) where x and y are the TUIO event coordinates)
The only way to avoid the crash was to wrap the whole content of processEvents() function in a __try/__except block, and return a Boolean, whether the event processing was ok or failed. Then poWindow.cpp (lines 90-92) examines this Boolean value, and if false (deque broke down), it quickly replaces the received-deque with a new instance (i.e. received = std::deque<Event>();) leaving a nasty, but less fatal memory leak than program crash. The memory leak was unavoidable in quick fix situation, because calling received.clear() function in poWindow would break the system another time. (VS also refused to cooperate if one tries to reinitialise the events-deque in __except block, thus the Boolean response to poWindow.)
Only by using deque.pop_back() in EventCenter would perhaps help to avoid this compiler bug from appearing?
The text was updated successfully, but these errors were encountered:
There's a bug in VS C++ 2010 compiler, which kills the whole application (sometimes!) when std::deque breaks down.
In EventCenter::processEvents(..) at line 248 (development branch) the code says: events.pop_front();
What happens sometimes in VC++, is that it invalidates everything in the (events) deque. This leads to a nasty divide by zero situation, or actually even VC++ does not know what in the world just happened..
Here's the bug report in MS forums:
https://connect.microsoft.com/VisualStudio/feedback/details/533131/bug-in-std-deque-non-conforming-invalidation-of-iterators-after-pop-front
This bug started to appear (very often, like in 2-3 min intervals!) when I created enough dynamic dialogs & buttons (poObjects listening for mouse down events) and attached four TUIO screens, imitating those mouse down events (by hacking the TUIO events in as mouse down events via applicationCurrentWindow()->mouseDown(x, y, 0) where x and y are the TUIO event coordinates)
The only way to avoid the crash was to wrap the whole content of processEvents() function in a __try/__except block, and return a Boolean, whether the event processing was ok or failed. Then poWindow.cpp (lines 90-92) examines this Boolean value, and if false (deque broke down), it quickly replaces the received-deque with a new instance (i.e. received = std::deque<Event>();) leaving a nasty, but less fatal memory leak than program crash. The memory leak was unavoidable in quick fix situation, because calling received.clear() function in poWindow would break the system another time. (VS also refused to cooperate if one tries to reinitialise the events-deque in __except block, thus the Boolean response to poWindow.)
Only by using deque.pop_back() in EventCenter would perhaps help to avoid this compiler bug from appearing?
The text was updated successfully, but these errors were encountered: