User forums > Help

Codeblocks does not continue build after a command line start.

(1/2) > >>

Henk:
The codeblocks workspace build is started and running as pid 15477, but does not finish. (started with option --no-splash-screen and --target=LinuxDebug)
After a "strace -p 15477" this is the output:
   Process 15477 attached - interrupt to quit
   futex(0xb699b3c0, FUTEX_WAIT_PRIVATE, 2, NULL

There is no output in the codeblock logfile or on the stderr.
This problem will not occur every time, just about every 50 builds
Codeblocks revision information: Release 10.05 rev 6282 (2010-05-27 09:09:13) gcc 4.3.2 Linux/unicode - 32 bit, installed on Ubuntu 10.04 LTS

There is no clear indication to me, what happened to trigger this problem (no codeblocks updates or anything)
There are enough free resources on the machine. I was not able to locate the codeblocks.rpt file.

What could I do next to find the cause?

oBFusCATed:

--- Quote from: Henk on June 29, 2011, 10:33:55 am ---What could I do next to find the cause?

--- End quote ---
Try to explain you problem better, because I'm not sure what you do and what is the real problem.

Henk:
The build is started automatically from a Continuous Integration System (Jenkins)
Sometimes it just stops for the reason as described. (As far as I understand it is waiting for a lock/futex forever)
After this occurs the system hangs and manual intervention is required to start the Continuous Integration System again.

I am not able to find any information where the cause is. Just that codeblocks "stops building/appears to hang" right after starting a command line build.
The build is started with the command:
codeblocks --no-splash-screen --clean ./projects.workspace --target=LinuxDebug

oBFusCATed:
You can:
1. Try a newer build (search for the Jens repos)
2. Try to install debug symbols and then attach with a debugger to see where it has been locked.

killerbot:
note, it could be that it doesn't start at all. Does it give an error about the wx libs. I remember on another linux this fails since the jenkins daemon had no rights to the X environment. But I think it gives an error message. We have a special branch, targeted to fix this headless issues. Currenlty Jens is the one developing on this branch.

Navigation

[0] Message Index

[#] Next page