#42881 [NEW]: PDO::FETCH_CLASS incorrectly returns PDO::FETCH_BOTH
From: voidalan at koitech dot net Operating system: CentOS 5 PHP version: 5.2.4 PHP Bug Type: PDO related Bug description: PDO::FETCH_CLASS incorrectly returns PDO::FETCH_BOTH Description: When using PDO::FETCH_CLASS it incorrectly returns PDO::FETCH_BOTH. In other words instead of returning objects it is returning a mixed array. The below code worked in 5.2.3 but when upgrading to 5.2.4 this occured. Reproduce code: --- http://pastemonkey.org/paste/470883a5-8d1c-4256-a59d-27b2404fdb0d Expected result: Array( [0] = Object( id = hidden = featured = title = clientName = teaser = content = imgUrl = publishedBy = dateCreated = dateModified = ) ... ) Actual result: -- Array ( [0] = Array ( [id] = [0] = [hidden] = [1] = [featured] = [2] = [title] = [3] = [clientName] = [4] = [teaser] = [5] = [content] = [6] = [imgUrl] = [7] = [publishedBy] = [8] = [dateCreated] = [9] = [dateModified] = [10] = ) ... ) -- Edit bug report at http://bugs.php.net/?id=42881edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42881r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42881r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42881r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42881r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42881r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42881r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42881r=needscript Try newer version:http://bugs.php.net/fix.php?id=42881r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42881r=support Expected behavior:http://bugs.php.net/fix.php?id=42881r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42881r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42881r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42881r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42881r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42881r=dst IIS Stability:http://bugs.php.net/fix.php?id=42881r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42881r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42881r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42881r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42881r=mysqlcfg
#38915 [Com]: Apache: system() (and similar) don't cleanup opened handles of Apache
ID: 38915 Comment by: Cruz at guerillamail dot com Reported By: dimmoborgir at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: UNIX PHP Version: 5.2.2, 4.4.7 New Comment: Ran into the same problem. I'm appalled that a bug this big isn't fixed more than a year after it was reported. Previous Comments: [2007-07-29 10:48:18] antoine dot bajolet at tdf dot fr Hello, I agree with all contributors : It's a bunch of pain we can't launch a clean process from a PHP web interface. Without any technical consideration, functionally it's a real need to numerous PHP users, and for a long time seeing those bug reports : http://bugs.php.net/bug.php?id=15529 http://bugs.php.net/bug.php?id=15642 http://bugs.php.net/bug.php?id=16548 The only workaround whe found to obtain the result is : - Writing something to a file to tell hey, there is a process to launch or stop - Using a cron'ed script to read the file and launch/stop the process if it tells it. And this poor tip is far far from satisfying us. The last response given in 2003 was Given the nature of PHP's execution architecture this is not possible/practical to implement. But if the Apache API offers a apr_proc_create() function, why not using it in mod_php ? There are some other differences between mod_php and php-cli. Regards, Antoine [2007-03-05 21:11:51] oliver at realtsp dot com apart from the security considerations mentioned above the fact that mod_php doesn't free the FDs when forking prevents us from forking cleanly. ie we cannot from a web request to mod_php fork a cli process cleanly because it will inherit all the open FDs (ie typically port 80 443) even if you use setsid() (or daemon on FreeBSD) etc.. you can see this when you... fork stop apache netstat -an | grep LISTEN your cli process will be LISTENING to port 80 443. this is not only a security risk, but it will prevent apache for restarting: (48)Address already in use: make_sock: could not bind to address [::]:443 no listening sockets available, shutting down I have not found any way to close these sockets as they should be because the resource handles are not available in php. If you could at least make these available then we could at least ensure we close them manually. Regards Oliver [2007-01-04 19:25:26] anomie at users dot sf dot net On 20 Oct 2006 9:48am UTC, [EMAIL PROTECTED] wrote: The opened file descriptors are opened by Apache. It is the job of Apache to protect them, not something that should be reinvented in all apache modules. If that's your position, then as far as I can tell mod_php should be calling apr_proc_create() instead of system()/popen()/etc and apr_pool_cleanup_for_exec() before exec(). Apache adds (or should be adding) all the FDs that should be closed on exec to a list that those functions make use of. If you don't like that, then either explain (in as much detail as is required) why that isn't Apache's method of protecting the FDs, find a non-bogus reason for claiming this issue is not a mod_php bug, or just fix the bug already. Apache should just use FD_CLOEXEC isn't a non-bogus reason, BTW, although convincing Apache to do so and making sure FD_CLOEXEC is supported on all platforms mod_php can possibly be used on might be an acceptable bugfix. I've also seen the MTA ends up listening on port 80 issue after using the php mail functions. [2006-11-23 15:36:55] php at vanviegen dot net It seems that the mail() function is suffering from the same problem. It is rather scary to see Apache failing to restart, because the MTA (exim in our case) is already listening on port *:80 ! More details: http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20030407/msg00049.html [2006-10-30 16:55:36] jlawson-php at bovine dot net It should be PHP's responsibility to close all open file handles (after forking but before the exec). Keep in mind that PHP is running as a module within the same process space as Apache, and those private FDs are required for it to operate. Apache cannot reasonably close and re-open all of those whenever it is invoking a module's handlers, nor can it reasonably run modules in a separate process. Modules are intended to be trusted code and so Apache does not attempt to protect itself from misdesigned modules. (In the case where PHP is installed as a CGI and not a module, then Apache does indeed close the private FDs prior to running PHP.) For example, when a CGI process via Apache's mod_cgi, that module is responsible for ensuring that it explicitly closes all
#42645 [Com]: getdate/mktime does not always add/subtract dst offset
ID: 42645
Comment by: fkl at tfu dot jgfi
Reported By: carstenklein at yahoo dot de
Status: Assigned
Bug Type: Date/time related
Operating System: Linux Ubuntu Feisty Fawn
PHP Version: 5.2.4
Assigned To: derick
New Comment:
http://www.meta-fx.com
http://www.forex.co.ir
forexÝÇÑÓ
Previous Comments:
[2007-09-13 08:09:47] [EMAIL PROTECTED]
Assigned to the ext/date maintainer. :)
[2007-09-12 18:04:30] carstenklein at yahoo dot de
Small err on my behalf, where it reads:
result often are non reproducible and may seem quite random
it must read:
result are reproducible but may seem quite random
and
Therefore I urge you to at least provide a timezone offset less
version of mktime in order to at least get some reproducible results.
it should read
Therefore I urge you to at least provide a timezone offset less
version of mktime and let the user do the rest.
A provable solution would be to take the seventh, now deprecated
parameter to mktime and make it a flag indicating wether or not offsets
will be applied to the resulting date/time.
[2007-09-12 16:06:37] carstenklein at yahoo dot de
Description:
getdate() a/o mktime() do not always add/subtract the currently valid
dst offset. Actually, they do only add the dst offset under certain
conditions, but not always and not to all possible normal time/summer
time, summer time/normal time transitions.
see below code for an example on how to reprocude the erroneous
behaviour. the lines being marked with good/failure represent the
lines where the dst offset has been added. As you can see, it happens
not for all possible dates since 1970-1-1, at least in the local
configuration being set to CET/CEST.
BTW: opposed to what is expected, CEST to CET transitions do not seem
to work at all, I was unable to setup a scenario where the dst offset
would have been subtracted from the resulting timestamp. It seems as if
the mktime() or timelib functions do not take dst into account when
transitioning a date from summer time to normal time.
I would therefore like mktime and the timelib to no longer try to guess
the actual current time and automatically add the required dst offsets
to either date and time as it is prone to error as one can clearly see
in the below example outputs of below program fragment. Additionally,
the results often are non reproducible and may seem quite random. If you
don't believe, go and try for yourself, change the number of days to be
added to the start date from 20 to for example 10 or other reasonable
values. Furthermore, try to play with the starting date, make it some
date in February instead of for example March, but make sure that you
transition the date beyond the last Sunday in March, 1:00am. As you can
see, the results will vary greatly.
Of course one could always double check the results returned by mktime,
however, this is a lot of special casing etc. Therefore I urge you to at
least provide a timezone offset less version of mktime in order to at
least get some reproducible results.
And, using the seventh optional parameter to mktime() makes no
difference at all, besides that, it is considered deprecated.
similar bug reports, all having been closed so far:
http://bugs.php.net/bug.php?id=245
http://bugs.php.net/bug.php?id=741
Reproduce code:
---
?php
function addDuration( $date, $durationArray ) {
$t = getdate( $date ); $t[ year ] += $durationArray[ years
]; $t[ mon ] += $durationArray[ months ]; $t[ mday ] +=
$durationArray[ days ];
$t[ hours ] += $durationArray[ hours ]; $t[ minutes ] +=
$durationArray[ minutes ]; $t[ seconds ] += $durationArray[
seconds ];
return mktime( $t[ hours ], $t[ minutes ], $t[ seconds ],
$t[ mon ], $t[ mday ], $t[ year ] );
}
function durationToString( $durationArray ) {
return P . $durationArray[ years ] . Y . $durationArray[
months ] . M . $durationArray[ days ] . D . T .
$durationArray[ hours ] . : . $durationArray[ minutes ] . : .
$durationArray[ seconds ];
}
echo Testing Normal Time to DST Transition:\n;
for( $y = 1902; $y 2038; $y++ ) {
for( $x = 14; $x 32; $x++ ) {
$d = strtotime( $y-03-$x 02:30:30 ); echo ( date(
Y-m-d H:i:s, $d ) ) . \t;
$durationArray = array( years = 0, months = 0,
days = 20, hours = 0, minutes = 0, seconds = 0 ); echo +\t
. durationToString( $durationArray ) . \t+\t;
$t = addDuration( $d, $durationArray ); $td = getdate(
$t ); echo date( Y-m-d H:i:s, $t ) . ( $td[ hours ] == 3 ? -
FAILURE : ) . \n;
} }
echo Testing DST to Normal Time Transition:\n;
for( $y = 2037; $y 1901; $y-- ) {
for( $x = 24; $x 32; $x++ ) {
$d = strtotime( $y-10-$x
#39016 [Asn-Fbk]: Segfault in preg_replace_impl
ID: 39016 Updated by: [EMAIL PROTECTED] Reported By: jan at horde dot org -Status: Assigned +Status: Feedback Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.0RC4 Assigned To: andrei New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If 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. your reproducing script isn't complete (I can't run it..) Previous Comments: [2006-10-02 15:58:10] [EMAIL PROTECTED] Andrei, please take a look at this. Looks like yet another stack overflow in PCRE.. [2006-10-02 15:51:41] jan at horde dot org (gdb) p subject $1 = (zval **) 0xb6f019e0 (gdb) p **subject Cannot access memory at address 0x1 (gdb) p string_key $2 = 0x10 Address 0x10 out of bounds (gdb) p num_key $3 = 1 [2006-10-02 15:48:34] [EMAIL PROTECTED] What do you get in GDB with p subject p **subject p string_key p num_key ? [2006-10-02 15:41:08] jan at horde dot org I didn't try a snapshot since this happens with PHP 4, so I guess it's an older issue that simply hasn't been triggered yet. Here's the valgrind log: ==32185== Address 0xBE32 is on thread 1's stack ==32185== ==32185== Invalid read of size 4 ==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307) ==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==32185== ==32185== Process terminating with default action of signal 11 (SIGSEGV) ==32185== Access not within mapped region at address 0x1 ==32185==at 0x449FCA7: preg_replace_impl (php_pcre.c:1307) ==32185==by 0x4767B6B: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==32185==by 0x475AFBC: execute (zend_vm_execute.h:92) ==32185==by 0x47675EA: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) [2006-10-02 15:36:50] jan at horde dot org I should add the lines of code that caused this, right? :) $regexp = EOR / # Version 1: mailto: links with any valid email characters. # Pattern 1: Outlook parenthesizes in sqare brackets (\[\s*)? # Pattern 2: mailto: protocol prefix (mailto:\s?) # Pattern 3: email address ([^\s\?]*) # Pattern 4 to 6: Optional parameters ((\?)([^\s]*[\w+#?\/=]))? # Pattern 7: Closing Outlook square bracket ((?(1)\s*\])) | # Version 2 Pattern 8: simple email addresses. ([EMAIL PROTECTED]) # Pattern 9 to 11: Optional parameters ((\?)([^\s]*[\w+#?\/=]))? /eix EOR; preg_replace($regexp, 'Text_Filter_emails::callback(\'' . $tag . '\', \'' . $class . '\', \'$1\', \'$2\', \'$3\', \'$4\', \'$6\', \'$7\', \'$8\', \'$9\', \'$11\')', 'a long list of email addresses etc.') The regexp part that causes the problem, i.e. that no longer segfaults if removed is the pattern #8. The
#42882 [NEW]: strip_tags() interprets ' and = as tags
From: pub1 at hverdag dot dk Operating system: WinXP Pro PHP version: 5CVS-2007-10-07 (snap) PHP Bug Type: Strings related Bug description: strip_tags() interprets ' and = as tags Description: Description: strip_tags() removes too much information, it incorrectly interprets ' and = as tags. In version 5.1.6 strip_tags($string, '=) (as mentioned in reproducing code) would solve the problem, but in the 5.2.5-dev snapshot it does not and it even cuts out even more text. Reproduce code: --- ?php $string = EOD Message: Database query for getting dateblock titles failed. MySQL error: 'opening_date = '2007-01-01' AND closing_date ' at line 1 SQL: SELECT title FROM dateblocks WHERE opening_date = '2007-01-01' AND closing_date = '2007-12-31' Level 1 file: C:\Inetpub\wwwroot\includes\ini_functions_dateblock.php / line b563/b Level 2 file: C:\Inetpub\wwwroot\includes\ini_functions_dateblock.php / line b750/b / set_dateblock(bfont color=brown'add'/font/b, array( 'opening_date' = '10/19/2007', 'closing_date' = '11/3/2007', 'title' = 'flajdsflkj', )) EOD; echo strip_tags($string); //this does it INCORRECTLY #echo strip_tags($string, '=); //this one does it CORRECTLY in 5.1.6 (but not newest snapshot) ? Expected result: Only the b and font tags should be removed. Actual result: -- Everything after the first closing_date is cut off! In 5.1.6 some of the remaining text was not cut off. -- Edit bug report at http://bugs.php.net/?id=42882edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42882r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42882r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42882r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42882r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42882r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42882r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42882r=needscript Try newer version:http://bugs.php.net/fix.php?id=42882r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42882r=support Expected behavior:http://bugs.php.net/fix.php?id=42882r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42882r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42882r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42882r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42882r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42882r=dst IIS Stability:http://bugs.php.net/fix.php?id=42882r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42882r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42882r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42882r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42882r=mysqlcfg
#37911 [Asn-Csd]: preg_replace_callback ignores named groups
ID: 37911
Updated by: [EMAIL PROTECTED]
Reported By: thomas dot kalka at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: PCRE related
Operating System: xubuntu
PHP Version: 5.1.4
Assigned To: andrei
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-06-25 21:22:05] thomas dot kalka at gmail dot com
Description:
unfortunately preg_replace_callback does not handle named groups
Reproduce code:
---
?php
$a = bla blub blah;
$regex = '|(?Pnameblub)|';
function callback($match) { var_dump($match); return '-'; }
preg_replace_callback($regex,'callback',$a);
$m = array(); preg_match($regex,$a,$m); var_dump($m);
?
Expected result:
array(3) {
[0]=
string(4) blub
[name]=
string(4) blub
[1]=
string(4) blub
}
array(3) {
[0]=
string(4) blub
[name]=
string(4) blub
[1]=
string(4) blub
}
Actual result:
--
array(2) {
[0]=
string(4) blub
[1]=
string(4) blub
}
array(3) {
[0]=
string(4) blub
[name]=
string(4) blub
[1]=
string(4) blub
}
--
Edit this bug report at http://bugs.php.net/?id=37911edit=1
#42883 [NEW]: Bad function of rowCount combined with ATTR_EMULATE_PREPARES
From: salac dot r at gmail dot com
Operating system: openSUSE 10.2
PHP version: 5.2.4
PHP Bug Type: PDO related
Bug description: Bad function of rowCount combined with ATTR_EMULATE_PREPARES
Description:
When I'm using ATTR_EMULATE_PREPARES set to true,
function rowCount returns bad result (0).
I think that it's quite strange because without ATTR_EMULATE_PREPARES it
returns god values.
Reproduce code:
---
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass,
array(
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY = true,
PDO::ATTR_EMULATE_PREPARES = true)
);
$result=$dbh-query(SELECT * FROM Table);
echo rows = .$result-rowCount();
Expected result:
rows = 7 //number of rows in Table
Actual result:
--
rows = 0
--
Edit bug report at http://bugs.php.net/?id=42883edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42883r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42883r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42883r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42883r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42883r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42883r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42883r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42883r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42883r=support
Expected behavior:http://bugs.php.net/fix.php?id=42883r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42883r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42883r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42883r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42883r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42883r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42883r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42883r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42883r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42883r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42883r=mysqlcfg
#42737 [Asn-Csd]: Notice: preg_split(): Unknown error
ID: 42737
Updated by: [EMAIL PROTECTED]
Reported By: rm at drgs dot no
-Status: Assigned
+Status: Closed
Bug Type: PCRE related
Operating System: Mac OS X 10.3.9
PHP Version: 5.2.4
Assigned To: nlopess
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-09-22 20:17:43] rm at drgs dot no
this seems to be the case with all strings which end with \r\n
btw, theres an extra obsolete parantesis at the end of the second
line in reproduce code, sorry
[2007-09-22 20:11:09] rm at drgs dot no
Description:
I'm splitting a string into characters with this:
preg_split('//u', $string, - 1, PREG_SPLIT_NO_EMPTY);
I get a notice on an uknown error which happens when I use the
unicode suffix u in the pattern and when the input string is
\r\n:
$string = chr(13).chr(10);
but not when i drop the unicode option, ie. this works fine:
preg_split('//', $string, - 1, PREG_SPLIT_NO_EMPTY);
Reproduce code:
---
$string = chr(13).chr(10);
$array = preg_split('//u', $string, - 1, PREG_SPLIT_NO_EMPTY));
print_r(array_map('ord', $array));
Expected result:
Array
(
[0] = 13
[1] = 10
)
Actual result:
--
br /
bNotice/b: preg_split() [a href='function.preg-
split'function.preg-split/a]: Unknown error in b/Users/
myname/Sites/script.php/b on line b73/bbr /
Array
(
[0] = 13
[1] = 10
)
--
Edit this bug report at http://bugs.php.net/?id=42737edit=1
#4900 [Com]: Losing memory on web server and Listerner on the NT Service
ID: 4900 Comment by: fkl at tfu dot jgfi Reported By: herve at elma dot fr Status: No Feedback Bug Type: OCI8 related Operating System: Linux RedHat 6.1 - Apache 1.3.12 PHP Version: 4.0.0 Release New Comment: http://www.forex.co.ir http://wwwmeta-fx.com forex ÝÇÑÓ Previous Comments: [2000-08-31 21:15:47] [EMAIL PROTECTED] No feedback. Reopen this bug report if problem still exists when using php4.0.2. --Jani [2000-08-08 22:43:48] [EMAIL PROTECTED] Please verify that it´s still happening using the latest version of PHP (release 4.0.1pl2 or CVS). [2000-06-08 15:47:59] herve at elma dot fr I'm using a Linux RedHat 6.1 - Apache 1.3.12 - with Oracle Client 8.1.5 - PHP 4.0.0 Release And the Oracle Server is Oracle Server 8.0.5 on Windows NT It's a web site, with a minimum of 1 oracle request per page, and a maximum of 6 or 7 oracle requests per page. linked with many other web site which make Oracle request about 7 requests per day ... It's global troubles : - I lose memory on the Web server about 100Kb/seconde, I have to do a ./apachectl gracefull every hour to get the memory back (like when it start) because I get no more memory forthe service ... (512 Mb on this computer) - On the NT Server the Oracle Listener service memory grow all the time and must be restarted once a day, because it used all the memory (just the listener) - 512 Mb on this computer. When I make the graceful on apache the memory is not free for the Listener on the Oracle, and there is no connexions persinsting on the Oracle (or seems to not). Same thing when I cut the Listener on the NT Server the memory trouble of the Web server still remain. I mean in the two troubles it's not seems to be persistants connexion ... !? In the PHP scripts I open connections with Oracle with OCINLogon, before closing the connexion I make OCIFreeStatement, and then OCILogoff. We choose the ICNLogon because the OCIPLogin make persistant connexions and quickly the Oracle told us that the maximum of connexions were set, and when we made graceful on the apache the connexion were closed on the Oracle. I give you the php.ini I use : [PHP] ;;; ; About this file ; ;;; ; This file controls many aspects of PHP's behavior. In order for PHP to ; read it, it must be named 'php.ini'. PHP looks for it in the current ; working directory, in the path designated by the environment variable ; PHPRC, and in the path that was defined in compile time (in that order). ; Under Windows, the compile-time path is the Windows directory. The ; path in which the php.ini file is looked for can be overriden using ; the -c argument in command line mode. ; ; The syntax of the file is extremely simple. Whitespace and Lines ; beginning with a semicolon are silently ignored (as you probably guessed). ; Section headers (e.g. [Foo]) are also silently ignored, even though ; they might mean something in the future. ; ; Directives are specified using the following syntax: ; directive = value ; Directive names are *case sensitive* - foo=bar is different from FOO=bar. ; ; The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one ; of the INI constants (On, Off, True, False, Yes, No and None) or an expression ; (e.g. E_ALL ~E_NOTICE), or a quoted string (foo). ; ; Expressions in the INI file are limited to bitwise operators and parentheses: ; | bitwise OR ; bitwise AND ; ~ bitwise NOT ; ; Boolean flags can be turned on using the values 1, On, True or Yes. ; They can be turned off using the values 0, Off, False or No. ; ; An empty string can be denoted by simply not writing anything after the equal ; sign, or by using the None keyword: ; ; foo = ; sets foo to an empty string ; foo = none ; sets foo to an empty string ; foo = none; sets foo to the string 'none' ; ; If you use constants in your value, and these constants belong to a dynamically ; loaded extension (either a PHP extension or a Zend extension), you may only ; use these constants *after* the line that loads the extension. ; ; All the values in the php.ini-dist file correspond to the builtin ; defaults (that is, if no php.ini is used, or if you delete these lines, ; the builtin defaults will be identical). ; Language Options ; engine = On ; Enable the PHP scripting language engine under Apache short_open_tag = On ; allow the ? tag. otherwise, only ?php and script tags are recognized. asp_tags= Off ; allow ASP-style % % tags precision =
#42885 [NEW]: empty fields get zeroed
From: tobwen at gmx dot de
Operating system: Linux, win32
PHP version: 5.2.4
PHP Bug Type: dBase related
Bug description: empty fields get zeroed
Description:
The dBase-extension, which is bundled with PHP, fills empty dBase-fields
with a zero.
Reproduce code:
---
?php
$db = @dbase_open('test.dbf', READ_ONLY);
print pre\n;
for ($i = 1; $i = dbase_numrecords($db); $i++) {
$row = dbase_get_record($db, $i);
printf(%7d: %s\n, $i, join('|', $row));
}
print /pre\n;
dbase_close($db);
?
Expected result:
Access, Office 2003 and various dBase-readers can read those fields and
leave them empty.
Right now, you can't differ real zero entries from empty entries :-(
Actual result:
--
Fields, which are empty (not marked as deleted) are filled with zeros.
--
Edit bug report at http://bugs.php.net/?id=42885edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42885r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42885r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42885r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42885r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42885r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42885r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42885r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42885r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42885r=support
Expected behavior:http://bugs.php.net/fix.php?id=42885r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42885r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42885r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42885r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42885r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42885r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42885r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42885r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42885r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42885r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42885r=mysqlcfg
#41822 [Asn-Csd]: include()/require() cause permission denied error (bug #39351 not fixed!)
ID: 41822
Updated by: [EMAIL PROTECTED]
-Reported By: ian at onlineloop dot com
+Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: *Directory/Filesystem functions
Operating System: Solaris 10
PHP Version: 5.2CVS-20070627
-Assigned To: tony2001
+Assigned To: ab5602
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
This is fixed in CVS.
Previous Comments:
[2007-10-05 22:01:31] ab5602 at wayne dot edu
I created the following patch which fixes the problem, however it still
needs discussion as to if it is a good way to implement this fix. At
least it can serve as a starting point. One concern was if this should
be implemented at a lower level (TSRM code).
--- ./plain_wrapper.c.old 2007-10-05 02:50:59.0 -0400
+++ ./plain_wrapper.c 2007-10-05 02:55:38.0 -0400
@@ -885,9 +885,20 @@
return NULL;
}
- if ((realpath = expand_filepath(filename, NULL TSRMLS_CC)) ==
NULL) {
- return NULL;
- }
+if ((realpath = expand_filepath(filename, NULL TSRMLS_CC)) ==
NULL)
+{
+if (options STREAM_OPEN_FOR_INCLUDE) {
+/* Attempt to open without path expansion
anyways.
+ Files in Solaris dirs with --x will
+ not return a realpath, but are accessible
*/
+fd = open(filename, open_flags, 0666);
+if (fd != -1) {
+ret =
php_stream_fopen_from_fd_int_rel(fd, mode, persistent_id);
+return ret; }
+else {
+return NULL; }
+}
+}
if (persistent) {
spprintf(persistent_id, 0, streams_stdio_%d_%s,
open_flags, realpath);
[2007-10-05 11:58:09] jh at webteam dot at
Could reproduce this bug under Mac OS X 10.4.10 and PHP 5.2.4 (via
MacPorts).
[2007-10-05 03:29:44] ab5602 at wayne dot edu
No, the above NFS issues is a side-effect of:
1) Solaris getcwd() not functioning properly with (--x) directories
and
2) PHP not properly allowing relative include()'s when #1 is the case
#2 is probably solvable w/ a bug fix, #1 is obviously not.
[2007-10-02 11:11:49] [EMAIL PROTECTED]
So this is only an issue with NFS shares? If so, please indicate that
in the summary.
[2007-10-02 06:54:42] ab5602 at wayne dot edu
I figured out what the issue was with the NFS shares and the
permission denied error in our Solaris environment. It was related to
the same (--x) permission issue that you are having.
As it turns out, if you mount an NFS share in:
/mylocaldir/nfsmount/
The /nfsmount/ directory permissions, *before* you mount the share,
need to be (r-x) or better, even though these permissions are hidden
after the mount in order to avoid the Solaris+PHP include() bug. Now
include() and getcwd() work just fine!
It is very clear that this all goes back to two options:
1) Either make all the subdirs underneath (r-x)
OR
2) If it is possible (which I'm not yet sure of), the PHP binary needs
to tell Solaris that it already knows the current path by doing a
chdir(/absolute/path/) or the like before trying getcwd() in order to
make the include() cause permission denied error go away.
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/41822
--
Edit this bug report at http://bugs.php.net/?id=41822edit=1
#41899 [Asn-Fbk]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 Updated by: [EMAIL PROTECTED] -Reported By: geoffwa at cs dot rmit dot edu dot au +Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 -Assigned To: tony2001 +Assigned To: ab5602 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Try the latest CVS snapshot. Fixed the 41822 bug, which I feel is probably the same. Previous Comments: [2007-09-17 09:48:37] ian at onlineloop dot com Unfortunately we are not in a position to wither wait for PHP6 nor immediately migrate to it when it does come out. We have too many users with too many scripts on our server, and telling over 800 people that they have to adjust their scripts in less than 6 months just doesn't work here :-( With the continuing failure to fix this bug, we are left in a very uncomfortable situation, either continue with the security hole loaded 5.1.6, or apply the patch you offered. No one from the PHP project has logged into the system we set up for them on an E3500 since 5 July 2007 either, so I'm really left wondering about the seriousness there is to actually fix this bug. Anyway, I have seen from the source for PHP that realpath is definately not a function from Sun. realplath is all from the PHP project itself, so the attempt to shovel off the blame to Sun (post from 6 Jul 3:16pm) is not justifiable. Besides, this all worked just fine up until PHP 5.2.0 came out... [2007-09-13 01:56:00] geoffwa at cs dot rmit dot edu dot au I'll stress again that while the patch may work, I'm not sure if it's 'correct' or not, mainly because I have no idaa what php_checkuid_ex() is supposed to return, safe_mode-isms like open_basedir may need it. I just traced the execution of the offending PHP script repeatedly for the failure case, and deduced that the expand_filepath() call in php_checkuid_ex() that I've removed in the patch was returning an empty path under similar conditions to where a getcwd() call would fail. The actual path blatting appeared to occur in virtual_file_ex(), and we produced a separate patch which completely short-circuited this function and also made the all test conditions work. Given that PHP6 is removing safe_mode completely, I imagine this problem will hopefully be fixed then :) [2007-09-12 11:53:14] ian at onlineloop dot com I've tried the patch offered by Geoff. It seems to work just fine for us too in the cvs version from today (php5.2-200709121030). [2007-09-12 10:38:34] ian at onlineloop dot com Verified that this is still not working in 5.2.4. We made a system available on a Sun E3500, partially for the purposes of fixing this bug. The last login from anyone from the PHP team was on 5 July 2007. Is there any time plan to fix this bug? We are running on Solaris 10 and are stuck on PHP 5.1.6 because of this problem, so the situation for us is critical. [2007-08-14 15:21:39] wdierkes at 5dollarwhitebox dot org I have verified that this is *NOT* fixed in the latest CVS snapshot. Tested on Redhat Enterprise Linux 4 i386. Can we can an ETA on an official patch? 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/41899 -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#42879 [Opn-Bgs]: Feature proposal for print_r (for all PHP versions!)
ID: 42879 Updated by: [EMAIL PROTECTED] Reported By: rc at opelgt dot org -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: all PHP Version: 5.2.4 New Comment: My mail address is written next to the answer and the amounts of spam I get there tell it it works :-) Previous Comments: [2007-10-06 16:39:54] rc at opelgt dot org Description: I can deliver a different function if this is the only problem. Email me at the given address to avoid misusing this system. Rüdiger -- Edit this bug report at http://bugs.php.net/?id=42879edit=1
#41899 [Fbk-Opn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: Solaris 10
PHP Version: 5.2.3
Assigned To: ab5602
New Comment:
With php5.2-200710080430 the problem is worse, not better.
I can't even mkdir() in my test script any more!
?php
ini_set('display_errors', '1');
mkdir(./a/b, 0700, true) or die('mkdir failed');
touch(./a/b/file) or die('touch failed');
chmod(./a, 0300) or die('chmod failed');
chdir(./a/b) or die('chdir failed');
$fp = fopen('../b/file', 'r');
if ($fp) print SUCCESS\n;
else print FAILURE\n;
?
produces:
Warning: mkdir(): Unable to access ./a in
/home/g/geoffwa/work/test/test2.php on line 3
mkdir failed
Looking at truss, the last four syscalls are:
getcwd(/home/g/geoffwa/work/test, 1024) = 0
resolvepath(./a, 0xFFBFD238, 1024)Err#2 ENOENT
stat(a, 0xFFBFDF20) Err#2 ENOENT
stat(a, 0xFFBFDF20) Err#2 ENOENT
I'd also like to point out that the Solaris getcwd() works fine:
(from the man page)
The getcwd() function may fail if:
EACCES A parent directory cannot be read to get its
name.
Previous Comments:
[2007-10-08 03:04:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
Try the latest CVS snapshot. Fixed the 41822 bug, which I feel is
probably the same.
[2007-09-17 09:48:37] ian at onlineloop dot com
Unfortunately we are not in a position to wither wait for PHP6 nor
immediately migrate to it when it does come out. We have too many
users with too many scripts on our server, and telling over 800
people that they have to adjust their scripts in less than 6 months
just doesn't work here :-(
With the continuing failure to fix this bug, we are left in a very
uncomfortable situation, either continue with the security hole
loaded 5.1.6, or apply the patch you offered. No one from the PHP
project has logged into the system we set up for them on an E3500 since
5 July 2007 either, so I'm really left wondering about the seriousness
there is to actually fix this bug.
Anyway, I have seen from the source for PHP that realpath is
definately not a function from Sun. realplath is all from the PHP
project itself, so the attempt to shovel off the blame to Sun (post
from 6 Jul 3:16pm) is not justifiable. Besides, this all worked just
fine up until PHP 5.2.0 came out...
[2007-09-13 01:56:00] geoffwa at cs dot rmit dot edu dot au
I'll stress again that while the patch may work, I'm not sure if it's
'correct' or not, mainly because I have no idaa what php_checkuid_ex()
is supposed to return, safe_mode-isms like open_basedir may need it.
I just traced the execution of the offending PHP script repeatedly for
the failure case, and deduced that the expand_filepath() call in
php_checkuid_ex() that I've removed in the patch was returning an empty
path under similar conditions to where a getcwd() call would fail.
The actual path blatting appeared to occur in virtual_file_ex(), and we
produced a separate patch which completely short-circuited this function
and also made the all test conditions work.
Given that PHP6 is removing safe_mode completely, I imagine this
problem will hopefully be fixed then :)
[2007-09-12 11:53:14] ian at onlineloop dot com
I've tried the patch offered by Geoff. It seems to work just fine for
us too in the cvs version from today (php5.2-200709121030).
[2007-09-12 10:38:34] ian at onlineloop dot com
Verified that this is still not working in 5.2.4.
We made a system available on a Sun E3500, partially for the purposes
of fixing this bug. The last login from anyone from the PHP team was on
5 July 2007.
Is there any time plan to fix this bug? We are running on Solaris 10
and are stuck on PHP 5.1.6 because of this problem, so the situation for
us is critical.
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/41899
--
Edit this bug report at http://bugs.php.net/?id=41899edit=1
#32979 [Com]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
Comment by: roberto at spadim dot com dot br
Reported By: mjpph at stardust dot fi
Status: Assigned
Bug Type: Streams related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2006-01-18 (dev)
Assigned To: wez
New Comment:
i'm having the same problem with xeon quad core (prolian HP) on linux
socket_select work ok
but stream_select don't work
i will recompile php without openssl and check what happen
Previous Comments:
[2006-08-25 19:19:54] stotty at tvnet dot hu
Bug is still present in 5.1.4
[2006-01-31 23:08:00] stotty at tvnet dot hu
I have compared the original socket operations code, and the one in the
xp_ssl.x file, and it seems that even in the non-ssl path the code is
not identical.
I have fixed four differences, two of which caused some functions to be
called twice, and two of which are casting to *(int*)
I do not claim to know the real cause for the bug, and how these
changes fix the problem, but they do, and they make the code more
consistent, and faster, so I think they should be committed.
Here is the patch that solves this problem form me (against 5.1.2)
cut here---
*** php-5.1.2/ext/openssl/xp_ssl.c 2006-01-01 13:50:10.0 +0100
--- php-5.1.2ssl/ext/openssl/xp_ssl.c 2006-01-31 23:00:58.0
+0100
***
*** 188,194
} while(retry);
} else {
! didwrite = php_stream_socket_ops.write(stream, buf, count
TSRMLS_CC);
}
if (didwrite 0) {
--- 188,195
} while(retry);
} else {
! didwrite = php_stream_socket_ops.write(stream, buf, count
TSRMLS_CC);
! return didwrite;
}
if (didwrite 0) {
***
*** 226,231
--- 227,233
else
{
nr_bytes = php_stream_socket_ops.read(stream, buf, count
TSRMLS_CC);
+ return nr_bytes;
}
if (nr_bytes 0) {
***
*** 636,642
case PHP_STREAM_AS_FD_FOR_SELECT:
if (ret) {
! *ret = (void*)sslsock-s.socket;
}
return SUCCESS;
--- 638,644
case PHP_STREAM_AS_FD_FOR_SELECT:
if (ret) {
! *(int*)ret = (void*)sslsock-s.socket;
}
return SUCCESS;
***
*** 646,652
return FAILURE;
}
if (ret) {
! *ret = (void*)sslsock-s.socket;
}
return SUCCESS;
default:
--- 648,654
return FAILURE;
}
if (ret) {
! *(int*)ret = (void*)sslsock-s.socket;
}
return SUCCESS;
default:
cut here---
[2006-01-30 09:41:28] stotty at tvnet dot hu
I've done some testing, and this bug is definitely triggered by 64 bit+
SSL support.
Bug triggers:
FC4 64 bit + PHP5.1.2 (configure --with-openssl)
FC4 64 bit + PHP 5.1Jan 29 snapshot (configure --with-openssl)
Bug does not trigger:
FC4 64 bit + PHP 5.1.2 (configure)
FC4 64 bit + PHP 5.1Jan29 snapshot (configure)
FC4 32 bit + PHP 5.1.2 (configure --with-openssl)
FC4 32 bit + PHP 5.0.4-10.5 (stock FC RPM)
[2005-07-28 01:50:49] lew at mailduct dot com
wez -- the problems reported here are all due to a previously fixed bug
which has crept back into PHP. It has to do with how the PHP library
treats EOF under FreeBSD vs Linux.
You worked on this problem previously... please take a look at the
currently active Bug #32858 reported by me, as well as your prior fix in
Bug #25649.
Thanks
Lew Payne
[2005-05-30 22:11:28] mjpph at stardust dot fi
I haven't had problems with different kernels. Only the combination of
x86_64, stream_socket_client() or stream_socket_server(),
stream_select() and PHP OpenSSL-support seem to reproduce this every
time.
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/32979
--
Edit this bug report at
#32979 [Com]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979
Comment by: roberto at spadim dot com dot br
Reported By: mjpph at stardust dot fi
Status: Assigned
Bug Type: Streams related
Operating System: Linux (Fedora Core 3)
PHP Version: 5CVS-2006-01-18 (dev)
Assigned To: wez
New Comment:
the problem occur with php 5.2.4
Previous Comments:
[2007-10-08 05:32:50] roberto at spadim dot com dot br
i'm having the same problem with xeon quad core (prolian HP) on linux
socket_select work ok
but stream_select don't work
i will recompile php without openssl and check what happen
[2006-08-25 19:19:54] stotty at tvnet dot hu
Bug is still present in 5.1.4
[2006-01-31 23:08:00] stotty at tvnet dot hu
I have compared the original socket operations code, and the one in the
xp_ssl.x file, and it seems that even in the non-ssl path the code is
not identical.
I have fixed four differences, two of which caused some functions to be
called twice, and two of which are casting to *(int*)
I do not claim to know the real cause for the bug, and how these
changes fix the problem, but they do, and they make the code more
consistent, and faster, so I think they should be committed.
Here is the patch that solves this problem form me (against 5.1.2)
cut here---
*** php-5.1.2/ext/openssl/xp_ssl.c 2006-01-01 13:50:10.0 +0100
--- php-5.1.2ssl/ext/openssl/xp_ssl.c 2006-01-31 23:00:58.0
+0100
***
*** 188,194
} while(retry);
} else {
! didwrite = php_stream_socket_ops.write(stream, buf, count
TSRMLS_CC);
}
if (didwrite 0) {
--- 188,195
} while(retry);
} else {
! didwrite = php_stream_socket_ops.write(stream, buf, count
TSRMLS_CC);
! return didwrite;
}
if (didwrite 0) {
***
*** 226,231
--- 227,233
else
{
nr_bytes = php_stream_socket_ops.read(stream, buf, count
TSRMLS_CC);
+ return nr_bytes;
}
if (nr_bytes 0) {
***
*** 636,642
case PHP_STREAM_AS_FD_FOR_SELECT:
if (ret) {
! *ret = (void*)sslsock-s.socket;
}
return SUCCESS;
--- 638,644
case PHP_STREAM_AS_FD_FOR_SELECT:
if (ret) {
! *(int*)ret = (void*)sslsock-s.socket;
}
return SUCCESS;
***
*** 646,652
return FAILURE;
}
if (ret) {
! *ret = (void*)sslsock-s.socket;
}
return SUCCESS;
default:
--- 648,654
return FAILURE;
}
if (ret) {
! *(int*)ret = (void*)sslsock-s.socket;
}
return SUCCESS;
default:
cut here---
[2006-01-30 09:41:28] stotty at tvnet dot hu
I've done some testing, and this bug is definitely triggered by 64 bit+
SSL support.
Bug triggers:
FC4 64 bit + PHP5.1.2 (configure --with-openssl)
FC4 64 bit + PHP 5.1Jan 29 snapshot (configure --with-openssl)
Bug does not trigger:
FC4 64 bit + PHP 5.1.2 (configure)
FC4 64 bit + PHP 5.1Jan29 snapshot (configure)
FC4 32 bit + PHP 5.1.2 (configure --with-openssl)
FC4 32 bit + PHP 5.0.4-10.5 (stock FC RPM)
[2005-07-28 01:50:49] lew at mailduct dot com
wez -- the problems reported here are all due to a previously fixed bug
which has crept back into PHP. It has to do with how the PHP library
treats EOF under FreeBSD vs Linux.
You worked on this problem previously... please take a look at the
currently active Bug #32858 reported by me, as well as your prior fix in
Bug #25649.
Thanks
Lew Payne
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/32979
--
Edit this bug report at http://bugs.php.net/?id=32979edit=1
