Starting wxWidgets from main() function

[Bruno]

Hello all,

I'm currently working on a function to start a wxWidgets application manually, whose only purpose is to show an image, using Codeblocks 8.04, with the help of wxSmith to make the interface.

Searching in the mailing lists and the definition of the macro IMPLEMENT_APP, I decided to break it in 2 parts, using the IMPLEMENT_APP_NO_MAIN then simulating the call of wxEntry within my function, as it is in IMPLEMENT_WXWIN_MAIN.

I've come up with the following code:

#include "MyClass.h"
#include "MyApp.h"

IMPLEMENT_APP_NO_MAIN(MyApp)

int MyClass::ShowImage(wxBitmap* BMP)
{
        wxMyApp* app = new MyApp();
        wxApp::SetInstance( app );

        wxGetApp().SetBitmap(BMP);      //workaround to load the image pointer into the app

        int argc=1;
        char** argv=(char**)malloc(sizeof(char*));
        argv[0]=(char*)malloc(sizeof(char)*strlen("Test"));
        strcpy(argv[0],"Test");

        return wxEntry(argc, argv);
}

The funny thing is that the above code compiles and runs perfectly when my project is compiled under "release" options of Codeblocks, but under the "debug" one it throws a SIGSEGV when it execute the "wxEntry" function. Anyone knows what detail I'm missing or if it is possibly a bug?

[Vadim Zeitlin]

On Tue, 14 Jul 2009 18:05:50 -0200 Bruno <johndoe...@gmail.com> wrote:

B> I've come up with the following code:
B>
B> #include "MyClass.h"
B> #include "MyApp.h"
B>
B> IMPLEMENT_APP_NO_MAIN(MyApp)
B>
B> int MyClass::ShowImage(wxBitmap* BMP)
B> {
B> wxMyApp* app = new MyApp();
B> wxApp::SetInstance( app );
B>
B> wxGetApp().SetBitmap(BMP); //workaround to load the image
B> pointer into the app

You can't create wxBitmaps before initializing the GUI so I don't know
where do you take wxBitmaps pointer from before wxEntry is called.

B> int argc=1;
B> char** argv=(char**)malloc(sizeof(char*));
B> argv[0]=(char*)malloc(sizeof(char)*strlen("Test"));
B> strcpy(argv[0],"Test");

FWIW you don't need to allocate argv dynamically and if you do, you need
to free it as wx won't do it. And while wx itself doesn't assume that argv
is NULL-terminated, functions called by it (e.g gtk_init()) might so I'd do
this instead

char *argv[] = { "test", NULL };
wxEntry(1, argv);

B> The funny thing is that the above code compiles and runs perfectly when my
B> project is compiled under "release" options of Codeblocks,

Try running it under valgrind (assuming you're under Linux) and you will
see that it doesn't run perfectly.

B> but under the "debug" one it throws a SIGSEGV when it execute the
B> "wxEntry" function.

Have you tried looking at the stack trace under debugger when it crashed?
VZ

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

[Iulian-Nicu Șerbănoiu]

Hi,

I personally wouldn't try to do extreme stuff with wxWidgets. Not that
the library cannot handle it, but you could run into serious trouble
doing so.

What you want to do can be made without doing all that hocus-pocus.

My advice:

1. First create a working program in the classic way (no hocus-pocus).
2. Then analyze if it can be done better and start doing the
hocus-pocus if necessary.
3. [not mandatory] I'd make sure it works on all platforms - at least
windows and a unix like version

Good luck,

Iulian

PS: Why would you do such things? Do you have any constraints?

--
Iulian Şerbănoiu
MinVG - http://minvg.sourceforge.net

[Bruno]

Hello, thanks for the input

> You can't create wxBitmaps before initializing the GUI so I don't know
> where do you take wxBitmaps pointer from before wxEntry is called.

Realized that today, the program wouldn't compile in Debian, so now I
changed the code in the MyClass.cpp to:


int MyClass::ShowImage(RgbMap* Map)
{
//LRgbMap is our class that stores an RGB image

wxMyApp* app = new MyApp();

wxApp::SetInstance( app );

wxGetApp().SetRgbMap(Map);

char *argv[] = { "test", NULL };

int argc=1;

return wxEntry(argc, argv);
}

Then, inside MyApp.cpp, I added the following code for OnInit():

bool MyApp::OnInit()
{
//(*AppInitialize
bool wxsOK = true;
//wxInitAllImageHandlers(); //Is this important? With it,
it wouldn't compile under Windows and in Debian

it worked fine without it
if ( wxsOK )
{
this->BMP=new wxBitmap();
ConvertRGBMapToWxBitmap(this->RgbMap,this->BMP);
wxShowImageFrame *Frame = new wxShowImageFrame(this->BMP);
Frame->Show();
SetTopWindow(Frame);
}
//*)
return wxsOK;
}

My test program is this:

int main()
{
Map=new RgbMap;
Mapa->ReadBMP("image.bmp");
MyClass::ShowRgbMap(Map);

Map2=new RgbMap();
Map->ReadBMP("image2.bmp");
MyClass::ShowRgbMap(Map2);

return 0;
}

So, if I got it right, it would show a frame with the "image.bmp" and
only after I close it the "image2.bmp" frame

would be shown.

With the code like that, it compiled under Debian and it was able to
create the window showing the image the first

time it was called, but it threw another SIGSEGV when I called the
function a second time. In Windows, the same code

worked under release configuration of Codeblocks as it was expected
but failed with debug

> Have you tried looking at the stack trace under debugger when it crashed?
> VZ

Under Windows it showed this:

#0 00000000 ??() (??:??)
#1 004894A6 wxWindow::MSWWindowProc(this=0x2a34938, message=28,
wParam=1, lParam=1468)

(../../src/msw/window.cpp:2707)
#2 004B7B9F wxTopLevelWindowMSW::MSWWindowProc(this=0x2a34938,
message=28, wParam=1, lParam=1468)

