I'm trying to compile under Windows 10, Code::Blocks (last svn 12302) with wxWidgets 3.1.5 (just to try because I have the feeling that the release is almost ready !).
Compilation seems OK (if I use a Mingw64 distribution with binutils 2.35). But, when starting C::B, I obtain an assert message telling me a problem in GetString(), len!=(-1) msw/choice.cpp (369). This assert on that line of code was not present in previous 3.1.4 version. If I comment line 369 in msw\choice.cpp, I have no more this assert Message, but it's probably not a good idea.
Problem in wxWidgets msw code or in C::B ? I don't know.
Cannot reproduce with MinGW64 and binutils 2.30, but I am generating 32 bits binaries.
I don't think it's a 32/64 bits problem. It looks more as a GetString call with a string not correctly initialised the first time.
Did you try renaming default.conf?
I din't ... but after a rename, and a new default.conf creation by C::B, the problem is still there.
Can you attach a stack trace?
Have you tried to reproduce this in wx-samples? Does the choice (widgets probably) sample works correctly with your build?
@ Miguel : There is no RPT file produced, but I don't think it's what you want. How do you produce a stack trace ? Is it necessary to have a debug version of C::B ?
@ oBFusCATed : I don't have any (such) messages in any samples I tried. Particularly, I tried "choice" in "wxwidgets" sample and it seems to work as it should.
You need a debugger and possibly symbols. No need to build non-optimized builds.
OK, solved.
I have added DEBUG_FLAG=0 in my command line to build wxwidgets.
Until now, I had DEBUG_LEVEL=0. I have seen that somewhere, some time ago and until now I had no problems. But the parameter in the command line is DEBUG_FLAG, which is 1 by default and set a wxDEBUG_LEVEL (not DEBUG_LEVEL). Now, with DEBUG_FLAG=0, it forces wxDEBUG_LEVEL to 0, and I am no more annoyed by this wxAssert Message. May be, it masks an other problem, but it works as in 3.1.4 version.
In parallel, I had signaled this behaviour on wxtrac.
Here is their answer :
Quote
Comment (by MaartenB):
FYI, it was added in https://github.com/wxWidgets/wxWidgets/pull/2169
Apparently you call `wxChoice::GetString()` with invalid index `-1`. The
behaviour is also documented in
https://docs.wxwidgets.org/trunk/classwx_choice.html#a3a89e3eef072e7914f8408154b4a1daa
--
Ticket URL: <https://trac.wxwidgets.org/ticket/19096#comment:3>
So, for them, there is a call to GetString with incorrect value.
That was clear, the problem is finding where the call is, and the stack trace is the guide.
EDIT: can you try starting C::B from command line using --safe-mode switch?.
running codeblocks from the command line give this :
- without option : give the message; Nothing seems to be created (no log, no txt file), but may be I should use a C::B code compiled with -g and also perhaps wxwidgets).
- with --safe-mode : no message.
I tried to disable plugins and re-enable them one by one.
The guilty seems to be FileManager plugin : no message if it is disabled alone, all other activated.
Now I can reproduce, this is the stack trace:
#0 0x62da1cb8 in wxChoice::GetString(unsigned int) const () from C:\Windows\system32\wxmsw315u_gcc_custom.dll
#1 0x6c32422f in FileExplorerUpdater::Update (this=0x20572958, ti=...)
at G:\cbtrunk\src\plugins\contrib\FileManager\FileExplorerUpdater.cpp:153
#2 0x6c30a1ba in FileExplorer::OnTimerCheckUpdates (this=0x205c07e0)
at G:\cbtrunk\src\plugins\contrib\FileManager\FileExplorer.cpp:594
#3 0x62a43222 in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const ()
from C:\Windows\system32\wxmsw315u_gcc_custom.dll
#4 0x0028d57c in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Can you check the attached patch?
The code in that function is very strange, why use
m_path=wxString(m_fe->GetFullPath(ti).c_str());
instead of just
m_path=m_fe->GetFullPath(ti);
?
EDIT: around line 1260 there is an almost identical code snippet, you can still get an assert from it later.
Probably to break ref counting implementations and force an actual copy.
p.s. Is this code running on the main thread?
p.p.s. Please use wxString() instead of wxEmptyString.
FileExplorerUpdater::Update() and VCSFileLoader::Update() are called (or should be called) from the main thread and they start the threads:
void Update(const wxTreeItemId &ti); //call on main thread to do the background magic
void Update(const wxString &op, const wxString &source_path, const wxString &destination_path, const wxString &comp_commit); //call on main thread to do the background magic
With this patch, as it is, no more assert message (until the next one :( ). Thanks.
wxWidgets team say that there are other possible incompatibilities in version 3.1.5. I don't know if C::B is impacted.
Quote
Comment (by vadz):
I'm not sure where exactly is the code calling `GetString(-1)`, but it
should be fixed and not just hidden by disabling the asserts.
Note that this change was documented in the incompatible changes section
of the change log file:
{{{
- wxChoice::GetString() now consistently asserts when passed an invalid
index.
}}}
--
Ticket URL: <https://trac.wxwidgets.org/ticket/19096#comment:4>
Why do you say wxEmptyString should be avoided ?
I have just created ticket 1079 (https://sourceforge.net/p/codeblocks/tickets/1079) with a patch.
Quote from: gd_on on March 14, 2021, 10:51:48 AM
Why do you say wxEmptyString should be avoided ?
Because it is more expensive probably.
I'm seeing lots of commits in wx where they are removing wxT and they are replacing wxEmptyString with wxString().
wxEmptyString is just a wxChar*, this might lead to some surprises in certain situations, but otherwise it might be a bit faster than wxString().
sodev: Why faster? wxString() is the fastest possible way to initialize an empty string. The wxString(wxChar *) is something that should work for actual strings.
Is speed a real problem in that case ?
And in the official documentation :
wxString wxEmptyString
The global wxString instance of an empty string.
Used extensively in the entire wxWidgets API.
I have also seen that a few guys had problem with this wxEmptyString, but the doc seem to say it's good and used extensively. It's also said it's a wxString but effectively seen as a wxChar* inside C::B (which use it more than 600 times in it's workspace :-[). so ?? not so bad !
oBFusCATed: It is (only?) faster in situations where no temporary wxString object gets created. Right now only comparision against wxEmptyString that use a wxChar* overload comes into my mind. Maybe also method parameter initialization benefits, depends if direct initialization of a wxString from a wxChar* is faster than copy/move-initialization from a temporary wxString.
I've not measured, nor I've done any deep investigations.
I guess the difference is the same as std::string() and std::string("")...
The latter needs to find the end of the char* and do the copy, so it is obviously more expensive.
Does it matter in the real world - no, 99.9999%.
Where did you find this version 'wxWidget-3.1.5' ?
I follow it on github : https://github.com/wxWidgets/wxWidgets
gd_on: It is best to describe this as wx-master and specify a commit.
OK for wx-master.
It's effectively 3.1.5 today, but tomorrow, next week, ... it will probably be 3.2.0 !
For the commit, more difficult, it changes several times in a day ! ;D
And I build it very often ...
Then it is wx-master for you... It is better to describe it like this, if you don't want to confuse people.