qucsator crash calling std::polar

[GerryHickman]

When building c++ programs, major distros enable "lightweight" assertions _GLIBCXX_ASSERTIONS. This is to do with code hardening.

qucsator can crash if it calls std::polar with a negative magnitude.

qucs-lib has a library with op-amps; qucs/qucs-lib/library/OpAmps.lib
tl071(TI) has
CCCS:FB1 _net9 _net7 _net99 _cnet0 G="4.715e+06"
CCCS:FB2 _netP_VCC _net7 _net99 _cnet1 G="-5e+06"

note the negative 'G' here

net.cpp
dataset * net::runAnalysis (int &err) {

acsolver.cpp
int acsolver::solve (void) {
void acsolver::calc (acsolver * self) {
c->calcAC // calls virtual function

cccs.cpp
void cccs::calcAC (nr_double_t frequency) {
nr_double_t g = getPropertyDouble ("G");
nr_double_t t = getPropertyDouble ("T");
nr_complex_t r = qucs::polar (1.0 / g, - 2.0 * pi * frequency * t); // CRASH here

[felix-salfelder]

Thanks for the report.

On Fri, Dec 19, 2025 at 08:13:49AM -0800, GerryHickman wrote: When building c++ programs, major distros enable "lightweight" assertions _GLIBCXX_ASSERTIONS. This is to do with code hardening.

Debugging and hardening should be switched off in a production build. The normal procedure for this is to define NDEBUG, and *not* enabling _GLIBCXX_ASSERTIONS. The qucsator build system should deal with this. Given the shape qucsator is in, I do understand why it was done this way. But bad practise is bad practise... see also [1]

qucsator can crash if it calls std::polar with a negative magnitude.

[..]

nr_complex_t r = qucs::polar (1.0 / g, - 2.0 * pi * frequency * t); // CRASH here

qucs::polar needs patching. something between the lines of namespace qucs{ complex polar(double a, double b) { if(a<0){ return -polar(-a, b); }else{ ... } } } (qucsator still needs a maintainer to get any further) [1] https://www.gnu.org/software/libc/manual/html_node/Consistency-Checking.html

[GerryHickman]

First Paragraph, note where it says "production code".

https://gcc.gnu.org/wiki/LibstdcxxDebugMode

I don't know who is right or wrong, but the idea is that it hardens production code, such that a bad actor finds it harder to pass bad data into a C++ program.

The code example is helpful where you show checking for minus 'a', but I don't fully understand it, I think it's saying change the sign of both the magnitude and then the result? Would it be possible to show it in the actual qucsator function so I can make a patch?

[felix-salfelder]

On Sat, Dec 20, 2025 at 03:01:58AM -0800, GerryHickman wrote: The code example is helpful where you show checking for minus 'a', but I don't fully understand it, I think it's saying change the sign of both the magnitude and then the result? Would it be possible to show it in the actual qucsator function so I can make a patch?

For an angle phi, the function f(x) = std::polar(x , phi) is supposedly linear. In particular, we should have a * f(x) = f(a * x) for real a. Now the standard requires nonnegative 'x' for a reason I do not know, but see [1]. The workaround is to use the equality above, with a = -1. This is a wild guess and needs testing e.g. with your example. I have not looked into Qucsator code in a while. If you share a test, I could add it to the Gnucsator test suite and compare numerical results. [1] https://en.cppreference.com/w/cpp/numeric/complex/polar

[GerryHickman]

Here's my attempt to folow the instructions, it does not crash anymore.

nr_complex_t polar (const nr_double_t mag, const nr_double_t ang )
{
#ifdef HAVE_CXX_COMPLEX_POLAR
    if (mag < 0) {
        return -(std::polar (-mag, ang));
    } else {
        return std::polar (mag, ang);
    }
#else
    if (mag < 0) {
        return -(nr_complex_t (-mag * cos (ang), -mag * sin (ang)));
    } else {
        return nr_complex_t (mag * cos (ang), mag * sin (ang));
    }
#endif
}

[felix-salfelder]

On Sat, Dec 20, 2025 at 05:52:51AM -0800, GerryHickman wrote: if (mag < 0) { return -(std::polar (-mag, ang)); } else { return std::polar (mag, ang); }

Thanks for trying. I had these thoughts (in this order). - How about just mag*std::polar(1., ang)? (*) - std::polar restricts the radius. It could as well restrict the angle (but does not). I can argue that negative angles are not needed! - The standard polar definition simply makes no sense. - Nor does enabling the "weak assertion". How did we get into this mess again? - If qucs::polar is not meant to work for all radii and angles, then I do not see why std::polar has been put in. - Perhaps they did not know that std::polar is broken. Or it wasn't broken at the time. - Just remove the HAVE_CXX_COMPLEX_POLAR case and call it a day (**). - (reiterate/revert if somebody cares to fix std::polar) I will merge either (*) or (**) provided you share a test. For the record, (**) is identical to glib, except for the assertion: """ template<typename _Tp> inline complex<_Tp> polar(const _Tp& __rho, const _Tp& __theta) { __glibcxx_assert( __rho >= 0 ); return complex<_Tp>(__rho * cos(__theta), __rho * sin(__theta)); } """

[GerryHickman]

I'm happy for either of those to be merged.

The only test I have is from the original post above:

qucs-lib has a library with op-amps; qucs/qucs-lib/library/OpAmps.lib
tl071(TI) has
CCCS:FB1 _net9 _net7 _net99 _cnet0 G="4.715e+06"
CCCS:FB2 _netP_VCC _net7 _net99 _cnet1 G="-5e+06"

I noticed that when qucsator is processing CCCS, the FB1 with positive 'G' works, but when it gets to FB2, the magnitide goes negative and causes the glib version of polar to assert.