(../../src/msw/toplevel.cpp:372)
#3 0053B774 wxFrame::MSWWindowProc(this=0x2a34938, message=28,
wParam=1, lParam=1468)

(../../src/msw/frame.cpp:1101)
#4 004851E7 wxWndProc(hWnd=0x50472, message=28, wParam=1, lParam=1468)
(../../src/msw/window.cpp:2613)
#5 7E368734 USER32!GetDC() (C:\WINDOWS\system32\user32.dll:??)
#6 00050472 ??() (??:??)
#7 0000001C ??() (??:??)
#8 7E368816 USER32!GetDC() (C:\WINDOWS\system32\user32.dll:??)
#9 00485118 wxWindow::GetThemedBorderStyle(this=0x0) (../../src/msw/
window.cpp:1453)
#10 7E378EA0 USER32!DefWindowProcW() (C:\WINDOWS
\system32\user32.dll:??)
#11 00000000 ??() (??:??)

1. First create a working program in the classic way (no hocus-
pocus).

That's exactly what I did hehehe

PS: Why would you do such things? Do you have any constraints?

We're making a very easy to use image processing library in which the
studants can concentrate in the algorithms,

using C++ standard and without the need to understand how the Visual
Library works, so one of our ideas was to make

a method to simply show the image.

[Vadim Zeitlin]

On Wed, 15 Jul 2009 12:31:53 -0700 (PDT) Bruno <johndoe...@gmail.com> wrote:

