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

 
 

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

Submitter:  Mike Miller <mtmiller>
Submitted:  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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 29 Mar 2023 07:42:48 PM UTC, comment #11: 

As an update on the GCC side, it'd appear that this check might be valid:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107538#c3

Arsen Arsenović <arsen>
Sun 06 Nov 2022 11:37:48 AM UTC, comment #10: 

Well. I'm not certain if my sole opinion can be called a "consensus". 😉
But I appreciate having this brought up upstream. 👍

It's probably ok to keep this report open in case the libstdc++ developers think that downstream code should be handling this case instead.
And even if this is confirmed to be an upstream bug, we could keep this open as a pointer for anyone running across the same issue.

Markus Mützel <mmuetzel>
Group administrator
Sat 05 Nov 2022 10:24:47 PM UTC, comment #9: 

The consensus seems to be that it's likely a libstdc++ bug but nobody reported it to them? ;)

Anyway, I spoke to jwakley and he kindly did it at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107538.

Sam James <thesamesam>
Sat 05 Nov 2022 11:03:38 AM UTC, comment #8: 

Came here from bug #63318.

Shouldn't all of these not throw an error nor abort according to the standard documentation?
I haven't dug into the standard documentation itself. But if I understand its summary on cppreference correctly, those are valid calls to `std::pow` (and should return NaN for IEEE floating point numbers):
https://en.cppreference.com/w/cpp/numeric/complex/pow

> Errors and special cases are handled as if the operation is implemented by std::exp(y*std::log(x))


Neither `std::exp` nor `std::log` should be aborting for any input iiuc.

The summary for `std::polar` says the following:
https://en.cppreference.com/w/cpp/numeric/complex/polar

> The behavior is undefined if r is negative or NaN, or if theta is infinite.


So, it is conform with the standard if that function aborts. But we don't call that function in our code. And the standard doesn't mention that calling `std::pow` might inherit the behavior of `std::polar` afaict.

Does defining `_GLIBCXX_ASSERTIONS=1` mean that the implementation no longer follows the C++ standard? Do we want to support those non-conforming configurations (if an easy work-around is to not define that constant)?
This sound like a bug in libstdc++ to me. (But I could be wrong.)

Markus Mützel <mmuetzel>
Group administrator
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>
Group Member
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>
Group Member
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>
Group 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>
Group 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>
Group Member

 

(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

Digest:
   bug dependencies.

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-05 mmuetzel Dependencies- bugs #63318 is dependent
    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.13-599c.
    Corresponding source code