Author Topic: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)  (Read 1103 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10369
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #15 on: October 24, 2017, 12:37:46 am »
To me, that looks like undefined behaviour:
I'll need a quote from the standard where they've made this undefined behaviour.
Newer compilers might delete the check, but this doesn't make the check undefined behaviour (if you find the quote from the standard, then I'll admit my mistake)!


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.
How is this related, to Code::Blocks where we don't care at all about security.
And it seems you're wrong, because by the looks of it (I have no time to read the whole report) heartbleed is just a logic error and nothing related to compilers or UB.

And finally how is this thing related to the original problem?
<debugger plugin maintainer>
(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!]

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4985
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #16 on: October 24, 2017, 01:59:17 am »

And finally how is this thing related to the original problem?

I agree, it is not related.
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.

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4985
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #17 on: October 24, 2017, 04:34:05 pm »
I see another strange issue, the combobox's content can't be saved after the dialog closed. When I close the option, and I see the combobox becomes "*.*" again. Any one can reproduce this issue? I'm on 32bit C::B build against wx3.1 under windows 7.

See image shot below:
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.

Offline danselmi

  • Developer
  • Almost regular
  • *****
  • Posts: 199
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #18 on: October 24, 2017, 09:56:14 pm »

And finally how is this thing related to the original problem?

I agree, it is not related.

It is not undefined behaviour. But the check is definitely too late. 4 lines above the m_pViewManager was already dereferenced.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10369
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #19 on: October 25, 2017, 12:04:39 am »
@ollydbg: Changing the value in the dialog works fine for me on linux with 3.1.1
<debugger plugin maintainer>
(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!]

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4985
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #20 on: October 28, 2017, 10:16:21 am »
@ollydbg: Changing the value in the dialog works fine for me on linux with 3.1.1
I debugged this issue under Windows7 for a while, and it is a bug.

For example, if I set the mask as "*.abc", which means I only want to search the files which has the file name pattern as "*.abc", I can see this value is correctly saved to the conf file.

Code: [Select]
<MASK>
<str>
<![CDATA[*.abc]]>
</str>
</MASK>

While, when I close the CB, and restart again, I see that the "*.abc" is correctly loaded and set the the value "ThreadSearchFindData". But the bad thing happens is when the combobox constructed, it was set the a default value "*.*", see the code below:
Code: [Select]
DirectoryParamsPanel::DirectoryParamsPanel(ThreadSearchFindData *findData, wxWindow* parent, int id, const wxPoint& pos,
                                           const wxSize& size, long WXUNUSED(style)):
    wxPanel(parent, id, pos, size, wxTAB_TRAVERSAL),
    m_pFindData(findData)
{
    const wxString choices[] = {};

    // begin wxGlade: DirectoryParamsPanel::DirectoryParamsPanel
    m_pSearchDirPath = new wxComboBox(this, controlIDs.Get(ControlIDs::idSearchDirPath), wxEmptyString,
                                      wxDefaultPosition, wxDefaultSize, 0, choices, wxCB_DROPDOWN|wxTE_PROCESS_ENTER);
    m_pBtnSelectDir = new wxButton(this, controlIDs.Get(ControlIDs::idBtnDirSelectClick), _("..."));
    m_pChkSearchDirRecursively = new wxCheckBox(this, controlIDs.Get(ControlIDs::idChkSearchDirRecurse), _("Recurse"));
    m_pChkSearchDirHiddenFiles = new wxCheckBox(this, controlIDs.Get(ControlIDs::idChkSearchDirHidden), _("Hidden"));
    m_pMask = new wxComboBox(this, controlIDs.Get(ControlIDs::idSearchMask), wxT("*.*"),
                             wxDefaultPosition, wxDefaultSize, 0, choices, wxCB_DROPDOWN|wxTE_PROCESS_ENTER);

    set_properties();
    do_layout();
    // end wxGlade
}

