(0032299)
Jean-Christophe Fillion-Robin (reporter)
2013-02-15 15:31

Hi Greg,

Could you provide more details leading to the infinite loop ? From the description, it seems the loop happen at configuration time but your talk about build time loop : "cmake goes into an infinite loop when compiling using "make""

(0032300)
Bill Hoffman (manager)
2013-02-15 16:21

You could also run cmake --trace, it might give a clue as to where it is stuck. Also, you can run dtruss on the cmake process and see what it is doing. We need more information to help.

(0032301)
Christopher Mullins (reporter)
2013-02-15 19:19

Here is another related issue.

http://www.cmake.org/Bug/view.php?id=13927 [^]

(0032304)
Greg Sharp (reporter)
2013-02-15 21:34

Hi, in the Slicer build, make launches cmake to configure slicer main executable. It is this child process which is infinite loop. I didn't have time yet to figure out how to pass the --trace flag into the child process. Maybe if I reconfigure the original cmake (which creates the Makefile) with this flag?

But I could do the dtrace thing. The output is attached. CMake sub-process has been running for 40 mins, so I guess it is in steady state.

I hope to make more complete description of how to reproduce soon.

(0032319)
Jean-Christophe Fillion-Robin (reporter)
2013-02-17 11:43
edited on: 2013-02-17 11:44

@Greg: I did some experiment and CMake version "2.8.10.20130121-g92bd8" is known to work. See http://slicer-devel.65872.n3.nabble.com/How-to-build-Slicer-on-10-8-tp4027602p4027604.html [^]

On the other hand, I was able to reproduce the hang using version "cmake-2.8.10.20130215-g4c900".

I suspect it be caused by commit [1] recently introduced and discussed in 0013756 [2] and 0013901 [3]

[1] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccfeefae [^]
[2] http://www.cmake.org/Bug/view.php?id=13756 [^]
[3] http://www.cmake.org/Bug/view.php?id=13901#c32239 [^]

(0032323)
Brad King (manager)
2013-02-18 08:28

Re 0013926:0032319: Is Slicer trying to change the compiler of an existing build tree? All the issues/changes in your summary affect that.

(0032324)
Brad King (manager)
2013-02-18 08:53

Re 0013926:0032323, 0013926:0032319: The loop is also caused by "-DCMAKE_C_COMPILER=cc" in an already-configured tree where CMake has expanded "cc" to a full path already.

(0032334)
Jean-Christophe Fillion-Robin (reporter)
2013-02-18 11:43

Thanks for the hint. We are indeed passing CMAKE_{C, CXX}_COMPILER to both Slicer inner build and also all the other external projects to ensure that the compiler used by the developer is the one that will be used everywhere.

That said, I think this happen while "ExternalProject" module initially configuring each tree, it is still not clear to me why this is causing trouble.

[1] https://github.com/Slicer/Slicer/blob/master/SuperBuild.cmake#L369 [^]
[2] https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_CTK.cmake#L75 [^]

(0032355)
Brad King (manager)
2013-02-20 08:14

I think the fix to 0013756 mentioned in 0013756:0032354 may resolve this issue too. Please re-open if not.

(0033432)
Robert Maynard (manager)
2013-07-01 09:38

Closing resolved issues that have not been updated in more than 4 months.

Notes
(0032299) Jean-Christophe Fillion-Robin (reporter) 2013-02-15 15:31	Hi Greg, Could you provide more details leading to the infinite loop ? From the description, it seems the loop happen at configuration time but your talk about build time loop : "cmake goes into an infinite loop when compiling using "make""

(0032300) Bill Hoffman (manager) 2013-02-15 16:21	You could also run cmake --trace, it might give a clue as to where it is stuck. Also, you can run dtruss on the cmake process and see what it is doing. We need more information to help.

(0032301) Christopher Mullins (reporter) 2013-02-15 19:19	Here is another related issue. http://www.cmake.org/Bug/view.php?id=13927 [^]

