[jira] Resolved: (THRIFT-464) TimerManager uses std::set iterator after erasing the element that it references

["David Reiss (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Reiss resolved THRIFT-464.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 0.2

> TimerManager uses std::set iterator after erasing the element that it references
> --------------------------------------------------------------------------------
>
>                 Key: THRIFT-464
>                 URL: https://issues.apache.org/jira/browse/THRIFT-464
>             Project: Thrift
>          Issue Type: Bug
>          Components: Library (C++)
>    Affects Versions: 0.1
>         Environment: Mac OS X 10.5.6
>            Reporter: Rush Manbert
>             Fix For: 0.2
>
>         Attachments: TimerManagerPatch.txt
>
>
> In lib/cpp/src/concurrency/TimerManager.cpp the  TimerManager::stop() method has this loop:
>    if (doStop) {
>      // Clean up any outstanding tasks
>     for (task_iterator ix =  taskMap_.begin(); ix != taskMap_.end(); ix++) {
>       taskMap_.erase(ix);
>     }
> but, to quote Scott Meyers in "Effective STL", "when an element of a container is erased, all iterators that point to that element are invalidated", so this can result in undefined behavior.
> All that really needs to happen here is this:
>    if (doStop) {
>      // Clean up any outstanding tasks
>      taskMap_.clear();
>     }
> I discovered this by making a Xcode project using the entire contents of lib/cpp/src to make a command line utility. Since there is only one file in the tree that defines main(), I could get away with it. I did a Debug build and ran it and it blew up at the location I identified.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.