#47829 [Fbk-Opn]: Segmentation fault on startup with PDO Firebird compiled in
ID: 47829
User updated by: info at programmiernutte dot net
Reported By: info at programmiernutte dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Debian Etch x86_64
PHP Version: 5.3.0RC1
New Comment:
Same thing:
localhost:~/php5.2-200905010630/sapi/cli# ./php
Segmentation fault
gdb trace:
(gdb) run
Starting program: /root/php5.2-200905010630/sapi/cli/php
warning: no loadable sections found in added symbol-file system-
supplied DSO at 0x779fe000
[Thread debugging using libthread_db enabled]
[New Thread 47269144047376 (LWP 16865)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47269144047376 (LWP 16865)]
0x0062c1aa in _zend_hash_add_or_update (ht=0xa8f740,
arKey=0x8bbb92 firebird, nKeyLength=8, pData=0x77995060,
nDataSize=8, pDest=0x0, flag=2) at /root/php5.2-
200905010630/Zend/zend_hash.c:218
218 p = ht-arBuckets[nIndex];
(gdb) where
#0 0x0062c1aa in _zend_hash_add_or_update (ht=0xa8f740,
arKey=0x8bbb92 firebird, nKeyLength=8,
pData=0x77995060, nDataSize=8, pDest=0x0, flag=2) at
/root/php5.2-200905010630/Zend/zend_hash.c:218
#1 0x0052718f in php_pdo_register_driver (driver=0xa661c0) at
/root/php5.2-200905010630/ext/pdo/pdo.c:184
#2 0x005311c0 in zm_startup_pdo_firebird (type=value
optimized out, module_number=9157530)
at /root/php5.2-200905010630/ext/pdo_firebird/pdo_firebird.c:58
#3 0x006257c3 in zend_startup_module_ex (module=0xae52d0) at
/root/php5.2-200905010630/Zend/zend_API.c:1472
#4 0x0062a995 in zend_hash_apply (ht=0xa93bc0,
apply_func=0x6256c0 zend_startup_module_ex)
at /root/php5.2-200905010630/Zend/zend_hash.c:673
#5 0x00623fea in zend_startup_modules () at /root/php5.2-
200905010630/Zend/zend_API.c:1519
#6 0x005deebd in php_module_startup (sf=value optimized
out, additional_modules=0x0, num_additional_modules=0)
at /root/php5.2-200905010630/main/main.c:1843
#7 0x006a171d in php_cli_startup (sapi_module=0x0) at
/root/php5.2-200905010630/sapi/cli/php_cli.c:386
#8 0x006a1e11 in main (argc=1, argv=0x77995688) at
/root/php5.2-200905010630/sapi/cli/php_cli.c:745
Previous Comments:
[2009-04-30 10:48:27] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-29 21:51:51] info at programmiernutte dot net
I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.
[2009-03-29 16:11:42] info at programmiernutte dot net
Description:
I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related?
I used gdb to track this down to PDO Firebird Initialisation Startup:
(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
FB_ATTR_DATE_FORMAT, name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce-type ZEND_INTERNAL_CLASS) {
(gdb) where
#0 zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
FB_ATTR_DATE_FORMAT, name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1 0x005190c2 in zm_startup_pdo_firebird (type=value
optimized out, module_number=value optimized out)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2 0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3 0x00625f05 in zend_hash_apply (ht=0xc62e80,
apply_func=0x61cec0 zend_startup_module_ex)
at /usr/src/php-5.3.0RC1/Zend/zend_hash.c:673
#4 0x0061d89a in zend_startup_modules () at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1642
#5 0x005c827f in php_module_startup (sf=value optimized out,
additional_modules=0x0, num_additional_modules=0)
at /usr/src/php-5.3.0RC1/main/main.c:1952
#6 0x006a0e5d in php_cli_startup (sapi_module=0x0) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:370
#7 0x006a155f in main (argc=1, argv=0x7fff63c23928) at
/usr/src/php-5.3.0RC1/sapi/cli/php_cli.c:742
--
Edit this
#47107 [Bgs]: numbers with more than 15 digits are not behaved normally
ID: 47107
User updated by: mucahitkahveci at gmail dot com
Reported By: mucahitkahveci at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows xp sp2
-PHP Version: 5.2.8
+PHP Version: 5.2.2
New Comment:
I understand that, but isn't it a big problem? Since php supports
integers for maximum value of about two billion (php manual) in which
it than changes to floating point numbers for numbers bigger than this.
So for any value its bigger than 15 digit its a very very big problem
while querying in a database. For example mysql has bigint type which
supports a maximum of 20 digits. But because of this behaviour of php we
have to use only upto 15 digits!! And if someone skips this detail it
would cause problems that is impossible to solve
Thanks
Previous Comments:
[2009-01-15 12:48:30] j...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
And 32bit issue..etc. etc. No bug.
[2009-01-14 19:57:52] mucahitkahveci at gmail dot com
Description:
printf('%f', );
prints 7376.00
This number (555...) has 20 digits this happen in any number with more
than 15 digits
Reproduce code:
---
printf('%f', );
Expected result:
.00
Actual result:
--
7376.00
--
Edit this bug report at http://bugs.php.net/?id=47107edit=1
#48057 [Fbk-Opn]: Only the date fields of the first row are fetched, others are empty
ID: 48057
User updated by: info at programmiernutte dot net
Reported By: info at programmiernutte dot net
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: *
PHP Version: 5.3.0RC1
New Comment:
Worse, the only row that would be complete is nulled because of an
older bug:
array(4) {
[ID]=
NULL
[0]=
NULL
[BAR]=
NULL
[1]=
NULL
}
array(4) {
[ID]=
string(1) 2
[0]=
string(1) 2
[BAR]=
string(0)
[1]=
string(0)
}
array(4) {
[ID]=
string(1) 3
[0]=
string(1) 3
[BAR]=
string(0)
[1]=
string(0)
}
Previous Comments:
[2009-04-27 17:05:30] j...@php.net
Does this happen with PHP 5.2.9 ?
[2009-04-23 07:26:14] info at programmiernutte dot net
Description:
PDO::fetch() only returns date fields on the first call.
subsequent calls return empty strings instead of dates.
Configure Command = './configure' '--
prefix=/usr/local/php' '--with-apxs2' '--without-pdo-sqlite'
'--without-mysql'
php.ini-settings don't seem to matter, I only have these:
date.timezone = Europe/Berlin
include_path = /Library/WebServer/php-includes/
allow_call_time_pass_reference = Off
expose_php = Off
magic_quotes_gpc = Off
register_argc_argv = Off
output_buffering = On
plus settings for xdebug, apc and memcache, I already tried
disabling them, no difference.
PDO_FIREBIRD is loaded as an
extension:extension=pdo_firebird.so
Reproduce code:
---
isql:
SQL create database 'test.fdb';
SQL CREATE TABLE FOO (ID INTEGER, BAR DATE);
SQL INSERT INTO FOO (ID, BAR) VALUES ('1', '11.04.2009');
SQL INSERT INTO FOO (ID, BAR) VALUES ('2', '12.04.2009');
SQL INSERT INTO FOO (ID, BAR) VALUES ('3', '13.04.2009');
php:
?php
$oPDO = new PDO(
'firebird:dbname=localhost:test.fdb;charset=ISO8859_1',
'sysdba',
'masterkey',
array(
PDO::ATTR_PERSISTENT = true,
PDO::ATTR_DEFAULT_FETCH_MODE = PDO::FETCH_OBJ
)
);
$oStmt = $oPDO-query('select id, bar from foo');
foreach($oStmt as $oRow)
{
var_dump($oRow);
}
?
Expected result:
object(stdClass)#3 (2) {
[ID]=
string(1) 1
[BAR]=
string(10) 2009-04-11
}
object(stdClass)#4 (2) {
[ID]=
string(1) 2
[BAR]=
string(10) 2009-04-12
}
object(stdClass)#3 (2) {
[ID]=
string(1) 3
[BAR]=
string(10) 2009-04-13
}
Actual result:
--
object(stdClass)#3 (2) {
[ID]=
string(1) 1
[BAR]=
string(10) 2009-04-11
}
object(stdClass)#4 (2) {
[ID]=
string(1) 2
[BAR]=
string(0)
}
object(stdClass)#3 (2) {
[ID]=
string(1) 3
[BAR]=
string(0)
}
--
Edit this bug report at http://bugs.php.net/?id=48057edit=1
#47812 [NoF-Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: paj...@php.net Reported By: oeriksson at mandriva dot com -Status: No Feedback +Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye Previous Comments: [2009-04-15 01:00:00] 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. [2009-04-07 09:27:23] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-03-30 17:45:13] paj...@php.net The private changes in the bundled libmagic library (file-5.x) is also quite annoying. It will end like mod_mime, to only use the DB. [2009-03-30 17:38:58] oeriksson at mandriva dot com Thanks Pierre, I'm looking forward to a gd with all the bling-bling that's in the bundled gd in php, as well as with libzip. The private changes in the bundled libmagic library (file-5.x) is also quite annoying. [2009-03-27 21:29:40] paj...@php.net Please do not use this report to discuss other topics. But to answer your questions, yes, they are provided as patch upstream as well and we try to keep everything synced as much as possible. But they tend to stay behind for some fixes, especially edge cases for crashes or windows support. You can follow the libzip mailing list if you are interested. 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812edit=1
#47886 [Asn-Csd]: file system time functions not backported from 5.3/6, eg touch
ID: 47886 Updated by: paj...@php.net Reported By: d_kelsey at uk dot ibm dot com -Status: Assigned +Status: Closed Bug Type: Filesystem function related Operating System: win32 only - Windows XP PHP Version: 5.2.9 Assigned To: pajoye Previous Comments: [2009-04-06 08:44:58] d_kelsey at uk dot ibm dot com new test has been committed to cvs for php 5.2 stream [2009-04-03 13:06:34] paj...@php.net If it works in 5.2, yes please do :) Thanks! [2009-04-03 13:02:34] d_kelsey at uk dot ibm dot com Its new to runtests. Anything inside the %r...%r section is treated as a regular expression. If you want I can commit an update to the 5.2.x test ? [2009-04-03 12:51:38] paj...@php.net No, they will not be backported. Does the | operator works in 5.2 run-tests? I never used it :) [2009-04-03 12:07:30] d_kelsey at uk dot ibm dot com Description: touch_basic-win32.phpt test fails once we entered DST. I see in 5.3/5 this area has been looked into because the microsoft C runtime functions appear to be sensitive to DST (by design!) I was wondering if this code was going to be backported to 5.2.x stream ? If not then maybe the expectf section for touch_basic-win32.phpt should be changed from mtime=1 atime=20470 to mtime=%r1|6400%r atime=%r20470|16870%r -- Edit this bug report at http://bugs.php.net/?id=47886edit=1
#48123 [Asn-Bgs]: imagecolorset() misbehaves in newer versions of PHP
ID: 48123
Updated by: paj...@php.net
Reported By: vincent dot k dot hughitt at nasa dot gov
-Status: Assigned
+Status: Bogus
Bug Type: GD related
Operating System: *
PHP Version: 5.2.6-3
Assigned To: pajoye
New Comment:
hi,
There is no bug, the difference is actually a bug fix in how GD managed
PNG Grayscale images. When the grayscale image has an alpha component
(PNG_COLOR_TYPE_GRAY_ALPHA), a truecolor image is created.
If you use a real grayscale only image the resulting image will still
be a palette image. For example:
http://pierre.libgd.org/48123_eit_real_grayscale.png
is a grayscale only image and works as you expect. It is not a bug,
however next version of GD will support grayscale images as internal
formats, that will greatly ease this kind of transformation.
Previous Comments:
[2009-04-30 19:37:17] vincent dot k dot hughitt at nasa dot gov
Okay, got same result on Ubuntu 9.04 using compiled PHP + Bundled GD:
PHP 5.2.6-3ubuntu4.1, GD bundled (2.0.34 compatible)
[2009-04-30 19:12:37] j...@php.net
Verified with latest CVS, using bundled GD library.
[2009-04-30 18:11:51] vincent dot k dot hughitt at nasa dot gov
Hi Pajoye,
Thanks for the feedback. I did not know that about Ubuntu/Fedora's
packaged versions of GD. I will try downloading and compiling PHP from
source and see if I run into the same issues, and post my results here.
If you start with the images:
http://launchpadlibrarian.net/26034594/eit_grayscale.png
http://launchpadlibrarian.net/26034597/ctable_eit304.png
The expected output of the script is:
http://launchpadlibrarian.net/26034598/eit_final_ubuntu810.jpg
which is a COLOR image. The problem is that using newer version of PHP,
the result is a GRAYSCALE image.
[2009-04-30 17:33:11] paj...@php.net
and what do you expect as correct result? for this script.
And please not that both Debian and Ubuntu do not use the bundled GD as
it is recommended and the GD version they use is in a poor state (ubuntu
being less worst).
Please try the same using a normal php too, compiling it with the
bundled GD.
[2009-04-30 16:46:10] vincent dot k dot hughitt at nasa dot gov
Description:
I wrote a small piece of code using that uses the GD module to apply a
color-table to a gray-scale image.
In newer versions of PHP, however, the script only outputs grayscale
images, with no error message.
Furthermore, outputting the contents of imagecolorsforindex shows that
the script is still reading the palette properly, so it must have
something to do with the next step (imagecolorset).
Any ideas?
===
System 1 (non-working):
Ubuntu 9.04 Linux 2.6.28-11-generic
PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23
2009 14:35:05)
gd 2.0.36~rc1~dfsg-3ubuntu1
===
System 2 (non-working):
Fedora 11 Beta Linux 2.6.29.1-111.fc11.i586
PHP 5.2.9
gd 2.0.35
===
System 3 (WORKING):
Ubuntu 8.10 Linux 2.6.27-11-generic
PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11
2009 20:38:24)
gd 2.0.36~rc1~dfsg-3ubuntu1
===
(Originally reported downstream at:
https://bugs.edge.launchpad.net/ubuntu/+source/php5/+bug/368036)
Reproduce code:
---
/**
* Takes a grayscale PNG and modifies it's index to use 256-color
* lookup table then outputs it as an 8-bit JPEG image, or 8-bit
* paletted PNG.
*
* Sample image and color-table:
*
* http://launchpadlibrarian.net/26034594/eit_grayscale.png
* http://launchpadlibrarian.net/26034597/ctable_eit304.png
*/
$gd = imagecreatefrompng(eit_grayscale.png);
$ctable = imagecreatefrompng(ctable_eit304.png);
for ($i = 0; $i = 255; $i++) {
$rgba = imagecolorsforindex($ctable, $i);
imagecolorset($gd, $i, $rgba[red], $rgba[green], $rgba[blue]);
}
imagejpeg($gd, eit_final.jpg, 75);
imagedestroy($gd);
imagedestroy($ctable);
Expected result:
Outputs a 8-bit color JPEG.
(http://launchpadlibrarian.net/26034598/eit_final_ubuntu810.jpg)
Actual result:
--
Outputs a 8-bit grayscale JPEG.
(http://launchpadlibrarian.net/26034602/eit_final_ubuntu904.jpg)
--
Edit this bug report at http://bugs.php.net/?id=48123edit=1
#48098 [Sus]: ./configure --with-something fails when LANG=et_EE.UTF-8
ID: 48098
User updated by: paabulaabu at gmail dot com
Reported By: paabulaabu at gmail dot com
Status: Suspended
Bug Type: Compile Failure
Operating System: Ubuntu 9.04
PHP Version: 5.2.9
New Comment:
In their own words:
Please take your time to find 10 candles, the software you're
using has its birthday today. Then, after feasting on whatever cake
you
can get hold on, maybe a couple of jolly good fellow songs, please
throw
it away, right there, and grab Autoconf 2.63, which is but a toddler
with its almost 8 months.
Welcome to the new millennium! Its first decade ain't over yet. ;-)
Cheers, and also, we don't work on bugs in that version any more,
Ralf
Previous Comments:
[2009-04-29 08:49:25] paabulaabu at gmail dot com
Autoconf folks suggest that bug has been fixed.
configure generated by autoconf version 2.13
latest autoconf is 2.63
Not sure if it is stable one, tho.
[2009-04-28 17:40:08] j...@php.net
Impossible to fix by PHP (completely) since most of this stuff is
produced by autoconf which is 3rd party tool. Report it to the autoconf
folks..
[2009-04-28 13:04:08] paabulaabu at gmail dot com
Description:
Solution: use [:alpha:] instead a-zA-z in various regular expressions.
Bug:
:/usr/src/php-5.2.9$ export LANG=et_EE.UTF-8
:/usr/src/php-5.2.9$ ./configure --with-curl
configure: error: curl: invalid package name
buggy code part in configure script:
if test -n `echo $ac_package| sed 's/[-_a-zA-Z0-9]//g'`; then
{ echo configure: error: $ac_package: invalid package name
12; exit 1; }
fi
bug happens because Z isnt the final letter in estonian alphabet.
proof of concept in shell:
:~$ export LANG=en_GB.UTF-8
:~$ echo abcdefghijklmnopqrstuvõäöüABCDEFGHIJLKMNOPQRSTUVÕÄÖÜ123456789
|sed 's/[-_[:alpha:]0-9]//g'
:~$ echo abcdefghijklmnopqrstuvõäöüABCDEFGHIJLKMNOPQRSTUVÕÄÖÜ123456789
|sed 's/[-_a-zA-Z0-9]//g'
:~$ export LANG=et_EE.UTF-8
:~$ echo abcdefghijklmnopqrstuvõäöüABCDEFGHIJLKMNOPQRSTUVÕÄÖÜ123456789
|sed 's/[-_a-zA-Z0-9]//g'
tuvõäöüTUVÕÄÖÜ
:~$ echo abcdefghijklmnopqrstuvõäöüABCDEFGHIJLKMNOPQRSTUVÕÄÖÜ123456789
|sed 's/[-_[:alpha:]0-9]//g'
pri...@vidrik:~$
--
Edit this bug report at http://bugs.php.net/?id=48098edit=1
#48123 [Bgs]: imagecolorset() misbehaves in newer versions of PHP
ID: 48123 User updated by: vincent dot k dot hughitt at nasa dot gov Reported By: vincent dot k dot hughitt at nasa dot gov Status: Bogus Bug Type: GD related Operating System: * PHP Version: 5.2.6-3 Assigned To: pajoye New Comment: Using true grayscale images as input did the trick. Thank you for the advice pajoye. Keep up the great work! Previous Comments: [2009-05-01 12:17:23] paj...@php.net hi, There is no bug, the difference is actually a bug fix in how GD managed PNG Grayscale images. When the grayscale image has an alpha component (PNG_COLOR_TYPE_GRAY_ALPHA), a truecolor image is created. If you use a real grayscale only image the resulting image will still be a palette image. For example: http://pierre.libgd.org/48123_eit_real_grayscale.png is a grayscale only image and works as you expect. It is not a bug, however next version of GD will support grayscale images as internal formats, that will greatly ease this kind of transformation. [2009-04-30 19:37:17] vincent dot k dot hughitt at nasa dot gov Okay, got same result on Ubuntu 9.04 using compiled PHP + Bundled GD: PHP 5.2.6-3ubuntu4.1, GD bundled (2.0.34 compatible) [2009-04-30 19:12:37] j...@php.net Verified with latest CVS, using bundled GD library. [2009-04-30 18:11:51] vincent dot k dot hughitt at nasa dot gov Hi Pajoye, Thanks for the feedback. I did not know that about Ubuntu/Fedora's packaged versions of GD. I will try downloading and compiling PHP from source and see if I run into the same issues, and post my results here. If you start with the images: http://launchpadlibrarian.net/26034594/eit_grayscale.png http://launchpadlibrarian.net/26034597/ctable_eit304.png The expected output of the script is: http://launchpadlibrarian.net/26034598/eit_final_ubuntu810.jpg which is a COLOR image. The problem is that using newer version of PHP, the result is a GRAYSCALE image. [2009-04-30 17:33:11] paj...@php.net and what do you expect as correct result? for this script. And please not that both Debian and Ubuntu do not use the bundled GD as it is recommended and the GD version they use is in a poor state (ubuntu being less worst). Please try the same using a normal php too, compiling it with the bundled GD. 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/48123 -- Edit this bug report at http://bugs.php.net/?id=48123edit=1
#48096 [Fbk]: Error reading XML string
ID: 48096
Updated by: rricha...@php.net
Reported By: bbarnett at gt dot co dot cr
Status: Feedback
Bug Type: DOM XML related
Operating System: Windows 2003 Server R2
PHP Version: 5.2.9
New Comment:
You are still missing all the values being populated as well as another
function.
Previous Comments:
[2009-04-29 16:22:18] bbarnett at gt dot co dot cr
This is the function that I use to complete the length of the string
function llenacampo($valor,$tamano,$llenado,$justificado){
// Esta funcion devuelve el valor basado en los parametros para ser
agregado en la trama
$devuelve='';
if ($justificado=='derecha'){
//Llena el campo de derecha a izquierda
$cuanto=$tamano-strlen(trim($valor));
for ($i=0;$i$cuanto;$i++){
$devuelve.=$llenado;
}
$devuelve.=$valor;
} elseif ($justificado=='izquierda'){
//Llena el campo de derecha a izquierda
$devuelve.=$valor;
$cuanto=$tamano-strlen(trim($valor));
for ($i=0;$i$cuanto;$i++){
$devuelve.=$llenado;
}
}
return $devuelve;
}
[2009-04-28 11:57:32] rricha...@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.
Included script does not run because you are using functions and
variables that are not included here. As I said before this is an
encoding issue and I would bet it due to the values of them.
[2009-04-28 06:44:37] bbarnett at gt dot co dot cr
This is an example of the XML string:
?xml version=1.0?
X_A_PagoGen
Banco2/Banco
Localizacion2603460081/Localizacion
NotaCredito9787/NotaCredito
Correlativo82108608/Correlativo
Self9/Self
Monto003930/Monto
Agencia1400/Agencia
FechaPago20090427/FechaPago
FechaCaja20090428/FechaCaja
/X_A_PagoGen
[2009-04-28 06:36:40] bbarnett at gt dot co dot cr
Description:
I'm receiving and errors when I try to read and XML string, previously
generated by my code.
Reproduce code:
---
$doc = new DOMDocument('1.0'); $doc-formatOutput = true;
$root = $doc-createElement('X_A_PagoGen'); $root =
$doc-appendChild($root);
$title = $doc-createElement('Banco'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(trim($codigobanco)); $text =
$title-appendChild($text);
$title = $doc-createElement('Localizacion'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(trim($localizacion)); $text =
$title-appendChild($text);
$title = $doc-createElement('NotaCredito'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(llenacampo(trim($remesa),12,'0','derecha')); $text
= $title-appendChild($text);
$title = $doc-createElement('Correlativo'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(trim($factura)); $text =
$title-appendChild($text);
$title = $doc-createElement('Self'); $title =
$root-appendChild($title); $text = $doc-createTextNode(trim($self));
$text = $title-appendChild($text);
$title = $doc-createElement('Monto'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(llenacampo(trim($monto),10,'0','derecha')); $text =
$title-appendChild($text);
$title = $doc-createElement('Agencia'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(trim($recaudadorCNFL)); $text =
$title-appendChild($text);
$title = $doc-createElement('FechaPago'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(trim(fecha1())); $text =
$title-appendChild($text);
$title = $doc-createElement('FechaCaja'); $title =
$root-appendChild($title); $text =
$doc-createTextNode(trim($deposito)); $text =
$title-appendChild($text);
$tramaxml=$doc-saveXML();
$xml2= simplexml_load_string(trim($tramaxml));
Expected result:
XML Object
Actual result:
--
Error:
Fatal Error 73: Couldn't find end of Start Tag Fech line 10 Line: 10
Column: 8
Fatal Error 77: Premature end of data in tag X_A_PagoGen line 2 Line:
10 Column: 8
#47736 [Asn-Fbk]: imap_headerinfo() segfaults with large address lists
ID: 47736 Updated by: paj...@php.net Reported By: etremblay at kronostechnologies dot com -Status: Assigned +Status: Feedback Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-03-31) Assigned To: pajoye New Comment: This error is due to a too old cclient version, I should have saw it earlier (backtrace). Update the c-client to a more recent version (2007e for example). Previous Comments: [2009-04-27 23:15:57] paj...@php.net We still use some of the risky APIs. Testing again before the commit. [2009-03-31 11:49:40] etremblay at kronostechnologies dot com If you look closely at http://markmail.org/message/ypvowfyqcijit4f5, it say that the fixed api functions begin with rfc822_output_*. In the core dump, we see that the problem is in the function rfc822_output_address () from /usr/lib/libc-client.so.2007b. So, the actual problem is not the same. [2009-03-31 07:55:38] j...@php.net This explains the bug: http://markmail.org/message/ypvowfyqcijit4f5 [2009-03-23 12:22:38] etremblay at kronostechnologies dot com libc-client2007b (ubuntu intrepid) I try the current snapshot of php. Post back in 2 minutes. [2009-03-23 12:16:27] paj...@php.net Which imap version do you use? 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/47736 -- Edit this bug report at http://bugs.php.net/?id=47736edit=1
#48125 [Opn-Bgs]: php-cli makes less command behave differently
ID: 48125 Updated by: j...@php.net Reported By: scot at wilcoxon dot org -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Linux Ubuntu 9.04 PHP Version: 5.2.9 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2009-04-30 20:57:46] scot at wilcoxon dot org Description: When php-cli is sending output to less it becomes necessary to press ENTER after commands. It happens both locally and through SSH. Reproduce code: --- --- From manual page: features.commandline --- php -r 'print_r(get_defined_constants());' | less Expected result: Output from command with : at bottom. Pressing n should start a new page. Actual result: -- Output from command with : at bottom. Pressing n does nothing until ENTER is pressed. -- Edit this bug report at http://bugs.php.net/?id=48125edit=1
#48094 [Opn-Fbk]: Two graceful restarts are needed to enable PHP
ID: 48094 Updated by: j...@php.net Reported By: albegley at apple dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: * PHP Version: 5.2.9 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2009-04-27 23:23:55] albegley at apple dot com Description: A second graceful restart is needed to enable PHP. 1. Start apache with mod_php disabled. 2. Edit httpd.conf and enable the mod_php LoadModule directive. 3. Do a graceful restart of Apache. 4. Note that .php files are downloaded to client rather than being properly interpreted. 5. Do a second graceful restart of Apache. 6. Note that .php files are handled properly. Others have been reporting this for some time, with older versions of PHP, for example: http://aspn.activestate.com/ASPN/Mail/Message/php-dev/3591788 Expected result: Other Apache plugins initialize themselves after a single graceful restart. It appears the php plugin is relying on its own static variables instead of using Apache data structures. -- Edit this bug report at http://bugs.php.net/?id=48094edit=1
#45729 [Opn-Fbk]: Crash when fetching mails with long to-address field via pop3
ID: 45729
Updated by: j...@php.net
Reported By: kirsch at mediafinanz dot de
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: Windows
PHP Version: 5.2.6
Assigned To: pajoye
Previous Comments:
[2009-04-30 20:29:32] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please try 5.3 too (different c-client version).
[2008-08-06 09:37:37] kirsch at mediafinanz dot de
Description:
When trying to receive a mail with a really long to-address field (e.g.
Spam with 276 receivers) over pop3, PHP crashes. But it seems that it
depends of the way I open the connection to the mailbox.
PHP crashes on long to-address mail if I use $mailbox =
imap_open('{mail.myserver.net:110/pop3/novalidate-cert}INBOX',
'p...@myserver.net', 'mydamnsecretpassword');, but everything works fine
if I use $mailbox = imap_open('{mail.myserver.net:143}INBOX',
'p...@myserver.net', 'mydamnsecretpassword');
Reproduce code:
---
//you'll need a mail with a lot of receivers for this test
$mailbox =
imap_open('{mail.myserver.net:110/pop3/novalidate-cert}INBOX',
'p...@myserver.net', 'mydamnsecretpassword');
$check = imap_check($mailbox);
for ($i=1; $i = $check-Nmsgs; $i++)
{
$uid = imap_uid($mailbox, $i);
echo 'UID: '.$uid;
$messageNumber = imap_msgno($mailbox, $uid);
echo 'MessageNo: '.$messageNumber;
$headerinfo = imap_headerinfo($mailbox, $messageNumber);
[...]
}
Expected result:
$headerinfo contains an stdObject with headerinformation, like it does
if it is a 'normal' mail
Actual result:
--
Crash with message 'This application has requested the Runtime to
terminiate it in an unusual way. Please contact the application's
support team for more information'
--
Edit this bug report at http://bugs.php.net/?id=45729edit=1
#47596 [Asn-Csd]: Bus error on parsing file
ID: 47596 Updated by: j...@php.net Reported By: pahan at hubbitus dot info -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: Linux PHP Version: 5.3.0beta1 Assigned To: shire Previous Comments: [2009-03-26 17:32:31] dmi...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-03-22 01:19:06] sh...@php.net This is being caused because of mis-use of mmap(). We are currently relying on mmap to pad the end of our mmap'd file with zeros for detection of EOF in the scanner and scanning ahead. We specifically add ZEND_MMAP_AHEAD to the len passed to mmap in zend_stream_fixup(): /* *buf[size] is zeroed automatically by the kernel */ *buf = mmap(0, size + ZEND_MMAP_AHEAD, PROT_READ, MAP_PRIVATE, fileno(file_handle-handle.fp), 0); But AFAIK mmap does not support this usage of the len parameter, as it's a limit rather than able to extend the mmap region. This appears to work under most cases as mmap will pad zeroes up to PAGESIZE. This error will occur anytime we use mmap in this way on a file that is not ZEND_MMAP_AHEAD bytes less than PAGESIZE and therefore attempt to access a byte over PAGESIZE. It will be easy to fix the mmap calls, however this will break the re2c scanner. Originally for the EOF checks I was going to re-implement YYFILL to malloc additional space for the scanner after EOF, this may be an option to correct this. [2009-03-10 18:23:04] scott...@php.net Looks like something in the re2c stuff that's causing it to overread. [2009-03-10 11:12:19] pahan at hubbitus dot info This script completely self-contained reproducing script. But as I mention before, I can't make it smaller because it break reproducibility. [2009-03-08 09:37:43] pahan at hubbitus dot info Description: On particular file php always crashes with Bus Error. I'm try split file to get only sensible data, but I can't. ANY changes in it do predictable behavior and all works as expected. Even add/delete comment, any letter, space in any place... $ php test.bus.error.php Bus error Its contain many external dependencies, but it is absolutely unneeded for reproducibility: $ php -dinclude_path=: test.bus.error.php Bus error [pa...@x-www _SHARED_]$ ulimit -c unlimited [pa...@x-www _SHARED_]$ php -dinclude_path=/ test.bus.error.php Bus error (core dumped) This file is my working mess for test and sandboxing :), so, it is really not intended for any use outside and even any use except probes and examples. But as I can't even change 1 letter in it, I place it as is: http://ru.bir.ru/_temp/php-bugs/2/test.bus.error.php.gz Coredump file also available for download: http://ru.bir.ru/_temp/php- bugs/2/core.19581 Reproduce code: --- http://ru.bir.ru/_temp/php-bugs/2/test.bus.error.php.gz Sorry, I can't do that smaller. -- Edit this bug report at http://bugs.php.net/?id=47596edit=1
#47736 [Fbk-Opn]: imap_headerinfo() segfaults with large address lists
ID: 47736 User updated by: etremblay at kronostechnologies dot com Reported By: etremblay at kronostechnologies dot com -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-03-31) Assigned To: pajoye New Comment: If so, why does it work with php 5.2.6 ? (And before, we are using this since 2005) The only thing I can see, is that someone in PHP removed a workaround for a c-client bug int php 5.2.9?? c-client2007e doesn't seem to be widely distributed. The only place I've seen it is in a ftp (ftp://ftp.cac.washington.edu/imap/) and it look like it's packaged with an imap server. I don't like this solution. Previous Comments: [2009-05-01 14:29:00] paj...@php.net This error is due to a too old cclient version, I should have saw it earlier (backtrace). Update the c-client to a more recent version (2007e for example). [2009-04-27 23:15:57] paj...@php.net We still use some of the risky APIs. Testing again before the commit. [2009-03-31 11:49:40] etremblay at kronostechnologies dot com If you look closely at http://markmail.org/message/ypvowfyqcijit4f5, it say that the fixed api functions begin with rfc822_output_*. In the core dump, we see that the problem is in the function rfc822_output_address () from /usr/lib/libc-client.so.2007b. So, the actual problem is not the same. [2009-03-31 07:55:38] j...@php.net This explains the bug: http://markmail.org/message/ypvowfyqcijit4f5 [2009-03-23 12:22:38] etremblay at kronostechnologies dot com libc-client2007b (ubuntu intrepid) I try the current snapshot of php. Post back in 2 minutes. 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/47736 -- Edit this bug report at http://bugs.php.net/?id=47736edit=1
#47736 [Com]: imap_headerinfo() segfaults with large address lists
ID: 47736 Comment by: etremblay at kronostechnologies dot com Reported By: etremblay at kronostechnologies dot com Status: Open Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-03-31) Assigned To: pajoye New Comment: I still agree with what I said in the last message, but you are right, it works with imap2007e. Previous Comments: [2009-05-01 17:24:11] etremblay at kronostechnologies dot com If so, why does it work with php 5.2.6 ? (And before, we are using this since 2005) The only thing I can see, is that someone in PHP removed a workaround for a c-client bug int php 5.2.9?? c-client2007e doesn't seem to be widely distributed. The only place I've seen it is in a ftp (ftp://ftp.cac.washington.edu/imap/) and it look like it's packaged with an imap server. I don't like this solution. [2009-05-01 14:29:00] paj...@php.net This error is due to a too old cclient version, I should have saw it earlier (backtrace). Update the c-client to a more recent version (2007e for example). [2009-04-27 23:15:57] paj...@php.net We still use some of the risky APIs. Testing again before the commit. [2009-03-31 11:49:40] etremblay at kronostechnologies dot com If you look closely at http://markmail.org/message/ypvowfyqcijit4f5, it say that the fixed api functions begin with rfc822_output_*. In the core dump, we see that the problem is in the function rfc822_output_address () from /usr/lib/libc-client.so.2007b. So, the actual problem is not the same. [2009-03-31 07:55:38] j...@php.net This explains the bug: http://markmail.org/message/ypvowfyqcijit4f5 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/47736 -- Edit this bug report at http://bugs.php.net/?id=47736edit=1
#47736 [Opn-Bgs]: imap_headerinfo() segfaults with large address lists
ID: 47736 Updated by: paj...@php.net Reported By: etremblay at kronostechnologies dot com -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-03-31) Assigned To: pajoye New Comment: The old functions are even less safe and should be used. Most distributions have either updated to a decent version or have backported the fixes. If yours does not work I would suggest to report a bug there. Not a php bug but a c-client one. ps: yes, the c-client is part of the UW imap server but can be compiled alone. Previous Comments: [2009-05-01 18:31:27] etremblay at kronostechnologies dot com I still agree with what I said in the last message, but you are right, it works with imap2007e. [2009-05-01 17:24:11] etremblay at kronostechnologies dot com If so, why does it work with php 5.2.6 ? (And before, we are using this since 2005) The only thing I can see, is that someone in PHP removed a workaround for a c-client bug int php 5.2.9?? c-client2007e doesn't seem to be widely distributed. The only place I've seen it is in a ftp (ftp://ftp.cac.washington.edu/imap/) and it look like it's packaged with an imap server. I don't like this solution. [2009-05-01 14:29:00] paj...@php.net This error is due to a too old cclient version, I should have saw it earlier (backtrace). Update the c-client to a more recent version (2007e for example). [2009-04-27 23:15:57] paj...@php.net We still use some of the risky APIs. Testing again before the commit. [2009-03-31 11:49:40] etremblay at kronostechnologies dot com If you look closely at http://markmail.org/message/ypvowfyqcijit4f5, it say that the fixed api functions begin with rfc822_output_*. In the core dump, we see that the problem is in the function rfc822_output_address () from /usr/lib/libc-client.so.2007b. So, the actual problem is not the same. 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/47736 -- Edit this bug report at http://bugs.php.net/?id=47736edit=1
#47736 [Bgs]: imap_headerinfo() segfaults with large address lists
ID: 47736 User updated by: etremblay at kronostechnologies dot com Reported By: etremblay at kronostechnologies dot com Status: Bogus Bug Type: IMAP related Operating System: * PHP Version: 5.*, 6CVS (2009-03-31) Assigned To: pajoye New Comment: Now I understand. With php 5.2.6 and less, the old c-client unsafe method where used. Now the new ones are used but they are broken in old version of c-client. That sound logical. Thank you for your time. Previous Comments: [2009-05-01 18:39:25] paj...@php.net The old functions are even less safe and should be used. Most distributions have either updated to a decent version or have backported the fixes. If yours does not work I would suggest to report a bug there. Not a php bug but a c-client one. ps: yes, the c-client is part of the UW imap server but can be compiled alone. [2009-05-01 18:31:27] etremblay at kronostechnologies dot com I still agree with what I said in the last message, but you are right, it works with imap2007e. [2009-05-01 17:24:11] etremblay at kronostechnologies dot com If so, why does it work with php 5.2.6 ? (And before, we are using this since 2005) The only thing I can see, is that someone in PHP removed a workaround for a c-client bug int php 5.2.9?? c-client2007e doesn't seem to be widely distributed. The only place I've seen it is in a ftp (ftp://ftp.cac.washington.edu/imap/) and it look like it's packaged with an imap server. I don't like this solution. [2009-05-01 14:29:00] paj...@php.net This error is due to a too old cclient version, I should have saw it earlier (backtrace). Update the c-client to a more recent version (2007e for example). [2009-04-27 23:15:57] paj...@php.net We still use some of the risky APIs. Testing again before the commit. 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/47736 -- Edit this bug report at http://bugs.php.net/?id=47736edit=1
#48118 [Opn-Bgs]: unable to compile static binary using php embed sapi (libphp5.a)
ID: 48118
Updated by: j...@php.net
Reported By: mukustr at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Centos - 2.6.18/x86_64
PHP Version: 5.2.9
New Comment:
This is not any bug in PHP. When you build static stuff, the order of
libraries is significant. This works fine:
# gcc \
`/usr/local/bin/php-config --includes`
`/usr/local/bin/php-config --ldflags`
-Wall -Wextra -ggdb -static -o nohello nohello.c \
-L/usr/local/lib -lphp5 `/usr/local/bin/php-config --libs`
Previous Comments:
[2009-04-29 22:43:49] mukustr at yahoo dot com
Description:
I am trying hard to compile a statically linked binary using php embed
sapi, but it is impossible for me.
PHP Embed Sapi Configuration Options:
./configure --disable-all --with-libdir=lib64 --enable-embed=static
[r...@]# ls -al /usr/local/lib/libphp5.a
-rw-r--r-- 1 root root 15053670 Apr 30 02:11 /usr/local/lib/libphp5.a
Reproduce code:
---
nohello.c:
#include sapi/embed/php_embed.h
int main(int argc, char *argv[])
{
PHP_EMBED_START_BLOCK(argc,argv)
PHP_EMBED_END_BLOCK()
return 0;
}
[r...@]# gcc -I/usr/local/include/php/ -I/usr/local/include/php/main
-I/usr/local/include/php/Zend -I/usr/local/include/php/TSRM
-I/usr/local/include/php/sapi/embed -L/usr/local/lib -Wall -Wextra
-lpthread -static -ggdb -o nohello nohello.c /usr/local/lib/libphp5.a
Expected result:
A statically linked binary: nohello
Actual result:
--
/usr/local/lib/libphp5.a(filestat.o): In function `php_do_chgrp':
/root/php529modified/ext/standard/filestat.c:420: warning: Using
'getgrnam' in statically linked applications requires at runtime the
shared libraries from $
/usr/local/lib/libphp5.a(fopen_wrappers.o): In function
`php_fopen_primary_script':
/root/php529modified/main/fopen_wrappers.c:369: warning: Using
'getpwnam' in statically linked applications requires at runtime the
shared libraries from th$
/usr/local/lib/libphp5.a(safe_mode.o): In function
`php_get_current_user':
/root/php529modified/main/safe_mode.c:255: warning: Using 'getpwuid' in
statically linked applications requires at runtime the shared libraries
from the gli$
/usr/local/lib/libphp5.a(network.o): In function
`php_network_getaddresses':
/root/php529modified/main/network.c:204: warning: Using 'getaddrinfo'
in statically linked applications requires at runtime the shared
libraries from the gl$
/usr/local/lib/libphp5.a(dns.o): In function `php_gethostbyaddr':
/root/php529modified/ext/standard/dns.c:161: warning: Using
'gethostbyaddr' in statically linked applications requires at runtime
the shared libraries from $
/usr/local/lib/libphp5.a(dns.o): In function `php_gethostbyname':
/root/php529modified/ext/standard/dns.c:235: warning: Using
'gethostbyname' in statically linked applications requires at runtime
the shared libraries from $
/usr/local/lib/libphp5.a(basic_functions.o): In function
`zif_getprotobynumber':
/root/php529modified/ext/standard/basic_functions.c:6016: warning:
Using 'getprotobynumber' in statically linked applications requires at
runtime the shared$
/usr/local/lib/libphp5.a(basic_functions.o): In function
`zif_getprotobyname':
/root/php529modified/ext/standard/basic_functions.c:5989: warning:
Using 'getprotobyname' in statically linked applications requires at
runtime the shared l$
/usr/local/lib/libphp5.a(basic_functions.o): In function
`zif_getservbyname':
/root/php529modified/ext/standard/basic_functions.c:5938: warning:
Using 'getservbyname' in statically linked applications requires at
runtime the shared li$
/usr/local/lib/libphp5.a(basic_functions.o): In function
`zif_getservbyport':
/root/php529modified/ext/standard/basic_functions.c:5963: warning:
Using 'getservbyport' in statically linked applications requires at
runtime the shared li$
/usr/local/lib/libphp5.a(zend_operators.o): In function
`zend_string_to_double':
/root/php529modified/Zend/zend_operators.c:108: undefined reference to
`pow'
/usr/local/lib/libphp5.a(zend_API.o): In function `module_destructor':
/root/php529modified/Zend/zend_API.c:1947: undefined reference to
`dlclose'
/usr/local/lib/libphp5.a(zend_extensions.o): In function
`zend_load_extension':
/root/php529modified/Zend/zend_extensions.c:34: undefined reference to
`dlopen'
/root/php529modified/Zend/zend_extensions.c:44: undefined reference to
`dlsym'
/root/php529modified/Zend/zend_extensions.c:48: undefined reference to
`dlsym'
/root/php529modified/Zend/zend_extensions.c:79: undefined reference to
`dlclose'
/root/php529modified/Zend/zend_extensions.c:54: undefined reference to
`dlclose'
/root/php529modified/Zend/zend_extensions.c:46: undefined reference to
`dlsym'
/root/php529modified/Zend/zend_extensions.c:50: undefined reference to
`dlsym'
/root/php529modified/Zend/zend_extensions.c:37: undefined reference to
`dlerror'
#48127 [NEW]: Namespace error when file saved as UTF-8
From: sol at venasoft dot com
Operating system: Windows XP
PHP version: 5.3.0RC1
PHP Bug Type: Class/Object related
Bug description: Namespace error when file saved as UTF-8
Description:
Scripts containing namespaces fail with an error if the file is saved in
encoding UTF-8, but works as expected when saved in encoding ANSI using
Windows Notepad.
Only namespaces seem to be effected by this error.
Reproduce code:
---
?php
namespace
{
print 'Hello World';
}
Expected result:
Hello World
Actual result:
--
Fatal error: Namespace declaration statement has to be the very first
statement in the script in C:\home\public_html\name.php on line 4
--
Edit bug report at http://bugs.php.net/?id=48127edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48127r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48127r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48127r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48127r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48127r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48127r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48127r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48127r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48127r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48127r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48127r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48127r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48127r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48127r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48127r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48127r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48127r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48127r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48127r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48127r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48127r=mysqlcfg
#48127 [Opn-Bgs]: Namespace error when file saved as UTF-8
ID: 48127
Updated by: der...@php.net
Reported By: sol at venasoft dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows XP
PHP Version: 5.3.0RC1
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Quite likely you have a BOM in this PHP file. You need to configure
your editor not to write those.
Previous Comments:
[2009-05-01 20:17:22] sol at venasoft dot com
Description:
Scripts containing namespaces fail with an error if the file is saved
in encoding UTF-8, but works as expected when saved in encoding ANSI
using Windows Notepad.
Only namespaces seem to be effected by this error.
Reproduce code:
---
?php
namespace
{
print 'Hello World';
}
Expected result:
Hello World
Actual result:
--
Fatal error: Namespace declaration statement has to be the very first
statement in the script in C:\home\public_html\name.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=48127edit=1
#47536 [Opn-Csd]: Build warnings with embedded SAPI
ID: 47536 Updated by: j...@php.net Reported By: ikickdogsforfun at hotmail dot com -Status: Open +Status: Closed Bug Type: Compile Warning Operating System: Gentoo PHP Version: 5.2.9 New Comment: These warnings happen only when the embed lib is build with --enable- debug. I fixed most in CVS. The rest are harmless anyway and only needed for debugging. Previous Comments: [2009-03-01 16:46:48] ikickdogsforfun at hotmail dot com Description: When compiling a C program that makes use of the embedded SAPI (embed.h), there are a few compile warnings that would be nice if they could be fixed :) Also, this is a manually compiled version of PHP, not emerged from Gentoo's portage. Reproduce code: --- Compiled using the following: gcc -I/usr/lib/php5/include/php/ -I/usr/lib/php5/include/php/main -I/usr/lib/php5/include/php/Zend -I/usr/lib/php5/include/php/TSRM -I/usr/lib/php5/include/php/sapi/embed -L/home/crisp/php/local/lib -Wall -Wextra -lpthread -ggdb -o httpd *.c /home/crisp/php/local/lib/libphp5.so The code itself is here: http://crispycrisp.org/test.txt Expected result: No compile warnings Actual result: -- In file included from /usr/lib/php5/include/php/Zend/zend.h:664, from /usr/lib/php5/include/php/main/php.h:34, from /usr/lib/php5/include/php/sapi/embed/php_embed.h:23, from test.c:1: /usr/lib/php5/include/php/Zend/zend_variables.h:30: warning: unused parameter '__zend_filename' /usr/lib/php5/include/php/Zend/zend_variables.h:30: warning: unused parameter '__zend_lineno' /usr/lib/php5/include/php/Zend/zend_variables.h:40: warning: unused parameter '__zend_filename' /usr/lib/php5/include/php/Zend/zend_variables.h:40: warning: unused parameter '__zend_lineno' In file included from /usr/lib/php5/include/php/Zend/zend_API.h:30, from /usr/lib/php5/include/php/main/php.h:38, from /usr/lib/php5/include/php/sapi/embed/php_embed.h:23, from test.c:1: /usr/lib/php5/include/php/Zend/zend_execute.h:65: warning: unused parameter '__zend_orig_filename' /usr/lib/php5/include/php/Zend/zend_execute.h:65: warning: unused parameter '__zend_orig_lineno' -- Edit this bug report at http://bugs.php.net/?id=47536edit=1
#46340 [NoF-Fbk]: segmentation fault (11)
ID: 46340
Updated by: fel...@php.net
Reported By: dl4gbe at gmail dot com
-Status: No Feedback
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: linux suse
PHP Version: 5.2.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2008-10-27 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.
[2008-10-26 09:32:23] dl4gbe at gmail dot com
I can't provide lines of script. The error seems not to occure in
simple scripts. I guess it only happens in more complicated structures
that an segmentation fault happens in case a method of a class does not
exist. I will try to build a debug version on my system. But that needs
time. Just now, I am not able to compile php on the affected system.
I do not know if this helps:
public static function getFormHtml($a_row,$a_form)
{
$l_return = ;
$l_return .= tr class=' . $a_form-getCssFormTr() . ' .
utils::getLineEnd();
$l_return .= td class=' . $a_form-getCssFormTd() . ' .
utils::getLineEnd();
$l_return .= table class=' . $a_form-getCssFormTable() . '
width='100%';
$l_return .= id=' . $a_form-getControlName() . _table_form_main .
' . utils::getLineEnd();
utils::addToDebugLog(getFormHtml (Start));
if ($a_form-getTabCount() == 0)
{
utils::addToDebugLog(getFormHtml (1));
$l_return .= tr class=' . $a_form-getCssTrForm() . ' .
utils::getLineEnd();
$l_return .= td class=' . $a_form-getCssTdForm() . ' .
utils::getLineEnd();
utils::getLineEnd();
// this line causes php to crash
$l_return .= $a_form-getTabHtml(0,$a_row);
// because I moved getTabHtml to htmlrender class as static
// and there is no function with this name in $a_form anymore
// This is the line which I planned to call but forgot to change :-(
//$l_return .= htmlrender::getTabHtml(0,$a_row,$a_form);
// what I know is, using this line instead of the line above
// my program works and is not causing a segmentation error anymore.
$l_return .= /td . utils::getLineEnd();
$l_return .= /tr . utils::getLineEnd();
}
[2008-10-19 11:48:33] scott...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
We would also need a short reproduce script about 10-20 lines that we
can run.
[2008-10-19 08:39:29] dl4gbe at gmail dot com
Description:
I used to have functions (methods) in a class named form (not
static). Later, I changed the design and moved the methods into a static
class. named xmlparser. In one case I forgot to change my code and
still called the old instance method.
the old call was
$a_form-createTable($l_formnode);
it should have been:
xmlparser::createTable($a_form,$l_formnode);
Like said: I moved function createTable into the static class
xmlparser.
The function was called from another static function located in
xmlparser which had a valid form object instanized and a valid xml node
as a second parameter
The result? I did not get a function not found in class or something
like this error in the log file. No, I run into a crazy segmentation
fault (11) error. I can't debug crazy segmentation fault errors(11)
--
Edit this bug report at http://bugs.php.net/?id=46340edit=1
#46112 [NoF-Fbk]: Segfault when throwing exception during class construction (PHP_5_2 only)
ID: 46112 Updated by: fel...@php.net Reported By: erikg at codepoet dot no -Status: No Feedback +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux (64bit only) PHP Version: 5.2CVS-2008-10-07 Assigned To: fb-req-jani New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2008-11-08 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. [2008-10-31 15:57:44] j...@php.net Can you try running via valgrind using latest snapshot: # USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php test.php [2008-10-07 19:11:41] erikg at codepoet dot no I can still reproduce the crash with the latest 5.2 snapshot. However, it seems to work fine using the 5.3 snapshot. [2008-10-07 17:56:22] fel...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2008-10-07 17:44:31] erikg at codepoet dot no The crash doesn't occur when I compile PHP with debug symbols - no idea why. 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/46112 -- Edit this bug report at http://bugs.php.net/?id=46112edit=1
#47314 [Opn-Fbk]: SoapClient leave tcp connections in time_wait
ID: 47314
Updated by: j...@php.net
Reported By: bernd dot ott at k-m dot info
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5.2CVS-2009-02-05 (snap)
Assigned To: dmitry
New Comment:
But did you do what Pierre asked above ? The hosts thing..
Previous Comments:
[2009-03-02 08:34:22] bernd dot ott at k-m dot info
i created the sample on a old xp machine with apache 2.2 installed.
i have tested the webservice with different Clients made with different
languages. no other client keep the connections in time_wait.
[2009-02-23 11:21:16] paj...@php.net
Do you have IPv6 installed (by default on Vista or later, needs an
extra package for XP/2k). If yes, edit:
C:\windows\system32\drivers\etc\hosts
and comment the following line:
::1 localhost
becomes:
#::1 localhost
Restart the web server and test again.
[2009-02-23 11:11:00] bernd dot ott at k-m dot info
open the socket with fsocketopen / fclose doesnt leave timewait
connections.
the problem is, this causes my .net soap server to a not response
state. this is because all workers are allocated.
i cant use keep alive, my page is using ajax to a php page which
contains the soapclient.
[2009-02-18 15:41:39] dmi...@php.net
According to http://tangentsoft.net/wskfaq/articles/debugging-tcp.html
and http://www.developerweb.net/forum/showthread.php?t=2941 it's a
normal TCP behaviour. (In case you run Apache benchmark you can see a
lot of connections in TCP_WAIT state too)
In case you call SOAP functions on the same SoapClient object and your
Web Server responds with keep-alive HTTP header all the functions will
use a single TCP connection.
[2009-02-05 13:33:35] bernd dot ott at k-m dot info
Description:
Call to a Soapserver with the SoapClient leaves after a function call
tcp-connection in state time_wait.
depending on your server your server get unreachable, because all
workers are allocated by the waiting connections.
the sample code leaves 100 open connections.
if you call more than on function you get more open connections.
the soapclient doesnt reuse the open connection.
(this is not shown in the sample)
the connections you can see in netstat or tcpview (sysinternals)
Reproduce code:
---
Client:
?php
$i=100;
while ($i0) {
$sc = new SoapClient(null, array('location' =
http://localhost/server.php;,
'uri' =
http://test-uri/;));
echo $sc-__soapcall(test, array('test')).\r\n;
flush();
$i -= 1;
}
Server:
?php
function test($x)
{
return $x.hallo;
}
$server = new SoapServer(null, array('uri' = http://test-uri/;));
$server-addFunction(test);
$server-handle();
Expected result:
Client opens connection, does the function call and terminates
connection.
after correct close the should no connections in state time_wait.
Actual result:
--
100 connections are in time_wait status.
--
Edit this bug report at http://bugs.php.net/?id=47314edit=1
#47525 [Opn-Bgs]: value returned from __call copied prematurely
ID: 47525
Updated by: j...@php.net
Reported By: rodricg at sellingsource dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 5.2.9
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is a side-effect of the Zend memory manager. If you run the script
with PHP build with --enable-debug and like this:
# USE_ZEND_ALLOC=0 php test.php
new A(): 8,280
$a-str: 8,280
$a-getStr(): 8,280
$a-magic(): 8,280
You see that there is no leak or unnecessary copying anywhere.
Previous Comments:
[2009-02-28 01:56:43] rodricg at sellingsource dot com
Description:
Values returned from the magic __call method are copied immediately
resulting in increased memory usage.
Reproduce code:
---
?php
function mem($msg='') { echo ($msg ? $msg.: :
'').number_format(memory_get_usage(1)).\n; }
class A
{
public $str;
public function __construct() { $this-str = str_repeat(a,
100); }
public function __call($m, $a) {return $this-str;}
public function getStr() {return $this-str;}
}
$a = new A(); mem('new A()');
$b = $a-str; mem('$a-str');
$c = $a-getStr(); mem('$a-getStr()');
$d = $a-magic(); mem('$a-magic()');
?
Expected result:
new A(): 1,310,720
$a-str: 1,310,720
$a-getStr(): 1,310,720
$a-magic(): 1,310,720
Actual result:
--
new A(): 1,310,720
$a-str: 1,310,720
$a-getStr(): 1,310,720
$a-magic(): 2,359,296
--
Edit this bug report at http://bugs.php.net/?id=47525edit=1
#19937 [Com]: dynamic extension loading fails
ID: 19937 Comment by: spannothanks at example dot com/span Reported By: ryan dot smith at openwave dot com Status: No Feedback Bug Type: Dynamic loading Operating System: AIX 5.1 PHP Version: 4.3.0-dev New Comment: bThanks/b for this! Previous Comments: [2008-09-23 11:57:44] eilaf_mugbil at hotmail dot com eilaf [2006-04-21 07:04:45] jens_0 at hotmail dot com Same thing here with Apache/1.3.31 (Unix) PHP/4.0.6 using HP-UX or AIX concening libgd.so. The extension won't load: PHP Warning: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts/libgd.so' - Invalid argument in Unknown on line 0 [2003-07-18 18:49:39] sni...@php.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 Open. Thank you. [2003-07-10 18:08:00] sni...@php.net Here's an url to it: http://www.php.net/~jani/dlopen_patch.txt [2003-07-10 18:05:55] sni...@php.net Could you try this patch: Index: zend.h === RCS file: /repository/Zend/Attic/zend.h,v retrieving revision 1.164.2.8 diff -u -r1.164.2.8 zend.h --- zend.h 31 May 2003 01:37:43 - 1.164.2.8 +++ zend.h 10 Jul 2003 23:05:38 - @@ -89,7 +89,11 @@ # define RTLD_GLOBAL 0 # endif -# define DL_LOAD(libname) dlopen(libname, RTLD_LAZY | RTLD_GLOBAL) +# ifndef RTLD_PARENT +# define RTLD_PARENT 0 +# endif + +# define DL_LOAD(libname) dlopen(libname, RTLD_LAZY | RTLD_GLOBAL | RTLD_PARENT) # define DL_UNLOAD dlclose # if DLSYM_NEEDS_UNDERSCORE # define DL_FETCH_SYMBOL(h,s) dlsym((h), _ s) 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/19937 -- Edit this bug report at http://bugs.php.net/?id=19937edit=1
