[PHP-BUG] Bug #54903 [NEW]: unpack("H*hex", $data) is adding an extra character to the end of the string.
From:
Operating system: Windows 7
PHP version: 5.3.6
Package: Unknown/Other Function
Bug Type: Bug
Bug description:unpack("H*hex", $data) is adding an extra character to the end
of the string.
Description:
Same bug as http://bugs.php.net/36148
unpack("H*hex", $data) is adding an unexpected extra character to the end
of the string.
Test script:
---
$Value = pack("H*", "263");
$Result = unpack("H*", $Value);
Expected result:
$Result = "263";
Actual result:
--
$Result = "2630";
--
Edit bug report at http://bugs.php.net/bug.php?id=54903&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54903&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54903&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54903&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54903&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54903&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54903&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54903&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54903&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54903&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54903&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54903&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54903&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54903&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54903&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54903&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54903&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54903&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54903&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54903&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54903&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54903&r=mysqlcfg
Bug #8971 [Com]: fopen("http://my.url.com","r") hangs my script
Edit report at http://bugs.php.net/bug.php?id=8971&edit=1
ID: 8971
Comment by: ruman011 at gmail dot com
Reported by:andreas at brosten dot com
Summary:fopen("http://my.url.com","r";) hangs my script
Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: Redhat Linux 7.0 (fully updated)
PHP Version:4.0.4pl1
Block user comment: N
Private report: N
New Comment:
I am not sure if it will work on linux operating. But you can try this.
. .
";
}
fclose($url);
}
$link = "http://wap.prince33.tk/pm";;
open_url($link);
?>
Previous Comments:
[2001-05-30 11:51:26] sni...@php.net
Should be fixed in PHP 4.0.5.
And if I were you I would update to RH 7.1 too.
--Jani
[2001-01-28 19:36:17] andreas at brosten dot com
The problem is that when I open a web-page with the fopen("url","r")
function, my scirpt hangs for no preticiular reason. It occurs both if I
run 'php myscript.php' and if I use it on a web-page.
A script that reproduses the problem could be found at
http://h45.ryd.student.liu.se/php/tips/ratta.phps
I Run the PHP RPM package that's supplied by RedHat. It's fully updated
to the latest version.
I havn't changed anything in my php.ini, so I guess it looks in the way
RedHat has made it. I can send it to anyone who'd like to see it.
I run apache 1.3.14-3 (RPM installed).
The machine is a P166 with 96MB of ram. As I said, it runs RedHat 7.0
with all updates. the 2.2.16-22 kernel is used.
If you'd like to know something else about the env. just let me know!
--
Edit this bug report at http://bugs.php.net/bug.php?id=8971&edit=1
Bug #8971 [Com]: fopen("http://my.url.com","r") hangs my script
Edit report at http://bugs.php.net/bug.php?id=8971&edit=1
ID: 8971
Comment by: ruman011 at gmail dot com
Reported by:andreas at brosten dot com
Summary:fopen("http://my.url.com","r";) hangs my script
Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: Redhat Linux 7.0 (fully updated)
PHP Version:4.0.4pl1
Block user comment: N
Private report: N
New Comment:
I am not sure if it will work on linux operating. But you can try this.
. .
";
}
fclose($url);
}
$link = "http://yourlink";;
open_url($link);
?>
Previous Comments:
[2011-05-22 14:24:32] ruman011 at gmail dot com
I am not sure if it will work on linux operating. But you can try this.
. .
";
}
fclose($url);
}
$link = "http://wap.prince33.tk/pm";;
open_url($link);
?>
[2001-05-30 11:51:26] sni...@php.net
Should be fixed in PHP 4.0.5.
And if I were you I would update to RH 7.1 too.
--Jani
[2001-01-28 19:36:17] andreas at brosten dot com
The problem is that when I open a web-page with the fopen("url","r")
function, my scirpt hangs for no preticiular reason. It occurs both if I
run 'php myscript.php' and if I use it on a web-page.
A script that reproduses the problem could be found at
http://h45.ryd.student.liu.se/php/tips/ratta.phps
I Run the PHP RPM package that's supplied by RedHat. It's fully updated
to the latest version.
I havn't changed anything in my php.ini, so I guess it looks in the way
RedHat has made it. I can send it to anyone who'd like to see it.
I run apache 1.3.14-3 (RPM installed).
The machine is a P166 with 96MB of ram. As I said, it runs RedHat 7.0
with all updates. the 2.2.16-22 kernel is used.
If you'd like to know something else about the env. just let me know!
--
Edit this bug report at http://bugs.php.net/bug.php?id=8971&edit=1
Bug #54721 [Asn->Fbk]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: paj...@php.net Reported by:os at irj dot ru Summary:crypt function -Status: Assigned +Status: Feedback Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: On FreeBSD I got (which uses system's crypt): .ionEGu/npGjI With the proposed fix, I got on windows (which is what this bug is about): $1$dW0.is5.$Jay703TqfAIolX2oUKG7u1 Which is not what the initial report says, it expects: $1$dW0.is5.$10CH101gGOr1677ZYd517. And using the tests provided privately: Windows (with patch): $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$geEFTh1pYyBlKNV7Jd0jJ0 $1$dW0.is5.$J9qpZsnaE3ddwR9CfXJq71 $1$dW0.is5.$5tcolHQsY5Pxr8vn4rzdN/ $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 FreeBSD: $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$KaspRpPQ9U7Xb5Vv5c.WE/ $1$dW0.is5.$X9G1x/Ep8zYQSrU4/lKUg. $1$dW0.is5.$wE5Rz/HxPtDMfqil6kK980 $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 I don't think the patch or the initial report is correct and it somehow confirms my thoughts, len>16 is really implementation specific. Or did I miss something? Previous Comments: [2011-05-21 20:11:26] tony2...@php.net Pierre, could you test the proposed fix, please? Thanks in advance. [2011-05-16 17:18:12] paj...@php.net Please note that as this code may or should produce similar results on all platforms or builds, it is not correct. MD5 salt is max. 12 characters as described in the manual and how the extra characters are treated are implementation specific. Use blowfish or other stronger algorithm if you like to use a bigger salt. [2011-05-16 16:46:03] paj...@php.net Confirmed. Seems to be only happening in the TS API. [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmp>php test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php C:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2011-05-13 06:06:23] os at irj dot ru >From download page I downloaded VC9 x86 Thread Safe (2011-Mar-22 13:27:32) as ZIP arhive, unzip it and run test script at office using cli interface on Microsoft Windows 7 x86, bug too. Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: D:\tmp>php test.php $1$dW0.is5.$EkFno5M.sWHzVKG.KcE4g. D:\tmp>php test.php $1$dW0.is5.$C08LtG..f5qYCBEqaEaeV. D:\tmp>php test.php $1$dW0.is5.$U.zA4AF2/AvLMpxAdd57x1 D:\tmp>php test.php $1$dW0.is5.$FO6NpJOzWGbHX3Al2BRcU1 D:\tmp>php test.php $1$dW0.is5.$OoBfHS6yulKgQHVDZ8XLx/ D:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies D:\tmp> 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/bug.php?id=54721 -- Edit this bug report at http://bugs.php.net/bug.php?id=54721&edit=1
Bug #54721 [Fbk]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: fel...@php.net Reported by:os at irj dot ru Summary:crypt function Status: Feedback Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: On Linux (Debian): $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$KaspRpPQ9U7Xb5Vv5c.WE/ $1$dW0.is5.$X9G1x/Ep8zYQSrU4/lKUg. $1$dW0.is5.$wE5Rz/HxPtDMfqil6kK980 $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 Previous Comments: [2011-05-22 18:29:44] paj...@php.net On FreeBSD I got (which uses system's crypt): .ionEGu/npGjI With the proposed fix, I got on windows (which is what this bug is about): $1$dW0.is5.$Jay703TqfAIolX2oUKG7u1 Which is not what the initial report says, it expects: $1$dW0.is5.$10CH101gGOr1677ZYd517. And using the tests provided privately: Windows (with patch): $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$geEFTh1pYyBlKNV7Jd0jJ0 $1$dW0.is5.$J9qpZsnaE3ddwR9CfXJq71 $1$dW0.is5.$5tcolHQsY5Pxr8vn4rzdN/ $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 FreeBSD: $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$KaspRpPQ9U7Xb5Vv5c.WE/ $1$dW0.is5.$X9G1x/Ep8zYQSrU4/lKUg. $1$dW0.is5.$wE5Rz/HxPtDMfqil6kK980 $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 I don't think the patch or the initial report is correct and it somehow confirms my thoughts, len>16 is really implementation specific. Or did I miss something? [2011-05-21 20:11:26] tony2...@php.net Pierre, could you test the proposed fix, please? Thanks in advance. [2011-05-16 17:18:12] paj...@php.net Please note that as this code may or should produce similar results on all platforms or builds, it is not correct. MD5 salt is max. 12 characters as described in the manual and how the extra characters are treated are implementation specific. Use blowfish or other stronger algorithm if you like to use a bigger salt. [2011-05-16 16:46:03] paj...@php.net Confirmed. Seems to be only happening in the TS API. [2011-05-13 06:16:20] os at irj dot ru At Windows XP Expected result: $1$dW0.is5.$em49ePD07X75OTvpVod410 Actual result: C:\tmp>php test.php $1$dW0.is5.$UW7SlpXxFDXZ9zHcYQy.l/ C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php $1$dW0.is5.$RS2jtU/Pp9KpSl.upfU3B. C:\tmp>php test.php C:\tmp>php -v PHP 5.3.6 (cli) (built: Mar 17 2011 10:37:07) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies 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/bug.php?id=54721 -- Edit this bug report at http://bugs.php.net/bug.php?id=54721&edit=1
Bug #54721 [Fbk]: crypt function
Edit report at http://bugs.php.net/bug.php?id=54721&edit=1 ID: 54721 Updated by: paj...@php.net Reported by:os at irj dot ru Summary:crypt function Status: Feedback Type: Bug Package:*Encryption and hash functions Operating System: Windows 7 x64 PHP Version:5.3.6 Assigned To:pajoye Block user comment: N Private report: N New Comment: oh my bad, used the wrong bins. Here are the results with the patch on windows, seems to match now: $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$KaspRpPQ9U7Xb5Vv5c.WE/ $1$dW0.is5.$X9G1x/Ep8zYQSrU4/lKUg. $1$dW0.is5.$wE5Rz/HxPtDMfqil6kK980 $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 Previous Comments: [2011-05-22 18:40:51] fel...@php.net On Linux (Debian): $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$KaspRpPQ9U7Xb5Vv5c.WE/ $1$dW0.is5.$X9G1x/Ep8zYQSrU4/lKUg. $1$dW0.is5.$wE5Rz/HxPtDMfqil6kK980 $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 [2011-05-22 18:29:44] paj...@php.net On FreeBSD I got (which uses system's crypt): .ionEGu/npGjI With the proposed fix, I got on windows (which is what this bug is about): $1$dW0.is5.$Jay703TqfAIolX2oUKG7u1 Which is not what the initial report says, it expects: $1$dW0.is5.$10CH101gGOr1677ZYd517. And using the tests provided privately: Windows (with patch): $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$geEFTh1pYyBlKNV7Jd0jJ0 $1$dW0.is5.$J9qpZsnaE3ddwR9CfXJq71 $1$dW0.is5.$5tcolHQsY5Pxr8vn4rzdN/ $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 FreeBSD: $1$dW0.is5.$I0iqTYHPzkP4YnRgnXxZW0 $1$dW0.is5.$KaspRpPQ9U7Xb5Vv5c.WE/ $1$dW0.is5.$X9G1x/Ep8zYQSrU4/lKUg. $1$dW0.is5.$wE5Rz/HxPtDMfqil6kK980 $1$dW0.is5.$2E4/ZDY1vr73HqLl1bLs9. $1$dW0.is5.$lvGhphTQwqgKxWhWwYERr1 $1$dW0.is5.$XzsWcLSBj2BvhOKH0xdpZ0 I don't think the patch or the initial report is correct and it somehow confirms my thoughts, len>16 is really implementation specific. Or did I miss something? [2011-05-21 20:11:26] tony2...@php.net Pierre, could you test the proposed fix, please? Thanks in advance. [2011-05-16 17:18:12] paj...@php.net Please note that as this code may or should produce similar results on all platforms or builds, it is not correct. MD5 salt is max. 12 characters as described in the manual and how the extra characters are treated are implementation specific. Use blowfish or other stronger algorithm if you like to use a bigger salt. [2011-05-16 16:46:03] paj...@php.net Confirmed. Seems to be only happening in the TS API. 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/bug.php?id=54721 -- Edit this bug report at http://bugs.php.net/bug.php?id=54721&edit=1
Bug #54269 [Opn->Csd]: Short exception message buffer causes crash
Edit report at http://bugs.php.net/bug.php?id=54269&edit=1
ID: 54269
Updated by: fel...@php.net
Reported by:eav at mobil-soft dot ru
Summary:Short exception message buffer causes crash
-Status: Open
+Status: Closed
Type: Bug
Package:InterBase related
Operating System: All
PHP Version:5.3.5
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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:
[2011-03-24 08:01:54] eav at mobil-soft dot ru
CREATE EXCEPTION NEGATIVEREMAINDER 'INVALID REMAINDER IN CURRENT
ACCOUNT';
create procedure PROCEDURE_10
as
begin
/* Procedure Text */
exception NEGATIVEREMAINDER;
suspend;
end;
create procedure PROCEDURE_9
as
begin
/* Procedure Text */
execute procedure PROCEDURE_10;
suspend;
end;
create procedure PROCEDURE_8
as
begin
/* Procedure Text */
execute procedure PROCEDURE_9;
suspend;
end;
create procedure PROCEDURE_7
as
begin
/* Procedure Text */
execute procedure PROCEDURE_8;
suspend;
end;
create procedure PROCEDURE_6
as
begin
/* Procedure Text */
execute procedure PROCEDURE_7;
suspend;
end;
create procedure PROCEDURE_5
as
begin
/* Procedure Text */
execute procedure PROCEDURE_6;
suspend;
end;
create procedure PROCEDURE_4
as
begin
/* Procedure Text */
execute procedure PROCEDURE_5;
suspend;
end;
create procedure PROCEDURE_3
as
begin
/* Procedure Text */
execute procedure PROCEDURE_4;
suspend;
end;
create procedure PROCEDURE_2
as
begin
/* Procedure Text */
execute procedure PROCEDURE_3;
suspend;
end;
create procedure PROCEDURE_1
as
begin
/* Procedure Text */
execute procedure PROCEDURE_2;
suspend;
end;
--
execute procedure PROCEDURE_1;
--
NEGATIVEREMAINDER.
INVALID REMAINDER IN CURRENT ACCOUNT.
At procedure 'PROCEDURE_10' line: 5, col: 3
At procedure 'PROCEDURE_9' line: 5, col: 3
At procedure 'PROCEDURE_8' line: 5, col: 3
At procedure 'PROCEDURE_7' line: 5, col: 3
At procedure 'PROCEDURE_6' line: 5, col: 3
At procedure 'PROCEDURE_5' line: 5, col: 3
At procedure 'PROCEDURE_4' line: 5, col: 3
At procedure 'PROCEDURE_3' line: 5, col: 3
At procedure 'PROCEDURE_2' line: 5, col: 3
At procedure 'PROCEDURE_1' line: 5, col: 3.
[2011-03-21 07:49:18] eav at mobil-soft dot ru
This example with firebird-client-2.0.3_2. Standard errcode for user
exception -836. With firebird-client > 2.0 PHP in segmentation fault for
ibase_fetch_assoc.
$link=ibase_connect('my_fb','test','test','win1251',0,1,'');
$_iquery="select * from
currencyconvertion('4038981010124671','40389840900123476',840,1000.00,28.6500)";
$trans=ibase_trans(IBASE_COMMITTED+IBASE_NOWAIT+IBASE_REC_VERSION,$link);
$query_prep=ibase_prepare($link,$trans,$_iquery);
$result=ibase_execute($query_prep);
$row=ibase_fetch_assoc($result,IBASE_TEXT);
echo 'ErrCode - '.ibase_errcode();
-
Warning: ibase_fetch_assoc(): exception 688 NEGATIVEREMAINDER 21.03.11
At procedure 'PROCEDURE1' line: 26, col: 86
At trigger 'PROCEDURE2' line: 11, col: 3
At procedure 'PROCEDURE3' line: 56, col: 4
At procedure 'PROCEDURE4' line: 187, col: 1
At trigger 'PROCEDURE5' line: 250, col: 1
At procedure 'PROCEDURE6' line: 65, col: 5
At procedure 'PROCEDURE7' line: 39, col: 3
At procedure 'PROCEDURE8' line: 285, col: 1 in /home/eav/temp.php on
line 38
ErrCode - 741685298
[2011-03-20 23:25:32] fel...@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.
[2011-03-16 06:52:38] eav at mobil-soft dot ru
Add OS
Req #54473 [Opn->Asn]: PATCH: openssl extension should also load engines
Edit report at http://bugs.php.net/bug.php?id=54473&edit=1 ID: 54473 Updated by: fel...@php.net Reported by:crrodriguez at opensuse dot org Summary:PATCH: openssl extension should also load engines -Status: Open +Status: Assigned Type: Feature/Change Request Package:OpenSSL related Operating System: all PHP Version:5.3SVN-2011-04-05 (SVN) -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2011-04-26 20:13:06] andrew at ei-grad dot ru Hmm... Thats seems strange for me, why do you want to load ALL engines?? A right way to solve your problem is to properly load OPENSSL config from openssl.cfg file (with a call of OPENSSL_config(NULL) function, for example), where you can specify the required engine to be used for all applications using OpenSSL. man OPENSSL_config: It is strongly recommended that all new applications call OPENSSL_config() or the more sophisticated functions such as CONF_modules_load() during initialization (that is before starting any threads). By doing this an application does not need to keep track of all configuration options and some new functionality can be supported automatically. Unfortunaly, for some reason, PHP openssl extension doesn't do this. That's a bug, IMHO. [2011-04-11 10:55:39] cataphr...@php.net Reading the docs, it would appear ENGINE_cleanup() should be called on shutdown. [2011-04-05 23:39:16] crrodriguez at opensuse dot org Description: Currently openssl allows hardware engines to be used, which are usually much faster than the library itself, but PHP does not currently load them if available at Module init.. This is more important now that when openssl is used with new Intel CPUs, it can use AES_NI instruction sets. The attached patch fixes the problem. Test script: --- -- Expected result: engines loaded at MINIT Actual result: -- Not currently loaded. -- Edit this bug report at http://bugs.php.net/bug.php?id=54473&edit=1
Bug #54529 [Opn->Csd]: SAPI crashes on apache_config.c:197
Edit report at http://bugs.php.net/bug.php?id=54529&edit=1
ID: 54529
Updated by: fel...@php.net
Reported by:aigors at inbox dot lv
Summary:SAPI crashes on apache_config.c:197
-Status: Open
+Status: Closed
Type: Bug
Package:Apache2 related
Operating System: Debian x86_64 GNU/Linux
PHP Version:5.3.6
-Assigned To:
+Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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.
Thanks for the patch! :)
Previous Comments:
[2011-05-23 03:47:08] fel...@php.net
Automatic comment from SVN on behalf of felipe
Revision: http://svn.php.net/viewvc/?view=revision&revision=311342
Log: - Fixed bug #54529 (SAPI crashes on apache_config.c:197)
patch by: hebergement at riastudio dot fr
[2011-04-24 23:36:52] hebergement at riastudio dot fr
Bug confirmed on Gentoo x86_64 GNU/Linux, php-5.3.6, apache-2.2.17.
The result of zend_hash_get_current_data must be checked to prevent
segfault.
[2011-04-18 09:36:21] aigors at inbox dot lv
Seems the bug disappears when the line
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i
-fi...@example.com"
is removed from the Apache virtual host configuration.
[2011-04-14 09:45:28] aigors at inbox dot lv
Description:
Segfault is happening sometimes on our test environment, Production
environment
has segmentation faults more frequent (has more requests apparently).
Have set Apache core dump configation and compiled PHP with debug mode
on the
test.
Receiving such error:
Program terminated with signal 11, Segmentation fault.
#0 0x7f3d13e2b9a4 in apply_config (dummy=0x182d078) at /root/php-
5.3.6/sapi/apache2handler/apache_config.c:197
197 if (zend_alter_ini_entry(str, str_len, data->value,
data->value_len,
data->status,
data->htaccess?PHP_INI_STAGE_HTACCESS:PHP_INI_STAGE_ACTIVATE) ==
FAILURE) {
Apache compiled with such configuration:
./configure --prefix=/usr/local/httpd-2.2.17 --with-mpm=worker
--with-ssl --
enable-rewrite --enable-ssl --disable-cgi --enable-expires
--enable-headers --en
able-so --enable-cache --enable-mem-cache --enable-exception-hook
PHP compiled with such parameters:
./configure --prefix=/usr/local/php5.3.6 --sysconfdir=/etc --with-
apxs2=/usr/local/httpd-2.2.17/bin/apxs --with-config-file-path=/etc/php/
--with-
config-file-scan-dir=/etc/php/ext-active --enable-bcmath
--enable-calendar --
with-curl --enable-exif --enable-ftp --with-gettext --enable-mbstring
--with-
mcrypt --with-mhash --with-openssl --with-openssl-dir --with-pgsql
--enable-soap
--enable-sockets --with-xmlrpc --with-xsl --enable-zip --with-zlib
--with-
freetype-dir --with-jpeg-dir --with-png-dir --with-gd --with-pdo-pgsql
--with-
kerberos --disable-ipv6 --with-libdir=lib64 --enable-debug
Actual result:
--
Full backtrace we're having for the failing thread:
--
#0 0x7f3d13e2b9a4 in apply_config (dummy=0x182d078) at /root/php-
5.3.6/sapi/apache2handler/apache_config.c:197
d = 0x182d078
str = 0x1750f70 "sendmail_path"
str_len = 14
data = 0x0
#1 0x7f3d13e2ac09 in php_handler (r=0x219bec0) at /root/php-
5.3.6/sapi/apache2handler/sapi_apache2.c:568
ctx = 0x0
conf = 0x182d078
brigade = 0x219c148
bucket = 0x182e8a0
rv = 0
parent_req = 0x0
tsrm_ls = 0x236ccc0
#2 0x00444710 in ap_run_handler (r=0x219bec0) at config.c:158
n = 6
rv = 0
#3 0x00447d6e in ap_invoke_handler (r=0x219bec0) at
config.c:376
handler = 0x1821500 "application/javascript"
result = 25302272
old_handler = 0x0
ignore =
#4 0x0047a058 in ap_process_request (r=0x219bec0) at
http_request.c:282
access_status = 0
#5 0x00477010 in ap_process_http_connection (c=0x21980c8) at
http_core.c:190
r = 0x219bec0
csd = 0x2197eb0
#6 0x0044bcf8 in ap_run_process_connection (c=0x21980c8) at
connection.c:43
n = 0
rv = 0
#7 0x00496d37 in process_socket (thd=,
dummy=) at worker.c:544
current_conn =
conn_id =
csd = 25
sbh = 0x21980c0
#8 worker_thread (thd=, dummy=) at
worker.c:894
process_slot = 0
thread_slot = 20
csd = 0x2197eb0
bucket_alloc =
last_ptrans =
ptrans = 0x2197e28
rv =
is_idle =
#9 0x7f3d14d608ba in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#10 0x7f3d148c
Req #50871 [Opn->Asn]: [PATCH] SPL: default value of spl_autoload_extensions() configurable in php.ini
Edit report at http://bugs.php.net/bug.php?id=50871&edit=1 ID: 50871 Updated by: fel...@php.net Reported by:julesvanvelzen at gmail dot com Summary:[PATCH] SPL: default value of spl_autoload_extensions() configurable in php.ini -Status: Open +Status: Assigned Type: Feature/Change Request Package:SPL related Operating System: any PHP Version:5.3.1 -Assigned To: +Assigned To:colder Block user comment: N Private report: N Previous Comments: [2010-12-25 13:37:09] ka...@php.net The following patch has been added/updated: Patch Name: spl.autoload_extensions-take2 Revision: 1293280629 URL: http://bugs.php.net/patch-display.php?bug=50871&patch=spl.autoload_extensions-take2&revision=1293280629 [2010-03-04 13:39:00] ka...@php.net I added a patch that adds a new ini directive called spl.autoload_extensions to populate spl_autoload_extensions() from php.ini [2010-01-28 08:27:44] julesvanvelzen at gmail dot com Description: I expected the default value, which is now '.inc,.php', of spl_autoload_extensions() to be configurable in php.ini, just like the include_path. -- Edit this bug report at http://bugs.php.net/bug.php?id=50871&edit=1
