php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68703 bug in action for big numbers
Submitted: 2014-12-31 01:10 UTC Modified: 2015-01-18 04:22 UTC
From: andkos11 at gmail dot com Assigned:
Status: No Feedback Package: BC math related
PHP Version: 5.6.4 OS: Windows
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: andkos11 at gmail dot com
New email:
PHP Version: OS:

 

 [2014-12-31 01:10 UTC] andkos11 at gmail dot com
Description:
------------
When tested bcpowmod, I saw that sometimes it returns wrong results, and only after this functions is twice replaced by the correct result, but this error does not occur every time so I could be a problem to observe it

The number for this wrong result
a = 26876030130522977362132073521581183346181374574161923861784515294359096339790317651642545453710861830,
b = 77317036686803103778936280840587979061852865432165222860201467725250008729818881455247433896121539492,
c = 23419441391667485230412027806848395891480806969028551095494276441653557878516815994557378094191773302

Test script:
---------------
if(!empty($_GET['a']) && !empty($_GET['b']) && !empty($_GET['c']))
{
echo bcpowmod($_GET['a'], $_GET['b'], $_GET['c']);
}

Expected result:
----------------
7900166398097084738516054342209138549045537503223180351418154803251628881304583728795337234416935756

Actual result:
--------------
1214699235616625452989024013318099653900761106780848559004042547497269228234090040172747025.4033420042

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-31 22:01 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2014-12-31 22:01 UTC] ab@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

The script you supply isn't a self enclosed repro case. Thanks.
 [2015-01-01 17:32 UTC] andkos11 at gmail dot com
-Status: Feedback +Status: Open
 [2015-01-01 17:32 UTC] andkos11 at gmail dot com
Test script:
<?php
if(!empty($_GET['a']) && !empty($_GET['b']) && !empty($_GET['c']))
{
echo bcpowmod($_GET['a'], $_GET['b'], $_GET['c']);
}
?>
 [2015-01-09 17:53 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-01-09 17:53 UTC] ab@php.net
@andkos11, this can be hardly called a reproducer as you depend on $_GET. When I rephrase your snippet according to the data you've posted in the description, i se the expected result. See

echo bcpowmod(
"26876030130522977362132073521581183346181374574161923861784515294359096339790317651642545453710861830",
"77317036686803103778936280840587979061852865432165222860201467725250008729818881455247433896121539492",
"23419441391667485230412027806848395891480806969028551095494276441653557878516815994557378094191773302"
);

Please post a self enclosed reproducer or check your code.

Thanks.
 [2015-01-10 14:14 UTC] andkos11 at gmail dot com
-Status: Feedback +Status: Open
 [2015-01-10 14:14 UTC] andkos11 at gmail dot com
Yes, because the result obtained is not always valid.
Tested as in this example, and once receives the expected result, and once there so I decided to report this error. And I sent this example $_GET,because as observed at the beginning on it. I thought it might be really fault this, but after doing:
echo bcpowmod (
"26876030130522977362132073521581183346181374574161923861784515294359096339790317651642545453710861830",
"77317036686803103778936280840587979061852865432165222860201467725250008729818881455247433896121539492",
"23419441391667485230412027806848395891480806969028551095494276441653557878516815994557378094191773302"
);
the result was bad, and after being shown the correct refresh, refreshed so a couple of times a page, and again I received is not correct
 [2015-01-10 14:54 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2015-01-10 14:54 UTC] ab@php.net
Thanks for the update. Unfortunately i still can't reproduce what you're saying. Even running it this way

for ($i = 0; $i < 4; $i++) {
        echo bcpowmod(
        "26876030130522977362132073521581183346181374574161923861784515294359096339790317651642545453710861830",
        "77317036686803103778936280840587979061852865432165222860201467725250008729818881455247433896121539492",
        "23419441391667485230412027806848395891480806969028551095494276441653557878516815994557378094191773302"
        );
        echo "\n";
}

and always seeing 

7900166398097084738516054342209138549045537503223180351418154803251628881304583728795337234416935756
7900166398097084738516054342209138549045537503223180351418154803251628881304583728795337234416935756
7900166398097084738516054342209138549045537503223180351418154803251628881304583728795337234416935756
7900166398097084738516054342209138549045537503223180351418154803251628881304583728795337234416935756

Heh ... even 5.5 and master show no regression on this. Something else you maybe could observe/try, like changing ini, changing something in env, etc.?

Thanks.
 [2015-01-18 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 14 14:01:26 2024 UTC