64 bit release (Vista) and missing controls

[John Roberts]

wxWidgets trunk on Vista64, MingW compilers

 

I have a small project that creates a dialog that is populated by a FlexGridSizer with 2 rows and 3 columns. There are wxStaticText controls in the 1st column, Combo and TextCtrl in the 2nd column, Button and BoxSixer with 2 buttons in the 3rd column.

 

With 32 bit debug and release projects it shows as intended.

With 64 bit debug it is also ok.

With 64 bit release only the 2nd column shows and the dialog is sized to suit. The other controls are there somewhere because I can tab to them. No matter what I resize the dialog to, none of the other columns are visible.

 

Any ideas?

Thanks, John

[John Roberts]

It looks like I was linking to the debug libs. Now that I have sorted the lib issue, the dialog doesn't get to show at all in release64. Instead I get a dialog captioned "wxWidgets Debug Alert" and message (503): assert "" failed: the path shouldn't contain file name nor extension

No help there as to where it occurs and it doesn't happen in debug.

 

Using a file contents search I found it in filename.cpp in function

void wxFileName::Assign(const wxString& fullpathOrig,
                        const wxString& fullname,
                        wxPathFormat format)

line 503

#ifndef __VMS
   // This test makes no sense on an OpenVMS system.
   wxASSERT_MSG( nameDummy.empty() && extDummy.empty(),
                  wxT("the path shouldn't contain file name nor extension") );
#endif

 

I guess this is called somewhere by wxApp at startup or by wxDialog.ShowModal()? I haven't got around to looking yet but odd it doesn't occur in debug build.

Cheers, John

[John Roberts]

Apologies for the html format in the previous posts. I had my news settings at plain text but this was the first time posting via google groups and it uses the mail settings.

 

I have stripped the prog down to a .h and .cpp file. These are below.

It still asserts as previously in Release64 but not in release32/debug32/64.

I tried wxMessageBox as the first line in HCtrlApp::OnInit() and the assert occurs before that. No text on the message dialog I assume because at that stage there is no wxString.

Somewhere it calls filename.cpp function void wxFileName::Assign(...) at startup.

Difficult to trace through the macros etc even in debug build.

Any ideas welcomed.

 

-----------------------This is the header-------------------------------------

 

#ifndef HCTRLAPP_H
#define HCTRLAPP_H

 

#ifdef __BORLANDC__
 #pragma hdrstop
#endif

 

#include <wx/app.h>

 

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

 

DECLARE_APP( HCtrlApp)

 

#endif // HCTRLAPP_H

 

-----------------------------------------and this is the source---------------------------------------------------

 

#include "HCtrlApp.h"

 

IMPLEMENT_APP(HCtrlApp);

 

bool HCtrlApp::OnInit()
{
    //(*AppInitialize
    bool wxsOK = true;
    if ( wxsOK )
    {
     wxsOK = false;
    }
    //*)
    return wxsOK;

 

}

 

-----------------resource.rc-----------------------------------

//aaaa ICON "wx/msw/std.ico"

 

//#if defined(__WIN64__)
    #define WX_CPU_AMD64
//#else
//    #define WX_CPU_X86
//#endif

 

#include <wx/msw/wx.rc>

----------------------------------------------------

[Vadim Zeitlin]

On Fri, 20 Nov 2009 14:53:26 +0900 John Roberts <jo...@iinet.net.au> wrote:

JR> I have stripped the prog down to a .h and .cpp file. These are below.
JR> It still asserts as previously in Release64 but not in release32/debug32/64.
JR> I tried wxMessageBox as the first line in HCtrlApp::OnInit() and the assert occurs before that. No text on the message dialog I assume because at that stage there is no wxString.
JR> Somewhere it calls filename.cpp function void wxFileName::Assign(...) at startup.

There really seems to be something wrong with your build environment. Does
the minimal sample work for you (in release 64 bit build)?

Also, if you have troubles with release build only, try enabling debug
information for release builds of everything. This won't change the code
generated but will also create PDB files which will allow you to debug the
problem.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[John Roberts]

"Vadim Zeitlin" <va...@wxwidgets.org> said "There really seems to be

something wrong with your build environment. Does
the minimal sample work for you (in release 64 bit build)?"

That is far less minimal than the bare bones I posted, though I understand
that compiler flags etc might be configured in a way that mine might not be.

