Opened 10 years ago
Closed 10 years ago
#8068 closed Bugs (invalid)
Bad Memory Access in boost::future<>.then() after accessing given future
| Reported by: | Owned by: | viboes | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | thread |
| Version: | Boost 1.53.0 | Severity: | Problem |
| Keywords: | Cc: |
Description
When using "then" on a future and accessing the value of the future in the continuation, the memory of the future is freed/released and the further execution of the continuation happens in an undefined limbo state (leading to a crash with EXC_BAC_ACCESS at least on iOS.
Here is a minimal example:
#define BOOST_THREAD_VERSION 4
#include <boost/thread.hpp>
class Test {
public:
void test() {
boost::shared_ptr<Test> listener(new Test());
boost::future<bool> con = boost::make_future(true);
listener->foo(); // Works
boost::future<bool> initDone = con.then([listener](boost::future<bool>& connected) {
listener->foo(); // Works
if (!connected.get()) {
listener->foo();
return false;
}
listener->foo(); // EXC_BAD_ACCESS
return true;
});
}
void foo() {
std::cout << "foo";
}
};
Attachments (1)
Change History (6)
by , 10 years ago
| Attachment: | after-get.png added |
|---|
comment:1 by , 10 years ago
| Component: | threads → thread |
|---|
comment:2 by , 10 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I'm aware of the bug. future<>.then is not stable yet. this is why I have not delivered it yet, that is is not in the documentation. Sorry for this.
comment:3 by , 10 years ago
You could try with
#define BOOST_THREAD_DONT_PROVIDE_FUTURE_INVALID_AFTER_GET
but even with this future<>.then is not stable yet.
comment:4 by , 10 years ago
Thanks, with disabling the invalidation it seems to work. However, since it is not considered stable yet, I'll switch to using a separate thread in which I'll wait for the future and execute the needed actions afterwards.
comment:5 by , 10 years ago
| Resolution: | → invalid |
|---|---|
| Status: | assigned → closed |
I close the ticket as invalid as the feature is not delivered yet, but I have in mind that this doesn't works yet.

Debugger View after get() has been called in continuation