dandling pointers
Mantis Issue 513, reported by lhermitte, assigned to jmichel, created: 2012-02-07
In several places a pointer to the inner chars buffer of a temporary string variable is extracted. When the string is released (on the ';' sequence point) the pointer points to nothing valid and applications may crash.
Where COW implementations of std::string are used (GNU's libstdc++, STLport), the code may fall into order. Indeed when the string returned is a copy (why BTW ? This is not efficient) of a string stored elsewhere (like in a std::map, see for instance ApplicationOptionResult::GetParameterString), the actual buffer of chars is (ref-count-)shared and the application still runs.
This is a side effect. Next gen implementations of std::string won't permit that as COW implementations have been (voluntarily) deprecated from 2011 C++ standard. VC++/dinkumware implementation is likely to become the new de-facto behavioural standard.
Hence, OTB will crash more and more often on unixes platforms.
NB: the bug was initially detected on a windows platform, in the old OTB-Applications/Classification/otbLabeledImageColorMapping.cxx
Suggestion: hunt down all appearances of c_str() to check they are not applied on temporary variables. typically a
find . -type f |xargs grep ").c_str"shall do the trick (I count 971 occurrences in the latest branch).
N.B.: The only valid uses are when the returned pointer is immediately consumed (and not stored) in a function e.g.
const int i = atoi(GetFoo("bar").c_str());
// BTW atoi is a code smell because of its defensive approach (to ignore failures)