Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
otb
otb
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 298
    • Issues 298
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 14
    • Merge Requests 14
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Main Repositories
  • otbotb
  • Issues
  • #513

Closed
Open
Opened Feb 07, 2012 by Sébastien Dinot@sdinotOwner

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)
Edited Feb 01, 2018 by Sébastien Dinot
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: orfeotoolbox/otb#513