Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)

[ollydbg]

I see the thread search plugin cause crash when initilized, here is the line it crashed:

Code

void DirectoryParamsPanel::OnSearchDirTextEvent(wxCommandEvent &event)
{
    //m_pFindData->SetSearchPath(event.GetString());
    event.GetString();  // ****************Crash on this function call*************
    event.Skip();
}

Here is the call stack:

Code

[debug]Thread 1 received signal SIGSEGV, Segmentation fault.
[debug]0x6885d39d in wxCommandEvent::GetString() const () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]>>>>>>cb_gdb:

In wxCommandEvent::GetString() const () (D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll)

[debug]> bt 30
[debug]#0  0x6885d39d in wxCommandEvent::GetString() const () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#1  0x0d221da7 in DirectoryParamsPanel::OnSearchDirTextEvent (this=0xa41f070, event=...) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\DirectoryParamsPanel.cpp:98
[debug]#2  0x68702eb2 in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#3  0x68703217 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#4  0x6885bc80 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#5  0x6885bd6a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#6  0x6885c549 in wxEvtHandler::TryHereOnly(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#7  0x6885c5ba in wxEvtHandler::ProcessEventLocally(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#8  0x6885c615 in wxEvtHandler::ProcessEvent(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#9  0x68b24c8a in wxWindowBase::TryAfter(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#10 0x6885dff2 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#11 0x68b0cd18 in wxTextEntryBase::SendTextUpdatedEvent(wxWindow*) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#12 0x68b0cf57 in wxTextEntryBase::DoSetValue(wxString const&, int) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#13 0x68975ce1 in wxComboBox::SetValue(wxString const&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#14 0x0d222839 in DirectoryParamsPanel::SetSearchDirPath (this=0xa41f070, sDirPath=L"") at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\DirectoryParamsPanel.cpp:182
[debug]#15 0x0d23b534 in ThreadSearchView::set_properties (this=0xa462588) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\ThreadSearchView.cpp:376
[debug]#16 0x0d2394c5 in ThreadSearchView::ThreadSearchView (this=0xa462588, threadSearchPlugin=...) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\ThreadSearchView.cpp:95
[debug]#17 0x0d226249 in ThreadSearch::OnAttach (this=0xa452778) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\ThreadSearch.cpp:183
[debug]#18 0x01700408 in cbPlugin::Attach (this=0xa452778) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\sdk\cbplugin.cpp:73
[debug]#19 0x0179c7e3 in PluginManager::AttachPlugin (this=0xa20ea38, plugin=0xa452778, ignoreSafeMode=false) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\sdk\pluginmanager.cpp:195
[debug]#20 0x017a28d2 in PluginManager::LoadAllPlugins (this=0xa20ea38) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\sdk\pluginmanager.cpp:1104
[debug]#21 0x0045370c in MainFrame::ScanForPlugins (this=0x6a00648) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\main.cpp:1209
[debug]#22 0x0044e9b7 in MainFrame::MainFrame (this=0x6a00648, parent=0x0) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\main.cpp:633
[debug]#23 0x004029b3 in CodeBlocksApp::InitFrame (this=0x6778248) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\app.cpp:489
[debug]#24 0x00403f47 in CodeBlocksApp::OnInit (this=0x6778248) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\app.cpp:697
[debug]#25 0x004c93a6 in wxAppConsoleBase::CallOnInit (this=0x6778248) at D:\code\wxWidgets-3.1.0\include\wx\app.h:93
[debug]#26 0x687847d2 in wxEntryReal(int&, wchar_t**) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#27 0x004021af in WinMain@16 (hInstance=0x400000, hPrevInstance=0x0, nCmdShow=10) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\src\app.cpp:322
[debug]#28 0x004f73ad in main ()
[debug]>>>>>>cb_gdb:
[debug]> frame 1
[debug]#1  0x0d221da7 in DirectoryParamsPanel::OnSearchDirTextEvent (this=0xa41f070, event=...) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\DirectoryParamsPanel.cpp:98
[debug]D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\DirectoryParamsPanel.cpp:98:4038:beg:0xd221da7
[debug]>>>>>>cb_gdb:

It sounds like the passed wxCommandEvent object has some problems, it just crashed when the event.GetString() function is called.

You can see it is in the initialization stage, because it crashed in the ThreadSearchView::ThreadSearchView() function call.

Code

...
[debug]#14 0x0d222839 in DirectoryParamsPanel::SetSearchDirPath (this=0xa41f070, sDirPath=L"") at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\DirectoryParamsPanel.cpp:182
[debug]#15 0x0d23b534 in ThreadSearchView::set_properties (this=0xa462588) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\ThreadSearchView.cpp:376
[debug]#16 0x0d2394c5 in ThreadSearchView::ThreadSearchView (this=0xa462588, threadSearchPlugin=...) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\ThreadSearchView.cpp:95
[debug]#17 0x0d226249 in ThreadSearch::OnAttach (this=0xa452778) at D:\code\cb\cb_sf_git\clean-trunk-for-commit\src\plugins\contrib\ThreadSearch\ThreadSearch.cpp:183
...

The bad thing is I can not see the event under gdb

Code

[debug]> p event
[debug]$1 = (wxCommandEvent &) @0x28e3e4: <incomplete type>
[debug]>>>>>>cb_gdb:

$1 = (wxCommandEvent &) @0x28e3e4: <incomplete type>

I'm using Win7 64bit, mingw-build gcc 5.4 32bit compiler, wx3.1.

Thanks.

[oBFusCATed]

Are you sure everything is built with the same compiler? And you're using the correct wx libraries and headers?

[ollydbg]

Are you sure everything is built with the same compiler? And you're using the correct wx libraries and headers?

