Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A bug in VC2010 and earlier kill Pocode randomly #122

Open
androidi opened this issue Jul 12, 2014 · 0 comments
Open

A bug in VC2010 and earlier kill Pocode randomly #122

androidi opened this issue Jul 12, 2014 · 0 comments

Comments

@androidi
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant