Application crashes when deleting custom series

[surelyitsanton]

Version of Dear PyGui

Version: 1.11.1, 2.0.0 Operating System: Windows 10

My Issue/Question

Trying to delete a custom series causes my application to crash. I see this issue has been raised in #1864 and the ticket has been closed but the problem is still present.

To Reproduce

Steps to reproduce the behavior:

1. Create a window
2. Create a plot
3. Add a custom series to the plot
4. Attempt to delete the custom series or the parent window

Expected behavior

The parent window and/or the custom series should be deleted

Standalone, minimal, complete and verifiable example

This is basically the same example used in #1864

import dearpygui.dearpygui as dpg

dpg.create_context()
dpg.create_viewport(width=300, height=200)
dpg.setup_dearpygui()

with dpg.window(label="Example Window", tag="Primary"):
    dpg.add_button(label="delete custom_series using parent", callback=lambda: dpg.delete_item("win"))
    dpg.add_button(label="delete custom_series using tag", callback=lambda: dpg.delete_item("tricky_custom_series"))
    with dpg.child_window(tag="win"):
        with dpg.plot(width=-1, height=-1):
            dpg.add_plot_axis(dpg.mvXAxis)
            with dpg.plot_axis(dpg.mvYAxis) as yaxis:
                dpg.add_custom_series([], [], 2, tag="tricky_custom_series")

dpg.show_viewport()
dpg.set_primary_window("Primary", True)
dpg.start_dearpygui()
dpg.destroy_context()

[v-ein]

Most probably caused by this piece in DearPyGui::draw_custom_series (I didn't check it though):

mvSubmitCallback([&, mouse, mouse2]() {
    ...
    mvAddCallback(item.config.callback, item.uuid, appData, item.config.user_data);

When the series widget is deleted, the mvAppItem object that item is pointing to is deleted as well, and the code above tries to access memory that has been freed.

I believe it's a common issue in the current release of DPG, where many widgets submit their callbacks by calling mvAddCallback via mvSubmitCallback (just like the custom series widget does). Ideally callback scheduling needs a certain amount of rework to remove this extra mvSubmitCallback call and to provide safe memory referencing. I've tried to fix this in my local build but so far still have one race condition to resolve; that's why I prefer not to publish the fix yet.