wxsmith crashing after upgrade to Ubuntu 17.04

[oBFusCATed]

Do you have scrollbars in the wxsmith view? I see some UI problems when using the scrollbars.

[awake]

Yes, with the broken version(s) of C:B, wxsmith never renders the attached project correctly, and yes, there *would* be a scrollbar in the UI view if it rendered completely. So maybe the scrollbar problem is at the heart of this whole mess?

As I noted in my previous post, I was able to get a working version of C:B trunk by compiling against wxWidgets-2.8.12.

Out of curiosity, I went back to the virtual machine set up on my 4th-gen Core i5 computer and compiled wxWidgets 3.03 using --without-subdirs --enable-xrc --enable-unicode --enable-monolithic. I then compiled the C:B trunk against this version of wxWidgets, and it compiled with no problems. The result *mostly* works - it will render the project correctly, but when attempting to scroll down to see the rest of it, the rendering flickers, briefly showing the rest of the frame, but then blanking out. However, if I scroll down part way and hit F2 to make the logs disappear, it will show almost correctly - the exception  being that a spacer is showing up only as a line.

So, with additional curiosity, I came back to the laptop with the 7th-gen Core i5, uninstalled my now-working copy of C:B+wxWidgets 2.8, and  did the same as above - created a wxWidgets 3.03 monolithic library, and compiled a fresh version of the trunk against it. Again, it compiled fine, and again, it *mostly* works - same flickering when trying to scroll down to see the rest of the frame. This time, however, hitting F2 does not result in the frame showing correctly - the bottom part still briefly flickers and then blanks out. So again a slight difference in how it runs on this processor (or as you say, likely GPU) vs. the other.

But mostly is not good enough, so, I've gone back to the C:B + wxWidgets 2.8 version. Again, I don't know what, if anything, I will lose by running C:B off of 2.8 instead of 3.0, but AT LEAST IT WORKS!!!

And again, oBFfusCATed, thank you so very much for all the time you have taken on this. Even though my solution has turned out to be to regress to wxWidgets 2.8, I hope the experience provides some insights into ongoing or future problems that may show up as C:B continues to transition to wxWidgets 3.x!

[cacb]

I used to build my own version of Code::Blocks under Kubuntu based on Jens Lody tarballs, but lately it was very unstable so I thought I had done something wrong.

I cleaned up everything and installed C::B 16.01 from the Kubuntu 17.04 repository instead, but even this version crashes much to often to be comfortable a "save everything" every 30 seconds is my current mode. I cannot provide much detail, but somehow these issues seem related to this thread.

Just to let you know that there seems to be stability issues under recent *ubuntus.

[awake]

cacb, glad to know I'm not the only one! I hope my experience above will be helpful for you or others in finding a work-around.

[oBFusCATed]

Just to let you know that there seems to be stability issues under recent *ubuntus.

Have you disabled the symbol browser? If you're not using wxSmith then your issue is related to something else. In this topic we're discussing wxSmith related crashes.
Also to make your reports useful please provide backtraces. Here https://wiki.ubuntu.com/Backtrace you can read how to gather them.

[cacb]

Have you disabled the symbol browser?

Are you referring to the plugin called "Symbol Table Plugin" or something else? That plugin is currently enabled.

Reading through the thread I noticed "Settings -> Editor -> Code completion" which I now disabled.

If you're not using wxSmith then your issue is related to something else. In this topic we're discussing wxSmith related crashes.

I do use wxSmith, so it could very well be related to it.

Also to make your reports useful please provide backtraces. Here https://wiki.ubuntu.com/Backtrace you can read how to gather them.

I will have a look at that, thanks.

EDIT: I notice that I have a couple of pretty large files in /var/crash/
The latest one is called _usr_bin_codeblocks.1000.crash and is 21.2 MB
This is from a wxSmith session that crashed .

Would it be useful?

[oBFusCATed]

Would it be useful?

These are probably core files. So you can load them in gdb and then try to see if the backtrace produced by the bt or thread apply all bt commands is any useful.

