[cmake-developers] [CMake 0016134]: CMake crashes at generation stage

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=16134 
== 
Reported By:Daniel Levin
Assigned To:
== 
Project:CMake
Issue ID:   16134
Category:   CMake
Reproducibility:always
Severity:   crash
Priority:   high
Status: new
== 
Date Submitted: 2016-06-01 23:58 EDT
Last Modified:  2016-06-01 23:58 EDT
== 
Summary:CMake crashes at generation stage
Description: 
Reproducibility 100% on my personal project using either Makefile or Ninja
generator. Affected all CMake version after 3.4, earlier versions might contains
this issue as well, did not check. Provided fixup patch is for CMake 3.4.0.
Versions 3.5+ have different implementation of the same code, but bug is still
there. Please see attached Git bundle with branch 'bug' inside that contains the
fix.

Copy of the patch message:

cmGeneratorTarget: Fix tracing dependencies in local generator

When looping over the generator targets they might become indirectly
invalidated and recreated from cmGlobalGenerator::CreateGenerationObjects().
Thus targets container cmGeneratorTarget pointers will be deleted,
dereferencing them leads to crashes at generation stage.

To avoid this loop should iterate over cmTarget keys and look for
cmGeneratorTarget pointers directly from Makefile instance each time.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-06-01 23:58 Daniel Levin   New Issue
2016-06-01 23:58 Daniel Levin   File Added: crash.bundle 
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Matthäus G . Chajdas]

Hi Brad,

done - I had to squash and force push once more, because I used the
wrong author in the first commit.

Everything is now in one commit here:
https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4

Thanks for the timely feedback!

Cheers,
  Matthäus

