Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: BlueHazzard on June 15, 2019, 11:45:05 am

Title: Crash with batch build on linux
Post by: BlueHazzard on June 15, 2019, 11:45:05 am
Hi, i use the command line on my headless server to build codeblocks projects...
I can not reproduce this 100% but it occurs 1 in 6 times: I get a crash "call of pure virtual function" on the finish of a compilation.
This is the backtrace:
Code
#0  0x00007ffff41dee97 in raise () at /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff41e0801 in abort () at /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff4bd3957 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff4bd9ab6 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff4bd9af1 in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff4bda8bf in  () at /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff5bf2e29 in wxTextEntryBase::DoSetValue(wxString const&, int) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#7  0x00007ffff5acd507 in  () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#8  0x00007ffff76b2a2b in TextCtrlLogger::Clear() (this=0x555556356c40) at loggers.cpp:165
#9  0x00007fffe91d91f1 in CompilerGCC::ClearLog(bool) (this=0x555555fcc0f0, switchToLog=false) at compilergcc.cpp:1079
#10 0x00007fffe91e840b in CompilerGCC::OnWorkspaceClosed(CodeBlocksEvent&) (this=0x555555fcc0f0, event=...) at compilergcc.cpp:3437
#11 0x00007fffe91f9411 in cbEventFunctor<CompilerGCC, CodeBlocksEvent>::Call(CodeBlocksEvent&) (this=0x555556533590, event=...) at ../../../src/include/cbfunctor.h:49
#12 0x00007ffff76c3e9a in Manager::ProcessEvent(CodeBlocksEvent&) (this=0x555555b26ba0, event=...) at manager.cpp:263
#13 0x00007ffff76e262b in PluginManager::NotifyPlugins(CodeBlocksEvent&) (this=0x555555f17700, event=...) at pluginmanager.cpp:1522
#14 0x00007ffff770e88f in ProjectManager::CloseWorkspace() (this=0x555555d8f900) at projectmanager.cpp:620
#15 0x00005555556807a7 in MainFrame::DoCloseCurrentWorkspace() (this=0x555555bdb710) at main.cpp:2049
#16 0x0000555555687529 in MainFrame::OnApplicationClose(wxCloseEvent&) (this=0x555555bdb710, event=...) at main.cpp:2929
#17 0x00007ffff52d24be in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#18 0x00007ffff52d25c3 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#19 0x00007ffff52d298b in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#20 0x00007ffff52d2783 in wxEvtHandler::DoTryChain(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#21 0x00007ffff52d2a75 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#22 0x00007ffff52d27d7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#23 0x00007ffff5c039d7 in wxWindowBase::Close(bool) () at /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#24 0x0000555555605c25 in CodeBlocksApp::OnInit() (this=0x555555a675c0) at app.cpp:759
#25 0x000055555560d5d9 in wxAppConsoleBase::CallOnInit() (this=0x555555a675c0) at /usr/include/wx-3.0/wx/app.h:93
#26 0x00007ffff51e0b3a in wxEntry(int&, wchar_t**) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#27 0x0000555555603bcb in main(int, char**) (argc=5, argv=0x7fffffffe428) at app.cpp:338
Any ideas how to debug this?
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on June 15, 2019, 02:20:39 pm
Run cb from cb and debug it with gdb. Just edit the program arguments and/or work folder.

Most probably the text logger is already deleted when clear is called.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on June 16, 2019, 07:03:45 pm
Wasn't there a ticket or a forum post about the log panel with a fix lately?
I can not find it anymore...
Title: Re: Crash with batch build on linux
Post by: Miguel Gimenez on June 16, 2019, 07:32:31 pm
Ticket 738:

https://sourceforge.net/p/codeblocks/tickets/738/

I added a check about batch building before clearing the log, but it wasn't accepted.
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on June 16, 2019, 10:21:19 pm
@Miguel: If you look at the backtrace you'll see that this for the clear call is not nullptr, so your fix would probably be unhelpful in this case.
Title: Re: Crash with batch build on linux
Post by: Miguel Gimenez on June 17, 2019, 11:30:53 am
While investigating the crash I found this code snippet (not related directly to the crash) in compilergcc.cpp:

Code
        if (!Manager::IsBatchBuild())
        {
            CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pLog);
            Manager::Get()->ProcessEvent(evt);
        }

        {
            // TODO: This is wrong. We need some automatic way for this to happen!!!
            LogSlot &listSlot = logManager->Slot(m_ListPageIndex);
            delete listSlot.icon;
            listSlot.icon = nullptr;

            LogSlot &slot = logManager->Slot(m_PageIndex);
            delete slot.icon;
            slot.icon = nullptr;
        }

        m_pLog = 0;

The log window removal is made conditionally, but the nullifying of m_pLog always happens. Is this correct?
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 23, 2019, 12:10:36 am
Quote
While investigating the crash I found this code snippet (not related directly to the crash) in compilergcc.cpp:
So you can reproduce the crash?
Title: Re: Crash with batch build on linux
Post by: Miguel Gimenez on July 23, 2019, 11:58:21 am
Didn't try. I haven't used batch building since ticket 738, and the crash I got is fixed in my local copy.

