Apache OpenOffice (AOO) Bugzilla – Issue 128422
Boost related crash on start of freshly built AOO
Last modified: 2021-01-06 23:33:23 UTC
AOO is configured as such : ./configure --enable-debug --disable-unit-tests --without-junit --with-lang=fr --with-package-format=installed --with-epm=internal --with-epm-url=https://github.com/jimjag/epm/archive/v5.0.0/epm-5.0.0.tar.gz --enable-category-b --enable-gstreamer --enable-opengl --enable-hyphen --enable-hunspell --enable-pdfimport --enable-wiki-publisher --enable-graphite --with-system-beanshell --with-beanshell-jar=/usr/share/java/bsh.jar --with-jdk-home=/usr/lib/jvm/java-8-openjdk It has been good for years. At commit 49cc8443e2a, AOO will crash on start. A debug build gdb backtrace is as follows : (gdb) bt #0 boost::unordered::detail::table<boost::unordered::detail::map<std::allocator<std::pair<rtl::OUString const, com::sun::star::uno::Any> >, rtl::OUString, com::sun::star::uno::Any, rtl::OUStringHash, std::equal_to<rtl::OUString> > >::get_previous_start(unsigned long) const (this=0x7fffffffdb90, bucket_index=0) at /home/arc/src/aoo/main/solver/450/unxlngx6.pro/inc/boost/unordered/detail/table.hpp:245 #1 0x00007fffed2aed29 in boost::unordered::detail::table<boost::unordered::detail::map<std::allocator<std::pair<rtl::OUString const, com::sun::star::uno::Any> >, rtl::OUString, com::sun::star::uno::Any, rtl::OUStringHash, std::equal_to<rtl::OUString> > >::begin(unsigned long) const (this=0x7fffffffdb90, bucket_index=0) at /home/arc/src/aoo/main/solver/450/unxlngx6.pro/inc/boost/unordered/detail/table.hpp:256 #2 0x00007fffed2aead4 in boost::unordered::detail::table_impl<boost::unordered::detail::map<std::allocator<std::pair<rtl::OUString const, com::sun::star::uno::Any> >, rtl::OUString, com::sun::star::uno::Any, rtl::OUStringHash, std::equal_to<rtl::OUString> > >::find_node_impl<rtl::OUString, std::equal_to<rtl::OUString> >(unsigned long, rtl::OUString const&, std::equal_to<rtl::OUString> const&) const (this=0x7fffffffdb90, key_hash=3315242591626035584, k=..., eq=...) at /home/arc/src/aoo/main/solver/450/unxlngx6.pro/inc/boost/unordered/detail/unique.hpp:236 #3 0x00007fffed2ae9c3 in boost::unordered::detail::table<boost::unordered::detail::map<std::allocator<std::pair<rtl::OUString const, com::sun::star::uno::Any> >, rtl::OUString, com::sun::star::uno::Any, rtl::OUStringHash, std::equal_to<rtl::OUString> > >::find_node(rtl::OUString const&) const (this=0x7fffffffdb90, k=...) at /home/arc/src/aoo/main/solver/450/unxlngx6.pro/inc/boost/unordered/detail/table.hpp:784 #4 0x00007fffed2ae76c in boost::unordered::unordered_map<rtl::OUString, com::sun::star::uno::Any, rtl::OUStringHash, std::equal_to<rtl::OUString>, std::allocator<std::pair<rtl::OUString const, com::sun::star::uno::Any> > >::find(rtl::OUString const&) const (this=0x7fffffffdb90, k=...) at /home/arc/src/aoo/main/solver/450/unxlngx6.pro/inc/boost/unordered/unordered_map.hpp:1219 #5 0x00007fffed2ae25e in comphelper::SequenceAsHashMap::getUnpackedValueOrDefault<unsigned char>(rtl::OUString const&, unsigned char const&) const (this=0x7fffffffdb90, sKey=..., aDefault=@0x7fffffffd5a0: 1 '\001') at /home/arc/src/aoo/main/solver/450/unxlngx6.pro/inc/comphelper/sequenceashashmap.hxx:278 #6 0x00007fffed2ad4ab in desktop::FirstStart::execute(com::sun::star::uno::Sequence<com::sun::star::beans::NamedValue> const&) (this=0x7fffecc60720, args=...) at /home/arc/src/aoo/main/desktop/source/splash/firststart.cxx:131 #7 0x00007ffff7d0d903 in desktop::Desktop::Main() (this=0x7fffffffde70) at /home/arc/src/aoo/main/desktop/source/app/app.cxx:2035 #8 0x00007ffff56015a1 in ImplSVMain() () at /home/arc/src/aoo/main/instsetoo_native/unxlngx6.pro/Apache_OpenOffice/installed/install/fr/openoffice4/program/libvcl.so #9 0x00007ffff560170a in SVMain() () at /home/arc/src/aoo/main/instsetoo_native/unxlngx6.pro/Apache_OpenOffice/installed/install/fr/openoffice4/program/libvcl.so #10 0x00007ffff7d4287b in soffice_main() () at /home/arc/src/aoo/main/desktop/source/app/sofficemain.cxx:45 #11 0x0000555555556259 in sal_main () at main.c:31 #12 0x000055555555623e in main (argc=1, argv=0x7fffffffe018) at main.c:30 Hoping for a fix. Thanks.
Which distro is used?
(In reply to oooforum (fr) from comment #1) > Which distro is used? Arch Linux fully updated. gcc 10.2 make 4.3 Downgrading gcc to 10.1 does not help. Sorry for missing this info.
(In reply to SET from comment #0) > At commit 49cc8443e2a, AOO will crash on start. This refers to: https://github.com/apache/openoffice/commit/49cc8443e2aaa7c02ddd1611e7be852fd90266a6 ?
(In reply to Matthias Seidel from comment #3) > This refers to: > > https://github.com/apache/openoffice/commit/ > 49cc8443e2aaa7c02ddd1611e7be852fd90266a6 > > ? The above commit in epm seems to concern Debian packaging only. I specified '--with-package-format=installed' during configuration and files are laid out in 'main/instsetoo_native/unxlngx6.pro/Apache_OpenOffice/installed/install' where I start a test run. Perhaps 'installed' is no longer a parameter for '--with-package-format' since epm 5.0. Trying with '--with-package-format=normal'. Would be quite weird if a crash is related to this.
I ask again: With "At commit 49cc8443e2a" do you refer to this commit?
(In reply to Matthias Seidel from comment #5) > I ask again: > > With "At commit 49cc8443e2a" do you refer to this commit? Yes. $ git rev-parse HEAD 49cc8443e2aaa7c02ddd1611e7be852fd90266a6 (It concerns AOO git repo, not epm as I mistakenly thought of.)
I am somewhat confused by this bug report. The version noted is 4.2.0-dev but the code dumps refer to solver 450 (ie, version 4.5.0, which is trunk). Also the commit message refers to a patch that just affects the dpkg creation. How this would cause a boost core dump is unfathomable. Will look into the 'with-package-format=installed' code paths but I wonder if the person can confirm that by reverting that single commit, that things work as expected (no core dump)
Jim, there was no 4.5.0-dev available. I just created the version and did the change. Maybe it has to do with the combination of the configure switches? Does --with-epm=internal --with-epm-url=https://github.com/jimjag/epm/archive/v5.0.0/epm-5.0.0.tar.gz make sense?
I am even more confused now :) Who did the build? Where did the build come from? What does "I just created the version and did the change." mean? What version did you create? What change did you do? Furthermore, comment 6 has: Yes. $ git rev-parse HEAD 49cc8443e2aaa7c02ddd1611e7be852fd90266a6 (It concerns AOO git repo, not epm as I mistakenly thought of.) but the commit does NOT concern the AOO git repo, so is the commit hash the right one? Or does it mean that the orig bug reporter thought that the commit was FOR the EPM codebase and sees now that it was for AOO?
(In reply to Jim Jagielski from comment #9) > I am even more confused now :) > > Who did the build? Where did the build come from? What does "I just created > the version and did the change." mean? What version did you create? What > change did you do? Jim, Bugzilla had no 4.5.0-dev available, so he had 4.2.0-dev as only option. I just created the version 4.5.0-dev *in Bugzilla* and changed the version of this ticket. I hope that clears it. Matthias
(In reply to Jim Jagielski from comment #9) > I am even more confused now :) > > Who did the build? The reporter ! >Where did the build come from? The reporter's machine. > but the commit does NOT concern the AOO git repo, https://github.com/apache/openoffice/commit/49cc8443e2aaa7c02ddd1611e7be852fd90266a6 does not seem to come from elsewhere but from AOO repo. >so is the commit hash the right one? Yes >Or does it mean that the orig bug reporter thought that the >commit was FOR the EPM codebase and sees now that it was for AOO? Yes, that was the case, and the substance of the clarification in #6. All this is irrelevant. I doubt the issue is related to packaging. It happened that the last commit in my local repo after 'git pull' was yours. This didn't imply that your commit introduced a bug. On the contrary, EPM works great.
Build at commit bb6d2bd0f7e2 results in same failure, which is prior to commit 49cc8443e2. So we can rule out Jim's excellent work that is not related to this malfunction. Let's hope it can be fixed. Post https://bz.apache.org/ooo/show_bug.cgi?id=127569 suggests upgrading boost to > 1.65 so as to be able to use system boost. That's big work, perhaps a solution. Anyway, reporting bugs is always a good idea.
Thx for the info! What was the commit of the previous build that *did* work? We can then try to narrow down the range of commits that may have caused the problem.
(In reply to Jim Jagielski from comment #13) > Thx for the info! What was the commit of the previous build that *did* work? > We can then try to narrow down the range of commits that may have caused the > problem. Unfortunately I don't keep track of last commits after successful builds. My last build was on May 24, so it must be between 7f3d5d1d1e5 and cc6648e8b0b. Please refer to https://bz.apache.org/ooo/show_bug.cgi?id=128373 where the above commit interval can be deduced.
Hello, SET, maybe you could retry with a fresh checkout of the sources. Or, as a quicker alternative: 1- run "dmake clean" 2- delete any directory named "unxlngx6.pro" across your source tree. And then repeat configure, bootstrap and build. I hope this helps.
(In reply to Arrigo Marchiori from comment #15) > Or, as a quicker alternative: > 1- run "dmake clean" > 2- delete any directory named "unxlngx6.pro" across your source tree. I already did that many times, at many commits : nothing does. Recompiling at 49cc8443e2a still yields a usable app. I'll end up bisecting probably. Quite a long process.
Does the problem occur with these builds? o http://home.apache.org/~jim/AOO-builds/Dev/
(In reply to Jim Jagielski from comment #17) > Does the problem occur with these builds? > > o http://home.apache.org/~jim/AOO-builds/Dev/ No, the fr download runs fine.
Figured out what the problem was. I used to build with --std=c++14 in CXXFLAGS. 5f3b9f77916 (Aug 23) started enforcing gnu++98 for Linux builds. I suppose binaries were built with different standards, leading to some kind of incompatibility. After removing --std=c++14 in CXXFLAGS, AOO trunk builds and runs flawlessly. This thread has at least the minimal value of what one should not do since 5f3b9f77916. Regards.
Hit SET, For reference on backgrounds why the 98 standard has been set: https://github.com/apache/openoffice/pull/93 All the Best Peter
I close this as not an issue, in the sense that currently we are on 98 code standard and we havbe to think on an update path, which works for 98 and later. See discussion in the PR.