B> int MyClass::ShowImage(RgbMap* Map)
B> {
B> //LRgbMap is our class that stores an RGB image

B> wxMyApp* app = new MyApp();
B> wxApp::SetInstance( app );
B>

B> wxGetApp().SetRgbMap(Map);
B>
B> char *argv[] = { "test", NULL };
B> int argc=1;
B>
B> return wxEntry(argc, argv);
B> }
B>
B> Then, inside MyApp.cpp, I added the following code for OnInit():
B>
B> bool MyApp::OnInit()
B> {
B> //(*AppInitialize
B> bool wxsOK = true;
B> //wxInitAllImageHandlers(); //Is this important? With it,
B> it wouldn't compile under Windows and in Debian

wxInitAllImageHandlers() is needed if you use any bitmap handlers for
loading BMP, PNG, JPEG, TIFF, ... data into wxBitmap. If you don't, then
you don't need it. In any case, it will always compile fine without this
call, it just wouldn't find the handler and so might fail to load the
bitmap when you try to do it.

B> it worked fine without it
B> if ( wxsOK )
B> {
B> this->BMP=new wxBitmap();
B> ConvertRGBMapToWxBitmap(this->RgbMap,this->BMP);
B> wxShowImageFrame *Frame = new wxShowImageFrame(this->BMP);
B> Frame->Show();
B> SetTopWindow(Frame);
B> }
B> //*)
B> return wxsOK;
B> }
B>
B> My test program is this:
B>
B> int main()
B> {
B> Map=new RgbMap;
B> Mapa->ReadBMP("image.bmp");
B> MyClass::ShowRgbMap(Map);
B>
B> Map2=new RgbMap();
B> Map->ReadBMP("image2.bmp");
B> MyClass::ShowRgbMap(Map2);
B>
B> return 0;
B> }

Except for the obvious memory leaks of RgbMap objects this looks fine.
So maybe the problem is that something is not de-/re-initialized properly.
To prevent this from happening you could always create wxTheApp only once
and call wxEntryStart() (and wxEntryCleanup()) once too instead of calling
wxEntry() multiple times. Although doing the latter should work too, of
course...

B> time it was called, but it threw another SIGSEGV when I called the
B> function a second time.

Do you have the output of "bt" from gdb for Linux?

B> Under Windows it showed this:
B>
B> #0 00000000 ??() (??:??)
B> #1 004894A6 wxWindow::MSWWindowProc(this=0x2a34938, message=28,
B> wParam=1, lParam=1468)

This is strange, I don't see where exactly does it crash. We can see
that this happens while processing WM_ACTIVATEAPP but there doesn't seem to
be any pointer dereferences in its handler. Maybe you could try to debug it
a bit by putting a breakpoint on "case WM_ACTIVATEAPP" in
src/msw/window.cpp and checking what happens there?

Regards,

[Dave Silvia]

Whilst the scatter gun approach is preferred by some, I prefer to include
only code which I will use. I don't generally use wxInitAllImageHandlers()
for this reason. Even in MDIBitmapBrowser, which uses a significant portion
of the various images 'recognized' by wxWidgets, I load individual image
handlers.

But, to each his own...

[ btw, sorry that the body of the response is not included... It's
terribly inconvenient to extract them in my email client when they are sent
as attachments instead of in the main message body... You understand, it's
a lot like inconsiderate folks who won't wrap their email 'properly' to fit
other group members' email clients... Some people can be so
inconsiderate!... ]

jmmomp:

Dave S.

Development with wxWidgets on MSWindows
http://tech.groups.yahoo.com/group/wxMS_developers/

wxWidgets Code Exchange
http://www.wxcodex.net/

----- Original Message -----
From: "Vadim Zeitlin" <va...@wxwidgets.org>
To: <wx-u...@googlegroups.com>
Sent: Thursday, July 16, 2009 7:21 AM
Subject: Re[2]: Starting wxWidgets from main() function

[Bruno]

B> time it was called, but it threw another SIGSEGV when I called the
B> function a second time.

 Do you have the output of "bt" from gdb for Linux?

I didn't understand what you meant by "bt", so I took the output at the moment of the second crash under Linux. Also, the problem is happening when the function wxTheApp->OnRun() is called in the program, as I will put later:

#0 0x7ff01d843de4    _L_unlock_163() (/lib/libpthread.so.0:??)
#1 0x7ff01d843de9    _L_unlock_163() (/lib/libpthread.so.0:??)
#2 0x7ff01d843b26    __pthread_mutex_unlock_usercnt() (/lib/libpthread.so.0:??)
#3 0x7ff01e2e2099    wxMutexInternal::Unlock() (/usr/lib/libwx_baseu-2.8.so.0:??)
#4 0x7ff01eb5ee9a    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#5 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#6 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#7 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#8 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#9 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#10 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#11 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#12 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#13 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#14 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#15 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#16 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#17 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#18 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#19 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#20 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#21 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#22 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#23 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#24 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#25 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#26 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#27 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#28 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
#29 0x7ff01eb5eeb4    ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)

  This is strange, I don't see where exactly does it crash. We can see
