Bug #63705 [Com]: lack of error message
Edit report at https://bugs.php.net/bug.php?id=63705&edit=1 ID: 63705 Comment by: ni...@php.net Reported by:iam4webwork at hotmail dot com Summary:lack of error message Status: Not a bug Type: Bug Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: @rasmus: I still think that we should throw a notice/warning (in the lexer?) when an invalid octal is provided. Or do we have odd BC reasons preventing us from doing so? Previous Comments: [2012-12-06 06:12:31] ras...@php.net Octals are by definition identified by a single leading 0, not 2. [2012-12-06 06:08:09] iam4webwork at hotmail dot com Description: PHP fails to display error messages consistently when user provides invalid octals. Test script: --- $octal = 00812; $another= 00934; var_dump( $octal, $another); $will_error = 01c; var_dump( $will_error ); The first two octals PHP accepts as valid input, and silently truncates each. It only displays an error message for 01c and mentions the 'c' being a problem. Why doesn't PHP consistently reject invalid octal values and display error messages? Expected result: I expected error messages to result for each of the first two invalid octals. Instead PHP blindly accepted them while having each evaluate as zero. It only caught on to 01c being a bad octal value. Actual result: -- int 0 int 0 Parse error: syntax error, unexpected 'c' (T_STRING) in ... -- Edit this bug report at https://bugs.php.net/bug.php?id=63705&edit=1
Bug #63705 [Opn->Nab]: lack of error message
Edit report at https://bugs.php.net/bug.php?id=63705&edit=1 ID: 63705 Updated by: ras...@php.net Reported by:iam4webwork at hotmail dot com Summary:lack of error message -Status: Open +Status: Not a bug Type: Bug Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Octals are by definition identified by a single leading 0, not 2. Previous Comments: [2012-12-06 06:08:09] iam4webwork at hotmail dot com Description: PHP fails to display error messages consistently when user provides invalid octals. Test script: --- $octal = 00812; $another= 00934; var_dump( $octal, $another); $will_error = 01c; var_dump( $will_error ); The first two octals PHP accepts as valid input, and silently truncates each. It only displays an error message for 01c and mentions the 'c' being a problem. Why doesn't PHP consistently reject invalid octal values and display error messages? Expected result: I expected error messages to result for each of the first two invalid octals. Instead PHP blindly accepted them while having each evaluate as zero. It only caught on to 01c being a bad octal value. Actual result: -- int 0 int 0 Parse error: syntax error, unexpected 'c' (T_STRING) in ... -- Edit this bug report at https://bugs.php.net/bug.php?id=63705&edit=1
[PHP-BUG] Bug #63705 [NEW]: lack of error message
From: iam4webwork at hotmail dot com Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:lack of error message Description: PHP fails to display error messages consistently when user provides invalid octals. Test script: --- $octal = 00812; $another= 00934; var_dump( $octal, $another); $will_error = 01c; var_dump( $will_error ); The first two octals PHP accepts as valid input, and silently truncates each. It only displays an error message for 01c and mentions the 'c' being a problem. Why doesn't PHP consistently reject invalid octal values and display error messages? Expected result: I expected error messages to result for each of the first two invalid octals. Instead PHP blindly accepted them while having each evaluate as zero. It only caught on to 01c being a bad octal value. Actual result: -- int 0 int 0 Parse error: syntax error, unexpected 'c' (T_STRING) in ... -- Edit bug report at https://bugs.php.net/bug.php?id=63705&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63705&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63705&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63705&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63705&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63705&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63705&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63705&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63705&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63705&r=support Expected behavior: https://bugs.php.net/fix.php?id=63705&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63705&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63705&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63705&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63705&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63705&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63705&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63705&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63705&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63705&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63705&r=mysqlcfg
Bug #63073 [Opn]: master "make install" fails to install PEAR
Edit report at https://bugs.php.net/bug.php?id=63073&edit=1 ID: 63073 Updated by: dani...@php.net Reported by:php at bof dot de Summary:master "make install" fails to install PEAR Status: Open Type: Bug Package:Compile Failure Operating System: openSUSE 11.4 64bit -PHP Version:master-Git-2012-09-12 (Git) +PHP Version:5.5 Block user comment: N Private report: N New Comment: This needs to be fixed so PHP 5.5 can be properly tested. Things work as expected when building PHP <= 5.4. Previous Comments: [2012-10-14 11:06:27] bobvin at pillars dot net Branch master does not compile and also is missing file sapi/fpm/php- fpm.service.in Running git-bisect to find the break point, This is the commit that broke compilation: commit 4968fa644b0849321e1761e52b8db15dd46f9b75 Author: theanomaly...@gmail.com Date: Tue Apr 17 07:31:36 2012 -0400 Fixed bug #61038; "Z" and better behavior for unpack() Added new "Z" argument to pack/unpack, now allowing "a" to return data without stripping, and "A" strips all trailing white space, while "Z" will strip everything after the first null. [2012-09-12 15:30:17] php at bof dot de Description: I'm building PHP master from current git (at 5246d6f02e52798e343bd5208692f1a5ed89b9d9) Compile works fine, but on "make install", PEAR does not install. See "Actual result" regarding the error output I get. I can successfully compile AND install, with identical configure, the PHP-5.4.6 release, so I don't think that there is anything wrong with my build environment. I tried to copy over pecl, pear, and the pear environment, from the 5.4 build/install. pecl and pear search works. download or install fetches the file, but then fails with a similar "could not extract" error. Test script: --- make install Expected result: Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar- already installed: 1.3.7 [PEAR] Console_Getopt - already installed: 1.3.0 [PEAR] Structures_Graph- already installed: 1.0.4 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.9.4 Actual result: -- Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar: could not extract the package.xml file from "phar://install- pear-nozlib.phar/Archive_Tar-1.3.7.tar" [PEAR] Console_Getopt: could not extract the package.xml file from "phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar" [PEAR] Structures_Graph: could not extract the package.xml file from "phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar" [PEAR] XML_Util: could not extract the package.xml file from "phar://install- pear-nozlib.phar/XML_Util-1.2.1.tar" [PEAR] PEAR: could not extract the package.xml file from "phar://install-pear- nozlib.phar/PEAR-1.9.4.tar" -- Edit this bug report at https://bugs.php.net/bug.php?id=63073&edit=1
Req #54302 [Com]: var_dump truncates values with no option to output all values
Edit report at https://bugs.php.net/bug.php?id=54302&edit=1
ID: 54302
Comment by: jazz at funkynerd dot com
Reported by:php at falconfour dot com
Summary:var_dump truncates values with no option to output
all values
Status: Not a bug
Type: Feature/Change Request
Package:Variables related
Operating System: All
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
This is an xdebug thing. To remove the truncted output do this in your
xdebug.ini or php.ini file:
xdebug.var_display_max_data=-1
xdebug.var_display_max_children=-1
xdebug.var_display_max_depth=-1
Previous Comments:
[2011-03-18 10:02:51] ahar...@php.net
This is something XDebug does, not PHP. I'd suggest reporting it on the
XDebug issue tracker.
[2011-03-18 09:57:08] php at falconfour dot com
Description:
Simple as that... after var_dump() decides "enough is enough", it just
arbitrarily
cuts off the rest of the value with ellipses.
Seriously annoying when trying to debug a script (the only time I use var_dump
-
what other purpose does it serve in production?)... it produces a nice HTML
output, but
Test script:
---
$test = array('foo');
$test['foo'] = array('bar');
$test['foo']['this'] = array('that');
$test['foo']['this']['where'] = array('there');
$test['foo']['this']['where']['your'] = array('face');
$test['foo']['this']['where']['your']['mom'] = array('fat');
var_dump($test);
Expected result:
array
0 => string 'foo' (length=3)
'foo' =>
array
0 => string 'bar' (length=3)
'this' =>
array
0 => string 'that' (length=4)
'where' =>
array
0 => string 'there' (length=5)
'your' =>
array
0 => string
'face' (length=4)
'mom' =>
array
0 =>
string
'fat' (length=3)
Actual result:
--
array
0 => string 'foo' (length=3)
'foo' =>
array
0 => string 'bar' (length=3)
'this' =>
array
0 => string 'that' (length=4)
'where' =>
array
...
--
Edit this bug report at https://bugs.php.net/bug.php?id=54302&edit=1
Req #62574 [Opn]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 User updated by:thbley at gmail dot com Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: and maybe: - output htmlspecialchars+basename Previous Comments: [2012-12-05 23:26:45] thbley at gmail dot com So we have these use cases: - output unmodified content - output htmlspecialchars escaped content or - output strip_tags - output intval [2012-12-05 23:12:57] chuyu at microsoft dot com I was thinking the same thing. One advantage of using some template engines(twig, phptal) is that they automatically escape html characters during output. Many people use these template engine simply for that due to XSS worries. However if we have such an operator, then we create a simple php native template engine(which I'm all for), and in the template always use this operator to prevent XSS. I would suggest to make the operator like , the reason is that ~ is often located near the 'ESC' on the keyboard, so it feels more like escape :-) [2012-10-26 19:24:31] ajf at ajf dot me @dagguh: What? I'm just suggesting exporting variables into the global namespace, and escaping them in the process, for templating purposes. [2012-10-26 19:07:08] dagguh at gmail dot com This is valid. @ajf: You should never dop anything "ahead-of-time" in programming. You shoudl escape a variable right before passing it to en environment, that requires this form of escaping [2012-09-04 18:15:37] ajf at ajf dot me (I'm all for this though, I'm just pointing out other options) 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 https://bugs.php.net/bug.php?id=62574 -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
Req #62574 [Opn]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 User updated by:thbley at gmail dot com Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: So we have these use cases: - output unmodified content - output htmlspecialchars escaped content or - output strip_tags - output intval Previous Comments: [2012-12-05 23:12:57] chuyu at microsoft dot com I was thinking the same thing. One advantage of using some template engines(twig, phptal) is that they automatically escape html characters during output. Many people use these template engine simply for that due to XSS worries. However if we have such an operator, then we create a simple php native template engine(which I'm all for), and in the template always use this operator to prevent XSS. I would suggest to make the operator like , the reason is that ~ is often located near the 'ESC' on the keyboard, so it feels more like escape :-) [2012-10-26 19:24:31] ajf at ajf dot me @dagguh: What? I'm just suggesting exporting variables into the global namespace, and escaping them in the process, for templating purposes. [2012-10-26 19:07:08] dagguh at gmail dot com This is valid. @ajf: You should never dop anything "ahead-of-time" in programming. You shoudl escape a variable right before passing it to en environment, that requires this form of escaping [2012-09-04 18:15:37] ajf at ajf dot me (I'm all for this though, I'm just pointing out other options) [2012-09-04 18:06:32] ajf at ajf dot me You can escape things ahead-of-time, you know. In fact, I have a feeling you could use foreach to traverse the symtable and escape everything. (don't do that though, that's a horrendous idea) 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 https://bugs.php.net/bug.php?id=62574 -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
Req #62574 [Com]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 Comment by: chuyu at microsoft dot com Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I was thinking the same thing. One advantage of using some template engines(twig, phptal) is that they automatically escape html characters during output. Many people use these template engine simply for that due to XSS worries. However if we have such an operator, then we create a simple php native template engine(which I'm all for), and in the template always use this operator to prevent XSS. I would suggest to make the operator like , the reason is that ~ is often located near the 'ESC' on the keyboard, so it feels more like escape :-) Previous Comments: [2012-10-26 19:24:31] ajf at ajf dot me @dagguh: What? I'm just suggesting exporting variables into the global namespace, and escaping them in the process, for templating purposes. [2012-10-26 19:07:08] dagguh at gmail dot com This is valid. @ajf: You should never dop anything "ahead-of-time" in programming. You shoudl escape a variable right before passing it to en environment, that requires this form of escaping [2012-09-04 18:15:37] ajf at ajf dot me (I'm all for this though, I'm just pointing out other options) [2012-09-04 18:06:32] ajf at ajf dot me You can escape things ahead-of-time, you know. In fact, I have a feeling you could use foreach to traverse the symtable and escape everything. (don't do that though, that's a horrendous idea) [2012-07-16 04:07:43] thbley at gmail dot com Description: old: new: echo <$str>; ?> or: -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
Bug #63700 [Opn->Asn]: Buffer overrun in mysqlnd_reverse_api_register_api
Edit report at https://bugs.php.net/bug.php?id=63700&edit=1
ID: 63700
Updated by: johan...@php.net
Reported by:slangley at google dot com
Summary:Buffer overrun in mysqlnd_reverse_api_register_api
-Status: Open
+Status: Assigned
Type: Bug
Package:MySQL related
Operating System: N/A
PHP Version:5.4.9
-Assigned To:
+Assigned To:mysql
Block user comment: N
Private report: N
Previous Comments:
[2012-12-05 20:01:57] slangley at google dot com
Description:
Address sanitizer detected a buffer over run.
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff149259af at pc
0x7f3cfb7b1840 bp 0x7fff149258d0 sp 0x7fff149258c8
READ of size 1 at 0x7fff149259af thread T0
#0 0x7f3cfb7b183f php/v5_4_8/Zend/zend_hash.c:261 _zend_hash_add_or_update
#1 0x7f3cfba67ea1 php/v5_4_8/ext/mysqlnd/mysqlnd_reverse_api.c:63
mysqlnd_reverse_api_register_api
#2 0x7f3cfbb64bd3 php/v5_4_8/ext/pdo_mysql/pdo_mysql.c:123
zm_startup_pdo_mysql
#3 0x7f3cfb55af8d php/v5_4_8/Zend/zend_API.c:1661 zend_startup_module_ex
#4 0x7f3cfb7b5041 php/v5_4_8/Zend/zend_hash.c:716 zend_hash_apply
#5 0x7f3cfb55ba8e php/v5_4_8/Zend/zend_API.c:1788 zend_startup_modules
#6 0x7f3cfbf3b447 php/v5_4_8/main/main.c:2205 php_module_startup
Here's the patch to fix it
--- v5_4_8/ext/mysqlnd/mysqlnd_reverse_api.c.orig 2012-12-05
11:50:33.0 -0800
+++ v5_4_8/ext/mysqlnd/mysqlnd_reverse_api.c2012-12-05 11:50:52.0
-0800
@@ -61,7 +61,7 @@
mysqlnd_reverse_api_register_api(MYSQLND_REVERSE_API * apiext TSRMLS_DC)
{
zend_hash_add(&mysqlnd_api_ext_ht, apiext->module->name, strlen(apiext-
>module->name) + 1, &apiext,
- sizeof(MYSQLND_REVERSE_API), NULL);
+ sizeof(void*), NULL);
}
/* }}} */
--
Edit this bug report at https://bugs.php.net/bug.php?id=63700&edit=1
Bug #63699 [Opn->Asn]: Poor date()/etc performance [PATCH]
Edit report at https://bugs.php.net/bug.php?id=63699&edit=1
ID: 63699
Updated by: johan...@php.net
Reported by:njaguar at gmail dot com
Summary:Poor date()/etc performance [PATCH]
-Status: Open
+Status: Assigned
Type: Bug
Package:Performance problem
Operating System: *
PHP Version:5.4.9
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
Previous Comments:
[2012-12-05 15:52:47] njaguar at gmail dot com
Description:
More info: http://news.php.net/php.internals/64147
I ended up digging deeper and created a patch for this.
Summary of changes:
- Created a new tz_checked_valid flag on the global date structure
- Created a callback method when date.timezone is modified by the ini (set)
- Callback checks validity if set during runtime, and will error (with line
number) accordingly. This is probably useful for some users that might no
otherwise have realized they made a mistake on their ini_set() line in their
code.
- In guess_timezone(), if tz_checked_valid is not set, attempts to validate,
errors if cannot.
As previously noted from my benchmarks, over 1 million runs, it increased
performance from:
date: 1.751 sec
strftime: 1.872 sec
strtotime : 3.195 sec
to:
date: 1.238 sec
strftime: 0.999 sec
strtotime : 2.337 sec
Here is a test case to show that it will not blow up on invalid timezones, and
revalidates accordingly:
Note: If the ini is actually set wrong, it will not error until they call a
date function that makes use of the timezone, just like before.
Thanks!
Test script:
---
$c = 100;
for($i=0; $i<$c; $i++) date('F j, Y, g:i a');
etc..
Expected result:
Performance results are benchmarked and displayed in the general description
Actual result:
--
Performance results are benchmarked and displayed in the general description
--
Edit this bug report at https://bugs.php.net/bug.php?id=63699&edit=1
[PHP-BUG] Bug #63701 [NEW]: Php CLI does not respect display_errors option to report to STDOUT.
From: ksours at internetbrands dot com Operating system: CentOS PHP version: 5.3.19 Package: PHP options/info functions Bug Type: Bug Bug description:Php CLI does not respect display_errors option to report to STDOUT. Description: Run the script from the command line using something like: # php test.php > outstd.txt Note that I get the same behavior setting the display_errors in the php.ini instead of by the script. The problem only occurs in the CLI and only on Unix, Windows is fine. The use case here is that I would like to be able to test the eval, capture any errors, and report them via the app. Having it randomly output stuff to the stream messes up the reporting. There does not appear to be anyway to catch the output of STDERR with php using output buffering. Test script: --- Expected result: PHP Warning: include(foo): failed to open stream: No such file or directory in /home/ksours/test.php on line 4 PHP Warning: include(): Failed opening 'foo' for inclusion (include_path='.:/php/includes:/usr/share/pear') in /home/ksours/test.php on line 4 PHP Parse error: syntax error, unexpected T_STRING in /home/ksours/test.php(6) : eval()'d code on line 1 the outstd.txt will contain: Warning: include(foo): failed to open stream: No such file or directory in /home/ksours/test.php on line 4 Warning: include(): Failed opening 'foo' for inclusion (include_path='.:/php/includes:/usr/share/pear') in /home/ksours/test.php on line 4 string(3) "xxx" string(102) " Parse error: syntax error, unexpected T_STRING in /home/ksours/test.php(6) : eval()'d code on line 1 " string(3) "xxx" Actual result: -- No output to STDERR when display_errors is set to STDOUT. It's also odd that the output buffering captures the output, but its still displayed. -- Edit bug report at https://bugs.php.net/bug.php?id=63701&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63701&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63701&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63701&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63701&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63701&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63701&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63701&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63701&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63701&r=support Expected behavior: https://bugs.php.net/fix.php?id=63701&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63701&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63701&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63701&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63701&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63701&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63701&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63701&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63701&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63701&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63701&r=mysqlcfg
[PHP-BUG] Bug #63700 [NEW]: Buffer overrun in mysqlnd_reverse_api_register_api
From: slangley at google dot com
Operating system: N/A
PHP version: 5.4.9
Package: MySQL related
Bug Type: Bug
Bug description:Buffer overrun in mysqlnd_reverse_api_register_api
Description:
Address sanitizer detected a buffer over run.
ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff149259af at
pc
0x7f3cfb7b1840 bp 0x7fff149258d0 sp 0x7fff149258c8
READ of size 1 at 0x7fff149259af thread T0
#0 0x7f3cfb7b183f php/v5_4_8/Zend/zend_hash.c:261
_zend_hash_add_or_update
#1 0x7f3cfba67ea1 php/v5_4_8/ext/mysqlnd/mysqlnd_reverse_api.c:63
mysqlnd_reverse_api_register_api
#2 0x7f3cfbb64bd3 php/v5_4_8/ext/pdo_mysql/pdo_mysql.c:123
zm_startup_pdo_mysql
#3 0x7f3cfb55af8d php/v5_4_8/Zend/zend_API.c:1661
zend_startup_module_ex
#4 0x7f3cfb7b5041 php/v5_4_8/Zend/zend_hash.c:716 zend_hash_apply
#5 0x7f3cfb55ba8e php/v5_4_8/Zend/zend_API.c:1788 zend_startup_modules
#6 0x7f3cfbf3b447 php/v5_4_8/main/main.c:2205 php_module_startup
Here's the patch to fix it
--- v5_4_8/ext/mysqlnd/mysqlnd_reverse_api.c.orig 2012-12-05
11:50:33.0 -0800
+++ v5_4_8/ext/mysqlnd/mysqlnd_reverse_api.c2012-12-05 11:50:52.0
-0800
@@ -61,7 +61,7 @@
mysqlnd_reverse_api_register_api(MYSQLND_REVERSE_API * apiext TSRMLS_DC)
{
zend_hash_add(&mysqlnd_api_ext_ht, apiext->module->name, strlen(apiext-
>module->name) + 1, &apiext,
- sizeof(MYSQLND_REVERSE_API), NULL);
+ sizeof(void*), NULL);
}
/* }}} */
--
Edit bug report at https://bugs.php.net/bug.php?id=63700&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63700&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63700&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63700&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63700&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63700&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63700&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63700&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63700&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63700&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63700&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63700&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63700&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63700&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63700&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63700&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63700&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63700&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63700&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63700&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63700&r=mysqlcfg
Req #23241 [Com]: Perl's qq~~ and q~~ -> PHP?
Edit report at https://bugs.php.net/bug.php?id=23241&edit=1
ID: 23241
Comment by: php dot net at thehiltons dot net
Reported by:kitdekat_yh at yahoo dot com
Summary:Perl's qq~~ and q~~ -> PHP?
Status: Not a bug
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Win2K AdvSrv
PHP Version:4.3.2RC1
Block user comment: N
Private report: N
New Comment:
I would very much like to see this opened as an RFC. The end-of-discussion
nature of the "This is not perl" comment is incredibly closed minded. Much of
PHP's syntax is similar to Perl. It was adopted because it works. Not because
someone was trying to copy Perl. This also works. If you start taking away the
things in PHP which co-exist in Perl then you don't have a whole lot left.
That fact remains that a lack of qq or qq-like quoting is a hge deterrent
to
anyone looking to php after building a career in Perl (that, a cluttered
namespace, and messy regex wrappers, at least for me).
PHP (language A) is used all-the-damn-time for writing html (language B) with
inline javascript (language C)... each nested in quotes of the other. Choosing
your own quote character for the outer layer (PHP) is insanely useful for
writing readable and easy to maintain code. To ignore that value and dismiss
the
idea simply because it has roots in Perl is ridiculous. Absolutely ridiculous.
To do so without so much as a discussion is disrespectful at best, and easily
interpreted as un-welcoming or even hostile to those who might be looking to
make the transition from Perl.
Someone who is more involved with the project than I am - Please consider
opening this as a formal RFC.
It wouldn't be the first time it was recognized that providing functionality
which "Other web languages have similar syntax" for was a very good thing.
(https://wiki.php.net/rfc/shortsyntaxforarrays)
Previous Comments:
[2003-04-17 18:47:22] kitdekat_yh at yahoo dot com
fine.. its open-source, i'll implement it myself.
make it into a patch for all future releases...
thanks for the support.
[2003-04-16 10:38:19] w...@php.net
PHP is not perl; we won't be implementing this syntax.
[2003-04-16 10:07:55] kitdekat_yh at yahoo dot com
Perl has the ability to 'inline' HereDocs by using qq~~ (double quoting) and
q~~ (single quoting) a portion of text exactly like a HereDoc does (parsing
$vars while keeping nopn-escaped "s and 's as well) without taking up entire
lines for start and end tags. Also the ~ symbol can be replaced by any
character( q// and qq//, etc) that you wont be using within the string, and if
you do, can be escaped to still print it out. It also allows for multiple
HereDoc conversions on a single line, examples as follows:
echo <<< END_HERE1
remembers "quotes" and parses $vars
and 'remembers' new lines
END_HERE1;
echo join("\n", $array_list);
echo <<< END_HERE2
and continues.
END_HERE2;
can be done as follows:
echo qq~... "quotes" and $vars\n~ . join("\n", $array_list) . qq~and ...\n~;
which allows more condensed code and, atleast i think, makes creating complex
formatted HTML easier. This is not simply another alias btw (as mentioned in
#12779) but a varying functionality that increases the power of PHP as seen in
the examples. Since HereDocs do not do the q~~ (single quote version) at all
nor do they function with multiples 'inline'd either.
I feel that this will alleviate many Perl convert's problems with formatting
their pages a specific way and allow them to write however they need it written
at the moment.
--
Edit this bug report at https://bugs.php.net/bug.php?id=23241&edit=1
Bug #63638 [Com]: Cannot connect to SQL Server 2008 with PDO dblib
Edit report at https://bugs.php.net/bug.php?id=63638&edit=1
ID: 63638
Comment by: f dot marquis at of2m dot fr
Reported by:pmeunier at cybergeneration dot com
Summary:Cannot connect to SQL Server 2008 with PDO dblib
Status: Open
Type: Bug
Package:PDO related
Operating System: Linux Slackware 13
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
same problem here, but only from time to time (not all connections are failing
like with pmeunier)
seems related to #63258
Previous Comments:
[2012-11-28 21:43:00] pmeunier at cybergeneration dot com
We made a compare between the /ext/pdo_dblib/ php 5.4.7 and php 5.4.9 and found
only one file was changed. Line 318 in dblib_driver.c went from :
// In PHP 5.4.7
DBSETOPT(H->link, DBQUOTEDIDENT, 1);
To :
// In PHP 5.4.9
DBSETOPT(H->link, DBQUOTEDIDENT, NULL);
For fun, we tried to revert to passing 1 for the last parameter... and guess
what ? It worked. Since we don't actually understand what this function makes,
and why the parameter was changed, we don't find this solution very clean,
unless it is eventually confirmed by a PHP developper.
[2012-11-28 21:09:02] pmeunier at cybergeneration dot com
Description:
We are relying on PDO_DBLIB to connect to our SQL Server 2008 Server in PHP,
hosted on a Linux platform. We were running PHP 5.4.7 and everything was fine.
When we upgraded to 5.4.9, all connections to SQL Server were failing with the
following error : Warning: PDO::__construct(): Called dbsetopt with parameter 3
NULL (severity 11). We tried with different logins to be sure that it was not a
permission issue, but the bug also occurs when trying to log with 'sa'.
Test script:
---
$connection = new PDO('dblib:host=myServerHost;dbname=MyDatabase', 'username',
'pass');
Expected result:
We expect no warnings to be thrown and connection to SQL Server to work
Actual result:
--
A warning is thrown : Warning: PDO::__construct(): Called dbsetopt with
parameter
3 NULL (severity 11)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63638&edit=1
Req #51001 [Com]: Always shows stack trace when a Fatal error occurs
Edit report at https://bugs.php.net/bug.php?id=51001&edit=1
ID: 51001
Comment by: anrdaemon at freemail dot ru
Reported by:abdallah at gmx dot com
Summary:Always shows stack trace when a Fatal error occurs
Status: Feedback
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Windows 7
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
I'm facing a problem in tracking down various issues in a complex project, and
I would greatly benefit from ability to call Exception::getTraceAsString()
statically.
So that instead of doing something like
default:
if(isset($GLOBALS['toolDebugfilterEnabled']) &&
$GLOBALS['toolDebugfilterEnabled'] === true)
{
print('Breakpoint reached in: ');
$e = new Exception($mode);
print($e->getTraceAsString());
I could just do a
default:
if(isset($GLOBALS['toolDebugfilterEnabled']) &&
$GLOBALS['toolDebugfilterEnabled'] === true)
{
print('Breakpoint reached in: ');
print(Exception::getTraceAsString());
and be done with it.
Previous Comments:
[2011-04-12 20:40:30] dharkness at gmail dot com
You actually have to remove the try/catch to reproduce the problem. When you
catch the exception, no fatal error is raised and you can see the stack trace.
If
you don't catch the exception, the PHP engine raises an E_FATAL error which
cannot be trapped.
We use a shutdown hook and check for fatal errors so we can report the issue,
but
at that point there's no stack trace--just the file and line where the error
occurred. It would be nice to have a similar function to error_get_last() to
get
the stack trace, such as backtrace_get_last().
[2010-11-24 09:44:26] j...@php.net
I do get a trace here using your reproduce script with PHP 5.3.4RC1. So what is
the problem?
[2010-04-10 01:51:31] a at b dot c dot de
An observation from me:
A stack trace is dumped in the event of a fatal error (depending on the error
reporting level); but it's only when an uncaught exception reaches the top of
the call stack without being handled that such an error occurs. If it is
caught, then it's not an uncaught exception and therefore not a Fatal error.
[2010-02-10 20:05:24] abdallah at gmx dot com
Description:
Always shows stack trace when a Fatal error occurs without having to do always
something like this :
getTraceAsString();
}
?>
Reproduce code:
---
getTraceAsString();
}
?>
Expected result:
#0 /home/bjori/tmp/ex.php(7): test()
#1 {main}
Actual result:
--
nothin'
--
Edit this bug report at https://bugs.php.net/bug.php?id=51001&edit=1
[PHP-BUG] Bug #63699 [NEW]: Poor date()/etc performance [PATCH]
From: njaguar at gmail dot com
Operating system: *
PHP version: 5.4.9
Package: Performance problem
Bug Type: Bug
Bug description:Poor date()/etc performance [PATCH]
Description:
More info: http://news.php.net/php.internals/64147
I ended up digging deeper and created a patch for this.
Summary of changes:
- Created a new tz_checked_valid flag on the global date structure
- Created a callback method when date.timezone is modified by the ini
(set)
- Callback checks validity if set during runtime, and will error (with line
number) accordingly. This is probably useful for some users that might no
otherwise have realized they made a mistake on their ini_set() line in
their code.
- In guess_timezone(), if tz_checked_valid is not set, attempts to
validate, errors if cannot.
As previously noted from my benchmarks, over 1 million runs, it increased
performance from:
date: 1.751 sec
strftime: 1.872 sec
strtotime : 3.195 sec
to:
date: 1.238 sec
strftime: 0.999 sec
strtotime : 2.337 sec
Here is a test case to show that it will not blow up on invalid timezones,
and revalidates accordingly:
Note: If the ini is actually set wrong, it will not error until they call a
date function that makes use of the timezone, just like before.
Thanks!
Test script:
---
$c = 100;
for($i=0; $i<$c; $i++) date('F j, Y, g:i a');
etc..
Expected result:
Performance results are benchmarked and displayed in the general
description
Actual result:
--
Performance results are benchmarked and displayed in the general
description
--
Edit bug report at https://bugs.php.net/bug.php?id=63699&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63699&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63699&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63699&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63699&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63699&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63699&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63699&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63699&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63699&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63699&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63699&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63699&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63699&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63699&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63699&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63699&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63699&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63699&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63699&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63699&r=mysqlcfg
Bug #62003 [Com]: LDAP compile failure
Edit report at https://bugs.php.net/bug.php?id=62003&edit=1 ID: 62003 Comment by: fernando dot wendt at gmail dot com Reported by:aconnor at ait dot ie Summary:LDAP compile failure Status: Open Type: Bug Package:Compile Failure Operating System: Ubuntu server 12.04 PHP Version:5.4.3 Block user comment: N Private report: N New Comment: When compiling PHP 5.4.9, trying to enable both oci8 (instantclient, 11.2) and ldap modules, it points the same issue, and fails. The little bit diff is that once you point --with-ldap, it seems to compile it, but - by a misunderstood behavior, it uses the ldap.h from instantclient sdk file! Of course, make fails. Reading at OTN forum, theres is a thread where some people does not recommend compiling them togheter: the suggest is to compile PHP with ldap, and install oci8 with PECL, after [https://forums.oracle.com/forums/thread.jspa? messageID=10319335]. Works to me: i was needing ldap at first. oci8, will be added after. Best regards Previous Comments: [2012-06-28 13:41:19] macolinovo at gmail dot com I'm also with same problem [2012-05-11 10:42:37] aconnor at ait dot ie Description: I am trying configure php 5.4.3 from source on a ubuntu 12.04 server build using this switch --with-ldap=/usr i get this error: configure: error: Cannot find ldap libraries in /usr/lib. So i change to --with-ldap=/usr/lib Then i get this error: configure: error: Cannot find ldap.h So i find ldap.h in /usr/include I created a sym link for the /include directory in the /usr/lib directory, so the config might see ldap.h. I have tried ln -s /usr/include/ /usr/lib and ln -s /usr/include/ldap.h /usr/lib/ but i still get the same error. also: Permissions on the directory /usr/lib: drwxr-xr-x 53 root root 4096 May 11 09:06 lib I chmod 777 the ldap.h file. Then ran ln -s /usr/include/ldap.h /usr/lib/ i also tried ln -s /usr/include/ldap.h . Both create the link it appears as : lrwxrwxrwx 1 root root 19 May 11 09:00 ldap.h -> /usr/include/ldap.h But still the same error -- Edit this bug report at https://bugs.php.net/bug.php?id=62003&edit=1
Bug #63683 [Asn->Csd]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63683&edit=1 ID: 63683 Updated by: dmi...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties -Status: Assigned +Status: Closed Type: Bug Package:Date/time related PHP Version:5.4.9 Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-04 05:48:41] larue...@php.net The following patch has been added/updated: Patch Name: bug63683.patch Revision: 1354600121 URL: https://bugs.php.net/patch-display.php?bug=63683&patch=bug63683.patch&revision=1354600121 [2012-12-04 05:48:02] larue...@php.net Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63683&edit=1
Bug #63682 [Asn->Csd]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63682&edit=1 ID: 63682 Updated by: dmi...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties -Status: Assigned +Status: Closed Type: Bug Package:SimpleXML related PHP Version:5.4.9 Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-04 06:09:07] larue...@php.net The following patch has been added/updated: Patch Name: bug63682.patch Revision: 1354601347 URL: https://bugs.php.net/patch-display.php?bug=63682&patch=bug63682.patch&revision=1354601347 [2012-12-04 05:41:15] larue...@php.net The following patch has been added/updated: Patch Name: bug63682.patch Revision: 1354599675 URL: https://bugs.php.net/patch-display.php?bug=63682&patch=bug63682.patch&revision=1354599675 [2012-12-04 05:40:38] larue...@php.net Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63682&edit=1
Bug #63681 [Asn->Csd]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63681&edit=1 ID: 63681 Updated by: dmi...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties -Status: Assigned +Status: Closed Type: Bug Package:SPL related PHP Version:5.4.9 Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-04 05:33:48] larue...@php.net The following patch has been added/updated: Patch Name: bug63681.patch Revision: 1354599228 URL: https://bugs.php.net/patch-display.php?bug=63681&patch=bug63681.patch&revision=1354599228 [2012-12-04 05:33:22] larue...@php.net Description: imporve the gc handler for spl_object Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63681&edit=1
Bug #63680 [Csd]: Memleak in splfixedarray with cycle reference
Edit report at https://bugs.php.net/bug.php?id=63680&edit=1 ID: 63680 Updated by: dmi...@php.net Reported by:larue...@php.net Summary:Memleak in splfixedarray with cycle reference Status: Closed Type: Bug Package:SPL related PHP Version:5.4.9 Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-05 13:59:47] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=881416cda670a7ddb94db11a41d4929425da7d61 Log: Fixed bug #63680 (Memleak in splfixedarray with cycle reference) [2012-12-04 05:23:20] larue...@php.net The following patch has been added/updated: Patch Name: bug63680.patch Revision: 1354598600 URL: https://bugs.php.net/patch-display.php?bug=63680&patch=bug63680.patch&revision=1354598600 [2012-12-04 05:22:46] larue...@php.net Description: dmitry introduced the new get_gc handler, but seems splfixedarray doesn't implement it. also there are some other extensions still using ugly implementation for gc, I will review them one by one. thanks Test script: --- https://bugs.php.net/bug.php?id=63680&edit=1
Bug #63680 [Asn->Csd]: Memleak in splfixedarray with cycle reference
Edit report at https://bugs.php.net/bug.php?id=63680&edit=1 ID: 63680 Updated by: dmi...@php.net Reported by:larue...@php.net Summary:Memleak in splfixedarray with cycle reference -Status: Assigned +Status: Closed Type: Bug Package:SPL related PHP Version:5.4.9 Assigned To:dmitry Block user comment: N Private report: N New Comment: Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=881416cda670a7ddb94db11a41d4929425da7d61 Log: Fixed bug #63680 (Memleak in splfixedarray with cycle reference) Previous Comments: [2012-12-04 05:23:20] larue...@php.net The following patch has been added/updated: Patch Name: bug63680.patch Revision: 1354598600 URL: https://bugs.php.net/patch-display.php?bug=63680&patch=bug63680.patch&revision=1354598600 [2012-12-04 05:22:46] larue...@php.net Description: dmitry introduced the new get_gc handler, but seems splfixedarray doesn't implement it. also there are some other extensions still using ugly implementation for gc, I will review them one by one. thanks Test script: --- https://bugs.php.net/bug.php?id=63680&edit=1
Bug #44942 [Com]: exec() hangs apache
Edit report at https://bugs.php.net/bug.php?id=44942&edit=1
ID: 44942
Comment by: claudix dot kernel at gmail dot com
Reported by:inqualab1985 at gmail dot com
Summary:exec() hangs apache
Status: Duplicate
Type: Bug
Package:Program Execution
Operating System: Windows 2000 SP4
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Seen the same behavior, not only in exec(), but also in similar functions as
proc_open/proc_close. When there are concurrent scripts during a same PHP
session, the script spawning the process randomly hangs.
System:
- Windows 2003 server SP2
- Apache 2.2.22/ PHP 5.4.3
I can confirm that calling session_write_close() and then session_start() does
the trick.
I've observed, though, that the code below doesn't work:
$proc = proc_open($cmd,$pipedesc,$pipes);
//do stuff with pipes...
//... and close pipes
session_write_close(); //Close session before hanging function
$retval = proc_close($proc);
session_start(); //restore session
But the code below *does* work:
session_write_close(); //Close the session before proc_open()
$proc = proc_open($cmd,$pipedesc,$pipes);
//do stuff with pipes...
//... and close pipes
$retval = proc_close($proc);
session_start(); //restore session
This made me go into the PHP source code (actually the source file
"proc_open.c"). I've noticed that the command passed to proc_open() is spawned
by calling the WINAPI function CreateProcess(...) with the parameter
"bInheritHandles" set to TRUE. As of MSDN documentation, if this parameter is
TRUE then all handles are inherited by the child process. It seems that the
handle of the session is being inherited by the child process but for some
reason the OS doesn't release it when the process ends, eventually yielding a
deadlock. The code snippets above show this: the session has to be closed
before calling proc_open() to prevent the spawned command from inheriting the
session handle. People using exec() cannot see this effect because exec()
virtually embeds proc_open/proc_close.
May this give a clue to PHP developers?
Claudi
Previous Comments:
[2012-10-15 15:00:52] mail at GerhardBechtold dot com
Pajoye,
I didn't find any documentation on the service sensitivity of the new PHP.
You might be right, that the eof of the console stream is not taken care
properly, but in my case the system is now working (again).
[2012-10-15 09:12:30] paj...@php.net
@mail at GerhardBechtold dot com
this is documented, the shell/exec permissions have to be given.
However I do not think it is related to the original issue which is caused by a
real bug in the php stream, where the eof of the console stream is not
correctly
detected and ends in an endless loop.
[2012-10-14 15:28:38] mail at GerhardBechtold dot com
After many hours of testing, I managed to solve my problem of exec() calls in
PHP. This might be useful also for other developers, as I have seen many
struggling with te same problem.
1. xampp must be installed in real (!) administrator mode (in Windows 7 / 32 &
64 bit).
2. In many environments, Apache and MySQL should not run as services, but be
manually started (even not with interaction with desktop).
I have put a step-by-step procedure to troubleshoot at:
http://www.gerhardbechtold.com/LUPMIS/Manual/a15_xamppmap_maker_installation.html
(Ignore the references to our system LUPMIS).
Good luck to everybody
Gerhard
[2012-09-27 21:02:13] mail at GerhardBechtold dot com
Thanks for looking into my problems with exec() at the latest PHP.
Example for actual code, as in application (was running nicely in earlier PHP
installations, but not under PHP 2.4 anymore):
$str1Name = "C:\Map Maker\MMmacro.exe";
$str2Name = "command=remove layer";
exec(chr(34).$str1Name.chr(34).chr(32).chr(34).$str2Name.chr(34));
I am using a GIS called Map Maker, with powerful MMmacro functions
(www.mapmaker.com). 'remove layer' is one of the most basic parameters of
MMmacro.
A more simple test version also failed:
$str1Name = "C:\Windows\Notepad.exe";
exec($str1Name);
I also tested, all without success:
- with bat file, which then calls notepad.exe
- with exe/bat in different folders: document root (C:\xampp\htdocs) or from
calling directory (C:\xampp\htdocs\lupmis_s)
- with 'start .'
- with popen
- with exec( < file.in > file.out 2> nul", $output);
- with exec(,$output, $return);
- with exec("ping google.com", $output, $return);
-
My environment:
PHP 5.4.4 (VC 9)
Apache 2.4
Bug #63380 [Asn]: Allocation via libxml does not use PHP's per-request allocator
Edit report at https://bugs.php.net/bug.php?id=63380&edit=1
ID: 63380
Updated by: paj...@php.net
Reported by:tstarl...@php.net
Summary:Allocation via libxml does not use PHP's per-request
allocator
Status: Assigned
Type: Bug
Package:XML related
Operating System: Linux
PHP Version:master-Git-2012-10-29 (Git)
Assigned To:tstarling
Block user comment: N
Private report: N
New Comment:
That is a very well known issues when mixed builds free and alloc same memory
areas.
It is (almost) no problem when using libc allocation system but it is a (huge)
problem when php uses PHP memory manager and other libc or their own mm. It
leads
to crashes, almost always.
Previous Comments:
[2012-12-05 11:41:07] tstarl...@php.net
Do you know of a specific case where request-local allocations could bleed into
mod_perl and cause memory corruption?
I have reviewed all of libxml's global variables and ensured that they cannot
be made to hold pointers to request-local allocations. The hooks are disabled
at post-deactivate via a thread-local variable, so a perl request will not get
request-local pointers from xmlMalloc() whether it runs in its own thread
concurrently, or in the same thread as PHP but at a later time. TSRM_FETCH()
should give default global variables, with local request allocation disabled,
even if it is called from a thread where PHP has never been used.
Either way, I would be happy to make this configurable, off by default, since
the robustness of the solution depends on details of global pointer storage in
libxml which may change in the future. So my patch does introduce a maintenance
burden, with a risk of dangling pointers if that maintenance is not kept up to
date. I'm just not keen on having the documentation say that there are known
issues with interaction with other Apache modules unless that is truly the case.
[2012-12-05 11:08:41] rricha...@php.net
There is a major problem with doing this and why I didn't end tying into the
PHP
memory allocator. Depending upon setup, it is extremely likely to be able to
hit
memory corruption and/or mix memory allocations between modules. i.e. using
mod_perl and mod_php will cause PHP to override the libxml memory handling
functions (which are global) and bleed into mod_perl (or any others that are
using libxml2) causing any number of results (crashes, security issues, etc..).
The only way to be able to do something like this would be to make it compile
time option which is disabled by default allowing those who know their
environment intimately can utilize this at their own risk, Don't know if you
want to write a patch for that or not. Otherwise I don't see any way this could
safely be added,
[2012-10-29 21:55:03] tstarl...@php.net
https://github.com/php/php-src/pull/223
[2012-10-29 03:25:17] tstarl...@php.net
Description:
Allocation via libxml does not use PHP's per-request allocator. So any memory
used by libxml will not be accounted against memory_get_usage() or memory_limit.
At Wikimedia we use libxml DOM trees to store wikitext parse trees, because
they are more compact in memory than the equivalent pure-PHP data structures.
When these parse trees are cached, the memory requirements can become
excessive, and the memory is typically not returned to the system after request
termination. Using xmlMemSetup() to set hook functions which use PHP's
per-request allocation functions will allow us to more effectively monitor and
limit the use of libxml in production.
I've developed a patch and will submit it to GitHub as a pull request.
Test script:
---
$doc = new DOMDocument;
for ( $i = 0; $i < 100 ; $i++ ) {
$doc->appendChild($doc->createElement('foo'));
}
print memory_get_usage()."\n";
Expected result:
312331440 (with debug and ZTS)
Actual result:
--
694256
--
Edit this bug report at https://bugs.php.net/bug.php?id=63380&edit=1
Bug #63380 [Asn]: Allocation via libxml does not use PHP's per-request allocator
Edit report at https://bugs.php.net/bug.php?id=63380&edit=1
ID: 63380
Updated by: tstarl...@php.net
Reported by:tstarl...@php.net
Summary:Allocation via libxml does not use PHP's per-request
allocator
Status: Assigned
Type: Bug
Package:XML related
Operating System: Linux
PHP Version:master-Git-2012-10-29 (Git)
Assigned To:tstarling
Block user comment: N
Private report: N
New Comment:
Do you know of a specific case where request-local allocations could bleed into
mod_perl and cause memory corruption?
I have reviewed all of libxml's global variables and ensured that they cannot
be made to hold pointers to request-local allocations. The hooks are disabled
at post-deactivate via a thread-local variable, so a perl request will not get
request-local pointers from xmlMalloc() whether it runs in its own thread
concurrently, or in the same thread as PHP but at a later time. TSRM_FETCH()
should give default global variables, with local request allocation disabled,
even if it is called from a thread where PHP has never been used.
Either way, I would be happy to make this configurable, off by default, since
the robustness of the solution depends on details of global pointer storage in
libxml which may change in the future. So my patch does introduce a maintenance
burden, with a risk of dangling pointers if that maintenance is not kept up to
date. I'm just not keen on having the documentation say that there are known
issues with interaction with other Apache modules unless that is truly the case.
Previous Comments:
[2012-12-05 11:08:41] rricha...@php.net
There is a major problem with doing this and why I didn't end tying into the
PHP
memory allocator. Depending upon setup, it is extremely likely to be able to
hit
memory corruption and/or mix memory allocations between modules. i.e. using
mod_perl and mod_php will cause PHP to override the libxml memory handling
functions (which are global) and bleed into mod_perl (or any others that are
using libxml2) causing any number of results (crashes, security issues, etc..).
The only way to be able to do something like this would be to make it compile
time option which is disabled by default allowing those who know their
environment intimately can utilize this at their own risk, Don't know if you
want to write a patch for that or not. Otherwise I don't see any way this could
safely be added,
[2012-10-29 21:55:03] tstarl...@php.net
https://github.com/php/php-src/pull/223
[2012-10-29 03:25:17] tstarl...@php.net
Description:
Allocation via libxml does not use PHP's per-request allocator. So any memory
used by libxml will not be accounted against memory_get_usage() or memory_limit.
At Wikimedia we use libxml DOM trees to store wikitext parse trees, because
they are more compact in memory than the equivalent pure-PHP data structures.
When these parse trees are cached, the memory requirements can become
excessive, and the memory is typically not returned to the system after request
termination. Using xmlMemSetup() to set hook functions which use PHP's
per-request allocation functions will allow us to more effectively monitor and
limit the use of libxml in production.
I've developed a patch and will submit it to GitHub as a pull request.
Test script:
---
$doc = new DOMDocument;
for ( $i = 0; $i < 100 ; $i++ ) {
$doc->appendChild($doc->createElement('foo'));
}
print memory_get_usage()."\n";
Expected result:
312331440 (with debug and ZTS)
Actual result:
--
694256
--
Edit this bug report at https://bugs.php.net/bug.php?id=63380&edit=1
Bug #63380 [Asn]: Allocation via libxml does not use PHP's per-request allocator
Edit report at https://bugs.php.net/bug.php?id=63380&edit=1
ID: 63380
Updated by: rricha...@php.net
Reported by:tstarl...@php.net
Summary:Allocation via libxml does not use PHP's per-request
allocator
Status: Assigned
Type: Bug
Package:XML related
Operating System: Linux
PHP Version:master-Git-2012-10-29 (Git)
-Assigned To:rrichards
+Assigned To:tstarling
Block user comment: N
Private report: N
New Comment:
There is a major problem with doing this and why I didn't end tying into the
PHP
memory allocator. Depending upon setup, it is extremely likely to be able to
hit
memory corruption and/or mix memory allocations between modules. i.e. using
mod_perl and mod_php will cause PHP to override the libxml memory handling
functions (which are global) and bleed into mod_perl (or any others that are
using libxml2) causing any number of results (crashes, security issues, etc..).
The only way to be able to do something like this would be to make it compile
time option which is disabled by default allowing those who know their
environment intimately can utilize this at their own risk, Don't know if you
want to write a patch for that or not. Otherwise I don't see any way this could
safely be added,
Previous Comments:
[2012-10-29 21:55:03] tstarl...@php.net
https://github.com/php/php-src/pull/223
[2012-10-29 03:25:17] tstarl...@php.net
Description:
Allocation via libxml does not use PHP's per-request allocator. So any memory
used by libxml will not be accounted against memory_get_usage() or memory_limit.
At Wikimedia we use libxml DOM trees to store wikitext parse trees, because
they are more compact in memory than the equivalent pure-PHP data structures.
When these parse trees are cached, the memory requirements can become
excessive, and the memory is typically not returned to the system after request
termination. Using xmlMemSetup() to set hook functions which use PHP's
per-request allocation functions will allow us to more effectively monitor and
limit the use of libxml in production.
I've developed a patch and will submit it to GitHub as a pull request.
Test script:
---
$doc = new DOMDocument;
for ( $i = 0; $i < 100 ; $i++ ) {
$doc->appendChild($doc->createElement('foo'));
}
print memory_get_usage()."\n";
Expected result:
312331440 (with debug and ZTS)
Actual result:
--
694256
--
Edit this bug report at https://bugs.php.net/bug.php?id=63380&edit=1
[PHP-BUG] Bug #63695 [NEW]: PHP doesn't build with shared extensions and dtrace enabled
From: d...@php.net Operating system: Solaris 11 PHP version: 5.5.0alpha1 Package: *General Issues Bug Type: Bug Bug description:PHP doesn't build with shared extensions and dtrace enabled Description: PHP doesn't build if an extension is to build shared and --enable-dtrace is enabled. Test script: --- ./configure --enable-calendar=shared --enable-dtrace Expected result: build complete Actual result: -- __dtrace_php___request__shutdownmain/.libs/main.o __dtrace_php___exception__caughtZend/.libs/zend_execute.o __dtrace_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___request__startup main/.libs/main.o __dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o __dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o $dtrace15765465.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o __dtrace_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___error Zend/.libs/zend.o __dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o /fastcgi.lo -lresolv -lrt -lm -lnsl -lsocket -lgcc -o sapi/cgi/php-cgi UndefinedUndefined first referenced symbol in firstfile __dtraceenabled_php___execute__entryreferenced Zend/.libs /zend_dtrace.o symbol__dtraceenabled_php___execute__return Zend/ .libs/ zend_dtrace.o __dtrace_php___compile__file__return Zend/ .libs/ zend_dtrace.o __dtrace_php___exception__thrown Zendin/.libs/ zend_exceptions.o file__dtrace_php___error __dtraceenabled_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___compile__file__return Zend/.libs/zend_dtrace.o __dtrace_php___exception__thrownZend/.libs/zend_exceptions.o __dtrace_php___errorZend/.libs/zend.o __dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o ld: fatal: symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status Zend/.libs/zend.o __dtrace_php___function__entry Zend/.libs/zend_dtrace.o __dtrace_php___function__return Zend/.libs/zend_dtrace.o __dtrace_php___request__shutdownmain/.libs/main.o __dtrace_php___exception__caughtZend/.libs/zend_execute.o __dtrace_php___execute__return Zend/.libs/zend_dtrace.o __dtrace_php___request__startup main/.libs/main.o __dtraceenabled_php___exception__caught Zend/.libs/zend_execute.o __dtrace_php___compile__file__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___function__entry Zend/.libs/zend_dtrace.o $dtrace15765465.ZEND_CATCH_SPEC_CONST_CV_HANDLER Zend/zend_dtrace.d.o __dtrace_php___execute__entry Zend/.libs/zend_dtrace.o __dtraceenabled_php___error Zend/.libs/zend.o __dtraceenabled_php___function__return Zend/.libs/zend_dtrace.o __dtraceenabled_php___exception__thrown Zend/.libs/zend_exceptions.o ld: fatal: symbol referencing errors. No output written to sapi/cgi/php-cgi collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 make: *** Waiting for unfinished jobs make: *** [sapi/cgi/php-cgi] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=63695&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63695&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63695&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63695&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63695&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63695&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63695&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63695&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63695&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63695&r=support Expected behavior: https://bugs.php.net/fix.php?id=63695&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63695&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63695&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63695&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63695&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63695&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63695&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63695&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63695&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63695&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63695&r=mysqlcfg
Bug #63691 [Fbk->Opn]: Segmentation Fault (_zend_mm_free_int)
Edit report at https://bugs.php.net/bug.php?id=63691&edit=1 ID: 63691 User updated by:shivammaharshi at gmail dot com Reported by:shivammaharshi at gmail dot com Summary:Segmentation Fault (_zend_mm_free_int) -Status: Feedback +Status: Open Type: Bug Package:*General Issues Operating System: i386-redhat-linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: I won't be able to pass a sample script for this. As I said even if I did, it would be very improbable that you produce this error. It happens in high load condition, that too a very few times. As you guys have knowledge about how the memory manager in php works. I was hoping may be you can give some quick fix or configuration setting which will help reduce them a little. Previous Comments: [2012-12-05 08:59:41] larue...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. if there is no test script, then we can not do anything... please, try to refine a reproduce script or scripts. thanks [2012-12-05 07:16:15] shivammaharshi at gmail dot com Description: I am getting segmentation faults on the live server. Here is the core dump below. PHP Version : 5.4.6 Zend Module is Used. Please Notice that segmentation faults are 50-100 a day in number. The total hits I am getting on my Live servers are > 1. So no script can be given to reproduce this error. From what I understand this has a problem with accessing the variable which has been de-referenced already. Thus getting segmentation faults. Kindly help me fix this, or may be suggest a work around. Core was generated by `/usr/local/apache/bin/httpd -k start'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libssl.so.4...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/local/apache/lib/libaprutil-0.so.0...done. Loaded symbols for /usr/local/apache/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libgdbm.so.2...done. Loaded symbols for /usr/lib/libgdbm.so.2 Reading symbols from /usr/lib/tls/i686/libdb-4.2.so...done. Loaded symbols for /usr/lib/tls/i686/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/apache/lib/libapr-0.so.0...done. Loaded symbols for /usr/local/apache/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/local/apache/modules/libphp5.so...done. Loaded symbols for /usr/local/apache/modules/libphp5.so Reading symbols from /usr/local/mysql/lib/mysql/libmysqlclient.so.15...done. Loaded symbols for /usr/local/mysql/lib/mysql/libmysqlclient.so.15 Reading symbols from /usr/lib/libpng12.so.0...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libcurl.so.3...done. Loaded symbols for /usr/lib/libcurl
Bug #62351 [Com]: UTF-8 chars fail to be printed out properly with zend.multibyte
Edit report at https://bugs.php.net/bug.php?id=62351&edit=1 ID: 62351 Comment by: bukin242 at yandex dot ru Reported by:php at sebastianmendel dot de Summary:UTF-8 chars fail to be printed out properly with zend.multibyte Status: Open Type: Bug Package:Unicode Engine related Operating System: GNU/Linux PHP Version:5.4.4 Block user comment: N Private report: N New Comment: Please fix in the new versions of php Previous Comments: [2012-06-18 15:18:20] php at sebastianmendel dot de Description: Enabling zend.multibyte and having declare(encoding = UTF-8) in UTF-8 encoded scripts does not print UTF-8 chars properly. Same script (still encoded as UTF-8) but with declare(encoding = ISO-8859-1) prints out UTF-8 chars correct. >/opt/phpfarm/inst/bin/php-5.4.4 -i | grep multi zend.multibyte => On => On >/opt/phpfarm/inst/bin/php-5.4.4 -i | grep UTF default_charset => UTF-8 => UTF-8 zend.script_encoding => UTF-8 => UTF-8 exif.encode_unicode => UTF-8 => UTF-8 iconv.input_encoding => UTF-8 => UTF-8 iconv.internal_encoding => UTF-8 => UTF-8 iconv.output_encoding => UTF-8 => UTF-8 LANG => de_DE.UTF-8 _SERVER["LANG"] => de_DE.UTF-8 Test script: --- Expected result: "aäaà "aäaà Actual result: -- "aa "aâaâ -- Edit this bug report at https://bugs.php.net/bug.php?id=62351&edit=1
Bug #63691 [Opn->Fbk]: Segmentation Fault (_zend_mm_free_int)
Edit report at https://bugs.php.net/bug.php?id=63691&edit=1 ID: 63691 Updated by: larue...@php.net Reported by:shivammaharshi at gmail dot com Summary:Segmentation Fault (_zend_mm_free_int) -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: i386-redhat-linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. if there is no test script, then we can not do anything... please, try to refine a reproduce script or scripts. thanks Previous Comments: [2012-12-05 07:16:15] shivammaharshi at gmail dot com Description: I am getting segmentation faults on the live server. Here is the core dump below. PHP Version : 5.4.6 Zend Module is Used. Please Notice that segmentation faults are 50-100 a day in number. The total hits I am getting on my Live servers are > 1. So no script can be given to reproduce this error. From what I understand this has a problem with accessing the variable which has been de-referenced already. Thus getting segmentation faults. Kindly help me fix this, or may be suggest a work around. Core was generated by `/usr/local/apache/bin/httpd -k start'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libssl.so.4...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/local/apache/lib/libaprutil-0.so.0...done. Loaded symbols for /usr/local/apache/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libgdbm.so.2...done. Loaded symbols for /usr/lib/libgdbm.so.2 Reading symbols from /usr/lib/tls/i686/libdb-4.2.so...done. Loaded symbols for /usr/lib/tls/i686/libdb-4.2.so Reading symbols from /usr/lib/libexpat.so.0...done. Loaded symbols for /usr/lib/libexpat.so.0 Reading symbols from /usr/local/apache/lib/libapr-0.so.0...done. Loaded symbols for /usr/local/apache/lib/libapr-0.so.0 Reading symbols from /lib/tls/librt.so.1...done. Loaded symbols for /lib/tls/librt.so.1 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/tls/libpthread.so.0...done. Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/local/apache/modules/libphp5.so...done. Loaded symbols for /usr/local/apache/modules/libphp5.so Reading symbols from /usr/local/mysql/lib/mysql/libmysqlclient.so.15...done. Loaded symbols for /usr/local/mysql/lib/mysql/libmysqlclient.so.15 Reading symbols from /usr/lib/libpng12.so.0...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libcurl.so.3...done. Loaded symbols for /usr/lib/libcurl.so.3 Reading symbols from /usr/lib/libidn.so.11...done. Loaded symbols for /usr/lib/libidn.so.11 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/local/apache/modules/mod_expires.so...done. Loaded symbols for /usr/local/apache/modules/mod_expires.so Reading symbols from /usr/local/apache/modules/mod_headers.so...done. Loaded symbols for /usr/local/apache/modules/mod_headers.so Reading symbols from /usr/local/apache/modules/mod_rpaf-2.
