[+HOTFIX!] memory viewer: Close all instances after emulation exit

[elad335]

Enhancmenets

• Close all memory viewer instances after emulation exit.

Bugfixes

• Hotfix for utils::shm::map_self after utils::shm: Make map_self() atomic #9578

[Nekotekina]

Is it legal to call delete on widgets? Otherwise idm probably isn't best tool for this task.

[elad335]

It worked fine on my tests, @Megamouse is it safe to call delete on QDialog manually? This the main thread calling it.

[MSuih]

Qt has these two warnings about deleting objects:

Warning: All child objects are deleted. If any of these objects are on the stack or global, sooner or later your program will crash. We do not recommend holding pointers to child objects from outside the parent. If you still do, the destroyed() signal gives you an opportunity to detect when an object is destroyed.

Warning: Deleting a QObject while pending events are waiting to be delivered can cause a crash. You must not delete the QObject directly if it exists in a different thread than the one currently executing. Use deleteLater() instead, which will cause the event loop to delete the object after all pending events have been delivered to it.

https://doc.qt.io/qt-5/qobject.html#dtor.QObject

The 2nd point is a bit dangerious, as f.ex. there might be a pending repaint event in the event loop.

[elad335]

Fixed, made it use deleteLater() as QT spec recommends.

[Megamouse]

So is this guaranteed to be always alive when idm is done?
Also, is idm guaranteed to be done before the debugger is killed?

[elad335]

IDM is alive as long as emulation is running, debugger is alive as long as main_window is alive so basically all the time.
When IDM is resetted (i.e. emulation stopping) the destructor of memory_viewer_handle is called.
If closed manually via the exit button finished() signal will remove its IDM entry, also causing the destructor to be called.