MantisBT - CMake
View Issue Details
0009845CMakeCMakepublic2009-11-05 03:092016-06-10 14:31
David Holm 
Bill Hoffman 
normalminoralways
closedmoved 
CMake-2-6 
 
0009845: Segmentation fault when using hgfs
Hi,
I recently started using MacOS but most of our projects build for Linux. Since I had no time to set up cross-compilers I decided to use VMware Fusion to maintain a Linux installation with my compilers. This solution has worked very well for several months now but all of a sudden, when adding a file to one of the library CMakeLists.txt I stumbled upon a segmentation fault that I cannot get past.
VMware Fusion has a feature called hgfs which allows you to access files from the host system. So I have the entire repository on the Mac system (Git works faster and I can use GitX) and then symlink it into the Linux system, this used to work.
Setup:
** Mac **
~/Documents/hgfs-test/client

** Linux **
Symbolic link to source /mnt/hgfs/david.holm\ On\ My\ Mac/Documents/Projects/ZetaDisplay/client/
Build Directory build-linux
Running CMake from build-linux by: cmake ../client/

Note: that this worked perfectly a couple of weeks ago and to the best of my knowledge I haven't upgraded VMware Fusion, CMake or my compiler.
If I check out the project in Linux and build there are no segfaults but I would like to use Xcode to develop and Linux to compile.

See attached build log: CMake-segfault.rtf

Let me know what you need since this is an odd setup.
No tags attached.
rtf CMake-segfault.rtf (4,186) 2009-11-05 03:09
https://public.kitware.com/Bug/file/2636/CMake-segfault.rtf
txt CMakeLists.txt (393) 2009-11-05 03:10
https://public.kitware.com/Bug/file/2637/CMakeLists.txt
txt verbose-log.txt (2,245) 2009-11-10 03:55
https://public.kitware.com/Bug/file/2645/verbose-log.txt
Issue History
2009-11-05 03:09David HolmNew Issue
2009-11-05 03:09David HolmFile Added: CMake-segfault.rtf
2009-11-05 03:10David HolmFile Added: CMakeLists.txt
2009-11-05 14:00Bill HoffmanNote Added: 0018352
2009-11-05 14:00Bill HoffmanStatusnew => assigned
2009-11-05 14:00Bill HoffmanAssigned To => Bill Hoffman
2009-11-10 03:55David HolmNote Added: 0018382
2009-11-10 03:55David HolmFile Added: verbose-log.txt
2009-11-10 04:07David HolmNote Added: 0018383
2009-11-10 04:09David HolmNote Added: 0018384
2009-11-10 04:16David HolmNote Added: 0018385
2009-11-10 07:42Bill HoffmanNote Added: 0018386
2016-06-10 14:27Kitware RobotNote Added: 0041610
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0018352)
Bill Hoffman   
2009-11-05 14:00   
Can you run make VERBOSE=1 to find out exactly which command line is crashing?

Then run the command in gdb? I would like to see a call stack. Alternatively, you should be able to setup the mac to create core files when things crash. Then you can run gdb and load the core file and give me a call stack. Is there a core file left by cmake?

Seems to be a crash in the depend stuff.
(0018382)
David Holm   
2009-11-10 03:55   
Note:
I'm compiling from a Linux guest in VMware. If I copy in all the files there are no problems but I cannot use Xcode since it cannot easily access the files.
There are 168 cpp/hpp-files alone on the libraries subprojects all of which compile with the exception of this one particular file using the above mentioned method. In fact, I can build the entire project if I remove it and its dependencies which is a rather large project.
So all the source files are hosted on the Mac and exposed via VMware's hgfs interface.


If I run it with gdb I get:
(gdb) run
Starting program: /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/david.holm/Documents/ZetaDisplay/client /home/david.holm/Documents/ZetaDisplay/client/libs/scheduling /home/david.holm/Documents/ZetaDisplay/build-linux /home/david.holm/Documents/ZetaDisplay/build-linux/libs/scheduling /home/david.holm/Documents/ZetaDisplay/build-linux/libs/scheduling/CMakeFiles/scheduling.dir/DependInfo.cmake --color=
[Thread debugging using libthread_db enabled]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt full
No stack.



valgrind simply goes:
valgrind --leak-check=full /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/david.holm/Documents/ZetaDisplay/client /home/david.holm/Documents/ZetaDisplay/client/libs/scheduling /home/david.holm/Documents/ZetaDisplay/build-linux /home/david.holm/Documents/ZetaDisplay/build-linux/libs/scheduling /home/david.holm/Documents/ZetaDisplay/build-linux/libs/scheduling/CMakeFiles/scheduling.dir/DependInfo.cmake --color=
==30671== Memcheck, a memory error detector
==30671== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==30671== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info
==30671== Command: /usr/bin/cmake -E cmake_depends Unix\ Makefiles /home/david.holm/Documents/ZetaDisplay/client /home/david.holm/Documents/ZetaDisplay/client/libs/scheduling /home/david.holm/Documents/ZetaDisplay/build-linux /home/david.holm/Documents/ZetaDisplay/build-linux/libs/scheduling /home/david.holm/Documents/ZetaDisplay/build-linux/libs/scheduling/CMakeFiles/scheduling.dir/DependInfo.cmake --color=
==30671==
Segmentation fault
(0018383)
David Holm   
2009-11-10 04:07   
Scratch that about only affecting one file. Now even if I remove it from CMakeLists.txt I get a segfault. In the meantime I will rsync over the files to my virtual machine when building.
(0018384)
David Holm   
2009-11-10 04:09   
In case it matters:

cat /etc/issue
Ubuntu 9.10 \n \l

cmake --version
cmake version 2.6-patch 4
(0018385)
David Holm   
2009-11-10 04:16   
I'm using VMware Fusion 3 and running their tools, not the ones supplied by Ubuntu.
(0018386)
Bill Hoffman   
2009-11-10 07:42   
Can you build with debug on and try gdb and valgrind again?

Build with this on in your cmake build tree:
CMAKE_BUILD_TYPE=Debug
(0041610)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.