Codeblocks does not continue build after a command line start.

[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]

What could I do next to find the cause?

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.

[Henk]

@killerbot
There is a workaround connecting Codeblocks to a display when build from Jenkins. This workaround is in place, so this is (likely) not the cause if this problem. (Would be great to have a headless codeblocks, I could get rid of the workaround).
@oBFusCATed
I am not sure what you meant, is it installing debug symbols for Codeblocks, and then debug Codeblocks?

[oBFusCATed]

Yes, this is what I meant

[killerbot]

could you tell me your workaround ?

[Henk]

Sure, workaround for having a display for Jenkins, is exporting a display before codeblocks is started. This is done with:
#!/bin/sh
export DISPLAY=:2000.0

You will need to have display 2000.
In this case Jenkins runs on a machine without any display.
Before a Jenkins build is started, I login with nomachine. (Otherwise the build will fail)
You will see Codeblocks pop-ups when jenkins starts a build.

[Henk]

Just want to report.
The system is running fine now for quite some months.
But using the machine with NoMachine while Codeblocks builds are started through Jenkins, gives this problem.
Since this is a build machine, solution is simple