Assertion failure when editing training data with both mouse and keyboard?

[damellis]

One workshop participants hit an assertion failure when recording a new training sample shortly after doing delete all. Is it possible we're getting input on different threads for the keyboard vs. the mouse? Or that new events are coming in before we process the last one?

Assertion failed: (num_samples_per_label_[label] == data_.getClassData(label).getNumSamples()), function getNumSampleForLabel, file /Users/mellis/work/dev/ml/ESP/Xcode/ESP/src/training-data-manager.cpp, line 104.

Thread 1Queue : com.apple.main-thread (serial)
#0  0x00007fff844bf286 in __pthread_kill ()
#1  0x00007fff88f729f9 in pthread_kill ()
#2  0x00007fff89a7b9b3 in abort ()
#3  0x00007fff89a43a99 in __assert_rtn ()
#4  0x00000001000e73cb in TrainingDataManager::getNumSampleForLabel(unsigned int) at /Users/mellis/work/dev/ml/ESP/Xcode/ESP/src/training-data-manager.cpp:103
#5  0x000000010003f423 in ofApp::keyReleased(int) at /Users/mellis/work/dev/ml/ESP/Xcode/ESP/src/ofApp.cpp:2136
#6  0x00000001000492c1 in ofBaseApp::keyReleased(ofKeyEventArgs&) at /Users/mellis/work/dev/ml/ESP/Xcode/ESP/../../third-party/openFrameworks/libs/openFrameworks/app/ofBaseApp.h:83
#7  0x000000010057bfc3 in std::__1::shared_ptr<of::priv::Function<ofKeyEventArgs, std::__1::recursive_mutex> > ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>::make_function<ofBaseApp>(ofBaseApp*, void (ofBaseApp::*)(ofKeyEventArgs&), int)::'lambda'(void const*, ofKeyEventArgs&)::operator()(void const*, ofKeyEventArgs&) const [inlined] at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworksCompiled/project/osx/../../../../libs/openFrameworks/events/ofEvent.h:237
#8  0x000000010057bfa5 in decltype(std::__1::forward<ofBaseApp>(fp)(std::__1::forward<void const*, ofKeyEventArgs&>(fp0))) std::__1::__invoke<std::__1::shared_ptr<of::priv::Function<ofKeyEventArgs, std::__1::recursive_mutex> > ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>::make_function<ofBaseApp>(ofBaseApp*, void (ofBaseApp::*)(ofKeyEventArgs&), int)::'lambda'(void const*, ofKeyEventArgs&)&, void const*, ofKeyEventArgs&>(ofBaseApp&&, void const*&&, ofKeyEventArgs&&&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__functional_base:413
#9  0x000000010057bfa5 in std::__1::__function::__func<std::__1::shared_ptr<of::priv::Function<ofKeyEventArgs, std::__1::recursive_mutex> > ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>::make_function<ofBaseApp>(ofBaseApp*, void (ofBaseApp::*)(ofKeyEventArgs&), int)::'lambda'(void const*, ofKeyEventArgs&), std::__1::allocator<std::__1::shared_ptr<of::priv::Function<ofKeyEventArgs, std::__1::recursive_mutex> > ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>::make_function<ofBaseApp>(ofBaseApp*, void (ofBaseApp::*)(ofKeyEventArgs&), int)::'lambda'(void const*, ofKeyEventArgs&)>, bool (void const*, ofKeyEventArgs&)>::operator()(void const*&&, ofKeyEventArgs&) at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1370
#10 0x000000010055521f in std::__1::function<bool (void const*, ofKeyEventArgs&)>::operator()(void const*, ofKeyEventArgs&) const at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/functional:1756
#11 0x000000010055515a in of::priv::Function<ofKeyEventArgs, std::__1::recursive_mutex>::notify(void const*, ofKeyEventArgs&) [inlined] at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworksCompiled/project/osx/../../../../libs/openFrameworks/events/ofEvent.h:136
#12 0x000000010055513b in ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>::notify(void const*, ofKeyEventArgs&) at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworksCompiled/project/osx/../../../../libs/openFrameworks/events/ofEvent.h:303
#13 0x0000000100554248 in void ofNotifyEvent<ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>, ofKeyEventArgs>(ofEvent<ofKeyEventArgs, std::__1::recursive_mutex>&, ofKeyEventArgs&) [inlined] at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworksCompiled/project/osx/../../../../libs/openFrameworks/events/ofEventUtils.h:222
#14 0x0000000100554237 in ofCoreEvents::notifyKeyReleased(int, int, int, int) at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworks/events/ofEvents.cpp:281
#15 0x00007fff8b2b6ef2 in -[NSWindow _reallySendEvent:isDelayedEvent:] ()
#16 0x00007fff8ac48c86 in -[NSWindow sendEvent:] ()
#17 0x00007fff8ac458b1 in -[NSApplication sendEvent:] ()
#18 0x000000010031c018 in -[GLFWApplication sendEvent:] ()
#19 0x000000010031cf14 in _glfwPlatformPollEvents ()
#20 0x00000001005798af in ofMainLoop::pollEvents() [inlined] at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworks/app/ofMainLoop.cpp:148
#21 0x000000010057989d in ofMainLoop::loop() at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworks/app/ofMainLoop.cpp:122
#22 0x00000001005506fc in ofRunMainLoop() [inlined] at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworks/app/ofAppRunner.cpp:173
#23 0x00000001005506ef in ofRunApp(std::__1::shared_ptr<ofBaseApp>) at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworks/app/ofAppRunner.cpp:159
#24 0x0000000100550674 in ofRunApp(ofBaseApp*) at /Users/mellis/work/dev/ml/ESP/third-party/openFrameworks/libs/openFrameworks/app/ofAppRunner.cpp:153
#25 0x00000001000019cd in main at /Users/mellis/work/dev/ml/ESP/Xcode/ESP/src/main.cpp:20
#26 0x0000000100001844 in start ()

[damellis]

More generally, it seems that there are situations in which the training data can be modified by two threads simultaneously. We (or, at least, I) need a better sense of what's happening in which threads so we can make things thread-safe.

[nebgnahz]

All ofApp runs in a single thread and openFrameworks manages everything inside ofMainLoop. I also noticed a couple occurrence of the assertion failure but haven't been able to consistently reproduce it.

[damellis]

Removing from the milestone since we can't reproduce consistently.

[damellis]

It looks like this was happening when the GRT's addSample() function was failing (e.g. because the sample was empty). We didn't check for this, and so we added 1 to num_samples_per_label_[label] even though the sample wasn't added to the GRT's data store. This still needs to be merged into the master branch.