Author Topic: wxWidgets 3.1.5  (Read 2029 times)

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
wxWidgets 3.1.5
« on: March 11, 2021, 06:26:35 pm »
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.
« Last Edit: March 11, 2021, 06:57:14 pm by gd_on »
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #1 on: March 11, 2021, 06:54:33 pm »
Cannot reproduce with MinGW64 and binutils 2.30, but I am generating 32 bits binaries.

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #2 on: March 11, 2021, 07:15:03 pm »
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.
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #3 on: March 11, 2021, 07:29:35 pm »
Did you try renaming default.conf?

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #4 on: March 11, 2021, 07:50:41 pm »
I din't ... but after a rename, and a new default.conf creation by C::B, the problem is still there.
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #5 on: March 11, 2021, 07:52:19 pm »
Can you attach a stack trace?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #6 on: March 11, 2021, 10:03:24 pm »
Have you tried to reproduce this in wx-samples? Does the choice (widgets probably) sample works correctly with your build?
(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!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #7 on: March 12, 2021, 09:50:36 am »
@ 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.
« Last Edit: March 12, 2021, 02:42:05 pm by gd_on »
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #8 on: March 12, 2021, 10:30:20 am »
You need a debugger and possibly symbols. No need to build non-optimized builds.
(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!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
[Solved] Re: wxWidgets 3.1.5
« Reply #9 on: March 12, 2021, 07:12:23 pm »
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.
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #10 on: March 13, 2021, 11:30:53 am »
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.
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #11 on: March 13, 2021, 11:48:24 am »
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?.
« Last Edit: March 13, 2021, 12:08:23 pm by Miguel Gimenez »

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #12 on: March 13, 2021, 12:29:06 pm »
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.
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #13 on: March 13, 2021, 12:58:31 pm »
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.
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #14 on: March 13, 2021, 08:31:17 pm »
Now I can reproduce, this is the stack trace:

Code
#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?)

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #15 on: March 13, 2021, 08:47:38 pm »
Can you check the attached patch?

The code in that function is very strange, why use
Code
m_path=wxString(m_fe->GetFullPath(ti).c_str());
instead of just
Code
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.
 
« Last Edit: March 13, 2021, 09:26:54 pm by Miguel Gimenez »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #16 on: March 14, 2021, 12:27:50 am »
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.
(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!]

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #17 on: March 14, 2021, 10:51:15 am »
FileExplorerUpdater::Update() and VCSFileLoader::Update() are called (or should be called) from the main thread and they start the threads:
Code
    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

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #18 on: March 14, 2021, 10:51:48 am »
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 ?
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline Miguel Gimenez

  • Lives here!
  • ****
  • Posts: 711
Re: wxWidgets 3.1.5
« Reply #19 on: March 14, 2021, 07:41:01 pm »
I have just created ticket 1079 with a patch.


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #20 on: March 15, 2021, 01:38:18 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().
(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!]

Offline sodev

  • Regular
  • ***
  • Posts: 429
Re: wxWidgets 3.1.5
« Reply #21 on: March 15, 2021, 04:04:27 am »
wxEmptyString is just a wxChar*, this might lead to some surprises in certain situations, but otherwise it might be a bit faster than wxString().

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #22 on: March 15, 2021, 09:28:26 am »
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.
(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!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #23 on: March 15, 2021, 10:03:42 am »
Is speed a real problem in that case ?
And in the official documentation :
Code
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 !
« Last Edit: March 15, 2021, 06:47:44 pm by gd_on »
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline sodev

  • Regular
  • ***
  • Posts: 429
Re: wxWidgets 3.1.5
« Reply #24 on: March 15, 2021, 06:26:38 pm »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #25 on: March 15, 2021, 08:41:25 pm »
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%.
(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!]

Offline LETARTARE

  • Regular
  • ***
  • Posts: 445
  • L'ami de l'homme.The friend of man.
Re: wxWidgets 3.1.5
« Reply #26 on: March 17, 2021, 05:52:53 pm »
Where did you find this version 'wxWidget-3.1.5' ?
CB-rev12446, plugins : AddOnForQt-3.3 sdk260
1-Win7 Business Pack1 64bits : wx-3.1.5, gcc-8.1.0,
2-Vista Business Pack2 32bits : wx-3.1.4, gcc-8.1.0
3-OpenSuse-15.2-Leap 64bits : wx-3.03, gcc-7.5.
=> !! The messages are translated by Deepl !!

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #27 on: March 17, 2021, 06:23:30 pm »
« Last Edit: March 17, 2021, 06:56:12 pm by gd_on »
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #28 on: March 17, 2021, 06:31:44 pm »
gd_on: It is best to describe this as wx-master and specify a commit.
(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!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 650
Re: wxWidgets 3.1.5
« Reply #29 on: March 17, 2021, 06:41:53 pm »
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 ...
Windows 10 64 bits (21H1), svn C::B (last version or almost!), wxWidgets 3.1.5, Msys2 Compilers 10.3.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (sjlj, posix in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13311
    • Travis build status
Re: wxWidgets 3.1.5
« Reply #30 on: March 17, 2021, 08:19:27 pm »
Then it is wx-master for you... It is better to describe it like this, if you don't want to confuse people.
(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!]