@awake: The drawing artefacts should be fixed in rev 11086. Can you try it against wx3.0 and tell me if this really the case?

[awake]

Sure, I'll give it a try - but it will be tomorrow at the earliest; I'm away from the office today.

[awake]

oBFusCATed,

I was able to try this today - using revision 11087 rather than 11086 - on my virtual machine on the 4th-gen i5 processor. I compiled rev 11087 against a monolithic build of wxGTK 3.03. All went smoothly, and yes, the flickering is fixed and the scroll bars work smoothly. I haven't tried this on my laptop with the 7th gen i5 - which as noted above, seemed to be slightly less stable than the virtual machine - since I am actively back in process on a project, and, given that I have a working copy of C:B based on wxGTK 2.8, I didn't want to take the time to uninstall and re-install - "if it ain't broke, don't fix it."

Again, thanks so much for your work and your patient guidance through this process!

[awake]

oBFusCATed,

I also had a chance to set up a virtual Ubuntu 17.04 machine on my laptop with the 7th-gen i5 processor. There too the problem with the flickering / scrollbars appears to be fixed.

In the meantime, however, I've noticed a different problem, but I'm not sure if it counts as a wxsmith problem or a wxWidgets problem.

In the newer versions of wxWidgets (e.g., 3.0 and up), there is a recommendation that a control included inside a static box sizer should be created with the static box (contained within the sizer) as the parent, rather than the panel or other window that is normally used as the parent. Why does this matter? Well, it probably doesn't, most of the time ... until I spent two hours trying to figure out why I couldn't get drag-and-drop to work on a listbox inside a static box sizer. If the listbox is in a regular sizer, drag-and-drop works fine; if it is inside a static box sizer AND the static box is used as the parent, it also works fine. But if it is in a static box sizer and the underlying panel (for example) is the parent -- which is how wxsmith currently constructs the code -- then drag-and-drop will not work, and as I can testify there is no obvious reason why not.

As I said, it could be argued that this is a wxWidgets problem ... but they DO recommend using the static box as the parent, and if that is done (for all of the widgets that are inside the static box sizer), then drag and drop works as advertised ... so perhaps wxsmith ought to be changed to reflect that recommendation?

I'm also not sure if this is the appropriate way or place to bring this up - happy to take guidance on how I should offer this suggestion!

[oBFusCATed]

As I said, it could be argued that this is a wxWidgets problem ... but they DO recommend using the static box as the parent, and if that is done (for all of the widgets that are inside the static box sizer), then drag and drop works as advertised ... so perhaps wxsmith ought to be changed to reflect that recommendation?

Do you have a link with their recommendation?

[awake]

Here you go - look under the Detailed Description: http://docs.wxwidgets.org/3.0/classwx_static_box.html

On looking back at it, it is not a very strongly worded recommendation: "Note that while the previous versions required that windows appearing inside a static box be created as its siblings (i.e. use the same parent as the static box itself), since wxWidgets 2.9.1 it is also possible to create them as children of wxStaticBox itself and you are actually encouraged to do it like this if compatibility with the previous versions is not important." (my emphasis added)

Certainly they do not spell out what the implications are for doing it the old way, e.g., that DnD won't work. (I wonder if anything else might not work properly in this situation - I've got some old gremlins that I've worked around, that might possibly be related to a similar issue ... have to do some digging. My guess is that the static box is "on top of" the other widgets, so they are not getting "seen" - but my guess probably reveals more about my ignorance of the inner workings of wxWidgets than anything else!)

I tried a simple test - create a frame, sizer, panel, sizer. Inside are two sizers, one a regular sizer and one a static box sizer. Inside each is a list box, set up to accept drag-and-drop files. Created the "old" way (as wxsmith does it now), the list box inside the regular sizer works just fine; the one in the static box is oblivious to attempts to drag and drop. I've come up with three possible alternatives:

• Work around: Set the static box associated with the static box sizer as the drag and drop target, but code it to put the results in the desired widget. For the current app, this will work fine, and it's an easy work-around. Possible problem: often I have more than one widget inside a static box sizer, so the question will be whether more than one of them requires DnD, or whether it will be confusing to drop files on, say, an edit control only to see them show up in the list box.
• Alter wxsmith by having it set all widgets inside a static box sizer to have their parent as the static box associated with the sizer. Note that if you set just one of the widgets to be parented by the static box, but the rest to be as normal (e.g., parented by the panel), the other widgets do not display correctly. However, if you set all of the widgets to the static box parent, they all display correctly, work correctly, and individually accept DnD. I tested this by adjusting the wxsmith generated code - but obviously, the next time I tweak the UI using wxsmith, all of those changes will get overwritten. Possible major problem: wxsmith would have to distinguish whether it was designing for pre-2.91 or post-2.91 wxWidgets, since parenting by the static box would apparently not work in pre-2.91. (See more reflection on this problem below.)
• Possible alternative work around, though I haven't tried it: perhaps one could let wxsmith generate its code, and then after that re-parent each of the widgets inside the static box sizer. I'll have to give that a try to see if it works. Again, I assume it would have to be all widgets, not just some, in order to avoid display problems.

After thinking it through systematically in the list above, honestly, my best guess is that it would be better to leave wxsmith alone for the moment, and instead encourage wxWidgets to document this peculiarity of behavior and publish the possible work-arounds. My thinking is that there is probably still a large user base using pre-2.91 wxWidgets, and others who may switch from, say, 3.x to 2.8 because of problems - which would then break all of the code that wxsmith would have built - and it could get awfully confusing trying to anticipate which version is going to be used when.

[oBFusCATed]

Can you try to reproduce this problem in a wx sample and try to ask on same of wx's mailing lists if this is a bug or this is expected problem that couldn't be solved?
We could modify wxsmith, but we need to keep it compatible, so it can still generate wx2.8 code. Parts of c::b are done with wxsmith...

[awake]

Sure, I can give that a whirl. As noted, I came to the conclusion that it would be better NOT to try to change wxsmith - since it still needs to support 2.8. I'd say wx could label it a bug, or could simply offer [more easily found] clarity about the inconsistent behavior.

[awake]

I have created a sample program to illustrate the problem, which I've included below in case anyone is interested. The problem may be limited to Linux (wxGTK) - ? In any case, I have reported it through the wxWidgets bug tracker, but since this is my first report, it will have to pass through the moderator(s). We'll see what happens ...

On Linux (maybe also Windows/MingW??), the following code can be compiled via command line as follows: g++ example.cpp `wx-config --cxxflags --libs` -o example

When run, the leftmost and rightmost listboxes will accept drag-and-drop of files from a browser, but the middle one will not; the difference is whether the parent is the underlying panel (appropriate for 2.8 builds, and how wxsmith currently generates the code) or is the static box attached to the wxStaticBoxSizer.

Code

#include "wx/wxprec.h"

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#ifndef WX_PRECOMP
#include "wx/wx.h"
#endif

#include <wx/app.h>
#include <wx/frame.h>
#include <wx/listbox.h>
#include <wx/menu.h>
#include <wx/panel.h>
#include <wx/sizer.h>
#include <wx/dnd.h>
#include <wx/intl.h>
#include <wx/string.h>


class testApp : public wxApp
{
    public:
        virtual bool OnInit();
};


class testFrame: public wxFrame
{
    public:

        testFrame(wxWindow* parent,wxWindowID id = -1);
        virtual ~testFrame();

    private:

        void OnQuit(wxCommandEvent& event);

        wxListBox* lbPlain;
        wxListBox* lbStatic1;
        wxListBox* lbStatic2;

        DECLARE_EVENT_TABLE()
};


class DF : public wxFileDropTarget
{
    public:

        DF ( wxListBox * lb_target );

        virtual bool OnDropFiles ( wxCoord x, wxCoord y, const wxArrayString & files );