Post the full command you use, if I get time I'll check.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 25, 2019, 11:35:48 pm
Code
==26161==ERROR: AddressSanitizer: heap-use-after-free on address 0x61a000090bc0 at pc 0x7fd9158e6a41 bp 0x7fffba69c060 sp 0x7fffba69c050
READ of size 8 at 0x61a000090bc0 thread T0
    #0 0x7fd9158e6a40 in TextCtrlLogger::Clear() (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x8a8a40)
    #1 0x7fd90153e22e in CompilerGCC::ClearLog(bool) (/home/codeblocks/codeblocks/src/output30/share/codeblocks/plugins/libcompiler.so+0x10422e)
    #2 0x7fd9015649b6 in CompilerGCC::OnWorkspaceClosed(CodeBlocksEvent&) (/home/codeblocks/codeblocks/src/output30/share/codeblocks/plugins/libcompiler.so+0x12a9b6)
    #3 0x7fd901588eb3 in cbEventFunctor<CompilerGCC, CodeBlocksEvent>::Call(CodeBlocksEvent&) (/home/codeblocks/codeblocks/src/output30/share/codeblocks/plugins/libcompiler.so+0x14eeb3)
    #4 0x7fd9159107f0 in Manager::ProcessEvent(CodeBlocksEvent&) (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x8d27f0)
    #5 0x7fd91596ee68 in PluginManager::NotifyPlugins(CodeBlocksEvent&) (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x930e68)
    #6 0x7fd9159da356 in ProjectManager::CloseWorkspace() (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x99c356)
    #7 0x55778b662f64  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x290f64)
    #8 0x55778b67490b  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x2a290b)
    #9 0x7fd9168674bd in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x1e34bd)
    #10 0x7fd9168675c2 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x1e35c2)
    #11 0x7fd91686798a in wxEvtHandler::TryHereOnly(wxEvent&) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x1e398a)
    #12 0x7fd916867782 in wxEvtHandler::DoTryChain(wxEvent&) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x1e3782)
    #13 0x7fd916867a74 in wxEvtHandler::ProcessEvent(wxEvent&) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x1e3a74)
    #14 0x7fd9168677d6 in wxEvtHandler::SafelyProcessEvent(wxEvent&) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0x1e37d6)
    #15 0x7fd9171989d6 in wxWindowBase::Close(bool) (/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0+0x4419d6)
    #16 0x55778b52e391  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x15c391)
    #17 0x55778b54085b  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x16e85b)
    #18 0x7fd916775b39 in wxEntry(int&, wchar_t**) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0xf1b39)
    #19 0x55778b528e66  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x156e66)
    #20 0x7fd914110b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #21 0x55778b526dd9  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x154dd9)

0x61a000090bc0 is located 1344 bytes inside of 1408-byte region [0x61a000090680,0x61a000090c00)
freed by thread T0 here:
    #0 0x7fd9187b22d0 in operator delete(void*) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe12d0)
    #1 0x7fd917197316 in wxWindowBase::Destroy() (/usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0+0x440316)

previously allocated by thread T0 here:
    #0 0x7fd9187b1458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7fd9158e6be1 in TextCtrlLogger::CreateControl(wxWindow*) (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x8a8be1)
    #2 0x7fd90157e7e9 in BuildLogger::CreateControl(wxWindow*) (/home/codeblocks/codeblocks/src/output30/share/codeblocks/plugins/libcompiler.so+0x1447e9)
    #3 0x55778b68c058  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x2ba058)
    #4 0x55778b6beea3  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x2ecea3)
    #5 0x7fd915911534 in Manager::ProcessEvent(CodeBlocksLogEvent&) (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x8d3534)
    #6 0x7fd901530e5c in CompilerGCC::OnAttach() (/home/codeblocks/codeblocks/src/output30/share/codeblocks/plugins/libcompiler.so+0xf6e5c)
    #7 0x7fd9156bf8ab in cbPlugin::Attach() (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x6818ab)
    #8 0x7fd915958536 in PluginManager::AttachPlugin(cbPlugin*, bool) (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x91a536)
    #9 0x7fd91596a2db in PluginManager::LoadAllPlugins() (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x92c2db)
    #10 0x55778b652241  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x280241)
    #11 0x55778b6417bb  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x26f7bb)
    #12 0x55778b529d6c  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x157d6c)
    #13 0x55778b52dcc1  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x15bcc1)
    #14 0x55778b54085b  (/home/codeblocks/codeblocks/src/output30/codeblocks+0x16e85b)
    #15 0x7fd916775b39 in wxEntry(int&, wchar_t**) (/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0+0xf1b39)

SUMMARY: AddressSanitizer: heap-use-after-free (/home/codeblocks/codeblocks/src/output30/libcodeblocks.so+0x8a8a40) in TextCtrlLogger::Clear()
Shadow bytes around the buggy address:
  0x0c348000a120: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c348000a130: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c348000a140: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c348000a150: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c348000a160: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c348000a170: fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd
  0x0c348000a180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c348000a190: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c348000a1a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c348000a1b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c348000a1c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==26161==ABORTING

