Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: moloh on May 13, 2006, 11:36:50 am

Title: LINUX: Tools Run Crash and Company...
Post by: moloh on May 13, 2006, 11:36:50 am
I found a bad behaviour under Linux, i want to use cmake Makefile generator from Tools menu, made an entry
(Name:cmake, Executable:cmake, Parameters:${PROJECT_DIR}, Working Directory:${PROJECT_DIR}/.cmake) to configure out-of-the source build and try to run it. Result? crash. Under gdb i get onlt this as backtrace:
Code
#0  0xb76f10b2 in wxTimer::~wxTimer () from /usr/lib/libwx_gtk2u_core-2.6.so.0
#1  0xb6ed3c27 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
#2  0xb7a6643b in __pthread_alt_unlock () from /lib/libpthread.so.0
Te get more info i tried to run codeblocks under valgrind, here i present results, i also found other bug in TinyXML usage. Location:
Code
File: configmanager.cpp
Line: 103-105
Problem: Pass non-NULL terminated string to TinyXML Parse function
Result: Invalid Read after allocated block, but this don't cause any trouble (no crash).
Now to importand part of valgrind error log:
These warning show before actually Tools is executed in console but after "click":
Code
==20299== Warning: invalid file descriptor 1014 in syscall close()
==20299== Warning: invalid file descriptor 1015 in syscall close()
==20299== Warning: invalid file descriptor 1016 in syscall close()
==20299==    Use --log-fd=<number> to select an alternative log fd.
==20299== Warning: invalid file descriptor 1017 in syscall close()
==20299== Warning: invalid file descriptor 1018 in syscall close()
==20299== Warning: invalid file descriptor 1019 in syscall close()
==20299== Warning: invalid file descriptor 1020 in syscall close()
==20299== Warning: invalid file descriptor 1021 in syscall close()
==20299== Warning: invalid file descriptor 1022 in syscall close()
==20299== Warning: invalid file descriptor 1023 in syscall close()
And this is valgrind backtrace for error:
Code
==17229== Invalid read of size 4
==17229==    at 0x483AEBA: wxTimer::Stop() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==17229==    by 0x4A6B477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFA602: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFA7C6: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFA8E3: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFAB56: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4A6BA18: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4180022: Manager::ProcessPendingEvents() (manager.cpp:105)
==17229==    by 0x41E9138: SimpleTextLog::AddLog(wxString const&, bool) (simpletextlog.cpp:66)
==17229==    by 0x418496B: MessageManager::Log(wchar_t const*, ...) (messagemanager.cpp:232)
==17229==    by 0x41F11AD: ToolsManager::OnToolStdOutput(CodeBlocksEvent&) (toolsmanager.cpp:384)
==17229==    by 0x4A6B477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so. 0.2.0)
==17229==  Address 0x6DA13FC is 0 bytes after a block of size 164 alloc'd
==17229==    at 0x401CC31: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==17229==    by 0x4180589: Manager::GetToolsManager() const (manager.h:139)
==17229==    by 0x8090EF4: MainFrame::CreateMenubar() (main.cpp:673)
==17229==    by 0x8091DAF: MainFrame::CreateIDE() (main.cpp:537)
==17229==    by 0x8092A47: MainFrame::MainFrame(wxWindow*) (main.cpp:458)
==17229==    by 0x8065B5A: CodeBlocksApp::InitFrame() (app.cpp:218)
==17229==    by 0x8066B66: CodeBlocksApp::OnInit() (app.cpp:378)
==17229==    by 0x8067890: wxAppConsole::CallOnInit() (app.h:87)
==17229==    by 0x4AA0B91: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4B90420: (below main) (in /lib/libc-2.3.6.so)
==17229==
==17229== Invalid write of size 4
==17229==    at 0x483AECA: wxTimer::Stop() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==17229==    by 0x4A6B477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFA602: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFA7C6: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFA8E3: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4AFAB56: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4A6BA18: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4180022: Manager::ProcessPendingEvents() (manager.cpp:105)
==17229==    by 0x41E9138: SimpleTextLog::AddLog(wxString const&, bool) (simpletextlog.cpp:66)
==17229==    by 0x418496B: MessageManager::Log(wchar_t const*, ...) (messagemanager.cpp:232)
==17229==    by 0x41F11AD: ToolsManager::OnToolStdOutput(CodeBlocksEvent&) (toolsmanager.cpp:384)
==17229==    by 0x4A6B477: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==  Address 0x6DA13FC is 0 bytes after a block of size 164 alloc'd
==17229==    at 0x401CC31: operator new(unsigned) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==17229==    by 0x4180589: Manager::GetToolsManager() const (manager.h:139)
==17229==    by 0x8090EF4: MainFrame::CreateMenubar() (main.cpp:673)
==17229==    by 0x8091DAF: MainFrame::CreateIDE() (main.cpp:537)
==17229==    by 0x8092A47: MainFrame::MainFrame(wxWindow*) (main.cpp:458)
==17229==    by 0x8065B5A: CodeBlocksApp::InitFrame() (app.cpp:218)
==17229==    by 0x8066B66: CodeBlocksApp::OnInit() (app.cpp:378)
==17229==    by 0x8067890: wxAppConsole::CallOnInit() (app.h:87)
==17229==    by 0x4AA0B91: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.2.0)
==17229==    by 0x4B90420: (below main) (in /lib/libc-2.3.6.so)
==17229==
==17229== Invalid read of size 4
==17229==    at 0x483B0B2: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.2.0)
==17229==    by 0x50D9C26: (within /usr/lib/libglib-2.0.so.0.800.6)
==17229==  Address 0x68 is not stack'd, malloc'd or (recently) free'd
Crash is caused by last call but, but two previous ones are incorrect... For me it's hard to say what is problem, i am not familiar with Code::Blocks sources.
This is from revision 2449.

