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

Crash on closing the first of two windows if --single_process is active #1889

Closed
gunterkoenigsmann opened this issue Jan 24, 2024 · 7 comments

Comments

@gunterkoenigsmann
Copy link
Member

I believe that is the error we had for years, but now we trigger it reliably. Seems to be the following:

  • First we close the window and free the memory it used
  • Then something sends the window a signal.
@gunterkoenigsmann
Copy link
Member Author

git bisect seems to tell that the first bad commit is 534e4e0 - which doesn't make any sense.

@gunterkoenigsmann
Copy link
Member Author

Another bisect blames a8deb78 - which meant changes in Maxima.cpp - which actually really sends events to wxMaxima and which is called in the window's destructor. If we should unsubscribe to maxima's signals before closing maxima?

@gunterkoenigsmann
Copy link
Member Author

Found something that acknowledges my suspicion that this commit was a red herring and that the problem merely has gone worse when wxMaxima has grown faster: If I comment all our QueueEvent() commands the problem goes away => somehow some of our code sends the event that arrives after the main window was closed.

@gunterkoenigsmann
Copy link
Member Author

Disabling all sidebars didn't stop this issue from occurring. ...and it seems like a wxProcess on closing seems to send the message that crashes the program - but only if wxMaxima is closed early enough to trigger the problem.

@gunterkoenigsmann
Copy link
Member Author

The crash only happens if the application is closed shortly after start-up and valgrind tells:

==11762== Invalid read of size 8
==11762==    at 0x559C1B1: UnknownInlinedFun (event.h:1236)
==11762==    by 0x559C1B1: wxEvtHandler::DoTryChain(wxEvent&) (event.cpp:1592)
==11762==    by 0x559E691: wxEvtHandler::ProcessEvent(wxEvent&) (event.cpp:1534)
==11762==    by 0x5507347: wxProcess::OnTerminate(int, int) (process.cpp:94)
==11762==    by 0x558AA07: wxExecuteData::OnExit(int) (utilsunx.cpp:1799)
==11762==    by 0x558ED6D: wxExecuteData::OnSomeChildExited(int) (utilsunx.cpp:1730)
==11762==    by 0x5568AF0: wxAppConsole::CheckSignal() (appunix.cpp:125)
==11762==    by 0x4EC196B: wx_on_channel_event (evtloop.cpp:130)
==11762==    by 0x68041BD: g_main_dispatch.lto_priv.0 (gmain.c:3476)
==11762==    by 0x68625FE: UnknownInlinedFun (gmain.c:4284)
==11762==    by 0x68625FE: g_main_context_iterate_unlocked.isra.0 (gmain.c:4349)
==11762==    by 0x6804CA6: g_main_loop_run (gmain.c:4551)
==11762==    by 0x5EB2B04: gtk_main (gtkmain.c:1329)
==11762==    by 0x4EBAF34: wxGUIEventLoop::DoRun() (evtloop.cpp:61)

@gunterkoenigsmann
Copy link
Member Author

wxExecuteData::OnSomeChildExited(int) is called, if wxAppConsole::CheckSignal() detects that a child process has exited.

We only have very few child processes:

  • The gnuplot process we ask for the compiled-in terminals
  • maxima
  • gnuplot, again, if the user asks to pop out a plot (which doesn't happen in our case of crashes in the testsuite).

Should be very easy. But somehow I still don't find out how to get rid of this problem.

@gunterkoenigsmann
Copy link
Member Author

Resolved with 287ca62.

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