[PHP-BUG] Bug #64172 [NEW]: errorInfo doesn't cleans up properly
From: dmitry dot vasilev at gmail dot com
Operating system: FreeBSD 8.2
PHP version: 5.4.11
Package: PDO related
Bug Type: Bug
Bug description:errorInfo doesn't cleans up properly
Description:
Affects at least PgSQL driver (MySQL works fine).
Workflow:
1. Make invalid query - errorInfo()[2] contains error info. Error code is
not
zero.
2. Make valid query - errorInfo()[2] still contains an error from the first
step
(but error code is 0).
pdo_pgsql:
libpq version 9.0.8
Module version: 1.0.2
Test script:
---
$pdo->exec("SELECT * FROM bad_table;");
echo $pdo->errorInfo()[2]; // "relation bad_table doesn't exist"
$pdo->exec("SELECT * FROM good_table;");
echo $pdo->errorInfo()[2]; // "relation bad_table doesn't exist". Expected
"".
Expected result:
""
Actual result:
--
"relation bad_table doesn't exist"
--
Edit bug report at https://bugs.php.net/bug.php?id=64172&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64172&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64172&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64172&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64172&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64172&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64172&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64172&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64172&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64172&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64172&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64172&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64172&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64172&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64172&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64172&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64172&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64172&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64172&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64172&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64172&r=mysqlcfg
Req #63356 [Com]: Add support for native php data types returned from Firebird PDO select queries
Edit report at https://bugs.php.net/bug.php?id=63356&edit=1 ID: 63356 Comment by: mar...@php.net Reported by:james at kenjim dot com Summary:Add support for native php data types returned from Firebird PDO select queries Status: Assigned Type: Feature/Change Request Package:PDO related Operating System: All PHP Version:5.4Git-2012-10-25 (Git) Assigned To:mariuz Block user comment: N Private report: N New Comment: Could you split the patch for each bug the ones that you mentioned at the end Also i will ask about the patching of /ext/pdo/pdo_stmt.c , i'm not sure what is the right way so i better ask on the list first Previous Comments: [2012-10-25 08:11:17] james at kenjim dot com Description: The data returned from a $rs->fetch() should use native data types when applicable. Currently all data is turned into strings. Using native data types will not only provide a way for the user to easily check the data type. It should also give a performance enhancement since everything does not need to be turned into a string. Some other database adapters already provide this ability. I have included a patch to add this functionality however I did have to modify /ext/pdo/pdo_stmt.c due to the way it was handling returning of zval's. It was expecting a ***zval when it really should of been a **zval. Due to this excessive pointer requirement any other pdo database driver that returns zval's will need to be fixed. I included in my patch a possible fix for the mysqlng pdo driver since I believe this is the only driver that uses it. I say possible fix because I have not tested the mysqlng support part of it. The patch also includes my patch for Bug #61183 - Firebird PDO memory corruption. It should also fix Bug #60052 - Integer returned as a 64bit integer on X64_86. It also fixes the patch that was improperly applied in Bug #47415 - PDO_Firebird segfaults when passing lowercased column name to bindColumn(). -- Edit this bug report at https://bugs.php.net/bug.php?id=63356&edit=1
Bug #24450 [Com]: TTF and FreeType functions lock font file
Edit report at https://bugs.php.net/bug.php?id=24450&edit=1
ID: 24450
Comment by: dimagsv at f-m dot fm
Reported by:choinet at rocketmail dot com
Summary:TTF and FreeType functions lock font file
Status: Wont fix
Type: Bug
Package:GD related
Operating System: Windows XP
PHP Version:4.3.3RC1
Block user comment: N
Private report: N
New Comment:
I have the same problem.
It still persists also on Winxp + PHP5.4.4
Previous Comments:
[2011-03-05 16:16:31] stano110 at azet dot sk
thanks for explanation. I have the same problem, cannot remove plugin directory
with the font locked. It's a pity, that this problem still persists also on
Win7+PHP5.3.3.
[2003-07-14 18:24:43] paj...@php.net
Hello,
We cannot fix it. Freetype keeps the file handle open and windows interprets
that as a lock. Test your script on a unix system and it should work like a
charm.
thanks for your report,
pierre
[2003-07-03 18:44:10] choinet at rocketmail dot com
I don't necessarily want to delete the file, but I want to be able to
hypothetically delete the parent directory above it :) I'm developing an image
management system that also allows for random image generation with text, and
perhaps I would need to remove a parent directory or the file itself.
[2003-07-01 18:37:04] sni...@php.net
Just curious..but why do you want to delete the file? :)
[2003-07-01 17:45:37] choinet at rocketmail dot com
Description:
My computer setup is Apache 2.0.46,PHP 4.3.2, and Windows XP SP1. Only
modifications to php.ini are: 'extension=php_gd2.dll' and 'log_errors' are
enabled. Originally, I was trying to use the imagettftext() function to write
text to a png file. I used the function in a similar context as described by
the manual, and the text write was successful. However, I stumbled upon the
discovery that the font file that the function uses was locked by either the
webserver or PHP process, as I was not able to unlink or remove the font file.
I tried to isolate the problem by testing the code on Windows XP with Apache
1.3.27, Apache 2.0.46, and IIS 5.1 and either PHP 4.2.3, 4.3.2, 4.3.3RC1, or
5.0, so I am thinking that it has something to do with the operating system.
Furthermore, this problem does not occur with a webserver running Apache/PHP
4.3.2 on Linux. Also, this problem applies to various true-type font files.
The problem only goes away after I stop or restart the webserver.
In summary, there are four functions that use a font file that lock it:
imagettftext(), imagettfbbox(), imagefttext(), and imageftbbox().
Reproduce code:
---
$im = imagecreatefrompng('test.png');
$blue = imagecolorallocate($im, 0, 102, 255);
$font = 'tahoma.ttf';
//
// These four functions lock the font file and do not release it
//
imagettftext($im, 10, 0, 10, 25, $blue, $font, 'text');
imagettfbbox (20, 0, $font, 'text');
imagefttext ($im, 12, 0, 10, 20, 5, $font, 'text', $foo);
imageftbbox (12, 0, $font, 'text', $foo);
header('Content-Type: image/png');
imagepng($im);
imagedestroy($im);
unlink($font);
Expected result:
I expect to see the png image generated and the font file unlinked.
Actual result:
--
The image displays fine but the font file cannot be deleted.
(Windows Error Dialog Box after manually attempting to delete arial.ttf)
Cannot delete arial: It is being used by another person or program. Close any
programs that might be using the file and try again.
(Apache Error Log)
[client 127.0.0.1] PHP Warning: unlink(arial.ttf): Permission denied in
C:\Apache2\htdocs\gd\dynamic.php on line 16
--
Edit this bug report at https://bugs.php.net/bug.php?id=24450&edit=1
[PHP-BUG] Bug #64171 [NEW]: configure script fail when I use --with-curl and --with-mysql parameters
From: difer_t at hotmail dot com Operating system: Ubuntu 12.10 PHP version: 5.4.11 Package: cURL related Bug Type: Bug Bug description:configure script fail when I use --with-curl and --with-mysql parameters Description: ./configure --prefix=/home/diegof/Desarrollo/php --with-apxs2=/home/diegof/Desarrollo/apache/bin/apxs \ --with-mysql=/home/diegof/Desarrollo/mysql \ --with-mysqli=/home/diegof/Desarrollo/mysql/bin/mysql_config \ --with-mysql-sock=/tmp/mysql.sock \ --with-pgsql=/home/diegof/Desarrollo/postgresql-9.2.2 \ --with-pdo-pgsql=/home/diegof/Desarrollo/postgresql-9.2.2/bin \ --with-zlib \ --with-zlib-dir \ --with-bz2 \ --with-gd \ --enable-gd-jis-conv \ --enable-gd-native-ttf \ --with-jpeg-dir=/home/diegof/Desarrollo/aditivos/libjpeg \ --with-png-dir=/home/diegof/Desarrollo/aditivos/libpng \ --with-freetype-dir=/home/diegof/Desarrollo/aditivos/freetype \ --with-iconv=/home/diegof/Desarrollo/aditivos/libiconv \ --with-gettext \ --with-config-file-path=/home/diegof/Desarrollo/apache/conf \ --enable-ftp \ --enable-mbstring \ --with-openssl=/home/diegof/Desarrollo/aditivos/openssl \ --with-curl=/home/diegof/Desarrollo/aditivos/curl Test script: --- . . checking whether to enable calendar conversion support... no checking whether to enable ctype functions... yes checking for cURL support... yes checking if we should use cURL for url streams... no checking for cURL 7.10.5 or greater... libcurl 7.29.0 checking for SSL support in libcurl... yes checking how to run the C preprocessor... cc -E checking for openssl support in libcurl... no checking for gnutls support in libcurl... no checking for curl_easy_perform in -lcurl... no configure: error: There is something wrong. Please check config.log for more information. $ without --with-curl parameter: . . checking for MSSQL support via FreeTDS... no checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... /tmp/mysql.sock checking for mysql_close in -lmysqlclient_r... no checking for mysql_error in -lmysqlclient_r... no configure: error: mysql configure failed. Please check config.log for more information. $ Expected result: Compilation Completed Successfully Thanks for use PHP ! Actual result: -- "config.log" says . . . configure:27511: checking whether to enable calendar conversion support configure:27546: result: no configure:27855: checking whether to enable ctype functions configure:27890: result: yes configure:28199: checking for cURL support configure:28235: result: yes configure:28244: checking if we should use cURL for url streams configure:28259: result: no configure:28289: checking for cURL 7.10.5 or greater configure:28303: result: libcurl 7.29.0 configure:28528: checking for SSL support in libcurl configure:28532: result: yes configure:28546: checking how to run the C preprocessor configure:28616: result: cc -E configure:28636: cc -E -D_REENTRANT conftest.c configure:28636: $? = 0 configure:28650: cc -E -D_REENTRANT conftest.c conftest.c:235:28: fatal error: ac_nonexistent.h: No such file or directory compilation terminated. configure:28650: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" . . -- Edit bug report at https://bugs.php.net/bug.php?id=64171&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64171&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64171&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64171&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64171&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64171&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64171&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64171&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64171&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64171&r=support Expected behavior: https://bugs.php.net/fix.php?id=64171&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64171&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64171&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64171&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64171&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64171&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64171&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64171&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64171&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64171&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64171&r=mysqlcfg
Bug #60585 [Fbk->NoF]: php build fails with USE flag snmp when IPv6 support is disabled
Edit report at https://bugs.php.net/bug.php?id=60585&edit=1 ID: 60585 Updated by: lytbo...@php.net Reported by:sknizek at cyberport dot de Summary:php build fails with USE flag snmp when IPv6 support is disabled -Status: Feedback +Status: No Feedback Type: Bug Package:SNMP related Operating System: Gentoo Linux PHP Version:5.4.0RC3 Assigned To:lytboris Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2012-07-24 23:37:44] ras...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4 Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname) Fixed ipv6 test skipto if IPv6 support is disabled [2012-04-18 09:46:35] larue...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4 Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname) Fixed ipv6 test skipto if IPv6 support is disabled [2012-01-13 18:48:36] lytbo...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2012-01-13 18:46:26] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=322214 Log: merge from trunk: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname [2012-01-13 18:33:51] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=322213 Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname) Fixed ipv6 test skipto if IPv6 support is disabled The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60585 -- Edit this bug report at https://bugs.php.net/bug.php?id=60585&edit=1
Bug #60749 [Fbk->NoF]: SNMP module should not strip non-standard SNMP port from hostname
Edit report at https://bugs.php.net/bug.php?id=60749&edit=1 ID: 60749 Updated by: lytbo...@php.net Reported by:lytbo...@php.net Summary:SNMP module should not strip non-standard SNMP port from hostname -Status: Feedback +Status: No Feedback Type: Bug Package:SNMP related Operating System: * PHP Version:5.4.0RC5 Assigned To:lytboris Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2012-07-24 23:37:45] ras...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4 Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname) Fixed ipv6 test skipto if IPv6 support is disabled [2012-04-18 09:46:36] larue...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=583292ab221e98f1e9585412c515057626bccdd4 Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname) Fixed ipv6 test skipto if IPv6 support is disabled [2012-01-13 18:48:17] lytbo...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2012-01-13 18:46:27] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=322214 Log: merge from trunk: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname [2012-01-13 18:33:52] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revision&revision=322213 Log: Fixed bug #60585 (php build fails with USE flag snmp when IPv6 support is disabled) Fixed bug #60749 (SNMP module should not strip non-standard SNMP port from hostname) Fixed ipv6 test skipto if IPv6 support is disabled The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60749 -- Edit this bug report at https://bugs.php.net/bug.php?id=60749&edit=1
Req #35855 [Fbk->NoF]: Patch to Build PHP_SNMP with NET-SNMP Support
Edit report at https://bugs.php.net/bug.php?id=35855&edit=1
ID: 35855
Updated by: lytbo...@php.net
Reported by:larryjadams at comcast dot net
Summary:Patch to Build PHP_SNMP with NET-SNMP Support
-Status: Feedback
+Status: No Feedback
Type: Feature/Change Request
Package:SNMP related
Operating System: Win32
PHP Version:5.1.1
Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2011-08-21 20:24:02] lytbo...@php.net
Is this still an pressing issue?
[2005-12-31 09:11:59] larryjadams at comcast dot net
Here are the two patch files:
http://home.comcast.net/~larryjadams/config.w32.patch
http://home.comcast.net/~larryjadams/snmp.dsp.patch
Thanks!!
[2005-12-30 22:36:55] larryjadams at comcast dot net
Patch for snmp.dsp:
--- snmp.dsp2005-12-27 17:21:19.31250 -0500
+++ Backup/snmp.dsp 2004-01-17 07:59:48.0 -0500
@@ -54,7 +54,7 @@
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib php5ts.lib /nologo /dll /machine:I386
-# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib php5ts.lib libsnmp.lib netsnmp.lib wsock32.lib /nologo /dll
/machine:I386 /out:"..\..\Release_TS/php_snmp.dll" /libpath:"..\..\Release_TS"
/libpath:"..\..\Release_TS_Inline"
+# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib php5ts.lib libsnmp.lib wsock32.lib /nologo /dll /machine:I386
/out:"..\..\Release_TS/php_snmp.dll" /libpath:"..\..\Release_TS"
/libpath:"..\..\Release_TS_Inline"
!ELSEIF "$(CFG)" == "snmp - Win32 Debug_TS"
@@ -81,7 +81,7 @@
# ADD BSC32 /nologo
LINK32=link.exe
# ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib php5ts.lib /nologo /dll /machine:I386
-# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib php5ts_debug.lib libsnmp.lib netsnmp.lib wsock32.lib /nologo /dll
/machine:I386 /out:"..\..\Debug_TS/php_snmp.dll" /libpath:"..\..\Debug_TS"
+# ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib
advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib
odbccp32.lib php5ts_debug.lib libsnmp.lib wsock32.lib /nologo /dll
/machine:I386 /out:"..\..\Debug_TS/php_snmp.dll" /libpath:"..\..\Debug_TS"
!ENDIF
Patch for config.w32:
--- config.w32 2005-12-30 16:19:21.28125 -0500
+++ Backup/config.w32 2003-12-19 12:00:10.0 -0500
@@ -4,18 +4,13 @@
ARG_WITH("snmp", "SNMP support", "no");
if (PHP_SNMP != "no") {
- if (CHECK_HEADER_ADD_INCLUDE("snmp.h", "CFLAGS_SNMP", PHP_PHP_BUILD +
"\\include\\ucd-snmp;" + PHP_PHP_BUILD + "\\include\\net-snmp;" + PHP_SNMP)) {
- if (CHECK_LIB("netsnmp.lib", "snmp", PHP_SNMP)) {
- EXTENSION('snmp', 'snmp.c');
- AC_DEFINE('HAVE_SNMP', 1);
- AC_DEFINE('HAVE_NET_SNMP', 1);
- AC_DEFINE('MSVC_PERL', 1);
- } else if (CHECK_LIB("libsnmp.lib", "snmp", PHP_SNMP)) {
+
+ if (CHECK_HEADER_ADD_INCLUDE("snmp.h", "CFLAGS_SNMP", PHP_PHP_BUILD +
"\\include\\ucd-snmp;" + PHP_PHP_BUILD + "\\include\\net-snmp;" + PHP_SNMP) &&
+ CHECK_LIB("libsnmp.lib", "snmp", PHP_SNMP)) {
EXTENSION('snmp', 'snmp.c');
+
AC_DEFINE('HAVE_SNMP', 1);
- } else {
- WARNING("snmp not enabled; libraries and headers not
found");
- }
+
} else {
WARNING("snmp not enabled; libraries and headers not found");
}
[2005-12-30 22:26:40] larryjadams at comcast dot net
Description:
The current "Windows" version of the php_snmp extension is built with the
undersupported ucd-snmp libraries. There are several issues continuing to
utilize the ucd-snmp issues included unfixed bugs in Win32 b
Bug #64146 [Ver]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1 ID: 64146 Updated by: m...@php.net Reported by:slusarz at curecanti dot org Summary:serialize incorrectly saving objects when they are cloned Status: Verified Type: Bug Package:Variables related Operating System: Linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Using zend_objects_get_address() instead of the object handle fixes; but triggers bug #62836 Previous Comments: [2013-02-07 22:57:27] m...@php.net The following patch has been added/updated: Patch Name: zend_objects_get_address Revision: 1360277847 URL: https://bugs.php.net/patch-display.php?bug=64146&patch=zend_objects_get_address&revision=1360277847 [2013-02-07 21:35:26] m...@php.net Obviously a flaw in the way an object is identified in the engine/in the serializer. Since the cloned objects only live for the time of serialization, both have the same object handle and will be identified as the *same*. Not sure why unserialize barfs on it, though. [2013-02-07 19:37:35] ni...@php.net @slusarz: Github changed the Gist URLs to include the owner's name too. I guess they didn't consider users having number-names while doing that ^^ [2013-02-07 17:18:06] slusarz at curecanti dot org Strange... Since that is the link github provides when you click on "share". Anyway, try this instead: https://gist.github.com/slusarz/4709613 [2013-02-07 16:05:15] larue...@php.net the link says: 4709613 hasn't created any public gists yet. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64146 -- Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
Bug #64146 [PATCH]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1
ID: 64146
Patch added by: m...@php.net
Reported by:slusarz at curecanti dot org
Summary:serialize incorrectly saving objects when they are
cloned
Status: Verified
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: zend_objects_get_address
Revision: 1360277847
URL:
https://bugs.php.net/patch-display.php?bug=64146&patch=zend_objects_get_address&revision=1360277847
Previous Comments:
[2013-02-07 21:35:26] m...@php.net
Obviously a flaw in the way an object is identified in the engine/in the
serializer.
Since the cloned objects only live for the time of serialization, both have the
same object handle and will be identified as the *same*.
Not sure why unserialize barfs on it, though.
[2013-02-07 19:37:35] ni...@php.net
@slusarz: Github changed the Gist URLs to include the owner's name too. I guess
they didn't consider users having number-names while doing that ^^
[2013-02-07 17:18:06] slusarz at curecanti dot org
Strange... Since that is the link github provides when you click on "share".
Anyway, try this instead:
https://gist.github.com/slusarz/4709613
[2013-02-07 16:05:15] larue...@php.net
the link says: 4709613 hasn't created any public gists yet.
[2013-02-04 21:11:57] slusarz at curecanti dot org
Description:
When using clone in a Serializable serialize() method, the first object is
correctly cloned/saved. However, all subsequent calls to serialize() in the
same script access will have incorrect serialized representations of the cloned
object.
Using var_dump, it appears that clone is reusing the same object ID when the
object is cloned.
I can verify that removing the 'clone' keyword in the test script causes the
script to run correctly.
Test script:
---
https://gist.github.com/4709613
Expected result:
See gist for expected value.
For the record, the serialized value of the A object is as follows:
O:1:"A":1:{s:1:"a";a:2:{i:0;C:1:"B":24:{O:1:"C":1:{s:1:"c";i:1;}}i:1;C:1:"B":4:{r:4;}}}
Actual result:
--
See gist for actual value.
FWIW, running with --enable-debug produces this message:
[Mon Feb 4 14:11:17 2013] Script: '/tmp/test.php'
/disk2/src/php-5.4.11/Zend/zend_vm_execute.h(624) : Freeing 0x7FD6C9C94D78 (32
bytes), script=/tmp/test.php
=== Total 1 memory leaks detected ===
--
Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
Bug #64146 [Opn->Ver]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1
ID: 64146
Updated by: m...@php.net
Reported by:slusarz at curecanti dot org
Summary:serialize incorrectly saving objects when they are
cloned
-Status: Open
+Status: Verified
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Obviously a flaw in the way an object is identified in the engine/in the
serializer.
Since the cloned objects only live for the time of serialization, both have the
same object handle and will be identified as the *same*.
Not sure why unserialize barfs on it, though.
Previous Comments:
[2013-02-07 19:37:35] ni...@php.net
@slusarz: Github changed the Gist URLs to include the owner's name too. I guess
they didn't consider users having number-names while doing that ^^
[2013-02-07 17:18:06] slusarz at curecanti dot org
Strange... Since that is the link github provides when you click on "share".
Anyway, try this instead:
https://gist.github.com/slusarz/4709613
[2013-02-07 16:05:15] larue...@php.net
the link says: 4709613 hasn't created any public gists yet.
[2013-02-04 21:11:57] slusarz at curecanti dot org
Description:
When using clone in a Serializable serialize() method, the first object is
correctly cloned/saved. However, all subsequent calls to serialize() in the
same script access will have incorrect serialized representations of the cloned
object.
Using var_dump, it appears that clone is reusing the same object ID when the
object is cloned.
I can verify that removing the 'clone' keyword in the test script causes the
script to run correctly.
Test script:
---
https://gist.github.com/4709613
Expected result:
See gist for expected value.
For the record, the serialized value of the A object is as follows:
O:1:"A":1:{s:1:"a";a:2:{i:0;C:1:"B":24:{O:1:"C":1:{s:1:"c";i:1;}}i:1;C:1:"B":4:{r:4;}}}
Actual result:
--
See gist for actual value.
FWIW, running with --enable-debug produces this message:
[Mon Feb 4 14:11:17 2013] Script: '/tmp/test.php'
/disk2/src/php-5.4.11/Zend/zend_vm_execute.h(624) : Freeing 0x7FD6C9C94D78 (32
bytes), script=/tmp/test.php
=== Total 1 memory leaks detected ===
--
Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
Bug #64170 [Opn->Nab]: ECHO with a character become a backdoor
Edit report at https://bugs.php.net/bug.php?id=64170&edit=1 ID: 64170 Updated by: s...@php.net Reported by:yoco_smart at live dot cn Summary:ECHO with a character become a backdoor -Status: Open +Status: Not a bug Type: Bug Package:*General Issues Operating System: windows & linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. See http://php.net/manual/en/language.operators.execution.php Previous Comments: [2013-02-07 18:57:54] yoco_smart at live dot cn Description: echo function become a backdoor. hello, i'm YoCo,from Silic Network Solutions Company,China. I find that some character can make the function ECHO become the backdoor, just one line!! like this: echo `$_POST[x]`; the quote character is ``, not the '',it is diffrent between ' and `,is it right? i dont know why the `` will equal the function SYSTEM, i test it both on the windows with iis and linux with apache,both of them are work well, however the ECHO function become a hacker's backdoor, if some one use it, the manager hard to find it. Test script: --- Expected result: the ECHO function becomes the SYSTEM function, just one line script. -- Edit this bug report at https://bugs.php.net/bug.php?id=64170&edit=1
Bug #64166 [Opn]: quoted-printable-encode stream filter incorrectly discarding whitespace
Edit report at https://bugs.php.net/bug.php?id=64166&edit=1 ID: 64166 User updated by:slusarz at curecanti dot org Reported by:slusarz at curecanti dot org Summary:quoted-printable-encode stream filter incorrectly discarding whitespace Status: Open Type: Bug Package:Streams related Operating System: Linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Added pull request with fix that seems to work (w/unit test): https://github.com/php/php-src/pull/272 Previous Comments: [2013-02-07 01:14:58] slusarz at curecanti dot org Just kidding... apparently there's a difference between "filter" and "stream filter". Sorry for the noise. [2013-02-07 01:14:09] slusarz at curecanti dot org This is actually a stream *filter* issue, so put in filter queue. [2013-02-07 00:49:44] slusarz at curecanti dot org Description: The QP stream filter is incorrectly discarding whitespace at the end of the lines. The quoted_printable_encode() method does not have this issue. This is troublesome when attempting to save flowed text/plain data, as it causes the data to lose its flowed formatting. (I realize that RFC 3676 says flowed text SHOULD NOT be encoded in QP, but this is an (arguably) outdated policy restriction and not a technical restriction). Test script: --- 76 )); fwrite($fp, $data); rewind($fp); print quoted_printable_encode($data) . "\n"; print stream_get_contents($fp); Expected result: FIRST=20 SECOND FIRST=20 SECOND Actual result: -- FIRST=20 SECOND FIRST SECOND -- Edit this bug report at https://bugs.php.net/bug.php?id=64166&edit=1
Bug #64146 [Com]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1
ID: 64146
Comment by: ni...@php.net
Reported by:slusarz at curecanti dot org
Summary:serialize incorrectly saving objects when they are
cloned
Status: Open
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
@slusarz: Github changed the Gist URLs to include the owner's name too. I guess
they didn't consider users having number-names while doing that ^^
Previous Comments:
[2013-02-07 17:18:06] slusarz at curecanti dot org
Strange... Since that is the link github provides when you click on "share".
Anyway, try this instead:
https://gist.github.com/slusarz/4709613
[2013-02-07 16:05:15] larue...@php.net
the link says: 4709613 hasn't created any public gists yet.
[2013-02-04 21:11:57] slusarz at curecanti dot org
Description:
When using clone in a Serializable serialize() method, the first object is
correctly cloned/saved. However, all subsequent calls to serialize() in the
same script access will have incorrect serialized representations of the cloned
object.
Using var_dump, it appears that clone is reusing the same object ID when the
object is cloned.
I can verify that removing the 'clone' keyword in the test script causes the
script to run correctly.
Test script:
---
https://gist.github.com/4709613
Expected result:
See gist for expected value.
For the record, the serialized value of the A object is as follows:
O:1:"A":1:{s:1:"a";a:2:{i:0;C:1:"B":24:{O:1:"C":1:{s:1:"c";i:1;}}i:1;C:1:"B":4:{r:4;}}}
Actual result:
--
See gist for actual value.
FWIW, running with --enable-debug produces this message:
[Mon Feb 4 14:11:17 2013] Script: '/tmp/test.php'
/disk2/src/php-5.4.11/Zend/zend_vm_execute.h(624) : Freeing 0x7FD6C9C94D78 (32
bytes), script=/tmp/test.php
=== Total 1 memory leaks detected ===
--
Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
[PHP-BUG] Bug #64170 [NEW]: ECHO with a character become a backdoor
From: yoco_smart at live dot cn Operating system: windows & linux PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:ECHO with a character become a backdoor Description: echo function become a backdoor. hello, i'm YoCo,from Silic Network Solutions Company,China. I find that some character can make the function ECHO become the backdoor, just one line!! like this: echo `$_POST[x]`; the quote character is ``, not the '',it is diffrent between ' and `,is it right? i dont know why the `` will equal the function SYSTEM, i test it both on the windows with iis and linux with apache,both of them are work well, however the ECHO function become a hacker's backdoor, if some one use it, the manager hard to find it. Test script: --- Expected result: the ECHO function becomes the SYSTEM function, just one line script. -- Edit bug report at https://bugs.php.net/bug.php?id=64170&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64170&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64170&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64170&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64170&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64170&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64170&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64170&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64170&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64170&r=support Expected behavior: https://bugs.php.net/fix.php?id=64170&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64170&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64170&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64170&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64170&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64170&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64170&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64170&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64170&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64170&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64170&r=mysqlcfg
Bug #64124 [Csd->Fbk]: IPv6 malformed
Edit report at https://bugs.php.net/bug.php?id=64124&edit=1 ID: 64124 Updated by: lytbo...@php.net Reported by:andy at root dot lu Summary:IPv6 malformed -Status: Closed +Status: Feedback Type: Bug Package:SNMP related Operating System: * PHP Version:5.4.* Assigned To:lytboris Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2013-02-07 17:43:56] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=ed6763420c10c5eb47d6db675322ecaa6de079b6 Log: fix bug #64124 (IPv6 malformed) [2013-02-07 17:42:17] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=ed6763420c10c5eb47d6db675322ecaa6de079b6 Log: fix bug #64124 (IPv6 malformed) [2013-02-07 17:36:34] lytbo...@php.net Automatic comment on behalf of lytboris Revision: http://git.php.net/?p=php-src.git;a=commit;h=ed6763420c10c5eb47d6db675322ecaa6de079b6 Log: fix bug #64124 (IPv6 malformed) [2013-02-07 08:01:07] lytbo...@php.net johannes, I found the same bug source an currently I'm in the middle of testing it. ps. I wonder why specifying "s/" in param parsing call is not enough... [2013-02-06 22:11:02] andy at root dot lu Hi, patch went well, but I am getting a segmentation fault while executing the code. I made sure to use make distclean first, so I recompiled everything from scratch. I used the current built: php5.4-201302011830 (which worked with the same test code before I applied the 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 https://bugs.php.net/bug.php?id=64124 -- Edit this bug report at https://bugs.php.net/bug.php?id=64124&edit=1
Bug #64124 [Asn->Csd]: IPv6 malformed
Edit report at https://bugs.php.net/bug.php?id=64124&edit=1
ID: 64124
Updated by: lytbo...@php.net
Reported by:andy at root dot lu
Summary:IPv6 malformed
-Status: Assigned
+Status: Closed
Type: Bug
Package:SNMP related
Operating System: *
PHP Version:5.4.*
Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of lytboris
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=ed6763420c10c5eb47d6db675322ecaa6de079b6
Log: fix bug #64124 (IPv6 malformed)
Previous Comments:
[2013-02-07 08:01:07] lytbo...@php.net
johannes, I found the same bug source an currently I'm in the middle of testing
it.
ps. I wonder why specifying "s/" in param parsing call is not enough...
[2013-02-06 22:11:02] andy at root dot lu
Hi,
patch went well, but I am getting a segmentation fault while executing the code.
I made sure to use make distclean first, so I recompiled everything from
scratch.
I used the current built: php5.4-201302011830 (which worked with the same test
code before I applied the patch)
[2013-02-06 21:48:19] johan...@php.net
Hi Andy,
I don't have an SNMP-enabled device at hand, can you try this patch?
https://github.com/johannes/php-src/compare/bug64124.diff
This should fix the only potential problem explaining this. Thanks.
[2013-02-01 19:12:33] andy at root dot lu
Basically calling snmpget more than once will throw this error.
Code:
$ip = "[2001:abc:dead:beef::22]";
$test = snmpget($ip, "mycommunity", "something");
$test = snmpget($ip, "mycommunity", "something-else");
$test = snmpget($ip, "mycommunity", "something-different");
Throws this error twice:
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php
[2013-02-01 19:03:42] andy at root dot lu
Updated to latest. Problem persists.
I noticed something though:
This code works (only 2 lines):
$ip = "[2001:abc:dead:beef::22]";
$test = snmpget($ip, "mycommunity", "something");
This code does not work and throws the error about missing closing bracket:
$ip = "[2001:abc:dead:beef::22]";
for($j=1;$j<5;$j++)
{
$test = snmpget($ip, "mycommunity", "something".$j);
echo "Outlet $j: $test\n";
}
First iteration of for loop works fine, but after second iteration it complains
about malformed ipv6 address, which does not make any sense. Same issue happens
if
I use a while loop.
OUTPUT:
Outlet 1: 1
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php on line 9
Outlet 2:
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php on line 9
Outlet 3:
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php on line 9
Outlet 4:
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64124
--
Edit this bug report at https://bugs.php.net/bug.php?id=64124&edit=1
Bug #52322 [Com]: webPhar acting like not running in webpage
Edit report at https://bugs.php.net/bug.php?id=52322&edit=1
ID: 52322
Comment by: andycbriggs at gmail dot com
Reported by:myselfasunder at gmail dot com
Summary:webPhar acting like not running in webpage
Status: Open
Type: Bug
Package:PHAR related
Operating System: Windows 7
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
I'm also seeing this bug whilst running Apache.
However I'm using:
$phar->setDefaultStub('cli/console.php', 'web/web.php');
I noticed in the default stub of the phar is the line:
if (@(isset($_SERVER['REQUEST_URI']) && isset($_SERVER['REQUEST_METHOD']) &&
($_SERVER['REQUEST_METHOD'] == 'GET' || $_SERVER['REQUEST_METHOD'] == 'POST'))
If I echo those from console.php I see they are set and that line should pass.
Also makes me point to Phar::webPhar
Tested on PHP 5.4.11, 5.3.21, 5.2.17
The phar was recreated under each version also.
Previous Comments:
[2011-01-22 06:44:53] myselfasunder at gmail dot com
My current system is PHP 5.2.12 under Windows 7. Taking the PECL package from
5.2.6 (because that's the most recent available for 5.2.12), and using the Phar
module, I've executed the following:
var_dump(preg_grep('/web/i', get_class_methods('Phar')));
and got the following matching methods:
array(2) {
[54]=>
string(7) "webPhar"
[125]=>
string(7) "webPhar"
}
Therefore, not only is it available under 5.2.12, it must be available under
5.2.6 as well.
Do you have an actual response to the bug report?
Dustin
[2011-01-22 01:58:15] panman at traileyes dot com
I noticed that you listed the PHP version as 5.2.13. The Phar::webPhar() wasn't
introduced until PHP 5.3.
http://www.php.net/manual/en/phar.webphar.php
[2010-07-12 23:03:03] myselfasunder at gmail dot com
Description:
I'm using an Apache alias to map "/" to my Phar, and the webPhar() call acts as
if it was run from the CLI.
Test script:
---
My setStub() call looks like:
$phar->setStub('https://bugs.php.net/bug.php?id=52322&edit=1
Bug #64146 [Fbk->Opn]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1
ID: 64146
User updated by:slusarz at curecanti dot org
Reported by:slusarz at curecanti dot org
Summary:serialize incorrectly saving objects when they are
cloned
-Status: Feedback
+Status: Open
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
Strange... Since that is the link github provides when you click on "share".
Anyway, try this instead:
https://gist.github.com/slusarz/4709613
Previous Comments:
[2013-02-07 16:05:15] larue...@php.net
the link says: 4709613 hasn't created any public gists yet.
[2013-02-04 21:11:57] slusarz at curecanti dot org
Description:
When using clone in a Serializable serialize() method, the first object is
correctly cloned/saved. However, all subsequent calls to serialize() in the
same script access will have incorrect serialized representations of the cloned
object.
Using var_dump, it appears that clone is reusing the same object ID when the
object is cloned.
I can verify that removing the 'clone' keyword in the test script causes the
script to run correctly.
Test script:
---
https://gist.github.com/4709613
Expected result:
See gist for expected value.
For the record, the serialized value of the A object is as follows:
O:1:"A":1:{s:1:"a";a:2:{i:0;C:1:"B":24:{O:1:"C":1:{s:1:"c";i:1;}}i:1;C:1:"B":4:{r:4;}}}
Actual result:
--
See gist for actual value.
FWIW, running with --enable-debug produces this message:
[Mon Feb 4 14:11:17 2013] Script: '/tmp/test.php'
/disk2/src/php-5.4.11/Zend/zend_vm_execute.h(624) : Freeing 0x7FD6C9C94D78 (32
bytes), script=/tmp/test.php
=== Total 1 memory leaks detected ===
--
Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
Bug #64146 [Opn->Fbk]: serialize incorrectly saving objects when they are cloned
Edit report at https://bugs.php.net/bug.php?id=64146&edit=1
ID: 64146
Updated by: larue...@php.net
Reported by:slusarz at curecanti dot org
Summary:serialize incorrectly saving objects when they are
cloned
-Status: Open
+Status: Feedback
Type: Bug
Package:Variables related
Operating System: Linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
the link says: 4709613 hasn't created any public gists yet.
Previous Comments:
[2013-02-04 21:11:57] slusarz at curecanti dot org
Description:
When using clone in a Serializable serialize() method, the first object is
correctly cloned/saved. However, all subsequent calls to serialize() in the
same script access will have incorrect serialized representations of the cloned
object.
Using var_dump, it appears that clone is reusing the same object ID when the
object is cloned.
I can verify that removing the 'clone' keyword in the test script causes the
script to run correctly.
Test script:
---
https://gist.github.com/4709613
Expected result:
See gist for expected value.
For the record, the serialized value of the A object is as follows:
O:1:"A":1:{s:1:"a";a:2:{i:0;C:1:"B":24:{O:1:"C":1:{s:1:"c";i:1;}}i:1;C:1:"B":4:{r:4;}}}
Actual result:
--
See gist for actual value.
FWIW, running with --enable-debug produces this message:
[Mon Feb 4 14:11:17 2013] Script: '/tmp/test.php'
/disk2/src/php-5.4.11/Zend/zend_vm_execute.h(624) : Freeing 0x7FD6C9C94D78 (32
bytes), script=/tmp/test.php
=== Total 1 memory leaks detected ===
--
Edit this bug report at https://bugs.php.net/bug.php?id=64146&edit=1
Bug #64168 [Opn->Fbk]: Segmentation fault when a Closure ends up in the session data
Edit report at https://bugs.php.net/bug.php?id=64168&edit=1
ID: 64168
Updated by: larue...@php.net
Reported by:rosier at interstroom dot nl
Summary:Segmentation fault when a Closure ends up in the
session data
-Status: Open
+Status: Feedback
Type: Bug
Package:Session related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
I can not reproduce this with 5.4.* , could you please paste the backtrace out?
Previous Comments:
[2013-02-07 09:29:12] rosier at interstroom dot nl
Description:
I can reproduces the segfault with PHP 5.3.21 and PHP 5.4.11
Test script:
---
session_start();
$_SESSION['test'] = function($name) { return strtoupper($name); };
Expected result:
No crash and a error message like "PHP Fatal error: 'Closure' in session data
is not allowed"
Actual result:
--
Blank screen in the browser and the following apache logs:
[Wed Feb 06 12:51:50 2013] [error] [client 192.168.0.xx] PHP Fatal error:
Uncaught exception 'Exception' with message 'Serialization of 'Closure' is not
allowed' in [no active file]:0\nStack trace:\n#0 {main}\n thrown in [no active
file] on line 0
[Wed Feb 06 12:51:51 2013] [notice] child pid 7316 exit signal Segmentation
fault (11)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64168&edit=1
Bug #64135 [Asn->Csd]: Exceptions from set_error_handler are not always propagated
Edit report at https://bugs.php.net/bug.php?id=64135&edit=1
ID: 64135
Updated by: larue...@php.net
Reported by:za_creature at yahoo dot com
Summary:Exceptions from set_error_handler are not always
propagated
-Status: Assigned
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: WOW64, CentOS6.3
PHP Version:5.4.11
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=290509755ac4a3279b2b31b899aa9f2dd780f5f4
Log: Fixed bug #64135 (Exceptions from set_error_handler are not always
propagated)
Previous Comments:
[2013-02-07 14:26:05] larue...@php.net
okey, I will commit it to 5.5 and above
[2013-02-04 08:12:47] dmi...@php.net
I don't see any problems with the patch.
[2013-02-04 07:00:04] larue...@php.net
patch attached, but I think maybe only going into PHP 5.5, this could be
considered a BC break.
what do you think, dmitry? thanks
[2013-02-04 06:56:12] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64135.patch
Revision: 1359960972
URL:
https://bugs.php.net/patch-display.php?bug=64135&patch=bug64135.patch&revision=1359960972
[2013-02-02 16:55:11] za_creature at yahoo dot com
Description:
echo $undefined works
$undefined++ works
$undefined->method() doesn't
Test script:
---
method();
}
catch(Exception $e) {
echo "Exception is thrown";
}
Expected result:
Exception is thrown
Actual result:
--
PHP Warning: Uncaught exception 'Exception' in /home/radu/bug.php:4
Stack trace:
#0 /home/radu/bug.php(9): exception_error_handler(8, 'Undefined varia...',
'/home/radu/bug', 9, Array)
#1 {main}
thrown in /home/radu/bug.php on line 4
Warning: Uncaught exception 'Exception' in /home/radu/bug.php:4
Stack trace:
#0 /home/radu/bug.php(9): exception_error_handler(8, 'Undefined varia...',
'/home/radu/bug', 9, Array)
#1 {main}
thrown in /home/radu/bug.php on line 4
PHP Fatal error: Call to a member function method() on a non-object in
/home/radu/bug.php on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=64135&edit=1
Bug #64152 [Nab->Opn]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1 ID: 64152 Updated by: m...@php.net Reported by:mmicael at gmail dot com Summary:php return wrong string with HEAD Request Method -Status: Not a bug +Status: Open Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.11 -Assigned To: +Assigned To:mike Block user comment: N Private report: N New Comment: Ha, now I understand ;) Yes, this could be a regression. php_output_header() checks headers_only and sets PHP_OUTPUT_DISABLED. This leads to php_output_write() return immediately. Previous Comments: [2013-02-07 15:23:20] mmicael at gmail dot com yes the script continue, but it log 1-test1 2-test1 as we do a second ob_start ob_get_contents with an echo test2, after the echo $string, we should have in the logs 1-test1 2-test1test2 [2013-02-07 15:16:06] m...@php.net Cannot reproduce. I get no output with php-fpm in the response, but in the error_log. [2013-02-07 15:06:21] mmicael at gmail dot com I am using php-fpm [2013-02-07 15:03:38] m...@php.net Which SAPI? Are you sure, you don't see error_log output there? [2013-02-07 14:59:42] mmicael at gmail dot com it's only doing a HEAD request_method with curl -I for exemple in php 5.2 and 5.3, the script is stopped after the echo $string; in php 5.4, he continue bug the ob_get_contents after the echo $string; return empty response The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64152 -- Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64152 [Nab]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1 ID: 64152 User updated by:mmicael at gmail dot com Reported by:mmicael at gmail dot com Summary:php return wrong string with HEAD Request Method Status: Not a bug Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: yes the script continue, but it log 1-test1 2-test1 as we do a second ob_start ob_get_contents with an echo test2, after the echo $string, we should have in the logs 1-test1 2-test1test2 Previous Comments: [2013-02-07 15:16:06] m...@php.net Cannot reproduce. I get no output with php-fpm in the response, but in the error_log. [2013-02-07 15:06:21] mmicael at gmail dot com I am using php-fpm [2013-02-07 15:03:38] m...@php.net Which SAPI? Are you sure, you don't see error_log output there? [2013-02-07 14:59:42] mmicael at gmail dot com it's only doing a HEAD request_method with curl -I for exemple in php 5.2 and 5.3, the script is stopped after the echo $string; in php 5.4, he continue bug the ob_get_contents after the echo $string; return empty response [2013-02-07 14:54:52] m...@php.net I cannot see a bug here, sure execution of the script continues... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64152 -- Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64152 [Opn->Nab]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1 ID: 64152 Updated by: m...@php.net Reported by:mmicael at gmail dot com Summary:php return wrong string with HEAD Request Method -Status: Open +Status: Not a bug Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Cannot reproduce. I get no output with php-fpm in the response, but in the error_log. Previous Comments: [2013-02-07 15:06:21] mmicael at gmail dot com I am using php-fpm [2013-02-07 15:03:38] m...@php.net Which SAPI? Are you sure, you don't see error_log output there? [2013-02-07 14:59:42] mmicael at gmail dot com it's only doing a HEAD request_method with curl -I for exemple in php 5.2 and 5.3, the script is stopped after the echo $string; in php 5.4, he continue bug the ob_get_contents after the echo $string; return empty response [2013-02-07 14:54:52] m...@php.net I cannot see a bug here, sure execution of the script continues... [2013-02-05 13:26:05] mmicael at gmail dot com It's not the same bug the other bug have already been integrated in php 5.4.11 my bug only appears with HEAD request_method The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64152 -- Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64152 [Fbk->Opn]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1 ID: 64152 User updated by:mmicael at gmail dot com Reported by:mmicael at gmail dot com Summary:php return wrong string with HEAD Request Method -Status: Feedback +Status: Open Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: I am using php-fpm Previous Comments: [2013-02-07 15:03:38] m...@php.net Which SAPI? Are you sure, you don't see error_log output there? [2013-02-07 14:59:42] mmicael at gmail dot com it's only doing a HEAD request_method with curl -I for exemple in php 5.2 and 5.3, the script is stopped after the echo $string; in php 5.4, he continue bug the ob_get_contents after the echo $string; return empty response [2013-02-07 14:54:52] m...@php.net I cannot see a bug here, sure execution of the script continues... [2013-02-05 13:26:05] mmicael at gmail dot com It's not the same bug the other bug have already been integrated in php 5.4.11 my bug only appears with HEAD request_method [2013-02-05 13:16:56] yvan at dugwood dot com Seems to be a duplicate of https://bugs.php.net/bug.php?id=61272 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64152 -- Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64152 [Opn->Fbk]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1 ID: 64152 Updated by: m...@php.net Reported by:mmicael at gmail dot com Summary:php return wrong string with HEAD Request Method -Status: Open +Status: Feedback Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Which SAPI? Are you sure, you don't see error_log output there? Previous Comments: [2013-02-07 14:59:42] mmicael at gmail dot com it's only doing a HEAD request_method with curl -I for exemple in php 5.2 and 5.3, the script is stopped after the echo $string; in php 5.4, he continue bug the ob_get_contents after the echo $string; return empty response [2013-02-07 14:54:52] m...@php.net I cannot see a bug here, sure execution of the script continues... [2013-02-05 13:26:05] mmicael at gmail dot com It's not the same bug the other bug have already been integrated in php 5.4.11 my bug only appears with HEAD request_method [2013-02-05 13:16:56] yvan at dugwood dot com Seems to be a duplicate of https://bugs.php.net/bug.php?id=61272 [2013-02-05 11:54:55] mmicael at gmail dot com It seems that the behaviour have change with this commit https://github.com/php/php-src/commit/11d24c1593d6617f73d3f290617bd8994182f4dc# the ouput.c don't care anymore about headers_only The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64152 -- Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64152 [Fbk->Opn]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1 ID: 64152 User updated by:mmicael at gmail dot com Reported by:mmicael at gmail dot com Summary:php return wrong string with HEAD Request Method -Status: Feedback +Status: Open Type: Bug Package:Output Control Operating System: linux PHP Version:5.4.11 Block user comment: N Private report: N New Comment: it's only doing a HEAD request_method with curl -I for exemple in php 5.2 and 5.3, the script is stopped after the echo $string; in php 5.4, he continue bug the ob_get_contents after the echo $string; return empty response Previous Comments: [2013-02-07 14:54:52] m...@php.net I cannot see a bug here, sure execution of the script continues... [2013-02-05 13:26:05] mmicael at gmail dot com It's not the same bug the other bug have already been integrated in php 5.4.11 my bug only appears with HEAD request_method [2013-02-05 13:16:56] yvan at dugwood dot com Seems to be a duplicate of https://bugs.php.net/bug.php?id=61272 [2013-02-05 11:54:55] mmicael at gmail dot com It seems that the behaviour have change with this commit https://github.com/php/php-src/commit/11d24c1593d6617f73d3f290617bd8994182f4dc# the ouput.c don't care anymore about headers_only [2013-02-05 11:00:42] mmicael at gmail dot com Modifiying OS The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64152 -- Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64152 [Opn->Fbk]: php return wrong string with HEAD Request Method
Edit report at https://bugs.php.net/bug.php?id=64152&edit=1
ID: 64152
Updated by: m...@php.net
Reported by:mmicael at gmail dot com
Summary:php return wrong string with HEAD Request Method
-Status: Open
+Status: Feedback
Type: Bug
Package:Output Control
Operating System: linux
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
I cannot see a bug here, sure execution of the script continues...
Previous Comments:
[2013-02-05 13:26:05] mmicael at gmail dot com
It's not the same bug
the other bug have already been integrated in php 5.4.11
my bug only appears with HEAD request_method
[2013-02-05 13:16:56] yvan at dugwood dot com
Seems to be a duplicate of https://bugs.php.net/bug.php?id=61272
[2013-02-05 11:54:55] mmicael at gmail dot com
It seems that the behaviour have change with this commit
https://github.com/php/php-src/commit/11d24c1593d6617f73d3f290617bd8994182f4dc#
the ouput.c don't care anymore about headers_only
[2013-02-05 11:00:42] mmicael at gmail dot com
Modifiying OS
[2013-02-05 10:51:49] mmicael at gmail dot com
Description:
When we do a HEAD Request Method in php 5.4, php continue executing script even
if the output buffer exceed the max output_buffering.
the next ob_start, ob_get_contents always return empty string
In php 5.2 and 5.3, the script die after sending the first output buffer that
reach the max output_buffering.
Test script:
---
$string = '';
for($i=0;$i<5000;$i++) $string .= '0';
ob_start();
echo "test1";
$content = ob_get_contents();
ob_end_clean();
error_log("1-$content");
echo $string;
ob_start();
echo "test2";
$content .= ob_get_contents();
ob_end_clean();
echo $string;
error_log("2-$content");
Expected result:
In php 5.2 and 5.3
1-test1
Actual result:
--
In php 5.4
1-test1
2-test1
--
Edit this bug report at https://bugs.php.net/bug.php?id=64152&edit=1
Bug #64135 [Asn]: Exceptions from set_error_handler are not always propagated
Edit report at https://bugs.php.net/bug.php?id=64135&edit=1
ID: 64135
Updated by: larue...@php.net
Reported by:za_creature at yahoo dot com
Summary:Exceptions from set_error_handler are not always
propagated
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: WOW64, CentOS6.3
PHP Version:5.4.11
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
okey, I will commit it to 5.5 and above
Previous Comments:
[2013-02-04 08:12:47] dmi...@php.net
I don't see any problems with the patch.
[2013-02-04 07:00:04] larue...@php.net
patch attached, but I think maybe only going into PHP 5.5, this could be
considered a BC break.
what do you think, dmitry? thanks
[2013-02-04 06:56:12] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64135.patch
Revision: 1359960972
URL:
https://bugs.php.net/patch-display.php?bug=64135&patch=bug64135.patch&revision=1359960972
[2013-02-02 16:55:11] za_creature at yahoo dot com
Description:
echo $undefined works
$undefined++ works
$undefined->method() doesn't
Test script:
---
method();
}
catch(Exception $e) {
echo "Exception is thrown";
}
Expected result:
Exception is thrown
Actual result:
--
PHP Warning: Uncaught exception 'Exception' in /home/radu/bug.php:4
Stack trace:
#0 /home/radu/bug.php(9): exception_error_handler(8, 'Undefined varia...',
'/home/radu/bug', 9, Array)
#1 {main}
thrown in /home/radu/bug.php on line 4
Warning: Uncaught exception 'Exception' in /home/radu/bug.php:4
Stack trace:
#0 /home/radu/bug.php(9): exception_error_handler(8, 'Undefined varia...',
'/home/radu/bug', 9, Array)
#1 {main}
thrown in /home/radu/bug.php on line 4
PHP Fatal error: Call to a member function method() on a non-object in
/home/radu/bug.php on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=64135&edit=1
[PHP-BUG] Bug #64169 [NEW]: opendir not working with sftp since upgrade from php 5.3.14 to 5.3.21
From: michael dot dalbosco at gmail dot com Operating system: Debian 4.4.5-8 PHP version: 5.3.21 Package: Directory function related Bug Type: Bug Bug description:opendir not working with sftp since upgrade from php 5.3.14 to 5.3.21 Description: --- >From manual page: http://www.php.net/function.opendir#refsect1-function.opendir-description --- I'm connecting to a Sftp server and try to open a directory on this server. It worked fine on php 5.3.10 and php 5.3.14 but since we upgraded to 5.3.21 it doesn't work anymore, opendir returns false. Test script: --- $con = ssh2_connect($server, $port); ssh2_auth_pubkey_file ( $con, $login, $pubKeyFile, $privKeyFile); $sftp = ssh2_sftp($con); $dir = "ssh2.sftp://$sftp/";; var_dump(opendir($dir)); Expected result: the directory resource Actual result: -- false -- Edit bug report at https://bugs.php.net/bug.php?id=64169&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64169&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64169&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64169&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64169&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64169&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64169&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64169&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64169&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64169&r=support Expected behavior: https://bugs.php.net/fix.php?id=64169&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64169&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64169&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64169&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64169&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64169&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64169&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64169&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64169&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64169&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64169&r=mysqlcfg
Req #62065 [Com]: PDO should have a disconnect method
Edit report at https://bugs.php.net/bug.php?id=62065&edit=1 ID: 62065 Comment by: ionut dot stan at hostway dot ro Reported by:b12 at bsdpower dot com Summary:PDO should have a disconnect method Status: Open Type: Feature/Change Request Package:PDO related Operating System: Any PHP Version:5.3.13 Block user comment: N Private report: N New Comment: On a billing application the recurring services run on separate and consecutive transactions, so in case one fails with error the others are not blocked. At some point an error did occur (sooner or later it has to happen) - some data anomaly caused by some upgrade which didn't consider some scenario, and the application throws when it catches it. The uncommited transaction for the PDO object which will not be commited because of some assertion failure (app specific, not PDO related) was deadlocking future transactions. It would be nice if the PDO object could be disconnected *for sure*. The variable was already beeing unset before reuse, yet that was not enough. This doesn't like a big deal, I'm sure it can be done. Even without exception mode, a disconnected PDO object can happen (internet drops, MySQL dies, etc.), so that is not an argument against implementing a disconnect method. Previous Comments: [2012-05-18 20:26:16] b12 at bsdpower dot com Description: Currently the advertised way of having pdo disconnect from the database is to assign "null" to the pdo handle. This may work acceptably well in tutorials, however in real life this approach is impractical. When testing with, say, phpunit (dbunit), the setup code creates a connection and gives a pdo instance to phpunit. What phpunit subsequently does with that instance and in particular how many times the pdo variable is copied and assigned to cyclical and/or permanently referenced structures, is not something that connection management code can control. Example code from phpbb: https://github.com/phpbb/phpbb3/blob/develop/tests/test_framework/phpbb_database_test_connection_manager.php#L38 - connect function is called by phpunit. Currently in phpbb tests the database connections are not closed by pdo. This requires for example postgresql and oracle databases to be configured to allow more concurrent database connections than we have tests in the test suite. You might be tempted to say that it's phpunit's fault for not closing database connections, or there is a bug in phpbb test code which results in connections not being closed. Consider how such a bug might be found. If I close a connection when I think it should no longer be used, and subsequently it is used, I will receive an error pointing to the responsible party. How would you diagnose the same bug if there is no way to close a database connection explicitly? Not to mention that disconnecting from the database is a core operation of any sane db api. There is no need to change existing behavior of connection closing on finalization. The disconnect method should be in addition to existing functionality. Expected result: PDO should provide a method on connections to disconnect from the database. -- Edit this bug report at https://bugs.php.net/bug.php?id=62065&edit=1
[PHP-BUG] Bug #64168 [NEW]: Segmentation fault when a Closure ends up in the session data
From: rosier at interstroom dot nl
Operating system:
PHP version: Irrelevant
Package: Session related
Bug Type: Bug
Bug description:Segmentation fault when a Closure ends up in the session data
Description:
I can reproduces the segfault with PHP 5.3.21 and PHP 5.4.11
Test script:
---
session_start();
$_SESSION['test'] = function($name) { return strtoupper($name); };
Expected result:
No crash and a error message like "PHP Fatal error: 'Closure' in session
data is not allowed"
Actual result:
--
Blank screen in the browser and the following apache logs:
[Wed Feb 06 12:51:50 2013] [error] [client 192.168.0.xx] PHP Fatal error:
Uncaught exception 'Exception' with message 'Serialization of 'Closure' is
not allowed' in [no active file]:0\nStack trace:\n#0 {main}\n thrown in
[no active file] on line 0
[Wed Feb 06 12:51:51 2013] [notice] child pid 7316 exit signal Segmentation
fault (11)
--
Edit bug report at https://bugs.php.net/bug.php?id=64168&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64168&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64168&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64168&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64168&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64168&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64168&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64168&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64168&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64168&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64168&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64168&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64168&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64168&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64168&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64168&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64168&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64168&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64168&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64168&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64168&r=mysqlcfg
Bug #64124 [Asn]: IPv6 malformed
Edit report at https://bugs.php.net/bug.php?id=64124&edit=1
ID: 64124
Updated by: lytbo...@php.net
Reported by:andy at root dot lu
Summary:IPv6 malformed
Status: Assigned
Type: Bug
Package:SNMP related
-Operating System: Debian Squeeze
+Operating System: *
-PHP Version:5.4.11
+PHP Version:5.4.*
Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
johannes, I found the same bug source an currently I'm in the middle of testing
it.
ps. I wonder why specifying "s/" in param parsing call is not enough...
Previous Comments:
[2013-02-06 22:11:02] andy at root dot lu
Hi,
patch went well, but I am getting a segmentation fault while executing the code.
I made sure to use make distclean first, so I recompiled everything from
scratch.
I used the current built: php5.4-201302011830 (which worked with the same test
code before I applied the patch)
[2013-02-06 21:48:19] johan...@php.net
Hi Andy,
I don't have an SNMP-enabled device at hand, can you try this patch?
https://github.com/johannes/php-src/compare/bug64124.diff
This should fix the only potential problem explaining this. Thanks.
[2013-02-01 19:12:33] andy at root dot lu
Basically calling snmpget more than once will throw this error.
Code:
$ip = "[2001:abc:dead:beef::22]";
$test = snmpget($ip, "mycommunity", "something");
$test = snmpget($ip, "mycommunity", "something-else");
$test = snmpget($ip, "mycommunity", "something-different");
Throws this error twice:
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php
[2013-02-01 19:03:42] andy at root dot lu
Updated to latest. Problem persists.
I noticed something though:
This code works (only 2 lines):
$ip = "[2001:abc:dead:beef::22]";
$test = snmpget($ip, "mycommunity", "something");
This code does not work and throws the error about missing closing bracket:
$ip = "[2001:abc:dead:beef::22]";
for($j=1;$j<5;$j++)
{
$test = snmpget($ip, "mycommunity", "something".$j);
echo "Outlet $j: $test\n";
}
First iteration of for loop works fine, but after second iteration it complains
about malformed ipv6 address, which does not make any sense. Same issue happens
if
I use a while loop.
OUTPUT:
Outlet 1: 1
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php on line 9
Outlet 2:
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php on line 9
Outlet 3:
Warning: snmpget(): malformed IPv6 address, closing square bracket missing in
test.php on line 9
Outlet 4:
[2013-02-01 11:28:01] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Works for me (Warning: snmpget(): Invalid object identifier: something in - on
line 3) and code looks correct, too.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64124
--
Edit this bug report at https://bugs.php.net/bug.php?id=64124&edit=1
