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