The 09 March 2019 build (11579) is out.

[raynebc]

I went into "Plugins>Manage plugins", selected all plugins (since all were enabled by default) and clicked Disable.  After it spent several seconds disabling them one by one, the program crashed.  I tried the process again and it crashed immediately after the dialog displays that it is disabling FortranProject.  So I decided to open C::B, disable a set of 10 plugins at a time, use "Save everything" and restart the IDE just so I could make progress.  After disabling the first couple sets this way I saw the number of failed assertion messages had decreased.  Ultimately, I found that attempting to disable the "FortranProject",  "Symbol Table Plugin" or "Thread Search" plugins (even individually) causes the IDE to immediately crash, so I skipped them.  I was able to disable all plugins other than those 3.  After doing so, I only have to click Continue 16 times to get into the IDE when I open it during a Remote Desktop session.

[Miguel Gimenez]

The Thread Search crash is known (ticket 777) and linked to the Reopen Editor crash in ticket 807.

The Fortran Project crash has the same origin (use-after-free), but in this case the solution is easy: remove the call to Destroy() in FortranProject::RemoveLogWindow(bool appShutDown). I will try to report this to Darmar.

At least three plugins fail due to this use-after-free issue; Probably in old SDK code the cbEVT_REMOVE_LOG_WINDOW event didn't delete the window, but now it does and this plugins are not aware of the change.

EDIT: I can't reproduce the Symbol Table plugin crash.

[oBFusCATed]

raynebc: What are the exact steps to reproduce the asserts? Start codeblocks from a rdesktop terminal?

[raynebc]

All I have to do is remote desktop from computer A to computer B, and while remotely operating computer B, launch this nightly release of Code::Blocks on computer B.  Both computers in this scenario are running Windows 7 x64 Pro, although I'm not sure if that's relevant.  Most of the time, when I run into problems with programs not working in a Remote Desktop session it's involving limitations with the session's display such as no support for hardware acceleration (Mozilla Firefox has had problems with this off and on).

[oBFusCATed]

Can you try older night builds and 17.12? The goal is to see if this issue is caused by the switch to wx3.1 and 64bits.

[raynebc]

As per my previous posts, 17.12 works fine in this scenario and I am using it.  I was having trouble getting the spell checking features working when I noticed that it has to be enabled manually at the bottom right corner of the IDE, even though the plugin itself was already enabled.  After I right clicked on it and opted to "enable spell check", it worked the way I was expecting (underlines words that it doesn't recognize, has a context menu for underlined words, etc).  I'm not sure if it got turned off somehow, or one of the C::B releases eventually required turning it on manually, but I suppose I missed this step somewhere.

When I launch the 12-9-2017 nightly (WX 303, x64), it loads without any failed asserts.

When I launch the 4-29-2018 nightly (WX 303, x64), it loads without any failed asserts.

When I launch the 5-10-2018 nightly (WX 311, x64), it loads with failed asserts.

By the way, is there a way to have the spell checker plugin display a list of words in the active project that are flagged as misspelled, so I can easily look for real typos in my comments?  Manually skimming through source files one at a time isn't a good way to do this, and I have some comment typos that have been present for years mostly because I knew of no efficient way to find them.

[oBFusCATed]

Ok, so it seems the move to wx3.1 is causing it. Unfortunately I have no way to reproduce this, because I don't have two windows pcs...

[raynebc]

It probably mostly just matters that the remotely controlled computer is running Windows.  You could possibly use any RDP client to connect with for the sake of testing (ie. I have an RDP client on my cell phone).

Edit:  Oddly, I RDP'd into the computer from the Android phone and launched this nightly build, and the assert messages did NOT display.  It must depend on the RDP client settings too, perhaps third party implementations manage to avoid this particular issue.

[gd_on]

Could these problems with wxAssert be linked with a change in default configuration file (config.gcc) for a msw build.
In wx 2.8.12 we have :

Code

# Should __WXDEBUG__ be defined? The default value "default" means that it will
# be defined if BUILD=debug and not defined if BUILD=release. [0,1,default]
DEBUG_FLAG ?= default

In wx 3.11 (or 12) we have :

Code

# Value of wxDEBUG_LEVEL. The default value is the same as 1 and means that all
# but expensive assert checks are enabled, use 0 to completely remove debugging
# code. [0,1,default]
DEBUG_FLAG ?= 1

May be for a wx release build, it should be nice to force DEBUG_FLAG=0 (or DEBUG_FLAG=default) on the build command.
Those wxAssert are very annoying and, as far I can see, are more warnings than errors (but nevertheless, they indicate that something is not correct in the code !).
Effectively, when you see a dialog box with such assert, you can check a box to avoid all other asserts, but it's still annoying because you have to do that each time you launch your code using wxwidgets.
Has anybody tried such config option ?

gd_on

[oBFusCATed]

There is a documented way to do this for wx>=3.x. We don't do this because we want to catch as many errors as we can. And we're still in a transition period. Especially on windows. I guess we could build final releases without wx asserts, but I'd prefer if we keep the asserts in night builds.

So if you see an assert don't hesitate to report it on the forum or the ticket page in sf.net. It is always a bug.

[raynebc]

I've confirmed that if I RDP into the Windows computer via Android phone, launch this nightly build (it starts without any asserts), disconnect and then RDP into the Windows computer from a Windows computer, C::B immediately starts the same set of assert messages even though it was already running.  So this reaction occurs when the program detects the display has changed, and not just during launch.  After I clicked continue through the asserts, the IDE seemed to resume normal function.

Should I put an enhancement request on the bug tracker about a way to list all words flagged by the spell checker?  Having the option to sort this list would also be very handy so I could ignore variable names and look for truly misspelled words.

[oBFusCATed]

Should I put an enhancement request on the bug tracker about a way to list all words flagged by the spell checker?  Having the option to sort this list would also be very handy so I could ignore variable names and look for truly misspelled words.

Yes... But if someone would implement it is another matter...

[raynebc]

Bummer.  Guess there's no efficient way to spell check an entire project short of feeding all of the comment lines into a word processor.

[oBFusCATed]

You're a programmer, you can look at the source and add the features missing in it. It is not that hard. 

[raynebc]

It would take me enormously longer than somebody who already has a meaningful amount of experience working with:
1.  The Code::Blocks source code
2.  C++
3.  wxWidgets