Yes, I have used the same compiler to rebuild the wx library and c::b yesterday, and I see the same issue as before.

[ollydbg]

Oh, is it caused by the different building options when I build C::B and wx?

I have used such command to build wx:

Code

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport" >log-release.txt 2>&1

While I see when building Codeblocks_w31.cbp, I see it use "-std=gnu++11", while when I build threadsearch plugin, I see it also use "-std=gnu++11".

Do I need to add the "-std=gnu++11" to build the wx library?

[BlueHazzard]

i can not reproduce this with
wxWidgets git hash: c51dd81db6da3aa2fc853b452ca2500776b473ed debug build
Codeblocks trunk
gcc 5.1
win7

i can reproduce a crash with release builds, but i can not debug where it comes from because no stack trace. Only

Code

In wxCommandEvent::GetString() const () (wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_custom.dll)
and a lot ??? 

Do I need to add the "-std=gnu++11" to build the wx library?

i have also not enabled c++11 for wx builds

[ollydbg]

Hi, BlueHazzard, thanks for the tests, so this happens only in release version of wx(either in wx3.1 or wx git head), I will ask the question to wx maillist.

EDIT: posted here: https://groups.google.com/d/msg/wx-users/LUxm6fUhirk/FJRFNIt6AAAJ

[ollydbg]

I just build a debug version of wx3.1 with the following command: (note I have -std=gnu++11)

Code

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport -std=gnu++11" >log-debug-cxx11.txt 2>&1

And then I just rebuild the C::B against this wx3.1, and I don't see the crash. While, if I add the -std=gnu++11 option to build a release version of wx3.1, the crash still happens.

Guess: Do I need to add the option "-fno-keep-inline-dllexport" to build the C::B or the plugins?  That's was too complex if both the wx library and C::B need the exact same build option.

EDIT: please note that my wx3.1 source was already applied a patch to avoid a crash (in wxWidgets-3.1.0\include\wx\rtti.h, see #17483 (wxDynamicCast segfault with mingw64 5.3.0 release build) – wxWidgets):

Code

    bool IsKindOf(const wxClassInfo *info) const
    {
        if ( info == this )
            return true;

        if ( m_baseInfo1 )
        {
            if ( m_baseInfo1->IsKindOf(info) )
                return true;
        }

        if ( m_baseInfo2 )
        {
            if ( m_baseInfo2->IsKindOf(info) )
                return true;
        }

        return false;
    }

[ollydbg]

Oh my god, it looks like I meet a similar gcc bug, I just find the cause of this bug, see here:

in wxWidgets's ticket #17483 and https://groups.google.com/d/msg/wx-users/LUxm6fUhirk/GOX_obajAAAJ in wx-user maillist.

[BlueHazzard]

So if you apply this optimization patch the crash goes away? So this should be reported to gcc?

[stahta01]

So if you apply this optimization patch the crash goes away? So this should be reported to gcc?

The second one I would vote no, because I think the GCC crew would rightly say it is a wxWidgets bug.

The first one, I have no idea what the cause is; but, I would guess the right solution is to disable optimization.
Note: That might also fix the second bug. IIRC, someone found the right optimization to disable already.
Might that optimization only be needed on the second bug on wxWidgets's code.
Since, it is not in a header file.

I would try "-fno-delete-null-pointer-checks" in building wxWidgets and see if the second problem goes away.

Tim S.

 

[oBFusCATed]

If an valid optimisation breaks users code then the code is broken and must be fixed.
Disabling specific optimisations is only a short term workaround!

[stahta01]

If an valid optimisation breaks users code then the code is broken and must be fixed.
Disabling specific optimisations is only a short term workaround!

Re-writing wxWidgets to use C++ correctly is a very big job; it will likely take a while! As in years.
Adding the option to see if it works is much faster.

Do you wish to port CB to no longer use the wxWidgets backend?
Or, switch to using wxWidgets for STL build? (No idea if this will fix the issue; but, it has a slight chance)
Edit1: I forgot this bug is wxWidgets RTTI not wxWidgets STL class bug.
Or, try disabling what ever compiler/linker option is causing this bug?
The only other option is finding another solution or ignoring the bug.

Tim S.

[ollydbg]

So if you apply this optimization patch the crash goes away? So this should be reported to gcc?

yes and yes, I have already report to gcc bugzilla. see the links of my previous post.

edit: it is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867

[ollydbg]

I would try "-fno-delete-null-pointer-checks" in building wxWidgets and see if the second problem goes away.

I already try this years ago, but the crash still exists.
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867

[blauzahn]

To me, that looks like undefined behaviour:

Code

void ThreadSearch::SetManagerType(ThreadSearchViewManagerBase::eManagerTypes mgrType)
{
    // Is type different from current one ?
    if ( mgrType != m_pViewManager->GetManagerType() )
    {
        // Get show state and destroy current view manager.
        bool show(true);
        if ( m_pViewManager != NULL )          // <---------------- UB
        {
            show = m_pViewManager->IsViewShown();
            m_pViewManager->RemoveViewFromManager();
            delete m_pViewManager;
        }

        // Create and show new view manager.
        m_pViewManager = ThreadSearchViewManagerBase::BuildThreadSearchViewManagerBase(m_pThreadSearchView, true, mgrType);
        m_pViewManager->ShowView(show);
    }
}

A null-pointer check AFTER having dereferenced m_pViewManager.
If memory serves me, this in combination with "-fno-delete-null-pointer-checks"
led to bugs like heartbleed.

obfuscated:

If an valid optimisation breaks users code then the code is broken and must be fixed.
Disabling specific optimisations is only a short term workaround!

I agree with that.

Cheers!