that this happens while processing WM_ACTIVATEAPP but there doesn't seem to
be any pointer dereferences in its handler. Maybe you could try to debug it
a bit by putting a breakpoint on "case WM_ACTIVATEAPP" in
src/msw/window.cpp and checking what happens there?

I tried to do that but Codeblocks kept telling me that "C:/SourceCode/Libraries/wxWidgets2.8/src/window.cpp" didn't exist, which is untrue. I guess it's a matter of configuration, but any advice here would be appreciated, I'll keep searching the web for a solution. If it helps, I'm using wxPack2.8, using gcc compiled libraries.

To summarize the important parts of my code:

/**********************************************************************/
/*******************MyApp.cpp****************************************
/**********************************************************************/

bool MyApp::OnInit()
{
    bool wxsOK = true;

    if ( wxsOK )
    {
        this->BMP=new wxBitmap();

        MyLibrary::RGBMapToWxBitmap(this->RgbMap,this->BMP);
        wxImageFrame *Frame = new wxImageFrameFrame(this->BMP);
        Frame->Show(true);
        SetTopWindow(Frame);
    }
    return wxsOK;
}


int MyApp::OnExit()
{
    delete this->BMP;
    return 0;
}


/**********************************************************************/
/****************MyFrame.cpp****************************************
/**********************************************************************/

wxImageFrame::wxImageFrame(wxBitmap* Bitmap,string ImageName,wxWindow* parent,wxWindowID id)
{
    if (Bitmap==NULL)
        throw LExcept("wxImageFrame","Constructor","Error: Image pointer is NULL");

    this->BMP=Bitmap;

    wxString wxImageName(_("Image"));

    Create(parent, id, wxImageName, wxDefaultPosition, wxSize(BMP->GetWidth(),BMP->GetHeight()), wxDEFAULT_FRAME_STYLE, _T("id"));
    ImagePanel = new wxPanel(this, ID_PANEL1, wxPoint(128,384), wxSize(BMP->GetWidth(),BMP->GetHeight()), wxTAB_TRAVERSAL, _T("ID_PANEL1"));

    ImagePanel->Connect(ID_PANEL1,wxEVT_PAINT,(wxObjectEventFunction)&wxImageFrameFrame::OnImagePanelPaint,0,this);
}


void wxImageFrame::OnImagePanelPaint(wxPaintEvent& event)
{
    wxPaintDC dc(this->ImagePanel);
    dc.DrawBitmap(*this->BMP,0,0,false);
}

/**********************************************************************/
/****************MyLibrary.cpp***************************************
/**********************************************************************/

wxImageFrameApp static_app;

int MyLibrary::ShowLRgbMap(LRgbMap* SrcMap)
{
    char test[]="test";
    char *argv[] = { (char*)test, NULL };
    int argc=1;

#define APP_SOLUTION_2

#ifdef APP_SOLUTION_1
    wxImageFrameApp *app=new wxImageFrameApp(SrcMap);
    wxAppInitializer wxTheAppInitializer((wxAppInitializerFunction) app);

    wxEntryStart( argc, argv );
    wxTheApp->OnInit();
    wxTheApp->OnRun();
    wxTheApp->OnExit();
    wxEntryCleanup();

    return 0;
#endif


#ifdef APP_SOLUTION_2
    wxImageFrameApp *app=new wxImageFrameApp(SrcMap);
    wxAppInitializer wxTheAppInitializer((wxAppInitializerFunction) app);

    return wxEntry(argc, argv);
#endif


#ifdef APP_SOLUTION_3
    static_app.SetRgbMap(SrcMap);
    wxAppInitializer wxTheAppInitializer((wxAppInitializerFunction) &static_app);

    wxEntryStart( argc, argv );
    wxTheApp->OnInit();
    wxTheApp->OnRun();
    wxTheApp->OnExit();
    wxEntryCleanup();

    return 0;
#endif

}

