News:

The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .

Main Menu

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

Started by ollydbg, October 11, 2017, 05:36:34 PM

Previous topic - Next topic
Print
Go Down Pages1 2 All
User actions

ollydbg

October 11, 2017, 05:36:34 PM Last Edit: October 14, 2017, 10:50:48 AM by ollydbg
I see the thread search plugin cause crash when initilized, here is the line it crashed:

Code Select

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 Select

[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 Select

...
[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 Select

[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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

oBFusCATed

#1
October 12, 2017, 09:27:50 AM
Are you sure everything is built with the same compiler? And you're using the correct wx libraries and headers?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ollydbg

#2
October 12, 2017, 12:12:12 PM
Quote from: oBFusCATed on October 12, 2017, 09:27:50 AM
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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#3
October 13, 2017, 04:49:31 PM
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 Select

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?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

BlueHazzard

#4
October 13, 2017, 05:05:51 PM Last Edit: October 13, 2017, 05:07:49 PM by 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 Select
In wxCommandEvent::GetString() const () (wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_custom.dll)
and a lot ???


QuoteDo I need to add the "-std=gnu++11" to build the wx library?
i have also not enabled c++11 for wx builds

ollydbg

#5
October 14, 2017, 03:02:33 AM Last Edit: October 14, 2017, 03:20:07 AM by 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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#6
October 14, 2017, 10:55:13 AM Last Edit: October 14, 2017, 11:00:10 AM by ollydbg
I just build a debug version of wx3.1 with the following command: (note I have -std=gnu++11)
Code Select

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 Select

    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;
    }
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#7
October 14, 2017, 03:57:15 PM
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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

BlueHazzard

#8
October 14, 2017, 05:44:30 PM
So if you apply this optimization patch the crash goes away? So this should be reported to gcc?

stahta01

#9
October 14, 2017, 07:50:12 PM Last Edit: October 14, 2017, 07:54:42 PM by stahta01
Quote from: BlueHazzard on October 14, 2017, 05:44:30 PM
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.

 
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

oBFusCATed

#10
October 14, 2017, 08:01:57 PM
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!
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

stahta01

#11
October 14, 2017, 09:32:46 PM Last Edit: October 14, 2017, 09:35:13 PM by stahta01
Quote from: oBFusCATed on October 14, 2017, 08:01:57 PM
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.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

ollydbg

#12
October 14, 2017, 11:26:56 PM Last Edit: October 14, 2017, 11:31:56 PM by ollydbg
Quote from: BlueHazzard on October 14, 2017, 05:44:30 PM
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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

ollydbg

#13
October 14, 2017, 11:35:10 PM
Quote from: stahta01 on October 14, 2017, 07:50:12 PM
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
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

blauzahn

#14
October 23, 2017, 09:20:44 PM

To me, that looks like undefined behaviour:

Code Select

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:
Quote
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!
Print
Go Up Pages1 2 All
User actions