Am 01.06.2016 um 20:22 schrieb Brad King:
> On 06/01/2016 02:15 PM, Matthäus G. Chajdas wrote:
>> Hopefully done
> 
> The revised history looks good.  The change itself looks good.
> 
> Please also add a `Help/release/dev/FindOpenCL-imported-target.rst`
> file with a release note for the feature.  Look at other files
> in that directory for a sample.  See Help/release/*.rst for other
> examples.
> 
> As part of the modernization of find modules we're also trying
> to add better testing for them.  Please see Tests/FindPNG and the
> CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct
> a similar test for the FindOpenCL module.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Brad King]

On 06/01/2016 02:15 PM, Matthäus G. Chajdas wrote:
> Hopefully done

The revised history looks good.  The change itself looks good.

Please also add a `Help/release/dev/FindOpenCL-imported-target.rst`
file with a release note for the feature.  Look at other files
in that directory for a sample.  See Help/release/*.rst for other
examples.

As part of the modernization of find modules we're also trying
to add better testing for them.  Please see Tests/FindPNG and the
CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct
a similar test for the FindOpenCL module.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Matthäus G . Chajdas]

Hopefully done - I'm not the biggest git expert but the history looks
like I'd expect it to look like :)

Cheers,
  Matthäus

Am 01.06.2016 um 19:57 schrieb Brad King:
> On 06/01/2016 01:53 PM, Matthäus G. Chajdas wrote:
>> updated to latest master and pushed again (I merged latest master into
>> this - is that fine or does it have to be a rebase? In that case I'll redo.)
> 
> Please rebase and force push.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] fix issue #0016076 Add a --bindir option to bootstrap and use it to install cmake in custom directory

[Brad King]

On 05/30/2016 10:50 AM, BUNEL Nicolas wrote:
> Here, the new patch

Thanks.

I've applied the patches, squashed, and made some minor tweaks.
It has been merged to 'next' for testing:

 Add option to control 'bin' directory of CMake's own installation (#16076)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18bfbc97

Please try out that version.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Brad King]

On 06/01/2016 01:53 PM, Matthäus G. Chajdas wrote:
> updated to latest master and pushed again (I merged latest master into
> this - is that fine or does it have to be a rebase? In that case I'll redo.)

Please rebase and force push.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Matthäus G . Chajdas]

Hi Brad,

updated to latest master and pushed again (I merged latest master into
this - is that fine or does it have to be a rebase? In that case I'll redo.)

Cheers,
  Matthäus

Am 01.06.2016 um 17:18 schrieb Brad King:
> On 05/31/2016 03:17 PM, Matthäus G. Chajdas wrote:
>> I've just pushed "add-opencl-imported-target" which adds an imported
>> target to FindOpenCL. The whole change is rather small:
>>
>> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71
>>
>> Good to merge this to next for testing?
> 
> Please rebase on 'master' now that post-3.6 development is open.
> 
> Thanks,
> -Brad
> 

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Some trivial patches

[Brad King]

On 06/01/2016 05:04 AM, Tobias Hunger wrote:
> Attached you will find a couple of really small changes that add const to a
> method and fix a couple of typos in comments. Trivial stuff.

Thanks.  I've applied the changes:

 cmSearchPath: Fix typo in comment
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e

 cmSourceFileLocation: Fix typo in comment
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64

 cmGlobalGenerator: Make IsMultiConfig() const
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf

> This is mostly to figure out how to contribute code:-)

Good job.  For large changes (e.g. cmake-daemon work) feel free
to publish your branch somewhere and post a link here.  For most
changes please post here.

> Is this the preferred way you want your patches?
> Or do I need to inline them somehow?

Either attachments or inline is fine.

> How can I create an account in the bug tracker?

Unfortunately we had to turn off self-registration due to recent
spam attacks (by human registrants).  While we explore alternatives
it is a manual process. I'll contact you privately.

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake execute_process/signal_handler on Unix

[Brad King]

On 06/01/2016 09:04 AM, Yordanov, Dimitar wrote:
> I'm looking into an issue with a CMake build on Linux hanging in a
> select syscall, when using EXECUTE_PROCESS without any additional
> arguments. The subprocess executed is "chmod". The child finishes and
> is marked as a zombie, but CMake did not realize that. The only
> descriptors left open are the one of the signaling pipe.

The code in question uses a well-known idiom to make SIGCHLD
select()able.  It has worked well for years on many platforms.
Are you running inside some kind of virtualization or emulation
environment?

> is the use of a shared variable "kwsysProcesses" in the signal
> handler. I think the usage of non volatile shared objects should be
> avoided in signal handlers and we should just do as less as we
> can in there.

IIRC we suppress signals while updating the shared variables.
CMake also doesn't use threads.

> Why do we need the "(void)pipeStatus;" lines. For debugging?

Some compilers complain we don't use the return value of write().
Therefore we must assign it to a variable.  Then compilers
complain that the variable is assigned a value that is never
used.  The cast suppresses this.

> Why do we need to read from the pipe in the signal handler?

If many signals are received in succession before the select()
wakes up and reads from the pipe then it could fill the pipe
and block in the handler.  We do a non-blocking read to make
sure the pipe never has more than one byte in it.  All we care
about is waking up any blocking select().

BTW, in the long run I'd like to drop this code completely and
move to libuv.  Meanwhile I'd rather not spend too much time
updating the existing implementation.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Topic "add-opencl-imported-target" good to merge?

[Brad King]

On 05/31/2016 03:17 PM, Matthäus G. Chajdas wrote:
> I've just pushed "add-opencl-imported-target" which adds an imported
> target to FindOpenCL. The whole change is rather small:
> 
> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71
> 
> Good to merge this to next for testing?

Please rebase on 'master' now that post-3.6 development is open.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake 3.6 feature freeze on 2016-06-01

[Brad King]

On 05/27/2016 09:02 AM, Brad King wrote:
> I'll announce when post-3.6 development in 'next' is open.

I've branched 'release' for 3.6.  The repository is now open for
post-3.6 development.  Please rebase any open topics on 'master'
before merging to 'next'.

> * Documentation updates
> * Regression fixes
> * Fixes for bugs in features new to 3.6

These types of changes may still be accepted to 'release' during
the 3.6 release candidate cycle.  The 3.6 release is now closed
to new features and general bug fixes.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] CMake execute_process/signal_handler on Unix

[Yordanov, Dimitar]

Hey,

I'm looking into an issue with a CMake build on Linux hanging in a
select syscall, when using EXECUTE_PROCESS without any additional
arguments. The subprocess executed is "chmod". The child finishes and
is marked as a zombie, but CMake did not realize that. The only
descriptors left open are the one of the signaling pipe.

Looking through the code I couldn't see a place, where I could prove
that is directly related to the problem. Nevertheless I have a
question about the signal handler used. The function
kwsysProcessesSignalHandler in ProcessUnix.c. The problem that I see
is the use of a shared variable "kwsysProcesses" in the signal
handler. I think the usage of non volatile shared objects should be
avoided in signal handlers and we should just do as less as we
can in there. So my proposal would be:

1. Use just one SignalPipe for all subprocess
2. In the signal handler just write the one single byte into the w-end
of the pipe
3. Do the rest of the processing in the normal workflow.

A few more questions:
Why do we need the "(void)pipeStatus;" lines. For debugging?
Why do we need to read from the pipe in the signal handler?

Please let me know what is your opinion.

Best wishes
Dimitar
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Some trivial patches

[Tobias Hunger]

Hi CMake Developers!

Attached you will find a couple of really small changes that add const to a
method and fix a couple of typos in comments. Trivial stuff.

This is mostly to figure out how to contribute code:-)

Is this the preferred way you want your patches? Or do I need to inline
them somehow?

How can I create an account in the bug tracker?

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
From 2e3d372dd5026a257cd11badd87dbfff7255851d Mon Sep 17 00:00:00 2001
From: Tobias Hunger 
Date: Tue, 31 May 2016 13:53:19 +0200
Subject: [PATCH 01/11] cmGlobalGenerator: Make IsMultiConfig() const

---
 Source/cmGlobalGenerator.h | 2 +-
 Source/cmGlobalVisualStudioGenerator.h | 2 +-
 Source/cmGlobalXCodeGenerator.cxx  | 2 +-
 Source/cmGlobalXCodeGenerator.h| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 2575911..68ff042 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -319,7 +319,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return false; }
+  virtual bool IsMultiConfig() const { return false; }
 
   std::string GetSharedLibFlagsForLanguage(std::string const& lang) const;
 
diff --git a/Source/cmGlobalVisualStudioGenerator.h b/Source/cmGlobalVisualStudioGenerator.h
index fb2cdbd..1d456ff 100644
--- a/Source/cmGlobalVisualStudioGenerator.h
+++ b/Source/cmGlobalVisualStudioGenerator.h
@@ -85,7 +85,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return true; }
+  virtual bool IsMultiConfig() const { return true; }
 
   /** Return true if building for Windows CE */
   virtual bool TargetsWindowsCE() const { return false; }
diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx
index 6628cfc..b666594 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3437,7 +3437,7 @@ std::string cmGlobalXCodeGenerator::ComputeInfoPListLocation(
 
 // Return true if the generated build tree may contain multiple builds.
 // i.e. "Can I build Debug and Release in the same tree?"
-bool cmGlobalXCodeGenerator::IsMultiConfig()
+bool cmGlobalXCodeGenerator::IsMultiConfig() const
 {
   // Old Xcode 1.5 is single config:
   if (this->XcodeVersion == 15) {
diff --git a/Source/cmGlobalXCodeGenerator.h b/Source/cmGlobalXCodeGenerator.h
index 2ca4c19..0485d4f 100644
--- a/Source/cmGlobalXCodeGenerator.h
+++ b/Source/cmGlobalXCodeGenerator.h
@@ -79,7 +79,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig();
+  virtual bool IsMultiConfig() const;
 
   virtual bool SetGeneratorToolset(std::string const& ts, cmMakefile* mf);
   void AppendFlag(std::string& flags, std::string const& flag);
-- 
2.8.3

From 122c333c7820fd245a7a04851e4ac29cf58573a9 Mon Sep 17 00:00:00 2001
From: Tobias Hunger 
Date: Tue, 31 May 2016 17:15:22 +0200
Subject: [PATCH 02/11] Fix typo

---
 Source/cmSearchPath.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmSearchPath.h b/Source/cmSearchPath.h
index 4b37a3a..835196f 100644
--- a/Source/cmSearchPath.h
+++ b/Source/cmSearchPath.h
@@ -26,7 +26,7 @@ class cmSearchPath
 {
 public:
   // cmSearchPath must be initialized from a valid pointer.  The only reason
-  // for teh default is to allow it to be easily used in stl containers.
+  // for the default is to allow it to be easily used in stl containers.
   // Attempting to initialize with a NULL value will fail an assertion
   cmSearchPath(cmFindCommon* findCmd = 0);
   ~cmSearchPath();
-- 
2.8.3

From dfc0409147b6bb07e95226e2dd56b001f2cc6dc8 Mon Sep 17 00:00:00 2001
From: Tobias Hunger 
Date: Tue, 31 May 2016 17:15:56 +0200
Subject: [PATCH 03/11] Fix typo

---
 Source/cmSourceFileLocation.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmSourceFileLocation.h b/Source/cmSourceFileLocation.h
index af3651a..7989173 100644
--- a/Source/cmSourceFileLocation.h
+++ b/Source/cmSourceFileLocation.h
@@ -39,7 +39,7 @@ public:
   cmSourceFileLocation& operator=(const cmSourceFileLocation& loc);
 
   /**
-   * Return whether the givne source file location could refers to the
+   * Return whether the given source file location could refers to the
* same source file as this location given the level of ambiguity in
*