Linux: Crashes

[moloh]

Hello!
I found another problem (This time Revision 2451). During syntax highlight modifications, when i change a keyword then program just hung, but funny thing is that not always... sometimes it works correctly. Under gdb i found only this:

Code

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 114693 (LWP 8536)]
0xb75aa278 in wxSemaphore::Wait () from /usr/lib/libwx_baseu-2.6.so.0
(gdb) bt
#0  0xb75aa278 in wxSemaphore::Wait () from /usr/lib/libwx_baseu-2.6.so.0
#1  0xb75ab493 in wxThreadInternal::PthreadStart () from /usr/lib/libwx_baseu-2.6.so.0
#2  0xb75ab54b in wxPthreadStart () from /usr/lib/libwx_baseu-2.6.so.0
#3  0xb7ab7e04 in pthread_start_thread () from /lib/libpthread.so.0
#4  0xb7ab7f7d in pthread_start_thread_event () from /lib/libpthread.so.0
#5  0xb737248a in clone () from /lib/libc.so.6

I wont use debug version of wxWidgets because then usage of Code::Blocks is impossible because of number of Asserts Dialog at start.
I try to get some debug output under valgrind but somehow i can't do that, maybe this is related to other things i found. During project open phase:

Code

==8550== Conditional jump or move depends on uninitialised value(s)
==8550==    at 0x4111626: CompileTargetBase::SetOptionRelation(OptionsRelationType, OptionsRelation) (compiletargetbase.cpp:122)
==8550==    by 0x41AD7C6: ProjectLoader::DoBuildTargetOptions(TiXmlElement*, ProjectBuildTarget*) (projectloader.cpp:490)
==8550==    by 0x41AE68C: ProjectLoader::DoBuildTarget(TiXmlElement*) (projectloader.cpp:350)
==8550==    by 0x41AE863: ProjectLoader::DoBuild(TiXmlElement*) (projectloader.cpp:328)
==8550==    by 0x41B0090: ProjectLoader::Open(wxString const&) (projectloader.cpp:144)
==8550==    by 0x40F2926: cbProject::Open() (cbproject.cpp:288)
==8550==    by 0x40F47D5: cbProject::cbProject(wxString const&) (cbproject.cpp:84)
==8550==    by 0x41BD845: ProjectManager::LoadProject(wxString const&, bool) (projectmanager.cpp:654)
==8550==    by 0x8085640: MainFrame::DoOpenProject(wxString const&, bool) (main.cpp:1168)
==8550==    by 0x80873E7: MainFrame::OpenGeneric(wxString const&, bool) (main.cpp:1130)
==8550==    by 0x808803F: MainFrame::OnFileReopenProject(wxCommandEvent&) (main.cpp:1762)
==8550==    by 0x4982477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)

As i see this is some uninitialized option in program. But what it is exactly? I have no idea.
After change the keywords (adding new one, or delete, but it also could be just change of highlight or editor option, i test only keyword change) i get this one. But as i write, it doesn't occure every time:

Code