Title: Re: LINUX: Tools Run Crash and Company...
Post by: thomas on May 13, 2006, 01:46:10 pm
Regarding invalid read from tinyXML, that is correct, it is a known bug. The buffer is not null-terminated, which was a programming mistake of mine, not tinyXML's fault.

It is not an issue, though. Since March 13, we're using a completely different loading strategy in the development branch, which, among other things, fixes this bug.

However, since nobody ever seemed to have had a problem with the missing '\0' in 7 months (most of the time, there happens to be one by chance), I left the buggy code in HEAD untouched for now.
Modifying the same text block inside the same file in two different revision-controlled source trees causes a lot of havoc, which is something you like to avoid when you can ;)

The trees will be merged by the end of this month, anyway. By that time, this problem will be fixed, too.

The other thing... no bloody idea :)
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 13, 2006, 10:13:49 pm
However, since nobody ever seemed to have had a problem with the missing '\0' in 7 months (most of the time, there happens to be one by chance), I left the buggy code in HEAD untouched for now.
It is no "problem" as memory allocations rutines usually alloc more space for program, then even as it looks as invalid read, it is read in program memory as far i know.

The other thing... no bloody idea :)
I tried to get a debug version of wxwidgets to see if i can get more information but result is the same. Only problem is a bunch of ASSERTS from wxwidgets in load process (like loading if image of size zero). I can locate them all and send reports, but i don't know if You are concerned about them. It only result in that the debug version is unusable with Code::Blocks.
As for error i would say that wxTimer was freed somehow before call, but i may be wrong.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 16, 2006, 07:47:43 pm
I manage to test same configuration (or similar one) on Windows machine. And what? It works... how suprising.
But i use LINUX, may someone help me to debug this problem? Maybe some instructions how this can be made. I want it fixed, i may even try to hack Code::Blocks sources.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: thomas on May 16, 2006, 08:34:38 pm
I manage to test same configuration (or similar one) on Windows machine. And what? It works... how suprising.
That confirms the suspicion that I was getting after reading your other thread. Possibly the problem is not to be found in Code::Blocks at all, but in some weird configuration (or buggy library versions) of your gentoo system.
It just seems strange that nothing works for you whereas it mostly works quite OK for everybody.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: mandrav on May 16, 2006, 08:50:08 pm
I manage to test same configuration (or similar one) on Windows machine. And what? It works... how suprising.
But i use LINUX, may someone help me to debug this problem? Maybe some instructions how this can be made. I want it fixed, i may even try to hack Code::Blocks sources.

Surprise: I mainly use linux and everything works here too (3 installations, all debian based).
Try the following please:

Code
make clean-zipfiles
make clean-bin
make
make install
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 16, 2006, 10:38:00 pm
I manage to test same configuration (or similar one) on Windows machine. And what? It works... how suprising.
That confirms the suspicion that I was getting after reading your other thread. Possibly the problem is not to be found in Code::Blocks at all, but in some weird configuration (or buggy library versions) of your gentoo system.
It just seems strange that nothing works for you whereas it mostly works quite OK for everybody.

