[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Unable to use gdb
From: |
Greg Chicares |
Subject: |
Re: [lmi] Unable to use gdb |
Date: |
Fri, 09 Dec 2005 01:45:31 +0000 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
On 2005-12-9 0:58 UTC, Greg Chicares wrote:
> Vadim--Do you have any idea how I might attack this problem?
Maybe this makes it simpler--in 'main_wx.cpp', apply this change:
Skeleton::Skeleton()
:doc_manager_ (0)
,frame_ (0)
{
- SetAppName("lmi_wx");
- SetVendorName("lmi");
config_ = wxConfigBase::Get();
}
and then the program can be run in gdb without segfaulting.
So what's wrong with those two lines? From 'wx/app.h':
void SetAppName(const wxString& name) { m_appName = name; }
void SetVendorName(const wxString& name) { m_vendorName = name; }
I tried this:
- SetAppName("lmi_wx");
+ wxString app_name("lmi_wx");
+ SetAppName(app_name);
- SetVendorName("lmi");
+ wxString vendor_name("lmi");
+ SetVendorName(vendor_name);
but then it gives
Program received signal SIGTRAP, Trace/breakpoint trap.
upon issuing the gdb 'run' command.
I even dug up this ancient workaround that I once used with wx-2.4.1 :
http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/lmi/skeleton/wx_workarounds.hpp?rev=1.1&content-type=text/plain
and tried that:
+ // WX!! At least in wx-2.4.1, class wxString has an inline destructor
+ // but an out-of-line constructor. This triggers many mpatrol NOFREE
+ // diagnostics for applications that link to a wx dll. This problem
+ // should be fixed in wx; until it is, this workaround seems to
+ // cure the problem.
+
+ inline wxString wx_string_workaround(char const* s)
+ {
+ return *new wxString(s);
+ }
+
Skeleton::Skeleton()
:doc_manager_ (0)
,frame_ (0)
{
- SetAppName("lmi_wx");
- SetVendorName("lmi");
+ SetAppName (wx_string_workaround("lmi_wx"));
+ SetVendorName(wx_string_workaround("lmi" ));
config_ = wxConfigBase::Get();
}
but that gave the same result:
Program received signal SIGTRAP, Trace/breakpoint trap.
Am I calling these functions in the right place? I thought
I had to call them before wxConfigBase::Get(), and I thought
I should call wxConfigBase::Get() in the ctor of the class
derived from wxApp.