"try enabling debug information for release builds of everything. This won't
change the code
generated but will also create PDB files which will allow you to debug the
problem."

This may be so for VS but not MingW which is what I am using as I posted
initially. makefile.gcc is not configured for 64bit in any of the samples
and I haven't had time to look at switches etc to get it to work with 64.
Perhaps I should be using VS but I like the public domain IDE selection and
most work on other platforms and so avoid too many project changes.
I keep MingW, MingW64 cross and MingW64 native) in different C:\... dirs on
Vista.

I did think someone might be familiar enough with wxApp startup to know
where it might call "void wxFileName::Assign(...)" 3 times and crash -
before it gets to wxOnInit(). I have searched the wxApp/base/.h/cpp files
with no joy so perhaps it is probably a call from something else called by
wxApp.

I re-compiled wxWidgets again with readable output in wxFileName::Assign. In
either nameDummy or extDummy variables a single slash is returned from the
overloaded wxFileName::Assign that checks for UNC names by calling
IsUNCPath(). This occurs only in release and occurs 3 times on startup.

Works fine in debug build though but just not with release using either the
native or cross compilers. I am not convinced this is an environment
problem.

Thanks for replying
JR

[John Roberts]

As a follow up the full path name passed to the function Assign overload
that uses IsUNCPath() is "C:\" This happens 3 times with "C:\" and the same
result.

[iko...@earthlink.net]

Hi, John,

-----Original Message-----
>From: John Roberts <jo...@iinet.net.au>
>Sent: Nov 21, 2009 3:03 AM
>To: wx-u...@googlegroups.com
>Subject: Re: Re[2]: 64 bit release (Vista) and missing controls
>
>

>As a follow up the full path name passed to the function Assign overload
>that uses IsUNCPath() is "C:\" This happens 3 times with "C:\" and the same
>result.

Is you user have the proper access rights to "C:\"?

Thank you.

[John Roberts]

Access rights sufficient for the 64debug and 32 bit stuff to run.
Thanks

[Vadim Zeitlin]

On Sat, 21 Nov 2009 18:43:38 +0900 John Roberts <jo...@iinet.net.au> wrote:

JR> "Vadim Zeitlin" <va...@wxwidgets.org> said "There really seems to be
JR> something wrong with your build environment. Does
JR> the minimal sample work for you (in release 64 bit build)?"
JR>
JR> That is far less minimal than the bare bones I posted, though I understand
JR> that compiler flags etc might be configured in a way that mine might not be.

I'm not sure I understood me correctly. By "minimal" sample I mean
samples/minimal distributed with wxWidgets. Have you tried running it?

JR> I did think someone might be familiar enough with wxApp startup to know
JR> where it might call "void wxFileName::Assign(...)" 3 times and crash -
JR> before it gets to wxOnInit(). I have searched the wxApp/base/.h/cpp files
JR> with no joy so perhaps it is probably a call from something else called by
JR> wxApp.

Calling wxFileName::Assign() shouldn't be a problem. The fact that it
crashes is, of course.

JR> I re-compiled wxWidgets again with readable output in wxFileName::Assign. In
JR> either nameDummy or extDummy variables a single slash is returned from the
JR> overloaded wxFileName::Assign that checks for UNC names by calling
JR> IsUNCPath(). This occurs only in release and occurs 3 times on startup.

It doesn't seem normal that either of nameDummy or extDummy gets filled
with a slash but I still don't understand why should this result in a
crash.

[John Roberts]

----- Original Message -----
From: "Vadim Zeitlin" <va...@wxwidgets.org>
To: <wx-u...@googlegroups.com>
Sent: Sunday, November 22, 2009 7:56 PM
Subject: Re[4]: 64 bit release (Vista) and missing controls

JR> "Vadim Zeitlin" <va...@wxwidgets.org> said "There really seems to be
JR> something wrong with your build environment. Does
JR> the minimal sample work for you (in release 64 bit build)?"
JR>
JR> That is far less minimal than the bare bones I posted, though I
understand
JR> that compiler flags etc might be configured in a way that mine might not
be.

VZ " I'm not sure I understood me correctly. By "minimal" sample I mean

samples/minimal distributed with wxWidgets. Have you tried running it?"

I understood you perfectly. The text you omitted from my last post stated
that the makefile.gcc in the minimal sample (or any samples) does not work
with MinGW64. If someone could explain how to modify it or what command
line/variables/switches to use then I will gladly try it.

