bugGNU Octave - Bugs: bug #55547, libstdc++ assertion failure when...

 
 

bug #55547: libstdc++ assertion failure when built with -D_GLIBCXX_ASSERTIONS=1

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Wed 23 Jan 2019 12:54:52 AM UTC  
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Wed 23 Jan 2019 08:03:47 PM UTC, comment #7: 

I confirm crash in those two cases as well.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Jan 2019 07:23:25 PM UTC, comment #6: 

Ok, I agree with Dmitri's finding that 'x^10' does not trigger the assertion, but if the exponent is not an integer, it does:

>> 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


>> (NaN*1i) .^ pi
/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

Mike Miller <mtmiller>
Project Administrator
Wed 23 Jan 2019 06:28:10 PM UTC, comment #5: 

I agree we can take our time doing this correctly and thoroughly on the default branch.

I will make another build with this and do some tests. I believe I had examples that worked with a complex NaN in either the base or exponent, but maybe it was exponent only.

The relevant C++ functions are the 'std::pow' overrides that take mixed complex/non-complex arguments, both 'std::pow(const T&, const std::complex<T>&)' and 'std::pow(const std::complex<T>&, const T&)' call 'std::polar', which may trigger this assertion. Octave does not call 'std::polar' directly anywhere.

There are other calls to 'std::pow' sprinkled throughout Octave's code base, especially in some of the audio and graphics functions, but they are probably much less likely to be passing a complex NaN argument.

Mike Miller <mtmiller>
Project Administrator
Wed 23 Jan 2019 05:35:07 PM UTC, comment #4: 

It is fine as well:


octave:1> x = complex (NaN, 1);
octave:2> x^10
ans =  NaN + NaNi

Disclaimer -- this binary compiled with full set of
fedora's flags, not just GLIBCXX_ASSERTIONS


octave:1> __octave_config_info__ ("CXXFLAGS")
ans = -O2 -mtune=generic -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -Wl,--as-needed -fexceptions -fstack-protector-strong -grecord-gcc-switches

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Jan 2019 05:22:04 PM UTC, comment #3: 

Okay, what about

x = complex (NaN, 1);
x^10

Rik <rik5>
Project Administrator
Wed 23 Jan 2019 05:09:17 PM UTC, comment #2: 

Both of those are fine on octave compiled with GLIBCXX_ASSERTIONS


octave:1> 10^nan
ans =  NaN
octave:2> nan^10
ans =  NaN
octave:3> 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 (core dumped)

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 23 Jan 2019 05:00:12 PM UTC, comment #1: 

I suggest that this work be done on the development branch first, and grafted on to stable if it works correctly.  The change is likely to be deep in liboctave which might be too disruptive just before a release.

The obvious way to implement this is to check for NaN at the innermost loop of the power operator.  That will incur a penalty that most systems shouldn't have to bear.  The most straightforward approach would be to code this check inside of an #ifdef on __GLIBCXX_ASSERTIONS.

@Mike: Do we need to inspect both the base and the exponent or just the exponent?  Which of these code constructs causes the assertion?

## Exponent
10^NaN

## Base
NaN^10

Rik <rik5>
Project Administrator
Wed 23 Jan 2019 12:54:52 AM UTC, original submission:  

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.

Mike Miller <mtmiller>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by opoplawski
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-07 opoplawski Carbon-Copy- => Added opoplawski
    2019-01-23 mtmiller StatusNone => Confirmed
    2019-01-23 mtmiller Carbon-CopyRemoved 80942 => -

    Back to the top


    Powered by Savane 3.5