[Octave-bug-tracker] [bug #55547] libstdc++ assertion failure when built with -D_GLIBCXX_ASSERTIONS=1

[Mike Miller]

URL:
  <https://savannah.gnu.org/bugs/?55547>

                 Summary: libstdc++ assertion failure when built with
-D_GLIBCXX_ASSERTIONS=1
                 Project: GNU Octave
            Submitted by: mtmiller
            Submitted on: Tue 22 Jan 2019 04:54:52 PM PST
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Segfault, Bus Error, etc.
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Octave aborts from an assertion failure in libstdc++ when built with GCC and
the `_GLIBCXX_ASSERTIONS` flag enabled. This option is included by default in
some hardened build environments, including Flatpak and Fedora.

Example:


>> 10 ^ (NaN + 1i)
/usr/include/c++/8/complex:692: std::complex<_Tp> std::polar(const _Tp&, const
_Tp&) [with _Tp = double]: Assertion '__rho >= 0' failed.
fatal: caught signal Aborted -- stopping myself...
Aborted


The correct (Matlab compatible) behavior without this flag enabled is:


>> 10 ^ (NaN + 1i)
ans =  NaN + NaNi
>> 10 ^ (NaN * 1i)
ans =  NaN + NaNi


I'm not sure how common this would be in code in the wild, but this does break
the test suite in logspace.m:


***** assert (logspace (-Inf + 1i, Inf + 1i, 3), [0, NaN + NaN * 1i,
complex(-Inf, Inf)])
/usr/include/c++/8/complex:692: std::complex<_Tp> std::polar(const _Tp&, const
_Tp&) [with _Tp = double]: Assertion '__rho >= 0' failed.
fatal: caught signal Aborted -- stopping myself...
Aborted


Obvious workaround is to not build Octave with this option, but it may be
better to be robust against this check and ensure we don't call std::pow with
a NaN complex argument.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55547>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/