Bug 234201 - Regression in LLVM libunwind: Apache Tomcat web application crashes on 12.0 (but not on 11.2)
Summary: Regression in LLVM libunwind: Apache Tomcat web application crashes on 12.0 (...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-toolchain mailing list
URL:
Keywords: crash, regression, toolchain
Depends on:
Blocks:
 
Reported: 2018-12-20 09:19 UTC by Marie Helene Kvello-Aune
Modified: 2019-01-10 22:22 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marie Helene Kvello-Aune 2018-12-20 09:19:54 UTC
When the port devel/jakarta-commons-daemon is built with LLVM in base on 12.0-RELEASE (default configuration), our tomcat webapp "coffeehouse" fails with the message "libunwind: getEncodedP /usr/src/contrib/llvm/projects/libunwind/src/AddressSpace.hpp:280 - unknown pointer encoding"

The offending section of code:
(...)
inline LocalAddressSpace::pint_t
LocalAddressSpace::getEncodedP(pint_t &addr, pint_t end, uint8_t encoding,
                               pint_t datarelBase) {
(...)
 switch (encoding & 0x0F) {
(...)
  default:
    _LIBUNWIND_ABORT("unknown pointer encoding");
(...)

This error does not occur when the port is built with GCC, nor when it's built & run on 11.2 (it works fine with 11.2 world on top of 12.0 kernel).

We've applied a workaround internally which builds it with GCC, but think the correct approach is to fix the regression in base, so that we won't pull in GCC8 just for this.

The web application can be provided upon request.
Comment 1 Dimitry Andric freebsd_committer 2018-12-20 19:43:57 UTC
Hm, the problem is to figure out what the value of 'encoding' is at that point.  In libunwind trunk I see no change in the getEncodedP() function, so it's definitely not supported by a newer version of libunwind either.

Another possibility is that the unwind information gets mangled somehow (maybe by the linker, or by stripping?) causing libunwind to become confused.

Ed, any ideas?
Comment 2 David Chisnall freebsd_committer 2018-12-21 10:37:10 UTC
When I looked at that code a couple of years back, I seem to recall that not all of the DWARF encodings were supported.  I believe only the ones that LLVM emits are well tested (I also vaguely remember adding a couple that were missing in the CHERI branch).  The good news is that they're all pretty trivial (value plus some base address), so if someone can figure out what the value of `encoding` is in the failing case, I can probably give you a patch to fix it quite easily.