sadly the backtrace of the free is not really helpful :(

{edit] the command line:
Code
 output30/run.sh --target=All --no-splash-screen --build CodeBlocks_wx30-unix.workspace 
you probably have to run it a view times until you trigger it...
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on July 26, 2019, 12:50:05 am
Rebuild everything with -fno-omit-frame-pointer.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 26, 2019, 08:22:56 am
By everything you mean also wxWidgets? Because codeblocks is build with -fno-omit-frame-pointer
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on July 26, 2019, 08:40:13 am
The whole system would be best, but yes building wx with -fno-omit-frame-pointer improves backtraces produced by asan.
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on July 26, 2019, 08:45:52 am
But you don't need asan for tracking this problem just place a breakpoint on ~TextCtrlLogger and you'll find who is deleting it.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 26, 2019, 10:04:48 am
Code
[debug]=================================================================
[debug]==16639==ERROR: AddressSanitizer: heap-use-after-free on address 0x61a0000809c0 at pc 0x7ffff4c90861 bp 0x7fffffffba00 sp 0x7fffffffb9f0
[debug]READ of size 8 at 0x61a0000809c0 thread T0
[debug]    #0 0x7ffff4c90860 in TextCtrlLogger::Clear() /home/codeblocks/codeblocks/src/sdk/loggers.cpp:165
[debug]    #1 0x7fffe217813e in CompilerGCC::ClearLog(bool) /home/codeblocks/codeblocks/src/plugins/compilergcc/compilergcc.cpp:1108
[debug]    #2 0x7fffe219e8c6 in CompilerGCC::OnWorkspaceClosed(CodeBlocksEvent&) /home/codeblocks/codeblocks/src/plugins/compilergcc/compilergcc.cpp:3466
[debug]    #3 0x7fffe21c2dc3 in cbEventFunctor<CompilerGCC, CodeBlocksEvent>::Call(CodeBlocksEvent&) /home/codeblocks/codeblocks/src/include/cbfunctor.h:49
[debug]    #4 0x7ffff4cba610 in Manager::ProcessEvent(CodeBlocksEvent&) /home/codeblocks/codeblocks/src/sdk/manager.cpp:269
[debug]    #5 0x7ffff4d18c88 in PluginManager::NotifyPlugins(CodeBlocksEvent&) /home/codeblocks/codeblocks/src/sdk/pluginmanager.cpp:1522
[debug]    #6 0x7ffff4d84176 in ProjectManager::CloseWorkspace() /home/codeblocks/codeblocks/src/sdk/projectmanager.cpp:620
[debug]    #7 0x5555557e4d94 in MainFrame::DoCloseCurrentWorkspace() /home/codeblocks/codeblocks/src/src/main.cpp:2136
[debug]    #8 0x5555557f673b in MainFrame::OnApplicationClose(wxCloseEvent&) /home/codeblocks/codeblocks/src/src/main.cpp:3015
[debug]    #9 0x7ffff602e4e1 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x5fb4e1)
[debug]    #10 0x7ffff602e5ea in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x5fb5ea)
[debug]    #11 0x7ffff602e9f6 in wxEvtHandler::TryHereOnly(wxEvent&) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x5fb9f6)
[debug]    #12 0x7ffff602e7e5 in wxEvtHandler::DoTryChain(wxEvent&) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x5fb7e5)
[debug]    #13 0x7ffff602ead5 in wxEvtHandler::ProcessEvent(wxEvent&) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x5fbad5)
[debug]    #14 0x7ffff602e83e in wxEvtHandler::SafelyProcessEvent(wxEvent&) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x5fb83e)
[debug]    #15 0x7ffff6275777 in wxWindowBase::Close(bool) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x842777)
[debug]    #16 0x5555556b01c1 in CodeBlocksApp::OnInit() /home/codeblocks/codeblocks/src/src/app.cpp:753
[debug]    #17 0x5555556c268b in wxAppConsoleBase::CallOnInit() (/home/codeblocks/codeblocks/src/devel30/codeblocks+0x16e68b)
[debug]    #18 0x7ffff5f3efa1 in wxEntry(int&, wchar_t**) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x50bfa1)
[debug]    #19 0x5555556aac96 in main /home/codeblocks/codeblocks/src/src/app.cpp:338
[debug]    #20 0x7ffff34bab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
[debug]    #21 0x5555556a8c09 in _start (/home/codeblocks/codeblocks/src/devel30/codeblocks+0x154c09)
[debug]0x61a0000809c0 is located 1344 bytes inside of 1408-byte region [0x61a000080480,0x61a000080a00)
[debug]freed by thread T0 here:
[debug]    #0 0x7ffff6efb9d8 in operator delete(void*, unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe19d8)
[debug]    #1 0x7ffff6273fbe in wxWindowBase::Destroy() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x840fbe)
[debug]    #2 0x7ffff627400b in wxWindowBase::DestroyChildren() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x84100b)
[debug]    #3 0x7ffff60afbab in wxWindow::~wxWindow() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x67cbab)
[debug]    #4 0x7ffff622e3ca in wxPanel::~wxPanel() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x7fb3ca)
[debug]    #5 0x7ffff6273fbe in wxWindowBase::Destroy() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x840fbe)
[debug]    #6 0x7ffff64ac83c in wxAuiNotebook::DeletePage(unsigned long) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0xa7983c)
[debug]    #7 0x7ffff64b3739 in wxAuiNotebook::~wxAuiNotebook() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0xa80739)
[debug]    #8 0x7ffff4a0956e in cbAuiNotebook::~cbAuiNotebook() /home/codeblocks/codeblocks/src/sdk/cbauibook.cpp:80
[debug]    #9 0x5555557b8993 in InfoPane::~InfoPane() /home/codeblocks/codeblocks/src/src/infopane.cpp:65
[debug]    #10 0x5555557b89bf in InfoPane::~InfoPane() /home/codeblocks/codeblocks/src/src/infopane.cpp:72
[debug]    #11 0x7ffff6273fbe in wxWindowBase::Destroy() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x840fbe)
[debug]    #12 0x7ffff627400b in wxWindowBase::DestroyChildren() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x84100b)
[debug]    #13 0x7ffff60afbab in wxWindow::~wxWindow() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x67cbab)
[debug]    #14 0x5555556f986e in wxScrollingDialog::~wxScrollingDialog() /home/codeblocks/codeblocks/src/include/scrollingdialog.h:163
[debug]    #15 0x555555840724 in BatchLogWindow::~BatchLogWindow() /home/codeblocks/codeblocks/src/src/batchbuild.h:15
[debug]    #16 0x55555584073f in BatchLogWindow::~BatchLogWindow() /home/codeblocks/codeblocks/src/src/batchbuild.h:15
[debug]    #17 0x7ffff5eb01fa in wxAppConsoleBase::DeletePendingObjects() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x47d1fa)
[debug]    #18 0x7ffff5eb0273 in wxAppConsoleBase::ProcessIdle() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x47d273)
[debug]    #19 0x7ffff614ccdb in wxAppBase::ProcessIdle() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x719cdb)
[debug]    #20 0x7ffff6072a98 in wxApp::DoIdle() (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x63fa98)
[debug]    #21 0x7ffff6072ba2 in wxapp_idle_callback (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x63fba2)
[debug]    #22 0x7ffff148d284 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c284)
[debug]previously allocated by thread T0 here:
[debug]    #0 0x7ffff6efa458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
[debug]    #1 0x7ffff4c90a01 in TextCtrlLogger::CreateControl(wxWindow*) /home/codeblocks/codeblocks/src/sdk/loggers.cpp:171
[debug]    #2 0x7fffe21b86f9 in BuildLogger::CreateControl(wxWindow*) (/home/codeblocks/codeblocks/src/devel30/share/codeblocks/plugins/libcompiler.so+0x1446f9)
[debug]    #3 0x55555580de88 in MainFrame::OnAddLogWindow(CodeBlocksLogEvent&) /home/codeblocks/codeblocks/src/src/main.cpp:5146
[debug]    #4 0x555555840cd3 in cbEventFunctor<MainFrame, CodeBlocksLogEvent>::Call(CodeBlocksLogEvent&) /home/codeblocks/codeblocks/src/include/cbfunctor.h:49
[debug]    #5 0x7ffff4cbb354 in Manager::ProcessEvent(CodeBlocksLogEvent&) /home/codeblocks/codeblocks/src/sdk/manager.cpp:337
[debug]    #6 0x7fffe216ad6c in CompilerGCC::OnAttach() /home/codeblocks/codeblocks/src/plugins/compilergcc/compilergcc.cpp:414
[debug]    #7 0x7ffff4a696cb in cbPlugin::Attach() /home/codeblocks/codeblocks/src/sdk/cbplugin.cpp:73
[debug]    #8 0x7ffff4d02356 in PluginManager::AttachPlugin(cbPlugin*, bool) /home/codeblocks/codeblocks/src/sdk/pluginmanager.cpp:197
[debug]    #9 0x7ffff4d140fb in PluginManager::LoadAllPlugins() /home/codeblocks/codeblocks/src/sdk/pluginmanager.cpp:1108
[debug]    #10 0x5555557d4071 in MainFrame::ScanForPlugins() /home/codeblocks/codeblocks/src/src/main.cpp:1299
[debug]    #11 0x5555557c35eb in MainFrame::MainFrame(wxWindow*) /home/codeblocks/codeblocks/src/src/main.cpp:633
[debug]    #12 0x5555556abb9c in CodeBlocksApp::InitFrame() /home/codeblocks/codeblocks/src/src/app.cpp:505
[debug]    #13 0x5555556afaf1 in CodeBlocksApp::OnInit() /home/codeblocks/codeblocks/src/src/app.cpp:720
[debug]    #14 0x5555556c268b in wxAppConsoleBase::CallOnInit() (/home/codeblocks/codeblocks/src/devel30/codeblocks+0x16e68b)
[debug]    #15 0x7ffff5f3efa1 in wxEntry(int&, wchar_t**) (/home/codeblocks/wxInstall30/lib/libwx_gtk2u-3.0.so.0+0x50bfa1)
[debug]    #16 0x5555556aac96 in main /home/codeblocks/codeblocks/src/src/app.cpp:338
[debug]    #17 0x7ffff34bab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
[debug]SUMMARY: AddressSanitizer: heap-use-after-free /home/codeblocks/codeblocks/src/sdk/loggers.cpp:165 in TextCtrlLogger::Clear()

This output is somehow more useful then the debugger or not? Anyway, i wanted to learn how to use the address sanitizer and now i have a chance to use it :)

