Author Topic: LINUX: Tools Run Crash and Company... (Read 31360 times)

Ceniza · « **Reply #15 on:** May 23, 2006, 05:15:48 pm »

Quote from: Don Corleone

So you are looking at it? Good

Well, I just had the time to try it. If there's no hurry I could take deeper a look in two days (exams today and tomorrow)

moloh · « **Reply #16 on:** May 23, 2006, 09:06:11 pm »

Quote from: mandrav on May 23, 2006, 11:41:21 am

It makes no sense, because m_Timer is a member object (not a pointer). The only time this could be invalid is if the ToolsManager class is not constructed yet. But this can't be the case because it's a singleton. It exists throughout the application lifetime. And, if I 'm not mistaken, you don't get the crash on startup or on shutdown, but during a normal run. Right?

I get this crash only after Tool run, on exit.
Also i examined source code of this, and know that wxTimer is member object, so i said about structure aliasing. Maybe there are some differences in compiler flags or version (this could be issue with gcc4 line), but as i said earlier, this is blind shoot.

Quote from: Michael on May 23, 2006, 11:55:16 am

Moloh could you try a previous revision of C::B? And also the new built I will provided today (or tomorrow morning). Thanks

No problem, if You provide build i will test it.

Here are the few configuration things:
wx-config --cflags

Code

-I/usr/lib/wx/include/gtk2-unicode-release-2.6 -I/usr/include/wx-2.6 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -DNO_GCC_PRAGMA

wx-config --libs

Code

-pthread   -L/usr/X11R6/lib  -lwx_gtk2u_xrc-2.6 -lwx_gtk2u_html-2.6 -lwx_gtk2u_adv-2.6 -lwx_gtk2u_core-2.6 -lwx_baseu_xml-2.6 -lwx_baseu_net-2.6 -lwx_baseu-2.6

ldd /usr/bin/codeblocks

