php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #55712 FastCGI causes event 1000 application error when using number_format(0)
Submitted: 2011-09-16 16:28 UTC Modified: 2019-09-22 04:22 UTC
Votes:14
Avg. Score:4.4 ± 0.9
Reproduced:11 of 12 (91.7%)
Same Version:10 (90.9%)
Same OS:9 (81.8%)
From: ken at simplecommerce dot com Assigned: cmb (profile)
Status: No Feedback Package: IIS related
PHP Version: 5.3.8 OS: Windows server 2008 R2
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: ken at simplecommerce dot com
New email:
PHP Version: OS:

 

 [2011-09-16 16:28 UTC] ken at simplecommerce dot com 
Description:
------------
We installed PHP 5.3.8 using the windows installer from microsoft and set the configuration according to the recommended settings for IIS 7.

http://www.microsoft.com/web/platform/phponwindows.aspx

We have a simple script that echo number_format(0); 
When accessing that script, and refreshing a couple of times, we get an error 500.

We also have another script which does the same but has a query to an ODBC link. 
Whenever we use both at the same time, the 500 error occurs frequently, every 2 refreshes. 

We also, made sure that no script errors appear in the logs we have saved to the windows temp dir and in fact none appear, to be sure it was working properly we made simple errors to test and it was in fact writing properly to the log files.

Test script:
---------------
<?php
// works alone / doesn't work when both used with odbc acomba
echo number_format(0).'<br />';

// acomba
$odbc_link = odbc_connect('', '', '');

$result = odbc_exec($odbc_link,"SELECT PrActive AS actif, PrNumber AS code_produit, PrDescription1 AS desc_f, PrDescription2 AS desc_e, PrComments AS commentaire, PrProductGroupCP AS id_produits_groupes, PrTaxExceptionCP AS id_tax_exception, PrSellingPrice0_1 AS prix_membre_individuel, PrSellingPrice0_2 AS prix_membre_couple, PrSellingPrice0_3 AS prix_membre_famille, PrSellingPrice0_4 AS prix_membre_enfants, PrSellingPrice0_5 AS prix_non_membre, RecCardPos AS id_produits_acomba FROM Product") or die(odbc_errormsg($odbc_link));

if (odbc_num_rows($result)) { 		
	while ($row = odbc_fetch_array($result)) {
		print_r($row);
		exit;
	}
}
?>

Expected result:
----------------
The script should run and not cause a 500 error.

Actual result:
--------------
Here is the event details that is given on the crash.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" /> 
<EventID Qualifiers="0">1000</EventID> 
<Level>2</Level> 
<Task>100</Task> 
<Keywords>0x80000000000000</Keywords> 
<TimeCreated SystemTime="2011-09-15T22:37:50.000000000Z" /> 
<EventRecordID>5414</EventRecordID> 
<Channel>Application</Channel> 
<Computer>svrweb.intranet.local</Computer> 
<Security /> 
</System>
<EventData>
<Data>php-cgi.exe</Data> 
<Data>5.3.8.0</Data> 
<Data>4e537f4b</Data> 
<Data>KERNELBASE.dll</Data> 
<Data>6.1.7600.16385</Data> 
<Data>4a5bdbdf</Data> 
<Data>c000008e</Data> 
<Data>0000b727</Data> 
<Data>9b4</Data> 
<Data>01cc73f7f2b1da31</Data> 
<Data>C:\Program Files (x86)\PHP\v5.3\php-cgi.exe</Data> 
<Data>C:\Windows\syswow64\KERNELBASE.dll</Data> 
<Data>5773289d-dfeb-11e0-99e3-bc305bd47266</Data> 
</EventData>
</Event>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-09-16 16:34 UTC] pajoye@php.net
-Status: Open +Status: Feedback
 [2011-09-16 16:34 UTC] pajoye@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.
 [2011-09-16 16:42 UTC] ken at simplecommerce dot com
-Status: Feedback +Status: Open
 [2011-09-16 16:42 UTC] ken at simplecommerce dot com 
Hi,

The test script I have provided is infact the same one I am using.
The only thing I removed was the login information. 
The database I am using is Acomba which is a accounting software.
I have the same setup on PHP 5.2.13 which works flawlessly, except for the number errors that we are getting ".:" which seems to be fixed in the latest version of PHP. 

Also, the error occurs when using this simple script:

<?php echo number_format(0); ?>

The only difference is that it occurs less frequently than the other script which queries a database.

I have tried everything I could find online about IIS7 and 500 error messages.
Setup the fastcgi settings like it was mentionned. 
Even used the windows installer which is supposed to do it all for you.

