wxEntry(hInstance) fails in Release-Build only

[Karl Karpfen]

Hi,

I have a strange problem that happens in Release-Build only (Unicode
Release DLL). For some reasons I can't update to wxWidgets 3.0 now so every
hint/idea/suggestion on how to solve this with 2.8 is welcome!

I'm using a Windows-Application (WinMain()-entry point) that itself
accesses a DLL. This DLL initialises and uses wxWidgets, the main
application does not have any dependencies to wxWidgets. This is the code
inside the DLL that works smoothly when I run this software in Debug-Build:

if (!wxApp::GetInstance())
{
appThread=oapc_thread_create(appCreator,NULL);
if (!initValues.appThread) return -1;
for (int i=0; i<10; i++)
{
oapc_thread_sleep(100);
if (wxApp::IsMainLoopRunning()) break;
}
if (!wxApp::IsMainLoopRunning()) return -1;
}

This creates an own thread "appCreator" and afterwards checks for some time
if the wxWidgetsMainLoop is running. Within this thread wxWidgets is
initialised:

static void* appCreator(void* /*data*/)
{
const HINSTANCE hInstance =GetModuleHandle(NULL);
if ( !hInstance ) return NULL;
wxInitializer wxinit;
if ( !wxinit.IsOk() ) return 0; // failed to init wx
wxEntry(hInstance);
return NULL;
}

Here initialisation seem to fail in Release-Build in wxEntry(hInstance),
this function returns immediately. Since this happens in Release only, I
can't really check what the reason is, debugging does not work here.

Just to mention: For Linux function appCreator contains just this code
which works well in both, Debug and Release (using this code for Windows
does not solve the problem):

int argc=0;
wxEntry(argc,(char**)NULL);

So...anybody an idea what is wrong here?

Thanks!

[Vadim Zeitlin]

On Sun, 12 Oct 2014 09:38:14 -0700 (PDT) Karl Karpfen wrote:

KK> I have a strange problem that happens in Release-Build only (Unicode
KK> Release DLL). For some reasons I can't update to wxWidgets 3.0 now so every
KK> hint/idea/suggestion on how to solve this with 2.8 is welcome!

Unfortunately I haven't worked with 2.8 for half a decade, so I really
don't remember if wxEntry() worked differently in it. Even if you can't
update your production build to use 3.0, you should at least try to compile
an experimental build using it and see if the problem still occurs there.

KK> I'm using a Windows-Application (WinMain()-entry point) that itself
KK> accesses a DLL. This DLL initialises and uses wxWidgets, the main
KK> application does not have any dependencies to wxWidgets. This is the code
KK> inside the DLL that works smoothly when I run this software in Debug-Build:
KK>
KK> if (!wxApp::GetInstance())
KK> {
KK> appThread=oapc_thread_create(appCreator,NULL);
KK> if (!initValues.appThread) return -1;
KK> for (int i=0; i<10; i++)
KK> {
KK> oapc_thread_sleep(100);
KK> if (wxApp::IsMainLoopRunning()) break;
KK> }
KK> if (!wxApp::IsMainLoopRunning()) return -1;
KK> }

This is some really fragile code. You should post an event instead of busy
looping.

KK> static void* appCreator(void* /*data*/)
KK> {
KK> const HINSTANCE hInstance =GetModuleHandle(NULL);
KK> if ( !hInstance ) return NULL;
KK> wxInitializer wxinit;
KK> if ( !wxinit.IsOk() ) return 0; // failed to init wx
KK> wxEntry(hInstance);
KK> return NULL;
KK> }
KK>
KK> Here initialisation seem to fail in Release-Build in wxEntry(hInstance),
KK> this function returns immediately. Since this happens in Release only, I
KK> can't really check what the reason is, debugging does not work here.

Why not? First of all, nothing prevents you from enabling debug symbols
for the release build (and, in fact, a lot of people, including me, think
that you should always do it). Second, even without the symbols running the
program under debugger will at least allow you to check if any unexpected
exceptions happen.

My recommendation would be to rebuild with symbols and just step into
wxEntry() and see what's going on there.

Good luck,
VZ

[Karl Karpfen]

Post by Vadim Zeitlin
KK> Here initialisation seem to fail in Release-Build in
wxEntry(hInstance),
KK> this function returns immediately. Since this happens in Release only, I
KK> can't really check what the reason is, debugging does not work here.
Why not? First of all, nothing prevents you from enabling debug symbols
for the release build (and, in fact, a lot of people, including me, think
that you should always do it).

Simply because it does not work. I already enabled debug symbols for
release build and tried to step into it. It fails within wxEntry(), at some
point I just see next sub-function call but can't get into it. Seems the
compiler is doing some crap here since PDBs are in place and valid, but I
have no chance to go deeper.