wxStandardPaths seg fault in Linux Topic is solved

Do you have a typical platform dependent issue you're battling with ? Ask it here. Make sure you mention your platform, compiler, and wxWidgets version.
Post Reply
aval57
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

wxStandardPaths seg fault in Linux

Post by aval57 » Mon Oct 02, 2006 6:33 pm

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
Site Admin
Site Admin
Posts: 4019
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Post by DavidHart » Mon Oct 02, 2006 7:01 pm

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
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 » Mon Oct 02, 2006 9:40 pm

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
Site Admin
Site Admin
Posts: 4019
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Post by DavidHart » Mon Oct 02, 2006 9:52 pm

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
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 » Tue Oct 03, 2006 4:42 pm

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
Site Admin
Site Admin
Posts: 4019
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Post by DavidHart » Tue Oct 03, 2006 5:22 pm

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
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 » Wed Oct 04, 2006 2:05 pm

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
Site Admin
Site Admin
Posts: 4019
Joined: Thu Jan 12, 2006 6:23 pm
Location: IoW, UK

Post by DavidHart » Wed Oct 04, 2006 3:26 pm

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
Knows some wx things
Knows some wx things
Posts: 35
Joined: Thu Aug 25, 2005 5:38 am

Post by aval57 » Wed Oct 04, 2006 6:37 pm

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

Post Reply