    protected:

        wxListBox * m_target;
};


IMPLEMENT_APP(testApp);


bool testApp::OnInit()
{
    testFrame* Frame = new testFrame(0);
    Frame->Show();
    SetTopWindow(Frame);
    
    return true;
}


//#include <wx/msgdlg.h>


BEGIN_EVENT_TABLE(testFrame,wxFrame)
END_EVENT_TABLE()


testFrame::testFrame(wxWindow* parent,wxWindowID id)
{
    wxBoxSizer* bsOuter;
    wxPanel* 	Panel1;
    wxBoxSizer* bsInner;
    wxBoxSizer* bsPlain;
    wxStaticBoxSizer* bsStaticBox1;
    wxStaticBoxSizer* bsStaticBox2;
  
    Create(parent, id, wxEmptyString, wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE, _T("id"));

    // Create the basic foundation: frame contains a standard box sizer (bsOuter)
    // which contains a panel (Panel1) which contains a standard box sizer (bsInner)

    bsOuter = new wxBoxSizer(wxHORIZONTAL);
    Panel1 = new wxPanel(this, wxID_ANY);
    bsInner = new wxBoxSizer(wxHORIZONTAL);
 
    // Create a standard sizer containing a listbox and place it in the inner sizer    

    bsPlain = new wxBoxSizer(wxHORIZONTAL);
    lbPlain = new wxListBox(Panel1, wxID_ANY);
    lbPlain->SetMinSize(wxSize(200,400));
    bsPlain->Add(lbPlain, 1, wxALL|wxEXPAND, 5);
    bsInner->Add(bsPlain, 1, wxALL|wxEXPAND, 5);

    // Create a Static Box sizer containing a listbox and place it in the inner sizer
    // (next to the "plain" sizer created above). Note that the list box it contains is
    // created according to the pre-2.9.1 rules, i.e., parent is Panel1

    bsStaticBox1 = new wxStaticBoxSizer(wxHORIZONTAL, Panel1, _("Static Box Sizer 1"));
    lbStatic1 = new wxListBox(Panel1, wxID_ANY);
    bsStaticBox1->Add(lbStatic1, 1, wxALL|wxEXPAND, 5);
    bsInner->Add(bsStaticBox1, 1, wxALL|wxEXPAND, 5);

    // Create another Static Box sizer containing a listbox and place it next to the
    // bsStaticBox1 created above. Note that the list box this one contains is
    // created according to the 2.9.1 and above rules, i.e., parent is the wxStaticBox
    // contained within the Static Box sizer.

    bsStaticBox2 = new wxStaticBoxSizer(wxHORIZONTAL, Panel1, _("Static Box Sizer 2"));
    lbStatic2 = new wxListBox(bsStaticBox2->GetStaticBox(), wxID_ANY);
    bsStaticBox2->Add(lbStatic2, 1, wxALL|wxEXPAND, 5);
    bsInner->Add(bsStaticBox2, 1, wxALL|wxEXPAND, 5);

    Panel1->SetSizer(bsInner);
    bsInner->Fit(Panel1);
    bsInner->SetSizeHints(Panel1);
    bsOuter->Add(Panel1, 1, wxALL|wxALIGN_CENTER_HORIZONTAL|wxALIGN_CENTER_VERTICAL, 5);
    SetSizer(bsOuter);
    bsOuter->Fit(this);
    bsOuter->SetSizeHints(this);

    lbPlain->SetDropTarget(new DF(lbPlain));
    lbStatic1->SetDropTarget(new DF(lbStatic2));
    lbStatic2->SetDropTarget(new DF(lbStatic2));
}


testFrame::~testFrame()
{
}


void testFrame::OnQuit(wxCommandEvent& event)
{
    Close();
}


DF::DF ( wxListBox * lb_target )
{
    m_target = lb_target;
}


bool DF::OnDropFiles ( wxCoord x, wxCoord y, const wxArrayString & files )
{
    m_target->Append(files);

    return true;
}