==8550== Invalid read of size 4
==8550==    at 0x4872A02: wxGenericTreeCtrl::ScrollTo(wxTreeItemId const&) (in /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==8550==    by 0x4879396: wxGenericTreeCtrl::EnsureVisible(wxTreeItemId const&) (in /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==8550==    by 0x4903DBB: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==8550==  Address 0x77D2C20 is 16 bytes before a block of size 8 free'd
==8550==    at 0x401C029: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8550==    by 0x50DE13F: g_free (in /usr/lib/libglib-2.0.so.0.800.6)
==8550==    by 0x436E10E: SurfaceImpl::DrawTextTransparent(PRectangle, Font&, int, char const*, int, ColourAllocated) (PlatWX.cpp:359)
==8550==    by 0x43943EE: Editor::DrawLine(Surface*, ViewStyle&, int, int, int, PRectangle, LineLayout*, int) (Editor.cxx:2557)
==8550==    by 0x439CBB8: Editor::Paint(Surface*, PRectangle) (Editor.cxx:2892)
==8550==    by 0x4372068: ScintillaWX::DoPaint(wxDC*, wxRect) (ScintillaWX.cpp:689)
==8550==    by 0x437DEB7: wxScintilla::OnPaint(wxPaintEvent&) (wxscintilla.cpp:2918)
==8550==    by 0x4982477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==8550==
==8550== Invalid read of size 1
==8550==    at 0x48796CF: wxGenericTreeCtrl::DoSelectItem(wxTreeItemId const&, bool, bool) (in /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==8550==    by 0x7FFFFFFE: ???
==8550==  Address 0x77D2C2C is 4 bytes before a block of size 8 free'd
==8550==    at 0x401C029: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8550==    by 0x50DE13F: g_free (in /usr/lib/libglib-2.0.so.0.800.6)
==8550==    by 0x436E10E: SurfaceImpl::DrawTextTransparent(PRectangle, Font&, int, char const*, int, ColourAllocated) (PlatWX.cpp:359)
==8550==    by 0x43943EE: Editor::DrawLine(Surface*, ViewStyle&, int, int, int, PRectangle, LineLayout*, int) (Editor.cxx:2557)
==8550==    by 0x439CBB8: Editor::Paint(Surface*, PRectangle) (Editor.cxx:2892)
==8550==    by 0x4372068: ScintillaWX::DoPaint(wxDC*, wxRect) (ScintillaWX.cpp:689)
==8550==    by 0x437DEB7: wxScintilla::OnPaint(wxPaintEvent&) (wxscintilla.cpp:2918)
==8550==    by 0x4982477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==8550==
==8550== Invalid write of size 1
==8550==    at 0x48796D8: wxGenericTreeCtrl::DoSelectItem(wxTreeItemId const&, bool, bool) (in /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==8550==    by 0x7FFFFFFE: ???
==8550==  Address 0x77D2C2C is 4 bytes before a block of size 8 free'd
==8550==    at 0x401C029: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8550==    by 0x50DE13F: g_free (in /usr/lib/libglib-2.0.so.0.800.6)
==8550==    by 0x436E10E: SurfaceImpl::DrawTextTransparent(PRectangle, Font&, int, char const*, int, ColourAllocated) (PlatWX.cpp:359)
==8550==    by 0x43943EE: Editor::DrawLine(Surface*, ViewStyle&, int, int, int, PRectangle, LineLayout*, int) (Editor.cxx:2557)
==8550==    by 0x439CBB8: Editor::Paint(Surface*, PRectangle) (Editor.cxx:2892)
==8550==    by 0x4372068: ScintillaWX::DoPaint(wxDC*, wxRect) (ScintillaWX.cpp:689)
==8550==    by 0x437DEB7: wxScintilla::OnPaint(wxPaintEvent&) (wxscintilla.cpp:2918)
==8550==    by 0x4982477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)

I have no idea if this is somehow related to the crash under gdb (under valgrind application doesn't crash) but this is what i get aften an hour (program works very slow under valgrind). After next change of keyword program crashed with (it tells much ;-):

Code

==8550== Invalid read of size 4
==8550==    at 0x4871A44: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==8550==  Address 0x77D2C04 is 20 bytes inside a block of size 24 free'd
==8550==    at 0x401C029: free (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==8550==    by 0x50DE13F: g_free (in /usr/lib/libglib-2.0.so.0.800.6)

Also i managed to get valgrind output from one crash at application close:

Code

==23141== Invalid read of size 4
==23141==    at 0x41BE02D: ProjectManager::CloseWorkspace() (projectmanager.cpp:1036)
==23141==    by 0x8077476: MainFrame::DoCloseCurrentWorkspace() (main.cpp:1191)
==23141==    by 0x808D633: MainFrame::OnApplicationClose(wxCloseEvent&) (main.cpp:1942)
==23141==    by 0x4982477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in usr/lib/libwx_baseu-2.6.so.0.2.0)
==23141==  Address 0x54 is not stack'd, malloc'd or (recently) free'd

It looks like value was initialized to some value, but not the right one. Now i don't have any workspace defined. If it was created then it was done automatically, but as usual it doesn't happen every time.

As conclusion i must say that i am dissapointed. I lost about a week for Code::Blocks, installation problem under Gentoo (what is the purpose of svn information read during compilation i have no idea, if You want to embed a version information better do it server side, during commit), number of crashes was overwhelming, debugger don't work as i write a messege in other thread, use of Tools crash application, almost no documentation for program Features. There is also a KNOWN problem with TinyXML, read from unallocated memory (i described it in other topic), fix for that would add one line and change one line, and problem is left in the code... very strange. It is all much dissapointing from my point of view, and worse i know You do it for free, and try to create a decent IDE, but for me it is completly unusable.
I can try to debug application "little" more, but only if You will guide me what EXACTLY to do.
Also i would like to appologize for that i use Forum topic to report problems (additionally for that there are mangled many problems in each message).

[thomas]

There is also a KNOWN problem with TinyXML, read from unallocated memory (i described it in other topic), fix for that would add one line and change one line, and problem is left in the code... very strange.

Not strange at all.

I understand that you have a certain frustration if things don't work for you, but this statement is outright nonsense, and you know it.
The TinyXML problem is not what crashes you, it just provokes a warning from valgrind. You said that yourself the other day.
As you have been told, it has been fixed long ago, but has not been merged to the trunk yet. As it is not a real problem (it is not pretty, it is technically not correct, but that's it), there is no urgent reason to get dippy about it now.

The crash is thread-related. The only thing that uses threads (other than the main thread) is the code completion plugin, so you may want to try turning that off.

The next thing ("Conditional jump or move depends on uninitialised value(s)") is very likely about CompileTargetBase::m_OptionsRelation[] which is not initialised in the constructor. It is not pretty but it is not a bug either (and not the reason for a crash). Although the variable appears uninitialised, it is not. It is true that the constructor doesn't initialise it, but that's done in another place.

The other stuff ("Invalid read of size 4") I don't know. That's some stuff inside wxGTK. The very last one (ProjectManager::CloseWorkspace()) I haven't looked into yet. But I doubt that I'll find something, since it would crash for everybody if there was a dangling pointer or something (and it doesn't). I will nevertheless have a look at it.

[thomas]

Looked at that last thing, too. The only bit that might be possibly unsafe in this frame is dereferencing the m_pTree pointer without checking for null first.
It should actually not be null (and it is not on my machine), but then you never know...

I added the missing null pointer check to be on the safe side. With some luck, this fixes something.

[mandrav]

As conclusion i must say that i am dissapointed. I lost about a week for Code::Blocks, installation problem under Gentoo (what is the purpose of svn information read during compilation i have no idea, if You want to embed a version information better do it server side, during commit), number of crashes was overwhelming, debugger don't work as i write a messege in other thread, use of Tools crash application, almost no documentation for program Features.

No worries, here you go:

http://www.kdevelop.org/
http://anjuta.sourceforge.net/
http://www.eclipse.org/
http://www.parinyasoft.com/products.html

Hope one of these suit your needs better and do not dissapoint you as much...

[moloh]

No worries, here you go:

http://www.kdevelop.org/
http://anjuta.sourceforge.net/
http://www.eclipse.org/
http://www.parinyasoft.com/products.html

Hope one of these suit your needs better and do not dissapoint you as much...

Maybe i shouldn't say dissapoint, for now i just can't use it. Maybe my expectations and hopes for this IDE were too big., but for sure i wouldn't leave Code::Blocks now, during a whole week of tests, i learned many things how it works. But before i can use it for project development, i have to have working debugger and possiblity to run external tools.
As for examples, i use kdevelop for quite long time, at start, about 2 years ago there were also problems, crashes. But now i don't notice anything like that, also i'am used to how this application works, just want to cross out last kde app from system. I tried also Eclipse, but there the problem is lack of editor features (like show whitespace characters) and performance issues during file editing.

[moloh]

Not strange at all.

I understand that you have a certain frustration if things don't work for you, but this statement is outright nonsense, and you know it.
The TinyXML problem is not what crashes you, it just provokes a warning from valgrind. You said that yourself the other day.
As you have been told, it has been fixed long ago, but has not been merged to the trunk yet. As it is not a real problem (it is not pretty, it is technically not correct, but that's it), there is no urgent reason to get dippy about it now.

I can agree with that, in true i'am a little bit flustrated. Things just don't work as easy as they suppose to. But i am also kind of idealist, if there is a warning it should be suppressed somehow and that is why i don't like things like that left behind.

The crash is thread-related. The only thing that uses threads (other than the main thread) is the code completion plugin, so you may want to try turning that off.

I will try that.

The next thing ("Conditional jump or move depends on uninitialised value(s)") is very likely about CompileTargetBase::m_OptionsRelation[] which is not initialised in the constructor. It is not pretty but it is not a bug either (and not the reason for a crash). Although the variable appears uninitialised, it is not. It is true that the constructor doesn't initialise it, but that's done in another place.

If it is then it is initialized after this call or there is some valgrind bug.
Thanks for interest in these issues.

[thomas]

If it is then it is initialized after this call or there is some valgrind bug.

Whatever it is, it has no great consequences.
The absolutely worst thing to happen (if the variable was *really* uninitialised) would be the project file being incorrectly flagged as "modified" on startup. This, however, never happens (we would know if that ever happened!).

So this is really not a problem.

[moloh]

If it is then it is initialized after this call or there is some valgrind bug.

Whatever it is, it has no great consequences.
The absolutely worst thing to happen (if the variable was *really* uninitialised) would be the project file being incorrectly flagged as "modified" on startup. This, however, never happens (we would know if that ever happened!).

So this is really not a problem.

Ok, now i belive You. ;-)