The question now is, why is the window destroyed before the application exits?
Title: Re: Crash with batch build on linux
Post by: Miguel Gimenez on July 26, 2019, 01:54:49 pm
The question now is, why is the window destroyed before the application exits?

Because in batch mode it is not needed anymore. The crash is due to the destruction of the log window before closing the workspace, as there is a call to ClearLog() in the workspace closing event.

Solutions:
  - Use --no-batch-window-close in the command line call
  - Destroy the window after closing the workspace, not before
  - Use my patch in ticket 738
  - Mark the window as destroyed and don't call ClearLog() if it is marked
  - Remove the call to ClearLog() from the workspace closing event
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 26, 2019, 03:54:57 pm
Thank you for your feedback....

The patch in ticket 738 is for sure a simple and fast solution....
I have looked into the log window management, and it looks somehow like a big pile that needs some rework...

Quote
Destroy the window after closing the workspace, not before
This is somehow the solution i would like look into... Maybe i find some time...
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on July 26, 2019, 11:08:59 pm
Is this the full stack you will see in a debugger? I doubt it is? How to reproduce this?

Quote
The window is destroyed in the CodeBlocksApp::OnInit method and this needs to change.
Obviously this is the only correct fix. I doubt wx is really happy when we destroy windows from OnInit.
Do not push the fix from the patch in #738, it just hides the problem as I've already stated!!!
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 29, 2019, 11:56:06 pm
i am playing around with this, and this is my first try:
Code
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 22a46dfb1..abb415c60 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -974,6 +974,7 @@ int CodeBlocksApp::BatchJob()
     wxString bb_title = m_pBatchBuildDialog->GetTitle();
     m_pBatchBuildDialog->SetTitle(bb_title + _T(" - ") + title);
     m_pBatchBuildDialog->Show();
