Bug #2304
build-generator blocks with 100% cpu usage
Status: | Resolved | Start date: | 05/26/2015 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | J. Moringen | % Done: | 100% | |
Category: | Deployment | |||
Target version: | 0.5 |
Description
Versions:
$ build-generator --version build-generator version 0.4.76 jenkins.tar.gz was the latest version downloaded on the 03.02.15 from the toolkit website
Call:
build-generator --delete-other --on-error=continue -d distributions/lsp-csra-nightly.distribution -t templates/toolkit/*.template -u USER -p PASSWORD -D ros=indigo -j 1 --debugIssue:
- the build-generator creates the attached output and then runs forever with 100% cpu usage
- things have been working two weeks ago
- the build-gen and the Jenkins version were not changed
- command is run on the same machine as the Jenkins (host 'hcc'), after sshing there
- I changed my ssh key and am now using a passphrase for my key (there is no prompt on the console when running the command)
- dependencies were added to some project files (however trying an old distribution version leads to the same issue)
Associated revisions
Proper topological sort in src/model/util.lisp
fixes #2304
- src/model/util.lisp (cycle-error): new condition; signaled when a
cycle is detected
(node): new structure; used in topological sorting implementation
(topological-sort): new function; perform topological sort of given
graph nodes
(sort-with-partial-order): use `topological-sort'
History
#1 Updated by J. Moringen about 9 years ago
This may be an inefficiency I accidently introduced into the master version.
#2 Updated by N. Köster about 9 years ago
so, letting it run 'long enough' would work? (btw. issue also arises when setting "-j 8" and no "--debug")
#3 Updated by J. Moringen about 9 years ago
N. Köster wrote:
so, letting it run 'long enough' would work?
If the problem is what I think it is, yes.
(btw. issue also arises when setting "-j 8" and no "--debug")
Expected since the critical part is not parallelized, if I remember correctly.
#4 Updated by N. Köster about 9 years ago
J. Moringen wrote:
N. Köster wrote:
so, letting it run 'long enough' would work?
Currently at 42h+ and still running. I was hoping it would be something like 2h at most :/
If the problem is what I think it is, yes.
Can we do something to avoid this issue? I am confused as it was not present before ...
#5 Updated by J. Moringen about 9 years ago
N. Köster wrote:
J. Moringen wrote:
N. Köster wrote:
so, letting it run 'long enough' would work?
Currently at 42h+ and still running. I was hoping it would be something like 2h at most :/
Probably not what I thought, then.
If the problem is what I think it is, yes.
Can we do something to avoid this issue? I am confused as it was not present before ...
I have no idea what the problem could be either. Will probably need tracing and/or debugging.
#6 Updated by J. Moringen about 9 years ago
Was caused by dependency cycle. Still, generator should give better error message. Will be solved by implementing proper topological sort.
#7 Updated by J. Moringen about 9 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
J. Moringen wrote:
Was caused by dependency cycle. Still, generator should give better error message. Will be solved by implementing proper topological sort.
I implemented this. Will push some time later.
#8 Updated by J. Moringen about 9 years ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Applied in changeset 1c65631386925d72f94789f2f3f539252e84ab4a.
#9 Updated by J. Moringen about 9 years ago
J. Moringen wrote:
Applied in changeset 1c65631386925d72f94789f2f3f539252e84ab4a.
Doesn't build though. Probably Jenkins or code.cor-lab problem.