A few of our users are experiencing a bug in which the MidiKeyboardState generates an F5 note upon synth construction resulting in a hanging note. I can’t recreate the issue on my end, so I’m using SystemStats::getStackBackTrace() inside MidiKeyboardState and logging its result to a file so I can see where this noteOn is coming from.
When testing on my system (by manually triggering a note from QWERTY keyboard) I get a full 22-step stack trace (see below). But when he sends me his log file, it only shows the first three steps (19-21, see below)
This is on Windows. I’m sending him the debug version so that it’ll be symbolicated. Is there any additional files from the debug build I need to send him as well to get the full stack trace?
Mine:
0: Syntorial: juce::SystemStats::getStackBacktrace + 0x85
1: Syntorial: juce::MidiKeyboardState::noteOn + 0xe5
2: Syntorial: juce::MidiKeyboardComponent::keyStateChanged + 0xe1
3: Syntorial: juce::ComponentPeer::handleKeyUpOrDown + 0x77
4: Syntorial: juce::HWNDComponentPeer::doKeyDown + 0xf4
5: Syntorial: juce::HWNDComponentPeer::peerWindowProc + 0x39e
6: Syntorial: juce::HWNDComponentPeer::windowProc + 0x8b
7: AddClipboardFormatListener + 0x4b
8: GetClassLongW + 0x7aa
9: DispatchMessageW + 0x24a
10: DispatchMessageW + 0x10
11: Syntorial: juce::InternalMessageQueue::dispatchNextMessage + 0x12c
12: Syntorial: juce::dispatchNextMessageOnSystemQueue + 0x1f
13: Syntorial: juce::MessageManager::runDispatchLoop + 0x4d
14: Syntorial: juce::JUCEApplicationBase::main + 0x10a
15: Syntorial: WinMain + 0x12
16: Syntorial: invoke_main + 0x2d
17: Syntorial: __scrt_common_main_seh + 0x157
18: Syntorial: __scrt_common_main + 0xd
19: Syntorial: WinMainCRTStartup + 0x8
20: BaseThreadInitThunk + 0x19
21: RtlGetAppContainerNamedObjectPath + 0x11e
22: RtlGetAppContainerNamedObjectPath + 0xee
His:
19: BaseThreadInitThunk + 0x19
20: RtlGetAppContainerNamedObjectPath + 0x11e
21: RtlGetAppContainerNamedObjectPath + 0xee
