lmi
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]