+    m_pBatchBuildDialog->Bind(wxEVT_CLOSE_WINDOW, [=](wxCloseEvent& evt) { m_Frame->Close();});
 
     if (m_ReBuild)
     {
@@ -1000,7 +1001,7 @@ int CodeBlocksApp::BatchJob()
     // The batch build log might have been deleted in
     // CodeBlocksApp::OnBatchBuildDone().
     // If it has not, it's still compiling.
-    if (m_pBatchBuildDialog)
+    /*if (m_pBatchBuildDialog)
     {
         // If operation is "--clean", there is no need to display the dialog
         // as the operation is synchronous and it already has finished by the
@@ -1015,7 +1016,7 @@ int CodeBlocksApp::BatchJob()
             m_pBatchBuildDialog->Destroy();
             m_pBatchBuildDialog = nullptr;
         }
-    }
+    }*/
 
     if (tbIcon)
     {
I know Bind is not possible with wx28 but it is a first try... There are still other problems, but i wanted to know if this approach is ok. I am not familiar with this kind of wxWidgets stuff...
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 30, 2019, 08:06:08 am
I also added a timer that moves the BatchBuild() out of the OnInit function. Somehow this is missing in this diff...
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on July 30, 2019, 11:57:19 am
Can you post the full patch?
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on July 31, 2019, 11:39:15 pm
Code
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 22a46dfb1..8b90cae68 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -749,8 +749,15 @@ bool CodeBlocksApp::OnInit()
             s_Loading = false;
             LoadDelayedFiles(frame);
 
-            BatchJob();
-            frame->Close();
+            m_startBatchBuild.Bind(wxEVT_TIMER, [this](wxTimerEvent& evt)
+                {
+                    this->BatchJob();
+                });
+
+            m_startBatchBuild.Start(2000, true);
+
+
+            //frame->Close();
             return true;
         }
 
@@ -974,6 +981,10 @@ int CodeBlocksApp::BatchJob()
     wxString bb_title = m_pBatchBuildDialog->GetTitle();
     m_pBatchBuildDialog->SetTitle(bb_title + _T(" - ") + title);
     m_pBatchBuildDialog->Show();
+    m_pBatchBuildDialog->Bind(wxEVT_CLOSE_WINDOW, [=](wxCloseEvent& evt)
+                                                    {
+                                                        m_Frame->Close();
+                                                    });
 
     if (m_ReBuild)
     {
@@ -1000,7 +1011,7 @@ int CodeBlocksApp::BatchJob()
     // The batch build log might have been deleted in
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 22a46dfb1..8b90cae68 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -749,8 +749,15 @@ bool CodeBlocksApp::OnInit()
             s_Loading = false;
             LoadDelayedFiles(frame);
 
-            BatchJob();
-            frame->Close();
+            m_startBatchBuild.Bind(wxEVT_TIMER, [this](wxTimerEvent& evt)
+                {
+                    this->BatchJob();
+                });
+
+            m_startBatchBuild.Start(2000, true);
+
+
+            //frame->Close();
             return true;
         }
 
@@ -974,6 +981,10 @@ int CodeBlocksApp::BatchJob()
     wxString bb_title = m_pBatchBuildDialog->GetTitle();
     m_pBatchBuildDialog->SetTitle(bb_title + _T(" - ") + title);
     m_pBatchBuildDialog->Show();
+    m_pBatchBuildDialog->Bind(wxEVT_CLOSE_WINDOW, [=](wxCloseEvent& evt)
+                                                    {
+                                                        m_Frame->Close();
+                                                    });
 
     if (m_ReBuild)
     {
@@ -1000,7 +1011,7 @@ int CodeBlocksApp::BatchJob()
     // The batch build log might have been deleted in
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 22a46dfb1..8b90cae68 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -749,8 +749,15 @@ bool CodeBlocksApp::OnInit()
             s_Loading = false;
             LoadDelayedFiles(frame);
 
-            BatchJob();
-            frame->Close();
+            m_startBatchBuild.Bind(wxEVT_TIMER, [this](wxTimerEvent& evt)
+                {
+                    this->BatchJob();
+                });
+
+            m_startBatchBuild.Start(2000, true);
+
+
+            //frame->Close();
             return true;
         }
 
@@ -974,6 +981,10 @@ int CodeBlocksApp::BatchJob()
     wxString bb_title = m_pBatchBuildDialog->GetTitle();
     m_pBatchBuildDialog->SetTitle(bb_title + _T(" - ") + title);
     m_pBatchBuildDialog->Show();
+    m_pBatchBuildDialog->Bind(wxEVT_CLOSE_WINDOW, [=](wxCloseEvent& evt)
+                                                    {
+                                                        m_Frame->Close();
+                                                    });
 
     if (m_ReBuild)
     {
@@ -1000,7 +1011,7 @@ int CodeBlocksApp::BatchJob()
     // The batch build log might have been deleted in
     // CodeBlocksApp::OnBatchBuildDone().
     // If it has not, it's still compiling.
-    if (m_pBatchBuildDialog)
+    /*if (m_pBatchBuildDialog)
     {
         // If operation is "--clean", there is no need to display the dialog
         // as the operation is synchronous and it already has finished by the
@@ -1015,7 +1026,7 @@ int CodeBlocksApp::BatchJob()
             m_pBatchBuildDialog->Destroy();
             m_pBatchBuildDialog = nullptr;
         }
-    }
+    }*/
 
     if (tbIcon)
     {
@@ -1053,13 +1064,16 @@ void CodeBlocksApp::OnBatchBuildDone(CodeBlocksEvent& event)
 
     if (m_pBatchBuildDialog && m_BatchWindowAutoClose)
     {
-        if (m_pBatchBuildDialog->IsModal())
+        /*if (m_pBatchBuildDialog->IsModal())
             m_pBatchBuildDialog->EndModal(wxID_OK);
         else
         {
-            m_pBatchBuildDialog->Destroy();
-            m_pBatchBuildDialog = nullptr;
-        }
+
+
+        }*/
+        m_pBatchBuildDialog->Close();
+        //m_pBatchBuildDialog->Destroy();
+        //m_pBatchBuildDialog = nullptr;
     }
 }
 
diff --git a/src/src/app.h b/src/src/app.h
index 97c69e74e..953916fba 100644
--- a/src/src/app.h
+++ b/src/src/app.h
@@ -142,6 +142,8 @@ class CodeBlocksApp : public wxApp
         void SetupPersonality(const wxString& personality);
         void SetupImageSizes(wxToolBarAddOnXmlHandler *toolbarAddonHandler);
 
+        wxTimer m_startBatchBuild;
+
 
         wxString m_Prefix; // directory specified in --prefix switch
         wxString m_UserDataDir; // directory specified in --user-data-dir switch

still quick patch. I am still testing.... time is limited... and testing is difficult and slow...

[edit:] first problem found: can not cancel building withtout crash
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on August 05, 2019, 11:43:33 pm
This is really a shit situation...

I am close to throw the log manager out from the compiler

1) Is there some way to know when the build is completely finished? Not just project or file, but workspace? (If not, why do we do not have an event for this?)
2) Is there a way to wait until the event queue is completely empty?
3) Is there a way to put an event at the end of the event loop?
Title: Re: Crash with batch build on linux
Post by: sodev on August 06, 2019, 12:18:51 am
1) Is there some way to know when the build is completely finished? Not just project or file, but workspace? (If not, why do we do not have an event for this?)
Not my business 8)

