Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Batch build problems (hangs/stalls if log window is not active)
simons:
Hi all,
I am trying to use the batch build feature of Codeblocks to have my projects built automatically on a Jenkins CI server. This may be related to some earlier discussions:
- http://forums.codeblocks.org/index.php/topic,21838.msg148541.html#msg148541 (Linux and assumingly outdated solution "special build by Jens")
- http://forums.codeblocks.org/index.php/topic,14928.0.html (Linux solution: export DISPLAY=:2000.0)
- http://forums.codeblocks.org/index.php?topic=15662.0 (codeblocks_console branch, found it on github, assumingly outdated, could not get it to compile)
The problem that I get is on MS Windows 7 and with projects that produce *a lot* of compiler output (template-heavy code). Here is what happens:
- Running codeblocks with a command like this: codeblocks.exe <PATH_TO_WORKSPACE> --rebuild --no-check-associations --no-dde --no-splash-screen --no-batch-window-close --target=<TARGET>
- The batch build window opens and the build starts (I can see compiler output in the log window and cl.exe or mingw-gcc.exe shows up in the task manager's process list consuming cpu time and memory)
- After a while of not activating the batch log window, the build stalls, there is no more compiler output being appended and the compiler executables cpu usage goes down to zero
- Only if I hover over or click on the batch log window, the build continues, I can see new compiler output and cpu time being consumed
- Leaving the batch log window minimized or just not focused, the build stalls again
I already tried a couple of things:
- I looked into the Codeblocks code trying to find an easy way to "deactivate" the batch log window.. my current conclusion is that there is none ;)
- I managed to implement a hack that disables printing all the compiler output into the log window (remember the problem seems to only occur with projects that produce *much* output). The window is empty now, but the problem persists
- I tried to get a backtrace using gdb, which I don't know very well so I'm not sure if I did it right. After starting up gdb with codeblocks.exe as the debugee and waiting for the build to stall, I had to use a little helper application (http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt) to interrupt the process and to be able to get a backtrace
Here is the result of "(gdb) thread apply all bt":
--- Code: ---(gdb) thread apply all bt
Thread 146 (Thread 6524.0x1b84):
#0 0x77d5000d in ntdll!DbgBreakPoint () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77ddf306 in ntdll!DbgUiRemoteBreakin () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x3e10b887 in ?? ()
#3 0x00000000 in ?? ()
Thread 145 (Thread 6524.0x1ac4):
#0 0x77d61f76 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77d61f76 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x77d8fa8e in ntdll!TpSetTimer () from C:\WINDOWS\SysWOW64\ntdll.dll
#3 0x7780343d in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\syswow64\kernel32.dll
#4 0x77d79832 in ntdll!RtlInitializeExceptionChain () from C:\WINDOWS\SysWOW64\ntdll.dll
#5 0x77d79805 in ntdll!RtlInitializeExceptionChain () from C:\WINDOWS\SysWOW64\ntdll.dll
#6 0x00000000 in ?? ()
Thread 143 (Thread 6524.0x1cec):
#0 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x76ed15ce in WaitForSingleObjectEx () from C:\WINDOWS\syswow64\KernelBase.dll
#3 0x000001b0 in ?? ()
#4 0x00000000 in ?? ()
Thread 51 (Thread 6524.0x22b0):
---Type <return> to continue, or q <return> to quit---
#0 0x77d61f76 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77d61f76 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x77d8fa8e in ntdll!TpSetTimer () from C:\WINDOWS\SysWOW64\ntdll.dll
#3 0x7780343d in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\syswow64\kernel32.dll
#4 0x77d79832 in ntdll!RtlInitializeExceptionChain () from C:\WINDOWS\SysWOW64\ntdll.dll
#5 0x77d79805 in ntdll!RtlInitializeExceptionChain () from C:\WINDOWS\SysWOW64\ntdll.dll
#6 0x00000000 in ?? ()
Thread 47 (Thread 6524.0x9c4):
#0 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x76ed15ce in WaitForSingleObjectEx () from C:\WINDOWS\syswow64\KernelBase.dll
#3 0x00000290 in ?? ()
#4 0x00000000 in ?? ()
Thread 46 (Thread 6524.0x17f0):
#0 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x76ed15ce in WaitForSingleObjectEx () from C:\WINDOWS\syswow64\KernelBase.dll
#3 0x0000032c in ?? ()
#4 0x00000000 in ?? ()
Thread 45 (Thread 6524.0x86c):
#0 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
---Type <return> to continue, or q <return> to quit---
#1 0x77d5f901 in ntdll!ZwWaitForSingleObject () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x76ed15ce in WaitForSingleObjectEx () from C:\WINDOWS\syswow64\KernelBase.dll
#3 0x000001e8 in ?? ()
#4 0x00000000 in ?? ()
Thread 2 (Thread 6524.0x1670):
#0 0x77d6018d in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SysWOW64\ntdll.dll
#1 0x77d6018d in ntdll!ZwWaitForMultipleObjects () from C:\WINDOWS\SysWOW64\ntdll.dll
#2 0x77d8f69f in ntdll!_allmul () from C:\WINDOWS\SysWOW64\ntdll.dll
#3 0x00000003 in ?? ()
#4 0x014ecf50 in ?? ()
#5 0x7780343d in KERNEL32!BaseThreadInitThunk () from C:\WINDOWS\syswow64\kernel32.dll
#6 0x77d79832 in ntdll!RtlInitializeExceptionChain () from C:\WINDOWS\SysWOW64\ntdll.dll
#7 0x77d79805 in ntdll!RtlInitializeExceptionChain () from C:\WINDOWS\SysWOW64\ntdll.dll
#8 0x00000000 in ?? ()
Thread 1 (Thread 6524.0x10f8):
#0 0x767578d7 in USER32!DispatchMessageW () from C:\WINDOWS\syswow64\user32.dll
#1 0x627df5cc in wxEventLoop::Dispatch() ()
from D:\Users\scho_so\Dev\codeblocks-17.12-BatchFix\src\devel\wxmsw28u_gcc_custom.dll
#2 0x628b1798 in wxEventLoopManual::Run() ()
from D:\Users\scho_so\Dev\codeblocks-17.12-BatchFix\src\devel\wxmsw28u_gcc_custom.dll
#3 0x0a9a9448 in ?? ()
#4 0x8775d038 in ?? ()
---Type <return> to continue, or q <return> to quit---
#5 0x3128c483 in ?? ()
#6 0x04c25bc0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
--- End code ---
Does anyone have ideas about ...
... where the problem with a stalling build log window could originate from (e.g. wxWidgets modal windows / event loops etc.) ?
... how to further identify the problem, e.g. using some more advanced debugging techniques?
... things to try in order to find a work-around (e.g. some 'hackish' solution until someone can get a grip of the actual problem) ?
Help is much appreciated here and I would be more than willing to try out possible solutions or debugging techniques. Unfortunately, I haven't been able to reproduce the problem in a sort of "minimal example" that I could share, since it only comes up with certain projects that produce a lot of template-tracing compiler outputs. That's also the reason, I haven't issued a bug report...
Thanks everyone.
Miguel Gimenez:
May be related to this?
https://stackoverflow.com/questions/4453692/windows-console-application-getting-stuck-needs-key-press
oBFusCATed:
simons: Can you try to disable the option in the cmd.exe's settings? If it works we'll add it to the code, so it is automatic.
simons:
Thanks for the quick response.
I did not have the "quick edit mode" enabled in my command prompt. Anyway, I tried to enable/disable it without any changes to the symptoms.
Just to clarify: It's the Codeblocks batch build log window (a little wxWidgets modal dialog, as far as I read from the sources) that stalls and doesn't show any more compiler output. It's *not* the command prompt. Actually Codeblocks - even in batch mode - seems to completely detach from the command prompt such that I can close the command prompt window and just have the Codeblocks batch build log window open. It is this window that seems to stall the compile process when not focused for a while. Any GUI event, even hovering over the window with the mouse or dragging another window over it, will continue the build process. As soon as I put my hands off the mouse and the window does not have focus, it stalls again.
Any more ideas?
oBFusCATed:
It could be the idle handler we're probably using.
Can you reproduce it with an open source project?
Navigation
[0] Message Index
[#] Next page
Go to full version