Solutions 1 and 2 do the same thing: they work as expected under "release" in Windows but not in "debug", and on Linux it creates the Window the first time it is called but not afterwards. It throws a SIGSEGV when the line "wxTheApp->OnRun()" is called.

Solution 3 doesn't work. In Windows, with "release" configuration, it creates the first Frame with the image but it crashes soon after I close it. The "debug" still crashes: it creates the window but on the line "Frame->Show".

[Vadim Zeitlin]

On Fri, 17 Jul 2009 15:21:44 -0200 Bruno <johndoe...@gmail.com> wrote:

B> > B> time it was called, but it threw another SIGSEGV when I called the
B> > B> function a second time.
B> >
B> > Do you have the output of "bt" from gdb for Linux?
B>
B> I didn't understand what you meant by "bt",

The output of gdb "bt" command [at the moment of the crash].

B> so I took the output at the moment of the second crash under Linux.
B> Also, the problem is happening when the function wxTheApp->OnRun() is
B> called in the program, as I will put later:
B>
B> #0 0x7ff01d843de4 _L_unlock_163() (/lib/libpthread.so.0:??)
B> #1 0x7ff01d843de9 _L_unlock_163() (/lib/libpthread.so.0:??)
B> #2 0x7ff01d843b26 __pthread_mutex_unlock_usercnt()
B> (/lib/libpthread.so.0:??)
B> #3 0x7ff01e2e2099 wxMutexInternal::Unlock()
B> (/usr/lib/libwx_baseu-2.8.so.0:??)
B> #4 0x7ff01eb5ee9a ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)
B> #5 0x7ff01eb5eeb4 ??() (/usr/lib/libwx_gtk2u_core-2.8.so.0:??)

You should be using debug version of wx (libwx_gtk2ud-core.so &c) in order
to make anything out of this -- like this it really doesn't have any useful
information.

[Bruno]

 The output of gdb "bt" command [at the moment of the crash].

 

#0 0x7fd4237ac290    __lll_unlock_wake() (/lib/libpthread.so.0:??)
#1 0x7fd4237a8de9    _L_unlock_163() (/lib/libpthread.so.0:??)
#2 0x7fd4237a8b26    __pthread_mutex_unlock_usercnt() (/lib/libpthread.so.0:??)
#3 0x7fd42425f076    wxMutexInternal::Unlock(this=0x6eff50) (../src/unix/threadpsx.cpp:297)
#4 0x7fd424b0011a    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:256)
#5 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#6 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#7 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#8 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#9 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#10 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#11 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#12 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#13 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#14 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#15 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#16 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#17 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#18 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#19 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#20 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#21 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#22 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#23 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#24 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#25 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#26 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#27 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#28 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)
#29 0x7fd424b00134    wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0) (../src/gtk/app.cpp:259)

Seems the debug configuration missed the "--debug" on "wx-config". Will it help somehow now?

I'm re-compiling wxWidgets in Windows, with that script wxBuild_wxWidgets.bat, to see if I can solve the problem of "window.cpp not found"

Bruno

[Vadim Zeitlin]

On Mon, 20 Jul 2009 14:58:19 -0300 Bruno <johndoe...@gmail.com> wrote:

B> >
B> > The output of gdb "bt" command [at the moment of the crash].
B>
B> #0 0x7fd4237ac290 __lll_unlock_wake() (/lib/libpthread.so.0:??)
B> #1 0x7fd4237a8de9 _L_unlock_163() (/lib/libpthread.so.0:??)
B> #2 0x7fd4237a8b26 __pthread_mutex_unlock_usercnt()
B> (/lib/libpthread.so.0:??)
B> #3 0x7fd42425f076 wxMutexInternal::Unlock(this=0x6eff50)
B> (../src/unix/threadpsx.cpp:297)
B> #4 0x7fd424b0011a wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:256)
B> #5 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #6 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #7 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #8 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #9 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #10 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #11 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #12 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #13 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #14 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #15 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #16 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #17 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #18 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #19 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #20 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #21 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #22 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #23 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #24 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #25 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #26 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #27 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #28 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B> #29 0x7fd424b00134 wxapp_poll_func(ufds=0x7735d0, nfds=2, timeout=0)
B> (../src/gtk/app.cpp:259)
B>
B> Seems the debug configuration missed the "--debug" on "wx-config". Will it
B> help somehow now?

