#31982 [Fbk->Opn]: child pid $PID exit signal Segmentation fault (11) Apache 2.0.53
ID: 31982 User updated by: taskazan at metu dot edu dot tr Reported By: taskazan at metu dot edu dot tr -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: debian-linux PHP Version: 4.3.10 New Comment: when we try the latest snapshot, given in the previous link, we saw segmentation fault in the error log again. When we debug the httpd process, again we get following logs: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10502)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821ee08 "�031\b", pool=0x821ee08) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821ee08 "�031\b", pool=0x821ee08) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init (mutex=0x821ee08, fname=0x821ee08 "�031\b", pool=0x821ee08) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821ee08, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821ee08, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136441352) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821ee08, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_pconf=0x819b4f8, plog=0x81d35d8, s=0x0) at worker.c:1617 #8 0x080c113f in main (argc=2, argv=0xbc64) at main.c:618 Previous Comments: [2005-02-15 12:58:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-02-15 11:08:35] taskazan at metu dot edu dot tr Description: We have used php4-apache2 series in our web servers without any problems until last week. This week when we upgrade apache2.0.50 to 2.0.53, httpd processes suddenly get killed by a segfault as seen below in the error_log: Mon Feb 14 17:14:26 2005] [notice] child pid 16788 exit signal Segmentation fault (11) [Mon Feb 14 17:14:26 2005] [notice] child pid 16787 exit signal Segmentation fault (11) [Mon Feb 14 17:14:27 2005] [notice] child pid 16789 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16802 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16801 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16800 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16791 exit signal Segmentation fault (11) ... There is no core file, so we try to debug httpd process with gdb. Here is the outputs: # gdb /usr/local/httpd-2.0.53/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run -X Starting program: /usr/local/httpd-2.0.53/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 27979)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd 98) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init mutex=0x821dd98, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821dd98, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821dd98, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136437144) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821dd98, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_pconf=0x819b4f8, plog=0x81d35d8, s=0x0) at worker.c:1617 #8 0x080c113f in main (argc=2, argv=0xbc74) at main.c:618 (gdb) Can anybody know what to do? Yours, feyza -- Edit this bug report at http://bugs.php.net/?id=31982&edit=1
#31249 [Opn->Asn]: bad type in zend_strtod.c
ID: 31249 Updated by: [EMAIL PROTECTED] Reported By: long+phpbugs at kestrel dot cc dot ku dot edu -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Tru64 4.0F PHP Version: 4CVS-2004-12-22 (stable) Assigned To: sniper Previous Comments: [2005-02-14 22:57:49] long+phpbugs at kestrel dot cc dot ku dot edu I'm still getting similar errors. I'm sending you an email containing the info you've requested. [2005-02-10 23:23:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip And it would help a lot if I could get an account on this machine and test stuff myself.. [2005-01-24 18:12:13] long+phpbugs at kestrel dot cc dot ku dot edu With php4-STABLE-200501241530 I now get: cc -IZend/ -I/homeb/long/src/php4-STABLE-200501241530/Zend/ -DPHP_ATOM_INC -I/homeb/long/src/php4-STABLE-200501241530/include -I/homeb/long/src/php4-STABLE-200501241530/main -I/homeb/long/src/php4-STABLE-200501241530 -I/homeb/long/src/php4-STABLE-200501241530/Zend -I/homeb/long/src/php4-STABLE-200501241530/ext/xml/expat -I/homeb/long/src/php4-STABLE-200501241530/TSRM -g -c /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c -o Zend/zend_strtod.o && echo > Zend/zend_strtod.lo cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 492: In this declaration, "int32_t" must specify a type. (badparsedecl) Long x, y; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 851: In this declaration, "int32_t" must specify a type. (badparsedecl) Long borrow, y; /* We need signed shifts here. */ ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 854: In this declaration, "int32_t" must specify a type. (badparsedecl) Long z; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 932: Missing ";". (nosemi) register Long L; --^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 1247: In this declaration, "int32_t" must specify a type. (badparsedecl) Long L; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 412: In this statement, "int32_t" is not declared. (undeclared) rv = (Bigint *)MALLOC(sizeof(Bigint) + (x-1)*sizeof(Long)); ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 472: In this statement, "int32_t" is not declared. (undeclared) Bcopy(b1, b); ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 494: In this statement, "x" is not declared. (undeclared) x = (nd + 8) / 9; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 495: In this statement, "y" is not declared. (undeclared) for(k = 0, y = 1; x > y; y <<= 1, k++) ; ---^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 881: In this statement, "borrow" is not declared. (undeclared) borrow = 0; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 884: In this statement, "y" is not declared. (undeclared) y = (*xa & 0x) - (*xb & 0x) + borrow; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 887: In this statement, "z" is not declared. (undeclared) z = (*xa++ >> 16) - (*xb++ >> 16) + borrow; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 894: In this statement, "y" is not declared. (undeclared) y = (*xa & 0x) + borrow; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 897: In this statement, "z" is not declared. (undeclared) z = (*xa++ >> 16) + borrow; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 936: In this statement, "L" is not declared. (undeclared) L = (word0(x) & Exp_mask) - (P-1)*Exp_msk1; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 1337: In this statement, "L" is not declared. (undeclared) L = c - '0'; ^ cc: Error: /homeb/long/src/php4-STABLE-200501241530/Zend/zend_strtod.c, line 1518: In this statement, "int32_t" is not declared. (undeclared) Bcopy(bd, bd0); ^ cc: Error:
#31965 [Opn->Ver]: PREG_SPLIT_NO_EMPTY strips non-empty pieces in some cases
ID: 31965
Updated by: [EMAIL PROTECTED]
Reported By: mikael at SPAMMENOTchl dot chalmers dot se
-Status: Open
+Status: Verified
Bug Type: PCRE related
-Operating System: Linux
+Operating System: *
-PHP Version: 4.3.8
+PHP Version: 4CVS, 5CVS (2005-02-15)
Previous Comments:
[2005-02-14 10:27:15] mikael at SPAMMENOTchl dot chalmers dot se
Description:
In some cases the preg_split strips non-empty pieces when the
PREG_SPLIT_NO_EMPTY flag i set. Specifically when using assertions only
to split on, eg. the string to split on itself is actually empty (but
not the pieces)
Reproduce code:
---
$terms = preg_split('/(?<=\d)(?=[a-zåäö])/', 'ser1ia456l', 0,
PREG_SPLIT_NO_EMPTY);
print_r($terms);
Expected result:
Array
(
[0] => ser1
[1] => ia456
[2] => l
)
Actual result:
--
Array
(
[0] => ser1
[1] => ia456
)
--
Edit this bug report at http://bugs.php.net/?id=31965&edit=1
#31984 [NEW]: sessions fail randomly, causes a segmentation fault in apache
From: root at mediamonks dot net Operating system: FreeBSD 4.11-STABLE PHP version: 5.0.3 PHP Bug Type: Session related Bug description: sessions fail randomly, causes a segmentation fault in apache Description: Apache 2.0.53 & mod_php5 5.0.3 Sessions occasionally work, but in two-thirds of the session requests an error is generated and the apache child segfaults. Error recorded in the logfile: PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 Error reported on site: Notice: Undefined variable: HTTP_SESSION_VARS in Notice: Undefined variable: _SESSION in in Warning: session_register() [function.session-register]: Cannot find save handler in Warning: session_register() [function.session-register]: Cannot find save handler in I'm using php.ini-recommended as php.ini. Tried commenting out session.save_handler, setting it to "files" and just files. Reproduce code: --- session_start(); -- Edit bug report at http://bugs.php.net/?id=31984&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31984&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31984&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31984&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31984&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31984&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31984&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31984&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31984&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31984&r=support Expected behavior: http://bugs.php.net/fix.php?id=31984&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31984&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31984&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31984&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31984&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31984&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31984&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31984&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31984&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31984&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31984&r=mysqlcfg
#31980 [Opn->Bgs]: Unable to Extract Windows XP EXIF Information
ID: 31980
Updated by: [EMAIL PROTECTED]
Reported By: sdteffen at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: EXIF related
Operating System: Windows XP
PHP Version: 4.3.10
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.
Thank you for your interest in PHP.
Works fine here when you really have mbstring loaded.
Please ask further support questions on the mailing lists.
Previous Comments:
[2005-02-15 13:18:33] sdteffen at gmail dot com
I just noticed that I mixed up
"Expected Result" and "Actual Result". It's
just the other way round.
Sorry for the confusion.
[2005-02-15 12:22:01] sdteffen at gmail dot com
Thanks for the comments.
I've updated my code according to Pierre's suggestion:
ini_set('exif.decode_unicode_intel', 'UCS-2LE');
ini_set('exif.encode_unicode','ISO-8859-1');
ini_set('exif.encode_jis','ISO-8859-1');
ini_set('exif.decode_jis_intel','ISO-8859-1');
$arrComment = exif_read_data('1.jpg', 'WINXP', true);
The problem still exists (Only first letter is returned).
Here's the example file:
http://sdteffen.de/1.jpg
[2005-02-15 10:19:19] [EMAIL PROTECTED]
> The constant EXIF_USE_MBSTRING is 0 - isn't this a
> contradiction with the PHP Manual that says
> "Windows users must also have the mbstring
> extension enabled"?
Loading the mbstring extension is one of the requirement, another is to
specify the encoding (See http://de.php.net/exif) using either php.ini
or ini_set.
If the problem remains, please provide a link to the image as
requested by Sniper.
--Pierre
[2005-02-15 10:11:26] [EMAIL PROTECTED]
Put that image file somewhere where we can download it and try
ourselves.
[2005-02-15 07:47:36] sdteffen at gmail dot com
Description:
I'm trying to extract EXIF information created by the Windows XP
Explorer (In particular the Comments field).
Dumping the array created by
exif_read_data('c:\test.jpg','WINXP',true);
includes the following result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
The problem is that the comment is not only the letter "G",
but a full sentence (starting with G).
Apparently, the comment is UNICODE (UCS-2?). I tried to
use mb_string (Loading php_mbstring.dll before php_exif.dll
like outlined in the PHP manual) without success.
The constant EXIF_USE_MBSTRING is 0 - isn't this a contradiction with
the PHP Manual that says
"Windows users must also have the mbstring extension enabled"?
If this is not a bug, please consider it as a request to
enhance the PHP Manual with a small example showing the
necessary php.ini configurations to use in conjuction with
Windows XP Explorer EXIF comments. Windows Explorer is the
most convenient application for our users to add EXIF comments.
PHP 4.3.10 Zipfile distribution, using the CGI (php.exe).
Reproduce code:
---
exif_read_data('c:\test.jpg','WINXP',true);
Expected result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
Actual result:
--
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "Generator and pump"
}
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#31980 [Bgs->Ver]: Unable to Extract Windows XP EXIF Information
ID: 31980
Updated by: [EMAIL PROTECTED]
Reported By: sdteffen at gmail dot com
-Status: Bogus
+Status: Verified
Bug Type: EXIF related
Operating System: Windows XP
PHP Version: 4.3.10
New Comment:
Nevermind, in windows the EXIF module isn't compiled with MBSTRING
support.
Previous Comments:
[2005-02-15 13:44:58] [EMAIL PROTECTED]
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.
Thank you for your interest in PHP.
Works fine here when you really have mbstring loaded.
Please ask further support questions on the mailing lists.
[2005-02-15 13:18:33] sdteffen at gmail dot com
I just noticed that I mixed up
"Expected Result" and "Actual Result". It's
just the other way round.
Sorry for the confusion.
[2005-02-15 12:22:01] sdteffen at gmail dot com
Thanks for the comments.
I've updated my code according to Pierre's suggestion:
ini_set('exif.decode_unicode_intel', 'UCS-2LE');
ini_set('exif.encode_unicode','ISO-8859-1');
ini_set('exif.encode_jis','ISO-8859-1');
ini_set('exif.decode_jis_intel','ISO-8859-1');
$arrComment = exif_read_data('1.jpg', 'WINXP', true);
The problem still exists (Only first letter is returned).
Here's the example file:
http://sdteffen.de/1.jpg
[2005-02-15 10:19:19] [EMAIL PROTECTED]
> The constant EXIF_USE_MBSTRING is 0 - isn't this a
> contradiction with the PHP Manual that says
> "Windows users must also have the mbstring
> extension enabled"?
Loading the mbstring extension is one of the requirement, another is to
specify the encoding (See http://de.php.net/exif) using either php.ini
or ini_set.
If the problem remains, please provide a link to the image as
requested by Sniper.
--Pierre
[2005-02-15 10:11:26] [EMAIL PROTECTED]
Put that image file somewhere where we can download it and try
ourselves.
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/31980
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#31980 [Ver->Asn]: Unable to Extract Windows XP EXIF Information
ID: 31980
Updated by: [EMAIL PROTECTED]
Reported By: sdteffen at gmail dot com
-Status: Verified
+Status: Assigned
Bug Type: EXIF related
Operating System: win32 only
PHP Version: 4CVS, 5CVS (2005-02-15)
-Assigned To:
+Assigned To: edink
New Comment:
Assigning to our win32 build guru..
Previous Comments:
[2005-02-15 13:48:00] [EMAIL PROTECTED]
Nevermind, in windows the EXIF module isn't compiled with MBSTRING
support.
[2005-02-15 12:22:01] sdteffen at gmail dot com
Thanks for the comments.
I've updated my code according to Pierre's suggestion:
ini_set('exif.decode_unicode_intel', 'UCS-2LE');
ini_set('exif.encode_unicode','ISO-8859-1');
ini_set('exif.encode_jis','ISO-8859-1');
ini_set('exif.decode_jis_intel','ISO-8859-1');
$arrComment = exif_read_data('1.jpg', 'WINXP', true);
The problem still exists (Only first letter is returned).
Here's the example file:
http://sdteffen.de/1.jpg
[2005-02-15 10:19:19] [EMAIL PROTECTED]
> The constant EXIF_USE_MBSTRING is 0 - isn't this a
> contradiction with the PHP Manual that says
> "Windows users must also have the mbstring
> extension enabled"?
Loading the mbstring extension is one of the requirement, another is to
specify the encoding (See http://de.php.net/exif) using either php.ini
or ini_set.
If the problem remains, please provide a link to the image as
requested by Sniper.
--Pierre
[2005-02-15 10:11:26] [EMAIL PROTECTED]
Put that image file somewhere where we can download it and try
ourselves.
[2005-02-15 07:47:36] sdteffen at gmail dot com
Description:
I'm trying to extract EXIF information created by the Windows XP
Explorer (In particular the Comments field).
Dumping the array created by
exif_read_data('c:\test.jpg','WINXP',true);
includes the following result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
The problem is that the comment is not only the letter "G",
but a full sentence (starting with G).
Apparently, the comment is UNICODE (UCS-2?). I tried to
use mb_string (Loading php_mbstring.dll before php_exif.dll
like outlined in the PHP manual) without success.
The constant EXIF_USE_MBSTRING is 0 - isn't this a contradiction with
the PHP Manual that says
"Windows users must also have the mbstring extension enabled"?
If this is not a bug, please consider it as a request to
enhance the PHP Manual with a small example showing the
necessary php.ini configurations to use in conjuction with
Windows XP Explorer EXIF comments. Windows Explorer is the
most convenient application for our users to add EXIF comments.
PHP 4.3.10 Zipfile distribution, using the CGI (php.exe).
Reproduce code:
---
exif_read_data('c:\test.jpg','WINXP',true);
Expected result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
Actual result:
--
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "Generator and pump"
}
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#31980 [Opn]: Unable to Extract Windows XP EXIF Information
ID: 31980
User updated by: sdteffen at gmail dot com
Reported By: sdteffen at gmail dot com
Status: Open
Bug Type: EXIF related
Operating System: Windows XP
PHP Version: 4.3.10
New Comment:
I just noticed that I mixed up
"Expected Result" and "Actual Result". It's
just the other way round.
Sorry for the confusion.
Previous Comments:
[2005-02-15 12:22:01] sdteffen at gmail dot com
Thanks for the comments.
I've updated my code according to Pierre's suggestion:
ini_set('exif.decode_unicode_intel', 'UCS-2LE');
ini_set('exif.encode_unicode','ISO-8859-1');
ini_set('exif.encode_jis','ISO-8859-1');
ini_set('exif.decode_jis_intel','ISO-8859-1');
$arrComment = exif_read_data('1.jpg', 'WINXP', true);
The problem still exists (Only first letter is returned).
Here's the example file:
http://sdteffen.de/1.jpg
[2005-02-15 10:19:19] [EMAIL PROTECTED]
> The constant EXIF_USE_MBSTRING is 0 - isn't this a
> contradiction with the PHP Manual that says
> "Windows users must also have the mbstring
> extension enabled"?
Loading the mbstring extension is one of the requirement, another is to
specify the encoding (See http://de.php.net/exif) using either php.ini
or ini_set.
If the problem remains, please provide a link to the image as
requested by Sniper.
--Pierre
[2005-02-15 10:11:26] [EMAIL PROTECTED]
Put that image file somewhere where we can download it and try
ourselves.
[2005-02-15 07:47:36] sdteffen at gmail dot com
Description:
I'm trying to extract EXIF information created by the Windows XP
Explorer (In particular the Comments field).
Dumping the array created by
exif_read_data('c:\test.jpg','WINXP',true);
includes the following result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
The problem is that the comment is not only the letter "G",
but a full sentence (starting with G).
Apparently, the comment is UNICODE (UCS-2?). I tried to
use mb_string (Loading php_mbstring.dll before php_exif.dll
like outlined in the PHP manual) without success.
The constant EXIF_USE_MBSTRING is 0 - isn't this a contradiction with
the PHP Manual that says
"Windows users must also have the mbstring extension enabled"?
If this is not a bug, please consider it as a request to
enhance the PHP Manual with a small example showing the
necessary php.ini configurations to use in conjuction with
Windows XP Explorer EXIF comments. Windows Explorer is the
most convenient application for our users to add EXIF comments.
PHP 4.3.10 Zipfile distribution, using the CGI (php.exe).
Reproduce code:
---
exif_read_data('c:\test.jpg','WINXP',true);
Expected result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
Actual result:
--
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "Generator and pump"
}
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#31981 [Opn->Fbk]: Crash in shutdown_memory_manager
ID: 31981 Updated by: [EMAIL PROTECTED] Reported By: asmi at owear dot ru -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: FreeBSD 4.8-RELEASE-p27 PHP Version: 4.3.10 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-02-15 10:58:02] asmi at owear dot ru Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit this bug report at http://bugs.php.net/?id=31981&edit=1
#31982 [Opn->Fbk]: child pid $PID exit signal Segmentation fault (11) Apache 2.0.53
ID: 31982 Updated by: [EMAIL PROTECTED] Reported By: taskazan at metu dot edu dot tr -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: debian-linux PHP Version: 4.3.10 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-02-15 11:08:35] taskazan at metu dot edu dot tr Description: We have used php4-apache2 series in our web servers without any problems until last week. This week when we upgrade apache2.0.50 to 2.0.53, httpd processes suddenly get killed by a segfault as seen below in the error_log: Mon Feb 14 17:14:26 2005] [notice] child pid 16788 exit signal Segmentation fault (11) [Mon Feb 14 17:14:26 2005] [notice] child pid 16787 exit signal Segmentation fault (11) [Mon Feb 14 17:14:27 2005] [notice] child pid 16789 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16802 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16801 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16800 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16791 exit signal Segmentation fault (11) ... There is no core file, so we try to debug httpd process with gdb. Here is the outputs: # gdb /usr/local/httpd-2.0.53/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run -X Starting program: /usr/local/httpd-2.0.53/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 27979)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd 98) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init mutex=0x821dd98, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821dd98, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821dd98, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136437144) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821dd98, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_pconf=0x819b4f8, plog=0x81d35d8, s=0x0) at worker.c:1617 #8 0x080c113f in main (argc=2, argv=0xbc74) at main.c:618 (gdb) Can anybody know what to do? Yours, feyza -- Edit this bug report at http://bugs.php.net/?id=31982&edit=1
#31440 [Ver]: [PATCH] GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 Updated by: [EMAIL PROTECTED] Reported By: john at jelsoft dot com Status: Verified Bug Type: Scripting Engine problem Operating System: * PHP Version: 4CVS, 5CVS (2005-02-15) New Comment: note: In HEAD you _can_ overwrite GLOBALS with this: script.php?GLOBALS=error but NOT with this: script.php?GLOBALS[php]=error Previous Comments: [2005-02-15 12:48:48] [EMAIL PROTECTED] Here are some patches I wrote to fix this: For PHP_4_3 branch: http://www.php.net/~jani/patches/bug31440.php_4_3_patch For HEAD branch: http://www.php.net/~jani/patches/bug31440.php_HEAD_patch [2005-02-01 20:09:52] john at jelsoft dot com Bug still remains in build dated Feb 1 2005 14:12:59. [2005-02-01 19:06:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-01-21 11:57:10] john at jelsoft dot com To reply to Iliaa, since my earlier comment was removed: this isn't fixed in 200501210530 build. To reproduce, you need to turn register_globals on. [2005-01-18 19:50:36] john at jelsoft dot com I have just downloaded the latest snapshot and the bug remains. Build date from my phpinfo() is Jan 18 2005 14:14:51. 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/31440 -- Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#31440 [Opn->Ver]: [PATCH] GLOBALS array overwritten from GET/POST/COOKIE vars
ID: 31440 Updated by: [EMAIL PROTECTED] -Summary: GLOBALS array overwritten from GET/POST/COOKIE vars Reported By: john at jelsoft dot com -Status: Open +Status: Verified Bug Type: Scripting Engine problem Operating System: * PHP Version: 4CVS, 5CVS (2005-02-15) New Comment: Here are some patches I wrote to fix this: For PHP_4_3 branch: http://www.php.net/~jani/patches/bug31440.php_4_3_patch For HEAD branch: http://www.php.net/~jani/patches/bug31440.php_HEAD_patch Previous Comments: [2005-02-01 20:09:52] john at jelsoft dot com Bug still remains in build dated Feb 1 2005 14:12:59. [2005-02-01 19:06:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-01-21 11:57:10] john at jelsoft dot com To reply to Iliaa, since my earlier comment was removed: this isn't fixed in 200501210530 build. To reproduce, you need to turn register_globals on. [2005-01-19 00:53:31] [EMAIL PROTECTED] Works fine with latest CVS. [2005-01-18 19:50:36] john at jelsoft dot com I have just downloaded the latest snapshot and the bug remains. Build date from my phpinfo() is Jan 18 2005 14:14:51. 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/31440 -- Edit this bug report at http://bugs.php.net/?id=31440&edit=1
#31980 [Fbk->Opn]: Unable to Extract Windows XP EXIF Information
ID: 31980
User updated by: sdteffen at gmail dot com
Reported By: sdteffen at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: EXIF related
Operating System: Windows XP
PHP Version: 4.3.10
New Comment:
Thanks for the comments.
I've updated my code according to Pierre's suggestion:
ini_set('exif.decode_unicode_intel', 'UCS-2LE');
ini_set('exif.encode_unicode','ISO-8859-1');
ini_set('exif.encode_jis','ISO-8859-1');
ini_set('exif.decode_jis_intel','ISO-8859-1');
$arrComment = exif_read_data('1.jpg', 'WINXP', true);
The problem still exists (Only first letter is returned).
Here's the example file:
http://sdteffen.de/1.jpg
Previous Comments:
[2005-02-15 10:19:19] [EMAIL PROTECTED]
> The constant EXIF_USE_MBSTRING is 0 - isn't this a
> contradiction with the PHP Manual that says
> "Windows users must also have the mbstring
> extension enabled"?
Loading the mbstring extension is one of the requirement, another is to
specify the encoding (See http://de.php.net/exif) using either php.ini
or ini_set.
If the problem remains, please provide a link to the image as
requested by Sniper.
--Pierre
[2005-02-15 10:11:26] [EMAIL PROTECTED]
Put that image file somewhere where we can download it and try
ourselves.
[2005-02-15 07:47:36] sdteffen at gmail dot com
Description:
I'm trying to extract EXIF information created by the Windows XP
Explorer (In particular the Comments field).
Dumping the array created by
exif_read_data('c:\test.jpg','WINXP',true);
includes the following result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
The problem is that the comment is not only the letter "G",
but a full sentence (starting with G).
Apparently, the comment is UNICODE (UCS-2?). I tried to
use mb_string (Loading php_mbstring.dll before php_exif.dll
like outlined in the PHP manual) without success.
The constant EXIF_USE_MBSTRING is 0 - isn't this a contradiction with
the PHP Manual that says
"Windows users must also have the mbstring extension enabled"?
If this is not a bug, please consider it as a request to
enhance the PHP Manual with a small example showing the
necessary php.ini configurations to use in conjuction with
Windows XP Explorer EXIF comments. Windows Explorer is the
most convenient application for our users to add EXIF comments.
PHP 4.3.10 Zipfile distribution, using the CGI (php.exe).
Reproduce code:
---
exif_read_data('c:\test.jpg','WINXP',true);
Expected result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
Actual result:
--
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "Generator and pump"
}
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#29683 [Com]: headers_list() func. return empty array
ID: 29683
Comment by: rd dot contact at free dot fr
Reported By: ca533512 at tiscali dot cz
Status: Open
Bug Type: Unknown/Other Function
Operating System: Win2k SP4
PHP Version: 5.0.1
New Comment:
Same bug on win xp and apache 2.52
Same code from PHP doc tested with today's (15 Fev 2005)
5.03
5.04dev
5.1.0dev
Previous Comments:
[2005-01-09 19:04:19] tiagojcb at hotmail dot com
Hi !
Server version: Apache/2.0.52
Server built: Oct 20 2004 11:51:56
Loaded Modules core mod_access mod_auth mod_include mod_log_config
mod_env mod_setenvif mod_ssl prefork http_core mod_mime mod_asis
mod_negotiation mod_dir mod_imap mod_actions mod_so mod_php5
PHP 5.0.3 (cli) (built: Jan 9 2005 15:46:57)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.3, Copyright (c) 1998-2004 Zend Technologies
If I run the example code from the CLI, it works.
>From apache it return an empty array.
It's running on a Slackware Linux and php was built with './configure'
'--with-apxs2=/usr/local/apache/bin/apxs' '--with-gd'
'--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-zlib'
'--enable-memory-limit' '--with-pgsql=/usr/local/pgsql'
'--prefix=/usr/local/php' '--without-mysql'
Thanks for any help.
[2004-08-24 06:38:42] [EMAIL PROTECTED]
This is also reproducible with Apache 1.3.x SAPI.
It happens because sapi_module.header_handler (particularly
sapi_apache_header_handler() with Apache 1.3.x) returns 0 instead of
SAPI_HEADER_ADD and headers just don't get to SG(sapi_headers).
[2004-08-23 19:59:52] ca533512 at tiscali dot cz
Apache 2.0.50
-- php: `original` for win32 from php.net
[2004-08-23 18:59:21] [EMAIL PROTECTED]
What SAPI are you using?
[2004-08-14 23:58:00] ca533512 at tiscali dot cz
Description:
If I try code from PHP docs of headers_list() function, browser print
only empty array.
or this function is not available on win OS ?
Reproduce code:
---
/* setcookie() will add a response header on its own */
setcookie('foo', 'bar');
/* Define a custom response header
This will be ignored by most clients */
header("X-Sample-Test: foo");
/* Specify plain text content in our response */
header('Content-type: text/plain');
/* What headers are going to be sent? */
var_dump(headers_list());
Expected result:
array(4) {
[0]=>
string(29) "X-Powered-By: PHP/5.0.0" // ... 5.0.1
[1]=>
string(19) "Set-Cookie: foo=bar"
[2]=>
string(18) "X-Sample-Test: foo"
[3]=>
string(24) "Content-type: text/plain"
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=29683&edit=1
#28866 [Fbk->Csd]: array of objs filling slowness
ID: 28866
User updated by: dmirand at abelia-decors dot com
Reported By: dmirand at abelia-decors dot com
-Status: Feedback
+Status: Closed
Bug Type: Performance problem
Operating System: Linux 2.4 / glibc 2.3
PHP Version: 5.0.0RC3
New Comment:
Much better now !
Need to say that my app has pretty much changed since the
bug report...
Thanks !
Previous Comments:
[2005-02-11 15:18:06] [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
[2004-06-21 13:15:36] dmirand at abelia-decors dot com
Description:
When running a portion of script which fills an array with
objects, it is easy to notice a significant slowness depending
on what has already run before in the script., even if that
"pre-processing" is totally independant . The more load that
runs before, the slower the filling will be...
Under 4.3.6 almost no differences between :
- a "just filling" script
- a big load followed by a "filling" part
Both 4.3.6 and 5.0.0 RC3 compiled from source.
Reproduce code:
---
$big_load = new BigLoad ;
$big_load->go() ;
unset( $big_load ) ;
/* Filling start */
$arr_obj_orders = array() ;
foreach( $arr_no_order as $no_order )
{
$obj_order = new Order ;
$obj_order->load( $no_order ) ;
// to show filling avancement
echo $no_order ;
$arr_obj_orders[$no_order] = $obj_order ;
}
/* Filling end */
Expected result:
The expected behavior is of course no slowness with the
"filling" part of the script, ie the same behavior as if there was
no big load before the filling part.
--
Edit this bug report at http://bugs.php.net/?id=28866&edit=1
#31981 [NEW]: Crash in shutdown_memory_manager
From: asmi at owear dot ru Operating system: FreeBSD 4.8-RELEASE-p27 PHP version: 4.3.10 PHP Bug Type: Reproducible crash Bug description: Crash in shutdown_memory_manager Description: SIGSERV in shutdown_memory_manager after WackoWiki script execution I cannot find the exact part of code leading to crash. Reproduce code: --- http://wackowiki.com/files/wacko.r4.zip Expected result: WackoWiki good working for me. Actual result: -- (gdb) run -X Starting program: /usr/local/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 491 REMOVE_POINTER_FROM_LIST(ptr); (gdb) p t $1 = (zend_mem_header *) 0xbfbfad74 (gdb) bt #0 0x2828df02 in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/ports/lang/php4/work/php-4.3.10/Zend/zend_alloc.c:491 #1 0x28272ff9 in php_request_shutdown (dummy=0x0) at /usr/ports/lang/php4/work/php-4.3.10/main/main.c:1003 #2 0x282b78ad in apache_php_module_main (r=0x8125304, display_source_mode=0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/sapi_apache.c:60 #3 0x282b8468 in send_php (r=0x8125304, display_source_mode=0, filename=0x0) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:621 #4 0x282b84c9 in send_parsed_php (r=0x8125304) at /usr/ports/lang/php4/work/php-4.3.10/sapi/apache/mod_php4.c:636 #5 0x8051fac in ap_invoke_handler (r=0x8125304) at http_config.c:475 #6 0x8061d71 in process_request_internal (r=0x8125304) at http_request.c:1298 #7 0x8062074 in ap_internal_redirect (new_uri=0x81252cc "/wacko/wakka.php?wakka=SsylkiNaUpravlenieSajjtami", r=0x8122034) at http_request.c:1435 #8 0x281b5d19 in handler_redirect (r=0x8122034) at mod_rewrite.c:1590 #9 0x8051fac in ap_invoke_handler (r=0x8122034) at http_config.c:475 #10 0x8061d71 in process_request_internal (r=0x8122034) at http_request.c:1298 #11 0x8061dd0 in ap_process_request (r=0x8122034) at http_request.c:1314 #12 0x805b19a in child_main (child_num_arg=0) at http_main.c:4786 #13 0x805b30c in make_child (s=0x8084034, slot=0, now=1108460485) at http_main.c:4901 #14 0x805b429 in startup_children (number_to_start=2) at http_main.c:4983 #15 0x805b97c in standalone_main (argc=2, argv=0xbfbffb84) at http_main.c:5315 #16 0x805c063 in main (argc=2, argv=0xbfbffb84) at http_main.c:5657 -- Edit bug report at http://bugs.php.net/?id=31981&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31981&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31981&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31981&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31981&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31981&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31981&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31981&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31981&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31981&r=support Expected behavior: http://bugs.php.net/fix.php?id=31981&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31981&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31981&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31981&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31981&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31981&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31981&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31981&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31981&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31981&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31981&r=mysqlcfg
#31982 [NEW]: child pid $PID exit signal Segmentation fault (11) Apache 2.0.53
From: taskazan at metu dot edu dot tr Operating system: debian-linux PHP version: 4.3.10 PHP Bug Type: Apache2 related Bug description: child pid $PID exit signal Segmentation fault (11) Apache 2.0.53 Description: We have used php4-apache2 series in our web servers without any problems until last week. This week when we upgrade apache2.0.50 to 2.0.53, httpd processes suddenly get killed by a segfault as seen below in the error_log: Mon Feb 14 17:14:26 2005] [notice] child pid 16788 exit signal Segmentation fault (11) [Mon Feb 14 17:14:26 2005] [notice] child pid 16787 exit signal Segmentation fault (11) [Mon Feb 14 17:14:27 2005] [notice] child pid 16789 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16802 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16801 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16800 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16791 exit signal Segmentation fault (11) ... There is no core file, so we try to debug httpd process with gdb. Here is the outputs: # gdb /usr/local/httpd-2.0.53/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run -X Starting program: /usr/local/httpd-2.0.53/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 27979)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd 98) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init mutex=0x821dd98, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821dd98, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821dd98, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136437144) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821dd98, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_pconf=0x819b4f8, plog=0x81d35d8, s=0x0) at worker.c:1617 #8 0x080c113f in main (argc=2, argv=0xbc74) at main.c:618 (gdb) Can anybody know what to do? Yours, feyza -- Edit bug report at http://bugs.php.net/?id=31982&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31982&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31982&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31982&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31982&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31982&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31982&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31982&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31982&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31982&r=support Expected behavior: http://bugs.php.net/fix.php?id=31982&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31982&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31982&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31982&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31982&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31982&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31982&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31982&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31982&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31982&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31982&r=mysqlcfg
#28397 [Bgs]: call-by-value on objects doesn't work
ID: 28397
User updated by: bobalong at gmx dot net
Reported By: bobalong at gmx dot net
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Redhat 9
PHP Version: 4.3.4
New Comment:
Look - like I said before, the reproduce script is as short as I can
make it. It's not difficult to get your head around, so if you can't be
bothered to take the time then that's your issue. I'm aware of your
rules regarding reproduce scripts, but due to the deep-seated nature of
the problem, in this case I hold that the reproduce script I submitted
is readable and usable.
I'm sure anyone who cares about objects in PHP4 would be interested in
this bug, but like I said in my last post, I would imagine at most of
those people have moved to PHP5 by now.
Keep up the good work!
Previous Comments:
[2005-02-15 01:52:15] [EMAIL PROTECTED]
Okay, so let's close this report until someone (you?) is able to
provide a shorter and more readable reproduce script, that clearly
decribes the problem.
[2005-02-12 11:56:18] bobalong at gmx dot net
Just to clarify, this is NOT a ZE2 bug - my mistake. I can't make the
reproduce script much shorter than it is, as it involves class
definitions and client code. I could remove the comments, but that's
not really what you're talking about, right?
Personally I've moved to PHP5 and found the object model to be
absoultely fine. If I were working on PHP4 bugs I would rationalise
that anyone looking for this kind of (fairly) advanced OO behaviour
would probably be using PHP5 by now anyway.
Cheers
Rob
[2005-02-11 20:34:12] [EMAIL PROTECTED]
Please provide a *short* but complete reproduce script.
Also, I don't get why it's a ZE2 bug if you're using 4.3.x.
[2004-05-14 13:59:49] bobalong at gmx dot net
Description:
I've created a user-defined list type - a bit like the ubiquitous
ArrayList - and wrapped it in another class, which exposes part of the
internal list's interface... OK, so nothing radical so far.
My problem is that when I make use of the list's exposed interface in
the wrapper class, it becomes a reference type for no apparent reason.
Another consequence, due to a previous bug
(http://bugs.php.net/bug.php?id=20993), is that if I pass the wrapper
object to a function that modifies the internal list, the original
object gets modified too, as though I'd passed it by reference!
Reproduce code:
---
internalArray, $obj);
}
function Remove($index)
{
unset($this -> internalArray[$index]);
}
}
//create a wrapper for the above list
Class MyListWrapper
{
var $myList;
function MyListWrapper()
{
$this -> myList = new MyList();
}
function AddItem($item)
{
$this -> myList -> Add($item);
}
function RemoveItem($index)
{
$this -> myList -> Remove($index);
}
}
//function that modifies the wrapper's internal list
function UpdateListWrapper($listWrapper)
{
$listWrapper -> RemoveItem(0);
}
//1. create a new wrapper object and dump
$listWrapper = new MyListWrapper();
var_dump($listWrapper);
//2. now add item to wrapper object and dump
$listWrapper -> AddItem("id");
var_dump($listWrapper); //notice the list is now a reference type
//3. now pass to modification function
UpdateListWrapper($listWrapper);
//4. see the original has been modified, as if
// call-by-reference had been used
var_dump($listWrapper);
?>
Expected result:
object(mylistwrapper)(1) {
["myList"]=>
object(mylist)(1) {
["internalArray"]=>
array(0) {
}
}
}
object(mylistwrapper)(1) {
["myList"]=>
object(mylist)(1) {
["internalArray"]=>
array(1) {
[0]=>
string(2) "id"
}
}
}
object(mylistwrapper)(1) {
["myList"]=>
object(mylist)(1) {
["internalArray"]=>
array(1) {
[0]=>
string(2) "id"
}
}
}
Actual result:
--
object(mylistwrapper)(1) {
["myList"]=>
object(mylist)(1) {
["internalArray"]=>
array(0) {
}
}
}
object(mylistwrapper)(1) {
["myList"]=>
&object(mylist)(1) {
["internalArray"]=>
array(1) {
[0]=>
string(2) "id"
}
}
}
object(mylistwrapper)(1) {
["myList"]=>
&object(mylist)(1) {
["internalArray"]=>
#31910 [Fbk->Opn]: A special string containing "E" causes an Unhandled Exception
ID: 31910 User updated by: jakub at icewarp dot com Reported By: jakub at icewarp dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: win32 / ISAPI PHP Version: 4CVS-2005-02-10 New Comment: It occurs on all Windows locales US, CZ. Reproduced it on W2000 and WXP. Please, try 4.3.10 or later Thank you Previous Comments: [2005-02-15 10:51:32] [EMAIL PROTECTED] If you think it might be that, than what's your locale? Nobody can reproduce it except you, so just don't sit & wait - run the code on another winblows box, try to get more info etc. [2005-02-15 07:39:13] jakub at icewarp dot com Yes it might be that... I can reproduce it since 4.3.10. [2005-02-14 21:48:19] plyrvt at mail dot ru Maybe this is related somehow to 4.3.10 Changelog: "Added the %F modifier to *printf to render a non-locale-aware representation of a float with the . as decimal separator." and is locale-dependent? [2005-02-14 21:17:17] plyrvt at mail dot ru "PHP has encountered an Unhandled Exception Code %d at %p" it's a part of php4isapi.dll file, but I cannot reproduce this bug neither under 4.3.8 nor 4.3.9 nor 5.0.2 (winxp-sp1-iis5.1) [2005-02-14 18:44:45] jakub at icewarp dot com Any news on the issue? 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/31910 -- Edit this bug report at http://bugs.php.net/?id=31910&edit=1
#31910 [Opn->Fbk]: A special string containing "E" causes an Unhandled Exception
ID: 31910 Updated by: [EMAIL PROTECTED] Reported By: jakub at icewarp dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: win32 / ISAPI PHP Version: 4CVS-2005-02-10 New Comment: If you think it might be that, than what's your locale? Nobody can reproduce it except you, so just don't sit & wait - run the code on another winblows box, try to get more info etc. Previous Comments: [2005-02-15 07:39:13] jakub at icewarp dot com Yes it might be that... I can reproduce it since 4.3.10. [2005-02-14 21:48:19] plyrvt at mail dot ru Maybe this is related somehow to 4.3.10 Changelog: "Added the %F modifier to *printf to render a non-locale-aware representation of a float with the . as decimal separator." and is locale-dependent? [2005-02-14 21:17:17] plyrvt at mail dot ru "PHP has encountered an Unhandled Exception Code %d at %p" it's a part of php4isapi.dll file, but I cannot reproduce this bug neither under 4.3.8 nor 4.3.9 nor 5.0.2 (winxp-sp1-iis5.1) [2005-02-14 18:44:45] jakub at icewarp dot com Any news on the issue? [2005-02-11 10:13:33] jakub at icewarp dot com I did some more tests and it is true I could not reproduce it in command line using php.exe (CGI). It is a subject of the ISAPI interface only then. Did you test ISAPI? 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/31910 -- Edit this bug report at http://bugs.php.net/?id=31910&edit=1
#31976 [Opn->Bgs]: Accessing overloaded member via foreach does not work
ID: 31976
Updated by: [EMAIL PROTECTED]
Reported By: adove at booyahnetworks dot com
-Status: Open
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: WinXP
PHP Version: 5.0.3
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See #29378.
Previous Comments:
[2005-02-15 02:00:32] adove at booyahnetworks dot com
Description:
Using an overloaded property from an object instance directly in a
foreach fails. If you assign the property (or a reference to it) to a
variable first it works fine. This is reproducable.
Interestingly enough, I see a strange problem with inheritance and
overloaded members. I am unable to reproduce it in a simple example. I
will continue to work that. Basically, you get the same fatal error as
here BUT on assignment to a member variable of the parent class that is
not overloaded. It's bizzare. As soon as I remove the __get/__set from
the child, the parent method works fine again from an instance of
child. Again, simple examples do not seem to reproduce.
Reproduce code:
---
class Son
{
protected $m_aActions;
function __construct(&$aActions)
{
$this->m_aActions = $aActions;
}
function __get($mName)
{
$mRetval = null;
switch($mName)
{
case("Actions"):
{
$mRetval = $this->m_aActions;
break;
}
}
return $mRetval;
}
}
$aActions = array("add", "delete");
$oSon = new Son($aActions);
$aActions = $oSon->Actions;
var_dump($aActions);
foreach($oSon->Actions as $strAction)
{
echo $strAction . "\n";
}
Expected result:
array(2) {
[0]=>
string(3) "add"
[1]=>
string(6) "delete"
}
add
delete
Actual result:
--
array(2) {
[0]=>
string(3) "add"
[1]=>
string(6) "delete"
}
Fatal error: Cannot access undefined property for object with
overloaded property access
--
Edit this bug report at http://bugs.php.net/?id=31976&edit=1
#31980 [Opn->Fbk]: Unable to Extract Windows XP EXIF Information
ID: 31980
Updated by: [EMAIL PROTECTED]
Reported By: sdteffen at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: EXIF related
Operating System: Windows XP
PHP Version: 4.3.10
New Comment:
> The constant EXIF_USE_MBSTRING is 0 - isn't this a
> contradiction with the PHP Manual that says
> "Windows users must also have the mbstring
> extension enabled"?
Loading the mbstring extension is one of the requirement, another is to
specify the encoding (See http://de.php.net/exif) using either php.ini
or ini_set.
If the problem remains, please provide a link to the image as
requested by Sniper.
--Pierre
Previous Comments:
[2005-02-15 10:11:26] [EMAIL PROTECTED]
Put that image file somewhere where we can download it and try
ourselves.
[2005-02-15 07:47:36] sdteffen at gmail dot com
Description:
I'm trying to extract EXIF information created by the Windows XP
Explorer (In particular the Comments field).
Dumping the array created by
exif_read_data('c:\test.jpg','WINXP',true);
includes the following result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
The problem is that the comment is not only the letter "G",
but a full sentence (starting with G).
Apparently, the comment is UNICODE (UCS-2?). I tried to
use mb_string (Loading php_mbstring.dll before php_exif.dll
like outlined in the PHP manual) without success.
The constant EXIF_USE_MBSTRING is 0 - isn't this a contradiction with
the PHP Manual that says
"Windows users must also have the mbstring extension enabled"?
If this is not a bug, please consider it as a request to
enhance the PHP Manual with a small example showing the
necessary php.ini configurations to use in conjuction with
Windows XP Explorer EXIF comments. Windows Explorer is the
most convenient application for our users to add EXIF comments.
PHP 4.3.10 Zipfile distribution, using the CGI (php.exe).
Reproduce code:
---
exif_read_data('c:\test.jpg','WINXP',true);
Expected result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
Actual result:
--
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "Generator and pump"
}
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#31980 [Opn]: Unable to Extract Windows XP EXIF Information
ID: 31980
Updated by: [EMAIL PROTECTED]
Reported By: sdteffen at gmail dot com
Status: Open
Bug Type: EXIF related
Operating System: Windows XP
PHP Version: 4.3.10
New Comment:
Put that image file somewhere where we can download it and try
ourselves.
Previous Comments:
[2005-02-15 07:47:36] sdteffen at gmail dot com
Description:
I'm trying to extract EXIF information created by the Windows XP
Explorer (In particular the Comments field).
Dumping the array created by
exif_read_data('c:\test.jpg','WINXP',true);
includes the following result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
The problem is that the comment is not only the letter "G",
but a full sentence (starting with G).
Apparently, the comment is UNICODE (UCS-2?). I tried to
use mb_string (Loading php_mbstring.dll before php_exif.dll
like outlined in the PHP manual) without success.
The constant EXIF_USE_MBSTRING is 0 - isn't this a contradiction with
the PHP Manual that says
"Windows users must also have the mbstring extension enabled"?
If this is not a bug, please consider it as a request to
enhance the PHP Manual with a small example showing the
necessary php.ini configurations to use in conjuction with
Windows XP Explorer EXIF comments. Windows Explorer is the
most convenient application for our users to add EXIF comments.
PHP 4.3.10 Zipfile distribution, using the CGI (php.exe).
Reproduce code:
---
exif_read_data('c:\test.jpg','WINXP',true);
Expected result:
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "G"
}
Actual result:
--
["WINXP"]=>
array(1) {
["Comments"]=>
string(1) "Generator and pump"
}
--
Edit this bug report at http://bugs.php.net/?id=31980&edit=1
#29956 [Asn->Csd]: support for s390 architecture in aclocal.m4 and configure script
ID: 29956 Updated by: [EMAIL PROTECTED] Reported By: mark dot post at eds dot com -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 4CVS, 5CVS (2005-02-14) Assigned To: sniper New Comment: 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. Previous Comments: [2005-02-14 22:54:42] [EMAIL PROTECTED] I have some patches to commit for libtool which fix this one too. [2004-09-02 18:47:30] mark dot post at eds dot com Description: For some time now, I've been having problems with building PHP on Linux/390. The Apache module would not build because libtool was having problems. I finally tracked the problem down to the aclocal.m4 file (and the resulting configure script). The following patch should be applied to PHP 5.0.0 (and later versions) to enable correct building on Linux/390. --- aclocal.m4.orig 2004-07-13 15:13:14.0 -0400 +++ aclocal.m4 2004-09-02 12:44:12.0 -0400 @@ -5315,7 +5315,7 @@ # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64*) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* | s390*) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM -- Edit this bug report at http://bugs.php.net/?id=29956&edit=1
#31984 [Opn]: sessions fail randomly, causes a segmentation fault in apache
ID: 31984 User updated by: root at mediamonks dot net Reported By: root at mediamonks dot net Status: Open Bug Type: Session related Operating System: FreeBSD 4.11-STABLE PHP Version: 5.0.3 New Comment: with notices on the log file records: PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 [Tue Feb 15 14:27:45 2005] [notice] child pid 83780 exit signal Segmentation fault (11) [Tue Feb 15 14:27:45 2005] [notice] child pid 83776 exit signal Segmentation fault (11) [Tue Feb 15 14:27:45 2005] [notice] child pid 83710 exit signal Segmentation fault (11) PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 [Tue Feb 15 14:27:48 2005] [notice] child pid 83752 exit signal Segmentation fault (11) [Tue Feb 15 14:27:48 2005] [notice] child pid 83713 exit signal Segmentation fault (11) Previous Comments: [2005-02-15 13:44:44] root at mediamonks dot net Description: Apache 2.0.53 & mod_php5 5.0.3 Sessions occasionally work, but in two-thirds of the session requests an error is generated and the apache child segfaults. Error recorded in the logfile: PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 Error reported on site: Notice: Undefined variable: HTTP_SESSION_VARS in Notice: Undefined variable: _SESSION in in Warning: session_register() [function.session-register]: Cannot find save handler in Warning: session_register() [function.session-register]: Cannot find save handler in I'm using php.ini-recommended as php.ini. Tried commenting out session.save_handler, setting it to "files" and just files. Reproduce code: --- session_start(); -- Edit this bug report at http://bugs.php.net/?id=31984&edit=1
#31985 [NEW]: Uploading on Windows
From: mshuffle at bournemouth dot ac dot uk
Operating system: redhat linux server
PHP version: Irrelevant
PHP Bug Type: Unknown/Other Function
Bug description: Uploading on Windows
Description:
My Web Host is running PHP 4.3.11-dev on redhat linux.
When windows users try to upload files to the server, it
takes the full file path C:\fullFilePath\filename.ext.As
a result the file is not uploaded and therefore isn't
working.
The code was working on a previous version of PHP. The
host has just upgraded their version of PHP.
Is this a stable release? Your PHP version drop menu
doesn't have this version.
Reproduce code:
---
if ($error == "") {
if (is_uploaded_file($imgtemp)){
move_uploaded_file($imgtemp,
fusion_basedir."fusion_images/".$imgname);
chmod(fusion_basedir."fusion_images/".$imgname,0644);
echo "
Expected result:
a file uploaded to the server.
Actual result:
--
C:\\WINNT\\Profiles\\mshuffle\\Desktop\\street.jpg
--
Edit bug report at http://bugs.php.net/?id=31985&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31985&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31985&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31985&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31985&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31985&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31985&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31985&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31985&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31985&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31985&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31985&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31985&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31985&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31985&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31985&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31985&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31985&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31985&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31985&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31985&r=mysqlcfg
#31876 [Fbk->Csd]: Inconsistant Behaviour With ncurses_mvwaddstr
ID: 31876 User updated by: dgrimes at scvl dot com Reported By: dgrimes at scvl dot com -Status: Feedback +Status: Closed Bug Type: ncurses related Operating System: SCO OpenServer 5 PHP Version: 4.3.10 New Comment: OK... I figured out the problem. I was running all of the correct versions of code and libraries. My problems stemmed from improperly setup terminfo entries in my terminfo database AND the terminal emulator was incompatible with the TERM setup I was using. It was a combination of two issues. But I have got it working just fine now. So I have closed this bug report. Sorry for reporting a false issue. I'm very new to ncurses and I still have a lot to learn. Right new everything is work fine. Dean Previous Comments: [2005-02-10 15:07:28] [EMAIL PROTECTED] Works just fine for me using latest CVS checkout of PHP_4_3 branch. Installed ncurses version: 5.4 Are you sure it isn't a bug in the ncurses version you have in your system..? [2005-02-07 22:08:10] dgrimes at scvl dot com Description: When setting reverse video on and outputting a string, mvwaddstr doesn't always out put the entire string. If the end of the string being output is more than 6 spaces than the readable text in the string, the reverse video will only apply to the readable characters in the string. Are you confused yet? OK: Have a string 'test ', the full length of the string will be in reverse video including the trailing spaces. If we have string that is 'test ', only the word test will be in reverse video but the trailing spaces will not be in reverse video. Remove one of the spaces and then the whole string will be in reverse video. You can use strings that consist only of spaces and get the same results. Reproduce code: --- Expected result: I would expect the entire length of the string to be in reverse video. What I'm trying to do is make each area of the screen that is an input field to be easily identified. -- Edit this bug report at http://bugs.php.net/?id=31876&edit=1
#31985 [Opn->Fbk]: Uploading on Windows
ID: 31985
Updated by: [EMAIL PROTECTED]
Reported By: mshuffle at bournemouth dot ac dot uk
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: redhat linux server
PHP Version: Irrelevant
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2005-02-15 15:20:08] mshuffle at bournemouth dot ac dot uk
Description:
My Web Host is running PHP 4.3.11-dev on redhat linux.
When windows users try to upload files to the server, it
takes the full file path C:\fullFilePath\filename.ext.As
a result the file is not uploaded and therefore isn't
working.
The code was working on a previous version of PHP. The
host has just upgraded their version of PHP.
Is this a stable release? Your PHP version drop menu
doesn't have this version.
Reproduce code:
---
if ($error == "") {
if (is_uploaded_file($imgtemp)){
move_uploaded_file($imgtemp,
fusion_basedir."fusion_images/".$imgname);
chmod(fusion_basedir."fusion_images/".$imgname,0644);
echo "
Expected result:
a file uploaded to the server.
Actual result:
--
C:\\WINNT\\Profiles\\mshuffle\\Desktop\\street.jpg
--
Edit this bug report at http://bugs.php.net/?id=31985&edit=1
#31986 [NEW]: exif_read_data incorrectly calculates nesting_level, throwing warnings
From: dpark at mit dot edu
Operating system: Linux
PHP version: 4CVS-2005-02-15 (stable)
PHP Bug Type: EXIF related
Bug description: exif_read_data incorrectly calculates nesting_level, throwing
warnings
Description:
Related to #31797? exif_read_data is still throwing the same warnings as
in #31797 on every camera-created image I give it (for cameras both new
and old, cheap and expensive).
The Debian package in question is actually based off the 2005-02-06 4CVS
snapshot, which is later than the time at which #31797 was reported to be
fixed in 4CVS. Adam Conrad, the package maintainer, confirms the bug is
in PHP, and can reproduce the problem with his own camera-created images.
Quoting an email from Adam Conrad:
Danny Park said:
> Anyway, when you say the nesting limit was increased from 5 to 25, are
> you saying 4.3.10-3 reflects that increase?
Indeed, it does. However, it seems that the way the code's written, the
nesting_level increases quite rapidly, and obviously takes on a different
meaning than the original developer thought it had.
As an example your 5 images all work fine with jhead(1), which has a
hardcoded directory nesting limit of *5*. However, with some debug
statements thrown into PHP's exif.c, we're reaching nesting levels of:
img_0949.jpg: 53
P1000415.JPG: 54
IMG_0669.JPG: 65
DSC00804.JPG: 48
dcp00884.jpg: 38
I don't currently have the time to hunt down what upstream's doing wrong
here, so I would encourage you to (re)file this bug upstream, and you're
welcome to quote this whole message.
I recommend they have a look at what jhead(1) is considering "directory
nesting" and mimic it, since PHP's obviously doing something a bit
differently.
If it doesn't get fixed properly upstream in a relatively timely fashion,
I'll make sure the next Debian packages uploaded either revert this
change, or hack MAX_IFD_NESTING_LEVEL to be something ridiculously high,
like 250. I'll test with some pro cameras lying around the house here to
see just how much higher we can get before I do that.
A second email from Adam Conrad:
Woo. An image from my EOS 300D gets the counter up to 75. I'm just going
to set it at 250 in the next upload. :)
You should still talk to upsteam about unbreaking this, as it LOOKS like
they're incrementing the counter at altogether the wrong bounday.
Reproduce code:
---
$url =
"http://dpark.mitacf.org/pix/pics/mit04/danny/03-sly_foliage/img_0949.jpg";;
print("\n\ntest img 1 - canon powershot S45\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit05/janice/01-christmas/P1000415.JPG";;
print("\n\ntest img 2 - panasonic DMC-FZ20\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit04/fslee/08-usgl_beach_sunrise/IMG_0669.JPG";;
print("\n\ntest img 3 - powershot S1 IS\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit04/chking/01-ivcf_sound_closet/DSC00804.JPG";;
print("\n\ntest img 4 - sony cybershot\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit00/dannys_camera/08-burton5-asbestos-evac/dcp00884.jpg";;
print("\n\ntest img 5 - kodak DC210\n");
$data = exif_read_data($url);
print_r($data);
Expected result:
Output of the print and print_r statements.
Actual result:
--
Output of the print and print_r statements interspersed with
"Warning: exif_read_data(imagefilename.jpg): corrupt EXIF header:
maximum directory nesting level reached in /path/to/script on line
line in script"
Each image produces two or three such warnings.
--
Edit bug report at http://bugs.php.net/?id=31986&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31986&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31986&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31986&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31986&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31986&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31986&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31986&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31986&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31986&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31986&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31986&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31986&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31986&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31986&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31986&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31986&r
#29583 [Fbk->Opn]: com_dotnet crashes when trying to strlen
ID: 29583
User updated by: edwin at rabbito dot org
Reported By: edwin at rabbito dot org
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Windows
-PHP Version: 5CVS-2004-08-25 (dev)
+PHP Version: 5CVS-2005-02-15 (dev)
New Comment:
Works after applying "msisolak at yahoo dot com"'s patch on latest CVS
Previous Comments:
[2005-02-15 00:26:40] [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
[2004-09-02 21:00:44] msisolak at yahoo dot com
I've dug into the COM error reported here and believe I have discovered
the issue. The problem is that com_object_cast() (in com_handlers.c)
assumes that the readobj and writeobj parameters will never be the same
object. That appears to work fine, except when the type conversion
request comes from the convert_object_to_type() macro
(zend_operators.c, line 264). In this case readobj == writeobj and we
end up with an access violation. Since _convert_to_string() uses
convert_object_to_type(), and _convert_to_string() is used when you try
to strlen() an object, com_object_cast() fails in the code from this bug
report.
Based on using sxe_object_cast() from the SimpleXML extension as a
example, I think that the freeing of the writeobj needs to be the last
thing done in the function rather than the first. The attached patch
uses that function as a model to move the zval_dtor() call to the end.
I also feel that the ZVAL_NULL(writeobj) should move after the
CDNO_FETCH(readobj). It seems to work as is, but only becuase
CDNO_FETCH() isn't checking that what is passed to it is really an
object.
I've played with this patch some and it seems to be holding, but I'm
looking at this with limited understanding of how the objects are
really being passed around so there may be an interaction here I'm not
seeing. With the patch applied, this PHP code:
echo strlen($rs->Fields(0)->Value), "\n";
echo date("F j, Y", variant_date_to_timestamp($rs->Fields(0)->Value)),
"\n";
echo date("F j, Y", variant_date_to_timestamp($rs->Fields(0))), "\n";
echo $rs->Fields(0)->Value, "\n";
echo $rs->Fields(0), "\n";
returns correct values in all five cases (for my test database):
8
January 1, 2001
January 1, 2001
1/1/2001
1/1/2001
--- php-5.0.1\ext\com_dotnet\com_handlers.c Wed Jul 28 19:48:26 2004
+++ com_handlers.c Thu Aug 19 15:18:45 2004
@@ -521,17 +521,17 @@
static int com_object_cast(zval *readobj, zval *writeobj, int type,
int should_free TSRMLS_DC)
{
+ zval free_obj;
php_com_dotnet_object *obj;
VARIANT v;
VARTYPE vt = VT_EMPTY;
if (should_free) {
- zval_dtor(writeobj);
+ free_obj = *writeobj;
}
- ZVAL_NULL(writeobj);
-
obj = CDNO_FETCH(readobj);
+ ZVAL_NULL(writeobj);
VariantInit(&v);
if (V_VT(&obj->v) == VT_DISPATCH) {
@@ -569,6 +569,9 @@
php_com_zval_from_variant(writeobj, &v, obj->code_page TSRMLS_CC);
VariantClear(&v);
+ if (should_free) {
+ zval_dtor(&free_obj);
+ }
return SUCCESS;
}
[2004-08-25 04:53:32] edwin at rabbito dot org
Same error as of 2004-08-25:
Application Error -
The instruction at "0x009dab5e" referenced memory at "0x0003". The
memory could not be "read".
[2004-08-10 03:46:16] edwin at rabbito dot org
ie)
php.exe - Application Error
The instruction at "0x1008a9de" referenced memory at "0x0003". The
memory could not be "read".
[2004-08-10 03:22:19] edwin at rabbito dot org
There is no output from the CLI, apart from the Dr. Watson exception
dialog:
An application error has occurred and an application error log is being
generated.
php.exe
Exception: access violation (0xc005), Address: 0x1008a9de.
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/29583
--
Edit this bug report at http://bugs.php.net/?id=29583&edit=1
#31982 [Opn->Bgs]: child pid $PID exit signal Segmentation fault (11) Apache 2.0.53
ID: 31982 Updated by: [EMAIL PROTECTED] Reported By: taskazan at metu dot edu dot tr -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: debian-linux PHP Version: 4.3.10 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Per ASF bugzilla, this is a mod_ldap bug. Previous Comments: [2005-02-15 14:20:08] taskazan at metu dot edu dot tr when we try the latest snapshot, given in the previous link, we saw segmentation fault in the error log again. When we debug the httpd process, again we get following logs: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 10502)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821ee08 "�031\b", pool=0x821ee08) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821ee08 "�031\b", pool=0x821ee08) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init (mutex=0x821ee08, fname=0x821ee08 "�031\b", pool=0x821ee08) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821ee08, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821ee08, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136441352) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821ee08, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_pconf=0x819b4f8, plog=0x81d35d8, s=0x0) at worker.c:1617 #8 0x080c113f in main (argc=2, argv=0xbc64) at main.c:618 [2005-02-15 12:58:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-02-15 11:08:35] taskazan at metu dot edu dot tr Description: We have used php4-apache2 series in our web servers without any problems until last week. This week when we upgrade apache2.0.50 to 2.0.53, httpd processes suddenly get killed by a segfault as seen below in the error_log: Mon Feb 14 17:14:26 2005] [notice] child pid 16788 exit signal Segmentation fault (11) [Mon Feb 14 17:14:26 2005] [notice] child pid 16787 exit signal Segmentation fault (11) [Mon Feb 14 17:14:27 2005] [notice] child pid 16789 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16802 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16801 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16800 exit signal Segmentation fault (11) [Mon Feb 14 17:14:28 2005] [notice] child pid 16791 exit signal Segmentation fault (11) ... There is no core file, so we try to debug httpd process with gdb. Here is the outputs: # gdb /usr/local/httpd-2.0.53/bin/httpd GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run -X Starting program: /usr/local/httpd-2.0.53/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 27979)] apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd 98) at proc_mutex.c:818 818 proc_mutex.c: No such file or directory. in proc_mutex.c (gdb) bt #0 apr_proc_mutex_child_init (mutex=0x4, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at proc_mutex.c:818 #1 0x4014abd2 in apr_global_mutex_child_init mutex=0x821dd98, fname=0x821dd98 "\xef\xbf\xbd031\b", pool=0x821dd98) at global_mutex.c:88 #2 0x0807f986 in util_ldap_child_init (p=0x821dd98, s=0x81d86d0) at util_ldap.c:1615 #3 0x080bb90d in ap_run_child_init (pchild=0x821dd98, s=0x81d86d0) at config.c:150 #4 0x080b901f in child_main (child_num_arg=136437144) at worker.c:1104 #5 0x080b93a6 in make_child (s=0x821dd98, slot=0) at worker.c:1248 #6 0x080b9439 in startup_children (number_to_start=0) at worker.c:1302 #7 0x080b9e7a in ap_mpm_run (_
#30962 [Com]: Space being returned for NULL columns
ID: 30962 Comment by: erudd at netfor dot com Reported By: richard dot quadling at bandvulc dot co dot uk Status: Open Bug Type: MSSQL related Operating System: Windows XP Pro SP2 PHP Version: 5.0.3 New Comment: -- The reason I say this, is that if I make the column NULL, -- then I get NULL. If I make the column an empty string -- (i.e. select all and then delete - doing this in -- Enterprise Manager), I get a space in the result set! I recently came across this issue when upgrading to the lastest FreeTDS and the lastet PHP 4.3.x connecting to MS SQL Server 2000. The issue was actualy not php, as it was easily fixed by editing the freetds.conf and set the global "tds version" from 4.2 to 7.0 and the space issue went away. Previous Comments: [2005-01-12 21:15:26] public at nexia dot ca I second the request by wchannospam at tomoye dot com to port this bug fix to 4.3.x stream. Its causing major issues for my PHP apps on Windows. [2005-01-12 21:02:43] wchannospam at tomoye dot com This problem is also appearing in PHP 4.3.x where x>=4. Can you implement the same fix there as well. Thank you very much. [2004-12-16 11:39:16] richard dot quadling at bandvulc dot co dot uk Simple test script to show the problem. ' . var_export($row, True) . 'Length of ' . $row['username'] . '\'s user_icq = ' . strlen($row['user_icq']) . ''; } mssql_free_result($rResults); mssql_close($rConn); ?> Requires phpBB and at least 1 user defined with an ICQ number. Obviously, you could choose any field or any other MS SQL database. Richard. [2004-12-16 11:32:42] richard dot quadling at bandvulc dot co dot uk Back again in V5.0.3! Or should that be still here? I notice that the version of the code now tests to see if the length is 0 before the conversion of the data to its appropriate type. Is it possible, that there is a distinction between NULL and 0? My C knowledge says no. NULL is 0, but I may be wrong! The reason I say this, is that if I make the column NULL, then I get NULL. If I make the column an empty string (i.e. select all and then delete - doing this in Enterprise Manager), I get a space in the result set! Argh! Is there ANY way a debug version could be built that reported that the code that has been modified is actually called. I'd really like to know what length IS being returned if the field is empty. I am more than willing to help get this fixed, but I need some hand holding in getting MSVC++ setup appropriately. I do not know what additional tools I need. I am in the process of downloading Cygwin to start some work on the PHP documentation (just getting the CHM compiled first!). [2004-12-03 03:27:19] [EMAIL PROTECTED] 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. 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/30962 -- Edit this bug report at http://bugs.php.net/?id=30962&edit=1
#31967 [Opn->Bgs]: mysql_fetch_field() reports weird table names on SHOW queries
ID: 31967 User updated by: me at derrabus dot de Reported By: me at derrabus dot de -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Linux 2.6 PHP Version: 5.0.3 New Comment: As I figured out, it's not a php problem. I could reproduce this with MySQL's C API, too. Previous Comments: [2005-02-14 11:40:41] me at derrabus dot de Description: I am running php 5.0.3 and MySQL 5.0.2 on my machine. The MySQL extension is compiled against a MySQL 5.0.2 client library. The code below returns weird table names (like #sql_f85_0) although the query should not affect any tables. So far, I could reproduce the problem with "SHOW TABLES" and "SHOW TABLE STATUS". If I do the same on my other machine (php 5.0.3, MySQL server & client API 4.0.22), the returned table name is empty (as it should, imho). I don't know if this is a bug of the MySQL extension or MySQL's C API, but since I cannot debug the C API right now, I'm posting this here. Reproduce code: --- Expected result: [table] should be empty. Actual result: -- stdClass Object ( [name] => Tables_in_test [table] => #sql_f85_0 [def] => [max_length] => 2 [not_null] => 1 [primary_key] => 0 [multiple_key] => 0 [unique_key] => 0 [numeric] => 0 [blob] => 0 [type] => string [unsigned] => 0 [zerofill] => 0 ) -- Edit this bug report at http://bugs.php.net/?id=31967&edit=1
#31987 [NEW]: phpinfo() crash PHP when --enable-zend-multibyte is enabled on Win-XP
From: [EMAIL PROTECTED] Operating system: Windows XP PRo SP2 PHP version: 5CVS-2005-02-15 (dev) PHP Bug Type: mbstring related Bug description: phpinfo() crash PHP when --enable-zend-multibyte is enabled on Win-XP Description: When ZEND_MULTIBYTE option is defined on Windows XP Pro SP2, and PHP is compiled as Apache 2 module, PHP 5.0.x break up by phpinfo(). Here is backtrace by VC6++ for PHP 5.0.4dev, zif_phpinfo() -> php_print_info(-1 TSRMLS_CC); -> zend_html_puts(zend_version, strlen(zend_verison TSRMLS_CC) -> (L66) LANG_SCNG(output_filter)(&filtered, &filtered_len, s, len TSRMLS_CC) filtered = 0x ""; &filtered = 0x04fcf54c filtered_len = -858993460 s = "Zend Engine v2.1.0-dev,..." len = 66 Reproduce code: --- Expected result: php releated info. Actual result: -- PHP 5.0.4dev executed as Apache 2 module will crash. -- Edit bug report at http://bugs.php.net/?id=31987&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31987&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31987&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31987&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31987&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31987&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31987&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31987&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31987&r=support Expected behavior: http://bugs.php.net/fix.php?id=31987&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31987&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31987&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31987&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31987&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31987&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31987&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31987&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31987&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31987&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31987&r=mysqlcfg
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I also put together a patch for the PHP_4_3 branch:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.4_3.diff
It hasn't been tested, but looking at the source of the MySQL extension
makes me think it should work.
Though the script I put in the "Reproduce code" section above doesn't
test what happens with empty strings, I subsequently tested the
behavior and everything works fine.
Previous Comments:
[2005-02-15 02:36:44] danielc at analysisandsolutions dot com
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query("INSERT INTO blah VALUES (1, 'a')", $con);
msql_query("INSERT INTO blah VALUES (2, NULL)", $con);
msql_query("INSERT INTO blah VALUES (NULL, 'c')", $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo "\n";
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(2) {
["i"]=>
string(1) "2"
["c"]=>
NULL
}
array(2) {
["a"]=>
NULL
["c"]=>
string(1) "c"
}
Actual result:
--
array(2) {
["i"]=>
string(1) "1"
["c"]=>
string(1) "a"
}
array(1) {
["i"]=>
string(1) "2"
}
array(1) {
["c"]=>
string(1) "c"
}
--
Edit this bug report at http://bugs.php.net/?id=31960&edit=1
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771
Comment by: anakarlarc at hp dot com
Reported By: info at tphnet dot com
Status: Verified
Bug Type: Apache2 related
Operating System: * (ZTS only!)
PHP Version: 4CVS, 5CVS (2004-02-25)
New Comment:
I have the same erro but I don't have php
Apache 2.0.48 Openssl__0.9.7c-win32
Web Logic
I don't have a idea why it is restarting
arent: child process exited with status 128 -- Restarting.
Previous Comments:
[2004-09-25 00:47:02] OvdSpek at LIACS dot NL
A simple testcase:
This will result in: [notice] Parent: child process exited with status
128 -- Restarting.
I know it's not so valid code, but I do assume this isn't supposed to
restart the entire webserver.
I'd also expect an error message telling me the stack overflowed.
[2004-09-24 23:47:40] OvdSpek at LIACS dot NL
I'm encountering the same error message with a certain script:
[Fri Sep 24 23:41:51 2004] [notice] Parent: child process exited with
status 128 -- Restarting.
Windows XP SP1
Apache/2.0.50 (Win32)
PHP/4.3.9
[2004-08-13 05:23:05] loye dot young at iycc dot net
If you have the PEAR Date package installed, this might be a solution:
There is a command in a Pear function that tries to write information
to the server. Some Windows installations and Unix servers with strict
Safe Mode options enabled do not allow this. You can fix this yourself
however.
Open the file ./pear/Date/TimeZone.php in a text editor. Go to line
247. You should be in a function named 'inDaylightTime()'. Add this
line: return date("I"); at the very top of the function. It should now
look like this:
function inDaylightTime($date)
{
return date("I");
$env_tz = "";
if(getenv("TZ"))
$env_tz = getenv("TZ");
putenv("TZ=".$this->id);
$ltime = localtime($date->getTime(), true);
putenv("TZ=".$env_tz);
return $ltime['tm_isdst'];
}
This should stop the error. It did for me. Try it and let us know how
it worked for you.
[2004-08-13 00:54:28] loye dot young at iycc dot net
I'm having the same error message in my apache log file, with similar
configuration. However, my php.ini settings allow unlimited persistent
connections, and my configuration for mysql does not include a limit on
the number of persistent connections.
My configuration:
apache 2.0.49
php 4.3.8
mysql 4.0.18
WinXP SP1 with latest WinUpdates
The application that I'm invoking is phpWebSite 0.9.3-3.
Loye Young
www.iycc.us
[2004-07-23 15:46:53] super_freax at hotmail dot com
It says in the PHP-manual for child operations that :
This means that for every child that opened a persistent connection
will have its own open persistent connection to the server. For
example, if you had 20 different child processes that ran a script that
made a persistent connection to your SQL server, you'd have 20 different
connections to the SQL server, one from each child.
Note, however, that this can have some drawbacks if you are using a
database with connection limits that are exceeded by persistent child
connections. If your database has a limit of 16 simultaneous
connections, and in the course of a busy server session, 17 child
threads attempt to connect, one will not be able to. If there are bugs
in your scripts which do not allow the connections to shut down (such
as infinite loops), the database with only 16 connections may be
rapidly swamped
==
So it might be the database that has no more connections left ?
My config is :
WinXPProSP1 (NTFS Formatted)
Apache version 2.0.49
MySQL 4.0.18 with MyODBC 3.51 and winMYSQLadmin 1.4
PHP 4.3.6 with Pear 1.3.1 ,Smarty 2.5.0 ,Zend Opt. 2.5.0 , Dbg 2.16.3,
TCL 8.4.5 with TK 8.4 and Vtcl 1.6.0
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/26771
--
Edit this bug report at http://bugs.php.net/?id=26771&edit=1
#31923 [Bgs]: file_get_contents() does not accept urls containing hypen period "-."
ID: 31923
User updated by: mike-bugs dot php dot net at webheat dot co dot uk
Reported By: mike-bugs dot php dot net at webheat dot co dot uk
Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 4.3.10
New Comment:
Thank you for all your help, I'll try this at the weekend most likely.
Previous Comments:
[2005-02-13 02:23:29] [EMAIL PROTECTED]
Correction:
$context =
stream_context_create(array('http'=>array('proxy'=>'tcp://dummy.deviantart.com:80')));
Forgot the port number :)
[2005-02-13 02:21:43] [EMAIL PROTECTED]
I have an ugly solution, it's a very rudimentary HTTP/1.0 client which
relies on the fact that deviantart.com uses a wildcard to direct
*.deviantart.com to the same IP address.
It also relies on the fact that they're not doing any kind of 3xx
redirection (at least as far as I could tell). I wouldn't be surprised
if you need to do some work on this function to make it work *well* for
you.
function http_get_contents($url) {
$resource = parse_url($url);
$ip = gethostbyname('dummy.deviantart.com');
$sock = fsockopen($ip, 80);
if (!$sock) return false;
fwrite($sock, "GET {$resource['path']}?{$resource['query']}
HTTP/1.0\r\n");
fwrite($sock, "Host: {$resource['host']}\r\n");
fwrite($sock, "Connection: close\r\n\r\n");
$response = fgets($sock, 8192);
if (substr($response, 0, 3) != 200) return '';
/* Skip headers */
while (trim(fgets($sock, 8192)));
$ret = '';
while (!feof($sock)) {
$ret .= fgets($sock, 8192);
}
return $ret;
}
That's PHP4/5 compliant. If you're only worried about PHP5
compatability you can do:
$context =
stream_context_create(array('http'=>array('proxy'=>'tcp://dummy.deviantart.com')));
$data = file_get_context($url, false, $context);
Which does *essentially* the same thing, but since it's a proper http
wrapper takes care of the 3xx and other shortcommings of the userspace
version I gave you above.
[2005-02-12 23:24:21] mike-bugs dot php dot net at webheat dot co dot
uk
Thank you Pollita. That's a lot clearer.
Do you have any suggestions for a work around for this issue?
[2005-02-12 17:52:10] [EMAIL PROTECTED]
"gethostbyname() (Used by the network streams code among other parts of
PHP) treats this correctly according to RFC specification."
I can see this statement being inobvious. I mean the gehostbyname()
function defined by the host systems standard C library. You
assumption that PHP's network code does not attempt to validate the
hostname before passing it on to the the system for resolution. It
works on some systems because on those systems the value is encoded
into a DNS packet and sent to the DNS server unmangled. On other
systems, a validation check is performed first and if it doesn't pass,
then it doesn't bother waiting for a network round trip, instead simply
returning a failure.
[2005-02-12 17:17:11] mike-bugs dot php dot net at webheat dot co dot
uk
Thanks Magnus.
This does explain possible behaviour but doesn't explain why 2 Windows
PHP installs work fine but 2 Linux PHP installs (as installed by my
hosting company) do not.
This seems to imply that file_get_contents() doesn't validate the DNS
compliance of the arguement.
Also referring to the previously note from Pollita, as forgiving as the
browser maybe the DNS servers involved in the lookup of
http://mark-.deviantart.com are the ones that are dealing with this
more so from what I know.
The deviantart.com DNS server software also seems to be forgiving, not
just of look ups of this kind but of creating new record of this kind
too, as the DNS entry would have been created when the user mark-
signed up his account with Deviantart.com
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/31923
--
Edit this bug report at http://bugs.php.net/?id=31923&edit=1
#31988 [NEW]: PHP crashes when COM tries to access an unknown DLL/function
From: francoisp at msn dot com Operating system: Windows XP PHP version: 4.3.10 PHP Bug Type: Unknown/Other Function Bug description: PHP crashes when COM tries to access an unknown DLL/function Description: When a COM is used to call an unknown DLL or function, PHP crashes. System: Windows XP PHP version 4.3.11.11 Apache 2 Error signature in Windows: szAppName : php.exe szAppVer : 4.3.11.11 szModName : php4ts.dll szModVer : 4.3.11.11 offset : 000c3e54 -- Edit bug report at http://bugs.php.net/?id=31988&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31988&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31988&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31988&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31988&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31988&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31988&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31988&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31988&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31988&r=support Expected behavior: http://bugs.php.net/fix.php?id=31988&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31988&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31988&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31988&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31988&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31988&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31988&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31988&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31988&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31988&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31988&r=mysqlcfg
#31988 [Opn]: PHP crashes when COM tries to access an unknown DLL/function
ID: 31988 User updated by: francoisp at msn dot com Reported By: francoisp at msn dot com Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.11.11 New Comment: I am currently using version 4.3.11.11 Previous Comments: [2005-02-15 22:30:24] francoisp at msn dot com Additional note: COM does return the right error message (DLL / Function not found) but soon after PHP crashes. [2005-02-15 22:24:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-02-15 22:21:10] francoisp at msn dot com Description: When a COM is used to call an unknown DLL or function, PHP crashes. System: Windows XP PHP version 4.3.11.11 Apache 2 Error signature in Windows: szAppName : php.exe szAppVer : 4.3.11.11 szModName : php4ts.dll szModVer : 4.3.11.11 offset : 000c3e54 -- Edit this bug report at http://bugs.php.net/?id=31988&edit=1
#31988 [Fbk->Opn]: PHP crashes when COM tries to access an unknown DLL/function
ID: 31988 User updated by: francoisp at msn dot com Reported By: francoisp at msn dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP -PHP Version: 4.3.10 +PHP Version: 4.3.11.11 New Comment: Additional note: COM does return the right error message (DLL / Function not found) but soon after PHP crashes. Previous Comments: [2005-02-15 22:24:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-02-15 22:21:10] francoisp at msn dot com Description: When a COM is used to call an unknown DLL or function, PHP crashes. System: Windows XP PHP version 4.3.11.11 Apache 2 Error signature in Windows: szAppName : php.exe szAppVer : 4.3.11.11 szModName : php4ts.dll szModVer : 4.3.11.11 offset : 000c3e54 -- Edit this bug report at http://bugs.php.net/?id=31988&edit=1
#31988 [Opn->Fbk]: PHP crashes when COM tries to access an unknown DLL/function
ID: 31988 Updated by: [EMAIL PROTECTED] Reported By: francoisp at msn dot com -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.10 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-02-15 22:21:10] francoisp at msn dot com Description: When a COM is used to call an unknown DLL or function, PHP crashes. System: Windows XP PHP version 4.3.11.11 Apache 2 Error signature in Windows: szAppName : php.exe szAppVer : 4.3.11.11 szModName : php4ts.dll szModVer : 4.3.11.11 offset : 000c3e54 -- Edit this bug report at http://bugs.php.net/?id=31988&edit=1
#31986 [Opn->Csd]: exif_read_data incorrectly calculates nesting_level, throwing warnings
ID: 31986
Updated by: [EMAIL PROTECTED]
Reported By: dpark at mit dot edu
-Status: Open
+Status: Closed
Bug Type: EXIF related
Operating System: Linux
PHP Version: 4CVS-2005-02-15 (stable)
New Comment:
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.
Previous Comments:
[2005-02-15 15:24:12] dpark at mit dot edu
Description:
Related to #31797? exif_read_data is still throwing the same warnings
as in #31797 on every camera-created image I give it (for cameras both
new and old, cheap and expensive).
The Debian package in question is actually based off the 2005-02-06
4CVS snapshot, which is later than the time at which #31797 was
reported to be fixed in 4CVS. Adam Conrad, the package maintainer,
confirms the bug is in PHP, and can reproduce the problem with his own
camera-created images.
Quoting an email from Adam Conrad:
Danny Park said:
> Anyway, when you say the nesting limit was increased from 5 to 25,
are
> you saying 4.3.10-3 reflects that increase?
Indeed, it does. However, it seems that the way the code's written,
the nesting_level increases quite rapidly, and obviously takes on a
different meaning than the original developer thought it had.
As an example your 5 images all work fine with jhead(1), which has a
hardcoded directory nesting limit of *5*. However, with some debug
statements thrown into PHP's exif.c, we're reaching nesting levels of:
img_0949.jpg: 53
P1000415.JPG: 54
IMG_0669.JPG: 65
DSC00804.JPG: 48
dcp00884.jpg: 38
I don't currently have the time to hunt down what upstream's doing
wrong here, so I would encourage you to (re)file this bug upstream, and
you're welcome to quote this whole message.
I recommend they have a look at what jhead(1) is considering "directory
nesting" and mimic it, since PHP's obviously doing something a bit
differently.
If it doesn't get fixed properly upstream in a relatively timely
fashion, I'll make sure the next Debian packages uploaded either revert
this change, or hack MAX_IFD_NESTING_LEVEL to be something ridiculously
high,
like 250. I'll test with some pro cameras lying around the house here
to see just how much higher we can get before I do that.
A second email from Adam Conrad:
Woo. An image from my EOS 300D gets the counter up to 75. I'm just
going to set it at 250 in the next upload. :)
You should still talk to upsteam about unbreaking this, as it LOOKS
like they're incrementing the counter at altogether the wrong bounday.
Reproduce code:
---
$url =
"http://dpark.mitacf.org/pix/pics/mit04/danny/03-sly_foliage/img_0949.jpg";;
print("\n\ntest img 1 - canon powershot S45\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit05/janice/01-christmas/P1000415.JPG";;
print("\n\ntest img 2 - panasonic DMC-FZ20\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit04/fslee/08-usgl_beach_sunrise/IMG_0669.JPG";;
print("\n\ntest img 3 - powershot S1 IS\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit04/chking/01-ivcf_sound_closet/DSC00804.JPG";;
print("\n\ntest img 4 - sony cybershot\n");
$data = exif_read_data($url);
print_r($data);
$url =
"http://dpark.mitacf.org/pix/pics/mit00/dannys_camera/08-burton5-asbestos-evac/dcp00884.jpg";;
print("\n\ntest img 5 - kodak DC210\n");
$data = exif_read_data($url);
print_r($data);
Expected result:
Output of the print and print_r statements.
Actual result:
--
Output of the print and print_r statements interspersed with
"Warning: exif_read_data(imagefilename.jpg): corrupt EXIF
header: maximum directory nesting level reached in
/path/to/script on line line in script"
Each image produces two or three such warnings.
--
Edit this bug report at http://bugs.php.net/?id=31986&edit=1
#31988 [Opn->Fbk]: PHP crashes when COM tries to access an unknown DLL/function
ID: 31988 Updated by: [EMAIL PROTECTED] Reported By: francoisp at msn dot com -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.11.11 New Comment: Please try the snapshot. Previous Comments: [2005-02-15 22:32:53] francoisp at msn dot com I am currently using version 4.3.11.11 [2005-02-15 22:30:24] francoisp at msn dot com Additional note: COM does return the right error message (DLL / Function not found) but soon after PHP crashes. [2005-02-15 22:24:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-02-15 22:21:10] francoisp at msn dot com Description: When a COM is used to call an unknown DLL or function, PHP crashes. System: Windows XP PHP version 4.3.11.11 Apache 2 Error signature in Windows: szAppName : php.exe szAppVer : 4.3.11.11 szModName : php4ts.dll szModVer : 4.3.11.11 offset : 000c3e54 -- Edit this bug report at http://bugs.php.net/?id=31988&edit=1
#31984 [Opn->Fbk]: sessions fail randomly, causes a segmentation fault in apache
ID: 31984 Updated by: [EMAIL PROTECTED] Reported By: root at mediamonks dot net -Status: Open +Status: Feedback Bug Type: Session related Operating System: FreeBSD 4.11-STABLE PHP Version: 5.0.3 New Comment: 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 Previous Comments: [2005-02-15 14:30:56] root at mediamonks dot net with notices on the log file records: PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 [Tue Feb 15 14:27:45 2005] [notice] child pid 83780 exit signal Segmentation fault (11) [Tue Feb 15 14:27:45 2005] [notice] child pid 83776 exit signal Segmentation fault (11) [Tue Feb 15 14:27:45 2005] [notice] child pid 83710 exit signal Segmentation fault (11) PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 [Tue Feb 15 14:27:48 2005] [notice] child pid 83752 exit signal Segmentation fault (11) [Tue Feb 15 14:27:48 2005] [notice] child pid 83713 exit signal Segmentation fault (11) [2005-02-15 13:44:44] root at mediamonks dot net Description: Apache 2.0.53 & mod_php5 5.0.3 Sessions occasionally work, but in two-thirds of the session requests an error is generated and the apache child segfaults. Error recorded in the logfile: PHP Fatal error: Unknown: Cannot find save handler \x02 in Unknown on line 0 Error reported on site: Notice: Undefined variable: HTTP_SESSION_VARS in Notice: Undefined variable: _SESSION in in Warning: session_register() [function.session-register]: Cannot find save handler in Warning: session_register() [function.session-register]: Cannot find save handler in I'm using php.ini-recommended as php.ini. Tried commenting out session.save_handler, setting it to "files" and just files. Reproduce code: --- session_start(); -- Edit this bug report at http://bugs.php.net/?id=31984&edit=1
#31968 [Asn->Bgs]: PDO getcolumnmeta returns no value when select returns not data
ID: 31968
Updated by: [EMAIL PROTECTED]
Reported By: jlim at natsoft dot com
-Status: Assigned
+Status: Bogus
Bug Type: *Database Functions
Operating System: WinXP SP2
PHP Version: 5CVS-2005-02-14 (dev)
Assigned To: wez
New Comment:
Report to PECL. This is not PECL bug system..
Previous Comments:
[2005-02-15 06:52:20] jlim at natsoft dot com
Hi
This is probably a problem with sqlite. I just tested with pdo's pgsql
extension and getcolumnmeta worked fine under both cases.
John
[2005-02-14 16:34:22] [EMAIL PROTECTED]
I'll look into it.
PS: John, can you submit PDO bugs via PECL instead in the future. I'd
love to find out more about the OCI problems you mentioned.
http://pecl.php.net/bugs/report.php?package=PDO
http://pecl.php.net/bugs/report.php?package=PDO_OCI
etc.
thanks!
[2005-02-14 12:09:33] jlim at natsoft dot com
Description:
Hi,
I think PDO should return the getColumnMeta info even if no data is
returned, so long as SQL parses correctly and table exists. I believe
that all of the non-PDO database extensions work like this.
I don't know whether this is an SQLite issue or PDO issue.
Thanks, John Lim
Reproduce code:
---
prepare("select * from hash ");
$ok = $st2->execute();
echo "GetColumnMeta";
for ($i=0; $i<2; $i++) {
$col = $st2->getColumnMeta($i);
var_dump($col);echo "";
}
}
$db = new PDO('sqlite:' . getenv('HOME') . "/.web-watch.sql3");
$db->query('create table hash(url primary key, hash)');
$db->query('delete from hash');
GetColumnMeta($db);
$db->query("insert into hash (url, hash) values
('http://yahoo.com/','100')");
GetColumnMeta($db);
?>
Expected result:
GetColumnMeta
array(6) { ["native_type"]=> string(6) "string" ["flags"]=> array(0) {
} ["name"]=> string(3) "url" ["len"]=> int(-1) ["precision"]=> int(0)
["pdo_type"]=> int(2) }
array(6) { ["native_type"]=> string(6) "string" ["flags"]=> array(0) {
} ["name"]=> string(4) "hash" ["len"]=> int(-1) ["precision"]=> int(0)
["pdo_type"]=> int(2) }
GetColumnMeta
array(6) { ["native_type"]=> string(6) "string" ["flags"]=> array(0) {
} ["name"]=> string(3) "url" ["len"]=> int(-1) ["precision"]=> int(0)
["pdo_type"]=> int(2) }
array(6) { ["native_type"]=> string(6) "string" ["flags"]=> array(0) {
} ["name"]=> string(4) "hash" ["len"]=> int(-1) ["precision"]=> int(0)
["pdo_type"]=> int(2) }
Actual result:
--
GetColumnMeta
bool(false)
bool(false)
GetColumnMeta
array(6) { ["native_type"]=> string(6) "string" ["flags"]=> array(0) {
} ["name"]=> string(3) "url" ["len"]=> int(-1) ["precision"]=> int(0)
["pdo_type"]=> int(2) }
array(6) { ["native_type"]=> string(6) "string" ["flags"]=> array(0) {
} ["name"]=> string(4) "hash" ["len"]=> int(-1) ["precision"]=> int(0)
["pdo_type"]=> int(2) }
--
Edit this bug report at http://bugs.php.net/?id=31968&edit=1
#30110 [Fbk->NoF]: mysql.connect_timeout is bugged for NSAPI
ID: 30110 Updated by: php-bugs@lists.php.net Reported By: manuelsagra at ibermutuamur dot es -Status: Feedback +Status: No Feedback Bug Type: iPlanet related Operating System: Solaris 9 PHP Version: 4.3.8 New Comment: 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". Previous Comments: [2005-02-03 04:50:29] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-09-16 12:46:15] manuelsagra at ibermutuamur dot es Description: A fresh install of PHP whith the NSAPI doesn't connect to a remote MySQL. We have discovered that it's related to the timeout of the connection socket. While the socket is connecting, and after the first "synack", the client sends a shutdown, so the connection is not established. The workaround is to put a -1 in the mentioned timeout option, but we think this is not desirable... Reproduce code: --- The default settings doesn't work with NSAPI -- Edit this bug report at http://bugs.php.net/?id=30110&edit=1
#29554 [Fbk->Opn]: compile failure when using --with-pspell=/usr/local
ID: 29554 User updated by: John at Albin dot Net Reported By: John at Albin dot Net -Status: Feedback +Status: Open Bug Type: Pspell related Operating System: * PHP Version: 4CVS, 5CVS (2005-02-03) New Comment: As per sniper's request, I tried the latest CVS snapshot, php4-STABLE-200502152130, but received the same error during compile: ld: ext/pspell/pspell.o illegal reference to symbol: _aspell_word_list_elements defined in indirectly referenced dynamic library /usr/local/lib/ libaspell.15.dylib The fix mentioned in my first posting still works. Previous Comments: [2005-02-11 05:43:19] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-01-19 21:50:17] dhaveconfig at elitemail dot org same issue with OS X Server 10.3.7 and php 4.3.10. same fix resolved it. [2004-10-01 11:59:09] BjarneDM This is also an issue with PHP 5.0.x and PHP 4.3.9 Mac OS X 10.3.5 I'm upgrading the ServerLogistics PHP4 package that includes aspell: [Titanen:~] bjarne% aspell -v @(#) International Ispell Version 3.1.20 (but really Aspell 0.50.4.1) [Titanen:~] bjarne% which aspell /Library/PHP4/bin/aspell Installing the aspell packages from either fink or darwinports doesn't resolve this issue. Running these commands in the build directory before ./configure solves the problem for both PHP4 and PHP5: sed 's/\(LIBS="\)\(-lpspell \$LIBS"\)/\1-laspell \2/' configure > configure.1 mv configure.1 configure chmod a+x configure I've set up a site at http://webadmin.mathiesen.info/ where I make build scripts, comments, etc available for the ServerLogistics Complete* packages [2004-08-06 20:45:00] John at Albin dot Net Description: Environment: * Mac OS X 10.3.4 * aspell 0.50.5 and aspell-en 0.51-1 (installed into /usr/local from source files) * PHP 4.3.8 I've verified that aspell works from the command line, but PHP won't compile. I'm configuring with '--with-pspell=/usr/local' and when I run make, it errors out saying: "ld: ext/pspell/ pspell.o illegal reference to symbol: _aspell_error_number defined in indirectly referenced dynamic library /usr/local/lib/libaspell.15.dylib" I have never installed pspell. And I have installed aspell for the first time today on this machine. When I run 'sudo /usr/libexec/locate.updatedb' and then 'locate libpspell' I find (ignoring my build directory in /usr/ local/src): /usr/local/lib/libpspell.15.0.3.dylib /usr/local/lib/libpspell.15.dylib /usr/local/lib/libpspell.dylib /usr/local/lib/libpspell.la 'locate libaspell' returns: /usr/local/lib/libaspell.15.0.3.dylib /usr/local/lib/libaspell.15.dylib /usr/local/lib/libaspell.dylib /usr/local/lib/libaspell.la The compile error is easily fixed with a small change to 'configure'. PHP compiles fine, when I edit php-4.3.8/ configure and change line 71624 from: LIBS="-lpspell $LIBS" to: LIBS="-laspell -lpspell $LIBS" I have also talked to other Mac OS X/PHP/aspell users who have the same issue and the configure modification fixes their issue as well. This bug is very similar to bug #23089. From looking at that bug, it seems that this bug might be reproducable on any machine that has no legacy aspell/pspell libraries and only the most recent aspell library. Undoubtably, this was caused my the author of aspell changing the name of the library multiple times. But can this relatively minor fix please be added to PHP's configure script? Or would this impact Pspell users (those without the newer aspell)? If so, is there a way to check for this in the configure file? Unfortunately, I'm not an expert in configure files or I would attempt a patch myself. -- Edit this bug report at http://bugs.php.net/?id=29554&edit=1
#29956 [Csd]: support for s390 architecture in aclocal.m4 and configure script
ID: 29956 User updated by: mark dot post at eds dot com Reported By: mark dot post at eds dot com Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 4CVS, 5CVS (2005-02-14) Assigned To: sniper New Comment: I grabbed php4-STABLE-200502152330.tar.bz2 and php5-STABLE-200502152330.tar.bz2 and compiled them. This does seem to correct the problem that I reported. Thanks for following up on this. Mark Post Previous Comments: [2005-02-15 09:52:45] [EMAIL PROTECTED] 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. [2005-02-14 22:54:42] [EMAIL PROTECTED] I have some patches to commit for libtool which fix this one too. [2004-09-02 18:47:30] mark dot post at eds dot com Description: For some time now, I've been having problems with building PHP on Linux/390. The Apache module would not build because libtool was having problems. I finally tracked the problem down to the aclocal.m4 file (and the resulting configure script). The following patch should be applied to PHP 5.0.0 (and later versions) to enable correct building on Linux/390. --- aclocal.m4.orig 2004-07-13 15:13:14.0 -0400 +++ aclocal.m4 2004-09-02 12:44:12.0 -0400 @@ -5315,7 +5315,7 @@ # This must be Linux ELF. linux-gnu*) case $host_cpu in - alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64*) + alpha* | hppa* | i*86 | mips | mipsel | powerpc* | sparc* | ia64* | s390*) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM -- Edit this bug report at http://bugs.php.net/?id=29956&edit=1
#31989 [NEW]: Xmlrpc 'infinite loop' issue in php5 for windows only
From: grangeway at blueyonder dot co dot uk Operating system: Windows PHP version: 5.0.3 PHP Bug Type: XMLRPC-EPI related Bug description: Xmlrpc 'infinite loop' issue in php5 for windows only Description: The following code works fine in php 4.x for windows, appears to work fine in 4.x/5.x under linux, but in the distributed windows binarys, and also my own compilation, results in an infinite loop, in what appears to be xmlParseChunk. This issue only seems to occur if the xml header i.e. is not included in the response, and it's the windows build. Reproduce code: --- $foo = " Welcome "; var_dump($foo); var_dump(xmlrpc_decode($foo)); Expected result: Result under freebsd: > php/bin/php test.php Content-type: text/html X-Powered-By: PHP/5.0.4-dev string(110) " Welcome " string(7) "Welcome" Actual result: -- inifinite loop: char * data=0x00a40528 is "" php5ts_debug.dll!_xmlParseDocument() + 0x5c5 C php5ts_debug.dll!_xmlParseChunk() + 0xe5 C > php5ts_debug.dll!php_XML_Parse(_XML_Parser * parser=0x00a3f060, const unsigned char * data=0x00a40528, int data_len=7, int is_final=1) Line 481 + 0x18 C php5ts_debug.dll!xml_elem_parse_buf(const char * in_buf=0x00a40528, int len=7, _xml_input_options * options=0x0012f298, _xml_elem_error * error=0x0012f18c) Line 699 + 0x16 C php5ts_debug.dll!XMLRPC_REQUEST_FromXML(const char * in_buf=0x00a40528, int len=7, _xmlrpc_request_input_options * in_options=0x0012f298) Line 762 + 0x1c C php5ts_debug.dll!decode_request_worker(_zval_struct * xml_in=0x00a40440, _zval_struct * encoding_in=0x, _zval_struct * method_name_out=0x) Line 713 + 0x16C php5ts_debug.dll!zif_xmlrpc_decode(int ht=1, _zval_struct * return_value=0x00a3f018, _zval_struct * this_ptr=0x, int return_value_used=1, void * * * tsrm_ls=0x00912910) Line 778 + 0x31C -- Edit bug report at http://bugs.php.net/?id=31989&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31989&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31989&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31989&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31989&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31989&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31989&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31989&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31989&r=support Expected behavior: http://bugs.php.net/fix.php?id=31989&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31989&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31989&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31989&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31989&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31989&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31989&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31989&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31989&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31989&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31989&r=mysqlcfg
#31989 [Opn->Asn]: Xmlrpc 'infinite loop' issue in php5 for windows only
ID: 31989 Updated by: [EMAIL PROTECTED] Reported By: grangeway at blueyonder dot co dot uk -Status: Open +Status: Assigned Bug Type: XMLRPC-EPI related Operating System: Windows PHP Version: 5.0.3 -Assigned To: +Assigned To: edink New Comment: It's because this extension is linked with libxml2 which this extension DOES NOT support. It should be linked with expat like it is in PHP 4.. Previous Comments: [2005-02-16 01:27:42] grangeway at blueyonder dot co dot uk Description: The following code works fine in php 4.x for windows, appears to work fine in 4.x/5.x under linux, but in the distributed windows binarys, and also my own compilation, results in an infinite loop, in what appears to be xmlParseChunk. This issue only seems to occur if the xml header i.e. is not included in the response, and it's the windows build. Reproduce code: --- $foo = " Welcome "; var_dump($foo); var_dump(xmlrpc_decode($foo)); Expected result: Result under freebsd: > php/bin/php test.php Content-type: text/html X-Powered-By: PHP/5.0.4-dev string(110) " Welcome " string(7) "Welcome" Actual result: -- inifinite loop: char * data=0x00a40528 is "" php5ts_debug.dll!_xmlParseDocument() + 0x5c5 C php5ts_debug.dll!_xmlParseChunk() + 0xe5 C > php5ts_debug.dll!php_XML_Parse(_XML_Parser * parser=0x00a3f060, const unsigned char * data=0x00a40528, int data_len=7, int is_final=1) Line 481 + 0x18 C php5ts_debug.dll!xml_elem_parse_buf(const char * in_buf=0x00a40528, int len=7, _xml_input_options * options=0x0012f298, _xml_elem_error * error=0x0012f18c) Line 699 + 0x16 C php5ts_debug.dll!XMLRPC_REQUEST_FromXML(const char * in_buf=0x00a40528, int len=7, _xmlrpc_request_input_options * in_options=0x0012f298) Line 762 + 0x1c C php5ts_debug.dll!decode_request_worker(_zval_struct * xml_in=0x00a40440, _zval_struct * encoding_in=0x, _zval_struct * method_name_out=0x) Line 713 + 0x16 C php5ts_debug.dll!zif_xmlrpc_decode(int ht=1, _zval_struct * return_value=0x00a3f018, _zval_struct * this_ptr=0x, int return_value_used=1, void * * * tsrm_ls=0x00912910) Line 778 + 0x31C -- Edit this bug report at http://bugs.php.net/?id=31989&edit=1
#31990 [NEW]: dblib.c:303: buffer_add_row: Assertion `row_size <= buf->element_size' failed
From: tim at datad dot com
Operating system: SuSE 9.2 Pro 2.6.8-24.11-default
PHP version: 4.3.10
PHP Bug Type: Sybase (dblib) related
Bug description: dblib.c:303: buffer_add_row: Assertion `row_size <=
buf->element_size' failed
Description:
I get the following error when I run any stored procedure. The script
works fine if you use SQL statements, but sp's die.
php: dblib.c:303: buffer_add_row: Assertion `row_size <=
buf->element_size' failed.
Aborted
My PHP Configuration:
./configure \
--with-apache2=../httpd-2.0.53 \
--enable-track-vars \
--enable-magic-quotes \
--enable-discard-path \
--enable-force-cgi-redirect \
--enable-shared \
--enable-sigchild \
--enable-sockets=shared \
--enable-mailparse \
--with-module=so \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql \
--with-gnu-ld \
--with-zlib \
--with-sybase \
--with-tdsver=7.0 \
--with-unixODBC \
--with-dbase \
--with-openssl \
--with-gd \
--with-ttf \
--with-curl \
--with-mcrypt
Reproduce code:
---
name]";
if ( $field_cnt == $syb_num_fields )
{
print "\n" ;
$field_cnt = 0 ;
}
}
print "\n" ;
}
++$row_cnt ;
$field_cnt = 0 ;
while(list($k, $v) = each($row))
{
++$field_cnt;
$datum = NULL ;
$datum = rtrim ( $v ) ;
print "[$datum]" ;
if ( $field_cnt == $syb_num_fields )
{
print "\n" ;
$field_cnt = 0 ;
}
}
}
sybase_close ( $db ) ;
?>
Expected result:
I expect it to work!
I should see the output of the stored procedure or at least some kind of
explanation as to why it's failing.
Actual result:
--
the bug.
--
Edit bug report at http://bugs.php.net/?id=31990&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31990&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31990&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31990&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31990&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31990&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31990&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31990&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31990&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31990&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31990&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31990&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31990&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31990&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31990&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31990&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31990&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31990&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31990&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31990&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31990&r=mysqlcfg
#31990 [Opn->Fbk]: dblib.c:303: buffer_add_row: Assertion `row_size <= buf->element_size' failed
ID: 31990
Updated by: [EMAIL PROTECTED]
Reported By: tim at datad dot com
-Status: Open
+Status: Feedback
Bug Type: Sybase (dblib) related
Operating System: SuSE 9.2 Pro 2.6.8-24.11-default
PHP Version: 4.3.10
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
And why don't you use --with-sybase-ct ?? AFAIK, it's better supported
than the old sybase-db..
Previous Comments:
[2005-02-16 02:25:34] tim at datad dot com
Description:
I get the following error when I run any stored procedure. The script
works fine if you use SQL statements, but sp's die.
php: dblib.c:303: buffer_add_row: Assertion `row_size <=
buf->element_size' failed.
Aborted
My PHP Configuration:
./configure \
--with-apache2=../httpd-2.0.53 \
--enable-track-vars \
--enable-magic-quotes \
--enable-discard-path \
--enable-force-cgi-redirect \
--enable-shared \
--enable-sigchild \
--enable-sockets=shared \
--enable-mailparse \
--with-module=so \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql \
--with-gnu-ld \
--with-zlib \
--with-sybase \
--with-tdsver=7.0 \
--with-unixODBC \
--with-dbase \
--with-openssl \
--with-gd \
--with-ttf \
--with-curl \
--with-mcrypt
Reproduce code:
---
name]";
if ( $field_cnt == $syb_num_fields )
{
print "\n" ;
$field_cnt = 0 ;
}
}
print "\n" ;
}
++$row_cnt ;
$field_cnt = 0 ;
while(list($k, $v) = each($row))
{
++$field_cnt;
$datum = NULL ;
$datum = rtrim ( $v ) ;
print "[$datum]" ;
if ( $field_cnt == $syb_num_fields )
{
print "\n" ;
$field_cnt = 0 ;
}
}
}
sybase_close ( $db ) ;
?>
Expected result:
I expect it to work!
I should see the output of the stored procedure or at least some kind
of explanation as to why it's failing.
Actual result:
--
the bug.
--
Edit this bug report at http://bugs.php.net/?id=31990&edit=1
#31854 [Opn->Fbk]: Segfault if set memory_limit and other goodies
ID: 31854
Updated by: [EMAIL PROTECTED]
Reported By: bertrand at toggg dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: FC2 kernel-2.6.10-1.12
PHP Version: 4CVS-2005-02-06
New Comment:
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
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.
I can't get it to crash with any parameters..
Previous Comments:
[2005-02-06 11:30:08] bertrand at toggg dot com
I downloaded the CVS snapshot from this morning,
php4-STABLE-200502060730 unix version
I build only the executables:
./configure --enable-memory-limit
make
With sapi/cli/php or sapi/cgi/php, unfortunately the results are the
same.
Only one point is now better, it's the case where no memory_limit set
and less call to memory_get_usage:
php outmem.php 18 '' 100
17:2/88792 bytes
16:4/8 bytes
<...snip...>
1:131072/5855880 bytes
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate 35 bytes) in /home/bertrand/prog/test/outmem.php on line 19
<<< here it's still hanging a long time >>>
Allowed memory size of 8388608 bytes exhausted (tried to allocate 129
bytes)
But then it's coming back from PHP, no need no more to break. Is it
only due to the fact it's an only CLI PHP ?
Just to be sure, I've also rebuild some php-4.3.9 from 2004/10/09 and
results are identical.
[2005-02-06 06:57:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-02-05 20:31:24] bertrand at toggg dot com
Description:
This script doubles and again an array of long strings.
It accepts 3 parameters:
- nb of times to double the array
- eventuel memory_limit to set (thus default 8 Mo)
- interval of added rows to check memory_get_usage.
By 18 loops the 8Mo are exhausted.
Depending on the memory setting and the interval to check memory usage,
results are somewhat strange.
The segmentation fault occurs the same if running from Apache 2.0
Handler
It could be related to bug #31624
Reproduce code:
---
$loop = isset($_SERVER['argv'][1]) ? $_SERVER['argv'][1]+0 : 11;
$setmem = isset($_SERVER['argv'][2]) ? $_SERVER['argv'][2]+0 : ''; //
changed if set
$chk = isset($_SERVER['argv'][3]) ? $_SERVER['argv'][3]+0 : 100;
if ($setmem) {
if (ini_set ('memory_limit', $setmem*1048576)) {
echo 'Set memory limit to '.$setmem." Mo\n";
} else {
echo 'FAILED to set memory limit to '.$setmem." Mo\n";
}
}
error_reporting(E_ALL);
$arr = array (str_repeat('X', 65536));
$mem = 0;
while ($loop--) {
for ($i = count($arr); $i; $i--) {
$arr[] = $arr[0];
if ($i%$chk) continue;
if ( ( ($nmem = memory_get_usage()) - $mem) > 100) {
$mem = $nmem;
echo 'Count:'.count($arr)." ($mem bytes)\n";
}
}
echo $loop.':'.count($arr).'/'.memory_get_usage() . " bytes\n"; //
36640
}
echo "\n OK \n";
Expected result:
1) no memory_limit set
PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried
to allocate 35 bytes) in /home/bertrand/prog/test/outmem.php on line 19
+ break
2) with memory_limit set.
If not enough: same as 1)
Enough memory: OK
Actual result:
--
1) no memory_limit set
I actually get memory exhausted, but if I lower the memory_get_usage
frequence, then no break, must control-C:
php outmem.php 18 '' 100 ---> break, get hand back
php outmem.php 18 '' 1000 ---> I must abort
That means if I check memory_get_usage only each 1000 rows PHP is not
coming back, but everything OK if I check each 100 rows
PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried
to allocate 35 bytes) in /home/bertrand/prog/test/outmem.php on line 19
Allowed memory size of 8388608 bytes exhausted (tried to allocate 129
bytes)
The second message is coming after a long while, but the PHP is
sleeping and I need to break
2) with memory_limit
It's as expected but will in both cases (enough mem or not) make a
segmentation fault.
--
Edit this bug report at http://bugs.php.net/?id=31854&edit=1
#30412 [Fbk->Opn]: Apache Segmentation Fault (11)
ID: 30412 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: SuSE Linux 8.2 PHP Version: 5.0.4-Dev New Comment: TNS_ADMIN is not used, since I do not utilize tnsnames.ora file. As you can see from the code example I use the connection description string directly in the script: ORACLE_HOME is definitely set, otherwise there will be no successful queries at all. Previous Comments: [2005-02-10 21:34:05] [EMAIL PROTECTED] Please check that you have set all environments variables (i.e. ORACLE_HOME, TNS_ADMIN etc) properly. [2005-02-10 21:17:23] subscription at nazarenko dot net Hello it is me again, Tested both 5.0.3 release and the latest snapshot php5-STABLE-200502101130 with both Apache 2.0.52 Prefork and Worker MPMs. 5.0.3 and the snapshot behave identically. Under Prefork MPM everything is 100% ok. Under Worker the same problem as before: some page loads are unsuccessful with no segfault. The browser just keeps waiting and waiting and nothing happens. This happens on average for 30% of page requests containing Oracle queries. Don't know if you want to pursue this further as the Prefork works fine now. Many thanks for your time and effort!! [2005-01-21 01:00:08] 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-01-13 01:27:24] [EMAIL PROTECTED] Please, try latest snapshot with non-threaded Apache. Are you still able to replicate the problem ? [2004-12-03 11:52:49] rathamahata at ehouse dot ru Sorry, please ignore previous post. That was apache with MPM=prefork + php compiled against apache with mpm=worker. I don't know how did it work. After i recompiled php against current apache problem had disappeared. 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/30412 -- Edit this bug report at http://bugs.php.net/?id=30412&edit=1
#31990 [Fbk->Opn]: dblib.c:303: buffer_add_row: Assertion `row_size <= buf->element_size' failed
ID: 31990
User updated by: tim at datad dot com
Reported By: tim at datad dot com
-Status: Feedback
+Status: Open
Bug Type: Sybase (dblib) related
Operating System: SuSE 9.2 Pro 2.6.8-24.11-default
PHP Version: 4.3.10
New Comment:
OK, so...
I downloaded and installed the latest PHP ( 4.3.11-dev ) and it still
exhibits the same behavior.
php: dblib.c:303: buffer_add_row: Assertion `row_size <=
buf->element_size' failed.
Aborted
Incidentally, you cannot configure
--with-sybase
--with-sybase-ct
it has to be one or the other. When I configured --with-ct I got
segfaults, and nothing worked at all. I could not connect or anything
with either through a browser or php-cli.
I used --with-sybase-ct=/opt/sybase/OCS-12_5
So I've configured for --with-sybase=/opt/sybase and now what worked
before is working and it is producing the same error as before when I
try to use a stored procedure.
My latest configure:
./configure \
--enable-shared \
--with-apache2=../httpd-2.0.53 \
--with-module=so \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql \
--with-gnu-ld \
--with-zlib \
--with-sybase=/opt/sybase \
--with-unixODBC \
--with-dbase \
--with-openssl \
--with-gd \
--with-ttf \
--with-curl \
--with-mcrypt
Previous Comments:
[2005-02-16 03:18:29] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
And why don't you use --with-sybase-ct ?? AFAIK, it's better supported
than the old sybase-db..
[2005-02-16 02:25:34] tim at datad dot com
Description:
I get the following error when I run any stored procedure. The script
works fine if you use SQL statements, but sp's die.
php: dblib.c:303: buffer_add_row: Assertion `row_size <=
buf->element_size' failed.
Aborted
My PHP Configuration:
./configure \
--with-apache2=../httpd-2.0.53 \
--enable-track-vars \
--enable-magic-quotes \
--enable-discard-path \
--enable-force-cgi-redirect \
--enable-shared \
--enable-sigchild \
--enable-sockets=shared \
--enable-mailparse \
--with-module=so \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-mysql \
--with-gnu-ld \
--with-zlib \
--with-sybase \
--with-tdsver=7.0 \
--with-unixODBC \
--with-dbase \
--with-openssl \
--with-gd \
--with-ttf \
--with-curl \
--with-mcrypt
Reproduce code:
---
name]";
if ( $field_cnt == $syb_num_fields )
{
print "\n" ;
$field_cnt = 0 ;
}
}
print "\n" ;
}
++$row_cnt ;
$field_cnt = 0 ;
while(list($k, $v) = each($row))
{
++$field_cnt;
$datum = NULL ;
$datum = rtrim ( $v ) ;
print "[$datum]" ;
if ( $field_cnt == $syb_num_fields )
{
print "\n" ;
$field_cnt = 0 ;
}
}
}
sybase_close ( $db ) ;
?>
Expected result:
I expect it to work!
I should see the output of the stored procedure or at least some kind
of explanation as to why it's failing.
Actual result:
--
the bug.
--
Edit this bug report at http://bugs.php.net/?id=31990&edit=1
#30875 [Opn->Ana]: ext/xml: xml_parse_into_struct() does not resolve entities in element content
ID: 30875 Updated by: [EMAIL PROTECTED] -Summary: xml_parse_into_struct does not resolve entities in element content Reported By: joern_h at gmx dot net -Status: Open +Status: Analyzed -Bug Type: XML related +Bug Type: Feature/Change Request Operating System: * PHP Version: 4CVS, 5CVS (2005-02-03) New Comment: After some investigating of the issue: ext/xml just misses this functionality. No bug but feature request -> reclassified. Previous Comments: [2005-02-03 14:59:37] joern_h at gmx dot net This bug still occurs with current PHP4 (Feb 3 2005 06:13:06) and PHP5 (Feb 3 2005 12:17:00) snapshots. [2005-02-03 04:41:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-11-24 00:11:27] joern_h at gmx dot net Description: When using xml_parse_into_struct, entities from the internal dtd are not resolved in element content. Entities in attribute values are resolved properly. This bug is present in PHP 4.3.8 and PHP5 (cvs from 2004-11-22). Reproduce code: --- ]> &test; HERE; $parser =& xml_parser_create(); xml_parse_into_struct($parser, $xml, $vals, $idx); print_r($vals); xml_parser_free($parser); ?> Expected result: Array ( [0] => Array ( [tag] => TEST [type] => complete [level] => 1 [value] => test ) ) Actual result: -- Array ( [0] => Array ( [tag] => TEST [type] => complete [level] => 1 ) ) -- Edit this bug report at http://bugs.php.net/?id=30875&edit=1
