MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013926CMakeCMakepublic2013-02-15 15:232013-07-01 09:38
ReporterGreg Sharp 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSX 10.7OSOS Version
Product Version 
Target VersionCMake 2.8.11Fixed in VersionCMake 2.8.11 
Summary0013926: CMake hangs on OSX
DescriptionOSX 10.7
xcode 4.6 (4H127)
cmake-2.8.10.20130213-g7665b (built from source)

The cmake nightly successfully solves problem with finding QtWebKit framework on mac with newer xcode versions.

However, instead, cmake goes into an infinite loop when compiling using "make".
CMake CPU usage is 100%.

Here is where cmake goes into the infinite loop

-- Configuring SEM CLI module: DWIConvert
-- Configuring SEM CLI module: BRAINSCreateLabelMapFromProbabilityMaps
-- Enabling Slicer launcher option: --xterm
-- Enabling Slicer launcher option: --gdb
-- Configuring done
Steps To Reproduce
Additional InformationCross list with related issues

http://www.na-mic.org/Bug/view.php?id=2957 [^] (Bug filed for this issue @ Slicer)
http://www.cmake.org/Bug/view.php?id=13765 [^] (OSX framework linking error)
TagsNo tags attached.
Relationships
related to 0013756closed Brad King Infinite loop when reconfiguring with different CMAKE_C_COMPILER 
Attached Files? dtruss.out (169,241) 2013-02-15 21:34
https://public.kitware.com/Bug/file/4644/dtruss.out
Issue History
Date ModifiedUsernameFieldChange
2013-02-15 15:23Greg SharpNew Issue
2013-02-15 15:31Jean-Christophe Fillion-RobinNote Added: 0032299
2013-02-15 16:21Bill HoffmanNote Added: 0032300
2013-02-15 19:19Christopher MullinsNote Added: 0032301
2013-02-15 21:34Greg SharpNote Added: 0032304
2013-02-15 21:34Greg SharpFile Added: dtruss.out
2013-02-15 21:43Jean-Christophe Fillion-RobinNote Added: 0032305
2013-02-15 21:44Jean-Christophe Fillion-RobinNote Deleted: 0032305
2013-02-17 11:43Jean-Christophe Fillion-RobinNote Added: 0032319
2013-02-17 11:44Jean-Christophe Fillion-RobinNote Edited: 0032319bug_revision_view_page.php?bugnote_id=32319#r1038
2013-02-18 08:28Brad KingNote Added: 0032323
2013-02-18 08:53Brad KingNote Added: 0032324
2013-02-18 11:43Jean-Christophe Fillion-RobinNote Added: 0032334
2013-02-20 08:14Brad KingNote Added: 0032355
2013-02-20 08:14Brad KingAssigned To => Brad King
2013-02-20 08:14Brad KingStatusnew => resolved
2013-02-20 08:14Brad KingResolutionopen => fixed
2013-02-20 08:14Brad KingFixed in Version => CMake 2.8.11
2013-02-20 08:14Brad KingTarget Version => CMake 2.8.11
2013-02-20 08:14Brad KingRelationship addedrelated to 0013756
2013-07-01 09:38Robert MaynardNote Added: 0033432
2013-07-01 09:38Robert MaynardStatusresolved => closed

Notes
(0032299)
Jean-Christophe Fillion-Robin   
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   
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   
2013-02-15 19:19   
Here is another related issue.

http://www.cmake.org/Bug/view.php?id=13927 [^]
(0032304)
Greg Sharp   
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   
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   
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   
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   
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   
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   
2013-07-01 09:38   
Closing resolved issues that have not been updated in more than 4 months.