Quote
2) Is there a way to wait until the event queue is completely empty?
Sort of, wxWidgets will create an Idle-Event whenever the main event loop runs empty, however that doesn't mean that there won't be any new events beeing queued. Only way to know that wxWidgets is about to end is when the OnExit() method of the App object is called. This however requires that wxWidgets will be stopped which usually does not happen if there is a wxFrame open.

Quote
3) Is there a way to put an event at the end of the event loop?
You can use QueueEvent() or CallAfter() but this will queue the event at the end of the wxEvtHandler you called these methods on, there may be other event handlers active that will be called later, hence these events are only locally at the end, not globally. Plus i am not sure which of these do work in wx 2.8.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on August 06, 2019, 10:46:43 am
Thank you for the help. So wxWidgets does not supports me in this..
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on August 06, 2019, 07:03:58 pm
Why do you want to do 2 and 3 in the first place?

As far as I know events aren't reordered, so you can put an event in the queue and when it is executed you would know that it is the last one or at least you've reached something like a barrier.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on August 07, 2019, 12:22:05 am
Ok, adding two timers fixes all crashes, but this does not feel right.

Ideas?

Code
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 22a46dfb1..5263e1d2c 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -749,8 +749,15 @@ bool CodeBlocksApp::OnInit()
             s_Loading = false;
             LoadDelayedFiles(frame);
 
-            BatchJob();
-            frame->Close();
+            m_startBatchBuild.Bind(wxEVT_TIMER, [this](wxTimerEvent& evt)
+                {
+                    this->BatchJob();
+                });
+
+            m_startBatchBuild.Start(2000, true);
+
+
+            //frame->Close();
             return true;
         }
 
@@ -974,6 +981,21 @@ int CodeBlocksApp::BatchJob()
     wxString bb_title = m_pBatchBuildDialog->GetTitle();
     m_pBatchBuildDialog->SetTitle(bb_title + _T(" - ") + title);
     m_pBatchBuildDialog->Show();
