Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Batch build problems (hangs/stalls if log window is not active)

<< < (3/7) > >>

BlueHazzard:
i would like to add, that i have enabled -wall and -wpedantic to generate even more messages

oBFusCATed:
Can you write a simple app that just spits output which looks like warnings generated by GCC and set this as the compiler executable?

BlueHazzard:

--- Quote from: oBFusCATed on September 20, 2018, 06:02:12 pm ---Can you write a simple app that just spits output which looks like warnings generated by GCC and set this as the compiler executable?

--- End quote ---
tried it right now with > 10000 warnings and i am not able to trigger this. The output count should be a lot more then from the working project. At least it needs a lot more time to ouput.. There has to be something else contributing to this...

simons:

--- Quote ---tried it right now with > 10000 warnings and i am not able to trigger this
--- End quote ---
Yes, my observation is that the problem occurs only for the combination of many warnings being produced *and* heavy CPU load from the compiler processes. That's the reason I included boost::msm into the example application, because the simple warning generator wasn't enough and compiling the template-heavy library code consumes a lot of CPU time. The sample application pretty much reproduces the setting that I have in the projects where I originally observed the problem.


--- Quote ---Can you write a simple app that just spits output which looks like warnings generated by GCC and set this as the compiler executable?
--- End quote ---
Yes, I wrote a little "fake_gcc" and put it into the same repository. I was able to reproduce the problem with it, however, some tweaking may still be required. There are some variables inside the main.cpp that configure how the program behaves. They are set to what worked on my machine. If you are having trouble reproducing the problem, try to increase/decrease "work_us" to increase/decrease CPU time consumption and check that the processes are in fact consuming considerable CPU time (e.g. 15-25% each with 4 build jobs on a quad core).

One thing I noticed using the "fake_gcc": The problem seems to only arise when compiler processes start up and/or quit. For example, I could not reproduce the problem just letting fake_gcc run forever. The project being built also needs to have many compilation units, such that new compiler processes are started up every now and then.

simons:
I did some more experiments and have some minor insights to share:

- As I mentioned before, up until now I could only reproduce the problem if the compiler process is consuming considerable CPU time. I verified that the problem cannot be reproduced by hogging the CPU with some other processes and letting the compiler process output warnings only.

- However, now I found a configuration for the "fake_gcc"  that reproduces the problem without the busy loop, i.e. without consuming CPU time and by but just letting the compiler process sleep for a while each iteration. It's a bit harder to reproduce than the variant with the busy loop and only works with 4 build jobs on my machine. Still this decouples the problem from CPU usage and is pointing more towards a general timing issue.

Has anyone been able to reproduce the problem using the "fake_gcc"? I pushed the new configuration to the repo. Any ideas on how to move on from here?

Navigation

[0] Message Index

[#] Next page

[*] Previous page