MantisBT - CMake
View Issue Details
0007011CMakeCMakepublic2008-05-13 17:442008-05-23 15:53
Geoff Hutchison 
Bill Hoffman 
normalmajoralways
closedfixed 
CMake-2-6 
 
0007011: CMake hangs after "-- Found Qt-Version 4.3.4" on Mac OS X 10.5.2
I am currently trying to update to Qt-4.4 and CMake 2.6 on my Mac. Some friends have had luck, but every Mac I've tested, everything hangs after Qt-4.x is found (both for 4.3.4 and 4.4).

I've tried running with cmake --debug-output, but nothing useful comes up. I'd be happy to help debug this (or find the bug myself), but cannot. CMake 2.4.x all worked cleanly on these Macs.
lsof shows:
cmake 742 ghutchis cwd DIR 14,2 952 5120970 /Users/ghutchis/Devel/avogadro
cmake 742 ghutchis txt REG 14,2 6562240 5558154 /Applications/CMake 2.6-0.app/Contents/bin/cmake
cmake 742 ghutchis txt REG 14,2 1059776 4706834 /usr/lib/dyld
cmake 742 ghutchis txt REG 14,2 135778304 5496740 /private/var/db/dyld/dyld_shared_cache_i386
cmake 742 ghutchis 0u CHR 16,0 0t29128 96934148 /dev/ttys000
cmake 742 ghutchis 1u CHR 16,0 0t29128 96934148 /dev/ttys000
cmake 742 ghutchis 2u CHR 16,0 0t29128 96934148 /dev/ttys000

No tags attached.
patch Modules_FindOpenSSL_cmake.patch (698) 2008-05-14 03:58
https://public.kitware.com/Bug/file/1461/Modules_FindOpenSSL_cmake.patch
txt cmake-bt.txt (4,001) 2008-05-16 17:33
https://public.kitware.com/Bug/file/1469/cmake-bt.txt
Issue History
2008-05-13 17:44Geoff HutchisonNew Issue
2008-05-13 21:21Bill HoffmanStatusnew => assigned
2008-05-13 21:21Bill HoffmanAssigned To => Clinton Stimpson
2008-05-13 23:45Clinton StimpsonNote Added: 0011883
2008-05-14 03:28Michael WildNote Added: 0011886
2008-05-14 03:58Michael WildFile Added: Modules_FindOpenSSL_cmake.patch
2008-05-14 04:07Michael WildNote Added: 0011889
2008-05-14 04:08Michael WildNote Edited: 0011889
2008-05-14 08:57Geoff HutchisonNote Added: 0011892
2008-05-14 09:00Geoff HutchisonNote Added: 0011894
2008-05-14 15:14Bill HoffmanAssigned ToClinton Stimpson => Bill Hoffman
2008-05-14 15:16Bill HoffmanNote Added: 0011912
2008-05-14 15:18Bill HoffmanNote Added: 0011913
2008-05-14 15:50Clinton StimpsonNote Added: 0011918
2008-05-14 17:36Geoff HutchisonNote Added: 0011923
2008-05-14 19:36Geoff HutchisonNote Added: 0011938
2008-05-15 14:51Bill HoffmanNote Added: 0011949
2008-05-16 17:31Geoff HutchisonNote Added: 0011980
2008-05-16 17:33Geoff HutchisonFile Added: cmake-bt.txt
2008-05-23 15:53Bill HoffmanStatusassigned => closed
2008-05-23 15:53Bill HoffmanNote Added: 0012097
2008-05-23 15:53Bill HoffmanResolutionopen => fixed

Notes
(0011883)
Clinton Stimpson   
2008-05-13 23:45   
Can you reproduce it with a minimal CMakeLists.txt file?

==== CMakeLists.txt ====

find_package(Qt4)

=========================
(0011886)
Michael Wild   
2008-05-14 03:28   
CMake doesn't hang, and it isn't a problem of FindQt4.cmake neither. The problem lies in FindOpenSSL.cmake which gets called by FindQt4.cmake and is due to FIND_PATH(OPENSSL_INCLUDE_DIR openssl/ssl.h ) taking a very long time to complete. It seems as if FIND_PATH had serious problems with the partial path openssl/ssl.h. Using FIND_PATH(OPENSSL_INCLUDE_DIR ssl.h PATH_SUFFIXES openssl) seems to resolve the issue.
(0011889)
Michael Wild   
2008-05-14 04:07   
(edited on: 2008-05-14 04:08)
The attached patch solves the issue with FindOpenSSL.cmake. However, I'm not sure whether this actually should be considered as a bug of FIND_PACKAGE.

Timings:
w/o patch:
  FindOpenSSL: 40-50s
  FindQt4: 50-60s
with patch:
  FindOpenSSL: 1-2s
  FindQt4: 7-10s

These measurements fluctuated quite heavily because I had some pretty demanding stuff running at the same time.

