JUCE 6.1.3 PopupMenu read access exception on Windows

General JUCE discussion
1

Hi all,

Since updating to JUCE 6.1.3 I keep getting a read access violation exception. At first, I thought it was an issue with our code, but I’m able to reproduce it in DemoRunner too.

Steps:

  1. Build/run JUCE 6.1.3 DemoRunner on Windows (I’m using VS2019).
  2. Go to Browse Demos → GUI → WidgetsDemo.h → Menus.
  3. Click the Nested Sub-Menus button.
  4. Use the keyboard from this point onwards.
  5. Press the down arrow to highlight Item 0.
  6. Press the right arrow to open the Item 0 submenu.
  7. Press the right arrow again to open the Sub-item 0 submenu.
  8. Press the left arrow twice to close the submenus.
  9. If it works OK, repeat steps 3-8 a few times (it happens about 60% of the time for me).

Expected:
Submenus close as expected.

Actual:
Read access violation exception thrown (“peer-> was 0xFFFFFFFFFFFFFF37”) on juce_ModalComponentManager.cpp line 237.

Some investigation suggests that juce::PopupMenu::HelperClasses::MenuWindow::keyPressed(key == KeyPress::leftKey) is using a MenuWindow object that was deleted by a call to hide()/exitModalState(). See juce_PopupMenu.cpp line 575. Using a juce::WeakReference deletion checker in that context avoids the crash.

FWIW, I haven’t tried it on Mac yet, nor have I verified that it wasn’t already a problem in earlier JUCE releases (I just happened to notice it when testing after updating to 6.1.3).

Thanks,
Ben Staton

2 Likes
2

Here’s the stack:

> DemoRunner.exe!juce::ModalComponentManager::bringModalComponentsToFront(bool topOneShouldGrabFocus) Line 237 C++
DemoRunner.exe!juce::Component::exitModalState(int returnValue) Line 1777 C++
DemoRunner.exe!juce::PopupMenu::HelperClasses::MenuWindow::hide(const juce::PopupMenu::Item * item, bool makeInvisible) Line 494 C++
DemoRunner.exe!juce::PopupMenu::HelperClasses::MenuWindow::keyPressed(const juce::KeyPress & key) Line 577 C++
DemoRunner.exe!juce::ComponentPeer::handleKeyPress(const juce::KeyPress & keyInfo) Line 204 C++
DemoRunner.exe!juce::ComponentPeer::handleKeyPress(int keyCode, unsigned int textCharacter) Line 177 C++
DemoRunner.exe!juce::HWNDComponentPeer::doKeyDown(const unsigned __int64 key) Line 3253 C++
DemoRunner.exe!juce::HWNDComponentPeer::peerWindowProc(HWND__ * h, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3772 C++
DemoRunner.exe!juce::HWNDComponentPeer::windowProc(HWND__ * h, unsigned int message, unsigned __int64 wParam, __int64 lParam) Line 3618 C++
[External Code]
DemoRunner.exe!juce::InternalMessageQueue::dispatchNextMessage(bool returnIfNoPendingMessages) Line 149 C++
DemoRunner.exe!juce::dispatchNextMessageOnSystemQueue(bool returnIfNoPendingMessages) Line 266 C++
DemoRunner.exe!juce::MessageManager::runDispatchLoop() Line 107 C++
DemoRunner.exe!juce::JUCEApplicationBase::main() Line 266 C++
DemoRunner.exe!WinMain(HINSTANCE__ * formal, HINSTANCE * __formal, char * __formal, int __formal) Line 176 C++
3

Actually, I’m not sure adding a deletion checker does the trick after all, but the details are all there regardless. Hoping for a quick resolution :pray:

1 Like
4

Thanks for the report. I’ve pushed a fix to develop here:

We’ll likely be doing a point release in the next week or so that will contain this fix amongst some other high priority fixes from the 6.1.3 release.

2 Likes
5

Thanks once again, @ed95