Bug #2304

build-generator blocks with 100% cpu usage

Added by N. Köster about 9 years ago. Updated about 9 years ago.

Status:ResolvedStart date:05/26/2015
Priority:NormalDue 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 --debug

Issue:
  • the build-generator creates the attached output and then runs forever with 100% cpu usage
Remarks:
  • 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)

build_gen_log.log (23.7 MB) N. Köster, 05/26/2015 06:20 PM

Associated revisions

Revision 1c656313
Added by J. Moringen about 9 years ago

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

#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.

Also available in: Atom PDF