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":
(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?)
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.