Bugzilla – Bug 1401
Linux: ASSERT (Intermittent) opening new projects.
Last modified: 2018-08-20 11:45:44 UTC
Regression on 2.1.2. Assertion is "./src/gtk/dcclient.cpp(2043): assert "m_window" failed in DoGetSize(): GetSize()". BACKTRACE: [1] wxClientDCImpl::DoGetSize(int*, int*) const [2] wxRect::wxRect(wxSize const&) /usr/local/include/wx-3.0/wx/gdicmn.h:710 [3] OverlayPanel::DrawOverlays(bool, wxDC*) /home/gale/gitmaster/audacity/src/widgets/OverlayPanel.cpp:81 [4] TrackPanel::OnTimer(wxTimerEvent&) /home/gale/gitmaster/audacity/src/TrackPanel.cpp:963 [5] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const [6] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [7] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [8] wxEvtHandler::TryHereOnly(wxEvent&) [9] wxEvtHandler::ProcessEventLocally(wxEvent&) [10] wxEvtHandler::ProcessEvent(wxEvent&) [11] wxEvtHandler::ProcessPendingEvents() [12] wxAppConsoleBase::ProcessPendingEvents() [13] wxApp::DoIdle() [14] g_main_context_dispatch [15] g_main_loop_run [16] gtk_main [17] wxGUIEventLoop::DoRun() [18] wxEventLoopBase::Run() [19] wxAppConsoleBase::MainLoop() [20] wxEntry(int&, wchar_t**) [21] main /home/gale/gitmaster/audacity/src/AudacityApp.cpp:703 [22] __libc_start_main [23] _start
Just to clarify, this assertion occurs in release configuration, hence the priority and release note.
I'm intermittently getting the same assert, but without changing Snap To. I've not been able to trigger the assert using Snap To, but it occurs occasionally when launching Audacity. Whether opening an existing project or not also seems to be irrelevant. It looks like the "Snap To" step and opening projects are red herrings, though possibly encouraging the wrong side of a race. I'd suggest changing the bug title to something more general, such as "intermittent assert on launch". This would mean that the release note is also too specific. ASSERT INFO: ../src/gtk/dcclient.cpp(2043): assert "m_window" failed in DoGetSize(): GetSize() doesn't work without window BACKTRACE: [1] wxClientDCImpl::DoGetSize(int*, int*) const [2] wxRect /usr/include/wx-3.0/wx/gdicmn.h:710 [3] OverlayPanel::DrawOverlays(bool, wxDC*) /home/steve/sourcecode/Git/audacity/build/src/../../src/widgets/OverlayPanel.cpp:82 [4] TrackPanel::OnTimer(wxTimerEvent&) /home/steve/sourcecode/Git/audacity/build/src/../../src/TrackPanel.cpp:974 [5] wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const [6] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const [7] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [8] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [9] wxEvtHandler::TryHereOnly(wxEvent&) [10] wxEvtHandler::ProcessEventLocally(wxEvent&) [11] wxEvtHandler::ProcessEvent(wxEvent&) [12] wxEvtHandler::ProcessPendingEvents() [13] wxAppConsoleBase::ProcessPendingEvents() [14] wxApp::DoIdle() [15] g_main_context_dispatch [16] g_main_loop_run [17] gtk_main [18] wxGUIEventLoop::DoRun() [19] wxEventLoopBase::Run() [20] wxAppConsoleBase::MainLoop() [21] wxAppConsoleBase::OnRun() [22] wxAppBase::OnRun() [23] wxEntry(int&, wchar_t**) [24] wxEntry(int&, char**) [25] main /home/steve/sourcecode/Git/audacity/build/src/../../src/AudacityApp.cpp:703 [26] __libc_start_main [27] _start
(In reply to Steve Daulton from comment #2) Forgot to say - I'm using a debug build. Also, pressing "Stop" in an assert dialog is not strictly a "crash", it is forced termination.
(In reply to Steve Daulton from comment #2) > I've not been able to trigger the assert using Snap To, but it occurs > occasionally when launching Audacity. Thanks for testing. I have never had the assertion on launch, unless (sometimes) if I change Snap To to "Off" then immediately quit and restart Audacity. I have not yet seen the assertion unless I change Snap To to off. Are you able to build release configuration sometime and see if that behaves the same for you? I don't want to say "Intermittent assertion on launch" because that does not describe what happens for me in release configuration. In debug configuration, which I don't normally use, I can't reproduce the bug steps and have not yet seen this assertion. The bug title could be "intermittent assertion on launch or opening a new project window" (it also happens if I use File > Open to import a file, but only if I have turned Snap To off immediately before). I changed "crash" in the release note to "force quit". :=)
Based on backtrace, expected to be 'fixed' by wx3 compiled without ASSERTs. Looks to be a bug with the timer (for repaint) having started ticking BEFORE the window has actually been created. Anything that slows down window creation could cause it. One possible candidate is a slow disk drive and slow retrieval of preferences. A very remote possibility is that somehow the timer from the previous run is affecting the next run. Code for a mouse down restarts a timer, and that is queued and might possibly be handled as timer events in the next run! Could be speculatively fixed e.g. by starting the timer as late as possible, say in the first OnPaint(). At that point we know the window is valid and it is safe to start the timer.
(In reply to James Crook from comment #5) I only see this when opening a new (empty) project, so an easy fix that works on my machine is to not draw overlays on track panel when the project is empty.
I can repeat this bug nearly every time I launch or close a project. The value of Snap To makes no difference to me. Maybe because my window manager is relatively lightweight (openbox+LXDE) the race is more likely. See this thread for proposed solution. http://audacity.238276.n2.nabble.com/Linux-OverlayPanel-bug-td7578486.html In summary it is a race between the window initialization in wx and our attempt to draw stuff on it. A suggestion from #wxwidgets is to use test IsShown() or IsShownOnScreen() before attempting any drawing calls.
Changed title based on comment #7 and #5 which point to a race condition with the timer.
Adjusted Release Note to downplay changing Snap To, but doing that is still the only way I can get to see the bug (sometimes) on a very slow Ubuntu 14.04 netbook with GNOME or Unity.
Proposed fix using idle event and IsShownOnScreen(). This seems to be the best way as show event isn't supported on all platforms. Seems not to have broken Mac or Windows build; the view scrolls normally during pinned playback. https://github.com/audacity/audacity/pull/185
DEV-FIXMADE https://github.com/audacity/audacity/commit/43291687a5a10e873e8be9971a8f7272c7b4927b Thanks Darrell.
I don't see the assertion as I could previously do on slow Ubuntu netbook, using the steps to reproduce involving Snap To. I tried CTRL + W then immediately held down R to record before the project window was redrawn. This resulted only in a "Disallowed" message as in 2.1.2.
