#34832 [Opn-Fbk]: sprintf not reentrant
ID: 34832 Updated by: [EMAIL PROTECTED] Reported By: jdolecek at NetBSD dot org -Status: Open +Status: Feedback Bug Type: Strings related Operating System: Windows 2000 PHP Version: 5CVS-2005-10-17 (snap) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Previous Comments: [2007-01-18 09:01:12] jdolecek at NetBSD dot org (non content related, just editing submissing e-mail) [2005-11-10 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-11-02 13:26:07] [EMAIL PROTECTED] Yes, and now please read the comment. I asked for short but complete script..and not some huge package. [2005-11-01 17:15:24] dolecek at stringdata dot cz Reproducing script already provided in previous feedback. [2005-11-01 11:43:44] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/34832 -- Edit this bug report at http://bugs.php.net/?id=34832edit=1
#34832 [Opn-Fbk]: sprintf not reentrant
ID: 34832
Updated by: [EMAIL PROTECTED]
Reported By: dolecek at stringdata dot cz
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: Windows 2000
PHP Version: 5CVS-2005-10-17 (snap)
New Comment:
Yes, and now please read the comment. I asked for short but complete
script..and not some huge package.
Previous Comments:
[2005-11-01 17:15:24] dolecek at stringdata dot cz
Reproducing script already provided in previous feedback.
[2005-11-01 11:43:44] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-10-17 09:56:24] dolecek at stringdata dot cz
Tested with php5.1-win32-200510170630 and php5.0-win32-200510170030.
PHP 5.1 crashes Apache after several seconds of running the test. PHP
5.0.6-dev doesn't crash, but still exhibits the problem. Thus, the
problem is not fixed in snapshot.
[2005-10-12 12:07:00] dolecek at stringdata dot cz
Reproduce steps:
1. download FPDF 1.53 (fpdf153.zip), extract to suitable directory
accessible via web server
2. edit fpdf.php and replace line:
$this-_out('/CreationDate '.$this-_textstring('D:'.date('YmdHis')));
with:
$this-_out('/CreationDate '.$this-_textstring('D:20051011143910'));
This is necessary so that generated PDF don't differ gratuitously.
2. put attached script to the same directory as the modified fpdf.php
3. run:
siege -c 10 -v -u http://server/path/to/script.php
The script:
$pdf=new FPDF();
$pdf-AddPage();
$pdf-SetFont('Arial','B',16);
$pdf-Cell(40,10,'Hello World!');
$pdf-SetFont('Arial','',10);
$pdf-Cell(60,10,'Powered by FPDF.',0,1,'C');
$content = $pdf-Output(false, 'S');
if (md5($content) != '38ec5b17d2cda871e21b28ecaeecd08d') {
trigger_error('pdf generation test bug', E_USER_ERROR);
}
[2005-10-11 17:31:41] dolecek at stringdata dot cz
Description:
I'm using PHP with Apache 1.3.23 via apache module, using windows PHP
binaries downloaded from php.net.
If several parallelly running scripts execute same blocks of code using
sprintf(%.2f, $somefloat*$otherfloat), occassionally incorrect float
number is printed or even one character of the float contains binary
NUL.
Easy way to trigger this is to have a FPDF script generating a PDF
document, and have something which calls this script via web request in
parallel, so that all scripts are executed within the context of single
web server process. The problem appears in about 1% of generated
documents. The problem is repeatably in my environment, I can try to
put together simplier version of reproducing script if need be.
If I replace the above contruct with
number_format($somefloat*$otherfloat, 2, '.', ''), it works without
problem and no problem occurs.
The length of the gardbled output always exactly matches the length of
non-gardbled output, FWIW.
This suggests there is some kind of reentrancy problem with the
sprintf() routine, at least when printing floats. Perhaps some stack
alignment issue or something equally esoteric?
The problem exists in 5.1b3, 5.1.0rc1, 5.0.5. I did not check other
versions.
The type of bug has been set to repoducible crash due to missing
'Memory corruption' category and since this _might_ cause a crash (tho
no crash has been observed) - feel free to change to anything more
appropriate if need be.
Bug #21659 might actually be same problem, tho #21659 has been shrugged
off as miscompilation problem.
--
Edit this bug report at http://bugs.php.net/?id=34832edit=1
#34832 [Opn-Fbk]: sprintf not reentrant
ID: 34832
Updated by: [EMAIL PROTECTED]
Reported By: dolecek at stringdata dot cz
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: Windows 2000
PHP Version: 5CVS-2005-10-17 (snap)
New Comment:
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2005-10-17 09:56:24] dolecek at stringdata dot cz
Tested with php5.1-win32-200510170630 and php5.0-win32-200510170030.
PHP 5.1 crashes Apache after several seconds of running the test. PHP
5.0.6-dev doesn't crash, but still exhibits the problem. Thus, the
problem is not fixed in snapshot.
[2005-10-12 12:07:00] dolecek at stringdata dot cz
Reproduce steps:
1. download FPDF 1.53 (fpdf153.zip), extract to suitable directory
accessible via web server
2. edit fpdf.php and replace line:
$this-_out('/CreationDate '.$this-_textstring('D:'.date('YmdHis')));
with:
$this-_out('/CreationDate '.$this-_textstring('D:20051011143910'));
This is necessary so that generated PDF don't differ gratuitously.
2. put attached script to the same directory as the modified fpdf.php
3. run:
siege -c 10 -v -u http://server/path/to/script.php
The script:
$pdf=new FPDF();
$pdf-AddPage();
$pdf-SetFont('Arial','B',16);
$pdf-Cell(40,10,'Hello World!');
$pdf-SetFont('Arial','',10);
$pdf-Cell(60,10,'Powered by FPDF.',0,1,'C');
$content = $pdf-Output(false, 'S');
if (md5($content) != '38ec5b17d2cda871e21b28ecaeecd08d') {
trigger_error('pdf generation test bug', E_USER_ERROR);
}
[2005-10-11 17:31:41] dolecek at stringdata dot cz
Description:
I'm using PHP with Apache 1.3.23 via apache module, using windows PHP
binaries downloaded from php.net.
If several parallelly running scripts execute same blocks of code using
sprintf(%.2f, $somefloat*$otherfloat), occassionally incorrect float
number is printed or even one character of the float contains binary
NUL.
Easy way to trigger this is to have a FPDF script generating a PDF
document, and have something which calls this script via web request in
parallel, so that all scripts are executed within the context of single
web server process. The problem appears in about 1% of generated
documents. The problem is repeatably in my environment, I can try to
put together simplier version of reproducing script if need be.
If I replace the above contruct with
number_format($somefloat*$otherfloat, 2, '.', ''), it works without
problem and no problem occurs.
The length of the gardbled output always exactly matches the length of
non-gardbled output, FWIW.
This suggests there is some kind of reentrancy problem with the
sprintf() routine, at least when printing floats. Perhaps some stack
alignment issue or something equally esoteric?
The problem exists in 5.1b3, 5.1.0rc1, 5.0.5. I did not check other
versions.
The type of bug has been set to repoducible crash due to missing
'Memory corruption' category and since this _might_ cause a crash (tho
no crash has been observed) - feel free to change to anything more
appropriate if need be.
Bug #21659 might actually be same problem, tho #21659 has been shrugged
off as miscompilation problem.
--
Edit this bug report at http://bugs.php.net/?id=34832edit=1
#34832 [Opn-Fbk]: sprintf not reentrant
ID: 34832
Updated by: [EMAIL PROTECTED]
Reported By: dolecek at stringdata dot cz
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: Windows 2000
PHP Version: 5.0.5
New Comment:
Have you tried the snapshot?
Previous Comments:
[2005-10-12 12:07:00] dolecek at stringdata dot cz
Reproduce steps:
1. download FPDF 1.53 (fpdf153.zip), extract to suitable directory
accessible via web server
2. edit fpdf.php and replace line:
$this-_out('/CreationDate '.$this-_textstring('D:'.date('YmdHis')));
with:
$this-_out('/CreationDate '.$this-_textstring('D:20051011143910'));
This is necessary so that generated PDF don't differ gratuitously.
2. put attached script to the same directory as the modified fpdf.php
3. run:
siege -c 10 -v -u http://server/path/to/script.php
The script:
$pdf=new FPDF();
$pdf-AddPage();
$pdf-SetFont('Arial','B',16);
$pdf-Cell(40,10,'Hello World!');
$pdf-SetFont('Arial','',10);
$pdf-Cell(60,10,'Powered by FPDF.',0,1,'C');
$content = $pdf-Output(false, 'S');
if (md5($content) != '38ec5b17d2cda871e21b28ecaeecd08d') {
trigger_error('pdf generation test bug', E_USER_ERROR);
}
[2005-10-11 17:38:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
And try snapshot first.
[2005-10-11 17:38:24] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-10-11 17:31:41] dolecek at stringdata dot cz
Description:
I'm using PHP with Apache 1.3.23 via apache module, using windows PHP
binaries downloaded from php.net.
If several parallelly running scripts execute same blocks of code using
sprintf(%.2f, $somefloat*$otherfloat), occassionally incorrect float
number is printed or even one character of the float contains binary
NUL.
Easy way to trigger this is to have a FPDF script generating a PDF
document, and have something which calls this script via web request in
parallel, so that all scripts are executed within the context of single
web server process. The problem appears in about 1% of generated
documents. The problem is repeatably in my environment, I can try to
put together simplier version of reproducing script if need be.
If I replace the above contruct with
number_format($somefloat*$otherfloat, 2, '.', ''), it works without
problem and no problem occurs.
The length of the gardbled output always exactly matches the length of
non-gardbled output, FWIW.
This suggests there is some kind of reentrancy problem with the
sprintf() routine, at least when printing floats. Perhaps some stack
alignment issue or something equally esoteric?
The problem exists in 5.1b3, 5.1.0rc1, 5.0.5. I did not check other
versions.
The type of bug has been set to repoducible crash due to missing
'Memory corruption' category and since this _might_ cause a crash (tho
no crash has been observed) - feel free to change to anything more
appropriate if need be.
Bug #21659 might actually be same problem, tho #21659 has been shrugged
off as miscompilation problem.
--
Edit this bug report at http://bugs.php.net/?id=34832edit=1
#34832 [Opn-Fbk]: sprintf not reentrant
ID: 34832
Updated by: [EMAIL PROTECTED]
Reported By: dolecek at stringdata dot cz
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: Windows 2000
PHP Version: 5.0.5
New Comment:
Please reopen the report only when you really try the snapshot.
Previous Comments:
[2005-10-12 12:11:12] dolecek at stringdata dot cz
No, I've only tried PHP 5.1rc1 and 5.0.5 - is there any related change
to php_formatted_print() et.al recently which might likely fix this?
[2005-10-12 12:08:44] [EMAIL PROTECTED]
Have you tried the snapshot?
[2005-10-12 12:07:00] dolecek at stringdata dot cz
Reproduce steps:
1. download FPDF 1.53 (fpdf153.zip), extract to suitable directory
accessible via web server
2. edit fpdf.php and replace line:
$this-_out('/CreationDate '.$this-_textstring('D:'.date('YmdHis')));
with:
$this-_out('/CreationDate '.$this-_textstring('D:20051011143910'));
This is necessary so that generated PDF don't differ gratuitously.
2. put attached script to the same directory as the modified fpdf.php
3. run:
siege -c 10 -v -u http://server/path/to/script.php
The script:
$pdf=new FPDF();
$pdf-AddPage();
$pdf-SetFont('Arial','B',16);
$pdf-Cell(40,10,'Hello World!');
$pdf-SetFont('Arial','',10);
$pdf-Cell(60,10,'Powered by FPDF.',0,1,'C');
$content = $pdf-Output(false, 'S');
if (md5($content) != '38ec5b17d2cda871e21b28ecaeecd08d') {
trigger_error('pdf generation test bug', E_USER_ERROR);
}
[2005-10-11 17:38:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
And try snapshot first.
[2005-10-11 17:38:24] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34832
--
Edit this bug report at http://bugs.php.net/?id=34832edit=1
#34832 [Opn-Fbk]: sprintf not reentrant
ID: 34832 Updated by: [EMAIL PROTECTED] Reported By: dolecek at stringdata dot cz -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: Strings related Operating System: Windows 2000 PHP Version: 5.0.5 New Comment: 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-10-11 17:31:41] dolecek at stringdata dot cz Description: I'm using PHP with Apache 1.3.23 via apache module, using windows PHP binaries downloaded from php.net. If several parallelly running scripts execute same blocks of code using sprintf(%.2f, $somefloat*$otherfloat), occassionally incorrect float number is printed or even one character of the float contains binary NUL. Easy way to trigger this is to have a FPDF script generating a PDF document, and have something which calls this script via web request in parallel, so that all scripts are executed within the context of single web server process. The problem appears in about 1% of generated documents. The problem is repeatably in my environment, I can try to put together simplier version of reproducing script if need be. If I replace the above contruct with number_format($somefloat*$otherfloat, 2, '.', ''), it works without problem and no problem occurs. The length of the gardbled output always exactly matches the length of non-gardbled output, FWIW. This suggests there is some kind of reentrancy problem with the sprintf() routine, at least when printing floats. Perhaps some stack alignment issue or something equally esoteric? The problem exists in 5.1b3, 5.1.0rc1, 5.0.5. I did not check other versions. The type of bug has been set to repoducible crash due to missing 'Memory corruption' category and since this _might_ cause a crash (tho no crash has been observed) - feel free to change to anything more appropriate if need be. Bug #21659 might actually be same problem, tho #21659 has been shrugged off as miscompilation problem. -- Edit this bug report at http://bugs.php.net/?id=34832edit=1