(0011892)
Geoff Hutchison   
2008-05-14 08:57   
This does seem to resolve the issue for me. Thanks very much!
(0011894)
Geoff Hutchison   
2008-05-14 09:00   
Ah, for future reference, yes the issue could be reproduced by a minimal CMakeLists.txt, and I never had FindQt4 complete -- even after 10s of minutes, although I also have millions of files.
(0011912)
Bill Hoffman   
2008-05-14 15:16   
That should work. Is it perhaps hitting a network path or something? Can you run ktrace or add some debug print into cmake, so we can figure out what is taking so long? There are lots of other modules that use find path like that so, this fix is really just a hack around a specific instance of the problem.
(0011913)
Bill Hoffman   
2008-05-14 15:18   
My guess is this:

std::string cmFindPathCommand::FindHeaderInFramework(std::string& file,
                                                     std::string& dir)
{
  cmStdString fileName = file;
  cmStdString frameWorkName;
  cmStdString::size_type pos = fileName.find("/");
  // if there is a / in the name try to find the header as a framework
  // For example bar/foo.h would look for:
  // bar.framework/Headers/foo.h
  if(pos != fileName.npos)
    {
(0011918)
Clinton Stimpson   
2008-05-14 15:50   
I'm not able to reproduce the slowness, or any speed up with the patch.

For someone who can reproduce it, can you attach a ktrace of cmake?
Perhaps the best way would be to do one cmake run on the minimal CMakeLists.txt, remove the OPENSSL_INCLUDE_DIR from the CMakeCache.txt, and do another run with "ktrace cmake ." and attach the ktrace.out file. The ktrace.out file will also include timings that we can look at.
(0011923)
Geoff Hutchison   
2008-05-14 17:36   
Unfortunately, I'm using 10.5.x, so there's no ktrace. I haven't found anything on Google about emulating ktrace with dtrace. I also tried using the latter and Instruments to see what's going on.

I took the advice of bill.hoffman and looked at the source. I modified cmdFindPathCommand::FindHeaderInFramework to add an std::cerr. I'm now in the process of attempting to bootstrap the source and hit the same hang.

It looks like bootstrap has created an initial cmake:
loading initial cache file /Users/ghutchis/Devel/tools/cmake-2.6.0/Bootstrap.cmk/InitialCacheFlags.cmake
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done

At this point, I hit all of my new debugging statements:
 Find Header in Framework README.INSTALL /Users/ghutchis/Library/Frameworks/
 Find Header in Framework README.INSTALL /Library/Frameworks/
 Find Header in Framework README.INSTALL /Network/Library/Frameworks/
 Find Header in Framework README.INSTALL /System/Library/Frameworks/
 Find Header in Framework README.INSTALL /Users/ghutchis/Applications/
 Find Header in Framework README.INSTALL /Applications/
 Find Header in Framework README.INSTALL /Developer/Applications/
 Find Header in Framework README.INSTALL /usr/local/bin/
 Find Header in Framework README.INSTALL /opt/local/
 Find Header in Framework README.INSTALL /opt/local/
 Find Header in Framework README.INSTALL /usr/texbin/
 Find Header in Framework README.INSTALL /usr/bin/
 Find Header in Framework README.INSTALL /bin/
 Find Header in Framework README.INSTALL /usr/sbin/
 Find Header in Framework README.INSTALL /sbin/
 Find Header in Framework README.INSTALL /usr/local/bin/
 Find Header in Framework README.INSTALL /usr/X11/bin/
 Find Header in Framework README.INSTALL /include/
 Find Header in Framework README.INSTALL /
(hang)

That is, right now, it's looking for README.INSTALL in /.
More debugging output indicates that the hang occurs in the globIt.FindFiles() call.

Trying from the command-line, it seems like I'm hitting a hang with the /net directory.
(0011938)
Geoff Hutchison   
2008-05-14 19:36   
If I change the FindHeaderInFramework function:

std::string cmFindPathCommand::FindHeaderInFramework(std::string& file,
                                                     std::string& dir)
{
  if (dir == "/")
    return "";

  cmStdString fileName = file;
  cmStdString frameWorkName;


Everything appears to function normally. To me, this seems like an acceptable work-around, since headers will not be found in /*/Headers -- I can only find /Developer/Headers based off of that glob. (I believe this path is already searched.)
(0011949)
Bill Hoffman   
2008-05-15 14:51   
Odd thing that it is even looking in /. I wonder where that is coming from? Any ideas?
(0011980)
Geoff Hutchison   
2008-05-16 17:31   
Since I know practically nothing about Cmake internals, I have no idea. Attached is a back-trace. The first hit is for cmFindPathCommand:FindHeaderInFramework() which is triggered when "/" is sent as the dir.

Offhand, I'd guess "/" is set somewhere in a search path.
(0012097)
Bill Hoffman   
2008-05-23 15:53   
OK, this is fixed in CVS and should be in 2.6.1. I found out where the / was getting added into the search paths and removed it from there. Change to cmFindBase.cxx