Bug #51962 [Opn->Bgs]: PHP doesn't allow to have function named "goto"
Edit report at http://bugs.php.net/bug.php?id=51962&edit=1
ID: 51962
Updated by: ras...@php.net
Reported by: jankkhvej at gmail dot com
Summary: PHP doesn't allow to have function named "goto"
-Status: Open
+Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Ubuntu 10.04
PHP Version: 5.3.2
New Comment:
This should come as no surprise to you if you had read the migration
guide:
http://us.php.net/manual/en/migration53.incompatible.php
Previous Comments:
[2010-06-01 08:55:46] jankkhvej at gmail dot com
Description:
[...]
public function goto($page_num)
{
$this->page_num = $page_num;
}
[...]
gives that:
[Tue Jun 01 09:34:01 2010] [error] [client 127.0.1.1] PHP Parse error:
syntax error, unexpected T_GOTO, expecting T_STRING in
/workspace/project/web/lib/DataSourcePager.class.php on line 63
Test script:
---
goto('hello!');
Expected result:
hello!
Actual result:
--
PHP Parse error: syntax error, unexpected T_GOTO, expecting T_STRING in
/home/solik/jjj/goto_test.php on line 3
--
Edit this bug report at http://bugs.php.net/bug.php?id=51962&edit=1
Bug #51961 [Opn->Fbk]: ob_start w/ str_ireplace
Edit report at http://bugs.php.net/bug.php?id=51961&edit=1
ID: 51961
Updated by: ahar...@php.net
Reported by: zane at zanehooper dot com
Summary: ob_start w/ str_ireplace
-Status: Open
+Status: Feedback
Type: Bug
Package: Output Control
Operating System: Apache
PHP Version: 5.2.13
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.
Previous Comments:
[2010-06-01 06:02:14] zane at zanehooper dot com
Description:
I am making a bad word replacer using certain profanity settings.
Basically, when
I use str_ireplace inside of ob_start, a lot of the capitals on the page
are
removed (I didn't see any capitals added).
I'm not sure why it is happening, but I really need this fixed.
Test script:
---
function optimizeHTML( $html )
{
$html = str_ireplace( $badwords_array, $replacement, $html );
return $html;
}
ob_start( 'optimizeHTML' );
Expected result:
A regular page with $badwords_array replaced by $replacement
Actual result:
--
Some capitals on the page are removed
--
Edit this bug report at http://bugs.php.net/bug.php?id=51961&edit=1
Bug #51640 [Com]: Fwrite writes twice a text
Edit report at http://bugs.php.net/bug.php?id=51640&edit=1
ID: 51640
Comment by: g_i_ivanov at mail dot bg
Reported by: spiderboy1989 at gmail dot com
Summary: Fwrite writes twice a text
Status: Open
Type: Bug
Package: Filesystem function related
Operating System: Windows XP
PHP Version: 5.3.2
New Comment:
I have the same problem:
Windows XP Professional SP3, Apache/2.2.14, PHP 5.2.13 (cli)
code:
--
$fp = fopen("d:/Projects/test/logs/testfile.txt", "a");
fwrite($fp, date('c') . " - Sample text" . PHP_EOL);
fclose($fp);
result:
--
2010-05-31T10:36:37+03:00 - Sample text
2010-05-31T10:36:37+03:00 - Sample text
Previous Comments:
[2010-04-23 01:57:42] spiderboy1989 at gmail dot com
Description:
I'm having troubles with fwrite() function. It is writing twice a text I
just need to write once. I searched in google for the same problem, and
I found the same bug reported here :
http://bugs.php.net/bug.php?id=21916, and here :
http://bugs.php.net/bug.php?id=16225, but neither of both was solved.
This is how it writes into the file :
"First
Second
Hello world!
Hello world!
Third"
As you can see, the string "hello world!" is writed twice, and that
should not happen. Also, and this is weird, the line fwrite($op,
$lastLine); prints the text correctly, just once...
Test script:
---
$file = "test.txt";
$string = "Hello world!\r\n";
$op = fopen($file,"r+");
$exp = explode("\n", fread($op, filesize($file)));
$lastLine = end($exp);
fseek($op, -strlen($lastLine), SEEK_END);
fwrite($op, $string);
fwrite($op, $lastLine);
fclose($op);
Expected result:
The text should be writed just once.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51640&edit=1
Bug #51948 [Bgs]: Bug when you provide the absolute php-interpreter path
Edit report at http://bugs.php.net/bug.php?id=51948&edit=1
ID: 51948
User updated by: seizu at gmx dot at
Reported by: seizu at gmx dot at
Summary: Bug when you provide the absolute php-interpreter path
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Win32
PHP Version: 5.3.2
New Comment:
C:\php>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
C:\php>c:\php\php.exe -v
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I have only one php.ini located in c:\php\...
Problem does not occur in version 5.2.8
Previous Comments:
[2010-05-30 11:38:34] paj...@php.net
It is only about PHP finding or not a php.ini with a timezone defined in
it. If no tz is set you will get this error.
[2010-05-30 11:27:30] johan...@php.net
Make sure you are running the same PHP interpreter, two times. It looks
like another PHP is in the PATH first.
The error message tells you that c:\php\php.exe is configured wrong.
[2010-05-30 11:18:29] seizu at gmx dot at
Description:
Bug occurs even when you run the script from the command line and you
provide the absolute path of your php interpreter like c:\php\php.exe
.
also described in #51890 (but marked as bogus by kalle)
Test script:
---
just tpye in the command line
got an error:
=
c:\php\php.exe -r "echo strftime('%H:%M:%S',time());"
no error:
=
php.exe -r "echo strftime('%H:%M:%S',time());"
Expected result:
11:04:54
Actual result:
--
PHP Warning: strftime(): It is not safe to rely on the system's
timezone settings. You are *required* to use the date.timezone setting
or the date_default_timezone_set() function. In case you used any of
those methods and you are
still getting this warning, you most likely misspelled the timezone
identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Command
line code on line 1
Warning: strftime(): It is not safe to rely on the system's timezone
settings. You are *required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are stil
l getting this warning, you most likely misspelled the timezone
identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Command
line code on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51948&edit=1
Bug #51948 [Bgs]: Bug when you provide the absolute php-interpreter path
Edit report at http://bugs.php.net/bug.php?id=51948&edit=1
ID: 51948
User updated by: seizu at gmx dot at
Reported by: seizu at gmx dot at
Summary: Bug when you provide the absolute php-interpreter path
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Win32
PHP Version: 5.3.2
New Comment:
Ohhh mate!!! :( You are absolute right
It's a search-path problem! Sorry
Previous Comments:
[2010-06-01 10:43:12] seizu at gmx dot at
C:\php>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
C:\php>c:\php\php.exe -v
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I have only one php.ini located in c:\php\...
Problem does not occur in version 5.2.8
[2010-05-30 11:38:34] paj...@php.net
It is only about PHP finding or not a php.ini with a timezone defined in
it. If no tz is set you will get this error.
[2010-05-30 11:27:30] johan...@php.net
Make sure you are running the same PHP interpreter, two times. It looks
like another PHP is in the PATH first.
The error message tells you that c:\php\php.exe is configured wrong.
[2010-05-30 11:18:29] seizu at gmx dot at
Description:
Bug occurs even when you run the script from the command line and you
provide the absolute path of your php interpreter like c:\php\php.exe
.
also described in #51890 (but marked as bogus by kalle)
Test script:
---
just tpye in the command line
got an error:
=
c:\php\php.exe -r "echo strftime('%H:%M:%S',time());"
no error:
=
php.exe -r "echo strftime('%H:%M:%S',time());"
Expected result:
11:04:54
Actual result:
--
PHP Warning: strftime(): It is not safe to rely on the system's
timezone settings. You are *required* to use the date.timezone setting
or the date_default_timezone_set() function. In case you used any of
those methods and you are
still getting this warning, you most likely misspelled the timezone
identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Command
line code on line 1
Warning: strftime(): It is not safe to rely on the system's timezone
settings. You are *required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are stil
l getting this warning, you most likely misspelled the timezone
identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Command
line code on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51948&edit=1
[PHP-BUG] Bug #51963 [NEW]: preg_replace returns NULL, if in line more than 991 blanks
From:
Operating system: Windows XP SP3
PHP version: 5.2.13
Package: PCRE related
Bug Type: Bug
Bug description:preg_replace returns NULL, if in line more than 991 blanks
Description:
One of my regular expressions leads to return of emptiness to functions
preg_replace if the initial line contains more than 991 blanks. Example
more low. The first line works, the second dies also I lose all contents.
Test script:
---
$text = 'test'.str_repeat(' ', 991).'test'; // work
$text = 'test'.str_repeat(' ', 992).'test'; // empty :(
if ($text = preg_replace('/(.*?\s+)"([^\s]+.*?)/', '$1$2', $text))
{
echo "GOOD\n";
} else {
echo "BAD\n";
}
--
Edit bug report at http://bugs.php.net/bug.php?id=51963&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51963&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51963&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51963&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51963&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51963&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51963&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51963&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51963&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51963&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51963&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51963&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51963&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51963&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51963&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51963&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51963&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51963&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51963&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51963&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51963&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51963&r=mysqlcfg
[PHP-BUG] Bug #51964 [NEW]: mssql_query "Query Processor Error"
From:
Operating system: Ubuntu
PHP version: 5.3.2
Package: MSSQL related
Bug Type: Bug
Bug description:mssql_query "Query Processor Error"
Description:
I generate a SQL statement dynamically in PHP script.
When I execute this SQL query, the system crash with error "Query Processor
Error: The query processor could not produce a query plan".
If I execute the same query directly on SQL server, it works.
The SQL string is:
$sql = "BEGIN TRY
BEGIN TRANSACTION
DELETE FROM EEES_AprenAssigPE WHERE IdAssig like '200166' AND
Curs=2009;
INSERT INTO EEES_AprenAssigPE (IdPlaEst, IdAssig, CodiRes,
Curs) VALUES
('GEL01', '200166', 'C2', 2009);
INSERT INTO EEES_AprenAssigPE (IdPlaEst, IdAssig, CodiRes,
Curs) VALUES
('GEL01', '200166', 'E23', 2009);
INSERT INTO EEES_AprenAssigPE (IdPlaEst, IdAssig, CodiRes,
Curs) VALUES
('GEL01', '200166', 'E23.7', 2009);
SELECT 1 AS OK;
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
SELECT -1 AS OK;
ROLLBACK TRANSACTION;
END CATCH";
--
Edit bug report at http://bugs.php.net/bug.php?id=51964&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51964&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51964&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51964&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51964&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51964&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51964&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51964&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51964&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51964&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51964&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51964&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51964&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51964&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51964&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51964&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51964&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51964&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51964&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51964&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51964&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51964&r=mysqlcfg
Bug #51890 [Bgs]: CURL Problem
Edit report at http://bugs.php.net/bug.php?id=51890&edit=1 ID: 51890 User updated by: seizu at gmx dot at Reported by: seizu at gmx dot at Summary: CURL Problem Status: Bogus Type: Bug Package: cURL related Operating System: Windows XP PHP Version: 5.3.2 New Comment: --snip-- docu fopen 'r+' Open for reading and writing; place the file pointer at the beginning of the file. 'w+'Open for reading and writing; place the file pointer at the beginning of the file and truncate the file to zero length. If the file does not exist, attempt to create it. --snip-- when I use "wb+" the existing file will be truncate and that is not what I want, so I have to use "rb+" anyway ...and sorry, it has nothing to do with the absolute php-path it just a problem with php versions >5.2.8 Previous Comments: [2010-05-29 11:05:29] seizu at gmx dot at When you write into an "EXISTING FILE" "rb+" should work apart from that, the script works if you dont provide an absolute php-path! [2010-05-29 07:59:21] ka...@php.net You cannot do a writable operation using CURLOPT_FILE when the file pointer is opened with 'r', use 'wb+' instead of 'rb+'. [2010-05-22 23:10:16] seizu at gmx dot at Description: The script copy the URL into an existing file (robot.txt) The error occurs when you run the test script from the command line by providing the absolut path of your php.exe like >c:\php\php.exe test.php When you don't provide the absolut php path, the problem does not occure >php test.php Test script: --- http://www.astrobox.at/robots.txt";; $ch = curl_init($infile); $fo = fopen($outfile, "rb+" ); curl_setopt($ch, CURLOPT_FILE, $fo); curl_setopt($ch, CURLOPT_HEADER, 0); curl_exec($ch); curl_close($ch); fclose($fo); ?> Expected result: nothing Actual result: -- C:\phpda>c:\php\php.exe C:\phpda\test.php PHP Warning: curl_setopt(): the provided file handle is not writable in C:\phpda\test.php on line 7 Warning: curl_setopt(): the provided file handle is not writable in C:\phpda\test.php on line 7 User-agent: * Disallow: /administrator/ Disallow: /cache/ Disallow: /components/ Disallow: /editor/ Disallow: /help/ Disallow: /images/ Disallow: /includes/ Disallow: /language/ Disallow: /mambots/ Disallow: /media/ Disallow: /modules/ Disallow: /templates/ Disallow: /installation/ Disallow: /astrobox/produkte/ Disallow: /option/ -- Edit this bug report at http://bugs.php.net/bug.php?id=51890&edit=1
Bug #51948 [Bgs]: Bug when you provide the absolute php-interpreter path
Edit report at http://bugs.php.net/bug.php?id=51948&edit=1
ID: 51948
User updated by: seizu at gmx dot at
Reported by: seizu at gmx dot at
Summary: Bug when you provide the absolute php-interpreter path
Status: Bogus
Type: Bug
Package: Scripting Engine problem
Operating System: Win32
PHP Version: 5.3.2
New Comment:
But could you verify this, thx
http://bugs.php.net/bug.php?id=51890
Previous Comments:
[2010-06-01 10:51:57] seizu at gmx dot at
Ohhh mate!!! :( You are absolute right
It's a search-path problem! Sorry
[2010-06-01 10:43:12] seizu at gmx dot at
C:\php>php -v
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
C:\php>c:\php\php.exe -v
PHP 5.3.2 (cli) (built: Mar 3 2010 20:47:01)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
I have only one php.ini located in c:\php\...
Problem does not occur in version 5.2.8
[2010-05-30 11:38:34] paj...@php.net
It is only about PHP finding or not a php.ini with a timezone defined in
it. If no tz is set you will get this error.
[2010-05-30 11:27:30] johan...@php.net
Make sure you are running the same PHP interpreter, two times. It looks
like another PHP is in the PATH first.
The error message tells you that c:\php\php.exe is configured wrong.
[2010-05-30 11:18:29] seizu at gmx dot at
Description:
Bug occurs even when you run the script from the command line and you
provide the absolute path of your php interpreter like c:\php\php.exe
.
also described in #51890 (but marked as bogus by kalle)
Test script:
---
just tpye in the command line
got an error:
=
c:\php\php.exe -r "echo strftime('%H:%M:%S',time());"
no error:
=
php.exe -r "echo strftime('%H:%M:%S',time());"
Expected result:
11:04:54
Actual result:
--
PHP Warning: strftime(): It is not safe to rely on the system's
timezone settings. You are *required* to use the date.timezone setting
or the date_default_timezone_set() function. In case you used any of
those methods and you are
still getting this warning, you most likely misspelled the timezone
identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Command
line code on line 1
Warning: strftime(): It is not safe to rely on the system's timezone
settings. You are *required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are stil
l getting this warning, you most likely misspelled the timezone
identifier. We selected 'Europe/Paris' for '2.0/DST' instead in Command
line code on line 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=51948&edit=1
Bug #51146 [Com]: mcrypt doesn't do OFB mode correctly
Edit report at http://bugs.php.net/bug.php?id=51146&edit=1
ID: 51146
Comment by: me at haravikk dot com
Reported by: zelnaga at gmail dot com
Summary: mcrypt doesn't do OFB mode correctly
Status: Open
Type: Bug
Package: mcrypt related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
You're using the wrong OFB mode, you need to use MCRYPT_MODE_NOFB.
MCRYPT_MODE_OFB is per-byte, while MCRYPT_MODE_NOFB is per-block and
gives the
result you were expecting.
Previous Comments:
[2010-04-13 23:36:44] zelnaga at gmail dot com
I was comparing mcrypt against openssl_encrypt() and... well, either
OpenSSL is wrong or mcrypt is wrong:
ie. mcrypt, in CTR, CBC and ECB modes equal OpenSSL in OFB and CFB modes
but not mcrypt in OFB and CFB modes. In other words, OpenSSL's OFB !=
mcrypt's OFB and they should.
[2010-02-26 16:16:56] zelnaga at gmail dot com
As far as I know, the IV is also used for the first round, so I am not
sure if your statement holds up.
Ummm... the IV - as defined in mcrypt_generic_init - is only used in
the first round. Per wikipedia, the first block against which the
plaintext is XOR'd is the IV encrypted with the key. That's true in
both CFB and OFB modes of operation. The difference between CFB and OFB
is what subsequent blocks encrypt for the keystream. So, per that, the
first block should be the same. And as for my first bug report...
All of those should produce the same ciphertext. As it stands, only
ecb, cbc and ctr produce the same ciphertext. ofb and cfb produce the
same thing as each other (and, for the first block, they should, as I
already mentioned), however, they're not producing the same thing as any
of the other modes when, in fact, they should be.
[2010-02-26 10:54:01] der...@php.net
As far as I know, the IV is also used for the first round, so I am not
sure if your statement holds up.
[2010-02-26 03:28:05] zelnaga at gmail dot com
Filing a bug report is going to be a little difficult giving that, near
as I can tell, the command line version of mcrypt randomly generates
IV's. My first example requires the IV's be of a known value and my
second example requires encrypting the same string with two different
modes and with the same IV.
Also, to be honest, I don't know at all how to intreprete the data the
command line version of mcrypt is giving me, anyway. I do the
following:
mcrypt --algorithm des --mode ecb --no-openpgp test.txt --verbose
--bare
And I get a 100 byte file. Given that the source file was 16 bytes ("-"
repeated sixteen times), that's a bit odd. Curious to see what the
remaining 84 bytes are, I do the following:
And that doesn't produce anything even remotely resembling the source
text.
A while ago, there was a bug report filed on the mcrypt PHP extension
(49561) where someone reproduced the problem in C, using the mcrypt
libraries, and filed the bug report themselves. Can't that be done
here? I don't have the ability to compile PHP or PHP extensions such as
mcrypt and if no one reports the bug to the mcrypt developers than both
PHP and mcrypt will have this bug.
Of course, then again, given that bug # 49561 hasn't even been touched
by the mcrypt developers, it seems safe to assume that any bug report
that's filed - by me or anyone else - will be ignored. If mcrypt has
been abandoned by its developers when does PHP abandon mcrypt?
[2010-02-25 19:23:47] paj...@php.net
It looks like a libmcrypt problem, if it is a bug. Can you try using the
mcrypt cmd line tools? If it fails and you see it as a bug, please
report a bug to the mcrypt project. Let us know how it went.
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=51146
--
Edit this bug report at http://bugs.php.net/bug.php?id=51146&edit=1
Bug #51961 [Fbk->Opn]: ob_start w/ str_ireplace
Edit report at http://bugs.php.net/bug.php?id=51961&edit=1
ID: 51961
User updated by: zane at zanehooper dot com
Reported by: zane at zanehooper dot com
Summary: ob_start w/ str_ireplace
-Status: Feedback
+Status: Open
Type: Bug
Package: Output Control
Operating System: Apache
PHP Version: 5.2.13
New Comment:
Okay, the full script with PHP tags:
This is CapItalized.
The I or C in CapItalized might be removed, as well as the T in This or
The.
Previous Comments:
[2010-06-01 09:40:05] ahar...@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.
[2010-06-01 06:02:14] zane at zanehooper dot com
Description:
I am making a bad word replacer using certain profanity settings.
Basically, when
I use str_ireplace inside of ob_start, a lot of the capitals on the page
are
removed (I didn't see any capitals added).
I'm not sure why it is happening, but I really need this fixed.
Test script:
---
function optimizeHTML( $html )
{
$html = str_ireplace( $badwords_array, $replacement, $html );
return $html;
}
ob_start( 'optimizeHTML' );
Expected result:
A regular page with $badwords_array replaced by $replacement
Actual result:
--
Some capitals on the page are removed
--
Edit this bug report at http://bugs.php.net/bug.php?id=51961&edit=1
[PHP-BUG] Bug #51967 [NEW]: iconv_mime_encode() eats all memory
From:
Operating system: linux
PHP version: 5.2.13
Package: *Mail Related
Bug Type: Bug
Bug description:iconv_mime_encode() eats all memory
Description:
We got this error:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 2194780439 bytes) in
After examining the reason, I found this test to reproduce it.
Because we don't have 5.2.13 in production, this is only tested with
5.2.12, but as far as I know, there was no change here, since that, so it
should also be reproduce able with 5.2.13.
Test script:
---
'Q',
'input-charset' => 'utf-8',
'output-charset' => 'utf-8',
'line-length'=> 74,
'linke-break-chars' => "\r\n")
));
error_log("2");
Actual result:
--
The script prints out only "1" and breaks down with the fatal error. Take
care! It eats all memory if no limits are here!
--
Edit bug report at http://bugs.php.net/bug.php?id=51967&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51967&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51967&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51967&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51967&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51967&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51967&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51967&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51967&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51967&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51967&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51967&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51967&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51967&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51967&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51967&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51967&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51967&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51967&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51967&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51967&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51967&r=mysqlcfg
[PHP-BUG] Bug #51968 [NEW]: dns_get_record() [function.dns-get-record]: res_nsend() failed
From: Operating system: PHP version: 5.3.2 Package: *Network Functions Bug Type: Bug Bug description:dns_get_record() [function.dns-get-record]: res_nsend() failed Description: Certain hosts cause the dns_get_record() to fail with the following error: Warning: dns_get_record() [function.dns-get-record]: res_nsend() failed in dns.php on line 3 A live example of this error is found here: http://www.easywhois.com/index.php?mode=dnsinfo&domain=jjpny.com Test script: --- -- Edit bug report at http://bugs.php.net/bug.php?id=51968&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51968&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51968&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51968&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51968&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51968&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51968&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51968&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51968&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51968&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51968&r=support Expected behavior: http://bugs.php.net/fix.php?id=51968&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51968&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51968&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51968&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51968&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51968&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51968&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51968&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51968&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51968&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51968&r=mysqlcfg
Req #37681 [Com]: PUT and DELETE superglobals support
Edit report at http://bugs.php.net/bug.php?id=37681&edit=1
ID: 37681
Comment by: andreas dot s dot t dot jansson at gmail dot com
Reported by: f_kereki at cs dot com dot uy
Summary: PUT and DELETE superglobals support
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: SUSE 10.0
PHP Version: 5.1.4
New Comment:
If the only contents of the request body is the urlencoded "DELETE
parameters"
you can retrieve them by using file_get_contents("php://input"). It's
not as
clean as $_DELETE, but it's a workaround for now at least.
Previous Comments:
[2009-10-21 12:33:28] cyberspice at cyberspice dot org dot uk
I'd like to take this on. I too have come up against a similar issue
and I know of another developer who would be appreciative of it.
So I propose I make a patch that adds support for PUT, DELETE and HEAD
(for completeness) super globals.
Per RFC 2616 PUT is similar to post and can have data both in the URI
and the body of the request. DELETE and HEAD are like GET. Since there
is already support for POST data in the sapi code and php_variables.c
has treat_data() for handling GET. It seems it should be relatively
simple to extend for the new variables.
What do you think?
[2006-06-03 13:43:51] f_kereki at cs dot com dot uy
I'm coding a Service Oriented system, and according to REST principles,
I should be able to call a service with a PUT or DELETE method.
For example, using AJAX, in JavaScript I would write something like:
objeto= new XMLHttpRequest();
objeto.open("PUT", "my_own_service.php", true);
objeto.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded; charset=UTF-8");
objeto.onreadystatechange= some_function_of_mine;
objeto.send("a_string_like_field=value&field2=value2");
but then, my_own_service.php would have no way of getting to the PUT
parameters! With POST or GET methods, you can use the $_POST and $_GET
(and even $_REQUEST) arrays, but there are no $_PUT or $_DELETE
equivalent arrays.
Note, however, that this is *not* just an AJAX problem; if you require a
PHP service from within another PHP service, you would code something
like:
$ch= curl_init();
curl_setopt($ch, CURLOPT_URL, "my_own_service.php");
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($ch, CURLOPT_POSTFIELDS,
"a_string_like_field=value&field2=value2");
$result= curl_exec($ch);
curl_close($ch);
Of course, this points out yet ANOTHER problem... there is no
CURLOPT_PUTFIELDS! Since the format is the same, I assume my way should
work, but I cannot even get to test it until I have a way of getting to
the PUT parameters from within PHP.
So, to resume it all, it seems to me:
* there should be $_PUT and $_DELETE arrays
* curl should support CURLOPT_PUTFIELDS, *or* make it clearer that
CURLOPT_POSTFIELDS is to be used.
Hope I was clearer this time!
Best regards,
Federico Kereki
[2006-06-02 19:28:33] m...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2006-06-02 17:12:29] f_kereki at cs dot com dot uy
Description:
When coding Web Services according to REST ideas, there is no way to get
PUT or DELETE parameters -- something like $_GET or $_POST is needed.
You can invoke a service using curl, but only GET and POST can be used;
if you use PUT or DELETE you cannot get the parameters in PHP.
--
Edit this bug report at http://bugs.php.net/bug.php?id=37681&edit=1
Req #37681 [Com]: PUT and DELETE superglobals support
Edit report at http://bugs.php.net/bug.php?id=37681&edit=1
ID: 37681
Comment by: andreas dot s dot t dot jansson at gmail dot com
Reported by: f_kereki at cs dot com dot uy
Summary: PUT and DELETE superglobals support
Status: Open
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: SUSE 10.0
PHP Version: 5.1.4
New Comment:
I hit submit prematurely. Here's how to emulate $_DELETE:
parse_str(file_get_contents('php://input'), $_DELETE);
Previous Comments:
[2010-06-01 21:59:24] andreas dot s dot t dot jansson at gmail dot com
If the only contents of the request body is the urlencoded "DELETE
parameters"
you can retrieve them by using file_get_contents("php://input"). It's
not as
clean as $_DELETE, but it's a workaround for now at least.
[2009-10-21 12:33:28] cyberspice at cyberspice dot org dot uk
I'd like to take this on. I too have come up against a similar issue
and I know of another developer who would be appreciative of it.
So I propose I make a patch that adds support for PUT, DELETE and HEAD
(for completeness) super globals.
Per RFC 2616 PUT is similar to post and can have data both in the URI
and the body of the request. DELETE and HEAD are like GET. Since there
is already support for POST data in the sapi code and php_variables.c
has treat_data() for handling GET. It seems it should be relatively
simple to extend for the new variables.
What do you think?
[2006-06-03 13:43:51] f_kereki at cs dot com dot uy
I'm coding a Service Oriented system, and according to REST principles,
I should be able to call a service with a PUT or DELETE method.
For example, using AJAX, in JavaScript I would write something like:
objeto= new XMLHttpRequest();
objeto.open("PUT", "my_own_service.php", true);
objeto.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded; charset=UTF-8");
objeto.onreadystatechange= some_function_of_mine;
objeto.send("a_string_like_field=value&field2=value2");
but then, my_own_service.php would have no way of getting to the PUT
parameters! With POST or GET methods, you can use the $_POST and $_GET
(and even $_REQUEST) arrays, but there are no $_PUT or $_DELETE
equivalent arrays.
Note, however, that this is *not* just an AJAX problem; if you require a
PHP service from within another PHP service, you would code something
like:
$ch= curl_init();
curl_setopt($ch, CURLOPT_URL, "my_own_service.php");
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($ch, CURLOPT_POSTFIELDS,
"a_string_like_field=value&field2=value2");
$result= curl_exec($ch);
curl_close($ch);
Of course, this points out yet ANOTHER problem... there is no
CURLOPT_PUTFIELDS! Since the format is the same, I assume my way should
work, but I cannot even get to test it until I have a way of getting to
the PUT parameters from within PHP.
So, to resume it all, it seems to me:
* there should be $_PUT and $_DELETE arrays
* curl should support CURLOPT_PUTFIELDS, *or* make it clearer that
CURLOPT_POSTFIELDS is to be used.
Hope I was clearer this time!
Best regards,
Federico Kereki
[2006-06-02 19:28:33] m...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2006-06-02 17:12:29] f_kereki at cs dot com dot uy
Description:
When coding Web Services according to REST ideas, there is no way to get
PUT or DELETE parameters -- something like $_GET or $_POST is needed.
You can invoke a service using curl, but only GET and POST can be used;
if you use PUT or DELETE you cannot get the parameters in PHP.
--
Edit this bug report at http://bugs.php.net/bug.php?id=37681&edit=1
[PHP-BUG] Bug #51969 [NEW]: fwrite returns 1 when trying to write to a locked file
From:
Operating system: Windows 7 x86
PHP version: 5.3.2
Package: Filesystem function related
Bug Type: Bug
Bug description:fwrite returns 1 when trying to write to a locked file
Description:
When I try to write any length string with fwrite using a file handle I
previously
locked with flock, fwrite is of course unable to write, but will return
unexplicable value 1 instead of false.
Test script:
---
/*
Run two instances of this script in a rapid sequence
*/
$fp1 = fopen("/cache/lockable.txt","w");
if(flock($fp1, LOCK_EX | LOCK_NB)){
echo "locked fp1\n";
sleep(20);
}else{
$res = fwrite($fp1, "ABCDE");
if(false === $res){
echo "failed the write\n";
}
echo "I managed! fwrite returned: "; print_r($res);
}
Expected result:
I expect to read "failed to write" when a second instance of the script is
run,
since fwrite should return false as documentation says when fwrite is not
able to
write.
Actual result:
--
fwrite returns integer 1.
--
Edit bug report at http://bugs.php.net/bug.php?id=51969&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51969&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51969&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=51969&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=51969&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51969&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51969&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51969&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51969&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51969&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51969&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51969&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51969&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51969&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51969&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51969&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51969&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51969&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51969&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51969&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51969&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51969&r=mysqlcfg
Bug #51960 [Com]: PDO::MYSQL_ATTR_LOCAL_INFILE cause error always
Edit report at http://bugs.php.net/bug.php?id=51960&edit=1 ID: 51960 Comment by: rgagnon24 at gmail dot com Reported by: walkinraven at gmail dot com Summary: PDO::MYSQL_ATTR_LOCAL_INFILE cause error always Status: Open Type: Bug Package: PDO related Operating System: Ubuntu 8.04 PHP Version: 5.2SVN-2010-06-01 (SVN) New Comment: Looking in ext/pdo/mysql_driver.c, there is no support within get_attribute() nor set_attribute() for this attribute. This is why you always get false back. Its just not doing anything. We were running into just this same thing ourselves today in fact. Previous Comments: [2010-06-01 05:27:00] walkinraven at gmail dot com Description: If you set PDO::MYSQL_ATTR_LOCAL_INFILE with PDO::setAttribute function, it will return FALSE, whatever you set it to TRUE or FALSE. Test script: --- // $pdo=new PDO(...); $result=$pdo->setAttribute(PDO::MYSQL_ATTR_LOCAL_INFILE, FALSE); // or you could try set it to TRUE, you will get the same. $result=FALSE Expected result: $result != FALSE Actual result: -- $result == FALSE -- Edit this bug report at http://bugs.php.net/bug.php?id=51960&edit=1
[PHP-BUG] Bug #51970 [NEW]: Compile failure in Generation phar.php
From: Operating system: Linux slackware 2.6.34 PHP version: 5.3SVN-2010-06-02 (SVN) Package: Compile Failure Bug Type: Bug Bug description:Compile failure in Generation phar.php Description: PHP version SVN in r300051 2010-06-01 Description: - when i try to do 'make' with this configuration ./configure '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-curl' '--enable-pcntl' '--with-config-file-path=/etc' '--with-mysql' '--with-pear' '--with-zlib' '--enable-zip' '--enable-mbstring' make and then i see compile failure with string: Generating phar.php /usr/src/php/sapi/cli/php: error while loading shared libraries: libmysqlclient_r.so.16: cannot open shared object file: No such file or directory -- Edit bug report at http://bugs.php.net/bug.php?id=51970&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51970&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51970&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=51970&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=51970&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51970&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51970&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51970&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51970&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51970&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51970&r=support Expected behavior: http://bugs.php.net/fix.php?id=51970&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51970&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51970&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51970&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51970&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51970&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51970&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51970&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51970&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51970&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51970&r=mysqlcfg
Bug #51970 [Opn]: Compile failure in Generation phar.php
Edit report at http://bugs.php.net/bug.php?id=51970&edit=1 ID: 51970 User updated by: interpretor4 at gmail dot com Reported by: interpretor4 at gmail dot com Summary: Compile failure in Generation phar.php Status: Open Type: Bug Package: Compile Failure Operating System: Linux slackware 2.6.34 PHP Version: 5.3SVN-2010-06-02 (SVN) New Comment: bash-3.1$ locate libmysqlclient_r.so.16 /usr/lib/mysql/libmysqlclient_r.so.16.0.0 /usr/lib/mysql/libmysqlclient_r.so.16 /usr/src/mysql/libmysql_r/.libs/libmysqlclient_r.so.16.0.0 /usr/src/mysql/libmysql_r/.libs/libmysqlclient_r.so.16 Previous Comments: [2010-06-02 03:06:12] interpretor4 at gmail dot com Description: PHP version SVN in r300051 2010-06-01 Description: - when i try to do 'make' with this configuration ./configure '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-curl' '--enable-pcntl' '--with-config-file-path=/etc' '--with-mysql' '--with-pear' '--with-zlib' '--enable-zip' '--enable-mbstring' make and then i see compile failure with string: Generating phar.php /usr/src/php/sapi/cli/php: error while loading shared libraries: libmysqlclient_r.so.16: cannot open shared object file: No such file or directory -- Edit this bug report at http://bugs.php.net/bug.php?id=51970&edit=1
Bug #51960 [Com]: PDO::MYSQL_ATTR_LOCAL_INFILE cause error always
Edit report at http://bugs.php.net/bug.php?id=51960&edit=1 ID: 51960 Comment by: rgagnon24 at gmail dot com Reported by: walkinraven at gmail dot com Summary: PDO::MYSQL_ATTR_LOCAL_INFILE cause error always Status: Open Type: Bug Package: PDO related Operating System: Ubuntu 8.04 PHP Version: 5.2SVN-2010-06-01 (SVN) New Comment: A correction to my comment above after reviewing the source code more. The attribute PDO::MYSQL_ATTR_LOCAL_INFILE is supported by PDO, but only during the initial creation of the PDO object. You must set PDO::MYSQL_ATTR_LOCAL_INFILE in your options array. That means this is not a bug. Previous Comments: [2010-06-02 00:33:23] rgagnon24 at gmail dot com Looking in ext/pdo/mysql_driver.c, there is no support within get_attribute() nor set_attribute() for this attribute. This is why you always get false back. Its just not doing anything. We were running into just this same thing ourselves today in fact. [2010-06-01 05:27:00] walkinraven at gmail dot com Description: If you set PDO::MYSQL_ATTR_LOCAL_INFILE with PDO::setAttribute function, it will return FALSE, whatever you set it to TRUE or FALSE. Test script: --- // $pdo=new PDO(...); $result=$pdo->setAttribute(PDO::MYSQL_ATTR_LOCAL_INFILE, FALSE); // or you could try set it to TRUE, you will get the same. $result=FALSE Expected result: $result != FALSE Actual result: -- $result == FALSE -- Edit this bug report at http://bugs.php.net/bug.php?id=51960&edit=1
Bug #51967 [Opn->Fbk]: iconv_mime_encode() eats all memory
Edit report at http://bugs.php.net/bug.php?id=51967&edit=1
ID: 51967
Updated by: ahar...@php.net
Reported by: alex dot aulbach at mayflower dot de
Summary: iconv_mime_encode() eats all memory
-Status: Open
+Status: Feedback
Type: Bug
Package: *Mail Related
Operating System: linux
PHP Version: 5.2.13
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
It's not exactly the same bug, but given that the fix for bug #48289
(which was only committed about a month ago, hence isn't yet in any
releases) tinkered with the same function, could you please try a
snapshot and see if it fixes the problem?
Previous Comments:
[2010-06-01 18:39:17] alex dot aulbach at mayflower dot de
Description:
We got this error:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried
to allocate 2194780439 bytes) in
After examining the reason, I found this test to reproduce it.
Because we don't have 5.2.13 in production, this is only tested with
5.2.12, but as far as I know, there was no change here, since that, so
it should also be reproduce able with 5.2.13.
Test script:
---
'Q',
'input-charset' => 'utf-8',
'output-charset' => 'utf-8',
'line-length'=> 74,
'linke-break-chars' => "\r\n")
));
error_log("2");
Actual result:
--
The script prints out only "1" and breaks down with the fatal error.
Take care! It eats all memory if no limits are here!
--
Edit this bug report at http://bugs.php.net/bug.php?id=51967&edit=1
Bug #51940 [Com]: [notice] child pid 7335 exit signal Segmentation fault (11)
Edit report at http://bugs.php.net/bug.php?id=51940&edit=1 ID: 51940 Comment by: levuhoang at yahoo dot com Reported by: levuhoang at yahoo dot com Summary: [notice] child pid 7335 exit signal Segmentation fault (11) Status: Open Type: Bug Package: Reproducible crash Operating System: Centos 5.2 PHP Version: 5.2.13 New Comment: It seems the problem is libapr-1.so.0.3.0 and later. If I use libapr-1.so.0.2.7, it's fine. Otherwise, openssl_pkcs7_sign does not work. Previous Comments: [2010-05-28 06:36:26] levuhoang at yahoo dot com Description: Apache child process is killed when using openssl_pkcs7_sign I tried the snapshot PHP version (5.2dev) but not solve the problem. Apache: 2.2.15 OpenSSL: 1.0 PHP: 5.2.13/5.2dev OS: Centos 5.2 PHP Module: mod_security Test script: --- http://pastebin.com/vhjKtRJm Expected result: signed file must created. Actual result: -- Compile directives: ./configure \ --with-apxs2=/opt/apache2/bin/apxs \ --with-mysql \ --prefix=/opt/apache2/php \ --with-config-file-path=/opt/apache2/php \ --enable-force-cgi-redirect \ --disable-cgi \ --with-zlib \ --with-gettext \ --with-gdbm \ --enable-soap \ --with-pear \ --with-libxml-dir \ --with-ncurses \ --enable-gd-jis-conv \ --enable-gd-native-ttf \ --enable-mbstring \ --with-gd \ --with-freetype-dir=/usr/include/freetype2 \ --enable-gd-native-ttf \ --enable-shared \ --with-jpeg-dir \ --with-xpm-dir \ --enable-sockets \ --with-openssl=/usr/local/ssl BackTrace: warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libaprutil-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libaprutil-1.so.0 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/lib/libldap-2.3.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libldap-2.3.so.0 Reading symbols from /usr/lib/liblber-2.3.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib/liblber-2.3.so.0 Reading symbols from /lib/libdb-4.3.so...(no debugging symbols found)...done. Loaded symbols for /lib/libdb-4.3.so Reading symbols from /opt/apache2/lib/libexpat.so.0...done. Loaded symbols for /opt/apache2/lib/libexpat.so.0 Reading symbols from /opt/apache2/lib/libapr-1.so.0...done. Loaded symbols for /opt/apache2/lib/libapr-1.so.0 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libssl.so.6...done. Loaded symbols for /lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 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 /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /lib/libselinux.so.1...done. Loaded symbols for /lib/libselinux.so.1 Reading symbols from /lib/libsepol.so.1...done. Loaded symbols for /lib/libsepol.so.1 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /opt/apache2/modules/libphp5.so...done. Loaded symbols for /opt/apache2/modules/libphp5.so Reading symbols from /usr/lib/libpanel.so.5...done. Loaded symbols for /usr/lib/libpanel.so.5 Reading symbols from /usr/lib/libncurses.so.5...done. Loaded symbols for /usr/lib/libncurses.so.5 Reading symbols from /usr/lib/mysql/libmysqlclient_r.so.15...done
Bug #51847 [Opn]: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale
Edit report at http://bugs.php.net/bug.php?id=51847&edit=1 ID: 51847 Updated by: ras...@php.net Reported by: php-bugs-2010 at ryandesign dot com Summary: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale Status: Open Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.3 x86_64 PHP Version: 5.2.13 New Comment: I think this has to do with libintl. I see: #undef setlocale #define setlocale libintl_setlocale in libintl.h which is obviously going to make a mess of things. So, a quick compile fix is to skip the #include libintl.h in ext/standard/string.c but someone should really give the libintl dev who decided that was a good idea a "pat" on the back. Previous Comments: [2010-05-18 12:18:08] php-bugs-2010 at ryandesign dot com php 5.3.2 builds fine with gettext 0.17 and 0.18. This issue only appears to affect php 5.2.x. Adding '#include "ext/standard/php_string.h"' to ext/standard/basic_functions.c does not change the error message. [2010-05-18 10:04:40] ka...@php.net Hi Does this happen with 5.3 aswell? Does adding the following include after including 'ext/standard/php_uuencode.h' work: #include "ext/standard/php_string.h" [2010-05-18 05:09:31] php-bugs-2010 at ryandesign dot com Modify summary. [2010-05-18 05:07:58] php-bugs-2010 at ryandesign dot com Description: Hello, I'm the maintainer of the php packages in MacPorts, and it seems that php 5.2.13 doesn't build with gettext 0.18 (at least not on Mac OS X 10.6.3 x86_64). It fails with: Undefined symbols: "_zif_setlocale", referenced from: _basic_functions in basic_functions.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 php 5.2.13 builds fine with gettext 0.17, and php 5.3.2 builds fine with gettext 0.17 and 0.18. Here's the bug report that was submitted to us: http://trac.macports.org/ticket/24934 -- Edit this bug report at http://bugs.php.net/bug.php?id=51847&edit=1
Bug #51960 [Opn]: PDO::MYSQL_ATTR_LOCAL_INFILE cause error always
Edit report at http://bugs.php.net/bug.php?id=51960&edit=1 ID: 51960 User updated by: walkinraven at gmail dot com Reported by: walkinraven at gmail dot com Summary: PDO::MYSQL_ATTR_LOCAL_INFILE cause error always Status: Open Type: Bug Package: PDO related Operating System: Ubuntu 8.04 PHP Version: 5.2SVN-2010-06-01 (SVN) New Comment: Thank you! For there is no notice about this problem in user's manual ( http://www.php.net/manual/en/ref.pdo-mysql.php ), I have changed this into a problem of documentation. PDO::MYSQL_ATTR_LOCAL_INFILE can be set only at object initialization. Previous Comments: [2010-06-02 05:42:27] rgagnon24 at gmail dot com A correction to my comment above after reviewing the source code more. The attribute PDO::MYSQL_ATTR_LOCAL_INFILE is supported by PDO, but only during the initial creation of the PDO object. You must set PDO::MYSQL_ATTR_LOCAL_INFILE in your options array. That means this is not a bug. [2010-06-02 00:33:23] rgagnon24 at gmail dot com Looking in ext/pdo/mysql_driver.c, there is no support within get_attribute() nor set_attribute() for this attribute. This is why you always get false back. Its just not doing anything. We were running into just this same thing ourselves today in fact. [2010-06-01 05:27:00] walkinraven at gmail dot com Description: If you set PDO::MYSQL_ATTR_LOCAL_INFILE with PDO::setAttribute function, it will return FALSE, whatever you set it to TRUE or FALSE. Test script: --- // $pdo=new PDO(...); $result=$pdo->setAttribute(PDO::MYSQL_ATTR_LOCAL_INFILE, FALSE); // or you could try set it to TRUE, you will get the same. $result=FALSE Expected result: $result != FALSE Actual result: -- $result == FALSE -- Edit this bug report at http://bugs.php.net/bug.php?id=51960&edit=1
Bug #51847 [Opn->Csd]: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale
Edit report at http://bugs.php.net/bug.php?id=51847&edit=1 ID: 51847 Updated by: ras...@php.net Reported by: php-bugs-2010 at ryandesign dot com Summary: php 5.2.13 and gettext 0.18: Undefined symbols: _zif_setlocale -Status: Open +Status: Closed Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.3 x86_64 PHP Version: 5.2.13 -Assigned To: +Assigned To: rasmus New Comment: Fixed in all branches in svn Previous Comments: [2010-06-02 07:53:15] ras...@php.net Automatic comment from SVN on behalf of rasmus Revision: http://svn.php.net/viewvc/?view=revision&revision=300085 Log: Fix for bug #51847 Someone in libintl world decided it was a good idea to do: #undef setlocale #define setlocale libintl_setlocale That means, of course, that any use of "setlocale" by the preprocessor now becomes libintl_setlocale which means we no longer have a _zif_setlocale symbol in string.o, but we magically have a _zif_libintl_setlocale symbol. The linker is obviously not very happy about this when basic_functions.o tries to find _zif_setlocale. So, let's not do that again. [2010-06-02 07:35:18] ras...@php.net I think this has to do with libintl. I see: #undef setlocale #define setlocale libintl_setlocale in libintl.h which is obviously going to make a mess of things. So, a quick compile fix is to skip the #include libintl.h in ext/standard/string.c but someone should really give the libintl dev who decided that was a good idea a "pat" on the back. [2010-05-18 12:18:08] php-bugs-2010 at ryandesign dot com php 5.3.2 builds fine with gettext 0.17 and 0.18. This issue only appears to affect php 5.2.x. Adding '#include "ext/standard/php_string.h"' to ext/standard/basic_functions.c does not change the error message. [2010-05-18 10:04:40] ka...@php.net Hi Does this happen with 5.3 aswell? Does adding the following include after including 'ext/standard/php_uuencode.h' work: #include "ext/standard/php_string.h" [2010-05-18 05:09:31] php-bugs-2010 at ryandesign dot com Modify summary. 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=51847 -- Edit this bug report at http://bugs.php.net/bug.php?id=51847&edit=1
Bug #51961 [Opn->Fbk]: ob_start w/ str_ireplace
Edit report at http://bugs.php.net/bug.php?id=51961&edit=1
ID: 51961
Updated by: ahar...@php.net
Reported by: zane at zanehooper dot com
Summary: ob_start w/ str_ireplace
-Status: Open
+Status: Feedback
Type: Bug
Package: Output Control
Operating System: Apache
PHP Version: 5.2.13
New Comment:
That's still incomplete, since it doesn't include the actual array
you're giving str_ireplace() (which is kind of important).
Honestly, I'm kind of inclined to suspect it's a problem in your code,
rather than PHP, since the following code works for me on PHP 5.2:
Previous Comments:
[2010-06-01 13:31:47] zane at zanehooper dot com
Okay, the full script with PHP tags:
This is CapItalized.
The I or C in CapItalized might be removed, as well as the T in This or
The.
[2010-06-01 09:40:05] ahar...@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.
[2010-06-01 06:02:14] zane at zanehooper dot com
Description:
I am making a bad word replacer using certain profanity settings.
Basically, when
I use str_ireplace inside of ob_start, a lot of the capitals on the page
are
removed (I didn't see any capitals added).
I'm not sure why it is happening, but I really need this fixed.
Test script:
---
function optimizeHTML( $html )
{
$html = str_ireplace( $badwords_array, $replacement, $html );
return $html;
}
ob_start( 'optimizeHTML' );
Expected result:
A regular page with $badwords_array replaced by $replacement
Actual result:
--
Some capitals on the page are removed
--
Edit this bug report at http://bugs.php.net/bug.php?id=51961&edit=1