I see the ThreadSearchFindData will be updated in a event handler:
Code: [Select]
[debug]> bt 30
[debug]#0  ThreadSearchFindData::SetSearchMask (this=0xa93270c, searchMask=L"*.*") at D:\code\cb\cb_sf_git\trunk\src\plugins\contrib\ThreadSearch\ThreadSearchFindData.h:53
[debug]#1  0x0d331e37 in DirectoryParamsPanel::OnSearchMaskTextEvent (this=0xa976340, event=...) at D:\code\cb\cb_sf_git\trunk\src\plugins\contrib\ThreadSearch\DirectoryParamsPanel.cpp:103
[debug]#2  0x68702ec2 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  0x68703327 in wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#4  0x6885a3c0 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#5  0x68858f6a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#6  0x6885a709 in wxEvtHandler::TryHereOnly(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#7  0x6885a61a in wxEvtHandler::ProcessEventLocally(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#8  0x6885a505 in wxEvtHandler::ProcessEvent(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#9  0x68b1d5ea in wxWindowBase::TryAfter(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#10 0x6885a752 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#11 0x68973d5c in wxComboBox::MSWCommand(unsigned int, unsigned short) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#12 0x6893635b in wxWindow::HandleCommand(unsigned short, unsigned short, HWND__*) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#13 0x6893fdc9 in wxWindow::MSWHandleMessage(long*, unsigned int, unsigned int, long) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#14 0x68930a20 in wxWindow::MSWWindowProc(unsigned int, unsigned int, long) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#15 0x68938843 in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#16 0x75bc62fa in gapfnScSendMessage () from C:\windows\syswow64\user32.dll
[debug]#17 0x001308dc in ?? ()
[debug]#18 0x00000111 in ?? ()
[debug]#19 0x00050484 in ?? ()
[debug]#20 0x000a07fa in ?? ()
[debug]#21 0x689387d0 in wxWindow::SubclassWin(HWND__*) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#22 0x75bc6d3a in USER32!GetThreadDesktop () from C:\windows\syswow64\user32.dll
[debug]#23 0x689387d0 in wxWindow::SubclassWin(HWND__*) () from D:\code\wxWidgets-3.1.0\lib\gcc_dll\wxmsw310u_gcc_cb.dll
[debug]#24 0x75bc965e in USER32!GetWindow () from C:\windows\syswow64\user32.dll
[debug]#25 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:


Here, the value "*.abc" is just overwriten by the "*.*". Thus my customized value is lost.
I'm not sure why the event below happens.
Code: [Select]
void DirectoryParamsPanel::OnSearchMaskTextEvent(wxCommandEvent &event)
{
    m_pFindData->SetSearchMask(event.GetString());
    event.Skip();
}

In my original problem, a crash happens when we call "event.GetString()", but that is another crash issue, which can be workaround by adding the "O0" optimization decoration to the function(I wrote that in my previous posts).

 :(
« Last Edit: October 28, 2017, 10:18:29 am by ollydbg »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10369
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #21 on: October 28, 2017, 12:10:06 pm »
Works perfectly fine here. There is something broken in your build.
Do you see the same problem with the night build?
<debugger plugin maintainer>
(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!]

Online ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4985
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #22 on: October 28, 2017, 01:06:46 pm »
Works perfectly fine here.
You are using Linux, right?

Quote
There is something broken in your build.
Do you see the same problem with the night build?
This issue does not exist in nightly build which is wx2.8 based.
I suggest someone using wx3.1 based C::B under Windows would test it. Thanks.
« Last Edit: October 28, 2017, 01:12:54 pm by ollydbg »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10369
Re: Threadsearch plugin cause crash when initilized (wx3.1,C::B svn head)
« Reply #23 on: October 28, 2017, 04:46:32 pm »
Yes, linux, wx3.0.2 and wx-master all built with gcc-5.4. But I'm building for 64bit all the time. So it is not too relevant.
<debugger plugin maintainer>
(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!]