Maybe, but this would be the first application that works weird. As for wxWidgets i use onlt aMule - it works stable. But hey i use gcc-4.1, who knows implications.
At weekend i will install some binary distribution, probably debian and see results. When i will heve some new info i will post it here.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 23, 2006, 11:22:07 am
New informations...
I managed to install debian unstable, get newest svn build (i use a ubuntu deb package http://forums.codeblocks.org/index.php?topic=3172.0 (http://forums.codeblocks.org/index.php?topic=3172.0)) and get crash with tools.
What i have done?
Added tool named: ln
Executable: ln
Parameters: --help
Run this and crash. Valgrind output, i have to say it is slighty different, it has slighty different trace, why? i don't have any idea, but problem is with the same element.
Code
==4175== Invalid read of size 4
==4175==    at 0x465A8CA: wxTimer::Stop() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x420068F: ToolsManager::OnToolTerminated(CodeBlocksEvent&) (in /usr/lib/libcodeblocks.so.0.0.1)
==4175==    by 0x48AE814: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x49403F2: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x49405FE: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x49407DE: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x4940E45: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x48AEB7B: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x4634F9B: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x527A7C0: (within /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x52781AB: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x527B63A: (within /usr/lib/libglib-2.0.so.0.1000.2)
==4175==  Address 0x698647C is 0 bytes after a block of size 164 alloc'd
==4175==    at 0x401C825: operator new(unsigned) (vg_replace_malloc.c:164)
==4175==    by 0x4180617: Manager::GetToolsManager() const (in /usr/lib/libcodeblocks.so.0.0.1)
==4175==    by 0x808D546: (within /usr/bin/codeblocks)
==4175==    by 0x808E3F7: (within /usr/bin/codeblocks)
==4175==    by 0x808F198: (within /usr/bin/codeblocks)
==4175==    by 0x806609D: (within /usr/bin/codeblocks)
==4175==    by 0x8066E40: (within /usr/bin/codeblocks)
==4175==    by 0x80680FE: wxAppConsole::CallOnInit() (in /usr/bin/codeblocks)
==4175==    by 0x48E56BF: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x48E57A5: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x8062A43: (within /usr/bin/codeblocks)
==4175==    by 0x4AC8EAF: (below main) (in /lib/tls/libc-2.3.6.so)
==4175==
==4175== Invalid write of size 4
==4175==    at 0x465A8DA: wxTimer::Stop() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x420068F: ToolsManager::OnToolTerminated(CodeBlocksEvent&) (in /usr/lib/libcodeblocks.so.0.0.1)
==4175==    by 0x48AE814: wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x49403F2: wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x49405FE: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x49407DE: wxEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x4940E45: wxEvtHandler::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x48AEB7B: wxAppConsole::ProcessPendingEvents() (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x4634F9B: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x527A7C0: (within /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x52781AB: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x527B63A: (within /usr/lib/libglib-2.0.so.0.1000.2)
==4175==  Address 0x698647C is 0 bytes after a block of size 164 alloc'd
==4175==    at 0x401C825: operator new(unsigned) (vg_replace_malloc.c:164)
==4175==    by 0x4180617: Manager::GetToolsManager() const (in /usr/lib/libcodeblocks.so.0.0.1)
==4175==    by 0x808D546: (within /usr/bin/codeblocks)
==4175==    by 0x808E3F7: (within /usr/bin/codeblocks)
==4175==    by 0x808F198: (within /usr/bin/codeblocks)
==4175==    by 0x806609D: (within /usr/bin/codeblocks)
==4175==    by 0x8066E40: (within /usr/bin/codeblocks)
==4175==    by 0x80680FE: wxAppConsole::CallOnInit() (in /usr/bin/codeblocks)
==4175==    by 0x48E56BF: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x48E57A5: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x8062A43: (within /usr/bin/codeblocks)
==4175==    by 0x4AC8EAF: (below main) (in /lib/tls/libc-2.3.6.so)
==4175==
==4175== Invalid read of size 4
==4175==    at 0x465ABF2: (within /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x5279FA5: (within /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x52781AB: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x527B63A: (within /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x527B996: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1000.2)
==4175==    by 0x4EB2340: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.800.17)
==4175==    by 0x4650B37: wxEventLoop::Run() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x46EDB48: wxAppBase::MainLoop() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x46EDC40: wxAppBase::OnRun() (in /usr/lib/libwx_gtk2u_core-2.6.so.0.3.1)
==4175==    by 0x8064A4D: (within /usr/bin/codeblocks)
==4175==    by 0x48E56E9: wxEntry(int&, wchar_t**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==    by 0x48E57A5: wxEntry(int&, char**) (in /usr/lib/libwx_baseu-2.6.so.0.3.1)
==4175==  Address 0x44 is not stack'd, malloc'd or (recently) free'd

Additionally this build produced a file codeblocks.xml:
Code
<?xml version="1.0" encoding="utf-8"?>
<report version="1.0" kind="exception">
  <system description="Linux 2.6.16-1-k7 i686"/>
  <modules>
    <module path="/lib/ld-2.3.6.so" address="04000000" size="00017000" version="2.3.6"/>
    <module path="/usr/lib/valgrind/x86-linux/vgpreload_core.so" address="04019000" size="00002000" version="linux/vgpreload_core"/>
    <module path="/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so" address="0401f000" size="00001000" version="linux/vgpreload_memcheck"/>
    <module path="/usr/lib/gconv/ISO8859-1.so" address="04021000" size="00002000" version="1"/>
    <module path="/usr/lib/X11/locale/common/xlcDef.so.2.0.0" address="04025000" size="00001000" version="2.0.0"/>
    <module path="/usr/lib/libcodeblocks.so.0.0.1" address="04029000" size="00347000" version="0.0.1"/>
    <module path="/lib/tls/libpthread-2.3.6.so" address="04374000" size="00010000" version="2.3.6"/>
    <module path="/lib/tls/libdl-2.3.6.so" address="04386000" size="00004000" version="2.3.6"/>
    <module path="/usr/lib/libwx_gtk2u_xrc-2.6.so.0.3.1" address="0438b000" size="00082000" version="0.3.1"/>
    <module path="/usr/lib/libwx_gtk2u_qa-2.6.so.0.3.1" address="0440e000" size="00020000" version="0.3.1"/>
    <module path="/usr/lib/libwx_gtk2u_html-2.6.so.0.3.1" address="044b2000" size="00005000" version="0.3.1"/>
    <module path="/usr/lib/libwx_gtk2u_adv-2.6.so.0.3.1" address="044b8000" size="0009b000" version="0.3.1"/>
    <module path="/usr/lib/libwx_gtk2u_core-2.6.so.0.3.1" address="04555000" size="002e1000" version="0.3.1"/>
    <module path="/usr/lib/libwx_baseu_xml-2.6.so.0.3.1" address="0483d000" size="00009000" version="0.3.1"/>
    <module path="/usr/lib/libwx_baseu_net-2.6.so.0.3.1" address="04870000" size="00002000" version="0.3.1"/>
    <module path="/usr/lib/libwx_baseu-2.6.so.0.3.1" address="04987000" size="0000e000" version="0.3.1"/>
    <module path="/usr/lib/libstdc++.so.6.0.8" address="049a2000" size="000db000" version="6.0.8"/>
    <module path="/lib/tls/libm-2.3.6.so" address="04a83000" size="00026000" version="2.3.6"/>
    <module path="/lib/libgcc_s.so.1" address="04ab3000" size="00001000" version="1"/>
    <module path="/lib/tls/libc-2.3.6.so" address="04be2000" size="00008000" version="2.3.6"/>
    <module path="/usr/lib/libwxscintilla.so.0.0.1" address="04bed000" size="00102000" version="0.0.1"/>
    <module path="/usr/lib/libgdk-x11-2.0.so.0.800.17" address="04cf0000" size="00082000" version="0.800.17"/>
    <module path="/usr/lib/libz.so.1.2.3" address="04d85000" size="00001000" version="1.2.3"/>
    <module path="/usr/lib/libgtk-x11-2.0.so.0.800.17" address="0506e000" size="00009000" version="0.800.17"/>
    <module path="/usr/lib/libatk-1.0.so.0.1114.0" address="0507a000" size="0001a000" version="0.1114.0"/>
    <module path="/usr/lib/libgdk_pixbuf-2.0.so.0.800.17" address="05095000" size="00016000" version="0.800.17"/>
    <module path="/usr/lib/libfontconfig.so.1.0.4" address="050d4000" size="00005000" version="1.0.4"/>
    <module path="/usr/lib/libXext.so.6.4.0" address="050da000" size="0000e000" version="6.4.0"/>
    <module path="/usr/lib/libXrender.so.1.3.0" address="050ef000" size="00001000" version="1.3.0"/>
    <module path="/usr/lib/libXinerama.so.1.0.0" address="050f2000" size="00001000" version="1.0.0"/>
    <module path="/usr/lib/libXi.so.6.0.0" address="050fa000" size="00001000" version="6.0.0"/>
    <module path="/usr/lib/libXrandr.so.2.0.0" address="050fc000" size="00004000" version="2.0.0"/>
    <module path="/usr/lib/libXcursor.so.1.0.2" address="05108000" size="00001000" version="1.0.2"/>
    <module path="/usr/lib/libXfixes.so.3.0.0" address="0510d000" size="00001000" version="3.0.0"/>
    <module path="/usr/lib/libpango-1.0.so.0.1200.1" address="05145000" size="00002000" version="0.1200.1"/>
    <module path="/usr/lib/libX11.so.6.2.0" address="0520c000" size="00003000" version="6.2.0"/>
    <module path="/usr/lib/libgobject-2.0.so.0.1000.2" address="05249000" size="00001000" version="0.1000.2"/>
    <module path="/usr/lib/libgmodule-2.0.so.0.1000.2" address="0524b000" size="00004000" version="0.1000.2"/>
    <module path="/usr/lib/libgthread-2.0.so.0.1000.2" address="05252000" size="00001000" version="0.1000.2"/>
    <module path="/usr/lib/libglib-2.0.so.0.1000.2" address="052da000" size="00001000" version="0.1000.2"/>
    <module path="/usr/lib/libpng12.so.0.1.2.8" address="052ff000" size="00001000" version="0.1.2.8"/>
    <module path="/usr/lib/libjpeg.so.62.0.0" address="0531f000" size="00001000" version="62.0.0"/>
    <module path="/usr/lib/libtiff.so.4.2.1" address="05372000" size="00003000" version="4.2.1"/>
    <module path="/usr/lib/libexpat.so.1.0.0" address="05376000" size="00020000" version="1.0.0"/>
    <module path="/usr/lib/libpangocairo-1.0.so.0.1200.1" address="0539d000" size="00001000" version="0.1200.1"/>
    <module path="/usr/lib/libcairo.so.2.2.4" address="053e7000" size="00001000" version="2.2.4"/>
    <module path="/usr/lib/libfreetype.so.6.3.10" address="053e9000" size="0006c000" version="6.3.10"/>
    <module path="/usr/lib/libXau.so.6.0.0" address="05457000" size="00001000" version="6.0.0"/>
    <module path="/usr/lib/libXdmcp.so.6.0.0" address="0545b000" size="00002000" version="6.0.0"/>
    <module path="/usr/lib/libpangoft2-1.0.so.0.1200.1" address="05481000" size="00001000" version="0.1200.1"/>
    <module path="/usr/lib/locale/locale-archive" address="05585000" size="00047000"/>
    <module path="/usr/lib/pango/1.5.0/modules/pango-basic-fc.so" address="055d6000" size="00003000" version="fc"/>
    <module path="/lib/tls/libnss_compat-2.3.6.so" address="055df000" size="00009000" version="2.3.6"/>
    <module path="/lib/tls/libnsl-2.3.6.so" address="055fa000" size="00002000" version="2.3.6"/>
    <module path="/lib/tls/libnss_nis-2.3.6.so" address="055fe000" size="0000a000" version="2.3.6"/>
    <module path="/lib/tls/libnss_files-2.3.6.so" address="05612000" size="00002000" version="2.3.6"/>
    <module path="/usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so" address="0572e000" size="00013000" version="2.0/2.4.0/engines/libclearlooks"/>
    <module path="/usr/lib/libart_lgpl_2.so.2.3.17" address="05756000" size="00001000" version="2.3.17"/>
    <module path="/usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-xpm.so" address="0575d000" size="00001000" version="xpm"/>
    <module path="/usr/lib/libgnomeprint-2-2.so.0.1.0" address="05c61000" size="00063000" version="0.1.0"/>
    <module path="/usr/lib/libxml2.so.2.6.24" address="05dd7000" size="00005000" version="2.6.24"/>
    <module path="/usr/lib/libgnomeprintui-2-2.so.0.1.0" address="05ddd000" size="00038000" version="0.1.0"/>
    <module path="/usr/lib/libgnomecanvas-2.so.0.1400.0" address="05e3f000" size="00001000" version="0.1400.0"/>
    <module path="/SYSV00000000" address="06e40000" size="00060000"/>
    <module path="/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf" address="072e5000" size="00054000"/>
    <module path="/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf" address="07353000" size="00024000"/>
    <module path="/usr/share/codeblocks/plugins/libprojectwizard.so" address="073d7000" size="0004a000"/>
    <module path="/usr/share/codeblocks/plugins/libwxsmith.so" address="075a4000" size="00017000"/>
    <module path="/usr/share/codeblocks/plugins/libastyle.so" address="075bf000" size="0004a000"/>
    <module path="/usr/share/codeblocks/plugins/libcodestat.so" address="07630000" size="00002000"/>
    <module path="/usr/share/codeblocks/plugins/libtodo.so" address="07661000" size="00003000"/>
    <module path="/usr/share/codeblocks/plugins/libdefaultmimehandler.so" address="07686000" size="00002000"/>
    <module path="/usr/share/codeblocks/plugins/libkeybinder.so" address="076ce000" size="00003000"/>
    <module path="/usr/share/codeblocks/plugins/libpluginwizard.so" address="076f4000" size="00002000"/>
    <module path="/usr/share/codeblocks/plugins/libprofiler.so" address="07721000" size="00002000"/>
    <module path="/usr/share/codeblocks/plugins/libclasswizard.so" address="07731000" size="00001000"/>
    <module path="/usr/share/codeblocks/plugins/libhelp_plugin.so" address="07758000" size="00002000"/>
    <module path="/usr/share/codeblocks/plugins/libcodecompletion.so" address="077eb000" size="00005000"/>
    <module path="/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansCondensed-Bold.ttf" address="07ff9000" size="00043000"/>
    <module path="/usr/bin/codeblocks" address="080d6000" size="00006000"/>
    <module path="/usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf" address="08bdd000" size="00031000"/>
    <module path="/usr/lib/valgrind/x86-linux/memcheck" address="0a143000" size="00001000"/>
    <module path="[stack]" address="afa5b000" size="00015000"/>
  </modules>
  <stack>
    <frame level="2" function="wxStackWalker::Walk(unsigned int)" offset="0000002e"/>
    <frame level="3" function="wxDebugReport::AddContext(wxDebugReport::Context)" offset="000009f2"/>
    <frame level="4" function="wxDebugReport::AddAll(wxDebugReport::Context)" offset="00000018"/>
    <frame level="5" function="wxHtmlWindow::LoadPage(wxString const&amp;)" offset="00000cdc"/>
    <frame level="6" function="wxFatalSignalHandler" offset="00000026"/>
    <frame level="7"/>
    <frame level="8"/>
    <frame level="9"/>
    <frame level="10" function="g_main_context_dispatch" offset="000001fc"/>
    <frame level="11"/>
    <frame level="12" function="g_main_loop_run" offset="000001f7"/>
    <frame level="13" function="gtk_main" offset="000000c1"/>
    <frame level="14" function="wxEventLoop::Run()" offset="00000058"/>
    <frame level="15" function="wxAppBase::MainLoop()" offset="00000059"/>
    <frame level="16" function="wxAppBase::OnRun()" offset="00000021"/>
    <frame level="17"/>
    <frame level="18" function="wxEntry(int&amp;, wchar_t**)" offset="0000006a"/>
    <frame level="19" function="wxEntry(int&amp;, char**)" offset="00000036"/>
    <frame level="20" function="EditorBase::CreateContextSubMenu(int)" offset="000002bc"/>
  </stack>
</report>

I contacted with one other Gentoo User but he doesn't have these strange crash problems.
One more thought, this problem is with last element of class ToolsManager, wxTimer, so maybe it could be a problem with structure alignment? But this is a blind shoot...
I can't send anything about debian configuration, nor how this binary package was created but i can give some specific informations about my system configuration, but i must say, i don't use anything weird, i never had problems with any library configuration, also i use one more wxWidgets application (aMule) and it works without problems.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: mandrav on May 23, 2006, 11:41:21 am
Here you go:

Code: cpp
void ToolsManager::OnToolTerminated(CodeBlocksEvent& event)
{
    m_Timer.Stop(); // <-- your crash is here
    m_Pid = 0;
    m_pProcess = 0;

    Manager::Get()->GetMessageManager()->Log(_T("Tool execution terminated with status %d"), event.GetInt());
}

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?

Quote
i never had problems with any library configuration, also i use one more wxWidgets application (aMule) and it works without problems.

This means absolutely nothing. Nil.
The fact that two apps use the same widgets lib under the hood doesn't necessarily indicate faulty usage in one of them (if one is misbehaving). Especially if that lib is wxWidgets. You can have it configured in so many ways (static/shared, monolithic/modular, unicode/ansi, etc).

Quote
I can't send anything about debian configuration, nor how this binary package was created but i can give some specific informations about my system configuration

And you really want to get help after stating this?
Well, I will ask for info and you decide if you want to give me some.
I need the output of the following commands:
Code
wx-config --cflags
wx-config --libs
ldd codeblocks
ldd libcodeblocks.so

(I just hope you 're not using a static wxWidgets build)
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Michael on May 23, 2006, 11:55:16 am
Hallo,

I have checked both under Gentoo (rev2489) and Ubuntu 5.10 (.deb package rev2484). I have added ln as tool with --help as parameter.

Gentoo works fine, but Ubuntu crashes. It crashes when I press enter (but also with the X button) to close the command line windows and generates the same error report as posted by moloh.

It is possible that this is just a problem of the .deb package instead of C::B itself.

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

Best wishes,
Michael
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Der Meister on May 23, 2006, 12:38:40 pm
@mandrav:
The crash does not occur at this position. Valgring simply reports that there is something (possibly) wrong at this place - but its inside a wxWidgets function thus probably not "our" fault. If it would crash there valgrind should not report any other issues beyond this place - but it does.
But the main reason is: Take a look at the backtrace. Unfortunately it is not a complete one, but you can see that above frame level 20 (EditorBase::CreateContextSubMenu(int)) a new main loop is created - looks like one of those wxYield-re-entrance-problems to me. Anyway, this is still strange because I can't see a call to wxYield in the backtrace (OK, it is not complete - maybe some important parts are missing) and with a quick look I couldn't find any problematic line in 'EditorBase::CreateContextSubMenu' that could lead into such trouble.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: mandrav on May 23, 2006, 12:51:20 pm
@mandrav:
... and with a quick look I couldn't find any problematic line in 'EditorBase::CreateContextSubMenu' that could lead into such trouble.

The backtrace is invalid. Unless I 'm mistaken, he experiences this crash when running a custom tool. EditorBase::CreateContextSubMenu() just doesn't belong in this picture...
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Michael on May 23, 2006, 02:17:59 pm
Hello,

I have built a .deb package for rev2489, but still get the same crash. And I have used make clean-zipfiles, before building.

Best wishes,
Michael
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza on May 23, 2006, 03:27:33 pm
I tried with my own compiled version in Dapper and get the crash calling ln --help with any launching option, and get the same backtrace too.

I also tried calling a python program that just prints argv and it works fine.

Time to wonder...

BTW, I also tried calling ln --help under Windows (I have unxutils in the path) and it worked fine (it's meaningless, I know, but I just wanted to try :)).
Title: Re: LINUX: Tools Run Crash and Company...
Post by: mandrav on May 23, 2006, 04:05:55 pm
I tried with my own compiled version in Dapper and get the crash calling ln --help with any launching option, and get the same backtrace too.

So you are looking at it? Good :)
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza 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) :)
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 23, 2006, 09:06:11 pm
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.

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)
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Michael on May 24, 2006, 12:06:10 pm
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
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 24, 2006, 10:47:14 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.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh 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?
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh 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.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on May 25, 2006, 10:43:23 pm
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.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza 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 :D
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 02, 2006, 05:21:18 am
Well, time to remove some code :D

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 (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).


Title: Re: LINUX: Tools Run Crash and Company...
Post by: 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.

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.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 02, 2006, 07:49:46 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...

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.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza 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?
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh 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.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: 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.

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]
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 02, 2006, 09:02:50 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:
Added tool named: ln
Executable: ln
Parameters: --help

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)?

[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]
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza on June 02, 2006, 09:29:51 am
This in Execute: 141134688 <-- address of an instance of ToolsManager.
This in Execute (c cast): 141134692 <-- here's an offset adjustment so it points to base (wxEvtHandler).
This in Execute (static cast): 141134693 <-- idem
This in Execute (reinterpret cast): 141134688 <-- cast without offset adjustment (dangerous). You must really know what you're doing.
This in Execute (dynamic cast): 141134692 <-- cast solved at run-time. It'll adjust the offset too.
This in OnToolTerminated: 141134692 <-- Compiler bug? this of the wxEvtHandler for a call to a ToolsManager member function.

If you're using GCC 4.x, could you try the same code with 3.4.x?

Setting to 0 m_Pid and m_pProcess with a displacement of 4 bytes...

Since those are the last two variables of ToolsManager, and considering a typical 32 bits architecture they both would be the same size, m_pProcess = 0 would be setting m_Pid to 0, and m_Pid = 0 would be setting something out of ToolsManager space to 0 (it'd explain a possible crash and a possible attemp to access memory that doesn't belong to the object in no way).

If PipedProcess didn't modify m_pProcess thru that void **, m_pProcess would keep its old value :shock:

Those are my guesses.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 02, 2006, 09:49:37 am
This in Execute: 141134688 <-- address of an instance of ToolsManager.
This in Execute (c cast): 141134692 <-- here's an offset adjustment so it points to base (wxEvtHandler).
This in Execute (static cast): 141134692 <-- idem
This in Execute (reinterpret cast): 141134688 <-- cast without offset adjustment (dangerous). You must really know what you're doing.
This in Execute (dynamic cast): 141134692 <-- cast solved at run-time. It'll adjust the offset too.
This in OnToolTerminated: 141134692 <-- Compiler bug? this of the wxEvtHandler for a call to a ToolsManager member function.

If you're using GCC 4.x, could you try the same code with 3.4.x?

I use 4.1, You mean recompilation on Gentoo with 3.4? I must be crazy to do that. There are incompatibilities in ABI. I want to have working system.
But as far i know there was no problem with gcc-3.4 earlier so *problably* it works correctly.

I see that problem could be lack o vtables, why? How do compiler (program on run-time) can know that parent pointer (wxEvtHandler) in PipedProcess is sth different and make a shift back? Maybe between gcc version they changed layout of multiple derived classes. And here is a problem, but i don't know. I am only average c programmer and raport problem here.
Also There wouldn't be any problem if there were no multiple inheritance? Am i right?

Setting to 0 m_Pid and m_pProcess with a displacement of 4 bytes...

Since those are the last two variables of ToolsManager, and considering a typical 32 bits architecture they both would be the same size, m_pProcess = 0 would be setting m_Pid to 0, and m_Pid = 0 would be setting something out of ToolsManager space to 0 (it'd explain a possible crash and a possible attemp to access memory that doesn't belong to the object in no way).

If PipedProcess didn't modify m_pProcess thru that void **, m_pProcess would keep its old value :shock:

Those are my guesses.
Ow, good! Now You see problem...
Now it works ok (i mean Code::Blocks does not crash, memory access if "safe" as it is close to real *this* pointer), problem was before with wxTimer (i mean Code::Block crash on Tool Termintion).
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza on June 02, 2006, 10:04:53 am
If there was no multiple inheritance, or if at least the inheritance order was swapped, it should work, but who knows... it's the GCC 4.1 world and crazy things could happen (that just shouldn't) :)