VZ "Calling wxFileName::Assign() shouldn't be a problem. The fact that it
crashes is, of course."

I do not call this. wxWidgets calls wxFileName::Assign() and crashes before
wxApp.OnInit()

VZ " It doesn't seem normal that either of nameDummy or extDummy gets filled

with a slash but I still don't understand why should this result in a
crash."

BackSlash actually and not normal that it only happens in release build.
Crashes probably because it is stripping the "\" and passing "C:" and not
"C:\" back from ::Assign() as a valid path in Windows.

extDummy gets filled with the backslash from "C:\" leaving "C:" and only in
release build, then it goes on to segfault/crash. No crash in debug mode.
This happens with all my projects in release 64 build. Debug64 still works
perfectly. This never used to happen until I updated from trunk after 6
months absence.
Regards, John

[Vadim Zeitlin]

On Mon, 23 Nov 2009 19:45:57 +0900 John Roberts <jo...@iinet.net.au> wrote:

JR> VZ " I'm not sure I understood me correctly. By "minimal" sample I mean
JR> samples/minimal distributed with wxWidgets. Have you tried running it?"
JR>
JR> I understood you perfectly. The text you omitted from my last post stated
JR> that the makefile.gcc in the minimal sample (or any samples) does not work
JR> with MinGW64. If someone could explain how to modify it or what command
JR> line/variables/switches to use then I will gladly try it.

If you can build your own example, can't you use the same
makefile/commands to build minimal.cpp too? I don't use mingw64 myself much
so I don't know what the problem is but I do remember being able to build
the samples whne using msys+configure+mingw64, so maybe this would be a
solution.

JR> VZ "Calling wxFileName::Assign() shouldn't be a problem. The fact that it
JR> crashes is, of course."
JR>
JR> I do not call this. wxWidgets calls wxFileName::Assign() and crashes before
JR> wxApp.OnInit()

I didn't say you called it, did I? All I meant was that there was nothing
wrong with the fact that it was called.

JR> VZ " It doesn't seem normal that either of nameDummy or extDummy gets filled
JR> with a slash but I still don't understand why should this result in a
JR> crash."
JR>
JR> BackSlash actually and not normal that it only happens in release build.
JR> Crashes probably because it is stripping the "\" and passing "C:" and not
JR> "C:\" back from ::Assign() as a valid path in Windows.
JR>
JR> extDummy gets filled with the backslash from "C:\" leaving "C:" and only in
JR> release build, then it goes on to segfault/crash. No crash in debug mode.
JR> This happens with all my projects in release 64 build. Debug64 still works
JR> perfectly. This never used to happen until I updated from trunk after 6
JR> months absence.

I.e. mingw64 worked for you correctly before? If so, it would be really
great if you could bisect this change as I have no idea about where could
such regression come from.

Thanks,

[John Roberts]

----- Original Message -----
From: "Vadim Zeitlin" <va...@wxwidgets.org>
To: <wx-u...@googlegroups.com>

Sent: Tuesday, November 24, 2009 1:02 AM
Subject: Re[6]: 64 bit release (Vista) and missing controls

As a follow up it appears that in release64 build at least with MinGW64 a
wxWidgets.exe does not read its own executable path properly and registers
only C:\ no matter where you place the exe. I do not know why. Placing the
exe on C:\ does not help things.

In debug build it does this properly and the vars passed to previously
discussed wxFileName::Assign() contain the correct startup dir no matter
where the exe is placed.
Regards, John

[John Roberts]

----- Original Message -----
From: "John Roberts" <jo...@iinet.net.au>
To: <wx-u...@googlegroups.com>
Sent: Tuesday, November 24, 2009 10:39 PM
Subject: Re: Re[6]: 64 bit release (Vista) and missing controls

>As a follow up it appears that in release64 build at least with MinGW64 a
>wxWidgets.exe does not read its own executable path properly and registers
>only C:\ no matter where you place the exe. I do not know why. Placing the
>exe on C:\ does not help things.

Hi Vadim
You were right about it not being a wxWidgets problem, I downloaded a recent
native MingW-w64 compiler/toolchain and recompiled wxWidgets. Release build
executables now work as they should.
Thank you for your help and time.
I will spend some time on the samples with Mingw-w64 and MSYS when I get
time. Also perhaps try a batch file with -e switch to override some makefile
parameters with env vars.
Regards, John