#30615 [Com]: Fatal error: Call to undefined function: onselect()
ID: 30615 Comment by: soltansa at hotmail dot com Reported By: dmitryseliv at yahoo dot com Status: No Feedback Bug Type: Class/Object related Operating System: Red Hat Linux PHP Version: 4.3.9 New Comment: http://www.vbulletin.com | http://www.vbulletin.com/license.html # || || || \*==*/ /*---*\ | ** NOTE REGARDING THE VARIABLES IN THIS FILE ** | +-+ | If you get any errors while attempting to connect to | | MySQL, you will need to email your webhost because we | | cannot tell you the correct values for the variables | | in this file. | \*---*/ // ** DATABASE SERVER NAME ** // This is the hostname or IP address of the database server. // It is in the format HOST:PORT. If no PORT is specified, 3306 is used. // If you are unsure of what to put here, leave it at the default value. $servername = 'mysql53.secureserver.net'; // ** DATABASE USERNAME & PASSWORD ** // This is the username and password you use to access MySQL. // These must be obtained through your webhost. $dbusername = 'ars2005'; $dbpassword = 's16451645s'; // ** DATABASE NAME ** // This is the name of the database where your vBulletin will be located. // This must be created by your webhost. $dbname = 'ars2005'; // ** TECHNICAL EMAIL ADDRESS ** // If any database errors occur, they will be emailed to the address specified here. // Leave this blank to not send any emails when there is a database error. $technicalemail = '[EMAIL PROTECTED]'; // ** PERSISTENT CONNECTIONS ** // This option allows you to turn persistent connections to MySQL on or off. // The difference in performance is negligible for all but the largest boards. // If you are unsure what this should be, leave it off. // 0 = Off; 1 = On $usepconnect = 0; // ** PATH TO ADMIN & MODERATOR CONTROL PANELS ** // This setting allows you to change the name of the folders that the admin and // moderator control panels reside in. You may wish to do this for security purposes. // Please note that if you change the name of the directory here, you will still need // to manually change the name of the directory on the server. $admincpdir = 'admincp'; $modcpdir = 'modcp'; // ** USERS WITH ADMIN LOG VIEWING PERMISSIONS ** // The users specified here will be allowed to view the admin log in the control panel. // Users must be specified by *ID number* here. To obtain a user's ID number, // view their profile via the control panel. If this is a new installation, leave // the first user created will have a user ID of 1. Seperate each userid with a comma. $canviewadminlog = '1'; // ** USERS WITH ADMIN LOG PRUNING PERMISSIONS ** // The users specified here will be allowed to remove ("prune") entries from the admin // log. See the above entry for more information on the format. $canpruneadminlog = '1'; // ** USERS WITH QUERY RUNNING PERMISSIONS ** // The users specified here will be allowed to run queries from the control panel. // See the above entries for more information on the format. // Please note that the ability to run queries is quite powerful. You may wish // to remove all user IDs from this list for security reasons. $canrunqueries = ''; // ** UNDELETABLE / UNALTERABLE USERS ** // The users specified here will not be deletable or alterable from the control panel by any users. // To specify more than one user, separate userids with commas. $undeletableusers = ''; // ** SUPER ADMINISTRATORS ** // The users specified below will have permission to access the administrator permissions // page, which controls the permissions of other administrators $superadministrators = ''; // Prefix that your vBulletin tables have in the database. // For example: $tableprefix = 'vb3_'; $tableprefix = ''; // Prefix that all vBulletin cookies will have // For example $cookieprefix = 'bb'; /*==*\ || || # Downloaded: 20:46, Thu Jul 28th 2005 || # CVS: $RCSfile: config.php.new,v $ - $Revision: 1.19 $ || \*==*/ ?> Previous Comments: [2004-11-07 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ---
#36084 [Com]: apache2 segfaults on phpinfo()
ID: 36084 Comment by: yvovandoorn at comcast dot net Reported By: clive at darkarts dot co dot za Status: No Feedback Bug Type: Reproducible crash Operating System: FreeBSD PHP Version: 5.1.2 New Comment: I recompiled pecl-imagick on both machines and it still doesn't work. I did make deinstall -> make clean -> make install. Error message: php -i ... imagick ImageMagick support => enabled Magick Backend => ImageMagick ImageMagick version => 6.2.5 PHP imagick version => 0.9.11 MaxRGB => 65535 Supported image formats => 8BIM php in free(): error: junk pointer, too high to make sense Abort (core dumped) Previous Comments: [2006-02-05 10:59:29] ale at FreeBSD dot org Have you recompiled pecl-imagick after php update? I have no problems: %php -v PHP 5.1.2 (cli) (built: Jan 30 2006 17:07:55) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies %php -i ... imagick ImageMagick support => enabled Magick Backend => ImageMagick ImageMagick version => 6.2.5 PHP imagick version => 0.9.11 MaxRGB => 65535 Supported image formats => 8BIM Font Family - Name => AvantGarde - AvantGarde-Book ... [2006-02-05 07:13:08] yvovandoorn at comcast dot net I'm pretty sure this isn't related to Apache2. The reason why is that I am experiencing this problem on two machines, one installed with FreeBSD 5.4 and the other FreeBSD 6.0. The only thing these two have in common is that I installed all my additional applications via the ports. On both machines the problem goes away the moment I disable the imagemagick extension. Yes both machines are running Apache2, however this problem appeared before php 5.1.2, but sometime a week after the new year. Since I strongly believe that the imagick extension is the cause of it, I did some checking and found out the port was upgraded for pecl-imagick on 01/05/06 so I'm pretty sure thats where the issue lies. I've contacted the maintainer for that port (and strangely he also maintains php5 & php5-extensions). [2006-02-03 12:20:50] mail at skraemer dot net This might help you: I ran into the same problem, and the error dissapeared when i commented out the "ImageMagick"-extension in my "exentsions.ini" (FreeBSD-system). If you need detailed informations about the cofiguration- / compiling-process, please send me an e-mail. [2006-01-28 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-01-27 01:06:31] engin at turk-php dot com i was having the same issue on same os and same php version but i didnt try to re-compile with different configure options coz in the previous php-5.0.5 with ZEND Debugger i faced with similar bug , seg fault, when i removed the Zend Debugger module it was working fine, ( on FreeBSD 4.11 - apache 1.3 ) recently i upgrade my os to FreeBSD-6.0 - apache 2.2 - php 5.1.2 with trial and error method i found imagick and recode modules cause issue [Thu Jan 27 02:04:12 2006] [notice] child pid 5968 exit signal Abort trap (6) httpd in free(): error: junk pointer, too high to make sense 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/36084 -- Edit this bug report at http://bugs.php.net/?id=36084&edit=1
#36299 [Opn->Bgs]: PHP 5.1.2 doesn't compile as cgi-fcgi while 5.1.1 does - with same ./configure
ID: 36299 Updated by: [EMAIL PROTECTED] Reported By: mfurdyk at takingitglobal dot org -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: RH EL 4 PHP Version: 5.1.2 New Comment: You probably forgot "make install" Previous Comments: [2006-02-05 23:15:21] mfurdyk at takingitglobal dot org Description: After compiling PHP 5.1.2 with the exact same configuration as 5.1.1, it compiles as cli instead of cgi-fcgi! PHP 5.1.2 (cli) (built: Feb 5 2006 16:56:15) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies with Zend Extension Manager v1.0.9, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v2.6.2, Copyright (c) 1998-2006, by Zend Technologies [EMAIL PROTECTED] bin]# ./php-5.1.1 -v PHP 5.1.1 (cgi-fcgi) (built: Jan 11 2006 01:41:47) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2005 Zend Technologies with Zend Extension Manager v1.0.9, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v2.6.2, Copyright (c) 1998-2006, by Zend Technologies Reproduce code: --- './configure' '--with-mysql=/usr/local/mysql-4.1.12' '--with-zlib' '--with-gd' '--with-jpeg-dir=/opt' '--with-png-dir=/usr/local/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-zend-multibyte' '--enable-fastcgi' '--enable-mbstring' --with-pspell Expected result: 5.1.2 should compile as fcgi! Actual result: -- Compiles as 'cli' -- Edit this bug report at http://bugs.php.net/?id=36299&edit=1
#36299 [NEW]: PHP 5.1.2 doesn't compile as cgi-fcgi while 5.1.1 does - with same ./configure
From: mfurdyk at takingitglobal dot org Operating system: RH EL 4 PHP version: 5.1.2 PHP Bug Type: *Compile Issues Bug description: PHP 5.1.2 doesn't compile as cgi-fcgi while 5.1.1 does - with same ./configure Description: After compiling PHP 5.1.2 with the exact same configuration as 5.1.1, it compiles as cli instead of cgi-fcgi! PHP 5.1.2 (cli) (built: Feb 5 2006 16:56:15) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies with Zend Extension Manager v1.0.9, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v2.6.2, Copyright (c) 1998-2006, by Zend Technologies [EMAIL PROTECTED] bin]# ./php-5.1.1 -v PHP 5.1.1 (cgi-fcgi) (built: Jan 11 2006 01:41:47) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2005 Zend Technologies with Zend Extension Manager v1.0.9, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v2.6.2, Copyright (c) 1998-2006, by Zend Technologies Reproduce code: --- './configure' '--with-mysql=/usr/local/mysql-4.1.12' '--with-zlib' '--with-gd' '--with-jpeg-dir=/opt' '--with-png-dir=/usr/local/lib' '--enable-inline-optimization' '--with-curl' '--disable-debug' '--with-mcrypt=/usr/local/src/libmcrypt-2.5.7' '--with-mhash' '--enable-ftp' '--enable-zend-multibyte' '--enable-fastcgi' '--enable-mbstring' --with-pspell Expected result: 5.1.2 should compile as fcgi! Actual result: -- Compiles as 'cli' -- Edit bug report at http://bugs.php.net/?id=36299&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36299&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36299&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36299&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36299&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36299&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36299&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36299&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36299&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36299&r=support Expected behavior:http://bugs.php.net/fix.php?id=36299&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36299&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36299&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36299&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36299&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36299&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36299&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36299&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36299&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36299&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36299&r=mysqlcfg
#36297 [Csd->Bgs]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Closed +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 Previous Comments: [2006-02-05 22:02:13] smartgenius1 at yahoo dot com Aaah ok. I see "The special value . indicates that the working directory of the script will be used as the base-directory. This is, however, a little dangerous as the working directory of the script can easily be changed with chdir()." I am very sorry if I seemed to cause any problems. I have looked at that before; but just overlooked that. Mistake. Sorry again Closed [2006-02-05 22:00:29] [EMAIL PROTECTED] "The restriction specified with open_basedir is actually a prefix, not a directory name." (c) [2006-02-05 21:54:25] judas dot iscariote at gmail dot com smartgenius1: can you RTFM please ? http://php.net/manual/en/features.safe-mode.php#ini.open-basedir you **should** use absolute paths ¡¡¡ i.e open_basedir = /path/to/your/data/ [2006-02-05 21:33:27] smartgenius1 at yahoo dot com Ah well. The least you guys should do is put up a warning on the chdir() page that Windows does not have UIDs. [2006-02-05 21:26:04] smartgenius1 at yahoo dot com This bug is NOT bogus. The support here will just not take the time to read what I am trying to say. chdir() should check the open_basedir restriction. It doesnt. I was able to get into my friends computer, because he believed that the open_basedir restriction and safe_mode would prevent people from accessing his files. This function did not follow the open_basedir restriction and let me get into his system files. Anybody that is thinking about hosting or letting other people use PHP on their windows computer... they need to know about this. This is not a bogus bug. This is a very critical bug; but nobody will take the time to read through it. I guess its OK that tons of windows users trust the open_basedir restriction enough to think that this type of thing cannot happen. Boy wont they be in a surprise when somebody uses this exploit and erases their entire computer. Good day. ~Sean 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Bgs->Csd]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com -Status: Bogus +Status: Closed Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: Aaah ok. I see "The special value . indicates that the working directory of the script will be used as the base-directory. This is, however, a little dangerous as the working directory of the script can easily be changed with chdir()." I am very sorry if I seemed to cause any problems. I have looked at that before; but just overlooked that. Mistake. Sorry again Closed Previous Comments: [2006-02-05 22:00:29] [EMAIL PROTECTED] "The restriction specified with open_basedir is actually a prefix, not a directory name." (c) [2006-02-05 21:54:25] judas dot iscariote at gmail dot com smartgenius1: can you RTFM please ? http://php.net/manual/en/features.safe-mode.php#ini.open-basedir you **should** use absolute paths ¡¡¡ i.e open_basedir = /path/to/your/data/ [2006-02-05 21:33:27] smartgenius1 at yahoo dot com Ah well. The least you guys should do is put up a warning on the chdir() page that Windows does not have UIDs. [2006-02-05 21:26:04] smartgenius1 at yahoo dot com This bug is NOT bogus. The support here will just not take the time to read what I am trying to say. chdir() should check the open_basedir restriction. It doesnt. I was able to get into my friends computer, because he believed that the open_basedir restriction and safe_mode would prevent people from accessing his files. This function did not follow the open_basedir restriction and let me get into his system files. Anybody that is thinking about hosting or letting other people use PHP on their windows computer... they need to know about this. This is not a bogus bug. This is a very critical bug; but nobody will take the time to read through it. I guess its OK that tons of windows users trust the open_basedir restriction enough to think that this type of thing cannot happen. Boy wont they be in a surprise when somebody uses this exploit and erases their entire computer. Good day. ~Sean [2006-02-05 20:45:46] smartgenius1 at yahoo dot com Sir, you must not be reading it correctly. I have open_basedir set to "."; which should only allow functions to access files in the current directory and under. I am able to change the directory to an above directory with chdir(); that is NOT a file in the cwd or lower. I can have a script working in System/Files/script.php with open_basedir set to "."; I cannot do include("../anyfile.php"); file("../anyfile.php"); or any other thing that access the above directory... so why can I do chdir("../"); include("anyfile.php"); ? The chdir() function should check to make sure that the directory argument is within the allowed paths of open_basedir; which it doesnt. Hope this clarifys my concern. ~Sean 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Opn->Bgs]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: "The restriction specified with open_basedir is actually a prefix, not a directory name." (c) Previous Comments: [2006-02-05 21:54:25] judas dot iscariote at gmail dot com smartgenius1: can you RTFM please ? http://php.net/manual/en/features.safe-mode.php#ini.open-basedir you **should** use absolute paths ¡¡¡ i.e open_basedir = /path/to/your/data/ [2006-02-05 21:33:27] smartgenius1 at yahoo dot com Ah well. The least you guys should do is put up a warning on the chdir() page that Windows does not have UIDs. [2006-02-05 21:26:04] smartgenius1 at yahoo dot com This bug is NOT bogus. The support here will just not take the time to read what I am trying to say. chdir() should check the open_basedir restriction. It doesnt. I was able to get into my friends computer, because he believed that the open_basedir restriction and safe_mode would prevent people from accessing his files. This function did not follow the open_basedir restriction and let me get into his system files. Anybody that is thinking about hosting or letting other people use PHP on their windows computer... they need to know about this. This is not a bogus bug. This is a very critical bug; but nobody will take the time to read through it. I guess its OK that tons of windows users trust the open_basedir restriction enough to think that this type of thing cannot happen. Boy wont they be in a surprise when somebody uses this exploit and erases their entire computer. Good day. ~Sean [2006-02-05 20:45:46] smartgenius1 at yahoo dot com Sir, you must not be reading it correctly. I have open_basedir set to "."; which should only allow functions to access files in the current directory and under. I am able to change the directory to an above directory with chdir(); that is NOT a file in the cwd or lower. I can have a script working in System/Files/script.php with open_basedir set to "."; I cannot do include("../anyfile.php"); file("../anyfile.php"); or any other thing that access the above directory... so why can I do chdir("../"); include("anyfile.php"); ? The chdir() function should check to make sure that the directory argument is within the allowed paths of open_basedir; which it doesnt. Hope this clarifys my concern. ~Sean [2006-02-05 20:41:55] [EMAIL PROTECTED] What Derick said. 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Com]: Bypass open_basedir on windows
ID: 36297 Comment by: judas dot iscariote at gmail dot com Reported By: smartgenius1 at yahoo dot com Status: Open Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: smartgenius1: can you RTFM please ? http://php.net/manual/en/features.safe-mode.php#ini.open-basedir you **should** use absolute paths ¡¡¡ i.e open_basedir = /path/to/your/data/ Previous Comments: [2006-02-05 21:33:27] smartgenius1 at yahoo dot com Ah well. The least you guys should do is put up a warning on the chdir() page that Windows does not have UIDs. [2006-02-05 21:26:04] smartgenius1 at yahoo dot com This bug is NOT bogus. The support here will just not take the time to read what I am trying to say. chdir() should check the open_basedir restriction. It doesnt. I was able to get into my friends computer, because he believed that the open_basedir restriction and safe_mode would prevent people from accessing his files. This function did not follow the open_basedir restriction and let me get into his system files. Anybody that is thinking about hosting or letting other people use PHP on their windows computer... they need to know about this. This is not a bogus bug. This is a very critical bug; but nobody will take the time to read through it. I guess its OK that tons of windows users trust the open_basedir restriction enough to think that this type of thing cannot happen. Boy wont they be in a surprise when somebody uses this exploit and erases their entire computer. Good day. ~Sean [2006-02-05 20:45:46] smartgenius1 at yahoo dot com Sir, you must not be reading it correctly. I have open_basedir set to "."; which should only allow functions to access files in the current directory and under. I am able to change the directory to an above directory with chdir(); that is NOT a file in the cwd or lower. I can have a script working in System/Files/script.php with open_basedir set to "."; I cannot do include("../anyfile.php"); file("../anyfile.php"); or any other thing that access the above directory... so why can I do chdir("../"); include("anyfile.php"); ? The chdir() function should check to make sure that the directory argument is within the allowed paths of open_basedir; which it doesnt. Hope this clarifys my concern. ~Sean [2006-02-05 20:41:55] [EMAIL PROTECTED] What Derick said. [2006-02-05 20:30:45] smartgenius1 at yahoo dot com I said i can reach UPPER LEVEL directories. (../) Any other file system functions wont let me do that. Just chdir(). 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36298 [Bgs]: Write files without permission
ID: 36298 User updated by: the dot spikey at gmail dot com Reported By: the dot spikey at gmail dot com Status: Bogus Bug Type: Filesystem function related Operating System: At least *nix PHP Version: 4.4.2 New Comment: Originally found by Rein Krul, submitted & commented by Spiked. Previous Comments: [2006-02-05 21:40:42] [EMAIL PROTECTED] 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. If a process writes a file then it definitely has enough privileges to do it, or you should complain to your OS developers. [2006-02-05 21:34:53] the dot spikey at gmail dot com Description: The COPY function can write/read files where you have no permission to. (Maybe in combination with the tempnam function, maybe without). Reproduce code: --- $tempfn = tempnam("",""); $temp = fopen($tempfn, "w"); fwrite ($temp, $newtxt); copy ($tempfn, "mysql.php"); Expected result: Line 1: $tempfn = the created temporary filename. Line 2: Open the temp. file with write access. Line 3: write your text $newtxt in $temp. Line 4: Copy your newly created temporary file over mysql.php, even without write access. Actual result: -- (same as above) Line 1: $tempfn = the created temporary filename. Line 2: Open the temp. file with write access. Line 3: write your text $newtxt in $temp. Line 4: Copy your newly created temporary file over mysql.php, even without write access. -- Edit this bug report at http://bugs.php.net/?id=36298&edit=1
#36298 [Opn->Bgs]: Write files without permission
ID: 36298 Updated by: [EMAIL PROTECTED] Reported By: the dot spikey at gmail dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: At least *nix PHP Version: 4.4.2 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. If a process writes a file then it definitely has enough privileges to do it, or you should complain to your OS developers. Previous Comments: [2006-02-05 21:34:53] the dot spikey at gmail dot com Description: The COPY function can write/read files where you have no permission to. (Maybe in combination with the tempnam function, maybe without). Reproduce code: --- $tempfn = tempnam("",""); $temp = fopen($tempfn, "w"); fwrite ($temp, $newtxt); copy ($tempfn, "mysql.php"); Expected result: Line 1: $tempfn = the created temporary filename. Line 2: Open the temp. file with write access. Line 3: write your text $newtxt in $temp. Line 4: Copy your newly created temporary file over mysql.php, even without write access. Actual result: -- (same as above) Line 1: $tempfn = the created temporary filename. Line 2: Open the temp. file with write access. Line 3: write your text $newtxt in $temp. Line 4: Copy your newly created temporary file over mysql.php, even without write access. -- Edit this bug report at http://bugs.php.net/?id=36298&edit=1
#36298 [NEW]: Write files without permission
From: the dot spikey at gmail dot com Operating system: At least *nix PHP version: 4.4.2 PHP Bug Type: Filesystem function related Bug description: Write files without permission Description: The COPY function can write/read files where you have no permission to. (Maybe in combination with the tempnam function, maybe without). Reproduce code: --- $tempfn = tempnam("",""); $temp = fopen($tempfn, "w"); fwrite ($temp, $newtxt); copy ($tempfn, "mysql.php"); Expected result: Line 1: $tempfn = the created temporary filename. Line 2: Open the temp. file with write access. Line 3: write your text $newtxt in $temp. Line 4: Copy your newly created temporary file over mysql.php, even without write access. Actual result: -- (same as above) Line 1: $tempfn = the created temporary filename. Line 2: Open the temp. file with write access. Line 3: write your text $newtxt in $temp. Line 4: Copy your newly created temporary file over mysql.php, even without write access. -- Edit bug report at http://bugs.php.net/?id=36298&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36298&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36298&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36298&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36298&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36298&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36298&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36298&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36298&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36298&r=support Expected behavior:http://bugs.php.net/fix.php?id=36298&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36298&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36298&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36298&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36298&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36298&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36298&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36298&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36298&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36298&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36298&r=mysqlcfg
#36297 [Bgs->Opn]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com -Status: Bogus +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: Ah well. The least you guys should do is put up a warning on the chdir() page that Windows does not have UIDs. Previous Comments: [2006-02-05 21:26:04] smartgenius1 at yahoo dot com This bug is NOT bogus. The support here will just not take the time to read what I am trying to say. chdir() should check the open_basedir restriction. It doesnt. I was able to get into my friends computer, because he believed that the open_basedir restriction and safe_mode would prevent people from accessing his files. This function did not follow the open_basedir restriction and let me get into his system files. Anybody that is thinking about hosting or letting other people use PHP on their windows computer... they need to know about this. This is not a bogus bug. This is a very critical bug; but nobody will take the time to read through it. I guess its OK that tons of windows users trust the open_basedir restriction enough to think that this type of thing cannot happen. Boy wont they be in a surprise when somebody uses this exploit and erases their entire computer. Good day. ~Sean [2006-02-05 20:45:46] smartgenius1 at yahoo dot com Sir, you must not be reading it correctly. I have open_basedir set to "."; which should only allow functions to access files in the current directory and under. I am able to change the directory to an above directory with chdir(); that is NOT a file in the cwd or lower. I can have a script working in System/Files/script.php with open_basedir set to "."; I cannot do include("../anyfile.php"); file("../anyfile.php"); or any other thing that access the above directory... so why can I do chdir("../"); include("anyfile.php"); ? The chdir() function should check to make sure that the directory argument is within the allowed paths of open_basedir; which it doesnt. Hope this clarifys my concern. ~Sean [2006-02-05 20:41:55] [EMAIL PROTECTED] What Derick said. [2006-02-05 20:30:45] smartgenius1 at yahoo dot com I said i can reach UPPER LEVEL directories. (../) Any other file system functions wont let me do that. Just chdir(). [2006-02-05 20:29:05] [EMAIL PROTECTED] No bug here. 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Bgs]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: This bug is NOT bogus. The support here will just not take the time to read what I am trying to say. chdir() should check the open_basedir restriction. It doesnt. I was able to get into my friends computer, because he believed that the open_basedir restriction and safe_mode would prevent people from accessing his files. This function did not follow the open_basedir restriction and let me get into his system files. Anybody that is thinking about hosting or letting other people use PHP on their windows computer... they need to know about this. This is not a bogus bug. This is a very critical bug; but nobody will take the time to read through it. I guess its OK that tons of windows users trust the open_basedir restriction enough to think that this type of thing cannot happen. Boy wont they be in a surprise when somebody uses this exploit and erases their entire computer. Good day. ~Sean Previous Comments: [2006-02-05 20:45:46] smartgenius1 at yahoo dot com Sir, you must not be reading it correctly. I have open_basedir set to "."; which should only allow functions to access files in the current directory and under. I am able to change the directory to an above directory with chdir(); that is NOT a file in the cwd or lower. I can have a script working in System/Files/script.php with open_basedir set to "."; I cannot do include("../anyfile.php"); file("../anyfile.php"); or any other thing that access the above directory... so why can I do chdir("../"); include("anyfile.php"); ? The chdir() function should check to make sure that the directory argument is within the allowed paths of open_basedir; which it doesnt. Hope this clarifys my concern. ~Sean [2006-02-05 20:41:55] [EMAIL PROTECTED] What Derick said. [2006-02-05 20:30:45] smartgenius1 at yahoo dot com I said i can reach UPPER LEVEL directories. (../) Any other file system functions wont let me do that. Just chdir(). [2006-02-05 20:29:05] [EMAIL PROTECTED] No bug here. [2006-02-05 20:28:27] [EMAIL PROTECTED] And what if you try to set it to the real path instead of "."? I doubt that PHP is able to distinguish "." when you're in /path/1 from "." when you're in "/another/path". 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Bgs]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: Sir, you must not be reading it correctly. I have open_basedir set to "."; which should only allow functions to access files in the current directory and under. I am able to change the directory to an above directory with chdir(); that is NOT a file in the cwd or lower. I can have a script working in System/Files/script.php with open_basedir set to "."; I cannot do include("../anyfile.php"); file("../anyfile.php"); or any other thing that access the above directory... so why can I do chdir("../"); include("anyfile.php"); ? The chdir() function should check to make sure that the directory argument is within the allowed paths of open_basedir; which it doesnt. Hope this clarifys my concern. ~Sean Previous Comments: [2006-02-05 20:41:55] [EMAIL PROTECTED] What Derick said. [2006-02-05 20:30:45] smartgenius1 at yahoo dot com I said i can reach UPPER LEVEL directories. (../) Any other file system functions wont let me do that. Just chdir(). [2006-02-05 20:29:05] [EMAIL PROTECTED] No bug here. [2006-02-05 20:28:27] [EMAIL PROTECTED] And what if you try to set it to the real path instead of "."? I doubt that PHP is able to distinguish "." when you're in /path/1 from "." when you're in "/another/path". [2006-02-05 20:27:52] [EMAIL PROTECTED] Well "." is the current working directory, so ofcourse you can read it then... 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Opn->Bgs]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: What Derick said. Previous Comments: [2006-02-05 20:30:45] smartgenius1 at yahoo dot com I said i can reach UPPER LEVEL directories. (../) Any other file system functions wont let me do that. Just chdir(). [2006-02-05 20:29:05] [EMAIL PROTECTED] No bug here. [2006-02-05 20:28:27] [EMAIL PROTECTED] And what if you try to set it to the real path instead of "."? I doubt that PHP is able to distinguish "." when you're in /path/1 from "." when you're in "/another/path". [2006-02-05 20:27:52] [EMAIL PROTECTED] Well "." is the current working directory, so ofcourse you can read it then... [2006-02-05 20:25:39] smartgenius1 at yahoo dot com I have it set to "." 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Bgs->Opn]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com -Status: Bogus +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: I said i can reach UPPER LEVEL directories. (../) Any other file system functions wont let me do that. Just chdir(). Previous Comments: [2006-02-05 20:29:05] [EMAIL PROTECTED] No bug here. [2006-02-05 20:28:27] [EMAIL PROTECTED] And what if you try to set it to the real path instead of "."? I doubt that PHP is able to distinguish "." when you're in /path/1 from "." when you're in "/another/path". [2006-02-05 20:27:52] [EMAIL PROTECTED] Well "." is the current working directory, so ofcourse you can read it then... [2006-02-05 20:25:39] smartgenius1 at yahoo dot com I have it set to "." [2006-02-05 20:24:48] [EMAIL PROTECTED] What is the value of open_basedir? 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Fbk->Bgs]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Feedback +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: No bug here. Previous Comments: [2006-02-05 20:28:27] [EMAIL PROTECTED] And what if you try to set it to the real path instead of "."? I doubt that PHP is able to distinguish "." when you're in /path/1 from "." when you're in "/another/path". [2006-02-05 20:27:52] [EMAIL PROTECTED] Well "." is the current working directory, so ofcourse you can read it then... [2006-02-05 20:25:39] smartgenius1 at yahoo dot com I have it set to "." [2006-02-05 20:24:48] [EMAIL PROTECTED] What is the value of open_basedir? [2006-02-05 19:13:21] smartgenius1 at yahoo dot com I was also able to unlink() files; and also fwrite() things as well. I had full permissions; as if I was working in ./ and no error ever occured. 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/36297 -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Bgs->Fbk]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Bogus +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: And what if you try to set it to the real path instead of "."? I doubt that PHP is able to distinguish "." when you're in /path/1 from "." when you're in "/another/path". Previous Comments: [2006-02-05 20:27:52] [EMAIL PROTECTED] Well "." is the current working directory, so ofcourse you can read it then... [2006-02-05 20:25:39] smartgenius1 at yahoo dot com I have it set to "." [2006-02-05 20:24:48] [EMAIL PROTECTED] What is the value of open_basedir? [2006-02-05 19:13:21] smartgenius1 at yahoo dot com I was also able to unlink() files; and also fwrite() things as well. I had full permissions; as if I was working in ./ and no error ever occured. [2006-02-05 18:42:07] smartgenius1 at yahoo dot com Description: The function chdir() does NOT obey the open_basedir restriction on windows. Chdir() ONLY checks the UID of the directories; and on Windows there are no UIDs. So it is possible to do chdir("../"); and it works on windows; even if the open_basedir restriction is set to "."; which should be blocking it. And to make sure I had open_basedir restriction configured correctly; I tried this: opendir("../"); and sure enough; an error stating that the restriction was on. Reproduce code: --- Expected result: A PHP error stating that the open_basedir restriction was on Actual result: -- It worked. No errors at all; and I was able to open the directory with opendir(getcwd()); after changing the current working directory to the above directory. -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Opn->Bgs]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Open +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: Well "." is the current working directory, so ofcourse you can read it then... Previous Comments: [2006-02-05 20:25:39] smartgenius1 at yahoo dot com I have it set to "." [2006-02-05 20:24:48] [EMAIL PROTECTED] What is the value of open_basedir? [2006-02-05 19:13:21] smartgenius1 at yahoo dot com I was also able to unlink() files; and also fwrite() things as well. I had full permissions; as if I was working in ./ and no error ever occured. [2006-02-05 18:42:07] smartgenius1 at yahoo dot com Description: The function chdir() does NOT obey the open_basedir restriction on windows. Chdir() ONLY checks the UID of the directories; and on Windows there are no UIDs. So it is possible to do chdir("../"); and it works on windows; even if the open_basedir restriction is set to "."; which should be blocking it. And to make sure I had open_basedir restriction configured correctly; I tried this: opendir("../"); and sure enough; an error stating that the restriction was on. Reproduce code: --- Expected result: A PHP error stating that the open_basedir restriction was on Actual result: -- It worked. No errors at all; and I was able to open the directory with opendir(getcwd()); after changing the current working directory to the above directory. -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Fbk->Opn]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com -Status: Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: I have it set to "." Previous Comments: [2006-02-05 20:24:48] [EMAIL PROTECTED] What is the value of open_basedir? [2006-02-05 19:13:21] smartgenius1 at yahoo dot com I was also able to unlink() files; and also fwrite() things as well. I had full permissions; as if I was working in ./ and no error ever occured. [2006-02-05 18:42:07] smartgenius1 at yahoo dot com Description: The function chdir() does NOT obey the open_basedir restriction on windows. Chdir() ONLY checks the UID of the directories; and on Windows there are no UIDs. So it is possible to do chdir("../"); and it works on windows; even if the open_basedir restriction is set to "."; which should be blocking it. And to make sure I had open_basedir restriction configured correctly; I tried this: opendir("../"); and sure enough; an error stating that the restriction was on. Reproduce code: --- Expected result: A PHP error stating that the open_basedir restriction was on Actual result: -- It worked. No errors at all; and I was able to open the directory with opendir(getcwd()); after changing the current working directory to the above directory. -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [Opn->Fbk]: Bypass open_basedir on windows
ID: 36297 Updated by: [EMAIL PROTECTED] Reported By: smartgenius1 at yahoo dot com -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: What is the value of open_basedir? Previous Comments: [2006-02-05 19:13:21] smartgenius1 at yahoo dot com I was also able to unlink() files; and also fwrite() things as well. I had full permissions; as if I was working in ./ and no error ever occured. [2006-02-05 18:42:07] smartgenius1 at yahoo dot com Description: The function chdir() does NOT obey the open_basedir restriction on windows. Chdir() ONLY checks the UID of the directories; and on Windows there are no UIDs. So it is possible to do chdir("../"); and it works on windows; even if the open_basedir restriction is set to "."; which should be blocking it. And to make sure I had open_basedir restriction configured correctly; I tried this: opendir("../"); and sure enough; an error stating that the restriction was on. Reproduce code: --- Expected result: A PHP error stating that the open_basedir restriction was on Actual result: -- It worked. No errors at all; and I was able to open the directory with opendir(getcwd()); after changing the current working directory to the above directory. -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36295 [Bgs->Csd]: Reflection returns broken parameter name for SplFileObject::flock()
ID: 36295 Updated by: [EMAIL PROTECTED] Reported By: marcus at lastcraft dot com -Status: Bogus +Status: Closed Bug Type: SPL related Operating System: Windows PHP Version: 5.1.2 Previous Comments: [2006-02-05 20:23:55] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Actually there was a typo in parameter name. Fixed in CVS. [2006-02-05 18:35:02] marcus at lastcraft dot com Description: Spurious "]" character on name of "wouldblock" parameter. Reproduce code: --- $reflection = new ReflectionClass('SplFileObject'); print_r($reflection->getMethod('flock')->getParameters()); Expected result: Array ( [0] => ReflectionParameter Object ( [name] => operation ) [1] => ReflectionParameter Object ( [name] => wouldblock ) ) Actual result: -- Array ( [0] => ReflectionParameter Object ( [name] => operation ) [1] => ReflectionParameter Object ( [name] => wouldblock] ) ) -- Edit this bug report at http://bugs.php.net/?id=36295&edit=1
#36295 [Opn->Bgs]: Reflection returns broken parameter name for SplFileObject::flock()
ID: 36295 Updated by: [EMAIL PROTECTED] Reported By: marcus at lastcraft dot com -Status: Open +Status: Bogus Bug Type: SPL related Operating System: Windows PHP Version: 5.1.2 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Actually there was a typo in parameter name. Fixed in CVS. Previous Comments: [2006-02-05 18:35:02] marcus at lastcraft dot com Description: Spurious "]" character on name of "wouldblock" parameter. Reproduce code: --- $reflection = new ReflectionClass('SplFileObject'); print_r($reflection->getMethod('flock')->getParameters()); Expected result: Array ( [0] => ReflectionParameter Object ( [name] => operation ) [1] => ReflectionParameter Object ( [name] => wouldblock ) ) Actual result: -- Array ( [0] => ReflectionParameter Object ( [name] => operation ) [1] => ReflectionParameter Object ( [name] => wouldblock] ) ) -- Edit this bug report at http://bugs.php.net/?id=36295&edit=1
#36296 [Opn->Fbk]: PDOStatement::getColumnMeta death at client lib pgsql 8.1.0
ID: 36296 Updated by: [EMAIL PROTECTED] Reported By: flaboy dot cn at gmail dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: both windows / linux PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-02-05 18:36:09] flaboy dot cn at gmail dot com Description: PDOStatement::getColumnMeta death at client lib pgsql 8.1.0 both in windows and linux/unix Reproduce code: --- query('SELECT COUNT(*) FROM fruit'); $meta = $select->getColumnMeta(0); var_dump($meta); ?> Expected result: array(6) { ["native_type"]=> string(7) "integer" ["flags"]=> array(0) { } ["name"]=> string(8) "COUNT(*)" ["len"]=> int(-1) ["precision"]=> int(0) ["pdo_type"]=> int(2) } Actual result: -- no it's death. when i change back to pgsql lib 8.0.1 it's running very well -- Edit this bug report at http://bugs.php.net/?id=36296&edit=1
#36294 [Fbk]: PHP crashes when exiting
ID: 36294 Updated by: [EMAIL PROTECTED] Reported By: ramesh25 at gmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: NSK-TANDEM PHP Version: 5.1.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-02-05 20:17:49] [EMAIL PROTECTED] Well, I doubt we'll be able to debug it without any information on a such rare platform. [2006-02-05 19:13:31] ramesh25 at gmail dot com there is no gdb. we use a debugger called inspect. [2006-02-05 16:49:39] [EMAIL PROTECTED] Is there some kind of GDB or different debugger? [2006-02-05 16:43:11] ramesh25 at gmail dot com It is HP's Non Stop Kernel.. [2006-02-05 16:26:21] [EMAIL PROTECTED] "NSK-TANDEM"? What OS is that? 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/36294 -- Edit this bug report at http://bugs.php.net/?id=36294&edit=1
#36294 [Opn->Fbk]: PHP crashes when exiting
ID: 36294 Updated by: [EMAIL PROTECTED] Reported By: ramesh25 at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: NSK-TANDEM PHP Version: 5.1.2 New Comment: Well, I doubt we'll be able to debug it without any information on a such rare platform. Previous Comments: [2006-02-05 19:13:31] ramesh25 at gmail dot com there is no gdb. we use a debugger called inspect. [2006-02-05 16:49:39] [EMAIL PROTECTED] Is there some kind of GDB or different debugger? [2006-02-05 16:43:11] ramesh25 at gmail dot com It is HP's Non Stop Kernel.. [2006-02-05 16:26:21] [EMAIL PROTECTED] "NSK-TANDEM"? What OS is that? [2006-02-05 16:23:31] ramesh25 at gmail dot com Description: PHP crashes when it exits Reproduce code: --- php -h Expected result: display command line options Actual result: -- #sapi/cli/php -h Usage: php [options] [-f] [--] [args...] php [options] -r [--] [args...] php [options] [-B ] -R [-E ] [--] [args...] php [options] [-B ] -F [-E ] [--] [args...] php [options] -- [args...] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F Parse and execute for every input line -E Run PHP after processing all input lines -H Hide any passed arguments from external tools. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdin --rf Show information about function . --rc Show information about class . --re Show information about extension . \MRS010.$:1:442:104328200 - *** Run-time Error 034 *** \MRS010.$:1:442:104328200 - Released space not allocated \MRS010.$:1:442:104328200 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:442:104328200 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:442:104328200 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:442:104328200 - module_destructor + 0xB8 (UCr) \MRS010.$:1:442:104328200 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:442:104328200 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:442:104328200 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:442:104328200 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:442:104328200 - main + 0x1D88 (UCr) \MRS010.$:1:442:104328200 - _MAIN + 0x4C (UCr) Unknown Signal #31 # #sapi/cli/php -v PHP 5.1.2 (cli) (built: Feb 5 2006 08:57:08) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies \MRS010.$:1:441:104328712 - *** Run-time Error 034 *** \MRS010.$:1:441:104328712 - Released space not allocated \MRS010.$:1:441:104328712 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:441:104328712 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:441:104328712 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:441:104328712 - module_destructor + 0xB8 (UCr) \MRS010.$:1:441:104328712 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:441:104328712 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:441:104328712 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:441:104328712 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:441:104328712 - main + 0x1D88 (UCr) \MRS010.$:1:441:104328712 - _MAIN + 0x4C (UCr) Unknown Signal #31 # -- Edit this bug report at http://bugs.php.net/?id=36294&edit=1
#36294 [Fbk->Opn]: PHP crashes when exiting
ID: 36294 User updated by: ramesh25 at gmail dot com Reported By: ramesh25 at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: NSK-TANDEM PHP Version: 5.1.2 New Comment: there is no gdb. we use a debugger called inspect. Previous Comments: [2006-02-05 16:49:39] [EMAIL PROTECTED] Is there some kind of GDB or different debugger? [2006-02-05 16:43:11] ramesh25 at gmail dot com It is HP's Non Stop Kernel.. [2006-02-05 16:26:21] [EMAIL PROTECTED] "NSK-TANDEM"? What OS is that? [2006-02-05 16:23:31] ramesh25 at gmail dot com Description: PHP crashes when it exits Reproduce code: --- php -h Expected result: display command line options Actual result: -- #sapi/cli/php -h Usage: php [options] [-f] [--] [args...] php [options] -r [--] [args...] php [options] [-B ] -R [-E ] [--] [args...] php [options] [-B ] -F [-E ] [--] [args...] php [options] -- [args...] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F Parse and execute for every input line -E Run PHP after processing all input lines -H Hide any passed arguments from external tools. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdin --rf Show information about function . --rc Show information about class . --re Show information about extension . \MRS010.$:1:442:104328200 - *** Run-time Error 034 *** \MRS010.$:1:442:104328200 - Released space not allocated \MRS010.$:1:442:104328200 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:442:104328200 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:442:104328200 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:442:104328200 - module_destructor + 0xB8 (UCr) \MRS010.$:1:442:104328200 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:442:104328200 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:442:104328200 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:442:104328200 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:442:104328200 - main + 0x1D88 (UCr) \MRS010.$:1:442:104328200 - _MAIN + 0x4C (UCr) Unknown Signal #31 # #sapi/cli/php -v PHP 5.1.2 (cli) (built: Feb 5 2006 08:57:08) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies \MRS010.$:1:441:104328712 - *** Run-time Error 034 *** \MRS010.$:1:441:104328712 - Released space not allocated \MRS010.$:1:441:104328712 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:441:104328712 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:441:104328712 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:441:104328712 - module_destructor + 0xB8 (UCr) \MRS010.$:1:441:104328712 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:441:104328712 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:441:104328712 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:441:104328712 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:441:104328712 - main + 0x1D88 (UCr) \MRS010.$:1:441:104328712 - _MAIN + 0x4C (UCr) Unknown Signal #31 # -- Edit this bug report at http://bugs.php.net/?id=36294&edit=1
#36297 [Opn]: Bypass open_basedir on windows
ID: 36297 User updated by: smartgenius1 at yahoo dot com Reported By: smartgenius1 at yahoo dot com Status: Open Bug Type: Safe Mode/open_basedir Operating System: Windows PHP Version: 5.1.2 New Comment: I was also able to unlink() files; and also fwrite() things as well. I had full permissions; as if I was working in ./ and no error ever occured. Previous Comments: [2006-02-05 18:42:07] smartgenius1 at yahoo dot com Description: The function chdir() does NOT obey the open_basedir restriction on windows. Chdir() ONLY checks the UID of the directories; and on Windows there are no UIDs. So it is possible to do chdir("../"); and it works on windows; even if the open_basedir restriction is set to "."; which should be blocking it. And to make sure I had open_basedir restriction configured correctly; I tried this: opendir("../"); and sure enough; an error stating that the restriction was on. Reproduce code: --- Expected result: A PHP error stating that the open_basedir restriction was on Actual result: -- It worked. No errors at all; and I was able to open the directory with opendir(getcwd()); after changing the current working directory to the above directory. -- Edit this bug report at http://bugs.php.net/?id=36297&edit=1
#36297 [NEW]: Bypass open_basedir on windows
From: smartgenius1 at yahoo dot com Operating system: Windows PHP version: 5.1.2 PHP Bug Type: Safe Mode/open_basedir Bug description: Bypass open_basedir on windows Description: The function chdir() does NOT obey the open_basedir restriction on windows. Chdir() ONLY checks the UID of the directories; and on Windows there are no UIDs. So it is possible to do chdir("../"); and it works on windows; even if the open_basedir restriction is set to "."; which should be blocking it. And to make sure I had open_basedir restriction configured correctly; I tried this: opendir("../"); and sure enough; an error stating that the restriction was on. Reproduce code: --- Expected result: A PHP error stating that the open_basedir restriction was on Actual result: -- It worked. No errors at all; and I was able to open the directory with opendir(getcwd()); after changing the current working directory to the above directory. -- Edit bug report at http://bugs.php.net/?id=36297&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36297&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36297&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36297&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36297&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36297&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36297&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36297&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36297&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36297&r=support Expected behavior:http://bugs.php.net/fix.php?id=36297&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36297&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36297&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36297&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36297&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36297&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36297&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36297&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36297&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36297&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36297&r=mysqlcfg
#36296 [NEW]: PDOStatement::getColumnMeta death at client lib pgsql 8.1.0
From: flaboy dot cn at gmail dot com Operating system: both windows / linux PHP version: 5.1.2 PHP Bug Type: PDO related Bug description: PDOStatement::getColumnMeta death at client lib pgsql 8.1.0 Description: PDOStatement::getColumnMeta death at client lib pgsql 8.1.0 both in windows and linux/unix Reproduce code: --- query('SELECT COUNT(*) FROM fruit'); $meta = $select->getColumnMeta(0); var_dump($meta); ?> Expected result: array(6) { ["native_type"]=> string(7) "integer" ["flags"]=> array(0) { } ["name"]=> string(8) "COUNT(*)" ["len"]=> int(-1) ["precision"]=> int(0) ["pdo_type"]=> int(2) } Actual result: -- no it's death. when i change back to pgsql lib 8.0.1 it's running very well -- Edit bug report at http://bugs.php.net/?id=36296&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36296&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36296&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36296&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36296&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36296&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36296&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36296&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36296&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36296&r=support Expected behavior:http://bugs.php.net/fix.php?id=36296&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36296&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36296&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36296&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36296&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36296&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36296&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36296&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36296&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36296&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36296&r=mysqlcfg
#36295 [NEW]: Reflection returns broken parameter name for SplFileObject::flock()
From: marcus at lastcraft dot com Operating system: Windows PHP version: 5.1.2 PHP Bug Type: SPL related Bug description: Reflection returns broken parameter name for SplFileObject::flock() Description: Spurious "]" character on name of "wouldblock" parameter. Reproduce code: --- $reflection = new ReflectionClass('SplFileObject'); print_r($reflection->getMethod('flock')->getParameters()); Expected result: Array ( [0] => ReflectionParameter Object ( [name] => operation ) [1] => ReflectionParameter Object ( [name] => wouldblock ) ) Actual result: -- Array ( [0] => ReflectionParameter Object ( [name] => operation ) [1] => ReflectionParameter Object ( [name] => wouldblock] ) ) -- Edit bug report at http://bugs.php.net/?id=36295&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36295&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36295&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36295&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36295&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36295&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36295&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36295&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36295&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36295&r=support Expected behavior:http://bugs.php.net/fix.php?id=36295&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36295&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36295&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36295&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36295&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36295&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36295&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36295&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36295&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36295&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36295&r=mysqlcfg
#36197 [Opn->Bgs]: php does not free script memory when the process alive
ID: 36197 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: gentoo 2005.1 PHP Version: 5.1.2 New Comment: Once PHP frees memory it is now up to the OS to make this memory available to other process. Memory managers on some OSes like Linux try to anticipate future use of memory by the same process and do not immidiately make the memory available. This however is no fault of PHP, nor is something PHP can do anything about. Previous Comments: [2006-02-02 15:21:47] [EMAIL PROTECTED] Good answer to another question. No, i don't won't to restrict the memory usage. i want use huge arrays and i also want the php to free the memory it use on the end of script. If that is not possible for some reason, please mark this bug as "won't fix" not bogus. [2006-02-02 15:05:29] [EMAIL PROTECTED] if you want to restrict memory usage use the memory-limit configuration option when compiling PHP. [2006-02-02 09:19:20] [EMAIL PROTECTED] Thank for the replay, but please read my question carefully. I know that php free the allocated by emalloc memory on the end of script, my question was why php don't do it for the memory that was allocated by the *php end user* just like the example i give above. Yes you can call it feature, and blame linux mm, but the fact that php do it for the memory used by the extensions developers, give me a hint that may there is simple way protecting the end user to not kill his server as well, especially when we talk about linux+apache 1.3.x that AFAIK it the most common configuration of production php web servers. (sorry for opening the bug again, if you will change the status of the bug to 'will not fix', i'll let him die) [2006-01-31 16:12:08] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php PHP uses an internal memory memory manager, when you allocate memory using emalloc() it'll be freed at the end of the request, even if you don't free it explicitly yourself. [2006-01-30 12:24:33] [EMAIL PROTECTED] My apology of being nagger but the bellow code, use memory (even without inner free) that become free right after the script execution ending. is there a problem to get back the php varibles memory, just like the efree do? PHP_FUNCTION(momo_test) { char *some_memory; int a; some_memory = (char *) emalloc(0x400); for(a=0;a<0x400;a++) some_memory[a]=0; //efree(some_memory); } Can you send me more exact reference how the linux memory allocation responsible for this spend memory? 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/36197 -- Edit this bug report at http://bugs.php.net/?id=36197&edit=1
#29878 [Bgs->Csd]: ImageCreateFromJpeg returns 'not a valid jpeg file'
ID: 29878 Updated by: [EMAIL PROTECTED] Reported By: cyleriggs at kc dot rr dot com -Status: Bogus +Status: Closed Bug Type: GD related Operating System: Linux 2.6.8.1 PHP Version: 5.0.1 Assigned To: pajoye New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. You can now allow the jpeg decoder to be more tolerant/weak: error_reporting(E_ALL); // 0 is the current behavior ini_set('gd.jpeg_ignore_warning', 1); $im = imagecreatefromjpeg($file); Php 5.1.3+ will contain the fix. Previous Comments: [2004-10-12 17:23:26] paul at gslip dot com Has anyone at php verified that the images are corrupt? In what way are they corrupt? Here's what I know: 1- These images were supported with no issues whatsoever before I 'upgraded' to php 5.x 2- Every other piece of software I own, including Windows Image Viewer, Photoshop, Paint, IE, Netscape, Imagemagick, etc. open the files with no complaint. 3- A visual inspection of the files on the byte level show nothing out of the ordinary. That all leads me to believe that the images are not corrupt and that PHP or GD has a bug. Please, stop being so stubborn and at least look at the problem. I can show you hundreds of examples of where this is happening on the web. Just do a google search for 'is not a valid JPEG file in' to see for yourselves how many sites are having this issue. I suspect there's some new twist on the JPEG format that new digital cameras are using ,or something along those lines, that GD and PHP just aren't yet up to speed with. Let's get this solved folks. [2004-10-07 09:12:21] [EMAIL PROTECTED] Corrupted files are invalid, and may crash an application if attempted to use. That's why we will not implement that. (Actually, it's not a PHP issue either, it has to do with how libgd handles opening files). [2004-10-07 03:18:23] cyleriggs at kc dot rr dot com Okay, so how about a feature suggestion than, i think that there should be the option in GD that allows you to try and open images that have a few corrupted bytes. If other programs can open them just fine what would be the harm in allowing programmers to choose to live with the corruptions? [2004-10-05 09:33:47] [EMAIL PROTECTED] PHP only reads non-coprrupted files - there is no bug here. [2004-10-05 04:34:39] cyleriggs at kc dot rr dot com After playing around with the images themselves i have found that converting them from jpeg to png then back to jpeg fixed the problem and yielded no quality loss. I used the linux tool set called ImageMagick to do this. I wrote a short perl script to go through all my images and fix them. Other than this i have found no other way of stopping this. one interesting fact though is that while converting the images with the imagemagick utility it complained about some corruptions, however it was still able to open them fine and convert them. Maybe PHP is being too picky about the images that it opens as despite a few corrupted bytes EVERYthing was able to open these images except for PHP. 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/29878 -- Edit this bug report at http://bugs.php.net/?id=29878&edit=1
#36289 [WFx->Opn]: Implement SplBinaryFileObject
ID: 36289 Updated by: [EMAIL PROTECTED] -Summary: SplFileObject needs fread() Reported By: robertpaul at gmail dot com -Status: Wont fix +Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.1.2 Assigned To: helly New Comment: Yes, maybe we can implement a SplBinaryFileObject class. That would have all those functions. Actually an interesting idea. Previous Comments: [2006-02-05 16:52:03] robertpaul at gmail dot com I see ... thanks for the quick reply. So is it fair to say, then, that SplFileObject isn't suitable for reading a binary file? Thanks again, --Rob [2006-02-05 12:54:56] [EMAIL PROTECTED] SplFileObject is a line iterator, that is it reads the next line on current() and friends. Introducing fread would mean one would need to cound the '\n's after reading some bytes. That said it would be ok to read the remainder as from the object since then valid() would return true and the number of lines wouldn't matter. An alternative would be allowing to skip line counting. However right now fread() in its current forma does not make sense. [2006-02-05 00:32:23] robertpaul at gmail dot com Description: Please forgive me if I'm missing something, but it seems as though SplFileObject has most of the useful file functions except fread. Having that available would be Really Good. Thanks! -- Edit this bug report at http://bugs.php.net/?id=36289&edit=1
#36289 [WFx]: SplFileObject needs fread()
ID: 36289 User updated by: robertpaul at gmail dot com Reported By: robertpaul at gmail dot com Status: Wont fix Bug Type: Feature/Change Request Operating System: * PHP Version: 5.1.2 Assigned To: helly New Comment: I see ... thanks for the quick reply. So is it fair to say, then, that SplFileObject isn't suitable for reading a binary file? Thanks again, --Rob Previous Comments: [2006-02-05 12:54:56] [EMAIL PROTECTED] SplFileObject is a line iterator, that is it reads the next line on current() and friends. Introducing fread would mean one would need to cound the '\n's after reading some bytes. That said it would be ok to read the remainder as from the object since then valid() would return true and the number of lines wouldn't matter. An alternative would be allowing to skip line counting. However right now fread() in its current forma does not make sense. [2006-02-05 00:32:23] robertpaul at gmail dot com Description: Please forgive me if I'm missing something, but it seems as though SplFileObject has most of the useful file functions except fread. Having that available would be Really Good. Thanks! -- Edit this bug report at http://bugs.php.net/?id=36289&edit=1
#36294 [Opn->Fbk]: PHP crashes when exiting
ID: 36294 Updated by: [EMAIL PROTECTED] Reported By: ramesh25 at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: NSK-TANDEM PHP Version: 5.1.2 New Comment: Is there some kind of GDB or different debugger? Previous Comments: [2006-02-05 16:43:11] ramesh25 at gmail dot com It is HP's Non Stop Kernel.. [2006-02-05 16:26:21] [EMAIL PROTECTED] "NSK-TANDEM"? What OS is that? [2006-02-05 16:23:31] ramesh25 at gmail dot com Description: PHP crashes when it exits Reproduce code: --- php -h Expected result: display command line options Actual result: -- #sapi/cli/php -h Usage: php [options] [-f] [--] [args...] php [options] -r [--] [args...] php [options] [-B ] -R [-E ] [--] [args...] php [options] [-B ] -F [-E ] [--] [args...] php [options] -- [args...] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F Parse and execute for every input line -E Run PHP after processing all input lines -H Hide any passed arguments from external tools. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdin --rf Show information about function . --rc Show information about class . --re Show information about extension . \MRS010.$:1:442:104328200 - *** Run-time Error 034 *** \MRS010.$:1:442:104328200 - Released space not allocated \MRS010.$:1:442:104328200 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:442:104328200 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:442:104328200 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:442:104328200 - module_destructor + 0xB8 (UCr) \MRS010.$:1:442:104328200 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:442:104328200 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:442:104328200 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:442:104328200 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:442:104328200 - main + 0x1D88 (UCr) \MRS010.$:1:442:104328200 - _MAIN + 0x4C (UCr) Unknown Signal #31 # #sapi/cli/php -v PHP 5.1.2 (cli) (built: Feb 5 2006 08:57:08) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies \MRS010.$:1:441:104328712 - *** Run-time Error 034 *** \MRS010.$:1:441:104328712 - Released space not allocated \MRS010.$:1:441:104328712 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:441:104328712 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:441:104328712 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:441:104328712 - module_destructor + 0xB8 (UCr) \MRS010.$:1:441:104328712 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:441:104328712 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:441:104328712 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:441:104328712 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:441:104328712 - main + 0x1D88 (UCr) \MRS010.$:1:441:104328712 - _MAIN + 0x4C (UCr) Unknown Signal #31 # -- Edit this bug report at http://bugs.php.net/?id=36294&edit=1
#36294 [Fbk->Opn]: PHP crashes when exiting
ID: 36294 User updated by: ramesh25 at gmail dot com Reported By: ramesh25 at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: NSK-TANDEM PHP Version: 5.1.2 New Comment: It is HP's Non Stop Kernel.. Previous Comments: [2006-02-05 16:26:21] [EMAIL PROTECTED] "NSK-TANDEM"? What OS is that? [2006-02-05 16:23:31] ramesh25 at gmail dot com Description: PHP crashes when it exits Reproduce code: --- php -h Expected result: display command line options Actual result: -- #sapi/cli/php -h Usage: php [options] [-f] [--] [args...] php [options] -r [--] [args...] php [options] [-B ] -R [-E ] [--] [args...] php [options] [-B ] -F [-E ] [--] [args...] php [options] -- [args...] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F Parse and execute for every input line -E Run PHP after processing all input lines -H Hide any passed arguments from external tools. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdin --rf Show information about function . --rc Show information about class . --re Show information about extension . \MRS010.$:1:442:104328200 - *** Run-time Error 034 *** \MRS010.$:1:442:104328200 - Released space not allocated \MRS010.$:1:442:104328200 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:442:104328200 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:442:104328200 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:442:104328200 - module_destructor + 0xB8 (UCr) \MRS010.$:1:442:104328200 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:442:104328200 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:442:104328200 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:442:104328200 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:442:104328200 - main + 0x1D88 (UCr) \MRS010.$:1:442:104328200 - _MAIN + 0x4C (UCr) Unknown Signal #31 # #sapi/cli/php -v PHP 5.1.2 (cli) (built: Feb 5 2006 08:57:08) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies \MRS010.$:1:441:104328712 - *** Run-time Error 034 *** \MRS010.$:1:441:104328712 - Released space not allocated \MRS010.$:1:441:104328712 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:441:104328712 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:441:104328712 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:441:104328712 - module_destructor + 0xB8 (UCr) \MRS010.$:1:441:104328712 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:441:104328712 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:441:104328712 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:441:104328712 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:441:104328712 - main + 0x1D88 (UCr) \MRS010.$:1:441:104328712 - _MAIN + 0x4C (UCr) Unknown Signal #31 # -- Edit this bug report at http://bugs.php.net/?id=36294&edit=1
#36294 [Opn->Fbk]: PHP crashes when exiting
ID: 36294 Updated by: [EMAIL PROTECTED] Reported By: ramesh25 at gmail dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: NSK-TANDEM PHP Version: 5.1.2 New Comment: "NSK-TANDEM"? What OS is that? Previous Comments: [2006-02-05 16:23:31] ramesh25 at gmail dot com Description: PHP crashes when it exits Reproduce code: --- php -h Expected result: display command line options Actual result: -- #sapi/cli/php -h Usage: php [options] [-f] [--] [args...] php [options] -r [--] [args...] php [options] [-B ] -R [-E ] [--] [args...] php [options] [-B ] -F [-E ] [--] [args...] php [options] -- [args...] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F Parse and execute for every input line -E Run PHP after processing all input lines -H Hide any passed arguments from external tools. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdin --rf Show information about function . --rc Show information about class . --re Show information about extension . \MRS010.$:1:442:104328200 - *** Run-time Error 034 *** \MRS010.$:1:442:104328200 - Released space not allocated \MRS010.$:1:442:104328200 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:442:104328200 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:442:104328200 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:442:104328200 - module_destructor + 0xB8 (UCr) \MRS010.$:1:442:104328200 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:442:104328200 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:442:104328200 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:442:104328200 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:442:104328200 - main + 0x1D88 (UCr) \MRS010.$:1:442:104328200 - _MAIN + 0x4C (UCr) Unknown Signal #31 # #sapi/cli/php -v PHP 5.1.2 (cli) (built: Feb 5 2006 08:57:08) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies \MRS010.$:1:441:104328712 - *** Run-time Error 034 *** \MRS010.$:1:441:104328712 - Released space not allocated \MRS010.$:1:441:104328712 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:441:104328712 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:441:104328712 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:441:104328712 - module_destructor + 0xB8 (UCr) \MRS010.$:1:441:104328712 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:441:104328712 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:441:104328712 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:441:104328712 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:441:104328712 - main + 0x1D88 (UCr) \MRS010.$:1:441:104328712 - _MAIN + 0x4C (UCr) Unknown Signal #31 # -- Edit this bug report at http://bugs.php.net/?id=36294&edit=1
#36294 [NEW]: PHP crashes when exiting
From: ramesh25 at gmail dot com Operating system: NSK-TANDEM PHP version: 5.1.2 PHP Bug Type: Reproducible crash Bug description: PHP crashes when exiting Description: PHP crashes when it exits Reproduce code: --- php -h Expected result: display command line options Actual result: -- #sapi/cli/php -h Usage: php [options] [-f] [--] [args...] php [options] -r [--] [args...] php [options] [-B ] -R [-E ] [--] [args...] php [options] [-B ] -F [-E ] [--] [args...] php [options] -- [args...] php [options] -a -a Run as interactive shell -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -r Run PHP without using script tags -B Run PHP before processing input lines -R Run PHP for every input line -F Parse and execute for every input line -E Run PHP after processing all input lines -H Hide any passed arguments from external tools. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdin --rf Show information about function . --rc Show information about class . --re Show information about extension . \MRS010.$:1:442:104328200 - *** Run-time Error 034 *** \MRS010.$:1:442:104328200 - Released space not allocated \MRS010.$:1:442:104328200 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:442:104328200 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:442:104328200 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:442:104328200 - module_destructor + 0xB8 (UCr) \MRS010.$:1:442:104328200 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:442:104328200 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:442:104328200 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:442:104328200 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:442:104328200 - main + 0x1D88 (UCr) \MRS010.$:1:442:104328200 - _MAIN + 0x4C (UCr) Unknown Signal #31 # #sapi/cli/php -v PHP 5.1.2 (cli) (built: Feb 5 2006 08:57:08) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies \MRS010.$:1:441:104328712 - *** Run-time Error 034 *** \MRS010.$:1:441:104328712 - Released space not allocated \MRS010.$:1:441:104328712 - From zend_hash_del_key_or_index + 0x2E0 (UCr) \MRS010.$:1:441:104328712 - php_stream_filter_unregister_factory + 0x58 (UCr) \MRS010.$:1:441:104328712 - zm_shutdown_bz2 + 0x50 (UCr) \MRS010.$:1:441:104328712 - module_destructor + 0xB8 (UCr) \MRS010.$:1:441:104328712 - zend_hash_apply_deleter + 0x88 (UCr) \MRS010.$:1:441:104328712 - zend_hash_graceful_reverse_destroy + 0x4C (UCr) \MRS010.$:1:441:104328712 - zend_shutdown + 0x48 (UCr) \MRS010.$:1:441:104328712 - php_module_shutdown + 0x74 (UCr) \MRS010.$:1:441:104328712 - main + 0x1D88 (UCr) \MRS010.$:1:441:104328712 - _MAIN + 0x4C (UCr) Unknown Signal #31 # -- Edit bug report at http://bugs.php.net/?id=36294&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36294&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36294&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36294&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36294&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36294&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36294&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36294&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36294&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36294&r=support Expected behavior:http://bugs.php.net/fix.php?id=36294&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36294&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36294&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36294&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36294&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36294&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36294&r=isapi Install GNU Sed: htt
#36293 [Opn->Csd]: zend/php crashes with server side includes in 5.0.4
ID: 36293 Updated by: [EMAIL PROTECTED] Reported By: gw at gnc dot at -Status: Open +Status: Closed Bug Type: Reproducible crash Operating System: suse sles9 kernel 2.6.5 PHP Version: 5.1.2 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Fixed long time ago in 5.1.x branch. Previous Comments: [2006-02-05 15:52:12] gw at gnc dot at Description: php 5.0.4,httpd 2.0.55 on a suse sles 9 httpd crashes when using server side includes. no idea if this belongs to php only...i'm not using any 3rd party products.just a plain php504 installation. no changes to php.ini. upgrade is not possible due to external customer scripts . php config: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql' '--enable-ftp' '--enable-trans-sid' '--enable-track-vars' '--enable-imap' '--with-gettext' '--with-oci8=/opt/oracle/ora9i' '--without-sqlite' Reproduce code: --- Actual result: -- zaphod:/usr/local/apache/bin # gdb ./httpd GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread 1076812448 (LWP 29354)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076812448 (LWP 29354)] zend_hash_index_find (ht=0x90a3e69, h=2, pData=0x90a3e69) at /root/software/php-5.0.4/Zend/zend_hash.c:955 955 if ((p->h == h) && (p->nKeyLength == 0)) { (gdb) bt #0 zend_hash_index_find (ht=0x90a3e69, h=2, pData=0x90a3e69) at /root/software/php-5.0.4/Zend/zend_hash.c:955 #1 0x4045b038 in _zend_list_delete (id=2) at /root/software/php-5.0.4/Zend/zend_list.c:55 #2 0x404305fc in _php_stream_free (stream=0x82f988c, close_options=3) at /root/software/php-5.0.4/main/streams/streams.c:310 #3 0x40420461 in stream_closer_for_zend (handle=0x82f988c) at /root/software/php-5.0.4/main/main.c:843 #4 0x4043f913 in zend_file_handle_dtor (fh=0x82f99ac) at zend_language_scanner.l:246 #5 0x4044cb29 in zend_llist_del_element (l=0x404cf2d4, element=0xbfffef40, compare=0x4043b770 ) at /root/software/php-5.0.4/Zend/zend_llist.c:104 #6 0x4043f769 in zend_destroy_file_handle (file_handle=0xbfffef40) at zend_language_scanner.l:284 #7 0x40452909 in zend_execute_scripts (type=2, retval=0x0, file_count=1) at /root/software/php-5.0.4/Zend/zend.c:1066 #8 0x40482466 in php_handler (r=0x82f76e0) at /root/software/php-5.0.4/sapi/apache2handler/sapi_apache2.c:557 #9 0x0808612b in ap_run_handler (r=0x82f76e0) at config.c:152 #10 0x08088aa5 in ap_invoke_handler (r=0x82f76e0) at config.c:364 #11 0x0809b278 in ap_run_sub_req (r=0x82f76e0) at request.c:1855 #12 0x080658cc in handle_include (ctx=0x82d7878, bb=0xb1bc, r=0x82e3298, f=0x82dd438, head_ptr=0x82db850, inserted_head=0xb1c0) at mod_include.c:742 #13 0x080638f9 in includes_filter (f=0x82dd438, b=0x82dd578) at mod_include.c:3309 #14 0x0809200b in ap_pass_brigade (next=0x82dd438, bb=0x82dd578) at util_filter.c:512 #15 0x08099aad in default_handler (r=0x82e3298) at core.c:3640 #16 0x0808612b in ap_run_handler (r=0x82e3298) at config.c:152 #17 0x08088aa5 in ap_invoke_handler (r=0x82e3298) at config.c:364 #18 0x0806e7af in ap_process_request (r=0x82e3298) at http_request.c:249 #19 0x08069e1c in ap_process_http_connection (c=0x82d7340) at http_core.c:251 #20 0x0809007b in ap_run_process_connection (c=0x82d7340) at connection.c:43 #21 0x08085238 in child_main (child_num_arg=) at prefork.c:610 #22 0x0808538e in make_child (s=0x80c6c88, slot=0) at prefork.c:650 #23 0x08085451 in startup_children (number_to_start=5) at prefork.c:722 #24 0x08085b1d in ap_mpm_run (_pconf=0x80c20a8, plog=0x80fc190, s=0x80c6c88) at prefork.c:941 #25 0x0808ac7c in main (argc=2, argv=0xb614) at main.c:618 #0 zend_hash_index_find (ht=0x90a3e69, h=2, pData=0x90a3e69) at /root/software/php-5.0.4/Zend/zend_hash.c:955 nIndex = 2 p = (Bucket *) 0x90a3e69 #1 0x4045b038 in _zend_list_delete (id=2) at /root/software/php-5.0.4/Zend/zend_list.c:55 le = #2 0x404305fc in _php_stream_free (stream=0x82f988c, close_options=3) at /root/software/php-5.0.4/main/streams/streams.c:310 ret = 1 remove_rsrc = release_cast = 1 #3 0x40420461 in stream_closer_for_zend (handle=0x82f988c) at /root/software/php-5.0.4/main/main.c:843 No locals. #4 0x4043f913 in zend_
#36293 [NEW]: zend/php crashes with server side includes in 5.0.4
From: gw at gnc dot at Operating system: suse sles9 kernel 2.6.5 PHP version: 5.1.2 PHP Bug Type: Reproducible crash Bug description: zend/php crashes with server side includes in 5.0.4 Description: php 5.0.4,httpd 2.0.55 on a suse sles 9 httpd crashes when using server side includes. no idea if this belongs to php only...i'm not using any 3rd party products.just a plain php504 installation. no changes to php.ini. upgrade is not possible due to external customer scripts . php config: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql' '--enable-ftp' '--enable-trans-sid' '--enable-track-vars' '--enable-imap' '--with-gettext' '--with-oci8=/opt/oracle/ora9i' '--without-sqlite' Reproduce code: --- Actual result: -- zaphod:/usr/local/apache/bin # gdb ./httpd GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X [Thread debugging using libthread_db enabled] [New Thread 1076812448 (LWP 29354)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1076812448 (LWP 29354)] zend_hash_index_find (ht=0x90a3e69, h=2, pData=0x90a3e69) at /root/software/php-5.0.4/Zend/zend_hash.c:955 955 if ((p->h == h) && (p->nKeyLength == 0)) { (gdb) bt #0 zend_hash_index_find (ht=0x90a3e69, h=2, pData=0x90a3e69) at /root/software/php-5.0.4/Zend/zend_hash.c:955 #1 0x4045b038 in _zend_list_delete (id=2) at /root/software/php-5.0.4/Zend/zend_list.c:55 #2 0x404305fc in _php_stream_free (stream=0x82f988c, close_options=3) at /root/software/php-5.0.4/main/streams/streams.c:310 #3 0x40420461 in stream_closer_for_zend (handle=0x82f988c) at /root/software/php-5.0.4/main/main.c:843 #4 0x4043f913 in zend_file_handle_dtor (fh=0x82f99ac) at zend_language_scanner.l:246 #5 0x4044cb29 in zend_llist_del_element (l=0x404cf2d4, element=0xbfffef40, compare=0x4043b770 ) at /root/software/php-5.0.4/Zend/zend_llist.c:104 #6 0x4043f769 in zend_destroy_file_handle (file_handle=0xbfffef40) at zend_language_scanner.l:284 #7 0x40452909 in zend_execute_scripts (type=2, retval=0x0, file_count=1) at /root/software/php-5.0.4/Zend/zend.c:1066 #8 0x40482466 in php_handler (r=0x82f76e0) at /root/software/php-5.0.4/sapi/apache2handler/sapi_apache2.c:557 #9 0x0808612b in ap_run_handler (r=0x82f76e0) at config.c:152 #10 0x08088aa5 in ap_invoke_handler (r=0x82f76e0) at config.c:364 #11 0x0809b278 in ap_run_sub_req (r=0x82f76e0) at request.c:1855 #12 0x080658cc in handle_include (ctx=0x82d7878, bb=0xb1bc, r=0x82e3298, f=0x82dd438, head_ptr=0x82db850, inserted_head=0xb1c0) at mod_include.c:742 #13 0x080638f9 in includes_filter (f=0x82dd438, b=0x82dd578) at mod_include.c:3309 #14 0x0809200b in ap_pass_brigade (next=0x82dd438, bb=0x82dd578) at util_filter.c:512 #15 0x08099aad in default_handler (r=0x82e3298) at core.c:3640 #16 0x0808612b in ap_run_handler (r=0x82e3298) at config.c:152 #17 0x08088aa5 in ap_invoke_handler (r=0x82e3298) at config.c:364 #18 0x0806e7af in ap_process_request (r=0x82e3298) at http_request.c:249 #19 0x08069e1c in ap_process_http_connection (c=0x82d7340) at http_core.c:251 #20 0x0809007b in ap_run_process_connection (c=0x82d7340) at connection.c:43 #21 0x08085238 in child_main (child_num_arg=) at prefork.c:610 #22 0x0808538e in make_child (s=0x80c6c88, slot=0) at prefork.c:650 #23 0x08085451 in startup_children (number_to_start=5) at prefork.c:722 #24 0x08085b1d in ap_mpm_run (_pconf=0x80c20a8, plog=0x80fc190, s=0x80c6c88) at prefork.c:941 #25 0x0808ac7c in main (argc=2, argv=0xb614) at main.c:618 #0 zend_hash_index_find (ht=0x90a3e69, h=2, pData=0x90a3e69) at /root/software/php-5.0.4/Zend/zend_hash.c:955 nIndex = 2 p = (Bucket *) 0x90a3e69 #1 0x4045b038 in _zend_list_delete (id=2) at /root/software/php-5.0.4/Zend/zend_list.c:55 le = #2 0x404305fc in _php_stream_free (stream=0x82f988c, close_options=3) at /root/software/php-5.0.4/main/streams/streams.c:310 ret = 1 remove_rsrc = release_cast = 1 #3 0x40420461 in stream_closer_for_zend (handle=0x82f988c) at /root/software/php-5.0.4/main/main.c:843 No locals. #4 0x4043f913 in zend_file_handle_dtor (fh=0x82f99ac) at zend_language_scanner.l:246 No locals. #5 0x4044cb29 in zend_llist_del_element (l=0x404cf2d4, element=0xbfffef40, compare=0x4043b770 ) at /root/software/php-5.0.4/Zend/zend_llist.c:104 current = (zend_llist_element *) 0x82f99a4 next = (zend_llist_element *) 0x0 #6 0x4043f769 in zend_destroy_file_handle (file_handle=0xbfffef40) at zend_langua
#36292 [Opn->Bgs]: A BIG PROBLEM IN mktime FUNCTION !!!!!
ID: 36292 Updated by: [EMAIL PROTECTED] Reported By: hello at cmail dot cz -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows XP SP2 PHP Version: 4.4.2 New Comment: You just have discovered octal numbers. 09 != 9 Previous Comments: [2006-02-05 15:36:24] hello at cmail dot cz Description: Hi! I found a big problem in function mktime. A different days returns same value. Especially FEBRUARY 8th and 9th 2006. It's a very important, because it's a very soon. There is a fatal problem. See the code below. Greetings from Czech republic. Beda Reproduce code: --- $A1 = mktime(00,00,00,01,31,2006); $A2 = mktime(00,00,00,02,07,2006); // $A1=1138662000 $A2=1139266800 $A1 = mktime(00,00,00,01,31,2006); $A2 = mktime(00,00,00,02,08,2006); // both ($A1 and $A2) returns 1138662000 $A1 = mktime(00,00,00,01,31,2006); $A2 = mktime(00,00,00,02,09,2006); // both ($A1 and $A2) returns 1138662000 Expected result: please see the above Actual result: -- please see the above -- Edit this bug report at http://bugs.php.net/?id=36292&edit=1
#36292 [NEW]: A BIG PROBLEM IN mktime FUNCTION !!!!!
From: hello at cmail dot cz Operating system: Windows XP SP2 PHP version: 4.4.2 PHP Bug Type: Date/time related Bug description: A BIG PROBLEM IN mktime FUNCTION ! Description: Hi! I found a big problem in function mktime. A different days returns same value. Especially FEBRUARY 8th and 9th 2006. It's a very important, because it's a very soon. There is a fatal problem. See the code below. Greetings from Czech republic. Beda Reproduce code: --- $A1 = mktime(00,00,00,01,31,2006); $A2 = mktime(00,00,00,02,07,2006); // $A1=1138662000 $A2=1139266800 $A1 = mktime(00,00,00,01,31,2006); $A2 = mktime(00,00,00,02,08,2006); // both ($A1 and $A2) returns 1138662000 $A1 = mktime(00,00,00,01,31,2006); $A2 = mktime(00,00,00,02,09,2006); // both ($A1 and $A2) returns 1138662000 Expected result: please see the above Actual result: -- please see the above -- Edit bug report at http://bugs.php.net/?id=36292&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36292&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36292&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36292&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36292&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36292&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36292&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36292&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36292&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36292&r=support Expected behavior:http://bugs.php.net/fix.php?id=36292&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36292&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36292&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36292&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36292&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36292&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36292&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36292&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36292&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36292&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36292&r=mysqlcfg
#36289 [Opn->WFx]: SplFileObject needs fread()
ID: 36289 Updated by: [EMAIL PROTECTED] Reported By: robertpaul at gmail dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: * PHP Version: 5.1.2 -Assigned To: +Assigned To: helly New Comment: SplFileObject is a line iterator, that is it reads the next line on current() and friends. Introducing fread would mean one would need to cound the '\n's after reading some bytes. That said it would be ok to read the remainder as from the object since then valid() would return true and the number of lines wouldn't matter. An alternative would be allowing to skip line counting. However right now fread() in its current forma does not make sense. Previous Comments: [2006-02-05 00:32:23] robertpaul at gmail dot com Description: Please forgive me if I'm missing something, but it seems as though SplFileObject has most of the useful file functions except fread. Having that available would be Really Good. Thanks! -- Edit this bug report at http://bugs.php.net/?id=36289&edit=1
#36287 [Asn->Csd]: segfault with RecursiveIteratorIterator
ID: 36287 Updated by: [EMAIL PROTECTED] Reported By: meeb at meeb dot org -Status: Assigned +Status: Closed Bug Type: Filesystem function related Operating System: * PHP Version: 5.1.2 Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-02-04 18:44:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-02-04 17:45:06] meeb at meeb dot org s/iterator/object/ whoops :p [2006-02-04 17:42:12] meeb at meeb dot org Description: When accidently comparing a the iterator created by RecursiveDirectoryIterator against a string PHP segfaulted. This is new to 5.1.2 (worked under 5.1.1 and I was unaware of the issue with my code). There are obvious workarounds for this so no major panic. Removing the 'if': if($file!="."&&$file!="..") stops the segfault. Unfortunately I only have EMT64/Debian64 servers available so I am unable to test this for cross-platform compatibility, and I was unable to find any exact matching bugs (closest were a few stack corruptions). This occurs when the script is executed on the command line and via apache2. I have saved straces should they be requested. Reproduce code: --- $this->dir = new RecursiveIteratorIterator(new RecursiveDirectoryIterator("."),true); foreach($this->dir as $file){ // works... echo $file->getPathName()."\n"; // segfauls... if($file!="."&&$file!="..") echo $file->getPathName()."\n"; } Expected result: ./dir/ ./dir/file1.ext ./dir/file2.ext Actual result: -- Segmentation Fault. -- Edit this bug report at http://bugs.php.net/?id=36287&edit=1
#36287 [Fbk->Asn]: segfault with RecursiveIteratorIterator
ID: 36287 Updated by: [EMAIL PROTECTED] Reported By: meeb at meeb dot org -Status: Feedback +Status: Assigned Bug Type: Filesystem function related -Operating System: Debian64 EMT64 SMP +Operating System: * PHP Version: 5.1.2 -Assigned To: +Assigned To: helly Previous Comments: [2006-02-04 18:44:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-02-04 17:45:06] meeb at meeb dot org s/iterator/object/ whoops :p [2006-02-04 17:42:12] meeb at meeb dot org Description: When accidently comparing a the iterator created by RecursiveDirectoryIterator against a string PHP segfaulted. This is new to 5.1.2 (worked under 5.1.1 and I was unaware of the issue with my code). There are obvious workarounds for this so no major panic. Removing the 'if': if($file!="."&&$file!="..") stops the segfault. Unfortunately I only have EMT64/Debian64 servers available so I am unable to test this for cross-platform compatibility, and I was unable to find any exact matching bugs (closest were a few stack corruptions). This occurs when the script is executed on the command line and via apache2. I have saved straces should they be requested. Reproduce code: --- $this->dir = new RecursiveIteratorIterator(new RecursiveDirectoryIterator("."),true); foreach($this->dir as $file){ // works... echo $file->getPathName()."\n"; // segfauls... if($file!="."&&$file!="..") echo $file->getPathName()."\n"; } Expected result: ./dir/ ./dir/file1.ext ./dir/file2.ext Actual result: -- Segmentation Fault. -- Edit this bug report at http://bugs.php.net/?id=36287&edit=1
#34158 [Opn->Fbk]: Wrong t.tm_isdst flag value.
ID: 34158 Updated by: [EMAIL PROTECTED] Reported By: aesthete at telecenter dot ru -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Linux 2.6.12 (Fedora Core 3) PHP Version: 4.4.0 New Comment: Did you try PDO_FIREBIRD ? Previous Comments: [2006-02-05 11:57:01] aesthete at telecenter dot ru In php-5.1.2 this bug too ... [2006-01-17 15:05:21] c dot coppari at sintekno dot it I think the problem is in mktime() function, at line: timestamp = mktime(&t); This is because the variable t for SQL_TYPE_TIME doesn't get the proper values for month, year and day. The mktime() function tries to normalize the date, however with libc6 this result in an incorrect time. I used this patch: case SQL_TYPE_TIME: isc_decode_sql_time((ISC_TIME *) data, &t); format = IBG(timeformat); t.tm_mday = 16; t.tm_mon = 0; t.tm_year = 106; break; Forcing the day, month and year with a correct value solved the problem for me. I don't know if this is the correct behaviour of mktime(). [2005-11-28 12:17:17] [EMAIL PROTECTED] [20 Sep 11:13pm CEST] [EMAIL PROTECTED] Can you please give a try for the PDO driver? [2005-08-16 21:37:10] aesthete at telecenter dot ru Description: My previos message was about Wrong Time conersion from db: http://bugs.php.net/bug.php?id=34037&edit=1 I solved my problem when comment t.tm_isdst = -1; in interbase.c I don't know is there bug of php or interbase but i have some ideas abot it. In interbase.c we have some code: /* XXX - Might have to remove this later - seems that isc_decode_date() always sets tm_isdst to 0, sometimes incorrectly (InterBase 6 bug?) */ t.tm_isdst = -1; As you say in your comment: "isc_decode_date() always sets tm_isdst to 0" ... thats true. But in gds.cpp (firebird 1.5.2 source) nothing said about changeing tm_isdst (in all gds.cpp) to any value Except for 0 in memset(times, 0, sizeof(*times)) instructions. It always return tm_isdst = 0 in all api functions where "struct tm *times" used as argument! I dont know why you do t.tm_isdst = -1; Therefore strftime(string_data, sizeof(string_data), format, &t) cannot return right formated time string. May be it php bug ?) P.S.: Sorry my english. -- Edit this bug report at http://bugs.php.net/?id=34158&edit=1
#34158 [NoF->Opn]: Wrong t.tm_isdst flag value.
ID: 34158 User updated by: aesthete at telecenter dot ru Reported By: aesthete at telecenter dot ru -Status: No Feedback +Status: Open Bug Type: InterBase related Operating System: Linux 2.6.12 (Fedora Core 3) PHP Version: 4.4.0 New Comment: In php-5.1.2 this bug too ... Previous Comments: [2006-01-17 15:05:21] c dot coppari at sintekno dot it I think the problem is in mktime() function, at line: timestamp = mktime(&t); This is because the variable t for SQL_TYPE_TIME doesn't get the proper values for month, year and day. The mktime() function tries to normalize the date, however with libc6 this result in an incorrect time. I used this patch: case SQL_TYPE_TIME: isc_decode_sql_time((ISC_TIME *) data, &t); format = IBG(timeformat); t.tm_mday = 16; t.tm_mon = 0; t.tm_year = 106; break; Forcing the day, month and year with a correct value solved the problem for me. I don't know if this is the correct behaviour of mktime(). [2005-11-28 12:17:17] [EMAIL PROTECTED] [20 Sep 11:13pm CEST] [EMAIL PROTECTED] Can you please give a try for the PDO driver? [2005-08-16 21:37:10] aesthete at telecenter dot ru Description: My previos message was about Wrong Time conersion from db: http://bugs.php.net/bug.php?id=34037&edit=1 I solved my problem when comment t.tm_isdst = -1; in interbase.c I don't know is there bug of php or interbase but i have some ideas abot it. In interbase.c we have some code: /* XXX - Might have to remove this later - seems that isc_decode_date() always sets tm_isdst to 0, sometimes incorrectly (InterBase 6 bug?) */ t.tm_isdst = -1; As you say in your comment: "isc_decode_date() always sets tm_isdst to 0" ... thats true. But in gds.cpp (firebird 1.5.2 source) nothing said about changeing tm_isdst (in all gds.cpp) to any value Except for 0 in memset(times, 0, sizeof(*times)) instructions. It always return tm_isdst = 0 in all api functions where "struct tm *times" used as argument! I dont know why you do t.tm_isdst = -1; Therefore strftime(string_data, sizeof(string_data), format, &t) cannot return right formated time string. May be it php bug ?) P.S.: Sorry my english. -- Edit this bug report at http://bugs.php.net/?id=34158&edit=1
#36084 [Com]: apache2 segfaults on phpinfo()
ID: 36084 Comment by: ale at FreeBSD dot org Reported By: clive at darkarts dot co dot za Status: No Feedback Bug Type: Reproducible crash Operating System: FreeBSD PHP Version: 5.1.2 New Comment: Have you recompiled pecl-imagick after php update? I have no problems: %php -v PHP 5.1.2 (cli) (built: Jan 30 2006 17:07:55) Copyright (c) 1997-2006 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies %php -i ... imagick ImageMagick support => enabled Magick Backend => ImageMagick ImageMagick version => 6.2.5 PHP imagick version => 0.9.11 MaxRGB => 65535 Supported image formats => 8BIM Font Family - Name => AvantGarde - AvantGarde-Book ... Previous Comments: [2006-02-05 07:13:08] yvovandoorn at comcast dot net I'm pretty sure this isn't related to Apache2. The reason why is that I am experiencing this problem on two machines, one installed with FreeBSD 5.4 and the other FreeBSD 6.0. The only thing these two have in common is that I installed all my additional applications via the ports. On both machines the problem goes away the moment I disable the imagemagick extension. Yes both machines are running Apache2, however this problem appeared before php 5.1.2, but sometime a week after the new year. Since I strongly believe that the imagick extension is the cause of it, I did some checking and found out the port was upgraded for pecl-imagick on 01/05/06 so I'm pretty sure thats where the issue lies. I've contacted the maintainer for that port (and strangely he also maintains php5 & php5-extensions). [2006-02-03 12:20:50] mail at skraemer dot net This might help you: I ran into the same problem, and the error dissapeared when i commented out the "ImageMagick"-extension in my "exentsions.ini" (FreeBSD-system). If you need detailed informations about the cofiguration- / compiling-process, please send me an e-mail. [2006-01-28 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-01-27 01:06:31] engin at turk-php dot com i was having the same issue on same os and same php version but i didnt try to re-compile with different configure options coz in the previous php-5.0.5 with ZEND Debugger i faced with similar bug , seg fault, when i removed the Zend Debugger module it was working fine, ( on FreeBSD 4.11 - apache 1.3 ) recently i upgrade my os to FreeBSD-6.0 - apache 2.2 - php 5.1.2 with trial and error method i found imagick and recode modules cause issue [Thu Jan 27 02:04:12 2006] [notice] child pid 5968 exit signal Abort trap (6) httpd in free(): error: junk pointer, too high to make sense [2006-01-20 09:51:30] [EMAIL PROTECTED] Then you need to add rest of your options one by one to see which one is causing the problem for you. 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/36084 -- Edit this bug report at http://bugs.php.net/?id=36084&edit=1
#36290 [Opn->Fbk]: tempnam() creates file on wrong drive
ID: 36290 Updated by: [EMAIL PROTECTED] Reported By: info at silisoftware dot com -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Windows XP Pro SP2 PHP Version: 4.4.2 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-02-05 02:19:00] info at silisoftware dot com Description: tempnam() returns a temp filename, and creates the file. However, it creates it on the wrong drive. For example: $tempname = tempnam('', 'foo'); echo $tempname.''; echo realpath($tempname).''; This outputs: \foo49.tmp e:\foo49.tmp Notice the returned filename has no drive letter. The file is created (to prevent race condition) in C:\ but realpath() resolves that to E:\ (the last drive letter of physical harddrives in this system). For reference: getenv('TMP')== 'C:\WINDOWS\TEMP' getenv('TMPDIR') == '' Reproduce code: --- $tempname = tempnam('', 'foo'); echo $tempname.''; echo realpath($tempname).''; Expected result: c:\foo49.tmp c:\foo49.tmp Actual result: -- \foo49.tmp e:\foo49.tmp -- Edit this bug report at http://bugs.php.net/?id=36290&edit=1
#36288 [Csd]: fastcgi crashes on ternary operator and $foo{x}
ID: 36288 Updated by: [EMAIL PROTECTED] Reported By: scripts at freq9 dot de Status: Closed Bug Type: Variables related Operating System: Windows XP Prof. PHP Version: 6CVS-2006-02-04 (snap) New Comment: Please report PECL bugs to PECL bugsystem. Previous Comments: [2006-02-05 01:25:13] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Bug was in PECL/operator extension. Forgot to take into account string offsets. [2006-02-05 00:05:28] scripts at freq9 dot de if php_operator is loaded fastcgi/cli crashes! - cli# php -f test.php > CLI hat ein Problem festgestellt und muss beendet werden. - - browser# http://localhost/test.php > CGI / FastCGI hat ein Problem festgestellt und muss beendet werden. - (german) [2006-02-04 23:35:14] [EMAIL PROTECTED] Does CLI work in the same time? Please explain what does it mean "crashes" and provide more info. Also, I can't reproduce it on Linux. [2006-02-04 23:17:14] scripts at freq9 dot de Description: When I execute this code, fastcgi crashes and i´ll get an Error 500. Reproduce code: --- Expected result: hello world Actual result: -- FastCGI crashes & Error 500 (Premature end of script headers) -- Edit this bug report at http://bugs.php.net/?id=36288&edit=1