Try this:

toolsmanager.h, line 33, from:
Code: cpp
class DLLIMPORT ToolsManager : public Mgr<ToolsManager>, public wxEvtHandler
to:
Code: cpp
class DLLIMPORT ToolsManager : public wxEvtHandler, public Mgr<ToolsManager>

That should give you the same output for all casts and hopefully for the one in OnTerminate :)
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 02, 2006, 10:17:40 am
If there was no multiple inheritance, or if at least the inheritance order was swapped, it should work, but who knows... it's the GCC 4.1 world and crazy things could happen (that just shouldn't) :)

For me this is still depending on undefined behaviour ;-).
To fix this there have to be made some serious inheritance rearangment in source.

Try this:

toolsmanager.h, line 33, from:
Code: cpp
class DLLIMPORT ToolsManager : public Mgr<ToolsManager>, public wxEvtHandler
to:
Code: cpp
class DLLIMPORT ToolsManager : public wxEvtHandler, public Mgr<ToolsManager>

That should give you the same output for all casts and hopefully for the one in OnTerminate :)
Yes, all are same now.
See You going sleep now, already 2AM here...
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 04, 2006, 02:09:39 am
I would like to know if now, as You know what is the problem, there would be some patch to this problem.
I would appreciate any information.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza on June 04, 2006, 03:39:22 am
Well, since this problem makes no sense (becoming a compiler's problem), maybe the trick in toolsmanager.h line 33 could work as a patch (you said it's giving you the same value of this everywhere), but I cannot assure it'll solve everything.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 04, 2006, 03:53:21 am
Well, since this problem makes no sense (becoming a compiler's problem), maybe the trick in toolsmanager.h line 33 could work as a patch (you said it's giving you the same value of this everywhere), but I cannot assure it'll solve everything.

