wxStandardPaths seg fault in Linux Topic is solved

[aval57]

Hi, I've ported/built some working win32 code in Linux but get a seg fault during execution at this line:

Code: Select all

appDir = wxStandardPaths().GetDataDir();

where gdb reports:

Program received signal SIGSEGV, Segmentation fault.
0xb7e308f8 in wxStandardPaths::GetInstallPrefix () from /usr/local/lib/libwx_base-2.6.so.0

After looking at GetInstallPrefix() in the wx manual and also at <wx/unix/stdpaths.h>, I tried to see if first calling SetInstallPrefix( ) might bypass the problem:

Code: Select all

wxStandardPaths().SetInstallPrefix( wxString("/usr/local") );
appDir = wxStandardPaths().GetDataDir() + wxSEP;

but no luck: crashes at the same line.

Any help from the linux-savvy would be appreciated.
Bahman

my setup: g++ (GCC) 3.3.5 (Debian 1:3.3.5-13 mounted on colinux), using anjuta 1.2.2 IDE.

[DavidHart]

Hi,

What happens if you try: appDir = wxStandardPaths::Get().GetDataDir();? This works for me, on wxGTK-2.6.3.

If that segfaults too, try commenting it out and see if the rest of the app works. If it doesn't, that suggests some more-general problem e.g. two conflicting sets of libs.

Regards,

David

[aval57]

Thanks for the speedy response, David.

::Get().GetDataDir() crashes too, though everything appears to run ok if the line is removed. But you may be on to something: make hung twice and had to be restarted when I was building wxWidgets (2.6.3 gtk also) yesterday, so I'll try and see if a rebuild clears the problem.

Bahman

[DavidHart]

The ideal way to do that would be to do a 'local' install, so that there is no chance of conflict. See http://forums.wxwidgets.org/viewtopic.php?t=7065

It would also be worth making it a debug build, so that you can investigate any crash more easily.

[aval57]

Well, still segfaults after an uneventful debug build:

Program received signal SIGSEGV, Segmentation fault.
0xb7e64e79 in wxStandardPaths::GetInstallPrefix (this=0xbfaeea20) at ../src/unix/stdpaths.cpp:68
68 wxString basename(wxString(wxTheApp->argv[0]).AfterLast(_T('/')));

apparently while trying to get argv[0]. gdb reports "No symbol "wxTheApp" in current context." on trying to inspect, and stepping into the statement results in "Couldn't get registers: No such process." Tried several times to stop gdb at the preceding lines and inspect wxTheApp, but it goes straight to line 68 once entering the function.

My app is in a local project folder, so I tried copying it to /usr/local/bin and running it from home just to see if that would give GetInstallPrefix an argv[0] it might like better: crashed again.

cheers,
Bahman

PS Here's GetInstallPrefix just for reference:

Code: Select all

wxString wxStandardPaths::GetInstallPrefix() const
{
    if ( m_prefix.empty() )
    {
        wxStandardPaths *self = wx_const_cast(wxStandardPaths *, this);

#ifdef __LINUX__
        // under Linux, we can get location of the executable
        char buf[4096];
        if ( readlink("/proc/self/exe", buf, WXSIZEOF(buf)) != -1 )
        {
            wxString exe(buf, wxConvLibc);

            // consider that we're in the last "bin" subdirectory of our prefix
            wxString basename(wxString(wxTheApp->argv[0]).AfterLast(_T('/'))); // << SEGFAULT
            size_t pos = exe.find(_T("/bin/") + basename);
            if ( pos != wxString::npos )
            {
                self->m_prefix.assign(exe, 0, pos);
            }
        }

        if ( m_prefix.empty() )
#endif // __LINUX__
        {
#ifdef __VMS
	   self->m_prefix = _T("/sys$system");
#else
	   self->m_prefix = _T("/usr/local");
#endif
        }
    }

    return m_prefix;
}

[DavidHart]

gdb reports "No symbol "wxTheApp" in current context."

Very strange! And even stranger since this is code that does work in MSWin, which means I don't need to ask silly questions like "Did you forget to do IMPLEMENT_APP(MyApp)".

What happens if you add
wxString StdDataDir = wxStandardPaths::Get().GetDataDir(); wxMessageBox( StdDataDir );
to the Minimal sample, at the end of MyFrame::MyFrame (you'll need #include "wx/stdpaths.h" too)?
This works for me: if it crashes for you, I suspect that Colinux would be the most likely culprit, being the only unusual part of your system.

[aval57]

In my (limited) experience the silly questions always need to be asked, David.

It's a console app, and wxWidgets is primed by calling wxInitialize() early on. There's no myApp class. I modified the minimal sample as you suggested above and it ran successfully.

I also added "#define TEST_STDPATHS" at the top of the console sample and it resulted in the identical segfault. Does this happen for you? If it doesn't, then I think you may be right about colinux and the thing to do would be work around GetDataDir() for now on the assumption that if I get things running ok it's likely to build in a native linux setup.

Thanks,
Bahman

PS just for the sake of completeness I also did a static build of wxWidgets, but it behaves exactly the same as the shared version.

[DavidHart]

t's a console app

Ah!

I also added "#define TEST_STDPATHS" at the top of the console sample and it resulted in the identical segfault. Does this happen for you?

Yes it does.

Searching through the bug-tracker revealed http://sourceforge.net/tracker/index.ph ... tid=109863, which was probably the same problem (in fact, I wonder why it ever works!). Patching with the latest code from http://cvs.wxwidgets.org/viewcvs.cgi/wx ... dpaths.cpp cures the console segfault for me.

I withdraw my colinux imputation

[aval57]

Eureka! Your aim is true David (not to mention swift).

Had to update the full suite:

• wx/stdpaths.h
  wx/unix/stdpaths.h
  unix/stdpaths.cpp
  common/stdpbase.cpp

before getting a successful rebuild.

Looks like the official solution avoids querying wxTheApp, which makes sense, as well as fixing the unterminated string a few lines above as mentioned in the bug report.

many many thanks,
Bahman