Code

        linux-gate.so.1 =>  (0xffffe000)
        libcodeblocks.so.0 => /usr/lib/libcodeblocks.so.0 (0xb7c16000)
        libwxscintilla.so.0 => /usr/lib/libwxscintilla.so.0 (0xb7b0e000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7abc000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ab8000)
        libwx_gtk2u_xrc-2.6.so.0 => /usr/lib/libwx_gtk2u_xrc-2.6.so.0 (0xb7a36000)
        libwx_gtk2u_html-2.6.so.0 => /usr/lib/libwx_gtk2u_html-2.6.so.0 (0xb79a8000)
        libwx_gtk2u_adv-2.6.so.0 => /usr/lib/libwx_gtk2u_adv-2.6.so.0 (0xb7908000)
        libwx_gtk2u_core-2.6.so.0 => /usr/lib/libwx_gtk2u_core-2.6.so.0 (0xb7622000)
        libwx_baseu_xml-2.6.so.0 => /usr/lib/libwx_baseu_xml-2.6.so.0 (0xb7619000)
        libwx_baseu_net-2.6.so.0 => /usr/lib/libwx_baseu_net-2.6.so.0 (0xb75ed000)
        libwx_baseu-2.6.so.0 => /usr/lib/libwx_baseu-2.6.so.0 (0xb74c2000)
        libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libstdc++.so.6 (0xb73e2000)
        libm.so.6 => /lib/libm.so.6 (0xb73bf000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libgcc_s.so.1 (0xb73b5000)
        libc.so.6 => /lib/libc.so.6 (0xb729d000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb721d000)
        /lib/ld-linux.so.2 (0xb7f3f000)
        libz.so.1 => /lib/libz.so.1 (0xb720b000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6f29000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f10000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6efa000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6ec3000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6e89000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6e85000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6e7f000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6dfb000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6df8000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6df3000)
        libpng.so.3 => /usr/lib/libpng.so.3 (0xb6dce000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6db0000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6d5d000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb6d01000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6ce2000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6cdb000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6c90000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6c69000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb6c5b000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6c53000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6b6b000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb6b63000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6b5e000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6b55000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6b50000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6b2a000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6ab7000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6a92000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6a8f000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6a8a000)

ldd /usr/lib/libcodeblocks.so

Code

        linux-gate.so.1 =>  (0xffffe000)
        libwxscintilla.so.0 => /usr/lib/libwxscintilla.so.0 (0xb7b18000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7ac6000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ac2000)
        libwx_gtk2u_xrc-2.6.so.0 => /usr/lib/libwx_gtk2u_xrc-2.6.so.0 (0xb7a40000)
        libwx_gtk2u_html-2.6.so.0 => /usr/lib/libwx_gtk2u_html-2.6.so.0 (0xb79b2000)
        libwx_gtk2u_adv-2.6.so.0 => /usr/lib/libwx_gtk2u_adv-2.6.so.0 (0xb7913000)
        libwx_gtk2u_core-2.6.so.0 => /usr/lib/libwx_gtk2u_core-2.6.so.0 (0xb762c000)
        libwx_baseu_xml-2.6.so.0 => /usr/lib/libwx_baseu_xml-2.6.so.0 (0xb7623000)
        libwx_baseu_net-2.6.so.0 => /usr/lib/libwx_baseu_net-2.6.so.0 (0xb75f7000)
        libwx_baseu-2.6.so.0 => /usr/lib/libwx_baseu-2.6.so.0 (0xb74cc000)
        libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libstdc++.so.6 (0xb73ed000)
        libm.so.6 => /lib/libm.so.6 (0xb73ca000)
        libc.so.6 => /lib/libc.so.6 (0xb72b1000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/libgcc_s.so.1 (0xb72a7000)
        /lib/ld-linux.so.2 (0x80000000)
        libz.so.1 => /lib/libz.so.1 (0xb7295000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb6fb4000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb6f34000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb6f1a000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb6f04000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb6ecd000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb6e93000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb6e8f000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb6e8a000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6e05000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6e02000)
        libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb6dfd000)
        libpng.so.3 => /usr/lib/libpng.so.3 (0xb6dd8000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6dba000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0xb6d68000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb6d0b000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb6cec000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb6ce5000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xb6bfd000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb6bb2000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb6b8b000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xb6b7d000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6b75000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0xb6b6d000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb6b69000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb6b5f000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb6b5a000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6b34000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb6ac2000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0xb6abe000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb6ab9000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6a94000)

Michael · « **Reply #17 on:** May 24, 2006, 12:06:10 pm »

Quote from: moloh on May 23, 2006, 09:06:11 pm

Quote from: Michael on May 23, 2006, 11:55:16 am
Moloh could you try a previous revision of C::B? And also the new built I will provided today (or tomorrow morning). Thanks
No problem, if You provide build i will test it.

Thanks

.

Ubuntu packages are in the Nightly Builds sub-forum. There you can choose the revision you would like to try. E.g., the one of 8th or 9th May and the one of yesterday (23th of May).

Best wishes,
Michael

moloh · « **Reply #18 on:** May 24, 2006, 10:47:14 pm »

Quote from: Michael on May 24, 2006, 12:06:10 pm

Ubuntu packages are in the Nightly Builds sub-forum. There you can choose the revision you would like to try. E.g., the one of 8th or 9th May and the one of yesterday (23th of May).

20060509 - crash
20060523 - crash
20060524 - crash

same valgrind output, same codeblocks.xml backtrace.

moloh · « **Reply #19 on:** May 25, 2006, 12:05:07 am »

Ok i started hacking...
Commented out m_Timer.SetOwner(...) m_Timer.Start(...) and m_Timer.Stop() in toolsmanager.cpp. It works, no crash...
So maybe it is bad wxTimer initialization (i don't know wxWidgets internals), i will try to see doc about this.
Are You sure it is safe to pass "this" pointer in constructor to wxTimer, especially as it is a member structure, is it fully constructed?

moloh · « **Reply #20 on:** May 25, 2006, 04:19:02 am »

I changed wxTimer m_Timer into wxTimer *m_Timer in source code, add suitable new and delete with parameters as in current source. Result? Crash, but different valgrind output. I don't have idea what is happennig, also why this OnToolTerminated is called more that once?

Code

==29363== Invalid read of size 4
==29363==    at 0x41D56CA: ToolsManager::OnToolTerminated(CodeBlocksEvent&) (toolsmanager.cpp:405)
==29363==    by 0x49AE417: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3D952: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3DB16: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3DC33: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3DEA6: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x49AE9C8: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x473E718: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==29363==    by 0x51064AF: (within /usr/lib/libglib-2.0.so.0.800.6)
==29363==  Address 0x61963D4 is 0 bytes after a block of size 108 alloc'd
==29363==    at 0x401CC31: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==29363==    by 0x416483B: Manager::GetToolsManager() const (manager.h:139)
==29363==    by 0x8090F83: MainFrame::CreateMenubar() (main.cpp:673)
==29363==    by 0x8091DEB: MainFrame::CreateIDE() (main.cpp:537)
==29363==    by 0x8092A9E: MainFrame::MainFrame(wxWindow*) (main.cpp:458)
==29363==    by 0x8065CE8: CodeBlocksApp::InitFrame() (app.cpp:246)
==29363==    by 0x8066A56: CodeBlocksApp::OnInit() (app.cpp:405)
==29363==    by 0x8067A10: wxAppConsole::CallOnInit() (app.h:87)
==29363==    by 0x49E4151: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4BBC420: (below main) (in /lib/libc-2.3.6.so)
==29363==
==29363== Invalid read of size 4
==29363==    at 0x41D56CD: ToolsManager::OnToolTerminated(CodeBlocksEvent&) (toolsmanager.cpp:405)
==29363==    by 0x49AE417: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3D952: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3DB16: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3DC33: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x4A3DEA6: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x49AE9C8: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==29363==    by 0x473E718: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==29363==    by 0x51064AF: (within /usr/lib/libglib-2.0.so.0.800.6)
==29363==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

toolsmanager.cpp
405: m_Timer->Stop();
Error line is with m_Timer pointer but i rather think error is about "this" pointer, not m_Timer. And additionally, why there are two errors there?
To test it i add a NULL check, and to result show it clearly, problem is with "this" pointer, so either bad object is registered somewhere as an event reciver or some other bad thing is happening. But i have no experience how exactly events in wxWidgets work. Here is output

Code

==9271== Invalid read of size 4
==9271==    at 0x41D56C6: ToolsManager::OnToolTerminated(CodeBlocksEvent&) (toolsmanager.cpp:405)
==9271==    by 0x49AE417: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3D952: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3DB16: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3DC33: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3DEA6: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x49AE9C8: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x473E718: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==9271==    by 0x51064AF: (within /usr/lib/libglib-2.0.so.0.800.6)
==9271==  Address 0x5C00BA4 is 0 bytes after a block of size 108 alloc'd
==9271==    at 0x401CC31: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==9271==    by 0x416483B: Manager::GetToolsManager() const (manager.h:139)
==9271==    by 0x8090F83: MainFrame::CreateMenubar() (main.cpp:673)
==9271==    by 0x8091DEB: MainFrame::CreateIDE() (main.cpp:537)
==9271==    by 0x8092A9E: MainFrame::MainFrame(wxWindow*) (main.cpp:458)
==9271==    by 0x8065CE8: CodeBlocksApp::InitFrame() (app.cpp:246)
==9271==    by 0x8066A56: CodeBlocksApp::OnInit() (app.cpp:405)
==9271==    by 0x8067A10: wxAppConsole::CallOnInit() (app.h:87)
==9271==    by 0x49E4151: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4BBC420: (below main) (in /lib/libc-2.3.6.so)
==9271==
==9271== Invalid read of size 4
==9271==    at 0x41D56CD: ToolsManager::OnToolTerminated(CodeBlocksEvent&) (toolsmanager.cpp:406)
==9271==    by 0x49AE417: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3D952: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3DB16: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3DC33: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x4A3DEA6: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x49AE9C8: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==9271==    by 0x473E718: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==9271==    by 0x51064AF: (within /usr/lib/libglib-2.0.so.0.800.6)
==9271==  Address 0xFFF7993F is not stack'd, malloc'd or (recently) free'd

toolsmanager.cpp
405: if( m_Timer )
406: m_Timer->Stop();

There is also one more question, why in case of m_Timer commenting out (only in source code file, in header there was still declaration of object) things work ok.
I will still try to investigate more this problem, but hope for a help from experienced developer.

moloh · « **Reply #21 on:** May 25, 2006, 10:43:23 pm »

Quote from: moloh on May 25, 2006, 04:19:02 am

There is also one more question, why in case of m_Timer commenting out (only in source code file, in header there was still declaration of object) things work ok.

So it seems things don't work ok.
Under valgrind there are also invalid reads but application does not crash so it seems it is problem with event handling.

Ceniza · « **Reply #22 on:** May 26, 2006, 08:53:26 pm »

Finally I had the time to look at it and the timer just makes no sense.

The tools manager used to launch the tools in another way which maybe needed this timer to get Code::Blocks responsive, but every launching option is executed asynchronously, so Code::Blocks shouldn't need it now.

It looks like a problem similar to that we had with wxYield before, but it just shouldn't happen, even though it does.

Well, time to remove some code

moloh · « **Reply #23 on:** June 02, 2006, 05:21:18 am »

Quote from: Ceniza on May 26, 2006, 08:53:26 pm

Well, time to remove some code

Thanks to removal of wxTimer, codeblocks no longer crash on Tools usage, but problem is still there.
I tried to analyze source code, how event is registered and added some checks. As i said there is problem with this pointer and to check this i add sth like this (all modifications in files toolsmanager.cpp and pipedprocess.cpp, all that are in the post are from toolsmanager.cpp file)

Code

Manager::Get()->GetMessageManager()->Log(_T("This at start: %d"), this);

in function that runs Tool (bool ToolsManager::Execute(Tool* tool)) and

Code

Manager::Get()->GetMessageManager()->Log(_T("This at end: %d"), this);

in (void ToolsManager::OnToolTerminated(CodeBlocksEvent& event))
As i thought this value is different, why? Ok lets go further...

I added similar modifications to PipedProcess class (there i used m_Parent, which should be the same) and results were pretty interesting.
So it occur to me that problem was that: this pointer is okay in ToolsManger, but bad in ProcessManager...
I googled a moment... and? Here is why: http://carcino.gen.nz/tech/cpp/multiple_inheritance_this.php#downcasting
Read it and You would know (better whole, not only about downcasting).
Problematic line:

Code

162:    m_pProcess = new PipedProcess((void**)&m_pProcess, this, idToolProcess, pipe, dir);
// comment: i must say this is interesting hack for setting m_Process value, modify self pointer in parent from self, child instance.

DOWNCASTING OF THIS!!!!!!!!
I am definetly a c programmer, don't know c++ hacks and tricks, here is one pitfall, but i see someone who did that also doesn't know c++ very well. Ok i lost patience... sorry.
Prolem is still, i tried dynamic_cast and no chance, it doesn't work so probably You don't have virtual function, so either You have to modify inheritance (if there wouldn't be multiple inheritance, then there would be no problem).

Ceniza · « **Reply #24 on:** June 02, 2006, 07:04:31 am »

I just checked the value of this on both ToolsManager::Execute and ToolsManager::OnTerminate and it's the same, just as it should be.

The cast in there, for what it's used, makes no harm at all. The whole idea of it is that when the PipedProcess is notified about tool termination the pointer ToolsManager::m_pProcess is modified from PipedProcess to indicate just that. Since sizeof(void **) == sizeof(PipedProcess **) and there's no need to adjust offsets (what you might be wondering about that cast), it'll work. In fact that would also work for any kind of pointee (including built-in types), not just PipedProcess.

Now, the purpose of m_pProcess is to know if there's a tool running, just that. If you try to run another tool and m_pProcess is not 0, you'll get a message saying there's another tool already running. It's just being sure the "process terminated setting that pointer to 0" trick is applied as soon as the tool finishes. It'll also create a new event which will get ToolsManager::OnTerminate executed, which BTW sets the pointer once again to 0. This suggests the cast could be replaced by a plain 0 (a NULL pointer) and it should work.

If you check what's that pointer being used for in PipedProcess, you'll find it's just used to set to 0 the pointer it's pointing to. It'sn't casted to anything else and then trying to call a member function of the resulting pointer.

That said, keeping it that way, it'll do what it's intended to do.

If you really dislike that C-cast (I do), it could, at most, be replaced by a reinterpret_cast, even though unnecessary.

moloh · « **Reply #25 on:** June 02, 2006, 07:49:46 am »

Quote from: Ceniza on June 02, 2006, 07:04:31 am

I just checked the value of this on both ToolsManager::Execute and ToolsManager::OnTerminate and it's the same, just as it should be.

The cast in there, for what it's used, makes no harm at all. The whole idea of it is that when the PipedProcess is notified about tool termination the pointer ToolsManager::m_pProcess is modified from PipedProcess to indicate just that. Since sizeof(void **) == sizeof(PipedProcess **) and there's no need to adjust offsets (what you might be wondering about that cast), it'll work. In fact that would also work for any kind of pointee (including built-in types), not just PipedProcess.

It makes, read article. There is no guarantee that it will work correctly, downcasting this value when there is multiple inheritance is compiler dependent.
On Gentoo it sometimes makes crashes (gcc-4.1) or on older compiler (gcc-3.4) it works ok, confirmed by few people i contacted, also on debian by myself (i only check crashes).
You can also check other posts in this thread, crashes are confirmed there by other developers. They use linux, valgrind will show them still invelid reads with this pointer as in my case...

Quote from: Ceniza on June 02, 2006, 07:04:31 am

Now, the purpose of m_pProcess is to know if there's a tool running, just that. If you try to run another tool and m_pProcess is not 0, you'll get a message saying there's another tool already running. It's just being sure the "process terminated setting that pointer to 0" trick is applied as soon as the tool finishes. It'll also create a new event which will get ToolsManager::OnTerminate executed, which BTW sets the pointer once again to 0. This suggests the cast could be replaced by a plain 0 (a NULL pointer) and it should work.

If you check what's that pointer being used for in PipedProcess, you'll find it's just used to set to 0 the pointer it's pointing to. It'sn't casted to anything else and then trying to call a member function of the resulting pointer.

That said, keeping it that way, it'll do what it's intended to do.

If you really dislike that C-cast (I do), it could, at most, be replaced by a reinterpret_cast, even though unnecessary.

It wont work, read article why. I belive in what is written there as i saw results with my bare eyes in Code::Blocks.
Also i understand how this thing work, but for the first time i saw this kind of construction (that dynamic object set self pointer in "owner" class). For me this was strage, why do not modify m_pProcess pointer only in event ToolsManager class, now it first is set to 0 by PipedProcess class, and then in ToolsManager OnToolTerminated event handler.

Ceniza · « **Reply #26 on:** June 02, 2006, 08:18:22 am »

Here you have a reinterpret cast with multiple inheritance:

Code: asm

leal	-28(%ebp), %eax
movl	%eax, -32(%ebp)

In words: get the address of a variable (which is a pointer) and store it in another variable (which is a pointer to pointer).

Once again: it is NOT a downcast, it IS a reinterpret cast, and, again, that's the intention.

Modifying the pointer only in ToolsManager is a choice, but really, don't get yourself confused. That would save us a double assignment to that pointer which happens to be two asm lines (because of the indirection), and just that.

Code: asm

movl	-32(%ebp), %eax
movl	$0, (%eax)

Just for fun. Here you have the code of a downcast with offset adjustment (4 bytes for this test) and which also checks for NULL (well, it really has to):

Code: asm

	cmpl	$0, -28(%ebp)
	je	L2
	movl	-28(%ebp), %eax
	addl	$4, %eax
	movl	%eax, -36(%ebp)
	jmp	L3
L2:
	movl	$0, -36(%ebp)
L3:
	movl	-36(%ebp), %eax
	movl	%eax, -32(%ebp)

Anything else to prove?

moloh · « **Reply #27 on:** June 02, 2006, 08:28:11 am »

Ok here You got me. I can't speak in assembler language. But this way it has to work, because You do work of compiler.
Do You want me to say You are better? Here You go... You are better.

To show You the problem i will prepare a build and send binary and diff of sources to You, with screenshots (in ~24h).
One thing, i am very suprised how this work, i never thought that c pointer cast can change address, but You will see that too.

Ceniza · « **Reply #28 on:** June 02, 2006, 08:42:47 am »

Just give me something I can test, like: Add tool with name xxx that calls yyy with parameters zzz and blah blah blah, check the value of this here and there... something like that.

Just be sure to include filename and line

[edit]
I just took a closer look to the line that surprised you. If you take a closer look too you'll find it's OK

Code: cpp

m_pProcess = 
  new PipedProcess((void**)
    &m_pProcess, // address of m_pProcess != m_pProcess
  this, idToolProcess, pipe, dir);

[/edit]

moloh · « **Reply #29 on:** June 02, 2006, 09:02:50 am »

Quote from: Ceniza on June 02, 2006, 08:42:47 am

Just give me something I can test, like: Add tool with name xxx that calls yyy with parameters zzz and blah blah blah, check the value of this here and there... something like that.

Already did this here:

Quote from: moloh on May 23, 2006, 11:22:07 am

Added tool named: ln
Executable: ln
Parameters: --help

Quote from: Ceniza on June 02, 2006, 08:42:47 am

Just be sure to include filename and line

Diff of changes:

Code

diff -ur codeblocks/src/sdk/toolsmanager.cpp codeblocks.my/src/sdk/toolsmanager.cpp
--- codeblocks/src/sdk/toolsmanager.cpp 2006-05-27 16:42:42.000000000 -0600
+++ codeblocks.my/src/sdk/toolsmanager.cpp      2006-06-02 00:35:23.000000000 -0600
@@ -159,6 +159,12 @@
       break;
        }

+    Manager::Get()->GetMessageManager()->Log(_T("This in Execute: %d"), this);
+    Manager::Get()->GetMessageManager()->Log(_T("This in Execute (c cast): %d"), (wxEvtHandler *)this);
+    Manager::Get()->GetMessageManager()->Log(_T("This in Execute (static cast): %d"), static_cast<wxEvtHandler *>(this));
+    Manager::Get()->GetMessageManager()->Log(_T("This in Execute (reinterpret cast): %d"), reinterpret_cast<wxEvtHandler *>(this));
+    Manager::Get()->GetMessageManager()->Log(_T("This in Execute (dynamic cast): %d"), dynamic_cast<wxEvtHandler *>(this));
+
     m_pProcess = new PipedProcess((void**)&m_pProcess, this, idToolProcess, pipe, dir);
     m_Pid = wxExecute(cmdline, flags, m_pProcess);

@@ -392,6 +398,8 @@

 void ToolsManager::OnToolTerminated(CodeBlocksEvent& event)
 {
+    Manager::Get()->GetMessageManager()->Log(_T("This in OnToolTerminated: %d"), this);
+
     m_Pid = 0;
     m_pProcess = 0;

Where to send binary (17MB, tar.gz)?

Quote from: Ceniza on June 02, 2006, 08:42:47 am

[edit]
I just took a closer look to the line that surprised you. If you take a closer look too you'll find it's OK

Code: cpp
m_pProcess = 
  new PipedProcess((void**)
    &m_pProcess, // address of m_pProcess != m_pProcess
  this, idToolProcess, pipe, dir);
[/edit]

I all the time speak about *this* pointer in this call.
Screenshot attached. I must say i am suprised about reinterpret_cast, it works, i must eveluate why there is change there...
[edit]
After few minutes and some reading, now i am not suprised why reinterpret_cast works as in screenshot ;-)
[/edit]

[attachment deleted by admin]

Code::Blocks Forums

News:

Author Topic: LINUX: Tools Run Crash and Company... (Read 31360 times)

Ceniza

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

Michael

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

Ceniza

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

Ceniza

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

Ceniza

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...

Ceniza

Re: LINUX: Tools Run Crash and Company...

moloh

Re: LINUX: Tools Run Crash and Company...