I think it won't, ie. it can cause problems with gcc-3.4. Also this is only workaround, not a true patch for pointer casts problems.
I must also say that i think gcc-4.1 behaviour is resonable. Ok then, if there would be any new info, please post it in this thread.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza on June 04, 2006, 04:25:36 am
That fix won't cause problems with GCC 3.4.x, it'll just change the order of the base classes in memory. If you recompile the whole thing it'll work, but it'd be good if you could try it and check for those random crashes first.

A true patch wouldn't be applied to Code::Blocks but GCC itself since we'ren't the ones causing the problem. In the meanwhile, if that works for you, we could apply the workaround so it'll work with GCC 4.1.

That behaviour is completely wrong from GCC 4.1 since it's the one that fails setting this to the right value when calling that member function. It really has nothing to do with Code::Blocks.

Just in case: that cast to void ** has nothing to do with it.

[edit]
I just tried recompiling Code::Blocks with GCC 4.1.1 (MinGW) and the problem showed up here (it didn't crash, but this changed its value from one call to another).

It'd be good to report this bug, even though to know the real problem I'd need to dig deep in wxWidget's sources and find what makes GCC 4.1 go wrong.

Apart of taking some time until I get a small testcase, this bug could be already reported, but hard to find in the bug tracker.
[/edit]
Title: Re: LINUX: Tools Run Crash and Company...
Post by: Ceniza on June 04, 2006, 06:29:48 am
I took a look at the event "construction", which is just a bunch of casts, and replaced it just as suggested in the wxWidget's manual (adding even more casts) and... voilĂ ! The value of this is right for both calls now (good luck or fix... nobody knows).

I checked the address returned by both bunch of casts and both return the same address. It's even more confusing now because if it was the problem it should, at least, return different values.

I decided to check that 'cause I thought some evil magic there could cause it, but having the same value returned do also makes sense after all, 'cause we're playing with pointers to member functions.

At the end it could be some deep cast in wxWidget's code being generated differently by GCC 4.1, but the results of my tests just confuse me more.

For reference: sdk_events.h, line 209, from:
Code: cpp
#define EVT_PIPEDPROCESS_TERMINATED(id, fn) DECLARE_EVENT_TABLE_ENTRY( cbEVT_PIPEDPROCESS_TERMINATED, id, wxID_ANY, (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) & fn, (wxObject *) NULL ),
to:
Code: cpp
#define EVT_PIPEDPROCESS_TERMINATED(id, fn) DECLARE_EVENT_TABLE_ENTRY( cbEVT_PIPEDPROCESS_TERMINATED, id, wxID_ANY, (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) (wxNotifyEventFunction) (CodeBlocksEventFunction)&fn, (wxObject *) NULL ),

Right now, the most confusing part is why that change makes it work if it seems to change absolutely nothing at all  :(
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 04, 2006, 07:20:13 am
Right now, the most confusing part is why that change makes it work if it seems to change absolutely nothing at all  :(

I must say, interesting... so i know why in documentation they said:
Quote
...Watch out to put in enough casts to the inherited event function...
I agree i don't understand this... but for sure it has sth to do with wxWidgets internals.
Title: Re: LINUX: Tools Run Crash and Company...
Post by: moloh on June 11, 2006, 08:25:08 pm
Could this and other event definitions could be fixed before rc3?