[CMake] Bug in cmake 2.8.4/5 when using IMPORTED static targets?

[David Cole]

Is your project publicly available?

Or can you construct a minimal reproduce case?

I'd like to reproduce that issue here and then get a fix in ASAP.


Thanks,
David


On Thu, Jul 21, 2011 at 1:07 PM, Marco Corvo <marco.corvo at pd.infn.it> wrote:

> Hi all,
>
> I'm trying to use a new feature of releases 2.8.4/5, that is the
> possibility to define dependencies for IMPORTED targets and when I run cmake
> I get a SIGSEV signal. Trying to get some more info with Valgrind I found
> that:
>
> -- Configuring done
> ==5659== Invalid read of size 1
> ==5659==    at 0x82001B0: cmTarget::IsImported() const (cmTarget.h:235)
> ==5659==    by 0x83CA8BB: cmComputeTargetDepends::**AddTargetDepend(int,
> cmTarget*, bool) (cmComputeTargetDepends.cxx:**272)
> ==5659==    by 0x83CA93E: cmComputeTargetDepends::**AddTargetDepend(int,
> cmTarget*, bool) (cmComputeTargetDepends.cxx:**281)
> ==5659==    by 0x83CA93E: cmComputeTargetDepends::**AddTargetDepend(int,
> cmTarget*, bool) (cmComputeTargetDepends.cxx:**281)
> ==5659==    by 0x83CAB3D: cmComputeTargetDepends::**AddTargetDepend(int,
> char const*, bool) (cmComputeTargetDepends.cxx:**263)
> ==5659==    by 0x83CAC5F: cmComputeTargetDepends::**CollectTargetDepends(int)
> (cmComputeTargetDepends.cxx:**216)
> ==5659==    by 0x83CAEFB: cmComputeTargetDepends::**CollectDepends()
> (cmComputeTargetDepends.cxx:**193)
> ==5659==    by 0x83CB055: cmComputeTargetDepends::**Compute()
> (cmComputeTargetDepends.cxx:**114)
> ==5659==    by 0x8346B4E: cmGlobalGenerator::**ComputeTargetDepends()
> (cmGlobalGenerator.cxx:912)
> ==5659==    by 0x8346ECB: cmGlobalGenerator::Generate()
> (cmGlobalGenerator.cxx:873)
> ==5659==    by 0x835C9AE: cmGlobalUnixMakefileGenerator3**::Generate() (**
> cmGlobalUnixMakefileGenerator3**.cxx:156)
> ==5659==    by 0x8260986: cmake::Generate() (cmake.cxx:2390)
> ==5659==  Address 0xdd is not stack'd, malloc'd or (recently) free'd
> ==5659==
> ==5659==
> ==5659== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==5659==  Access not within mapped region at address 0xDD
> ==5659==    at 0x82001B0: cmTarget::IsImported() const (cmTarget.h:235)
> ==5659==    by 0x83CA8BB: cmComputeTargetDepends::**AddTargetDepend(int,
> cmTarget*, bool) (cmComputeTargetDepends.cxx:**272)
> ==5659==    by 0x83CA93E: cmComputeTargetDepends::**AddTargetDepend(int,
> cmTarget*, bool) (cmComputeTargetDepends.cxx:**281)
> ==5659==    by 0x83CA93E: cmComputeTargetDepends::**AddTargetDepend(int,
> cmTarget*, bool) (cmComputeTargetDepends.cxx:**281)
> ==5659==    by 0x83CAB3D: cmComputeTargetDepends::**AddTargetDepend(int,
> char const*, bool) (cmComputeTargetDepends.cxx:**263)
> ==5659==    by 0x83CAC5F: cmComputeTargetDepends::**CollectTargetDepends(int)
> (cmComputeTargetDepends.cxx:**216)
> ==5659==    by 0x83CAEFB: cmComputeTargetDepends::**CollectDepends()
> (cmComputeTargetDepends.cxx:**193)
> ==5659==    by 0x83CB055: cmComputeTargetDepends::**Compute()
> (cmComputeTargetDepends.cxx:**114)
> ==5659==    by 0x8346B4E: cmGlobalGenerator::**ComputeTargetDepends()
> (cmGlobalGenerator.cxx:912)
> ==5659==    by 0x8346ECB: cmGlobalGenerator::Generate()
> (cmGlobalGenerator.cxx:873)
> ==5659==    by 0x835C9AE: cmGlobalUnixMakefileGenerator3**::Generate() (**
> cmGlobalUnixMakefileGenerator3**.cxx:156)
> ==5659==    by 0x8260986: cmake::Generate() (cmake.cxx:2390)
>
> So it looks like cmake is trying to access (dereference) a NULL pointer. In
> particular, digging in the source code, the issue arises (apparently) in
> cmComputeTargetDepends.cxx(**AddTargetDepend) at line 279
>
> cmTarget* transitive_dependee =
>        dependee->GetMakefile()->**FindTargetToUse(i->c_str());
>
> when cmake recursively calculates the dependency of my target, which relies
> on all IMPORTED targets, and hits an IMPORTED target (a library) with NO
> dependencies, that is the last leaf of my deps tree. The
> "transitive_dependee" returned by FindTargetToTuse turns out to be a NULL
> pointer and when IsImported() is called on it, it makes the program crash.
>
> Have anyone else tried to use this feature of cmake 2.8.4 and eventually
> discovered this issue?
>
> Cheers,
>
> Marco
>
>
> --
> Marco Corvo
> SuperB experiment
> CNRS - Orsay
> c/o INFN - Padova
> ______________________________**_________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/**
> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html>
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/**CMake_FAQ<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110721/c4e3d627/attachment.htm>