(0032304) Greg Sharp (reporter) 2013-02-15 21:34	Hi, in the Slicer build, make launches cmake to configure slicer main executable. It is this child process which is infinite loop. I didn't have time yet to figure out how to pass the --trace flag into the child process. Maybe if I reconfigure the original cmake (which creates the Makefile) with this flag? But I could do the dtrace thing. The output is attached. CMake sub-process has been running for 40 mins, so I guess it is in steady state. I hope to make more complete description of how to reproduce soon.

(0032319) Jean-Christophe Fillion-Robin (reporter) 2013-02-17 11:43 edited on: 2013-02-17 11:44	@Greg: I did some experiment and CMake version "2.8.10.20130121-g92bd8" is known to work. See http://slicer-devel.65872.n3.nabble.com/How-to-build-Slicer-on-10-8-tp4027602p4027604.html [^] On the other hand, I was able to reproduce the hang using version "cmake-2.8.10.20130215-g4c900". I suspect it be caused by commit [1] recently introduced and discussed in 0013756 [2] and 0013901 [3] [1] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccfeefae [^] [2] http://www.cmake.org/Bug/view.php?id=13756 [^] [3] http://www.cmake.org/Bug/view.php?id=13901#c32239 [^]

(0032323) Brad King (manager) 2013-02-18 08:28	Re 0013926:0032319: Is Slicer trying to change the compiler of an existing build tree? All the issues/changes in your summary affect that.

(0032324) Brad King (manager) 2013-02-18 08:53	Re 0013926:0032323, 0013926:0032319: The loop is also caused by "-DCMAKE_C_COMPILER=cc" in an already-configured tree where CMake has expanded "cc" to a full path already.

(0032334) Jean-Christophe Fillion-Robin (reporter) 2013-02-18 11:43	Thanks for the hint. We are indeed passing CMAKE_{C, CXX}_COMPILER to both Slicer inner build and also all the other external projects to ensure that the compiler used by the developer is the one that will be used everywhere. That said, I think this happen while "ExternalProject" module initially configuring each tree, it is still not clear to me why this is causing trouble. [1] https://github.com/Slicer/Slicer/blob/master/SuperBuild.cmake#L369 [^] [2] https://github.com/Slicer/Slicer/blob/master/SuperBuild/External_CTK.cmake#L75 [^]

(0032355) Brad King (manager) 2013-02-20 08:14	I think the fix to 0013756 mentioned in 0013756:0032354 may resolve this issue too. Please re-open if not.

(0033432) Robert Maynard (manager) 2013-07-01 09:38	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2013-02-15 15:23	Greg Sharp	New Issue
2013-02-15 15:31	Jean-Christophe Fillion-Robin	Note Added: 0032299
2013-02-15 16:21	Bill Hoffman	Note Added: 0032300
2013-02-15 19:19	Christopher Mullins	Note Added: 0032301
2013-02-15 21:34	Greg Sharp	Note Added: 0032304
2013-02-15 21:34	Greg Sharp	File Added: dtruss.out
2013-02-15 21:43	Jean-Christophe Fillion-Robin	Note Added: 0032305
2013-02-15 21:44	Jean-Christophe Fillion-Robin	Note Deleted: 0032305
2013-02-17 11:43	Jean-Christophe Fillion-Robin	Note Added: 0032319
2013-02-17 11:44	Jean-Christophe Fillion-Robin	Note Edited: 0032319
2013-02-18 08:28	Brad King	Note Added: 0032323
2013-02-18 08:53	Brad King	Note Added: 0032324
2013-02-18 11:43	Jean-Christophe Fillion-Robin	Note Added: 0032334
2013-02-20 08:14	Brad King	Note Added: 0032355
2013-02-20 08:14	Brad King	Assigned To	=> Brad King
2013-02-20 08:14	Brad King	Status	new => resolved
2013-02-20 08:14	Brad King	Resolution	open => fixed
2013-02-20 08:14	Brad King	Fixed in Version	=> CMake 2.8.11
2013-02-20 08:14	Brad King	Target Version	=> CMake 2.8.11
2013-02-20 08:14	Brad King	Relationship added	related to 0013756
2013-07-01 09:38	Robert Maynard	Note Added: 0033432
2013-07-01 09:38	Robert Maynard	Status	resolved => closed