Bug 489046 - cmake fails in user's macro.
cmake fails in user's macro.
Product: Fedora
Classification: Fedora
Component: cmake (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Orion Poplawski
Fedora Extras Quality Assurance
Depends On:
Blocks: 457160
  Show dependency treegraph
Reported: 2009-03-06 17:10 EST by Paul F. Kunz
Modified: 2009-05-21 19:25 EDT (History)
5 users (show)

See Also:
Fixed In Version: 2.6.4-1.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-21 19:25:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
experimental patch to fix C-string corruption in cmMakefile.cxx (540 bytes, patch)
2009-03-15 07:24 EDT, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Paul F. Kunz 2009-03-06 17:10:45 EST
Description of problem:
CMake File command apparently fails because CMAKE_CURRENT_LIST_FILE variable
is incorrect set with non ASCII characters.

Version-Release number of selected component (if applicable):

How reproducible:
See bug 457160 comment #13

Steps to Reproduce:
1. Get SRPM from bug 457160
2. Try to build
Actual results:

Expected results:

Additional info:
User's cmake files work fine on Fedora 8, and 10 and line of code
with error was written by upstream developers in Oct 2007.
Comment 1 Kevin Kofler 2009-03-09 04:21:38 EDT
Unhiding this bug. It makes no sense to keep this restricted to Fedora contributors as all the information is also public in the review request.
Comment 2 Kevin Kofler 2009-03-09 04:23:25 EDT
From the Zorba review request:

Comment #24 From  Kevin Kofler 2009-03-07 18:04:32 EDT
I suspect this may be the same bug which triggers the random crashes during
kdepimlibs builds (which vanish when we try to debug them). See bug 475876 for
that one.

Comment #25 From  Kevin Kofler  2009-03-07 18:28:58 EDT
Hmmm, this is probably different from the other bug. The problem here is that
${CMAKE_CURRENT_LIST_FILE} is invalid for some reason. We need to figure out
why. The CMake call stack could help, but what would be even more useful would
be running Valgrind over cmake (with cmake-debuginfo installed) to see where
the memory corruption or the invalid pointer happens.

Comment #26 From  Kevin Kofler  2009-03-07 18:47:21 EDT
Actually I think I already know what's wrong. This is how
CMAKE_CURRENT_LIST_FILE is implemented (unless it changed since):

The problem here is that it saves the value into a std::string, then restores
it from that string's c_str. That pointer is no longer valid once the
std::string goes out of scope, which is soon afterwards. The value probably
needs to be saved into a const char * instead.

Comment #27 From  Kevin Kofler  2009-03-07 19:00:23 EDT
Actually, the definitions are stored in a map using std::string, so this can't
be it (AddDefinition copies the passed const char * into a new std::string, so
when the pointer goes out of scope, it's supposed to be copied already).

I think we really need a Valgrind log.

Comment #28 From  Kevin Kofler  2009-03-08 21:51:36 EDT
Any chance we can get a log from running cmake in Valgrind, if possible with
cmake-debuginfo installed?
Comment 3 Michael Schwendt 2009-03-14 13:43:28 EDT
The problem is related, however, because if  cmMakefile::ReadListFile(...)  is patched to use dynamically allocated copies of the C-strings (e.g. instead of assigning filenametoread = external), the problem goes away. Then, instead of the error seen in bug 457160 comment 13 (a result of a freed/corrupted RelativePath value) I get this:

CMake Error at cmake_modules/AddSrcSubfolder.cmake:18 (INCLUDE):
  include could not find load file:

Call Stack (most recent call first):
  src/CMakeLists.txt:54 (ADD_SRC_SUBFOLDER)

CMake Error at cmake_modules/AddSrcSubfolder.cmake:18 (INCLUDE):
  include could not find load file:

Call Stack (most recent call first):
  src/CMakeLists.txt:55 (ADD_SRC_SUBFOLDER)

CMake Error at cmake_modules/AddSrcSubfolder.cmake:18 (INCLUDE):
  include could not find load file:

Call Stack (most recent call first):
  src/CMakeLists.txt:58 (ADD_SRC_SUBFOLDER)

A deeper look is needed to find out why the relative path is wrong.
Comment 4 Michael Schwendt 2009-03-14 16:29:57 EDT
Results of a second look at it after dinner:

cmake_modules/AddSrcSubfolder.cmake  contains the ADD_SRC_SUBFOLDER and RELATIVE_PATH macros. These are used e.g. in src/zorbatypes/CMakeLists.txt where source sub-folders are added.

What I see here is that when the RELATIVE_PATH command in AddSrcSubfolder.cmake is evalulated, CMAKE_CURRENT_LIST_FILE contains the full path to cmake_modules/AddSrcSubfolder.cmake, a wrong relative path is calculated because of that, and in turn it fails to include the sub-folder CMakeLists.txt files. Hence the errors as above. If I patch it to evaluate CMAKE_PARENT_LIST_FILE instead, it works until cmake moves from the top-level "src" directory into the top-level "test" directory.
Comment 5 Michael Schwendt 2009-03-14 16:45:49 EDT
The cmake-2.6.3-2.fc10 test update is affected by this whereas cmake-2.6.2-3.fc10 in stable is not.
Comment 6 Kevin Kofler 2009-03-14 16:51:21 EDT
I think the memory misuse bug in CMake definitely needs fixing, can you please post the patch you used in comment #3?

As for the remaining issue, it looks like the behavior of CMAKE_CURRENT_LIST_FILE changed somehow from 2.6.2 to 2.6.3? What does CMAKE_CURRENT_LIST_FILE contain at the same place in 2.6.2?
Comment 7 Paul F. Kunz 2009-03-14 18:00:24 EDT
I just tried CMake 2.6.3 by installing it from source on a Fedora 10 machine.
With the sources reported in bug 457160 I get the same cmake problem.
I also don't see the problem with cmake-2.6.2.fc10.   So there is something broke in CMake 2.6.3.
Comment 8 Michael Schwendt 2009-03-15 07:24:34 EDT
Created attachment 335252 [details]
experimental patch to fix C-string corruption in cmMakefile.cxx

Here's what I changed to simply fight the symptoms (= garbage or "invalid args error" as a result of freed string storage).

What I haven't done is to trace the AddDefinition method to find out where this C-string is stored in the end, e.g. whether and how it is copied into a std::string.


> it looks like the behavior of CMAKE_CURRENT_LIST_FILE changed
> somehow from 2.6.2 to 2.6.3? What does CMAKE_CURRENT_LIST_FILE
> contain at the same place in 2.6.2?

That's a matter of definition. The existing documentation is terse. I assume with 2.6.2 the global points to the CMakeLists.txt file in the current "src" subdir, e.g. ./src/zorbatypes/CMakeLists.txt, before entering the source subfolders in that directory. As I see directory stack operations in the code, the changed behaviour could be side-effects.

If this in Zorba's ADD_SRC_SUBFOLDER,


is based on a wrong assumption (even if it used to work prior to 2.6.3), CMake cannot be blamed.
Comment 9 Paul F. Kunz 2009-05-12 17:47:57 EDT
I noticed that cmake 2.6.4 is now available.   I tried it on the sources of
 bug 457160 which originally reported this bug and things worked fine.
So if the maintainer can update to cmake 2.6.4, this issue will be resolved.
Comment 10 Paul F. Kunz 2009-05-21 19:24:54 EDT
I can confirm that this bug is fixed with cmake-2.6.4-1.rpm on Fedora 10.
Comment 11 Fedora Update System 2009-05-21 19:25:42 EDT
cmake-2.6.4-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.