Operational Defect Database

BugZero found this defect 2358 days ago.

MongoDB | 425779

[SERVER-31016] return type 'std::__1::cv_status' must match previous return type 'std::__1::cv_status::__lx' when lambda expression has unspecified explicit return type

Last update date:


Affected products:

MongoDB Server

Affected releases:


Fixed releases:




mongodb 3.4.7 fails to build on OS X 10.8 with the compiler "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)" from Xcode 5.1.1; here is a build log: https://build.macports.org/builders/ports-10.8_x86_64_legacy-builder/builds/35112/steps/install-port/logs/stdio src/mongo/db/operation_context.cpp:335:13: error: return type 'std::__1::cv_status' must match previous return type 'std::__1::cv_status::__lx' when lambda expression has unspecified explicit return type return cv.wait_until(m, deadline.toSystemTimePoint()); ^ src/mongo/db/operation_context.cpp:340:9: error: return type 'stdx::cv_status' (aka 'std::__1::cv_status') must match previous return type 'std::__1::cv_status::__lx' when lambda expression has unspecified explicit return type return cvWaitUntilWithClockSource(clockSource, cv, m, deadline); ^ src/mongo/db/operation_context.cpp:366:12: error: no viable conversion from 'const std::__1::cv_status::__lx' to 'StatusWith<stdx::cv_status>' return waitStatus; ^~~~~~~~~~ The same version builds fine on OS X 10.9 with the compiler "Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)" from Xcode 6.2. Here is that build log: https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/34415/steps/install-port/logs/stdio The same version also builds fine on OS X 10.7 with clang 3.9.1 as installed by MacPorts. Here is that build log: https://build.macports.org/builders/ports-10.7_x86_64_legacy-builder/builds/40825/steps/install-port/logs/stdio If necessary, we can tell MacPorts to build mongodb with a newer clang on OS X 10.8 as well, but previous versions of mongodb built fine on OS X 10.8 with clang from Xcode so I wanted to let you know in case this is a bug.

Top User Comments

ryandesign commented on Tue, 31 Oct 2017 21:32:56 +0000: I think I've understood enough about lambdas now to guess that this is the additional change you're suggesting: --- src/mongo/db/operation_context_test.cpp.orig 2017-10-18 11:01:51.000000000 -0500 +++ src/mongo/db/operation_context_test.cpp 2017-10-31 16:03:27.000000000 -0500 @@ -231,7 +231,7 @@ Date_t maxTime) { auto barrier = std::make_shared<unittest::Barrier>(2); - auto task = stdx::packaged_task<stdx::cv_status()>([=] { + auto task = stdx::packaged_task<stdx::cv_status()>([=]() -> stdx::cv_status { if (maxTime < Date_t::max()) { txn->setDeadlineByDate(maxTime); } With that additional change, it builds! Thanks! acm commented on Tue, 31 Oct 2017 18:44:22 +0000: I think the same fix will work there: just give the lambda passed into the packaged_task a trailing return type of stdx::cv_status. ryandesign commented on Sun, 29 Oct 2017 13:40:51 +0000: Thanks for your help; sorry I didn't respond sooner. The patch you provided allows compilation to proceed further, but fails later with a similar error: :info:build src/mongo/db/operation_context_test.cpp:245:17: error: return type 'std::__1::cv_status::__lx' must match previous return type 'stdx::cv_status' (aka 'std::__1::cv_status') when lambda expression has unspecified explicit return type :info:build return stdx::cv_status::no_timeout; :info:build ^ acm commented on Tue, 17 Oct 2017 16:37:17 +0000: Hi ryandesign - I'm closing this ticket because there has been no activity on it for some time. I assume that you have either applied a local patch to address the issue, or that this is no longer a problem for you for other reasons. Please feel free to re-open the ticket or comment on it if there is additional help I can provide. acm commented on Mon, 9 Oct 2017 20:28:12 +0000: ryandesign - Just circling back to this ticket to see if you were able to verify my proposed fix. If so I would still encourage you to open a PR. acm commented on Wed, 20 Sep 2017 13:46:02 +0000: ryandesign - Were you able to test out my suggested change? Did it fix the issue for you? acm commented on Thu, 14 Sep 2017 15:55:41 +0000: Hi ryandesign - I had something like this in mind: diff --git a/src/mongo/db/operation_context.cpp b/src/mongo/db/operation_context.cpp index 8151fe97df..41b54eb661 100644 --- a/src/mongo/db/operation_context.cpp +++ b/src/mongo/db/operation_context.cpp @@ -325,7 +325,7 @@ StatusWith<stdx::cv_status> OperationContext::waitForConditionOrInterruptNoAsser deadline = std::min(deadline, getDeadline()); }   - const auto waitStatus = [&] { + const auto waitStatus = [&]() -> stdx::cv_status { if (Date_t::max() == deadline) { cv.wait(m); return stdx::cv_status::no_timeout; Note also that this appears to only affect the v3.4 branch (well, maybe 3.2 as well but I didn't check) - this code has changed in master. So if you validate this fix, please create a GitHub PR against the v3.4 branch, and I can run it through our CI loop and get it merged. ryandesign commented on Wed, 13 Sep 2017 18:35:28 +0000: I'd be happy to try out some changes, but I haven't used the C++ features you mentioned so I'm not sure what changes to make. Could you attach possible diffs to this issue for me to try? acm commented on Wed, 13 Sep 2017 15:44:30 +0000: Hi ryandesign - Thanks for the bug report. You have identified a weakness in our current CI environment, in that we don't actually build on macOS 10.8 with XCode 5. We set it as the minimum compiler version that we enforce, but I believe we actually do the official 3.4 builds with XCode 7 on a much newer macOS version, so this slipped by us. Given that, we don't really have a straightforward way to validate a fix for this. However, I think that the answer to this is probably as simple as either giving the lambda a trailing return type of stdx::cv_status, or wrapping the call to cv.wait_until in a stdx::cv_status constructor. It is interesting to me that the more recent compilers can see that this code is fine, so I suspect that this is really a bug in Xcode 5. Since you are in a position to repro with the configuration that you have, would you mind trying out one of the above suggestions, and, if one of them works, posting a CR? We will be able to get that merged as long as it tests clean in our CI system. Also, an FYI that MongoDB 3.5 (soon to be 3.6) has bumped the minimum to Xcode 8. ryandesign commented on Sat, 9 Sep 2017 15:09:07 +0000: I should be more specific about versions: mongodb 3.2.x built fine on OS X 10.8 with clang from Xcode. mongodb 3.4.0 and later don't.

Additional Resources / Links


BugZero Risk Score

Coming soon



Have you been affected by this bug?


Do you know how much operational outages are costing you?

Understand the cost to your business and how BugZero can help you reduce those costs.


Login to read and write comments.

Have you ever...

had your data corrupted from a