No php error is returned to the logs, always the 500 on the browser every 2 refreshes if you account for the ODBC link, if not, it happens once in a while.

The issue, is that our application uses number format and the ODBC link intensively, so we need to get the 500 error resolved or at least need to figure out what is causing it.

I do know that when running the same scripts using command line, I do not get the 500 error but running it in the webpage I do.

Also, when switching from fastcgi to cgi, the error does not occur, but other problems arises, like 502 errors.

Oh and to add, we also tried 5.3.6 at first, and get the same event errors, talking about php-cgi.exe and kernelbase.dll.
 [2011-09-18 11:48 UTC] ken at simplecommerce dot com 
We just tried updating the windows server 2008 R2 with all updates to make sure that none of the updates missing we're part of the problem.
The error still occurs.
 [2011-09-18 13:38 UTC] ken at simplecommerce dot com 
I also tried the following:

<?php
echo "Number Format:" . number_format(0.00,2) . '<br />';
echo sprintf("%01.2f", 0).'<br />';
?>

The 2nd one works fine when used with my database query.
But number format causes an error. 
Number format works with 0.01 but not 0 or 0.00.

It is really weird.
 [2011-09-18 15:19 UTC] ken at simplecommerce dot com 
I just wanted to add that I opened up a thread on iis.net forum to see if I Can get assistance on that end also.

http://forums.iis.net/p/1181683/1996258.aspx

I am desperately trying to find a fix to this issue.
 [2011-09-18 15:29 UTC] pajoye@php.net 
I would go with intl, see http://www.php.net/manual/en/class.numberformatter.php

number_format depends on the system API and can be very buggie.
 [2011-09-18 17:11 UTC] ken at simplecommerce dot com 
Thanks for the link.
It is a good alternative, but if possible I would prefer a solution to my current problem without having to go through all my files and re-code using this new method.
 [2011-09-18 17:57 UTC] ken at simplecommerce dot com 
I have used Debug Diag 1.2 to create a crash hang report on the php-cgi.exe process.

Here is the result I have got from the analysis.
If it can help figure out if this is indeed a bug or it's something else.
I am trying to narrow it down to get a possible fix.

http://www.mediafire.com/?ezxjt68v0axozif
 [2011-09-23 11:23 UTC] ken at simplecommerce dot com 
Ok so we had a local expert go through the debugging and see if he could find anything wrong with our setup, and from what he tells me, it really is number_format(0) that seems to crash the IIS7/FastCGI server with a 500 error.
 [2011-09-25 21:31 UTC] ken at simplecommerce dot com 
Here is an update.
We made our own function to bypass number_format.
We found another error which causes php fastcgi to crash.

round(0).

I am assuming that number_format uses round?
So we are bypassing round for the moment to see if we encounter any other problems.

But right now both number_format and round 0 crashes.
I hope you guys are aware of this or are testing this also.
 [2011-09-25 21:37 UTC] pajoye@php.net
-Assigned To: +Assigned To: mattficken
 [2011-09-25 21:37 UTC] pajoye@php.net 
Matt, please take the hand here.
 [2011-10-18 21:42 UTC] ken at simplecommerce dot com 
Any update on this issue?
 [2011-10-19 17:12 UTC] pajoye@php.net
-Status: Assigned +Status: Feedback
 [2011-10-19 17:12 UTC] pajoye@php.net 
hi,

We cannot reproduce this crash in any way. Using round(0) or number_format, 
using 0 or any other kind of random values.

Please provide a self contained script (aka no DB usage, but only using 
number_format and round) to reproduce this crash.
 [2011-10-19 17:25 UTC] ken at simplecommerce dot com 
Hi,

Did you guys take a look at the diagnostic report I had included to see if any of the information was relevant enough for you guys to discern where the problem was?

Also, as I had mentioned before, the error arises more often when I use number_format or round 0 in a script that makes calls to an ODBC link to a accounting database called Acomba. 

But the error also arises when using number_format or round 0 in a script alone with nothing else. But the problem does not error as frequently as the other scenario with the database link.

Did you guys try to reproduce the error using the same environment?

I also tried with a windows 7 workstation with IIS 7/FastCGI and that ODBC link and was having the issue also.
 [2011-10-19 17:25 UTC] ken at simplecommerce dot com
-Status: Feedback +Status: Assigned
 [2017-10-24 06:43 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: mattficken +Assigned To:
 [2019-09-13 10:38 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2019-09-13 10:38 UTC] cmb@php.net 
Can anybody still reproduce this with any of the supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2019-09-22 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 21 12:01:31 2024 UTC