Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Possible undefined behavior division by zero in complex's _Py_c_pow() #113841

Open
gpshead opened this issue Jan 9, 2024 · 7 comments
Open

Possible undefined behavior division by zero in complex's _Py_c_pow() #113841

gpshead opened this issue Jan 9, 2024 · 7 comments
Labels
3.11 bug and security fixes 3.12 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@gpshead
Copy link
Member

gpshead commented Jan 9, 2024 •
edited by github-actions bot

Bug report

Bug description:

https://github.com/python/cpython/blob/main/Objects/complexobject.c#L150 _Py_c_pow() contains:

        at = atan2(a.imag, a.real);
        phase = at*b.real;
        if (b.imag != 0.0) {
            len /= exp(at*b.imag);

An oss-fuzz pycompiler fuzzer identified a problem compiling the code " 9J**33J**3" within the optimizer folding the constant by doing the math in place. We haven't been able to reproduce this ourselves - but code inspection reveals a potential problem:

C exp(x) can return 0 in a couple of cases. Which would lead to the /= executing an undefined division by zero operation.

I believe the correct _Py_c_pow() code should look something like:

        if (b.imag != 0.0) {
            double tmp_exp = exp(at*b.imag);
            if (exp == 0.0 || errno == ERANGE) {
                // Detected as OverflowError by our caller.
                r.real = Py_HUGE_VAL;
                r.imag = Py_HUGE_VAL;
                return r;
            }
            len /= tmp_exp;

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux
@gpshead gpshead added type-bug An unexpected behavior, bug, or error interpreter-core (Objects, Python, Grammar, and Parser dirs) 3.11 bug and security fixes 3.12 bugs and security fixes labels Jan 9, 2024
@serhiy-storchaka
Copy link
Member

serhiy-storchaka commented Jan 9, 2024 •
edited

Why not use multiplication instead of division?

@gpshead
Copy link
Member Author

gpshead commented Jan 9, 2024

The complex object code has been this way since it was added 28 years ago. f9fca92 😅 and may have come from @khinsen.

For floating point things, it is often worth figuring out how error accumulates along the way in the computation to minimize loss. I haven't given the algorithm here any thought or looked up alternatives. My proposal is a mere edit that'd keep it the same with an added check in the middle.

@gpshead
Copy link
Member Author

gpshead commented Jan 9, 2024

Also of note since complexobject.c was written... C99 added a complex double type and among the functions available for use with that is cpow()...

@gpshead
Copy link
Member Author

gpshead commented Jan 9, 2024 •
edited

which may be less trivial to use because visual studio support appears to be partial? https://developercommunity.visualstudio.com/t/support-for-c99-complex-numbers/1409049
->
https://learn.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support?view=msvc-170

@khinsen
Copy link

khinsen commented Jan 9, 2024

Yes, that was me who contributed the complex object to CPython. All the algorithms were taken from C code snippets floating around in my environment - version control hadn't arrived in computational science yet! Since then, not only the C language has evolved, but also the optimization habits of C compilers. I wouldn't waste much effort figuring out why pow was implemented this way. It's more productive to consider how best to implement pow in today's C ecosystem.

@serhiy-storchaka
Copy link
Member

I think that the result should be NaN if exp == 0.0 && len == 0.0.

Also, should not errno == ERANGE give zero or NaN, depending on len, as result?

@serhiy-storchaka
Copy link
Member

cc @mdickinson

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
3.11 bug and security fixes 3.12 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gpshead @khinsen @serhiy-storchaka