Well, sorry, no. This is clearly not a valid stack trace. If you mean that
you didn't use debug version of wx, it would explain it. Please build
everything in debug when trying to gather information about a problem.

Alternatively please make a _small_ self-contained example showing your
problem and then maybe I could debug it here.

[Bruno]

  Well, sorry, no. This is clearly not a valid stack trace. If you mean that
you didn't use debug version of wx, it would explain it. Please build
everything in debug when trying to gather information about a problem.

I compiled using `wx-config --debug --cflags` and `wx-config --debug --libs`, and that was the call stack that was given to me, even when I ran it manually, without the help of Codeblocks

Alternatively please make a _small_ self-contained example showing your
problem and then maybe I could debug it here.

I'm sending a small program with the makefile. The problem is with subsequent calls of ShowImage(2), as you'll see in main.cpp

Alternatively, I can change the question to: what steps I need to take to start a wxApp in the main function, as many times as I want, without the IMPLEMENT_APP macro?

 

[Vadim Zeitlin]

On Tue, 21 Jul 2009 17:26:24 -0300 Bruno <johndoe...@gmail.com> wrote:

B> > Well, sorry, no. This is clearly not a valid stack trace. If you mean
B> > that
B> > you didn't use debug version of wx, it would explain it. Please build
B> > everything in debug when trying to gather information about a problem.
B>
B> I compiled using `wx-config --debug --cflags` and `wx-config --debug
B> --libs`, and that was the call stack that was given to me, even when I ran
B> it manually, without the help of Codeblocks

Strange, maybe something corrupting the stack then... have you tried
running it under valgrind?

B> Alternatively please make a small self-contained example showing your
B> > problem and then maybe I could debug it here.
B>
B> I'm sending a small program with the makefile. The problem is with
B> subsequent calls of ShowImage(2), as you'll see in main.cpp

I'll try to have a look at it.

[Vadim Zeitlin]

On Tue, 21 Jul 2009 17:26:24 -0300 Bruno <johndoe...@gmail.com> wrote:

B> I'm sending a small program with the makefile. The problem is with
B> subsequent calls of ShowImage(2), as you'll see in main.cpp

I built your test under Linux and it works just fine for me. I even ran it
under valgrind to be sure I don't miss anything and here is what it says:

% valgrind ./Test
==6920== Memcheck, a memory error detector.
==6920== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==6920== Using LibVEX rev 1854, a library for dynamic binary translation.
==6920== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==6920== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation framework.
==6920== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==6920== For more details, rerun with: -v
==6920==
==6920==
==6920== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 88 from 2)
==6920== malloc/free: in use at exit: 419,871 bytes in 4,736 blocks.
==6920== malloc/free: 28,805 allocs, 24,069 frees, 2,348,266 bytes allocated.
==6920== For counts of detected errors, rerun with: -v
==6920== searching for pointers to 4,736 not-freed blocks.
==6920== checked 4,375,576 bytes.
==6920==
==6920== LEAK SUMMARY:
==6920== definitely lost: 580 bytes in 13 blocks.
==6920== possibly lost: 48,352 bytes in 42 blocks.
==6920== still reachable: 370,939 bytes in 4,681 blocks.
==6920== suppressed: 0 bytes in 0 blocks.
==6920== Rerun with --leak-check=full to see details of leaked memory.

I.e. everything looks fine. I really don't know what's going on in your
case, sorry.

B> Alternatively, I can change the question to: what steps I need to take to
B> start a wxApp in the main function, as many times as I want, without the
B> IMPLEMENT_APP macro?

As I said before, your code looks correctly to me...

[Bruno]

Well, seems I'm running out of options then.

Maybe it is because of machine configuration? I'm actually running Debian in a remote machine with vncserver, logging in with putty in Windows.

The output of `wx-config --debug --cflags` was:

-I/usr/lib/wx/include/gtk2-unicode-debug-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -pthread

And for `wx-config --debug --libs`:

-pthread -Wl,-Bsymbolic-functions  -lwx_gtk2ud_richtext-2.8 -lwx_gtk2ud_aui-2.8 -lwx_gtk2ud_xrc-2.8 -lwx_gtk2ud_qa-2.8 -lwx_gtk2ud_html-2.8 -lwx_gtk2ud_adv-2.8 -lwx_gtk2ud_core-2.8 -lwx_baseud_xml-2.8 -lwx_baseud_net-2.8 -lwx_baseud-2.8

My output of valgrind was this:

==8120==  Address 0xde9b357 is 4,495 bytes inside a block of size 8,680 alloc'd
==8120==    at 0x4C220BC: calloc (vg_replace_malloc.c:397)
==8120==    by 0xD57757E: xcb_connect_to_fd (in /usr/lib/libxcb.so.1.0.0)
==8120==    by 0xD579ADF: xcb_connect (in /usr/lib/libxcb.so.1.0.0)
==8120==    by 0xA985529: _XConnectXCB (in /usr/lib/libX11.so.6.2.0)
==8120==    by 0xA96E7C5: XOpenDisplay (in /usr/lib/libX11.so.6.2.0)
==8120==    by 0x83DF448: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==8120==    by 0x83BEAA3: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.1200.9)
==8120==    by 0x7F19373: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.1200.9)
==8120==    by 0x600E77C: wxApp::Initialize(int&, wchar_t**) (app.cpp:478)
==8120==    by 0x699FF49: wxEntryStart(int&, wchar_t**) (init.cpp:296)
==8120==    by 0x69A01EA: wxEntry(int&, wchar_t**) (init.cpp:425)
==8120==    by 0x4039DA: MyLibrary::ShowImage(int) (MyLibrary.cpp:17)
==8120== Stack overflow in thread 1: can't grow stack to 0x7FE801FE0
==8120==
==8120== Process terminating with default action of signal 11 (SIGSEGV)
==8120==  Access not within mapped region at address 0x7FE801FE0
==8120==    at 0x7443DE4: _L_unlock_163 (in /lib/libpthread-2.7.so)
==8120== Stack overflow in thread 1: can't grow stack to 0x7FE801FD8
==8120==
==8120== Process terminating with default action of signal 11 (SIGSEGV)
==8120==  Access not within mapped region at address 0x7FE801FD8
==8120==    at 0x4A1F310: _vgnU_freeres (vg_preloaded.c:56)
==8120==
==8120== ERROR SUMMARY: 40 errors from 16 contexts (suppressed: 56 from 1)
==8120== malloc/free: in use at exit: 580,799 bytes in 4,862 blocks.
==8120== malloc/free: 10,563 allocs, 5,701 frees, 1,777,635 bytes allocated.
==8120== For counts of detected errors, rerun with: -v
==8120== searching for pointers to 4,862 not-freed blocks.
==8120== checked 9,215,640 bytes.
==8120==
==8120== LEAK SUMMARY:
==8120==    definitely lost: 0 bytes in 0 blocks.
==8120==      possibly lost: 66,856 bytes in 174 blocks.
==8120==    still reachable: 513,943 bytes in 4,688 blocks.
==8120==         suppressed: 0 bytes in 0 blocks.
==8120== Rerun with --leak-check=full to see details of leaked memory.

Does this shed new light about what could be happening? I

Btw, I managed to correct the problems with windows - I wasn't using the __WXDEBUG__ definition on the build of my library.

And thanks for all the help, Vadim.

[Vadim Zeitlin]

On Wed, 22 Jul 2009 16:44:08 -0300 Bruno <johndoe...@gmail.com> wrote:

B> Maybe it is because of machine configuration? I'm actually running Debian in
B> a remote machine with vncserver, logging in with putty in Windows.

I don't think this can make any difference.

B> The output of `wx-config --debug --cflags` was:
B>
B> -I/usr/lib/wx/include/gtk2-unicode-debug-2.8 -I/usr/include/wx-2.8
B> -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXGTK__ -pthread

This looks correct. Could you try 2.9.0 (RC6) just to see if you have
better luck with it?