+    m_pBatchBuildDialog->Bind(wxEVT_CLOSE_WINDOW, [=](wxCloseEvent& evt)
+                                                    {
+                                                        //m_sceduleForClose = true;
+                                                        cbCompilerPlugin *compiler = Manager::Get()->GetPluginManager()->GetFirstCompiler();
+                                                        if(compiler != nullptr && compiler->IsRunning())
+                                                        {
+                                                            evt.Veto();
+                                                            compiler->KillProcess();
+                                                        }
+                                                        else
+                                                        {
+                                                            m_Frame->Close();
+                                                        }
+
+                                                    });
 
     if (m_ReBuild)
     {
@@ -1000,7 +1022,7 @@ int CodeBlocksApp::BatchJob()
     // The batch build log might have been deleted in
     // CodeBlocksApp::OnBatchBuildDone().
     // If it has not, it's still compiling.
-    if (m_pBatchBuildDialog)
+    /*if (m_pBatchBuildDialog)
     {
         // If operation is "--clean", there is no need to display the dialog
         // as the operation is synchronous and it already has finished by the
@@ -1015,7 +1037,7 @@ int CodeBlocksApp::BatchJob()
             m_pBatchBuildDialog->Destroy();
             m_pBatchBuildDialog = nullptr;
         }
-    }
+    }*/
 
     if (tbIcon)
     {
@@ -1053,13 +1075,23 @@ void CodeBlocksApp::OnBatchBuildDone(CodeBlocksEvent& event)
 
     if (m_pBatchBuildDialog && m_BatchWindowAutoClose)
     {
-        if (m_pBatchBuildDialog->IsModal())
+        /*if (m_pBatchBuildDialog->IsModal())
             m_pBatchBuildDialog->EndModal(wxID_OK);
         else
         {
-            m_pBatchBuildDialog->Destroy();
-            m_pBatchBuildDialog = nullptr;
-        }
+
+
+        }*/
+        //m_Frame->Close();
+        m_closeCodeblocks.Bind(wxEVT_TIMER, [=](wxTimerEvent& evt)
+            {
+                m_pBatchBuildDialog->Close();
+            });
+        m_closeCodeblocks.Start(3000, true);
+
+        //m_pBatchBuildDialog->Close();
+        //m_pBatchBuildDialog->Destroy();
+        //m_pBatchBuildDialog = nullptr;
     }
 }
 
diff --git a/src/src/app.h b/src/src/app.h
index 97c69e74e..4aafa9f7e 100644
--- a/src/src/app.h
+++ b/src/src/app.h
@@ -142,6 +142,9 @@ class CodeBlocksApp : public wxApp
         void SetupPersonality(const wxString& personality);
         void SetupImageSizes(wxToolBarAddOnXmlHandler *toolbarAddonHandler);
 
+        wxTimer m_startBatchBuild;
+        wxTimer m_closeCodeblocks;
+
 
         wxString m_Prefix; // directory specified in --prefix switch
         wxString m_UserDataDir; // directory specified in --user-data-dir switch
Title: Re: Crash with batch build on linux
Post by: sodev on August 07, 2019, 01:37:29 am
I'm sure it is not right :).

I examined the code only a little but i spot one big problem there: you are doing operations that create / use events in OnInit(). There is no event loop running in OnInit(). You get around it partly by processing events manually but still this looks like trouble, especially because the event handlers will get executed before OnInit() did finish. Offloading the work with timers actually postones the execution of the code because these will get executed later by the event loop.

A minimal invasive attempt to check if executing the batch job after OnInit() is enough would be to wrap
Code
        if (m_Batch)
        {
            Manager::SetAppStartedUp(true);

            // the compiler plugin might be waiting for this
            CodeBlocksEvent event(cbEVT_APP_STARTUP_DONE);
            Manager::Get()->ProcessEvent(event);

            Manager::Get()->RegisterEventSink(cbEVT_COMPILER_FINISHED, new cbEventFunctor<CodeBlocksApp, CodeBlocksEvent>(this, &CodeBlocksApp::OnBatchBuildDone));
            s_Loading = false;
            LoadDelayedFiles(frame);

            BatchJob();
            frame->Close();
            return true;
        }

into

Code
        if (m_Batch)
        {
            CallAfter([this, frame]() {
                Manager::SetAppStartedUp(true);

                // the compiler plugin might be waiting for this
                CodeBlocksEvent event(cbEVT_APP_STARTUP_DONE);
                Manager::Get()->ProcessEvent(event);

                Manager::Get()->RegisterEventSink(cbEVT_COMPILER_FINISHED, new cbEventFunctor<CodeBlocksApp, CodeBlocksEvent>(this, &CodeBlocksApp::OnBatchBuildDone));
                s_Loading = false;
                LoadDelayedFiles(frame);

                BatchJob();
                frame->Close();
            });
            return true;
        }

However i still see the problem that you have not set a top window and this might exit wxWidgets too early. And no, i didn't even compile this, all your compiler error are belong to you :D.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on August 07, 2019, 11:45:58 am
Quote
I examined the code only a little but i spot one big problem there: you are doing operations that create / use events in OnInit(). There is no event loop running in OnInit(). You get around it partly by processing events manually but still this looks like trouble, especially because the event handlers will get executed before OnInit() did finish. Offloading the work with timers actually postones the execution of the code because these will get executed later by the event loop.
So what would be the wxWidgets way to do this?
As far as i understand: in the OnInit the Window for the application is initialized and after the OnInit the event handler of the main window takes over. If i go this approach the Batch Job should be started in the Batch build window. But we do not want this: we want to separate logic from UI as far as possible, the BatchWindow should only display log messages and give the user a possibility to stop the process but not handle the build process. This should happen in the "main" thread also without any GUI componentes running, only the wxWidgets basics (like an event loop) . With the Timer i was thinking to move the start of the Batch build to outside of OnInit to the event loop of the main thread. According to your post (as far as i understand) this does not work, because in OnInit there is no event loop and with creating the timer  i create an artificially (???) event handler only for this in the OnInit function?. Isn't there an event loop of the "main thread" outside of the GUI?
Since we remove wx28 support CallAfter is a nice alternative (and i really like it over the timer), but isn't this technically the same as the timer events? It queues the execution to the end of an event loop.

Thank you for adding your wxWidgets knowledge here! This goes way beyond my wxWidgets knowledge.
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on August 07, 2019, 11:33:31 pm
@BlueHazzard: Please read more about events and how to handle them correctly in wx. Most of the problems in C::B related to events are because people (including me) had no good understanding what is going on. Read about idle events. I think this is all that is needed. And please don't run everything from lambda's.

And no timers aren't creating fake events they are real events which happen after oninit ends. Same as the idle event.
Title: Re: Crash with batch build on linux
Post by: sodev on August 08, 2019, 10:08:05 pm
@BlueHazzard: Your understanding is not quite correct, but the effects of CallAfter() and the timers are technically the same, they move the processing time of the code fragments out of OnInit() into OnRun(). I am a bad teacher but i try to give a short overview of what is happening.

After OnInit() did finish the thread that does execute OnRun() becomes the main thread. This main thread just drives the main event loop which is processing the events. This is done roughly speaking by passing each event through the event handler chain until it is processed. In wxWidgets pretty much every GUI element is an event handler and these form a vertical chain. Most simple case is a button inside a frame:

wxButton -> wxFrame -> wxTheApp

So if the button gets clicked the event loop first calls the event handler of the button, if that doesn't process the event it is passed to the frame and if that also doesn't process it, it is passed to the global app object (this is very simplified, check the wxWidgets docs for details).

In your OnInit() method the CallAfter() and the timers actually queue the event in the App object and nothing more happens there. Only when OnRun() starts executing they will be actually executed. On the other hand in OnInit() your Manager object manually processes the startup event. This itself might be an issue but what is even more problematic is that im pretty sure that your own event handling system uses wxWidgets events and processes them horizontally.

This means in contrast to wxWidgets where event processing ends when the event got consumed you pass the event to all other registered sinks as well. This usually is not a problem unless one of the sinks opens a modal dialog (or anything else that causes the creation of another event loop). Because control flow has to stop for the modal dialog, another event loop gets created which is again driven by the main thread. This ensures that event processing does not stop. In horizontal processing this has however the side effect that after that modal dialog got closed, the originating event that opened it gets passed along to the next event sinks. So this "old" event gets further processed after all the events that it might have created.

I hope this wall of text doesn't confuse you even more but maybe gives you some ideas what can cause the present problems.


@oBFusCATed: I don't think idle events are the way to go, they happen all the time and are not suited for one time tasks. These lambdas are nice to write code in one place and let it execute in another place, like work units for a work queue. But i also like auto so im afraid we won't agree here as well  ::) ;D
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on August 08, 2019, 11:10:32 pm
@oBFusCATed: I don't think idle events are the way to go, they happen all the time and are not suited for one time tasks. These lambdas are nice to write code in one place and let it execute in another place, like work units for a work queue. But i also like auto so im afraid we won't agree here as well  ::) ;D
I know people like to run their whole applications from inside a lamdba, but this doesn't make it a good idea. Same as the almost-always-auto crap. I've seen it in the wild and it is not fun when something breaks. 8)
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on August 14, 2019, 12:16:02 am
Ok, here is a cleaned up patch.
I think the limited use of lambda is ok in this context. I do not think that using the idle event is the right place. I think CallAfter is exactly the right way to do this.
i tested it on linux and windows. More testing is still needed.

