Description of problem: "yum update yaml-cpp" will break applications compiled against yaml-cpp-0.5.1. See for example https://github.com/scylladb/scylla/issues/3161 and https://github.com/scylladb/scylla/issues/3157. Version-Release number of selected component (if applicable): yaml-cpp-0.5.3-7.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Build an application against yaml-cpp-0.5.1 2. Update to yaml-cpp-0.5.3 3. Run the application Actual results: Crash, memory corruption, world ends. Expected results: Upgrade has no effect except for bugs fixed. Additional info: yaml-cpp is a header and template intensive library. Any small change in a header can cause upgrades to fail. IMO, the best way to fix it is to remove the shared library and replace it with a static library, so that the application and library must be updated in lock step. Alternatively, keep the shared library, but add a static library. Applications will still break, but when they find out, they'll be able to switch to the static library.
I really hate updating packages on EPEL but I was asked too... It would have been really nice to find out before pushing the packages to stable but no one seems to check updates-testing on EPEL. I could try to bump the Epoch and downgrade the package.
For reference, the offending commit is commit 03d6e7d67271be698d9a2fd51f749201649e0223 Author: Haydn Trigg <me> Date: Sat Jul 25 11:45:10 2015 +0930 Removed boost requirement from memory.h (detail) Removed the boost requirement from memory.h using the shared_memory type defined in ptr.h diff --git a/include/yaml-cpp/node/detail/memory.h b/include/yaml-cpp/node/detail/memory.h index e3d344b..8f2bc26 100644 --- a/include/yaml-cpp/node/detail/memory.h +++ b/include/yaml-cpp/node/detail/memory.h @@ -5,12 +5,10 @@ (defined(__GNUC__) && (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) || \ (__GNUC__ >= 4)) // GCC supports "pragma once" correctly since 3.4 #pragma once #endif -#include <boost/shared_ptr.hpp> -#include <boost/smart_ptr/shared_ptr.hpp> #include <set> #include "yaml-cpp/dll.h" #include "yaml-cpp/node/ptr.h" @@ -38,11 +36,11 @@ class YAML_CPP_API memory_holder { node& create_node() { return m_pMemory->create_node(); } void merge(memory_holder& rhs); private: - boost::shared_ptr<memory> m_pMemory; + shared_memory m_pMemory; }; } } #endif // VALUE_DETAIL_MEMORY_H_62B23520_7C8E_11DE_8A39_0800200C9A66 which changes a boost::shared_ptr to an std::shared_ptr, which have different memory layouts.
Bumping epoch and downgrading would work too. We have some packages that were already built againt 0.5.3, but they weren't released yet.
For now, what about reversing the patch and doing new builds?
+1
Here's a scratch build I just completed, please make sure it address the problem before I do official builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=24516842
Will test.
Scratch build still fails.
I tried running abi-compliance-checker against them but it errors out, we'll see if I can figure it out.
See if you can make sense of this: https://hobbes1069.fedorapeople.org/compat_reports/yaml-cpp/0.5.1_to_0.5.3/compat_report.html
It does say that node_data changed layout. Since there are inline member functions for that type, such a function inlined in an executable compiled against one version of yaml-cpp will fail against another version.
Ok, working on reverting the update.
Thanks. Please also consider packaging the static library in -devel, it will help avoid such problems in the future as upstream doesn't maintain binary compatibility across patch releases (in their defense, that's very hard with template-intensive C++ code).
yaml-cpp-0.5.1-1.el7.1 pdns-3.4.11-3.el7 mongodb-2.6.12-6.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-adb6af896b
(In reply to Avi Kivity from comment #13) > Thanks. Please also consider packaging the static library in -devel, it will > help avoid such problems in the future as upstream doesn't maintain binary > compatibility across patch releases (in their defense, that's very hard with > template-intensive C++ code). Unfortunately the packaging guidelines require it be in a -static subpackage...
Thanks, verified that it fixes the problem for me, and that it installs over 0.5.3 without complaints.
> Unfortunately the packaging guidelines require it be in a -static subpackage... Not a problem.
I can push it to stable early if you log in to bodhi and give it positive karma (plus scrounge up 2 more people to do it, with testing!).
I already Karma'd it. I'll ask here and on our mailing list.
mongodb-2.6.12-6.el7, pdns-3.4.11-3.el7, yaml-cpp-0.5.1-1.el7.1 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-adb6af896b
Karma is now at +3 (from at least 4 testers :)
mongodb-2.6.12-6.el7 pdns-3.4.11-3.el7 yaml-cpp-0.5.1-1.el7.2 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-adb6af896b
mongodb-2.6.12-6.el7, pdns-3.4.11-3.el7, yaml-cpp-0.5.1-1.el7.2 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-adb6af896b
So, from all the logs I can't tell if it got pushed to stable or not? It has the necessary karma AFAICT.
I've submitted it to stable, but it won't get picked up until the next push.
mongodb-2.6.12-6.el7, pdns-3.4.11-3.el7, yaml-cpp-0.5.1-1.el7.2 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
New packages showed up. Thanks a lot for your quick response.