Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

wxAuiManager preview issue under wxSmith cause C::B can't exit correctly

(1/6) > >>

ollydbg:
I found a very annoying issue. Here are steps to reproduce:
1, open C::B
2, create a simple wxWidgets app with the wizard(choose wxFrame based, wxSmith as the GUI designer)
3, add a wxAuiManager to the main Frame
4, save all
5, close C::B

The result is: I see the codeblocks.exe process is still in the Windows task manager(its memory size is about 35M to 40M), I have to kill this process.

Note, if you don't have wxAuiManager object in the wxFrame, you don't have such issue.

I have tested this steps under:
1, 32bit official C::B 17.12 under Win7(64bit), which is wx2.8.12 based.
2, 32bit C::B trunk build myself with wx3.12, gcc 7.2.
Both have such issue.

I try to debug this issue, but it looks like the process hang issue after the function call: void MainFrame::OnApplicationClose(wxCloseEvent& event), so it is hard to debug. Also, since C::B is halt (it stalls inside the Win32 wait object functions), I don't have a call stack here.

This issue firstly happens in a complex wxsmith project, but I just reduce the wxsmith and finally see that a single wxAuiManager object in wxsmith will cause this issue.

This issue is not related to code generation, because I event don't need to build the cbp project, just open the wxsmith gui designer(the preview window) will cause this issue.

Any ideas?
 

oBFusCATed:
1. Does reverting rev11530 changes anything?
2. Have you tried to reproduce the problem in some wx sample?
3. Have you tried with a debug wx build?

BlueHazzard:
Could it be this:
https://sourceforge.net/p/codeblocks/tickets/789/

--- Quote ---2) AuiManager::UnInit() has to be added to the destructor of the window code
--- End quote ---
in the destructor of the preview?

ollydbg:

--- Quote from: BlueHazzard on February 11, 2019, 10:38:30 pm ---Could it be this:
https://sourceforge.net/p/codeblocks/tickets/789/

--- Quote ---2) AuiManager::UnInit() has to be added to the destructor of the window code
--- End quote ---
in the destructor of the preview?

--- End quote ---

There is a UnInit() function call in the preview wxAuiManager derived object: in file: src\plugins\contrib\wxSmithAui\wxAuiManager\wxSmithAuiManager.h

--- Code: ---#ifndef WXSMITHAUIMANAGER_H
#define WXSMITHAUIMANAGER_H

#include <wx/aui/aui.h>
#include <wx/wx.h>
#include <wx/event.h>

#include <prep.h>

class wxSmithAuiManager : public wxAuiManager
{
    public:
        wxSmithAuiManager(wxWindow* managed_wnd = NULL, unsigned int flags = wxAUI_MGR_DEFAULT)
            : wxAuiManager(managed_wnd, flags)
        {
            Connect(wxEVT_DESTROY,(wxObjectEventFunction)&wxSmithAuiManager::OnDestroy);
        }

        virtual ~wxSmithAuiManager() {}

        void OnDestroy(cb_unused wxWindowDestroyEvent& event)
        {
            UnInit();
        }
    protected:
    private:
};

#endif // WXSMITHAUIMANAGER_H

--- End code ---

So, it will be called when the preview window closed?

ollydbg:

--- Quote from: oBFusCATed on February 11, 2019, 06:40:35 pm ---1. Does reverting rev11530 changes anything?
--- End quote ---
I'm not sure, but mostly I think it is not related to this commit.

--- Quote ---SHA-1: 28734b8204bff66d8a9d6b8e7bb2f4eb8ad83561

* * batch build: Fix segmentation fault after batch build (ticket #738)

> The problem happens because there is a Manager::Yield() in
  MainFrame::OnApplicationClose. This call to yield makes wxWidgets execute
  all events in its event queue and unfortunately there are events related
  to delayed destruction of the current window which get executed at a bad
  time.
> If I remove the Yield call the bug goes away. Not sure what would break
  by this change, but we'll probably see.
> I've tested if the APP_SHUTDOWN event is still sent and received. I found
  no problems with this.

git-svn-id: https://svn.code.sf.net/p/codeblocks/code/trunk@11530 2a5c6006-c6dd-42ca-98ab-0921f2732cef

--- End quote ---
But the issue happens in official C::B 17.12 version(r11256), which is long before commit r11530.



--- Quote ---2. Have you tried to reproduce the problem in some wx sample?
--- End quote ---
The issue happens in preview of the wxSmith, the generated executable by C::B doesn't have such issue.


--- Quote ---3. Have you tried with a debug wx build?

--- End quote ---
Note tried yet, building wx3.12 under gcc 7.2 is quite slow, will take some time to try it.

Navigation

[0] Message Index

[#] Next page