This breaks compiling for wx2.8, but we wanted to remove it anyway :)

Have we a plan for removing wx2.8? Just removing projects and removing conditional code as can be found, or heavy code cleanup the next 6 months?
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on August 14, 2019, 08:08:18 am
I'd just remove projects first. Then after a while I'll do a full cleanup of conditional code.
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on August 14, 2019, 08:12:40 am
Formatting of lambda's should be either:

Code
CallAfter([=]() {

});

or
Code
CallAfter([=]()
{

});

I don't think what you're doing is a good idea. And please don't use the all-things capture modes. Capture specific variables. And please triple check pointer/reference captures would be 100% alive/valid at the time of the execution of the lambda.

You patch has zero comments explaining why you have to use these CallAfters. This is really unacceptable!

p.s. Also limit long lines to 100 or 120 chars.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on August 14, 2019, 09:35:22 am
Quote
I don't think what you're doing is a good idea
Why not? The problem is we start the build process in the OnInit() method, and stop it in a codeblocks event method. In both cases the Output windows is destroyed before all window work is done.
With call after we move the heavy work functions to outside the OnInit and other Event method, when all work is done and the windows are ready to be updated or destroyed. This function only are called once: We start the build process only one time. No need to put this in the Idle event, that is called repeatedly, and we would need to introduce a complex state machine to check if this is the first call ecc... The same for closing the window. We can not close the windows in the build finished event, because the compiler plugin will use the output window after the event. But if we queue it in the event loop of wxWidgets it will get called after all other functions are finished. The right place to destroy the window....
If you have a better idea, you are welcome to provide it. I have read the event handling on wxWidgets and i do not see a counter point to this approach...

Quote
You patch has zero comments explaining why you have to use these CallAfters. This is really unacceptable!
Code
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 22a46dfb1..b6cc11fd3 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -749,8 +749,12 @@ bool CodeBlocksApp::OnInit()
             s_Loading = false;
             LoadDelayedFiles(frame);
 
-            BatchJob();
-            frame->Close();
+            // Start the batch build after finishing the init process
+            CallAfter([this]()
+                {
+                    this->BatchJob();
+                });
+
             return true;
         }

The other comments are noted and will be added
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on August 14, 2019, 07:12:55 pm
Quote
I don't think what you're doing is a good idea
Why not?
I'm talking strictly about formatting here.

// Start the batch build after finishing the init process
Sorry, but this is useless comment. It is the same as commenting that you are setting a variable to some value. Good comments answer the why question and not the what question. (sometimes there is a need for a comment answering the what question, but this is not one of them).
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 09, 2019, 11:59:52 pm
Ok here is a other version of this patch with hopefully improved formatting and comments.

I test this patch currently extensively on my build environment (windows and unix). If a can not find any bigger breaks, we should consider to merge this into trunk, and for this we have to decide who removes the wx28 projects....
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on September 10, 2019, 06:47:42 am
Why have you changed the process stuff?
For now it is best to make this only compile if building against wx3.x.
We'll remove them when we remove wx2.8 support.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 10, 2019, 08:15:04 am
Quote
Why have you changed the process stuff?
Because i have an automated build system for linux and windows that builds itself and then builds codeblocks automatically. I can not test one patch without the other, because if the process stuff is missing, the build will stall on windows, and if the CallAfter part is missing the build will crash on linux.

Code
For now it is best to make this only compile if building against wx3.x.
Ok i will wrap it in #ifdefs
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on September 10, 2019, 06:17:02 pm
Please separate them in two patches/commits.
The process stuff is really fragile, and when I say this I mean it. There is no way to test everything affected by this. :(

Also the flag parameter of the Launch method seems to be ignored. Aren't you getting unused variable warnings for this? Is there a reason to pass it at all? Comments why you need this?
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 12, 2019, 10:33:01 pm
First part. Fix crash on linux
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on September 13, 2019, 08:20:07 am
Why are you showing a message box in OnCloseBatchBuildWindow? It should be possible to run batch build on a headless machine where there is no operator. For example running in on appvoyer.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 13, 2019, 09:33:29 pm
Why are you showing a message box in OnCloseBatchBuildWindow? It should be possible to run batch build on a headless machine where there is no operator. For example running in on appvoyer.
We had this discussion on top (or at SF):
One step at the time
1) we fix that it can be used (because right now it simply crashes (on linux) and stalls (on windows). So it can't be used with or without dialog....
2) we remove all UI code from this part

at the moment we are at 1) . If the build runs (on linux and windows) we can move to step 2)

Is this patch ok for you?
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 14, 2019, 12:28:29 am
Here is the windows part. Thank you for showing me the error of the flags. I tried also to add some documentation and why we use this timer function...
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on September 14, 2019, 01:28:08 am
Is this patch ok for you?
Fine...
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on September 14, 2019, 01:28:53 am
Here is the windows part. Thank you for showing me the error of the flags. I tried also to add some documentation and why we use this timer function...
Does this polling work fine on linux? Does it add overhead? I don't like default values for parameters.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 19, 2019, 11:08:29 am
Sry i expressed me wrong... The "poll" is only sending an idle event. And this also only every second (I think we could increase the time even more. But then in the worst case the stall on windows would last for this long). I build codeblocks with this patch several times and never had any problems or slowdowns on my build server.
Title: Re: Crash with batch build on linux
Post by: BlueHazzard on September 26, 2019, 08:26:45 am
There are other parts of the code that slow down the build process unnecessary A LOT (i am looking at you CompilerCommandGenerator )...
What is wrong about the default parameter? In general or the selected values?
Title: Re: Crash with batch build on linux
Post by: oBFusCATed on September 26, 2019, 08:42:07 am
In general.