Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Batch build problems (hangs/stalls if log window is not active)
Miguel Gimenez:
Checking this issue I found another problem. After the reuild is finished, I close the window and a SIGSEGV is received:
--- Code: ---Thread 1 received signal SIGSEGV, Segmentation fault.
0x0046db13 in InfoPane::Show (this=0x8861a68, logger=0xbd81cd8) at G:\Codeblocks\src\src\infopane.cpp:253
253 if (m_Pages.Item(i)->logger == logger)
(gdb) bt
#0 0x0046db13 in InfoPane::Show (this=0x8861a68, logger=0xbd81cd8) at G:\Codeblocks\src\src\infopane.cpp:253
#1 0x00496b96 in MainFrame::OnSwitchToLogWindow (this=0x87a6670, event=...) at G:\Codeblocks\src\src\main.cpp:5036
#2 0x00513a3c in cbEventFunctor<MainFrame, CodeBlocksLogEvent>::Call (this=0x8845038, event=...)
at G:/Codeblocks/src/include/cbfunctor.h:49
#3 0x01fe7833 in Manager::ProcessEvent (this=0x7ea7310, event=...) at G:\Codeblocks\src\sdk\manager.cpp:328
#4 0x6a157d8b in CompilerGCC::ClearLog (this=0x88f3878) at G:\Codeblocks\src\plugins\compilergcc\compilergcc.cpp:1061
#5 0x6a16ab0b in CompilerGCC::OnWorkspaceClosed (this=0x88f3878, event=...)
at G:\Codeblocks\src\plugins\compilergcc\compilergcc.cpp:3405
#6 0x6a1d5b3c in cbEventFunctor<CompilerGCC, CodeBlocksEvent>::Call (this=0xa10f358, event=...)
at G:/Codeblocks/src/include/cbfunctor.h:49
#7 0x01fe7581 in Manager::ProcessEvent (this=0x7ea7310, event=...) at G:\Codeblocks\src\sdk\manager.cpp:260
#8 0x02002507 in PluginManager::NotifyPlugins (this=0x88e16e0, event=...) at G:\Codeblocks\src\sdk\pluginmanager.cpp:1522
#9 0x020297ac in ProjectManager::CloseWorkspace (this=0x885ede8) at G:\Codeblocks\src\sdk\projectmanager.cpp:613
#10 0x0047fd78 in MainFrame::DoCloseCurrentWorkspace (this=0x87a6670) at G:\Codeblocks\src\src\main.cpp:1877
#11 0x0048945b in MainFrame::OnApplicationClose (this=0x87a6670, event=...) at G:\Codeblocks\src\src\main.cpp:2758
#12 0x644433d2 in wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const ()
from C:\Windows\system32\wxmsw311u_gcc_custom.dll
#13 0x0028f5f0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) print i
$1 = 0
(gdb) print m_Pages
$2 = {<wxBaseArrayPtrVoid> = {m_nSize = 4277075694, m_nCount = 4277075694, m_pItems = 0xfeeefeee}, <No data fields>}
--- End code ---
I think m_Pages has not been initialized at this point. 4277075694 = 0xfeeefeee.
EDIT: the attached patch fixes this, I'll create a ticket.
simons:
I managed to assemble a "somewhat minimal" example using boost::msm (template-heavy code) that reproduces the problem when compiling with visual studio 2005 (msvc8) or visual studio 2010 (msvc10).
It seems like there are a couple conditions that raise the probability of the problem: many compiler warnings and errors, multiple compiler processes, a decent cpu load on the compiler. I also played around with some code snippets from https://codegolf.stackexchange.com/questions/5802/write-the-shortest-program-that-generates-the-most-compiler-warnings-and-errors and while I managed to totally hog the Codeblocks application with some of these "compiler bombs", I could not reproduce my original problem. Also, bare in mind that I have seen the issue with only a single compiler process as well.
I uploaded the "not-so-minimal" example here: https://github.com/simfinite/test_codeblocks_batch_build
Please, follow the steps in the README to reproduce the problem (and sorry for making you download the boost sources... ;))
oBFusCATed:
Can you reproduce this with mingw? The older versions of Visual studio aren't made to run in parallel.
BlueHazzard:
I can reproduce this on my machine with windows7 mingw-tdm-5 and the example project... Funny...
For me it always stops at linking stage. I am the only one?
I can not reproduce the SIGSEGV from Miguel Gimenez
There really should be a codeblocks console builder... It is nearly a shame that this does not exists..
simons:
--- Quote ---I can reproduce this on my machine with windows7 mingw-tdm-5
--- End quote ---
Interesting, I could not reproduce it with gcc on my machine yesterday. But I added a little warning generator to the example code and now I can reproduce the problem with
- msvc8
- msvc10
- TDM gcc 5.1.0
- MinGW-W64 gcc 5.4.0
(all with 4 build jobs)
The problem is still most easily reproduced with the old and weak visual studio compilers and hardest with gcc 5.4.0. It may take some tweaking of the amount of warnings generated (see fsm.hpp, line #206) or the number of build jobs. Although this sounds like an undeterministic problem, I could reproduce it *every time* once I found a configuration that works.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version