date:20021013

#16880 [Ctl->Fbk]: max_execution_time affects large uploads

2002-10-13 Thread sniper


 ID:   16880
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Critical
+Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Windows 98
 PHP Version:  4.2.0
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

(I can not reproduce this with this snapshot) 



Previous Comments:


[2002-10-12 21:02:59] [EMAIL PROTECTED]

Confirmed in 4.2.3



[2002-10-12 14:01:04] [EMAIL PROTECTED]

I have the same problem with iplanet web and IIS in win 2k.



[2002-10-12 10:24:58] [EMAIL PROTECTED]

This should be fixed..




[2002-10-04 08:20:06] [EMAIL PROTECTED]

I have the same problem running Php 4.2 on IIS on a W2K server machine



[2002-07-19 12:23:28] [EMAIL PROTECTED]

I have the same problem running Php 4.2.1 on Apache on a win NT server
machine



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/16880

-- 
Edit this bug report at http://bugs.php.net/?id=16880&edit=1

#19877 [Csd->Opn]: Apache segmentation faults

2002-10-13 Thread matt


 ID:   19877
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RH Linux 7.2
 PHP Version:  4.2.3
 New Comment:

I need to re-open this bug as I've discovered that using 4.3.0 is not a
valid solution for me. Rather than fixing the problem it seems to
simply abort execution of functions as they begin to crash, meaning
that no output is generated and in the end I'm no better off. 

I have determined that session_decode() is the source of the error,
here's a gdb backtrace:

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x400ce271 in php_set_session_var (name=0x80bb134 "player_id",
namelen=9, 
state_val=0x80bb174, var_hash=0xbfffa528) at session.c:290
290 zend_set_hash_symbol(state_val, name,
namelen, 1, 2, Z_ARRVAL_P(PS(http_session_vars)), &EG(symbol_table));
(gdb) bt
#0  0x400ce271 in php_set_session_var (name=0x80bb134 "player_id",
namelen=9, 
state_val=0x80bb174, var_hash=0xbfffa528) at session.c:290
#1  0x400ce83e in __lock_checklocker () at session.c:441
#2  0x400cea49 in php_session_decode (
val=0x80baf54
"id|s:1:\"1\";name|s:8:\"Specterx\";cont_id|s:1:\"1\";", vallen=184)
at session.c:490
#3  0x400d13ac in log_archive () at session.c:1340
#4  0x4017ef27 in new_heap (size=134983936) at malloc.c:2118
#5  0x4015a126 in zend_execute_scripts () at printf_fp.c:241
#6  0x400a0c42 in php_execute_script (primary_file=0xbfffe830) at
main.c:1383
#7  0x401657aa in apache_php_module_main () at psignal.c:62
#8  0x4009ce74 in nis_clone_object (src=0x80a6dc4, dest=0x0)
at nis_clone_obj.c:34
#9  0x4009cee1 in send_parsed_php () at nis_clone_obj.c:59
#10 0x40189577 in ap_invoke_handler () at argz-replace.c:125
#11 0x401a0b1f in process_request_internal () at
../stdlib/strtod.c:906
#12 0x401a0b93 in ap_process_request () at ../stdlib/strtod.c:1006
#13 0x40196ab5 in child_main () at ../stdlib/strtod.c:294
#14 0x40196c80 in make_child () at ../stdlib/strtod.c:938
#15 0x40196e14 in startup_children () at ../stdlib/strtod.c:807
#16 0x4019754a in __wcstof_internal (nptr=0x2, endptr=0xbfffeca4, 
---Type  to continue, or q  to quit---
group=-1073746920) at ../stdlib/strtod.c:603
#17 0x40197f5e in ap_main () at ../stdlib/strtod.c:283
#18 0x08048711 in ?? ()
#19 0x4031d627 in ?? (), 
(gdb) frame 2
#2  0x400cea49 in php_session_decode (
val=0x80baf54
"id|s:1:\"1\";name|s:8:\"Specterx\";cont_id|s:1:\"1\";", vallen=184)
at session.c:490
490 if (PS(serializer)->decode(val, vallen TSRMLS_CC) ==
FAILURE) {
(gdb) Quit  

I tested my theory by commenting out the call to session_decode() in
the offending script and manually setting the variables that I needed
instead. Lo and behold, it worked. 

Up to this point I have rebooted my server at least twice and
recompiled and reinstalled PHP and Apache numerous times.


Previous Comments:


[2002-10-12 13:08:26] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

User reports that the problem has been resolved in the CVS.



[2002-10-12 13:02:03] [EMAIL PROTECTED]

I've managed to resolve the problem. First I recompiled php without
ldap, zlib or the image library options and recompiled Apache from
scratch with the new PHP. That produced no effect. However, recompiling
from the 4.3.0-dev source (CVS snapshot) fixed the error.



[2002-10-12 02:18:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


Try first the snapshot. If it crashes too:
Just in case you didn't read this: 

http://bugs.php.net/bugs-generating-backtrace.php

(add --enable-debug to your configure line)

Also, did you update your php.ini at any time?
And could you please add the shortest possible
example script here which can be used to reproduce this problem..




[2002-10-11 23:33:30] [EMAIL PROTECTED]

I was using Apache 1.3.26 with PHP 4.2.1 for about 3 months with no
problems, then one day I discovered unable to access certain PHP pages
(IE would gi

#19886 [NEW]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread spic


From: [EMAIL PROTECTED]
Operating system: Windows, any Version
PHP version:  4CVS-2002-10-13
PHP Bug Type: Filesystem function related
Bug description:  readfile, fread, fpassthru won't work with large files!!!

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files. The
Frameset consists of three Frames. Every Frame is PHP-generated. One
functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.

-- 
Edit bug report at http://bugs.php.net/?id=19886&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19886&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19886&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19886&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19886&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19886&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19886&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19886&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19886&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19886&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19886&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19886&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19886&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19886&r=isapi

#19783 [Opn->Csd]: A big problem with fread() with PHP4.3.0

2002-10-13 Thread spic


 ID:   19783
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: WindowsNT/XP/2000/9x
 PHP Version:  4CVS-2002-10-06
 New Comment:

Sorry, my previous submitted problem is not related to this bug. 

Please see Bug #19886.


Previous Comments:


[2002-10-13 08:52:31] [EMAIL PROTECTED]

Reopened this bug.

readfile() on 4.0, 4.2.4-dev and latest CVS-snapshot (13-Oct-2002
03:27) won't work with large files in Windows.

Even
$ptfp=fopen($ipoc_passthru_fn,"rb");
while(!feof($ptfp))
{
print fread($ptfp,4096);
}
fclose($ptfp);
won't work.

Files <100k work fine, larger don't.

This error is reproductive on various computers with different
Windows-Systems and occurs while trying to pass through PDF-files.



[2002-10-06 20:56:44] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.



[2002-10-06 20:28:21] [EMAIL PROTECTED]

This bug looks really important. 

I dont know if it is because of the new handling of streams but I just
verified that its working with PHP4.2.3 and not wit h 4_3 latest.



[2002-10-06 14:14:32] [EMAIL PROTECTED]

on some of my code I use the following:
$fd=fopen($filename,"rb");  
echo fread($fd,filesize($filename)); 
fclose($fd);  

It looks fread is limited to a certain value. I can't get more than a
certain size. With bigs files, I dont get all of them but just a part
so I had to use fgets.

Can someone check if something changed on the fread()'s function that
would limit it?




-- 
Edit this bug report at http://bugs.php.net/?id=19783&edit=1

#19884 [Opn->Bgs]: Functions close connections

2002-10-13 Thread cynic


 ID:   19884
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: FreeBSD && XP
 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 think that counts as a script. you know, something that we
could actually run. code, you know?

and:
1. no, don't paste your whole application here.
   isolate the problem to the lowest line count possible.
2. *no* echo "$foo" stuff if it's
not required to make the bug show up;
   strip anrything that's not absolutely needed.
3. it needs to be *actual code*. just waving it like this makes it
harder for the developers, and you're less likely to get a speedy fix.
4. *paste* the code here: "i made a typo when i was typing it in here
coz i can't use clipboard" threads are wasting resources and have the
same ill effect as the previous point. the PHP developers don't enjoy
finding actual bugs buried in heaps of parse errors.

i hope that was explicit enough.




Previous Comments:


[2002-10-13 08:50:52] [EMAIL PROTECTED]

I open a connection to mysql ($conn) for use in my program.  Then I
call a function (FuncName) that begins with the line (global $conn). 
Even though there is no mysql_close($conn) statement when the function
returns I no longer have a mysql connection.  This causes subsequent
database queries to return "mysql resource error".  Therefore, it
appears as though the mysql connection is being closed by the function.



[2002-10-13 01:35:36] [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-13 00:54:19] [EMAIL PROTECTED]

I have many functions that use a mysql_result_resource that is declared
global (i.e. global $mysql_link).  For some reason after a call to
those functions my mysql_connection disappears/is closed.




-- 
Edit this bug report at http://bugs.php.net/?id=19884&edit=1

#19884 [Bgs->Opn]: Functions close connections

2002-10-13 Thread darylm


 ID:   19884
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Open
 Bug Type: MySQL related
 Operating System: FreeBSD && XP
 PHP Version:  4.2.3
 New Comment:

I open a connection to mysql ($conn) for use in my program.  Then I
call a function (FuncName) that begins with the line (global $conn). 
Even though there is no mysql_close($conn) statement when the function
returns I no longer have a mysql connection.  This causes subsequent
database queries to return "mysql resource error".  Therefore, it
appears as though the mysql connection is being closed by the function.


Previous Comments:


[2002-10-13 01:35:36] [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-13 00:54:19] [EMAIL PROTECTED]

I have many functions that use a mysql_result_resource that is declared
global (i.e. global $mysql_link).  For some reason after a call to
those functions my mysql_connection disappears/is closed.




-- 
Edit this bug report at http://bugs.php.net/?id=19884&edit=1

#17566 [Ana->Fbk]: phpinfo() causes load of 2+

2002-10-13 Thread iliaa


 ID:   17566
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: BSD/OS 4.2
 PHP Version:  4.3-dev
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

The memory leak problem has been corrected, can you please check if the
phpinfo() still drives up the load.


Previous Comments:


[2002-10-09 13:26:20] [EMAIL PROTECTED]

--disable-debug affects the display of the memory leak :-)

It does not affect the error itself. Still an increasing load.
I've added some trace warnings, and it seems that every string is
passed through php_escape_html_entities twice! Here's an anonimized
snippet:
PHP Warning:  oldlen is 15. old is ,
newlen=1210382182, all=1, quote_style=2, hint_charset is <(null)>
 in /webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Putting a terminator at position 15 in
/webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Returning replaced  (len=15) in
/webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  oldlen is 15. old is ,
newlen=1211165388, all=1, quote_style=2, hint_charset is <(null)>
 in /webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Putting a terminator at position 15 in
/webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Returning replaced  (len=15) in
/webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  oldlen is 34. old is , newlen=1210382258, all=1, quote_style=2, hint_chars
et is <(null)>
 in /webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Putting a terminator at position 34 in
/webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Returning replaced 
(len=34) in /webdocs/host.domain.nl/public_html/php
2345.php on line 2
PHP Warning:  oldlen is 34. old is , newlen=1211165388, all=1, quote_style=2, hint_chars
et is <(null)>
 in /webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Putting a terminator at position 34 in
/webdocs/host.domain.nl/public_html/script.php on line 2
PHP Warning:  Returning replaced 
(len=34) in /webdocs/host.domain.nl/public_html/php
2345.php on line 2



[2002-10-07 06:41:36] [EMAIL PROTECTED]

The problem is in the recent changes to ext/standard/info.c which is
calling php_escape_html_entities (via php_info_html_esc) and PUTS()-ing
the result.
It never efree's it.
I suspect the loading problems will go away if you build a
--disable-debug version of PHP.



[2002-10-06 23:09:07] [EMAIL PROTECTED]

PHPAPI char *php_escape_html_entities(unsigned char *old, int oldlen,
int *newlen, int all, int quote_style, char *hint_char
set TSRMLS_DC)
{
int i, j, maxlen, len;
char *replaced;
enum entity_charset charset = determine_charset(hint_charset
TSRMLS_CC);
int matches_map;

maxlen = 2 * oldlen;
if (maxlen < 128)
maxlen = 128;replaced = emalloc (maxlen); // #line 667
len = 0;

i = 0;
while (i < oldlen) {


}   
}
replaced[len] = '\0';
...


So what happens if oldlen = 0 and more importantly: how can oldlen
become 0?



[2002-10-06 23:01:29] [EMAIL PROTECTED]

hmm..that is a hint:
/home/mdev/cvs/php4/ext/standard/html.c(667) :  Freeing 0x0820BA24 (396
bytes), script=-
Last leak repeated 383 times

383 times?



[2002-10-06 22:57:30] [EMAIL PROTECTED]

No change at all.
Apache 2.0.43.

load averages:  6.81,  3.75,  1.91
149 processes: 2 running, 147 sleeping
CPU states:  0.2% user,  0.0% nice,  0.2% system,  0.0% interrupt,
99.6% idle
Memory: Real: 318M/397M Virt: 440M/1252M Free: 477M




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/17566

-- 
Edit this bug report at http://bugs.php.net/?id=17566&edit=1

#19886 [Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread spic


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Filesystem function related
+Bug Type: Reproducible crash
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...


Previous Comments:


[2002-10-13 09:08:03] [EMAIL PROTECTED]

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files.
The Frameset consists of three Frames. Every Frame is PHP-generated.
One functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.





-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#16880 [Fbk->Ctl]: max_execution_time affects large uploads

2002-10-13 Thread sniper


 ID:   16880
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Critical
 Bug Type: Scripting Engine problem
-Operating System: Windows 98
+Operating System: *
-PHP Version:  4.2.0
+PHP Version:  4.3.0-dev
 New Comment:

Nevermind, I had wrong php.ini settings.
Reproduced here too..



Previous Comments:


[2002-10-12 21:59:32] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

(I can not reproduce this with this snapshot) 




[2002-10-12 21:02:59] [EMAIL PROTECTED]

Confirmed in 4.2.3



[2002-10-12 14:01:04] [EMAIL PROTECTED]

I have the same problem with iplanet web and IIS in win 2k.



[2002-10-12 10:24:58] [EMAIL PROTECTED]

This should be fixed..




[2002-10-04 08:20:06] [EMAIL PROTECTED]

I have the same problem running Php 4.2 on IIS on a W2K server machine



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/16880

-- 
Edit this bug report at http://bugs.php.net/?id=16880&edit=1

#19857 [Fbk]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread sniper


 ID:   19857
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:

Please provide shortest possible example script that can
be just copy pasted and run. That would help us a lot..


Previous Comments:


[2002-10-13 06:24:45] [EMAIL PROTECTED]

Please provide shortest possible example script that can
be just copy pasted and run. That would help us a lot..



[2002-10-13 04:07:53] [EMAIL PROTECTED]

BTW, I apologize for all of the submissions; I mistakenly submitted
more times that I wanted to...



[2002-10-13 04:06:35] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



[2002-10-13 04:06:06] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



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/19857

-- 
Edit this bug report at http://bugs.php.net/?id=19857&edit=1

#19884 [NEW]: Functions close connections

2002-10-13 Thread darylm


From: [EMAIL PROTECTED]
Operating system: FreeBSD && XP
PHP version:  4.2.3
PHP Bug Type: MySQL related
Bug description:  Functions close connections

I have many functions that use a mysql_result_resource that is declared
global (i.e. global $mysql_link).  For some reason after a call to those
functions my mysql_connection disappears/is closed.
-- 
Edit bug report at http://bugs.php.net/?id=19884&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19884&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19884&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19884&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19884&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19884&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19884&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19884&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19884&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19884&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19884&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19884&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19884&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19884&r=isapi

#19783 [Csd->Opn]: A big problem with fread() with PHP4.3.0

2002-10-13 Thread spic


 ID:   19783
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: Filesystem function related
-Operating System: FreeBSD4.5
+Operating System: WindowsNT/XP/2000/9x
 PHP Version:  4CVS-2002-10-06
 New Comment:

Reopened this bug.

readfile() on 4.0, 4.2.4-dev and latest CVS-snapshot (13-Oct-2002
03:27) won't work with large files in Windows.

Even
$ptfp=fopen($ipoc_passthru_fn,"rb");
while(!feof($ptfp))
{
print fread($ptfp,4096);
}
fclose($ptfp);
won't work.

Files <100k work fine, larger don't.

This error is reproductive on various computers with different
Windows-Systems and occurs while trying to pass through PDF-files.


Previous Comments:


[2002-10-06 20:56:44] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.



[2002-10-06 20:28:21] [EMAIL PROTECTED]

This bug looks really important. 

I dont know if it is because of the new handling of streams but I just
verified that its working with PHP4.2.3 and not wit h 4_3 latest.



[2002-10-06 14:14:32] [EMAIL PROTECTED]

on some of my code I use the following:
$fd=fopen($filename,"rb");  
echo fread($fd,filesize($filename)); 
fclose($fd);  

It looks fread is limited to a certain value. I can't get more than a
certain size. With bigs files, I dont get all of them but just a part
so I had to use fgets.

Can someone check if something changed on the fread()'s function that
would limit it?




-- 
Edit this bug report at http://bugs.php.net/?id=19783&edit=1

#19876 [Opn->Csd]: Problem with parse_url() function...

2002-10-13 Thread iliaa


 ID:   19876
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: *URL Functions
 Operating System: Windows 2000 Pro (Sp3)
 PHP Version:  4CVS-2002-10-12
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The latest snapshot has this problem fixed.
http://snaps.php.net/win32/php4-win32-200210121800.zip


Previous Comments:


[2002-10-12 12:56:00] [EMAIL PROTECTED]

I just tried this snap: php4-win32-200210121400.zip

The result is different, but still incorrect:

Array
(
[scheme] => ftp
[host] => ww.moria.com
[user] => gandalf
[pass] => :mellon@
[path] => /foo/bar/index.php
[query] => page=news
)

host & pass values are wrong...

/OnionMan



[2002-10-12 03:28:35] [EMAIL PROTECTED]

Please wait until the next developer snapshot is generated and try
again.





[2002-10-11 23:31:53] [EMAIL PROTECTED]

The lack for formatting for phpinfo() when html_errors are Off is
intentional. 

parse_url() was recently rewritten from scratch that probably
introduced the bug you are seeing. I'll look into it in more detail.



[2002-10-11 23:26:58] [EMAIL PROTECTED]

Here's a link to the phpinfo at my machine:

http://onionman.homeip.net/phpinfo/

A weird thing i noticed is that if i have 'html_errors = Off' in my
php.ini file, then phpinfo looses all it formatting and is
unreadable... is it supposed to be like this?

Anyway... i doublechecked the parse_url bug by going back to an older
snapshot (2002-10-06), and there it works like expected... and then
trying latest snap again (2002-10-12), and there it's the same result
as before... so either something has introduced a bug there since last
week... or my machine is behaving strange... ;)

/OnionMan



[2002-10-11 23:00:11] [EMAIL PROTECTED]

The 1 comes from 'echo print_r' you do not need to echo print_r() it'll
do it automatically. The missing letter is something I am unable to
replicate on any of my machines. Could you please should output of
phpinfo() on your system, maybe that'll yeild some clues.



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/19876

-- 
Edit this bug report at http://bugs.php.net/?id=19876&edit=1

#19879 [Csd]: Failed build with simple options for apache2

2002-10-13 Thread derick


 ID:   19879
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Debian GNU/Linux 3.0
 PHP Version:  4.3.0-pre1
 New Comment:

1. This is not a hack, I just tried to be helpful and show you how to
integrate the fix in your version. It isn't called "pre1" for no
reason.
2. A little attitude change does no harm, you can always come up with a
better fix yourself.


Previous Comments:


[2002-10-12 20:23:02] [EMAIL PROTECTED]

Pardon? Even without trying that one it is obvious (just by reading the
code),
that this "hack" can´t fix the reported error!

Do you ever analyze the problem and/or test your "hacks" 

More and more I get the feeling, that php never becomes stable and
ready
to use in a production environment!



[2002-10-12 07:10:59] [EMAIL PROTECTED]

This is fixed in CVS. Would you be so kind to add the following line
after line 287:
TSRMLS_FETCH();

the code looks like this then:
{
char numbuf[NUM_BUF_SIZE];
char *cvt;
register int i = 0, j = 0;
int sign, decpt;
char decimal_point = EG(float_separator)[0];
TSRMLS_FETCH();

PRINTF_DEBUG(("sprintf: appenddouble(%x, %x, %x, %f, %d, '%c', %d,
%c)\n",
  *buffer, pos, size, number, width, padding,
alignment, fmt));


regards,
Derick




[2002-10-12 03:32:38] [EMAIL PROTECTED]

Hello, plain unzipped php4.3.0-pre1.tar.bz2 and did ./configure
--with-apxs2=/usr/bin/apxs --prefix=/usr/local
And it failed


Here is the last bit of the compile
--
/bin/sh libtool --silent --mode=compile gcc  -Iext/standard/
-I/root/php-4.3.0pre1/ext/standard/ -DPHP_ATOM_INC
-I/root/php-4.3.0pre1/include -I/root/php-4.3.0pre1/main
-I/root/php-4.3.0pre1 -I/usr/include/apache2 -I/root/php-4.3.0pre1/Zend
-I/root/php-4.3.0pre1/ext/xml/expat  -D_REENTRANT
-I/root/php-4.3.0pre1/TSRM -DTHREAD=1  -g -O2 -pthread -DZTS 
-prefer-pic -c /root/php-4.3.0pre1/ext/standard/formatted_print.c -o
ext/standard/formatted_print.lo
/root/php-4.3.0pre1/ext/standard/formatted_print.c: In function
`php_sprintf_appenddouble':
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: `tsrm_ls'
undeclared (first use in this function)
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: (Each
undeclared identifier is reported only once
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: for each
function it appears in.)
make: *** [ext/standard/formatted_print.lo] Error 1





-- 
Edit this bug report at http://bugs.php.net/?id=19879&edit=1

#19885 [Opn->Csd]: @dl() causes script to exit

2002-10-13 Thread derick


 ID:   19885
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: NT4
 PHP Version:  4.2.1
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


Previous Comments:


[2002-10-13 05:58:57] [EMAIL PROTECTED]

In fact this is specific to threaded servers, such as Apache, and
happens because the error is considered fatal. However the
categorisation may be inappropriate because a script may have an
appropriate handler to deal with all dl() failures, and not wish to
have platform/server specific code.



[2002-10-13 05:31:35] [EMAIL PROTECTED]

Ok, so dl() doesn't yet work on windows and that's fine, but it should
still be possible to call dl() on that platform and have no ill effects
when suppressed with @. However, whilst the resultant error message is
suppressed, script execution terminates. Suppression of other errors
from dl() on Unix works as expected.

Sniper: the following script will reproduce the problem.







-- 
Edit this bug report at http://bugs.php.net/?id=19885&edit=1

#19882 [Fbk->Opn]: Nonfunctional session_decode()

2002-10-13 Thread matt


 ID:   19882
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Redhat 7.2
 PHP Version:  4CVS-2002-10-12
 New Comment:

Yes, session_start() is called in another page. I store the session
data string in a local database and pass the session ID from page to
page. 

I should note that I've used these scripts with no problems for MONTHS,
I began experiencing crashes yesterday, for no reason I can identify,
and it's been all downhill from there.


Previous Comments:


[2002-10-12 19:49:26] [EMAIL PROTECTED]

Did you initialize a session by calling session_start() before calling
session_decode() ?



[2002-10-12 18:51:03] [EMAIL PROTECTED]

This is probably related to the issue described in
http://bugs.php.net/bug.php?id=19877. 

In 4CVs-2002-10-12 session_decode() appears to be non-functional. The
function simply does nothing - no values are returned and no variables
are set. I have verified that I'm passing the function a properly
formatted session data string. 

register_globals is on. Here's my configure line:
./configure --with-mysql --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets

I'm using the CVS version because I was experiencing the session_decode
crash bug with version 4.2.x (see previous bug report - URL given
above). Perhaps these two issues are related?




-- 
Edit this bug report at http://bugs.php.net/?id=19882&edit=1

#19857 [Fbk]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread sniper

#19885 [NEW]: @dl() causes script to exit

2002-10-13 Thread nick


From: [EMAIL PROTECTED]
Operating system: NT4
PHP version:  4.2.1
PHP Bug Type: Scripting Engine problem
Bug description:  @dl() causes script to exit

Ok, so dl() doesn't yet work on windows and that's fine, but it should
still be possible to call dl() on that platform and have no ill effects
when suppressed with @. However, whilst the resultant error message is
suppressed, script execution terminates. Suppression of other errors from
dl() on Unix works as expected.

Sniper: the following script will reproduce the problem.



-- 
Edit bug report at http://bugs.php.net/?id=19885&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19885&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19885&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19885&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19885&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19885&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19885&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19885&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19885&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19885&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19885&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19885&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19885&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19885&r=isapi

#19857 [Fbk->Opn]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread darwin

#19857 [Opn]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread darwin


 ID:   19857
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...


Previous Comments:


[2002-10-13 04:06:06] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



[2002-10-13 04:03:57] [EMAIL PROTECTED]

Please provide shortest possible example script that can
be just copy pasted and run. That would help us a lot..




[2002-10-13 04:02:02] [EMAIL PROTECTED]

FYI, I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



[2002-10-13 03:30:13] [EMAIL PROTECTED]

I tried using http://snaps.php.net/win32/php4-win32-latest.zip, and it
did not solve the problem.  Is there anything special that I need to do
to configure this build that you believe will solve the problem?



[2002-10-12 02:31:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



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/19857

-- 
Edit this bug report at http://bugs.php.net/?id=19857&edit=1

#19857 [Opn]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread darwin


 ID:   19857
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:

BTW, I apologize for all of the submissions; I mistakenly submitted
more times that I wanted to...


Previous Comments:


[2002-10-13 04:06:35] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



[2002-10-13 04:06:06] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



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/19857

-- 
Edit this bug report at http://bugs.php.net/?id=19857&edit=1

#19885 [Opn]: @dl() causes script to exit

2002-10-13 Thread nick


 ID:   19885
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: NT4
 PHP Version:  4.2.1
 New Comment:

In fact this is specific to threaded servers, such as Apache, and
happens because the error is considered fatal. However the
categorisation may be inappropriate because a script may have an
appropriate handler to deal with all dl() failures, and not wish to
have platform/server specific code.


Previous Comments:


[2002-10-13 05:31:35] [EMAIL PROTECTED]

Ok, so dl() doesn't yet work on windows and that's fine, but it should
still be possible to call dl() on that platform and have no ill effects
when suppressed with @. However, whilst the resultant error message is
suppressed, script execution terminates. Suppression of other errors
from dl() on Unix works as expected.

Sniper: the following script will reproduce the problem.







-- 
Edit this bug report at http://bugs.php.net/?id=19885&edit=1

#17489 [Com]: Unable to allocate connection record

2002-10-13 Thread dukin


 ID:   17489
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sybase-ct (ctlib) related
 Operating System: Red Hat 7.2
 PHP Version:  4.2.1
 New Comment:

I have changed my e-mail adress. Only PHP had such problem, isql is
working ok, but I'm not sure if it use ct lib.


Previous Comments:


[2002-10-07 22:10:48] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

Given the nature of the error and the fact you get the same error using
non PHP applications implies your system is running out of memory.
Which causes an error 



[2002-05-28 15:18:52] [EMAIL PROTECTED]

Apache 1.3.23 + PHP 4.2.1 compiled --with-sybase-ct=/opt/sybase-11.9.2.
Env are set (I can see it in phpinfo) Apache + php compiled just like
in Apache-COMPILE HOWTO (linux edition) by Luc de Louw. it's with ssl.
the message appears sometimes after 5 days sometimes after 10 minutes
from restarting apache. It appeared even when the traffic very small (5
users). Restarting apachectl(apache compiled with php) helps for some
time, but than it appears again. Tried --with-sybase : it appeared
again. In the same time no problems connecting from isql or from C++.  
  




-- 
Edit this bug report at http://bugs.php.net/?id=17489&edit=1

#19875 [NEW]: date fails around time change

2002-10-13 Thread beryrinaldo


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.3
PHP Bug Type: Date/time related
Bug description:  date fails around time change

Here is a short script:

\n";
 
$okday = mktime(0,0,0,10,27,2002);
$oksun = strtotime("Sun",$okday);
$badmon = strtotime("Mon",$okday);
$okdif = $badmon - $oksun;
$oksunstr = date("Ymd.Hi",$oksun);
$badmonstr = date("Ymd.Hi",$badmon);
print "$okday $okdif $oksunstr $badmonstr \n";
 
echo "PHP version " . phpversion() . " \n";
 
?>

The output of the script is this:

1035097200 86400 20021020. 20021021. 
1035702000 86400 20021027. 20021027.2300 
PHP version 4.2.3 

Although the difference between Sunday (Oct 27) and Monday is 24 hours,
the output from date shows it to be only 23.

-- 
Edit bug report at http://bugs.php.net/?id=19875&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19875&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19875&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19875&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19875&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19875&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19875&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19875&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19875&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19875&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19875&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19875&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19875&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19875&r=isapi

#19886 [Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread nicos


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

did you checked if php_stream_read() was returning the right filesize
value? that was the first bug.


Previous Comments:


[2002-10-13 09:10:57] [EMAIL PROTECTED]

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...



[2002-10-13 09:08:03] [EMAIL PROTECTED]

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files.
The Frameset consists of three Frames. Every Frame is PHP-generated.
One functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.





-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19875 [Opn]: date/strtotime fails around time change

2002-10-13 Thread beryrinaldo


 ID:   19875
 User updated by:  [EMAIL PROTECTED]
-Summary:  date fails around time change
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  4.2.3
 New Comment:

Updated summary line.


Previous Comments:


[2002-10-11 21:36:26] [EMAIL PROTECTED]

Here is a short script:

\n";
 
$okday = mktime(0,0,0,10,27,2002);
$oksun = strtotime("Sun",$okday);
$badmon = strtotime("Mon",$okday);
$okdif = $badmon - $oksun;
$oksunstr = date("Ymd.Hi",$oksun);
$badmonstr = date("Ymd.Hi",$badmon);
print "$okday $okdif $oksunstr $badmonstr \n";
 
echo "PHP version " . phpversion() . " \n";
 
?>

The output of the script is this:

1035097200 86400 20021020. 20021021. 
1035702000 86400 20021027. 20021027.2300 
PHP version 4.2.3 

Although the difference between Sunday (Oct 27) and Monday is 24 hours,
the output from date shows it to be only 23.





-- 
Edit this bug report at http://bugs.php.net/?id=19875&edit=1

#15983 [Com]: session variables lost between pages

2002-10-13 Thread pratesi


 ID:   15983
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Session related
 Operating System: Debian/Linux mips platform
 PHP Version:  4.1.2 and 4.2.0
 Assigned To:  sascha
 New Comment:

PHP 4.2.3 works for me also on Debian Woody Sparc, even
though I am using the CGI version and I'm not able to use
PHP as a module, as Apache refuses to start... it seems
that there is some sort of binary incompatibility.
I have the same problem with version 4.1.2, too.
However, this seems to be a different issue, I suppose
that it is better do deal with it elsewhere, right?


Previous Comments:


[2002-10-01 14:29:32] [EMAIL PROTECTED]

I'm closing this bug for now, use of pread/pwrite has been suspended.



[2002-09-28 15:19:24] [EMAIL PROTECTED]

PHP 4.2.3 works for me on Debian Woody PowerPC.



[2002-09-26 11:18:28] [EMAIL PROTECTED]

I cannot ensure you that 4.2.3 solves the problem
as I still have not upgraded from version 4.2.2,
but I am sure that it works, as the only change needed
to make things work for me has been the removal
of the lines that have been kindly removed
for version 4.2.3 (many thanks).
BTW, the same workaround has been backported on the
Debian Woody's 4.1.2 packages, and in a short time
I could check if the fix works on Woody for Sparc.
I also point out that, as this problem seems due to a glibc
bug and not to errors in the PHP code, I have submitted
a bug report to the Debian's glibc maintainer, asking him
to backport a fix for the glibc packages; hence, hopefully,
in the future, updated Linux distributions should have
a fixed glibc package and you could finally ignore this
problem and restore the code using pread().

But I would like to submit you a simple (and perhaps
stupid) suggestion.
Maybe you could provide a ./configure option to explicitly
disable the use of pread() and pwrite(), i.e.
./configure --no-pread --no-pwrite
In this case, you could release without problems the code
using pread() and pwrite(); the person that compiles and/or
packages PHP has the possibility of disabling pread()
and/or pwrite() if things do not work... is this
a bad idea?



[2002-09-25 16:36:09] [EMAIL PROTECTED]

Sascha it's not a problem of using a feature on their system, it's a
problem that the functionality is broken on their end.  Your test,
while possibly being correct, doesn't have a way to check this and
I don't really think there is a way.  

As of this moment I'm not even sure if there is a released version with
it working.  

Marking this as open, as there is nothing the end user can comment back
on to this.  



[2002-09-25 06:17:49] [EMAIL PROTECTED]

If you want us to avoid using certain features of your platform, then
you need to provide specific testcases. We will use these testcases to
determine whether pread/pwrite work on a platform.

Currently, we use this for pread (after echo test > conftest_in):

#include 
#include 
#include 
#include 

main() { char buf[3]; return !(pread(open("conftest_in", O_RDONLY),
buf, 2, 0) == 2);

And this for pwrite:

#include 
#include 
#include 
#include 

main() { return !(pwrite(open("conftest_in", O_WRONLY|O_CREAT, 0600),
"hi", 2, 0) == 2);




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/15983

-- 
Edit this bug report at http://bugs.php.net/?id=15983&edit=1

#19883 [Com]: string concatenation bug

2002-10-13 Thread skaventruc


 ID:   19883
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

maybe you do not consider it as a bug but it is quite
annoying when contatenating arguments, I personnaly
think that this is a lack of the parser/compiler to
do not detect that the '.' is not a part of the '2'
but it is an operator :

putting a '.' after the 2 doesn't change it's display.
$e = 2.3.'km'; // the dot after 2 followed by a digit
   // indicate a float
'2.3km'

$e = 2..'km'; // is ok the the dot after 2 is useless
'2km'

$e = 2.'km'; // produce a parse error
$e = 2 .'km'; // is ok
'2km'


Previous Comments:


[2002-10-12 22:50:10] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php



[2002-10-12 20:13:42] [EMAIL PROTECTED]

concatenation hazard ... on :

$a = 2;
echo 'c='.$a*2 .' ok';

it produce a good result : "c=4 ok"

but :

$a = 2;
echo 'c='.$a*2.' ok';

produce a parse error :
unexpected T_CONSTANT_ENCAPSED_STRING ...

also the following works :
echo 'c='.$a*2..' ok';

so it should be a bug when trying to see
"2." as a float when it is an integer followed by a concatenation
operator (that's the problem when using
operators that are also separators...)





-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19882 [Opn]: Nonfunctional session_decode()

2002-10-13 Thread iliaa


 ID:   19882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Redhat 7.2
 PHP Version:  4CVS-2002-10-12
 New Comment:

But does that page that calls session_decode call session_start itself?


Previous Comments:


[2002-10-12 20:02:38] [EMAIL PROTECTED]

Yes, session_start() is called in another page. I store the session
data string in a local database and pass the session ID from page to
page. 

I should note that I've used these scripts with no problems for MONTHS,
I began experiencing crashes yesterday, for no reason I can identify,
and it's been all downhill from there.



[2002-10-12 19:49:26] [EMAIL PROTECTED]

Did you initialize a session by calling session_start() before calling
session_decode() ?



[2002-10-12 18:51:03] [EMAIL PROTECTED]

This is probably related to the issue described in
http://bugs.php.net/bug.php?id=19877. 

In 4CVs-2002-10-12 session_decode() appears to be non-functional. The
function simply does nothing - no values are returned and no variables
are set. I have verified that I'm passing the function a properly
formatted session data string. 

register_globals is on. Here's my configure line:
./configure --with-mysql --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets

I'm using the CVS version because I was experiencing the session_decode
crash bug with version 4.2.x (see previous bug report - URL given
above). Perhaps these two issues are related?




-- 
Edit this bug report at http://bugs.php.net/?id=19882&edit=1

#19883 [Com]: string concatenation bug

2002-10-13 Thread skaventruc


 ID:   19883
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

and also :

$e = 0x7C.'km'; // is ok '124km'
$e = 124.'km'; // parse error

why do you process decimal integers in different way
than hexadecimal integers ? If it is only to detect
decimal float then you should take care to the fact that
'.' is not only a decimal separator but also a concatenation
operator !!!


Previous Comments:


[2002-10-13 09:41:43] [EMAIL PROTECTED]

maybe you do not consider it as a bug but it is quite
annoying when contatenating arguments, I personnaly
think that this is a lack of the parser/compiler to
do not detect that the '.' is not a part of the '2'
but it is an operator :

putting a '.' after the 2 doesn't change it's display.
$e = 2.3.'km'; // the dot after 2 followed by a digit
   // indicate a float
'2.3km'

$e = 2..'km'; // is ok the the dot after 2 is useless
'2km'

$e = 2.'km'; // produce a parse error
$e = 2 .'km'; // is ok
'2km'



[2002-10-12 22:50:10] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php



[2002-10-12 20:13:42] [EMAIL PROTECTED]

concatenation hazard ... on :

$a = 2;
echo 'c='.$a*2 .' ok';

it produce a good result : "c=4 ok"

but :

$a = 2;
echo 'c='.$a*2.' ok';

produce a parse error :
unexpected T_CONSTANT_ENCAPSED_STRING ...

also the following works :
echo 'c='.$a*2..' ok';

so it should be a bug when trying to see
"2." as a float when it is an integer followed by a concatenation
operator (that's the problem when using
operators that are also separators...)





-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19883 [Bgs]: string concatenation bug

2002-10-13 Thread derick


 ID:   19883
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

Why don't you just use '2km' instead of 2.'km' ?

Derick


Previous Comments:


[2002-10-13 09:46:06] [EMAIL PROTECTED]

and also :

$e = 0x7C.'km'; // is ok '124km'
$e = 124.'km'; // parse error

why do you process decimal integers in different way
than hexadecimal integers ? If it is only to detect
decimal float then you should take care to the fact that
'.' is not only a decimal separator but also a concatenation
operator !!!



[2002-10-13 09:41:43] [EMAIL PROTECTED]

maybe you do not consider it as a bug but it is quite
annoying when contatenating arguments, I personnaly
think that this is a lack of the parser/compiler to
do not detect that the '.' is not a part of the '2'
but it is an operator :

putting a '.' after the 2 doesn't change it's display.
$e = 2.3.'km'; // the dot after 2 followed by a digit
   // indicate a float
'2.3km'

$e = 2..'km'; // is ok the the dot after 2 is useless
'2km'

$e = 2.'km'; // produce a parse error
$e = 2 .'km'; // is ok
'2km'



[2002-10-12 22:50:10] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php



[2002-10-12 20:13:42] [EMAIL PROTECTED]

concatenation hazard ... on :

$a = 2;
echo 'c='.$a*2 .' ok';

it produce a good result : "c=4 ok"

but :

$a = 2;
echo 'c='.$a*2.' ok';

produce a parse error :
unexpected T_CONSTANT_ENCAPSED_STRING ...

also the following works :
echo 'c='.$a*2..' ok';

so it should be a bug when trying to see
"2." as a float when it is an integer followed by a concatenation
operator (that's the problem when using
operators that are also separators...)





-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19883 [NEW]: string concatenation bug

2002-10-13 Thread skaventruc


From: [EMAIL PROTECTED]
Operating system: Windows NT
PHP version:  4.2.0
PHP Bug Type: Strings related
Bug description:  string concatenation bug

concatenation hazard ... on :

$a = 2;
echo 'c='.$a*2 .' ok';

it produce a good result : "c=4 ok"

but :

$a = 2;
echo 'c='.$a*2.' ok';

produce a parse error :
unexpected T_CONSTANT_ENCAPSED_STRING ...

also the following works :
echo 'c='.$a*2..' ok';

so it should be a bug when trying to see
"2." as a float when it is an integer followed by a concatenation operator
(that's the problem when using
operators that are also separators...)

-- 
Edit bug report at http://bugs.php.net/?id=19883&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19883&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19883&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19883&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19883&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19883&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19883&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19883&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19883&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19883&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19883&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19883&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19883&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19883&r=isapi

#19881 [Opn->Fbk]: phpinfo() Security Problem

2002-10-13 Thread sniper


 ID:   19881
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
-Bug Type: Unknown/Other Function
+Bug Type: *General Issues
 Operating System: Win32
 PHP Version:  4.2.3
 New Comment:

If I understood your concern correctly, only thing you
have to do is to set 'expose_php=off' in your php.ini file.



Previous Comments:


[2002-10-12 18:16:16] [EMAIL PROTECTED]

phpinfo() in PHP 4.2.3 uses a special query string to cause a script to
return the PHP logo.  phpinfo() fails to strip any query string off of
the URI before writing it to the browser.  This opens up two issues,
one a nuisance, and the other a more serious security issue:

--- INFO.PHP ---

--- INFO.PHP ---

Yes, I know that's a security risk to allow anonymous users access to
debug information, but this is actually an example of a default script
in many web applications/servers (BadBlue web server, for example).

http://localhost/info.php?";>alert(document.URL)=x

Some browsers will not encode this, and this results in:

alert(document.URL)?=PHPE9568F34-D428-11d2-A769-00AA001ACF42"
border=0 align="right" alt="PHP Logo">

The security issue here is a cross-site scripting exposure -- not only
does PHP fail to strip the query string, it also fails to filter any
HTML entities contained in it.

The nuisance problem is that the ALT tag is displayed, but the script
executes a regular phpinfo(), and returns a bogus image.




-- 
Edit this bug report at http://bugs.php.net/?id=19881&edit=1

#19879 [Com]: Failed build with simple options for apache2

2002-10-13 Thread elkner


 ID:   19879
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: Debian GNU/Linux 3.0
 PHP Version:  4.3.0-pre1
 New Comment:

Pardon? Even without trying that one it is obvious (just by reading the
code),
that this "hack" can´t fix the reported error!

Do you ever analyze the problem and/or test your "hacks" 

More and more I get the feeling, that php never becomes stable and
ready
to use in a production environment!


Previous Comments:


[2002-10-12 07:10:59] [EMAIL PROTECTED]

This is fixed in CVS. Would you be so kind to add the following line
after line 287:
TSRMLS_FETCH();

the code looks like this then:
{
char numbuf[NUM_BUF_SIZE];
char *cvt;
register int i = 0, j = 0;
int sign, decpt;
char decimal_point = EG(float_separator)[0];
TSRMLS_FETCH();

PRINTF_DEBUG(("sprintf: appenddouble(%x, %x, %x, %f, %d, '%c', %d,
%c)\n",
  *buffer, pos, size, number, width, padding,
alignment, fmt));


regards,
Derick




[2002-10-12 03:32:38] [EMAIL PROTECTED]

Hello, plain unzipped php4.3.0-pre1.tar.bz2 and did ./configure
--with-apxs2=/usr/bin/apxs --prefix=/usr/local
And it failed


Here is the last bit of the compile
--
/bin/sh libtool --silent --mode=compile gcc  -Iext/standard/
-I/root/php-4.3.0pre1/ext/standard/ -DPHP_ATOM_INC
-I/root/php-4.3.0pre1/include -I/root/php-4.3.0pre1/main
-I/root/php-4.3.0pre1 -I/usr/include/apache2 -I/root/php-4.3.0pre1/Zend
-I/root/php-4.3.0pre1/ext/xml/expat  -D_REENTRANT
-I/root/php-4.3.0pre1/TSRM -DTHREAD=1  -g -O2 -pthread -DZTS 
-prefer-pic -c /root/php-4.3.0pre1/ext/standard/formatted_print.c -o
ext/standard/formatted_print.lo
/root/php-4.3.0pre1/ext/standard/formatted_print.c: In function
`php_sprintf_appenddouble':
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: `tsrm_ls'
undeclared (first use in this function)
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: (Each
undeclared identifier is reported only once
/root/php-4.3.0pre1/ext/standard/formatted_print.c:287: for each
function it appears in.)
make: *** [ext/standard/formatted_print.lo] Error 1





-- 
Edit this bug report at http://bugs.php.net/?id=19879&edit=1

#19875 [Opn->Bgs]: date/strtotime fails around time change

2002-10-13 Thread sniper


 ID:   19875
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Date/time related
 Operating System: Linux
 PHP Version:  4.2.3
 New Comment:

We are happy to tell you that you just discovered Daylight Savings
Time. For more information see:
http://webexhibits.org/daylightsaving/b.html


Previous Comments:


[2002-10-11 21:37:26] [EMAIL PROTECTED]

Updated summary line.



[2002-10-11 21:36:26] [EMAIL PROTECTED]

Here is a short script:

\n";
 
$okday = mktime(0,0,0,10,27,2002);
$oksun = strtotime("Sun",$okday);
$badmon = strtotime("Mon",$okday);
$okdif = $badmon - $oksun;
$oksunstr = date("Ymd.Hi",$oksun);
$badmonstr = date("Ymd.Hi",$badmon);
print "$okday $okdif $oksunstr $badmonstr \n";
 
echo "PHP version " . phpversion() . " \n";
 
?>

The output of the script is this:

1035097200 86400 20021020. 20021021. 
1035702000 86400 20021027. 20021027.2300 
PHP version 4.2.3 

Although the difference between Sunday (Oct 27) and Monday is 24 hours,
the output from date shows it to be only 23.





-- 
Edit this bug report at http://bugs.php.net/?id=19875&edit=1

#19883 [Opn->Bgs]: string concatenation bug

2002-10-13 Thread sniper


 ID:   19883
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

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


Previous Comments:


[2002-10-12 20:13:42] [EMAIL PROTECTED]

concatenation hazard ... on :

$a = 2;
echo 'c='.$a*2 .' ok';

it produce a good result : "c=4 ok"

but :

$a = 2;
echo 'c='.$a*2.' ok';

produce a parse error :
unexpected T_CONSTANT_ENCAPSED_STRING ...

also the following works :
echo 'c='.$a*2..' ok';

so it should be a bug when trying to see
"2." as a float when it is an integer followed by a concatenation
operator (that's the problem when using
operators that are also separators...)





-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19876 [Csd]: Problem with parse_url() function...

2002-10-13 Thread onionman


 ID:   19876
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: *URL Functions
 Operating System: Windows 2000 Pro (Sp3)
 PHP Version:  4CVS-2002-10-12
 New Comment:

Yep... tested it, and it works fine now.

Thanks for the fast response and fix!  :)

/OnionMan


Previous Comments:


[2002-10-12 14:29:30] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

The latest snapshot has this problem fixed.
http://snaps.php.net/win32/php4-win32-200210121800.zip



[2002-10-12 12:56:00] [EMAIL PROTECTED]

I just tried this snap: php4-win32-200210121400.zip

The result is different, but still incorrect:

Array
(
[scheme] => ftp
[host] => ww.moria.com
[user] => gandalf
[pass] => :mellon@
[path] => /foo/bar/index.php
[query] => page=news
)

host & pass values are wrong...

/OnionMan



[2002-10-12 03:28:35] [EMAIL PROTECTED]

Please wait until the next developer snapshot is generated and try
again.





[2002-10-11 23:31:53] [EMAIL PROTECTED]

The lack for formatting for phpinfo() when html_errors are Off is
intentional. 

parse_url() was recently rewritten from scratch that probably
introduced the bug you are seeing. I'll look into it in more detail.



[2002-10-11 23:26:58] [EMAIL PROTECTED]

Here's a link to the phpinfo at my machine:

http://onionman.homeip.net/phpinfo/

A weird thing i noticed is that if i have 'html_errors = Off' in my
php.ini file, then phpinfo looses all it formatting and is
unreadable... is it supposed to be like this?

Anyway... i doublechecked the parse_url bug by going back to an older
snapshot (2002-10-06), and there it works like expected... and then
trying latest snap again (2002-10-12), and there it's the same result
as before... so either something has introduced a bug there since last
week... or my machine is behaving strange... ;)

/OnionMan



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/19876

-- 
Edit this bug report at http://bugs.php.net/?id=19876&edit=1

#19882 [Opn->Bgs]: Nonfunctional session_decode()

2002-10-13 Thread iliaa


 ID:   19882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Redhat 7.2
 PHP Version:  4CVS-2002-10-12
 New Comment:

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

Unless you do session_start() before doing session_decode(), the latter
will fail to produce valid data. You MUST call session start before
calling session_decode.


Previous Comments:


[2002-10-12 23:21:54] [EMAIL PROTECTED]

To answer iliaa's question: No, session_start is called on a separate
page. 

This is really weird, I made up the following script as per Sniper's
request:



Strangely, THIS script works fine (if it was 'broken', it should output
"false", while it in fact prints "test"). 

However, I've made another script where the error is replicated:
www.dfstudios.com/session_test.php

Here's the source:

session_test.php--
");
?>
>Click here for page
two

session_test2.php--
");
?>

Notice how $testvar is properly set on the first page and encoded
properly, but in the second page $testvar is null. It seems that if
session_start and session_decode are called in separate pages the
decode function fails.



[2002-10-12 21:42:27] [EMAIL PROTECTED]

I closed the other report since it really is same issue.
Please add a short simple script which clearly shows the
problem you're having. And all in one single script, thank you.




[2002-10-12 20:09:30] [EMAIL PROTECTED]

But does that page that calls session_decode call session_start itself?



[2002-10-12 20:02:38] [EMAIL PROTECTED]

Yes, session_start() is called in another page. I store the session
data string in a local database and pass the session ID from page to
page. 

I should note that I've used these scripts with no problems for MONTHS,
I began experiencing crashes yesterday, for no reason I can identify,
and it's been all downhill from there.



[2002-10-12 19:49:26] [EMAIL PROTECTED]

Did you initialize a session by calling session_start() before calling
session_decode() ?



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/19882

-- 
Edit this bug report at http://bugs.php.net/?id=19882&edit=1

#19857 [Opn->Fbk]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread sniper


 ID:   19857
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:

Please provide shortest possible example script that can
be just copy pasted and run. That would help us a lot..


Previous Comments:


[2002-10-13 04:07:53] [EMAIL PROTECTED]

BTW, I apologize for all of the submissions; I mistakenly submitted
more times that I wanted to...



[2002-10-13 04:06:35] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



[2002-10-13 04:06:06] [EMAIL PROTECTED]

I tried changing the order of the fields in the WDDX packet,
removing fields from the WDDX packet, changing the types of the fields
in the WDDX packet, etc., none of this appears to have an impact on how
PHP unserializes the packet.  Also, PHP consistently only populates the
"last" four fields of the aoSuboptions array in the example that I sent
you, no matter how the WDDX packet is modified.

For example, this WDDX packet produces the same unserialized results as
stated in the original submission, even though the order of fields and
field data types in the packet have been changed:

COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?201012185'Da bomb is hear again!  This is a
friggin' quarter pound of good, good stuff!'Dis Shit is Wack!055Wacky
Burger 50

Thus, I would suspect that, since this bug is so easy to reproduce, it
will not be difficult to fix...



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/19857

-- 
Edit this bug report at http://bugs.php.net/?id=19857&edit=1

#19886 [Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread wez


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).


Previous Comments:


[2002-10-13 09:37:40] [EMAIL PROTECTED]

did you checked if php_stream_read() was returning the right filesize
value? that was the first bug.



[2002-10-13 09:10:57] [EMAIL PROTECTED]

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...



[2002-10-13 09:08:03] [EMAIL PROTECTED]

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files.
The Frameset consists of three Frames. Every Frame is PHP-generated.
One functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.





-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19886 [Opn->Fbk]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread wez


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13


Previous Comments:


[2002-10-13 10:02:11] [EMAIL PROTECTED]

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).



[2002-10-13 09:37:40] [EMAIL PROTECTED]

did you checked if php_stream_read() was returning the right filesize
value? that was the first bug.



[2002-10-13 09:10:57] [EMAIL PROTECTED]

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...



[2002-10-13 09:08:03] [EMAIL PROTECTED]

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files.
The Frameset consists of three Frames. Every Frame is PHP-generated.
One functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.





-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19886 [Fbk]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread spic


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
-Bug Type: Reproducible crash
+Bug Type: Performance problem
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

@wez: These scripts don't use sessions. They run of a CD in a
single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors.
But calling it in an frameset (together with two other scripts) crashes
when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles
a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.


Previous Comments:


[2002-10-13 10:02:11] [EMAIL PROTECTED]

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).



[2002-10-13 09:37:40] [EMAIL PROTECTED]

did you checked if php_stream_read() was returning the right filesize
value? that was the first bug.



[2002-10-13 09:10:57] [EMAIL PROTECTED]

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...



[2002-10-13 09:08:03] [EMAIL PROTECTED]

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files.
The Frameset consists of three Frames. Every Frame is PHP-generated.
One functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.





-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19881 [NEW]: phpinfo() Security Problem

2002-10-13 Thread mattmurphy


From: [EMAIL PROTECTED]
Operating system: Win32
PHP version:  4.2.3
PHP Bug Type: Unknown/Other Function
Bug description:  phpinfo() Security Problem

phpinfo() in PHP 4.2.3 uses a special query string to cause a script to
return the PHP logo.  phpinfo() fails to strip any query string off of the
URI before writing it to the browser.  This opens up two issues, one a
nuisance, and the other a more serious security issue:

--- INFO.PHP ---

--- INFO.PHP ---

Yes, I know that's a security risk to allow anonymous users access to
debug information, but this is actually an example of a default script in
many web applications/servers (BadBlue web server, for example).

http://localhost/info.php?";>alert(document.URL)=x

Some browsers will not encode this, and this results in:

alert(document.URL)?=PHPE9568F34-D428-11d2-A769-00AA001ACF42"
border=0 align="right" alt="PHP Logo">

The security issue here is a cross-site scripting exposure -- not only
does PHP fail to strip the query string, it also fails to filter any HTML
entities contained in it.

The nuisance problem is that the ALT tag is displayed, but the script
executes a regular phpinfo(), and returns a bogus image.
-- 
Edit bug report at http://bugs.php.net/?id=19881&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19881&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19881&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19881&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19881&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19881&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19881&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19881&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19881&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19881&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19881&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19881&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19881&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19881&r=isapi

#18375 [Asn->Bgs]: charset support for embedded libmysql

2002-10-13 Thread georg


 ID:   18375
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: all
 PHP Version:  4.2.0
 Assigned To:  zak
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the original bug instead.

Thank you for your interest in PHP.

Duplicate, see #15375 (missing charset support in embedded libmysql).

Georg


Previous Comments:


[2002-07-26 15:36:30] [EMAIL PROTECTED]

Sorry, unfortunately I changed the summary few days before



[2002-07-20 15:32:53] [EMAIL PROTECTED]

Ok, looks like we have to do something with the embedded libmysql
charset support.

Assigned to Zak :)



[2002-07-20 07:44:42] [EMAIL PROTECTED]

i've tested with lastest build
but sorry to tell u that, problem still there


win32 build and bundled libmysql still has no gbk support build-in
gbk and other multibyte charset has to be built in (i don't bother why
have to)
get the same error
MySQL - 1064 - You have an error in your SQL syntax near '' \''' at
line 1

and i have to put gbk.conf in shared/charset dir in order to `fake' a
charset which has to be built-in, although it's not right, but it's my
only way

mysql_character_set_name() return gbk
if didn't put gbk.conf, return latin1, and apache/logs/error.log
complain about missing charset file



[2002-07-20 03:49:07] [EMAIL PROTECTED]

To escape data please use mysql_real_escape_string 
function, which is implemented in the current cvs version.

http://www.php.net/manual/en/function.mysql-real-escape-string.php.




[2002-07-17 02:48:51] [EMAIL PROTECTED]

tested with latest build
still can't pass
also checkout cvs source
it's not libmysql 4



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/18375

-- 
Edit this bug report at http://bugs.php.net/?id=18375&edit=1

#19886 [Fbk->Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread spic


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
-Bug Type: Performance problem
+Bug Type: Reproducible crash
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]


[frame2.php]


[frame3.php]



Previous Comments:


[2002-10-13 10:16:01] [EMAIL PROTECTED]

@wez: These scripts don't use sessions. They run of a CD in a
single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors.
But calling it in an frameset (together with two other scripts) crashes
when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles
a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.



[2002-10-13 10:02:11] [EMAIL PROTECTED]

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).



[2002-10-13 09:37:40] [EMAIL PROTECTED]

did you checked if php_stream_read() was returning the right filesize
value? that was the first bug.



[2002-10-13 09:10:57] [EMAIL PROTECTED]

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...



[2002-10-13 09:08:03] [EMAIL PROTECTED]

Environment: Windows
WebServer: Microweb (CD-WebServer)
PHP-Version: Latest CVS and 4.2.4-dev
PHP is installed as CGI

In a frameset-environment, PHP hangs while outputting large PDF-Files.
The Frameset consists of three Frames. Every Frame is PHP-generated.
One functions as "PDF-Passthrough".

All works fine, if the Passthrough-File is smaller than approx. 100k.
Files >100k make the system hang.

Calling the passthrough-script directly (w/o frameset) causes no
problems.

There is no difference between using readfile, fpassthru, or fread.





-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19886 [Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread nicos


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Reproducible crash
+Bug Type: Performance problem
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

That last comment should let us open it back.

Removing the "big-files-passthrough" let the scripts run properly.

@Wez: can you check it? may be its because of the position of the
stream at the end of the execution of the first checksize?


Previous Comments:


[2002-10-13 10:19:11] [EMAIL PROTECTED]

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]


[frame2.php]


[frame3.php]




[2002-10-13 10:16:01] [EMAIL PROTECTED]

@wez: These scripts don't use sessions. They run of a CD in a
single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors.
But calling it in an frameset (together with two other scripts) crashes
when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles
a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.



[2002-10-13 10:02:11] [EMAIL PROTECTED]

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).



[2002-10-13 09:37:40] [EMAIL PROTECTED]

did you checked if php_stream_read() was returning the right filesize
value? that was the first bug.



[2002-10-13 09:10:57] [EMAIL PROTECTED]

Note: Calling sleep(5) before dumping the PDF solves the problem, so I
think the bug is related to a memory management/multithreading
problem...



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/19886

-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19882 [Fbk->Opn]: Nonfunctional session_decode()

2002-10-13 Thread matt


 ID:   19882
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Redhat 7.2
 PHP Version:  4CVS-2002-10-12
 New Comment:

To answer iliaa's question: No, session_start is called on a separate
page. 

This is really weird, I made up the following script as per Sniper's
request:



Strangely, THIS script works fine (if it was 'broken', it should output
"false", while it in fact prints "test"). 

However, I've made another script where the error is replicated:
www.dfstudios.com/session_test.php

Here's the source:

session_test.php--
");
?>
>Click here for page
two

session_test2.php--
");
?>

Notice how $testvar is properly set on the first page and encoded
properly, but in the second page $testvar is null. It seems that if
session_start and session_decode are called in separate pages the
decode function fails.


Previous Comments:


[2002-10-12 21:42:27] [EMAIL PROTECTED]

I closed the other report since it really is same issue.
Please add a short simple script which clearly shows the
problem you're having. And all in one single script, thank you.




[2002-10-12 20:09:30] [EMAIL PROTECTED]

But does that page that calls session_decode call session_start itself?



[2002-10-12 20:02:38] [EMAIL PROTECTED]

Yes, session_start() is called in another page. I store the session
data string in a local database and pass the session ID from page to
page. 

I should note that I've used these scripts with no problems for MONTHS,
I began experiencing crashes yesterday, for no reason I can identify,
and it's been all downhill from there.



[2002-10-12 19:49:26] [EMAIL PROTECTED]

Did you initialize a session by calling session_start() before calling
session_decode() ?



[2002-10-12 18:51:03] [EMAIL PROTECTED]

This is probably related to the issue described in
http://bugs.php.net/bug.php?id=19877. 

In 4CVs-2002-10-12 session_decode() appears to be non-functional. The
function simply does nothing - no values are returned and no variables
are set. I have verified that I'm passing the function a properly
formatted session data string. 

register_globals is on. Here's my configure line:
./configure --with-mysql --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets

I'm using the CVS version because I was experiencing the session_decode
crash bug with version 4.2.x (see previous bug report - URL given
above). Perhaps these two issues are related?




-- 
Edit this bug report at http://bugs.php.net/?id=19882&edit=1

#16880 [Com]: max_execution_time affects large uploads

2002-10-13 Thread webmaster


 ID:   16880
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Scripting Engine problem
 Operating System: Windows 98
 PHP Version:  4.2.0
 New Comment:

Confirmed in 4.2.3


Previous Comments:


[2002-10-12 14:01:04] [EMAIL PROTECTED]

I have the same problem with iplanet web and IIS in win 2k.



[2002-10-12 10:24:58] [EMAIL PROTECTED]

This should be fixed..




[2002-10-04 08:20:06] [EMAIL PROTECTED]

I have the same problem running Php 4.2 on IIS on a W2K server machine



[2002-07-19 12:23:28] [EMAIL PROTECTED]

I have the same problem running Php 4.2.1 on Apache on a win NT server
machine



[2002-06-16 00:25:53] [EMAIL PROTECTED]

Yes, Apache 1.3.xx



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/16880

-- 
Edit this bug report at http://bugs.php.net/?id=16880&edit=1

#19886 [Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread spic


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Performance problem
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

In addition

[frame1.php]
100k File is called. The next output of a >100k File
// will crash again...
sleep(5); 
header("Content-type: application/pdf\n");
readfile("some_100k_large.pdf");
?>


Previous Comments:


[2002-10-13 10:22:32] [EMAIL PROTECTED]

That last comment should let us open it back.

Removing the "big-files-passthrough" let the scripts run properly.

@Wez: can you check it? may be its because of the position of the
stream at the end of the execution of the first checksize?



[2002-10-13 10:19:11] [EMAIL PROTECTED]

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]


[frame2.php]


[frame3.php]




[2002-10-13 10:16:01] [EMAIL PROTECTED]

@wez: These scripts don't use sessions. They run of a CD in a
single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors.
But calling it in an frameset (together with two other scripts) crashes
when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles
a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.



[2002-10-13 10:02:11] [EMAIL PROTECTED]

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).



[2002-10-13 09:37:40] [EMAIL PROTECTED]

did you checked if php_stream_read() was returning the right filesize
value? that was the first 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/19886

-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19884 [Opn->Bgs]: Functions close connections

2002-10-13 Thread cynic


 ID:   19884
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: FreeBSD && XP
 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.



Previous Comments:


[2002-10-13 00:54:19] [EMAIL PROTECTED]

I have many functions that use a mysql_result_resource that is declared
global (i.e. global $mysql_link).  For some reason after a call to
those functions my mysql_connection disappears/is closed.




-- 
Edit this bug report at http://bugs.php.net/?id=19884&edit=1

#19857 [Com]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread darwin

#19857 [Com]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread darwin

#19886 [Opn]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread nicos


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Performance problem
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

May be its because that the stream hasn't enough time to get its new
position. I didn't read streams.c/h well enough too.


Previous Comments:


[2002-10-13 10:30:31] [EMAIL PROTECTED]

In addition

[frame1.php]
100k File is called. The next output of a >100k File
// will crash again...
sleep(5); 
header("Content-type: application/pdf\n");
readfile("some_100k_large.pdf");
?>



[2002-10-13 10:22:32] [EMAIL PROTECTED]

That last comment should let us open it back.

Removing the "big-files-passthrough" let the scripts run properly.

@Wez: can you check it? may be its because of the position of the
stream at the end of the execution of the first checksize?



[2002-10-13 10:19:11] [EMAIL PROTECTED]

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]


[frame2.php]


[frame3.php]




[2002-10-13 10:16:01] [EMAIL PROTECTED]

@wez: These scripts don't use sessions. They run of a CD in a
single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors.
But calling it in an frameset (together with two other scripts) crashes
when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles
a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.



[2002-10-13 10:02:11] [EMAIL PROTECTED]

Can you reduce this to the simplest combination of scripts?
(That don't use sessions).



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/19886

-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19876 [Fbk->Opn]: Problem with parse_url() function...

2002-10-13 Thread onionman


 ID:   19876
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: *URL Functions
 Operating System: Windows 2000 Pro (Sp3)
-PHP Version:  4CVS-2002-10-11
+PHP Version:  4CVS-2002-10-12
 New Comment:

I just tried this snap: php4-win32-200210121400.zip

The result is different, but still incorrect:

Array
(
[scheme] => ftp
[host] => ww.moria.com
[user] => gandalf
[pass] => :mellon@
[path] => /foo/bar/index.php
[query] => page=news
)

host & pass values are wrong...

/OnionMan


Previous Comments:


[2002-10-12 03:28:35] [EMAIL PROTECTED]

Please wait until the next developer snapshot is generated and try
again.





[2002-10-11 23:31:53] [EMAIL PROTECTED]

The lack for formatting for phpinfo() when html_errors are Off is
intentional. 

parse_url() was recently rewritten from scratch that probably
introduced the bug you are seeing. I'll look into it in more detail.



[2002-10-11 23:26:58] [EMAIL PROTECTED]

Here's a link to the phpinfo at my machine:

http://onionman.homeip.net/phpinfo/

A weird thing i noticed is that if i have 'html_errors = Off' in my
php.ini file, then phpinfo looses all it formatting and is
unreadable... is it supposed to be like this?

Anyway... i doublechecked the parse_url bug by going back to an older
snapshot (2002-10-06), and there it works like expected... and then
trying latest snap again (2002-10-12), and there it's the same result
as before... so either something has introduced a bug there since last
week... or my machine is behaving strange... ;)

/OnionMan



[2002-10-11 23:00:11] [EMAIL PROTECTED]

The 1 comes from 'echo print_r' you do not need to echo print_r() it'll
do it automatically. The missing letter is something I am unable to
replicate on any of my machines. Could you please should output of
phpinfo() on your system, maybe that'll yeild some clues.



[2002-10-11 22:54:02] [EMAIL PROTECTED]

Snapshot used: php4-win32-200210120200.zip

This simple script parses an ftp-url:

ftp://gandalf:[EMAIL PROTECTED]/foo/bar/index.php?page=news";;

$parts = parse_url($url);

echo ''."\n";
echo print_r($parts)."\n";
echo ''."\n";
?>

When i run the script i get this output:

Array
(
[scheme] => ftp
[host] => www.moria.com
[user] => gandalf
[pass] => mello
[path] => /foo/bar/index.php
[query] => page=news
)
1

Note the cropped password value... it is cropped by one charachter...
last snapshot i tested (2002-10-06) did not have this behaviour.

BTW: What does the 1 that is output after the value pairs mean?




-- 
Edit this bug report at http://bugs.php.net/?id=19876&edit=1

#19877 [Fbk->Opn]: Apache segmentation faults

2002-10-13 Thread matt


 ID:   19877
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: RH Linux 7.2
 PHP Version:  4.2.3
 New Comment:

I've managed to resolve the problem. First I recompiled php without
ldap, zlib or the image library options and recompiled Apache from
scratch with the new PHP. That produced no effect. However, recompiling
from the 4.3.0-dev source (CVS snapshot) fixed the error.


Previous Comments:


[2002-10-12 02:18:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


Try first the snapshot. If it crashes too:
Just in case you didn't read this: 

http://bugs.php.net/bugs-generating-backtrace.php

(add --enable-debug to your configure line)

Also, did you update your php.ini at any time?
And could you please add the shortest possible
example script here which can be used to reproduce this problem..




[2002-10-11 23:33:30] [EMAIL PROTECTED]

I was using Apache 1.3.26 with PHP 4.2.1 for about 3 months with no
problems, then one day I discovered unable to access certain PHP pages
(IE would give me a Cannot Find Server error). In my error logs I get
lines like this:

[Fri Oct 11 21:10:55 2002] [notice] Apache/1.3.26 (Unix) PHP/4.2.1
configured -- resuming normal operations
[Fri Oct 11 21:10:55 2002] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Fri Oct 11 21:10:59 2002] [notice] child pid 1226 exit signal
Segmentation fault (11)
[Fri Oct 11 21:15:18 2002] [notice] caught SIGTERM, shutting down
[Fri Oct 11 23:32:27 2002] [notice] Apache/1.3.27 (Unix) PHP/4.2.3
configured -- resuming normal operations
[Fri Oct 11 23:32:27 2002] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Fri Oct 11 23:32:41 2002] [notice] child pid 12347 exit signal
Segmentation fault (11)
[Fri Oct 11 23:32:41 2002] [notice] child pid 12345 exit signal
Segmentation fault (11)
[Fri Oct 11 23:32:42 2002] [notice] child pid 12348 exit signal
Segmentation fault (11)
[Fri Oct 11 23:32:42 2002] [notice] child pid 12346 exit signal
Segmentation fault (11)

I tried restarting apache (using both restart and stop/start), then
rebooting my server, then recompiling and reinstalling both PHP and
Apache (you can see in the error log how the version changes from
1.3.26/4.2.1 to 1.3.27/4.2.3) but nothing seemed to work. 

Other PHP scripts (including phpMyAdmin) work fine. The only difference
I can see between the "offending" script and my functional ones is the
broken one uses session_decode() and header(). As far as I know,
everything was working fine until today. The only change was about a
month ago, when I recompiled PHP and added in support for GD, Jpeg-6b,
zlib and ldap. Could one of those be the source of error?

My configure line is: 
./configure --with-mysql --with-jpeg-dir=/root/jpeg-6b --with-gd
--with-zlib --with-ldap --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets 

I tried diagnosing the problem using gdb but this is all I got:

(gdb) run -X
Starting program: /www/bin/httpd -X

Program received signal SIGTRAP, Trace/breakpoint trap.
0x40001e90 in _start () at rtld.c:160
160 rtld.c: No such file or directory.
in rtld.c
(gdb)

Nothing came up when I accessed the "culprit" scripts. The one error
that I can see there occured immediately at the start and in both
versions of Apache/PHP.




-- 
Edit this bug report at http://bugs.php.net/?id=19877&edit=1

#19882 [NEW]: Nonfunctional session_decode()

2002-10-13 Thread matt


From: [EMAIL PROTECTED]
Operating system: Redhat 7.2
PHP version:  4CVS-2002-10-12
PHP Bug Type: Session related
Bug description:  Nonfunctional session_decode() 

This is probably related to the issue described in
http://bugs.php.net/bug.php?id=19877. 

In 4CVs-2002-10-12 session_decode() appears to be non-functional. The
function simply does nothing - no values are returned and no variables are
set. I have verified that I'm passing the function a properly formatted
session data string. 

register_globals is on. Here's my configure line:
./configure --with-mysql --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets

I'm using the CVS version because I was experiencing the session_decode
crash bug with version 4.2.x (see previous bug report - URL given above).
Perhaps these two issues are related?
-- 
Edit bug report at http://bugs.php.net/?id=19882&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19882&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19882&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19882&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19882&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19882&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19882&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19882&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19882&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19882&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19882&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19882&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19882&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19882&r=isapi

#19586 [Com]: unset( $_SESSION['variable'] ) <- Fails with registered_globals 'on'

2002-10-13 Thread aarong


 ID:   19586
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Session related
 Operating System: ALL
 PHP Version:  4.2.2
 New Comment:

This problem is definitely not fixed in version 4.2.3. I'm running
Linux on a Cobalt RaQ 3i, and this is driving me up a wall...


Previous Comments:


[2002-09-25 06:36:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I think this was fixed in 4.2.3, but it might just be in head.  It's
been awhile since I saw the fix... try it anyways.



[2002-09-24 22:23:06] [EMAIL PROTECTED]

Below is the PHP Documentation on unregistering session variables...

Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is
used, use unset() to unregister a session variable.

unset( $_SESSION['variable'] ) fails to unset the given session
variable with registered_globals turned 'on' in ini file. It is safe to
say that this is true on all operating systems. PHP versions this was
tested on is 4.1.1 and 4.2.2, accross many different operating systems.
Using unset( $_SESSION['variable'] ) will unset the variable on the
current page only, and will not unset it in the global space.

We have come up with a workaround that works fine with
registered_globals on. See Below -->

---
unset( $_SESSION['variable'], $variable );
---

The above works fine. I believe that the documentation needs to reflect
this problem as countless developers in our community (Forums @
DevShed) has posted related problems using 'unset(
$_SESSION['variable'] )'

This applies only when registered_globals is truned 'on'.

unset( $_SESSION['variable'] ) works fine with registered_globals
'off'.








-- 
Edit this bug report at http://bugs.php.net/?id=19586&edit=1

#19404 [Com]: phpMyAdmin does not work properly anymore

2002-10-13 Thread khalil


 ID:   19404
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: mbstring related
 Operating System: SuSE Linux 8.0
 PHP Version:  4.2.3
 New Comment:

This is the same issue which was reported here
http://bugs.php.net/bug.php?id=19460
I was advised to take latest PHP from CVS. I did and the problem was
solved.


Previous Comments:


[2002-09-14 11:33:54] [EMAIL PROTECTED]

Reclassify



[2002-09-14 11:32:01] [EMAIL PROTECTED]

This was a problem with mbstring that has been fixed in CVS.
The workaround is not to use --enable-mbstr-enc-trans
when configuring PHP. (You won't miss it, because the
chances are that you don't even know what it does :-)



[2002-09-14 11:19:10] [EMAIL PROTECTED]

Hm, but its a strange behaviour of PHP if the same script worked from
Version 4.0.0 up to 4.2.2 and just stopped with 4.2.3. I don't believe
this is because of the script :) Even the configuration file has been
adapeted (MagicQuoting, SafeMode, RegisterGlobals etc)



[2002-09-14 10:53:14] [EMAIL PROTECTED]

Sorry, but the bug system is not the appropriate forum for asking
support questions. 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

Thank you for your interest in PHP.





[2002-09-14 08:55:38] [EMAIL PROTECTED]

Since I'm using PHP 4.2.3 phpMyAdmin (http://www.phpmyadmin.net) does
not work properly anymore. To me it seems as if string routines would
be broken. As an example I have two errormessages generated from
phpMyAdmin:

Creating a simple table with ID as auto_increment:

--
CREATE TABLE `atest` (

`ID` INT NULL _INCREMENT,
PRIMARY KEY ( `ID` ) 
) 

MySQL meldet: 


You have an error in your SQL syntax near '_INCREMENT, PRIMARY KEY
(`ID`))' at line 1
--

It seems as if this PHP version would kill the "auto" in front of
"_increment". Of course, then MySQL produces an error.

Second example: If I change a value (DATE), I get the following error:

--
UPDATE `termine` SET `datum` = '-09-23' WHERE `ID` = \'42\' LIMIT 1; 

MySQL meldet: 


You have an error in your SQL syntax near '\'42\' LIMIT 1' at line 1
--

There is one ' too much (changing MagicQuotes did not help anything)

I do not thing that this is a problem of phpMyAdmin because I just
recompiled PHP 4.2.2 with exactly the same configure options on the
same system (2 days difference, so no new libraries etc) and everything
works just perfect.

My confiugure Line:
--
'./configure' '--prefix=/usr/share' '--datadir=/usr/share/php'
'--bindir=/usr/bin' '--libdir=/usr/share' '--includedir=/usr/include'
'--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/lib/php/bin'
'--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'
'--enable-inline-optimization' '--enable-magic-quotes'
'--enable-mbstr-enc-trans' '--enable-mbstring' '--enable-memory-limit'
'--enable-shmop' '--enable-sigchild' '--enable-sysvsem'
'--enable-sysvshm' '--enable-track-vars' '--enable-versioning'
'--enable-wddx' '--enable-yp' '--with-bz2' '--with-ftp' '--with-gdbm'
'--with-gettext' '--with-gmp' '--with-imap=yes'
'--with-jpeg-dir=/usr/lib' '--with-ldap=yes' '--with-mcal=/usr'
'--with-mcrypt' '--with-mysql=/usr' '--with-ndbm' '--with-pgsql=/usr'
'--with-snmp' '--with-t1lib' '--with-ttf' '--with-freetype-dir=yes'
'--with-zlib=yes' '--with-openssl' '--with-curl' '--with-imap-ssl'
'--with-gd=yes' '--with-mm' '--with-apxs=/usr/sbin/apxs' '--with-ming'
'--with-mhash' '--with-pdflib' '--with-png-dir=/usr/lib'
'--with-tiffs-dir=/usr/lib' '--with-iodbc'
--
I do not include a backtrace because PHP does not crash at all. The
system continues to run, the page gets finished and I can continue to
work with PHP.




-- 
Edit this bug report at http://bugs.php.net/?id=19404&edit=1

#19877 [Opn->Csd]: Apache segmentation faults

2002-10-13 Thread iliaa


 ID:   19877
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: RH Linux 7.2
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

User reports that the problem has been resolved in the CVS.


Previous Comments:


[2002-10-12 13:02:03] [EMAIL PROTECTED]

I've managed to resolve the problem. First I recompiled php without
ldap, zlib or the image library options and recompiled Apache from
scratch with the new PHP. That produced no effect. However, recompiling
from the 4.3.0-dev source (CVS snapshot) fixed the error.



[2002-10-12 02:18:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


Try first the snapshot. If it crashes too:
Just in case you didn't read this: 

http://bugs.php.net/bugs-generating-backtrace.php

(add --enable-debug to your configure line)

Also, did you update your php.ini at any time?
And could you please add the shortest possible
example script here which can be used to reproduce this problem..




[2002-10-11 23:33:30] [EMAIL PROTECTED]

I was using Apache 1.3.26 with PHP 4.2.1 for about 3 months with no
problems, then one day I discovered unable to access certain PHP pages
(IE would give me a Cannot Find Server error). In my error logs I get
lines like this:

[Fri Oct 11 21:10:55 2002] [notice] Apache/1.3.26 (Unix) PHP/4.2.1
configured -- resuming normal operations
[Fri Oct 11 21:10:55 2002] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Fri Oct 11 21:10:59 2002] [notice] child pid 1226 exit signal
Segmentation fault (11)
[Fri Oct 11 21:15:18 2002] [notice] caught SIGTERM, shutting down
[Fri Oct 11 23:32:27 2002] [notice] Apache/1.3.27 (Unix) PHP/4.2.3
configured -- resuming normal operations
[Fri Oct 11 23:32:27 2002] [notice] Accept mutex: sysvsem (Default:
sysvsem)
[Fri Oct 11 23:32:41 2002] [notice] child pid 12347 exit signal
Segmentation fault (11)
[Fri Oct 11 23:32:41 2002] [notice] child pid 12345 exit signal
Segmentation fault (11)
[Fri Oct 11 23:32:42 2002] [notice] child pid 12348 exit signal
Segmentation fault (11)
[Fri Oct 11 23:32:42 2002] [notice] child pid 12346 exit signal
Segmentation fault (11)

I tried restarting apache (using both restart and stop/start), then
rebooting my server, then recompiling and reinstalling both PHP and
Apache (you can see in the error log how the version changes from
1.3.26/4.2.1 to 1.3.27/4.2.3) but nothing seemed to work. 

Other PHP scripts (including phpMyAdmin) work fine. The only difference
I can see between the "offending" script and my functional ones is the
broken one uses session_decode() and header(). As far as I know,
everything was working fine until today. The only change was about a
month ago, when I recompiled PHP and added in support for GD, Jpeg-6b,
zlib and ldap. Could one of those be the source of error?

My configure line is: 
./configure --with-mysql --with-jpeg-dir=/root/jpeg-6b --with-gd
--with-zlib --with-ldap --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets 

I tried diagnosing the problem using gdb but this is all I got:

(gdb) run -X
Starting program: /www/bin/httpd -X

Program received signal SIGTRAP, Trace/breakpoint trap.
0x40001e90 in _start () at rtld.c:160
160 rtld.c: No such file or directory.
in rtld.c
(gdb)

Nothing came up when I accessed the "culprit" scripts. The one error
that I can see there occured immediately at the start and in both
versions of Apache/PHP.




-- 
Edit this bug report at http://bugs.php.net/?id=19877&edit=1

#19873 [Opn->Bgs]: Unable to load dynamic library 'c:\php\php_interbase.dll' dialog box error.

2002-10-13 Thread sniper


 ID:   19873
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: InterBase related
 Operating System: Windows XP Professional
 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.


Look here:

http://www.php.net/manual/en/install.windows.php#install.windows.extensions

You need the extra dll...



Previous Comments:


[2002-10-11 18:35:48] [EMAIL PROTECTED]

I'm trying to make a connection to an Interbase 5 database with the
following code:

email, "\n";
//} 
ibase_free_result($sth);
ibase_close($dbh);
?>

NOTE: The lines as comments are for testing purposes.

My problem is I get a dialog box with the following error message:

Unable to load dynamic library 'c:\php\php_interbase.dll'.

I made sure the extensions path is correct and the php_interbase.dll
line isn't commented in php.ini like this:

extension_dir = c:\php\extensions\

extension=php_interbase.dll

I have been looking for a way to fix this on the web but I haven't
found anything. Does this only work with Interbase 6?




-- 
Edit this bug report at http://bugs.php.net/?id=19873&edit=1

#19881 [Com]: phpinfo() Security Problem

2002-10-13 Thread mattmurphy


 ID:   19881
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: *General Issues
 Operating System: Win32
 PHP Version:  4.2.3
 New Comment:

That setting does indeed eliminate the image tag bug.  It could be used
as a temporary workaround for this issue.  The correct behavior would
be for PHP to eradicate the query string before using it in a URL.


Previous Comments:


[2002-10-12 22:42:53] [EMAIL PROTECTED]

If I understood your concern correctly, only thing you
have to do is to set 'expose_php=off' in your php.ini file.




[2002-10-12 18:16:16] [EMAIL PROTECTED]

phpinfo() in PHP 4.2.3 uses a special query string to cause a script to
return the PHP logo.  phpinfo() fails to strip any query string off of
the URI before writing it to the browser.  This opens up two issues,
one a nuisance, and the other a more serious security issue:

--- INFO.PHP ---

--- INFO.PHP ---

Yes, I know that's a security risk to allow anonymous users access to
debug information, but this is actually an example of a default script
in many web applications/servers (BadBlue web server, for example).

http://localhost/info.php?";>alert(document.URL)=x

Some browsers will not encode this, and this results in:

alert(document.URL)?=PHPE9568F34-D428-11d2-A769-00AA001ACF42"
border=0 align="right" alt="PHP Logo">

The security issue here is a cross-site scripting exposure -- not only
does PHP fail to strip the query string, it also fails to filter any
HTML entities contained in it.

The nuisance problem is that the ALT tag is displayed, but the script
executes a regular phpinfo(), and returns a bogus image.




-- 
Edit this bug report at http://bugs.php.net/?id=19881&edit=1

#19877 [Opn->Bgs]: Apache segmentation faults

2002-10-13 Thread sniper


 ID:   19877
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: RH Linux 7.2
 PHP Version:  4.2.3
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the original bug instead.

Thank you for your interest in PHP.


Bogusing this since you opened new report about the real issue..and
this segfault was obviously fixed in the CVS.
Please, just one report per issue, thank you.



Previous Comments:


[2002-10-12 14:11:06] [EMAIL PROTECTED]

I need to re-open this bug as I've discovered that using 4.3.0 is not a
valid solution for me. Rather than fixing the problem it seems to
simply abort execution of functions as they begin to crash, meaning
that no output is generated and in the end I'm no better off. 

I have determined that session_decode() is the source of the error,
here's a gdb backtrace:

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x400ce271 in php_set_session_var (name=0x80bb134 "player_id",
namelen=9, 
state_val=0x80bb174, var_hash=0xbfffa528) at session.c:290
290 zend_set_hash_symbol(state_val, name,
namelen, 1, 2, Z_ARRVAL_P(PS(http_session_vars)), &EG(symbol_table));
(gdb) bt
#0  0x400ce271 in php_set_session_var (name=0x80bb134 "player_id",
namelen=9, 
state_val=0x80bb174, var_hash=0xbfffa528) at session.c:290
#1  0x400ce83e in __lock_checklocker () at session.c:441
#2  0x400cea49 in php_session_decode (
val=0x80baf54
"id|s:1:\"1\";name|s:8:\"Specterx\";cont_id|s:1:\"1\";", vallen=184)
at session.c:490
#3  0x400d13ac in log_archive () at session.c:1340
#4  0x4017ef27 in new_heap (size=134983936) at malloc.c:2118
#5  0x4015a126 in zend_execute_scripts () at printf_fp.c:241
#6  0x400a0c42 in php_execute_script (primary_file=0xbfffe830) at
main.c:1383
#7  0x401657aa in apache_php_module_main () at psignal.c:62
#8  0x4009ce74 in nis_clone_object (src=0x80a6dc4, dest=0x0)
at nis_clone_obj.c:34
#9  0x4009cee1 in send_parsed_php () at nis_clone_obj.c:59
#10 0x40189577 in ap_invoke_handler () at argz-replace.c:125
#11 0x401a0b1f in process_request_internal () at
../stdlib/strtod.c:906
#12 0x401a0b93 in ap_process_request () at ../stdlib/strtod.c:1006
#13 0x40196ab5 in child_main () at ../stdlib/strtod.c:294
#14 0x40196c80 in make_child () at ../stdlib/strtod.c:938
#15 0x40196e14 in startup_children () at ../stdlib/strtod.c:807
#16 0x4019754a in __wcstof_internal (nptr=0x2, endptr=0xbfffeca4, 
---Type  to continue, or q  to quit---
group=-1073746920) at ../stdlib/strtod.c:603
#17 0x40197f5e in ap_main () at ../stdlib/strtod.c:283
#18 0x08048711 in ?? ()
#19 0x4031d627 in ?? (), 
(gdb) frame 2
#2  0x400cea49 in php_session_decode (
val=0x80baf54
"id|s:1:\"1\";name|s:8:\"Specterx\";cont_id|s:1:\"1\";", vallen=184)
at session.c:490
490 if (PS(serializer)->decode(val, vallen TSRMLS_CC) ==
FAILURE) {
(gdb) Quit  

I tested my theory by commenting out the call to session_decode() in
the offending script and manually setting the variables that I needed
instead. Lo and behold, it worked. 

Up to this point I have rebooted my server at least twice and
recompiled and reinstalled PHP and Apache numerous times.



[2002-10-12 13:08:26] [EMAIL PROTECTED]

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

User reports that the problem has been resolved in the CVS.



[2002-10-12 13:02:03] [EMAIL PROTECTED]

I've managed to resolve the problem. First I recompiled php without
ldap, zlib or the image library options and recompiled Apache from
scratch with the new PHP. That produced no effect. However, recompiling
from the 4.3.0-dev source (CVS snapshot) fixed the error.



[2002-10-12 02:18:34] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip


Try first the

#19882 [Opn->Fbk]: Nonfunctional session_decode()

2002-10-13 Thread sniper


 ID:   19882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Redhat 7.2
 PHP Version:  4CVS-2002-10-12
 New Comment:

I closed the other report since it really is same issue.
Please add a short simple script which clearly shows the
problem you're having. And all in one single script, thank you.



Previous Comments:


[2002-10-12 20:09:30] [EMAIL PROTECTED]

But does that page that calls session_decode call session_start itself?



[2002-10-12 20:02:38] [EMAIL PROTECTED]

Yes, session_start() is called in another page. I store the session
data string in a local database and pass the session ID from page to
page. 

I should note that I've used these scripts with no problems for MONTHS,
I began experiencing crashes yesterday, for no reason I can identify,
and it's been all downhill from there.



[2002-10-12 19:49:26] [EMAIL PROTECTED]

Did you initialize a session by calling session_start() before calling
session_decode() ?



[2002-10-12 18:51:03] [EMAIL PROTECTED]

This is probably related to the issue described in
http://bugs.php.net/bug.php?id=19877. 

In 4CVs-2002-10-12 session_decode() appears to be non-functional. The
function simply does nothing - no values are returned and no variables
are set. I have verified that I'm passing the function a properly
formatted session data string. 

register_globals is on. Here's my configure line:
./configure --with-mysql --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets

I'm using the CVS version because I was experiencing the session_decode
crash bug with version 4.2.x (see previous bug report - URL given
above). Perhaps these two issues are related?




-- 
Edit this bug report at http://bugs.php.net/?id=19882&edit=1

#19882 [Opn->Fbk]: Nonfunctional session_decode()

2002-10-13 Thread iliaa


 ID:   19882
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Redhat 7.2
 PHP Version:  4CVS-2002-10-12
 New Comment:

Did you initialize a session by calling session_start() before calling
session_decode() ?


Previous Comments:


[2002-10-12 18:51:03] [EMAIL PROTECTED]

This is probably related to the issue described in
http://bugs.php.net/bug.php?id=19877. 

In 4CVs-2002-10-12 session_decode() appears to be non-functional. The
function simply does nothing - no values are returned and no variables
are set. I have verified that I'm passing the function a properly
formatted session data string. 

register_globals is on. Here's my configure line:
./configure --with-mysql --with-apache=/root/apache_1.3.27
--enable-track-vars --enable-trans-sid --enable-sigchild --enable-ftp
--enable-debug --enable-sockets

I'm using the CVS version because I was experiencing the session_decode
crash bug with version 4.2.x (see previous bug report - URL given
above). Perhaps these two issues are related?




-- 
Edit this bug report at http://bugs.php.net/?id=19882&edit=1

#19883 [Com]: string concatenation bug

2002-10-13 Thread skaventruc


 ID:   19883
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

and when you want to concatenate with dynamic
calculated infos ?

$i = 153;
echo $i*2.'km';


Previous Comments:


[2002-10-13 09:47:57] [EMAIL PROTECTED]

Why don't you just use '2km' instead of 2.'km' ?

Derick



[2002-10-13 09:46:06] [EMAIL PROTECTED]

and also :

$e = 0x7C.'km'; // is ok '124km'
$e = 124.'km'; // parse error

why do you process decimal integers in different way
than hexadecimal integers ? If it is only to detect
decimal float then you should take care to the fact that
'.' is not only a decimal separator but also a concatenation
operator !!!



[2002-10-13 09:41:43] [EMAIL PROTECTED]

maybe you do not consider it as a bug but it is quite
annoying when contatenating arguments, I personnaly
think that this is a lack of the parser/compiler to
do not detect that the '.' is not a part of the '2'
but it is an operator :

putting a '.' after the 2 doesn't change it's display.
$e = 2.3.'km'; // the dot after 2 followed by a digit
   // indicate a float
'2.3km'

$e = 2..'km'; // is ok the the dot after 2 is useless
'2km'

$e = 2.'km'; // produce a parse error
$e = 2 .'km'; // is ok
'2km'



[2002-10-12 22:50:10] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php



[2002-10-12 20:13:42] [EMAIL PROTECTED]

concatenation hazard ... on :

$a = 2;
echo 'c='.$a*2 .' ok';

it produce a good result : "c=4 ok"

but :

$a = 2;
echo 'c='.$a*2.' ok';

produce a parse error :
unexpected T_CONSTANT_ENCAPSED_STRING ...

also the following works :
echo 'c='.$a*2..' ok';

so it should be a bug when trying to see
"2." as a float when it is an integer followed by a concatenation
operator (that's the problem when using
operators that are also separators...)





-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19869 [Fbk->Csd]: bug in array_rand

2002-10-13 Thread edink


 ID:   19869
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: windows
 PHP Version:  4.2.2
 New Comment:

Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php




Previous Comments:


[2002-10-11 15:04:38] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip



[2002-10-11 13:12:25] [EMAIL PROTECTED]

I've found a bug with array_rand in PHP 4.2.2; it works in earlier
versions, however when tested in newer PHP versions the output never
changes.

eg.
srand ((double)microtime()*100);
$backgrounds = range (1,28);
$rand_keys = array_rand ($backgrounds, 3);
print
$backgrounds[$rand_keys[0]]."~".$backgrounds[$rand_keys[1]]."~".$backgrounds[$rand_keys[2]];


This would always for me produce the same results for me whatever I
try.




-- 
Edit this bug report at http://bugs.php.net/?id=19869&edit=1

#19872 [Opn->Fbk]: ssl:// doesn't appear to work correctly

2002-10-13 Thread wez


 ID:   19872
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Solaris
 PHP Version:  4.3.0-pre1
 New Comment:

We need more information than that...
Please post a short script that reproduces the problem,
and include the output you are getting and also the output you were
expecting.


Previous Comments:


[2002-10-11 16:52:54] [EMAIL PROTECTED]

using $fp=fsockopen("ssl://".$hostname,$port,$errno,$errstr,100); the
connection doesn't seem to work correctly. There's either no connection
being made or the response is not being gotten correctly.

Also, according to the docs on
http://www.php.net/manual/en/function.stream-get-meta-data.php, there
are additional items in the array returned which aren't there.




-- 
Edit this bug report at http://bugs.php.net/?id=19872&edit=1

#19883 [Bgs]: string concatenation bug

2002-10-13 Thread spic


 ID:   19883
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

In that case, simply use

$i = 153;
echo $i*2
echo 'km';

or printf()...


Previous Comments:


[2002-10-13 11:16:05] [EMAIL PROTECTED]

and when you want to concatenate with dynamic
calculated infos ?

$i = 153;
echo $i*2.'km';



[2002-10-13 09:47:57] [EMAIL PROTECTED]

Why don't you just use '2km' instead of 2.'km' ?

Derick



[2002-10-13 09:46:06] [EMAIL PROTECTED]

and also :

$e = 0x7C.'km'; // is ok '124km'
$e = 124.'km'; // parse error

why do you process decimal integers in different way
than hexadecimal integers ? If it is only to detect
decimal float then you should take care to the fact that
'.' is not only a decimal separator but also a concatenation
operator !!!



[2002-10-13 09:41:43] [EMAIL PROTECTED]

maybe you do not consider it as a bug but it is quite
annoying when contatenating arguments, I personnaly
think that this is a lack of the parser/compiler to
do not detect that the '.' is not a part of the '2'
but it is an operator :

putting a '.' after the 2 doesn't change it's display.
$e = 2.3.'km'; // the dot after 2 followed by a digit
   // indicate a float
'2.3km'

$e = 2..'km'; // is ok the the dot after 2 is useless
'2km'

$e = 2.'km'; // produce a parse error
$e = 2 .'km'; // is ok
'2km'



[2002-10-12 22:50:10] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php



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/19883

-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#16880 [Com]: max_execution_time affects large uploads

2002-10-13 Thread pbaum


 ID:   16880
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Scripting Engine problem
 Operating System: Windows 98
 PHP Version:  4.2.0
 New Comment:

I have the same problem with iplanet web and IIS in win 2k.


Previous Comments:


[2002-10-12 10:24:58] [EMAIL PROTECTED]

This should be fixed..




[2002-10-04 08:20:06] [EMAIL PROTECTED]

I have the same problem running Php 4.2 on IIS on a W2K server machine



[2002-07-19 12:23:28] [EMAIL PROTECTED]

I have the same problem running Php 4.2.1 on Apache on a win NT server
machine



[2002-06-16 00:25:53] [EMAIL PROTECTED]

Yes, Apache 1.3.xx



[2002-06-16 00:09:44] [EMAIL PROTECTED]

Which webserver? Apache 1.3.xx?




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/16880

-- 
Edit this bug report at http://bugs.php.net/?id=16880&edit=1

#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory

2002-10-13 Thread hank


 ID:   19292
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Apache related
 Operating System: linux
 PHP Version:  4.2.3
 New Comment:

I notice the same problem with an earlier version (4.1.2-5) on a Debian
3.0 system running Apache 1.3.26.  Hope that provides aid in tracking
this down.

The script used to reproduce this is simply phpinfo();


Previous Comments:


[2002-10-11 13:15:49] [EMAIL PROTECTED]

I can confirm the message from [EMAIL PROTECTED]

Same problem here on several linux boxes that servers a nummer of
virtual host. On some vhosts we have these error on every 2nd hit.

There is a chance that these kind of error not effected is to the first
vhost.

I have made a test with the latest 'php4-20021010' with shows the
same behavior.

Realy weird is that the unkown error messages shows the WRONG settings
(open_basedir) for that vhosts.
Screenshot:
http://sgi.takenet.de/~beh/error.gif

They are 2 other things out there that apps that using pear(cache)
shows open_basedir restrictions too. But the pear directory is always
allowed.

The make install prozess from the php latest and php-4.3rc1 shows both


tng-web:/usr/src/php-4.3.0pre1 # make install
Installing PHP SAPI module
[activating module `php4' in /usr/apache/conf/httpd.conf]
cp libs/libphp4.so /usr/apache/libexec/libphp4.so
chmod 755 /usr/apache/libexec/libphp4.so
cp /usr/apache/conf/httpd.conf /usr/apache/conf/httpd.conf.bak
cp /usr/apache/conf/httpd.conf.new /usr/apache/conf/httpd.conf
rm /usr/apache/conf/httpd.conf.new
Installing shared extensions:
/usr/lib/php/extensions/no-debug-non-zts-20020429/
Installing PHP CLI binary:/usr/bin/
Installing PEAR environment:  /usr/lib/php/

Warning: file_exists() [http://www.php.net/function.file-exists]: SAFE
MODE Restriction in effect.  The script whose uid is 500 is not allowed
to access /root owned by uid 0 in
/daten/src/php-4.3.0pre1/pear/PEAR/Config.php on line 282

a lot of more warnings.
Screenshot:
http://sgi.takenet.de/~beh/error2.gif

We are not using any kind of caching software or other 3rd party
modules. And yes.. switching back to 4.2.1 solves all the problems
without making any changes on configfiles (php.ini , httpd.conf)



[2002-10-10 08:43:37] [EMAIL PROTECTED]

Keep this at 'Critical' status.
([EMAIL PROTECTED]: Can you be a bit more specific? And did you test with PHP
4.3.0-dev there?)




[2002-10-10 05:05:17] [EMAIL PROTECTED]

Same here, yet only on one of four production boxes. Error randomly
pops up, and is gone after reloading (seems to be only one apache child
at a time is effected).

Seems like the error occurs for all functions using file i/o, mainly
include() in our case.



[2002-10-09 13:13:09] [EMAIL PROTECTED]

Could someone please check if this is still a problem in current CVS?



[2002-10-05 19:28:45] [EMAIL PROTECTED]

Keep it critical.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19292

-- 
Edit this bug report at http://bugs.php.net/?id=19292&edit=1

#19883 [Com]: string concatenation bug

2002-10-13 Thread skaventruc


 ID:   19883
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

Yes, of course,
I was only thinking that the advantage of PHP over C
was that we can concatenate easily strings with
expressions and functions results when setting variable,
calling functions ...

this syntax allow to do :

something('a='.$a.' and f(a)*2 = '.f($a)*2.' ...');

instead of :
$str = 'a=';
$str .= $a;
$str .= ' and f(a)*2 = ';
$str .= f($a)*2;
$str .= ' ...';
something($str);

or :
$str = sprintf('a=%d and f(a)*2 = %d ...', $a, f($a)*2);
something($str);

I really think that if you allow this kind of concatenation
to avoid complex string composition, then the 'float'
problem is a bug, standard C does not allow dynamic
string concatenation but in C++ you can overload the '+'
operator and there is no confusion with the '.'

I know there is always a way to overcome the problem
in syntax, my report is only about something that
appear to me to be an error.

Julien.


Previous Comments:


[2002-10-13 11:38:29] [EMAIL PROTECTED]

In that case, simply use

$i = 153;
echo $i*2
echo 'km';

or printf()...



[2002-10-13 11:16:05] [EMAIL PROTECTED]

and when you want to concatenate with dynamic
calculated infos ?

$i = 153;
echo $i*2.'km';



[2002-10-13 09:47:57] [EMAIL PROTECTED]

Why don't you just use '2km' instead of 2.'km' ?

Derick



[2002-10-13 09:46:06] [EMAIL PROTECTED]

and also :

$e = 0x7C.'km'; // is ok '124km'
$e = 124.'km'; // parse error

why do you process decimal integers in different way
than hexadecimal integers ? If it is only to detect
decimal float then you should take care to the fact that
'.' is not only a decimal separator but also a concatenation
operator !!!



[2002-10-13 09:41:43] [EMAIL PROTECTED]

maybe you do not consider it as a bug but it is quite
annoying when contatenating arguments, I personnaly
think that this is a lack of the parser/compiler to
do not detect that the '.' is not a part of the '2'
but it is an operator :

putting a '.' after the 2 doesn't change it's display.
$e = 2.3.'km'; // the dot after 2 followed by a digit
   // indicate a float
'2.3km'

$e = 2..'km'; // is ok the the dot after 2 is useless
'2km'

$e = 2.'km'; // produce a parse error
$e = 2 .'km'; // is ok
'2km'



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/19883

-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19883 [Bgs]: string concatenation bug

2002-10-13 Thread sander


 ID:   19883
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

THIS IS NOT A BUG!
Read the docs about operator precedence
(http://www.php.net/manual/en/language.operators.php#language.operators.precedence).
To avoid problems like these use parentheses ():
echo 'c='.($a*2).' ok';


Previous Comments:


[2002-10-13 12:03:06] [EMAIL PROTECTED]

Yes, of course,
I was only thinking that the advantage of PHP over C
was that we can concatenate easily strings with
expressions and functions results when setting variable,
calling functions ...

this syntax allow to do :

something('a='.$a.' and f(a)*2 = '.f($a)*2.' ...');

instead of :
$str = 'a=';
$str .= $a;
$str .= ' and f(a)*2 = ';
$str .= f($a)*2;
$str .= ' ...';
something($str);

or :
$str = sprintf('a=%d and f(a)*2 = %d ...', $a, f($a)*2);
something($str);

I really think that if you allow this kind of concatenation
to avoid complex string composition, then the 'float'
problem is a bug, standard C does not allow dynamic
string concatenation but in C++ you can overload the '+'
operator and there is no confusion with the '.'

I know there is always a way to overcome the problem
in syntax, my report is only about something that
appear to me to be an error.

Julien.



[2002-10-13 11:38:29] [EMAIL PROTECTED]

In that case, simply use

$i = 153;
echo $i*2
echo 'km';

or printf()...



[2002-10-13 11:16:05] [EMAIL PROTECTED]

and when you want to concatenate with dynamic
calculated infos ?

$i = 153;
echo $i*2.'km';



[2002-10-13 09:47:57] [EMAIL PROTECTED]

Why don't you just use '2km' instead of 2.'km' ?

Derick



[2002-10-13 09:46:06] [EMAIL PROTECTED]

and also :

$e = 0x7C.'km'; // is ok '124km'
$e = 124.'km'; // parse error

why do you process decimal integers in different way
than hexadecimal integers ? If it is only to detect
decimal float then you should take care to the fact that
'.' is not only a decimal separator but also a concatenation
operator !!!



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/19883

-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19586 [Fbk->Opn]: unset( $_SESSION['variable'] ) <- Fails with registered_globals 'on'

2002-10-13 Thread jpenn


 ID:   19586
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: ALL
 PHP Version:  4.2.2
 New Comment:

[EMAIL PROTECTED]:

Did you use the solution I provided ->
unset( $_SESSION['variable'], $variable );

This works fine as a workaround until they can fix the problem...


Previous Comments:


[2002-10-12 23:45:08] [EMAIL PROTECTED]

This problem is definitely not fixed in version 4.2.3. I'm running
Linux on a Cobalt RaQ 3i, and this is driving me up a wall...



[2002-09-25 06:36:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I think this was fixed in 4.2.3, but it might just be in head.  It's
been awhile since I saw the fix... try it anyways.



[2002-09-24 22:23:06] [EMAIL PROTECTED]

Below is the PHP Documentation on unregistering session variables...

Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is
used, use unset() to unregister a session variable.

unset( $_SESSION['variable'] ) fails to unset the given session
variable with registered_globals turned 'on' in ini file. It is safe to
say that this is true on all operating systems. PHP versions this was
tested on is 4.1.1 and 4.2.2, accross many different operating systems.
Using unset( $_SESSION['variable'] ) will unset the variable on the
current page only, and will not unset it in the global space.

We have come up with a workaround that works fine with
registered_globals on. See Below -->

---
unset( $_SESSION['variable'], $variable );
---

The above works fine. I believe that the documentation needs to reflect
this problem as countless developers in our community (Forums @
DevShed) has posted related problems using 'unset(
$_SESSION['variable'] )'

This applies only when registered_globals is truned 'on'.

unset( $_SESSION['variable'] ) works fine with registered_globals
'off'.








-- 
Edit this bug report at http://bugs.php.net/?id=19586&edit=1

#19613 [Com]: putenv("VAR=") does not empty VAR on win32

2002-10-13 Thread urs


 ID:   19613
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: Other web server
 Operating System: Win2K
 PHP Version:  4.2.3
 New Comment:

I downloaded a php-4.4.0-dev snapshot from http://snaps.php.net/win32
[Build Date Oct 7 2002 20:13:55 Server API CGI/FastCGI]. After
uncompressing the archive the first thing I was running was the
phpinfo() in a simple script . I tried this in MSIE
6, Moz 1.1 and Opera 6. 

After having added http://localhost/phpinfo.php?+ QueryString the
phpinfo came up in the browser.

I am running aEGiS nanoweb 1.8.3 [http://nanoweb.si.kz] and PHP as CGI
[c:\php\php-cgi.exe].

-urs


Previous Comments:


[2002-09-26 08:32:37] [EMAIL PROTECTED]

It appears that in Win32 (with php-cli.exe), the putenv function works
quite strangely.

When you call putenv("VAR="), this sould empty the "VAR" environment
variable. And it almost does it, because a call to getenv("VAR") will
return an empty string. However, the real env is not changed and VAR is
still set to its old value.

This small script (and its output) demonstrate the problem :

C:\php>php-cli

ZOB1
ZOB1

ZOB1
ZOB2
ZOB2




-- 
Edit this bug report at http://bugs.php.net/?id=19613&edit=1

#19887 [NEW]: php.exe error

2002-10-13 Thread tekronx


From: [EMAIL PROTECTED]
Operating system: XP Home
PHP version:  4.2.3
PHP Bug Type: Unknown/Other Function
Bug description:  php.exe error

When I add the extentions and try to test it I get an error saying that the
php.exe as some sort of error that causes it to have to shut down.

I used the phpinfo() to test.

And I am using an apache server.
-- 
Edit bug report at http://bugs.php.net/?id=19887&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19887&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19887&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19887&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19887&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19887&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19887&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19887&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19887&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19887&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19887&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19887&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19887&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19887&r=isapi

#19887 [Opn->Bgs]: php.exe error

2002-10-13 Thread derick


 ID:   19887
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: XP Home
 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.



Previous Comments:


[2002-10-13 12:53:11] [EMAIL PROTECTED]

When I add the extentions and try to test it I get an error saying that
the php.exe as some sort of error that causes it to have to shut down.

I used the phpinfo() to test.

And I am using an apache server.




-- 
Edit this bug report at http://bugs.php.net/?id=19887&edit=1

#19883 [Com]: string concatenation bug

2002-10-13 Thread skaventruc


 ID:   19883
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows NT
 PHP Version:  4.2.0
 New Comment:

ok, ok,
I understand, I also read carefully the docs,
I know there is 1000 ways to avoid a syntax problem,

'.' operator have left associativity and that mean
that when the parser found a '.' it operate the
concatenation function with the left member first.
I talk about a very special case when the left member
is a decimal digit (maybe we meet a float ?) and there
is no digit on the right side :

is a float in the form 123. is a float ?
- yes because the dot say that it is a float (see IEEE ...)
- not really because there is no decimal part, only integer
  so it can be considered as a integer. (round integer)
- the php introduce '.' as an operator but it is in some
  way imcompatible with the '.' definition with floats.

so what is the good decision to make ?

only ask to a human reader what did he understand
when he see :

123.'km'

and

0x45.'km'
or 145.7.'km'

ask anyone why the first case is false and try
to explain that this is in the doc, that the '.' operator
have left associativity and that 123 is a very special
case. Syntax rules should avoid us to do 'meaning' errors
but i'm not sure that the decision to take 2. as a float
in this case is a good decision.

And ... that's only my opinion, sorry to hurt you ...
I'm programming script parser since more than 15 years
and sometime it is better to listen users than stopping
to the docs and technical difficulties...

have a nice day.


Previous Comments:


[2002-10-13 12:09:03] [EMAIL PROTECTED]

THIS IS NOT A BUG!
Read the docs about operator precedence
(http://www.php.net/manual/en/language.operators.php#language.operators.precedence).
To avoid problems like these use parentheses ():
echo 'c='.($a*2).' ok';



[2002-10-13 12:03:06] [EMAIL PROTECTED]

Yes, of course,
I was only thinking that the advantage of PHP over C
was that we can concatenate easily strings with
expressions and functions results when setting variable,
calling functions ...

this syntax allow to do :

something('a='.$a.' and f(a)*2 = '.f($a)*2.' ...');

instead of :
$str = 'a=';
$str .= $a;
$str .= ' and f(a)*2 = ';
$str .= f($a)*2;
$str .= ' ...';
something($str);

or :
$str = sprintf('a=%d and f(a)*2 = %d ...', $a, f($a)*2);
something($str);

I really think that if you allow this kind of concatenation
to avoid complex string composition, then the 'float'
problem is a bug, standard C does not allow dynamic
string concatenation but in C++ you can overload the '+'
operator and there is no confusion with the '.'

I know there is always a way to overcome the problem
in syntax, my report is only about something that
appear to me to be an error.

Julien.



[2002-10-13 11:38:29] [EMAIL PROTECTED]

In that case, simply use

$i = 153;
echo $i*2
echo 'km';

or printf()...



[2002-10-13 11:16:05] [EMAIL PROTECTED]

and when you want to concatenate with dynamic
calculated infos ?

$i = 153;
echo $i*2.'km';



[2002-10-13 09:47:57] [EMAIL PROTECTED]

Why don't you just use '2km' instead of 2.'km' ?

Derick



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/19883

-- 
Edit this bug report at http://bugs.php.net/?id=19883&edit=1

#19603 [Ver->Csd]: Domxml causes segfault

2002-10-13 Thread iliaa


 ID:   19603
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Verified
+Status:   Closed
 Bug Type: DOM XML related
 Operating System: Windows XP
 PHP Version:  4.2.3
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-10-05 01:53:37] [EMAIL PROTECTED]

Works fine on Linux with any number of itterations, however it still
crashes on windows with 400+ itterations.



[2002-09-27 12:31:21] [EMAIL PROTECTED]

didnt't crash with 200 elements and latest CVS snapshot, but with 400
or more elements it still causes a segfault under apache and windows
xp. Each part alone still runs fine.
systemconfig:
 see my initial bug report



[2002-09-26 08:12:26] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip





[2002-09-25 15:40:08] [EMAIL PROTECTED]

System: Apache/1.3.24 PHP running as SAPI-module (Binary from php.net)

simple script, which causes segfault 
content
1content 2content
3content 4";

$document = xmltree($xml);
$ctx = xpath_new_context($document); 
$result = xpath_eval($ctx, "//element");
print_r($result);

/*part 2 create new xml document*/
$doc = domxml_new_doc("1.0");
$root = $doc->append_child($doc->create_element("para"));
for($i = 0; $i < 200; $i++){
$element = $doc->create_element("element");
$element->set_content("content ".$i);
$root->append_child($element);
}
echo "".htmlentities($doc->dump_mem(true))."";
?>

Description:
the content is shown in the browser, but apache causes a
segfault in module  php_domxml.dll, adress 0x1b03
as likely in bug 16888.
When you first create a xml document and parse second it runs without a
segfault.

This code causes no problems with PHP 4.1.2.

Modules:
php_domxml, php_xslt, php_iconv, php_gd and mysql







-- 
Edit this bug report at http://bugs.php.net/?id=19603&edit=1

#19872 [NEW]: ssl:// doesn't appear to work correctly

2002-10-13 Thread enygma


From: [EMAIL PROTECTED]
Operating system: Solaris
PHP version:  4.3.0-pre1
PHP Bug Type: Sockets related
Bug description:  ssl:// doesn't appear to work correctly

using $fp=fsockopen("ssl://".$hostname,$port,$errno,$errstr,100); the
connection doesn't seem to work correctly. There's either no connection
being made or the response is not being gotten correctly.

Also, according to the docs on
http://www.php.net/manual/en/function.stream-get-meta-data.php, there are
additional items in the array returned which aren't there.
-- 
Edit bug report at http://bugs.php.net/?id=19872&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19872&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19872&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19872&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19872&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19872&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19872&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19872&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19872&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19872&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19872&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19872&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19872&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19872&r=isapi

#19670 [Com]: 64bit Oracle installation fails

2002-10-13 Thread jkroll


 ID:   19670
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Solaris 2.8
 PHP Version:  4.2.3
 New Comment:

1.  Experienced similar but slightly different issue.
On Oracle 9i (9.2.0) under HP-UX 11i (11.11) the 64 bit libraries are
installed in ORACLE_HOME/lib and the 32 bit libraries are in
ORACLE_HOME/lib32.  This results in obvious link failures when trying
to build a 32 bit version of PHP.

2.  There are obvious work arounds to force linkage against the correct
libraries, however it would be nice if there were a config option to
override the Oracle library directory.


Previous Comments:


[2002-10-01 01:02:52] [EMAIL PROTECTED]

Yes, again this is the standard installation path of Oracle 8i. For
more information about disk layout of Oracle 8i 64bit read the Product
Notes section in 

'Oracle 8i Release Notes' available under:

http://download-east.oracle.com/docs/pdf/A90156_01.pdf



[2002-09-30 10:43:37] [EMAIL PROTECTED]

I understand what your claiming the bug is, thats not the issue.  What
I'm questioning is the validity of the bug, in the sense that my local
64bit Oracle install doesn't use the lib64 notation, but still uses the
lib.  Which may mean that my install is borked, but thus my asking.  



[2002-09-30 09:36:00] [EMAIL PROTECTED]

Yes, this is a standard install of Oracle 8. All 32 bit Libraries are
in $ORACLE_HOME/lib and 64 bit Libraries in $ORACLE_HOME/lib64

The problem is the configure script, which is not aware of compiling 64
bit - so the wrong library path is set.

The actual wayaround is to edit the configure script accordingly

vi configure
   :1,$s-OCI8_DIR\/lib-OCI8_DIR\/lib64-g
   :wq

This works - but there should be a better solution in future.



[2002-09-30 07:44:13] [EMAIL PROTECTED]

Is this a standard install?  My Oracle9 on Solaris 2.8 is all installed
under $ORACLE_HOME/lib





[2002-09-30 04:58:45] [EMAIL PROTECTED]

Configuring php with the --with-oci8 option fails when compiling in
64bit mode, because the configuration script will not find the correct
path of the Oracle 64bit libraries. 

The libraries are installed in $ORACLE_HOME/lib64. The Library Path is
resolved to $ORACLE_HOME/lib wher the 32bit libraries reside.




-- 
Edit this bug report at http://bugs.php.net/?id=19670&edit=1

#19888 [NEW]: failed --with-snmp (ucd 4.2.6 or 5.0.6)

2002-10-13 Thread mmx


From: [EMAIL PROTECTED]
Operating system: linux rh 6.2 or slack8
PHP version:  4.2.3
PHP Bug Type: Compile Failure
Bug description:  failed --with-snmp (ucd 4.2.6 or 5.0.6)

I am not sure if it is exactly php failure or maybe I should report a
net/ucd snmp bug ?

I had no success compiling php slack-8 with net-snmp5.0.6 althought I had
to push it by hand giving the proper snmp headers location it crashed
later during linking:

/bin/sh /riz-pack/system.httpd/php-4.2.3-exec/libtool --silent --mode=link
gcc -I. -I/riz-pack/system.httpd/php-4.2.3-exec/
-I/riz-pack/system.httpd/php-4.2.3-exec/main
-I/riz-pack/system.httpd/php-4.2.3-exec
-I/riz-pack/system.httpd/php-4.2.3-exec/Zend -I/usr/local/ssl/include
-I/usr/local/mysql/include/mysql -I/usr/local/include
-I/usr/local/include/ucd-snmp
-I/riz-pack/system.httpd/php-4.2.3-exec/ext/xml/expat 
-I/riz-pack/system.httpd/php-4.2.3-exec/TSRM -g -O2   -o php
-export-dynamic stub.lo libphp4.la
./.libs/libphp4.a(snmp.o): In function `php_snmp':
/riz-pack/system.httpd/php-4.2.3-exec/ext/snmp/snmp.c:318: undefined
reference to `sprint_value'
/riz-pack/system.httpd/php-4.2.3-exec/ext/snmp/snmp.c:328: undefined
reference to `sprint_objid'
/riz-pack/system.httpd/php-4.2.3-exec/ext/snmp/snmp.c:347: undefined
reference to `sprint_objid'
collect2: ld returned 1 exit status
make[1]: *** [php] Error 1
make[1]: Leaving directory `/riz-pack/system.httpd/php-4.2.3-exec'
make: *** [all-recursive] Error 1


with net-snmp-5.0.6 on rh6:

make[3]: Entering directory `/riz-pack/system.httpd/php-4.2.3/ext/snmp'
/bin/sh /riz-pack/system.httpd/php-4.2.3/libtool --silent --mode=compile
gcc  -I. -I/riz-pack/system.httpd/php-4.2.3/ext/snmp
-I/riz-pack/system.httpd/php-4.2.3/main -I/riz-pack/system.httpd/php-4.2.3
-I/usr/local/apache/include -I/riz-pack/system.httpd/php-4.2.3/Zend
-I/usr/local/ssl/include -I/usr/local/mysql/include/mysql
-I/usr/local/include -I/usr/local/include/ucd-snmp
-I/riz-pack/system.httpd/php-4.2.3/ext/xml/expat  -DLINUX=22
-DMOD_SSL=208109 -DMOD_PERL -DUSE_PERL_SSI -Dbool=char -DHAS_BOOL
-DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT
-I/riz-pack/system.httpd/php-4.2.3/TSRM -g -O2 -prefer-pic  -c snmp.c
In file included from /usr/local/include/ucd-snmp/snmp_api.h:4,
 from snmp.c:64:
/usr/local/include/net-snmp/library/snmp_api.h:84: warning: no semicolon
at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:84: parse error before `*'
/usr/local/include/net-snmp/library/snmp_api.h:99: parse error before `*'
/usr/local/include/net-snmp/library/snmp_api.h:99: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:125: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:125: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:131: parse error before
`netsnmp_pdu'
/usr/local/include/net-snmp/library/snmp_api.h:133: parse error before
`netsnmp_pdu'
/usr/local/include/net-snmp/library/snmp_api.h:186: parse error before
`oid'
/usr/local/include/net-snmp/library/snmp_api.h:186: warning: no semicolon
at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:190: parse error before
`*'
/usr/local/include/net-snmp/library/snmp_api.h:190: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:206: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:389: parse error before
`oid'
/usr/local/include/net-snmp/library/snmp_api.h:389: warning: no semicolon
at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:395: parse error before
`oid'
/usr/local/include/net-snmp/library/snmp_api.h:395: warning: no semicolon
at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:405: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:405: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:407: parse error before
`name_loc'
/usr/local/include/net-snmp/library/snmp_api.h:407: `MAX_OID_LEN'
undeclared here (not in a function)
/usr/local/include/net-snmp/library/snmp_api.h:407: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:409: conflicting types for
`data'
/riz-pack/system.httpd/php-4.2.3/main/php.h:212: previous declaration of
`data'
/usr/local/include/net-snmp/library/snmp_api.h:411: `index' redeclared as
different kind of symbol
/usr/include/string.h:240: previous declaration of `index'
/usr/local/include/net-snmp/library/snmp_api.h:412: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:455: parse error before
`netsnmp_pdu'
/usr/local/include/net-snmp/library/snmp_api.h:473: parse error before
`netsnmp_pdu'
/usr/local/include/net-snmp/library/snmp_api.h:498: parse error before
`*'
/usr/local/include/net-snmp/library/snmp_api.h:593: pa

#19887 [Bgs]: php.exe error

2002-10-13 Thread tekronx


 ID:   19887
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: XP Home
 PHP Version:  4.2.3
 New Comment:

When I add the extentions and try to test it I get an error saying
that
the php.exe as some sort of error that causes it to have to shut down.

I used the phpinfo() to test.

And I am using an apache server.

I also added all of the extesions.  It was the Zip version of the
windows binaries.  the CGI PHP one.


Previous Comments:


[2002-10-13 12:53:50] [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-13 12:53:11] [EMAIL PROTECTED]

When I add the extentions and try to test it I get an error saying that
the php.exe as some sort of error that causes it to have to shut down.

I used the phpinfo() to test.

And I am using an apache server.




-- 
Edit this bug report at http://bugs.php.net/?id=19887&edit=1

#16114 [Fbk->Opn]: fputs doesn't send all data(better now!)

2002-10-13 Thread manu

ID: 16114 User updated by: [EMAIL PROTECTED] -Summary: fputs doesn't send all data Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: Windows 2000 AS PHP Version: 4.1.1 New Comment: The lastest snapshot(Oct 13, 2002; php4-win32-latest.zip) works almost fine. This code: $socket = @fsockopen( 'localhost', 80, $err1, $err2 ); if (!$socket) die('socket not open'); $result = fputs( $socket, $request ); #$request holds a well formed MIME request for posting a file. fflush( $socket ); //echo ">>\r\n".str_replace('', '
', $request)."<<\r\n"; fclose( $socket ); This works if the file being posted is small(can't say how much). The point is that if I uncomment the echo line before fclose(), it sends all the data(up to 10.5M=11,076,608 bytes I sent), but without the echo line, it seems that fclose() executes in such a way that chops the socket's output stream and the Web Server does not executes the receive.php script. The echo line may be replace by sleep(8) and still working. Summary: Give it time before fclose() a works; otherwise, unstable. Manu. Previous Comments: [2002-09-26 10:38:03] [EMAIL PROTECTED] What's the status on this? Are you sure this is an issue with fputs and not instead an issue with file upload to a PHP script? What are you connecting to? If you are testing again, please try the latest snapshot; more changes have been made. http://snaps.php.net/win32/ [2002-07-21 12:42:05] [EMAIL PROTECTED] I downloaded the file php4-win32-200207182200.zip and made a test uploading a 3.2MB file. It didn't work. With smallers files(a test with a 13b one) works. I'll do a test trying to establish the failure boundaries. Manu. [2002-07-18 21:49:39] [EMAIL PROTECTED] I will do. In this moment I've been facing troubles with my Internet connection, and I cannot download the snapshots. Manu. [2002-07-10 12:29:00] [EMAIL PROTECTED] Could you try this on 4.2.1, and the latest snapshot on http://snaps.php.net/win32/ ? The internal streams subsystem has been implemented in the snapshots, which is a complete rewrite. Thanks, -Jason [2002-03-25 16:12:18] [EMAIL PROTECTED] I did also a test(without chunking the data), I could send 48653 bytes, but couldn't 49229 bytes. With the chunking feature it must be some bug in my code, cause didn't work with 48653 bytes. Manu. 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/16114 -- Edit this bug report at http://bugs.php.net/?id=16114&edit=1

#19889 [NEW]: Apache don´t start again after installing php as module

2002-10-13 Thread Gunther . Jentsch


From: [EMAIL PROTECTED]
Operating system: Windows xp
PHP version:  4.2.3
PHP Bug Type: Apache2 related
Bug description:  Apache don´t start again after installing php as module

I´m a newbie so I don´t know my mistake.

I´m runnning windows xp and want to install php

so i´ve installed apache2 and it works

I´ve installed php423 like its recommended in the install.txt.

When I put the three lines in the conf of apache to run php as modul the
apache server does not restart and I get the following error: The
requestet operation has failed!

If I run it as cgi binary it works. 

I searched for the mistake many hours, so I hope I can find help in his
forum.

many thanks and sorry for my bad English I´m German
-- 
Edit bug report at http://bugs.php.net/?id=19889&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19889&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19889&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19889&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19889&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19889&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19889&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19889&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19889&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19889&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19889&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19889&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19889&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19889&r=isapi

#19886 [Opn->Fbk]: readfile, fread, fpassthru won't work with large files!!!

2002-10-13 Thread sniper


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Performance problem
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

Did this work in any previous versions of PHP?
Is it stricly win32 thing? Does this workin in e.g. Linux?



Previous Comments:


[2002-10-13 10:40:41] [EMAIL PROTECTED]

May be its because that the stream hasn't enough time to get its new
position. I didn't read streams.c/h well enough too.



[2002-10-13 10:30:31] [EMAIL PROTECTED]

In addition

[frame1.php]
100k File is called. The next output of a >100k File
// will crash again...
sleep(5); 
header("Content-type: application/pdf\n");
readfile("some_100k_large.pdf");
?>



[2002-10-13 10:22:32] [EMAIL PROTECTED]

That last comment should let us open it back.

Removing the "big-files-passthrough" let the scripts run properly.

@Wez: can you check it? may be its because of the position of the
stream at the end of the execution of the first checksize?



[2002-10-13 10:19:11] [EMAIL PROTECTED]

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]


[frame2.php]


[frame3.php]




[2002-10-13 10:16:01] [EMAIL PROTECTED]

@wez: These scripts don't use sessions. They run of a CD in a
single-user-environment.

@nicos: Calling the "passthrough"-script directly works without errors.
But calling it in an frameset (together with two other scripts) crashes
when outputting a file > 100k,

The php_stream_read() returns the correct filesize.
The fact, that the parrallel execution of three scripts of one handles
a big file may be the source of the problem.

There are no write-accesses. Only Read-Accesses to small config-files.

Removing the "big-files-passthrough" let the scripts run properly.



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/19886

-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1

#19586 [Opn->Csd]: unset( $_SESSION['variable'] ) <- Fails with registered_globals 'on'

2002-10-13 Thread sniper


 ID:   19586
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Session related
 Operating System: ALL
 PHP Version:  4.2.2
 New Comment:

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2002-10-13 12:21:42] [EMAIL PROTECTED]

[EMAIL PROTECTED]:

Did you use the solution I provided ->
unset( $_SESSION['variable'], $variable );

This works fine as a workaround until they can fix the problem...



[2002-10-12 23:45:08] [EMAIL PROTECTED]

This problem is definitely not fixed in version 4.2.3. I'm running
Linux on a Cobalt RaQ 3i, and this is driving me up a wall...



[2002-09-25 06:36:14] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I think this was fixed in 4.2.3, but it might just be in head.  It's
been awhile since I saw the fix... try it anyways.



[2002-09-24 22:23:06] [EMAIL PROTECTED]

Below is the PHP Documentation on unregistering session variables...

Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is
used, use unset() to unregister a session variable.

unset( $_SESSION['variable'] ) fails to unset the given session
variable with registered_globals turned 'on' in ini file. It is safe to
say that this is true on all operating systems. PHP versions this was
tested on is 4.1.1 and 4.2.2, accross many different operating systems.
Using unset( $_SESSION['variable'] ) will unset the variable on the
current page only, and will not unset it in the global space.

We have come up with a workaround that works fine with
registered_globals on. See Below -->

---
unset( $_SESSION['variable'], $variable );
---

The above works fine. I believe that the documentation needs to reflect
this problem as countless developers in our community (Forums @
DevShed) has posted related problems using 'unset(
$_SESSION['variable'] )'

This applies only when registered_globals is truned 'on'.

unset( $_SESSION['variable'] ) works fine with registered_globals
'off'.








-- 
Edit this bug report at http://bugs.php.net/?id=19586&edit=1

#19888 [Opn->Bgs]: failed --with-snmp (ucd 4.2.6 or 5.0.6)

2002-10-13 Thread sniper


 ID:   19888
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
-Bug Type: Compile Failure
+Bug Type: SNMP related
 Operating System: linux rh 6.2 or slack8
 PHP Version:  4.2.3
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the original bug instead.

Thank you for your interest in PHP.



#18728 already reports this bug. Please add your information
(if it's something that isn't said yet) there.



Previous Comments:


[2002-10-13 14:14:50] [EMAIL PROTECTED]

I am not sure if it is exactly php failure or maybe I should report a
net/ucd snmp bug ?

I had no success compiling php slack-8 with net-snmp5.0.6 althought I
had to push it by hand giving the proper snmp headers location it
crashed later during linking:

/bin/sh /riz-pack/system.httpd/php-4.2.3-exec/libtool --silent
--mode=link gcc -I. -I/riz-pack/system.httpd/php-4.2.3-exec/
-I/riz-pack/system.httpd/php-4.2.3-exec/main
-I/riz-pack/system.httpd/php-4.2.3-exec
-I/riz-pack/system.httpd/php-4.2.3-exec/Zend -I/usr/local/ssl/include
-I/usr/local/mysql/include/mysql -I/usr/local/include
-I/usr/local/include/ucd-snmp
-I/riz-pack/system.httpd/php-4.2.3-exec/ext/xml/expat 
-I/riz-pack/system.httpd/php-4.2.3-exec/TSRM -g -O2   -o php
-export-dynamic stub.lo libphp4.la
./.libs/libphp4.a(snmp.o): In function `php_snmp':
/riz-pack/system.httpd/php-4.2.3-exec/ext/snmp/snmp.c:318: undefined
reference to `sprint_value'
/riz-pack/system.httpd/php-4.2.3-exec/ext/snmp/snmp.c:328: undefined
reference to `sprint_objid'
/riz-pack/system.httpd/php-4.2.3-exec/ext/snmp/snmp.c:347: undefined
reference to `sprint_objid'
collect2: ld returned 1 exit status
make[1]: *** [php] Error 1
make[1]: Leaving directory `/riz-pack/system.httpd/php-4.2.3-exec'
make: *** [all-recursive] Error 1


with net-snmp-5.0.6 on rh6:

make[3]: Entering directory
`/riz-pack/system.httpd/php-4.2.3/ext/snmp'
/bin/sh /riz-pack/system.httpd/php-4.2.3/libtool --silent
--mode=compile gcc  -I. -I/riz-pack/system.httpd/php-4.2.3/ext/snmp
-I/riz-pack/system.httpd/php-4.2.3/main
-I/riz-pack/system.httpd/php-4.2.3 -I/usr/local/apache/include
-I/riz-pack/system.httpd/php-4.2.3/Zend -I/usr/local/ssl/include
-I/usr/local/mysql/include/mysql -I/usr/local/include
-I/usr/local/include/ucd-snmp
-I/riz-pack/system.httpd/php-4.2.3/ext/xml/expat  -DLINUX=22
-DMOD_SSL=208109 -DMOD_PERL -DUSE_PERL_SSI -Dbool=char -DHAS_BOOL
-DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT
-I/riz-pack/system.httpd/php-4.2.3/TSRM -g -O2 -prefer-pic  -c snmp.c
In file included from /usr/local/include/ucd-snmp/snmp_api.h:4,
 from snmp.c:64:
/usr/local/include/net-snmp/library/snmp_api.h:84: warning: no
semicolon at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:84: parse error before
`*'
/usr/local/include/net-snmp/library/snmp_api.h:99: parse error before
`*'
/usr/local/include/net-snmp/library/snmp_api.h:99: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:125: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:125: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:131: parse error before
`netsnmp_pdu'
/usr/local/include/net-snmp/library/snmp_api.h:133: parse error before
`netsnmp_pdu'
/usr/local/include/net-snmp/library/snmp_api.h:186: parse error before
`oid'
/usr/local/include/net-snmp/library/snmp_api.h:186: warning: no
semicolon at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:190: parse error before
`*'
/usr/local/include/net-snmp/library/snmp_api.h:190: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:206: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:389: parse error before
`oid'
/usr/local/include/net-snmp/library/snmp_api.h:389: warning: no
semicolon at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:395: parse error before
`oid'
/usr/local/include/net-snmp/library/snmp_api.h:395: warning: no
semicolon at end of struct or union
/usr/local/include/net-snmp/library/snmp_api.h:405: parse error before
`}'
/usr/local/include/net-snmp/library/snmp_api.h:405: warning: data
definition has no type or storage class
/usr/local/include/net-snmp/library/snmp_api.h:407: parse error before
`name_loc'
/usr/local/include/net-snmp/library/snmp_api.h:407: `MAX_OID_LEN'
undeclared here (not in a function)
/usr/local/include/net-snmp/library/snmp_api.h:407: warning: data
definition has no type or storage class
/usr/local/include/net-snm

#19889 [Opn->Bgs]: Apache don´t start again after installing php as module

2002-10-13 Thread sniper


 ID:   19889
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows xp
 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.


Previous Comments:


[2002-10-13 16:35:11] [EMAIL PROTECTED]

I´m a newbie so I don´t know my mistake.

I´m runnning windows xp and want to install php

so i´ve installed apache2 and it works

I´ve installed php423 like its recommended in the install.txt.

When I put the three lines in the conf of apache to run php as modul
the apache server does not restart and I get the following error: The
requestet operation has failed!

If I run it as cgi binary it works. 

I searched for the mistake many hours, so I hope I can find help in his
forum.

many thanks and sorry for my bad English I´m German




-- 
Edit this bug report at http://bugs.php.net/?id=19889&edit=1

#19857 [Fbk->Opn]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread darwin


 ID:   19857
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:



//  here is a very short, and simple example that reproduces the
problem; please let me know, ASAP, if you locate the bug

class COption
{

  function COption( )
  {

  }//  constructor

  var $iID  ;
  var $sName;
  var $sBriefDesc   ;
  var $sDetailedDesc;
  var $iTimesAvailable  ;
  var $fRetailPrice ;
  var $fWholesalePrice  ;
  var $bTaxable ;
  var $bDiscounted  ;
  var $bActive  ;
  var $iMinNumFreeSuboptions;
  var $iMaxNumFreeSuboptions;
  var $iMinNumPaidSuboptions;
  var $iMaxNumPaidSuboptions;
  var $sQuestion;
  var $aoImages ;
  var $aoSuboptions ;
  var $iNumber  ;
  var $iPosition;

}//  COption

$oItemTemp = 'COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?2010

#19890 [NEW]: --prefix is not honoured for PEAR install

2002-10-13 Thread michael . mauch


From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.0-pre1
PHP Bug Type: *Compile Issues
Bug description:  --prefix is not honoured for PEAR install

Trying to install PHP into a directory other than /usr/local results in a
broken PEAR install, because the --prefix directory is not honoured:

Installing PHP SAPI module
Installing shared extensions:
/house/elmicha/spe142/lib/php/extensions/no-debug-non-zts-20020429/
Installing PHP CLI binary:/house/elmicha/spe142/bin/
Installing PEAR environment:  /house/elmicha/spe142/lib/php/

Warning: mkdir(/usr/local/lib/php) [http://www.php.net/function.mkdir]:
Permission denied in
/house/elmicha/local/src/php-4.3.0pre1/pear/System.php on line 236

Warning: mkdir(/usr/local/lib/php/.registry)
[http://www.php.net/function.mkdir]: No such file or directory in
/house/elmicha/local/src/php-4.3.0pre1/pear/System.php on line 236


-- 
Edit bug report at http://bugs.php.net/?id=19890&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19890&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=19890&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=19890&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19890&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=19890&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19890&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=19890&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19890&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19890&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=19890&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19890&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=19890&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=19890&r=isapi

#16114 [Opn->Fbk]: fputs doesn't send all data(better now!)

2002-10-13 Thread wez

ID: 16114 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Windows 2000 AS -PHP Version: 4.1.1 +PHP Version: 4.1.1-4.3/CVS New Comment: I've just committed a little patch that might fix this problem; PHP was calling shutdown(2) prior to closing the socket, and this may have been causing the data-loss. If you can compile PHP yourself, comment out the shutdown line in main/network.c. Otherwise, you need to wait for the next snapshot to be built (could be 3 hours away). Please let me know how you get on. Previous Comments: [2002-10-13 15:08:38] [EMAIL PROTECTED] The lastest snapshot(Oct 13, 2002; php4-win32-latest.zip) works almost fine. This code: $socket = @fsockopen( 'localhost', 80, $err1, $err2 ); if (!$socket) die('socket not open'); $result = fputs( $socket, $request ); #$request holds a well formed MIME request for posting a file. fflush( $socket ); //echo ">>\r\n".str_replace('', '
', $request)."<<\r\n"; fclose( $socket ); This works if the file being posted is small(can't say how much). The point is that if I uncomment the echo line before fclose(), it sends all the data(up to 10.5M=11,076,608 bytes I sent), but without the echo line, it seems that fclose() executes in such a way that chops the socket's output stream and the Web Server does not executes the receive.php script. The echo line may be replace by sleep(8) and still working. Summary: Give it time before fclose() a works; otherwise, unstable. Manu. [2002-09-26 10:38:03] [EMAIL PROTECTED] What's the status on this? Are you sure this is an issue with fputs and not instead an issue with file upload to a PHP script? What are you connecting to? If you are testing again, please try the latest snapshot; more changes have been made. http://snaps.php.net/win32/ [2002-07-21 12:42:05] [EMAIL PROTECTED] I downloaded the file php4-win32-200207182200.zip and made a test uploading a 3.2MB file. It didn't work. With smallers files(a test with a 13b one) works. I'll do a test trying to establish the failure boundaries. Manu. [2002-07-18 21:49:39] [EMAIL PROTECTED] I will do. In this moment I've been facing troubles with my Internet connection, and I cannot download the snapshots. Manu. [2002-07-10 12:29:00] [EMAIL PROTECTED] Could you try this on 4.2.1, and the latest snapshot on http://snaps.php.net/win32/ ? The internal streams subsystem has been implemented in the snapshots, which is a complete rewrite. Thanks, -Jason 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/16114 -- Edit this bug report at http://bugs.php.net/?id=16114&edit=1

#16114 [Fbk->Opn]: fputs doesn't send all data(better now!)

2002-10-13 Thread wez

ID: 16114 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: Windows 2000 AS PHP Version: 4.1.1-4.3/CVS New Comment: Scratch that; I just discovered something in the MSDN docs. Previous Comments: [2002-10-13 18:34:13] [EMAIL PROTECTED] I've just committed a little patch that might fix this problem; PHP was calling shutdown(2) prior to closing the socket, and this may have been causing the data-loss. If you can compile PHP yourself, comment out the shutdown line in main/network.c. Otherwise, you need to wait for the next snapshot to be built (could be 3 hours away). Please let me know how you get on. [2002-10-13 15:08:38] [EMAIL PROTECTED] The lastest snapshot(Oct 13, 2002; php4-win32-latest.zip) works almost fine. This code: $socket = @fsockopen( 'localhost', 80, $err1, $err2 ); if (!$socket) die('socket not open'); $result = fputs( $socket, $request ); #$request holds a well formed MIME request for posting a file. fflush( $socket ); //echo ">>\r\n".str_replace('', '
', $request)."<<\r\n"; fclose( $socket ); This works if the file being posted is small(can't say how much). The point is that if I uncomment the echo line before fclose(), it sends all the data(up to 10.5M=11,076,608 bytes I sent), but without the echo line, it seems that fclose() executes in such a way that chops the socket's output stream and the Web Server does not executes the receive.php script. The echo line may be replace by sleep(8) and still working. Summary: Give it time before fclose() a works; otherwise, unstable. Manu. [2002-09-26 10:38:03] [EMAIL PROTECTED] What's the status on this? Are you sure this is an issue with fputs and not instead an issue with file upload to a PHP script? What are you connecting to? If you are testing again, please try the latest snapshot; more changes have been made. http://snaps.php.net/win32/ [2002-07-21 12:42:05] [EMAIL PROTECTED] I downloaded the file php4-win32-200207182200.zip and made a test uploading a 3.2MB file. It didn't work. With smallers files(a test with a 13b one) works. I'll do a test trying to establish the failure boundaries. Manu. [2002-07-18 21:49:39] [EMAIL PROTECTED] I will do. In this moment I've been facing troubles with my Internet connection, and I cannot download the snapshots. Manu. 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/16114 -- Edit this bug report at http://bugs.php.net/?id=16114&edit=1

#16114 [Opn->Fbk]: fputs doesn't send all data(better now!)

2002-10-13 Thread wez

ID: 16114 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Windows 2000 AS PHP Version: 4.1.1-4.3/CVS New Comment: Please try the next snapshot. Previous Comments: [2002-10-13 18:40:35] [EMAIL PROTECTED] Scratch that; I just discovered something in the MSDN docs. [2002-10-13 18:34:13] [EMAIL PROTECTED] I've just committed a little patch that might fix this problem; PHP was calling shutdown(2) prior to closing the socket, and this may have been causing the data-loss. If you can compile PHP yourself, comment out the shutdown line in main/network.c. Otherwise, you need to wait for the next snapshot to be built (could be 3 hours away). Please let me know how you get on. [2002-10-13 15:08:38] [EMAIL PROTECTED] The lastest snapshot(Oct 13, 2002; php4-win32-latest.zip) works almost fine. This code: $socket = @fsockopen( 'localhost', 80, $err1, $err2 ); if (!$socket) die('socket not open'); $result = fputs( $socket, $request ); #$request holds a well formed MIME request for posting a file. fflush( $socket ); //echo ">>\r\n".str_replace('', '
', $request)."<<\r\n"; fclose( $socket ); This works if the file being posted is small(can't say how much). The point is that if I uncomment the echo line before fclose(), it sends all the data(up to 10.5M=11,076,608 bytes I sent), but without the echo line, it seems that fclose() executes in such a way that chops the socket's output stream and the Web Server does not executes the receive.php script. The echo line may be replace by sleep(8) and still working. Summary: Give it time before fclose() a works; otherwise, unstable. Manu. [2002-09-26 10:38:03] [EMAIL PROTECTED] What's the status on this? Are you sure this is an issue with fputs and not instead an issue with file upload to a PHP script? What are you connecting to? If you are testing again, please try the latest snapshot; more changes have been made. http://snaps.php.net/win32/ [2002-07-21 12:42:05] [EMAIL PROTECTED] I downloaded the file php4-win32-200207182200.zip and made a test uploading a 3.2MB file. It didn't work. With smallers files(a test with a 13b one) works. I'll do a test trying to establish the failure boundaries. Manu. 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/16114 -- Edit this bug report at http://bugs.php.net/?id=16114&edit=1

#19857 [Opn->Fbk]: wddx_deserialize Does Not Work Properly with Complex Data Types

2002-10-13 Thread sniper


 ID:   19857
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:

How did you create the wddx data?
Can you please come up with SHORT example?



Previous Comments:


[2002-10-13 17:55:43] [EMAIL PROTECTED]



//  here is a very short, and simple example that reproduces the
problem; please let me know, ASAP, if you locate the bug

class COption
{

  function COption( )
  {

  }//  constructor

  var $iID  ;
  var $sName;
  var $sBriefDesc   ;
  var $sDetailedDesc;
  var $iTimesAvailable  ;
  var $fRetailPrice ;
  var $fWholesalePrice  ;
  var $bTaxable ;
  var $bDiscounted  ;
  var $bActive  ;
  var $iMinNumFreeSuboptions;
  var $iMaxNumFreeSuboptions;
  var $iMinNumPaidSuboptions;
  var $iMaxNumPaidSuboptions;
  var $sQuestion;
  var $aoImages ;
  var $aoSuboptions ;
  var $iNumber  ;
  var $iPosition;

}//  COption

$oItemTemp = 'COptionhttp://localhost/Delisma/Menu/00.082522315.025.355good good stuffgood stuffpizza1COptionhttp://localhost/Delisma/Menu/00.0825What size do you
want?http://localhost/Delisma/Menu/00.0825What size do you want?22315.025.355good good stuffgood stuffsalad2coptionWaz' up?#19857 [Fbk->Opn]: wddx_deserialize Does Not Work Properly with Complex Data Types


2002-10-13

Thread
darwin


 ID:   19857
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: WDDX related
 Operating System: Win XP Pro
 PHP Version:  4.2.3
 New Comment:

//  I HAVE ISSOLATED THE PROBLEM FOR YOU!!!
//
//  Check out the code, below; via it, you will note that PHP is
sensitive to the positioning of fields in within the WDDX packet; this
is your bug; since the fields of a WDDX packet are unordered, you
cannot expect them to be in any particular order.  Please let me know,
ASAP, once you have fixed this bug, since my team would really like to
utilize WDDX for our project.
//
//  Take care,
//  Darwin



class COption
{

  function COption( )
  {

  }//  constructor

  function test( )
  {
$oSuboption1 = new COption( ) ;
$oSuboption1->iID = 10 ;
$oSuboption1->sName = "Suboption 1" ;
$oSuboption1->sBriefDesc = "SO 1 brief desc" ;
$oSuboption1->sDetailedDesc = "Suboption 1 detailed description..."
;
$oSuboption1->iTimesAvailable = 7 ;
$oSuboption1->fRetailPrice = 10 ;
$oSuboption1->fWholesalePrice = 5 ;
$oSuboption1->bTaxable = true ;
$oSuboption1->bDiscounted = false  ;
$oSuboption1->bActive = true ;
$oSuboption1->iMinNumFreeSuboptions = 0 ;
$oSuboption1->iMaxNumFreeSuboptions = 0 ;
$oSuboption1->iMinNumPaidSuboptions = 0 ;
$oSuboption1->iMaxNumPaidSuboptions = 0 ;
$oSuboption1->sQuestion = "Suoption 1 Question?" ;
$oSuboption1->aoImages = array() ;
$oSuboption1->iNumber = null ;
$oSuboption1->iPosition = null ;
$oSuboption1->sScriptRoot = "http://localhost/Delisma/Menu/"; ;
$oSuboption1->fDiscountRate = 0 ;
$oSuboption1->fTaxRate = 0.0825 ;

$oSuboption2 = new COption( ) ;
$oSuboption2->iID = 10 ;
$oSuboption2->sName = "Suboption 2" ;
$oSuboption2->sBriefDesc = "SO 2 brief desc" ;
$oSuboption2->sDetailedDesc = "Suboption 2 detailed description..."
;
$oSuboption2->iTimesAvailable = 1 ;
$oSuboption2->fRetailPrice = 8 ;
$oSuboption2->fWholesalePrice = 3 ;
$oSuboption2->bTaxable = true ;
$oSuboption2->bDiscounted = false  ;
$oSuboption2->bActive = true ;
$oSuboption2->iMinNumFreeSuboptions = 5 ;
$oSuboption2->iMaxNumFreeSuboptions = 10 ;
$oSuboption2->iMinNumPaidSuboptions = 15 ;
$oSuboption2->iMaxNumPaidSuboptions = 20 ;
$oSuboption2->sQuestion = "Suoption 2 Question?" ;
$oSuboption2->aoImages = array() ;
$oSuboption2->iNumber = null ;
$oSuboption2->iPosition = null ;
$oSuboption2->sScriptRoot = "http://localhost/Delisma/Menu/"; ;
$oSuboption2->fDiscountRate = 0 ;
$oSuboption2->fTaxRate = 0.0825 ;

$this->iID = 0 ;
$this->sName = "Wacky Burger 5" ;
$this->sBriefDesc = "'Dis Shit is Wack!" ;
$this->sDetailedDesc = "'Da bomb is hear again!  This is a friggin'
quarter pound of good, good stuff!" ;
$this->iTimesAvailable = 5 ;
$this->fRetailPrice = 18 ;
$this->fWholesalePrice = 12 ;
$this->bTaxable = true ;
$this->bDiscounted = false  ;
$this->bActive = true ;
$this->iMinNumFreeSuboptions = 0 ;
$this->iMaxNumFreeSuboptions = 1 ;
$this->iMinNumPaidSuboptions = 0 ;
$this->iMaxNumPaidSuboptions = 2 ;
$this->sQuestion = "Waz' up?" ;
$this->aoImages = array() ;
$this->aoSuboptions = array( $oSuboption1, $oSuboption2 ) ;
$this->iNumber = 55 ;
$this->iPosition = 0 ;
$this->sScriptRoot = "http://localhost/Delisma/Menu/"; ;
$this->fDiscountRate = 0 ;
$this->fTaxRate = 0.0825 ;
$this->iNumber = 55 ;
$this->iPosition = 0 ;
$this->sScriptRoot = "http://localhost/Delisma/Menu/"; ;
$this->fDiscountRate = 0 ;
$this->fTaxRate = 0.0825 ;

  }

  var $iID  ;
  var $sName;
  var $sBriefDesc   ;
  var $sDetailedDesc;
  var $iTimesAvailable  ;
  var $fRetailPrice ;
  var $fWholesalePrice  ;
  var $bTaxable ;
  var $bDiscounted  ;
  var $bActive  ;
  var $iMinNumFreeSuboptions;
  var $iMaxNumFreeSuboptions;
  var $iMinNumPaidSuboptions;
  var $iMaxNumPaidSuboptions;
  var $sQuestion;
  var $aoImages ;
  var $aoSuboptions ;
  var $iNumber  ;
  var $iPosition;

}//  COption

$sWDDXPacketBad = '

 
 
  
   COption
   http://localhost/Delisma/Menu/



#19886 [Fbk]: readfile, fread, fpassthru won't work with large files!!!


2002-10-13

Thread
wez


 ID:   19886
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Windows, any Version
 PHP Version:  4CVS-2002-10-13
 New Comment:

I just fixed (I hope) a socket-shutdown bug (#16114).
The interesting thing is that this is only to do with
writes to sockets opened by streams (so it should not
affect PHP output).

It might be that the Microweb server also has a similar
bug, or that it has some other threading issue.

It doesn't make sense for this to be related solely to
streams, as they aren't time-dependent, and they are
certainly not dependent on other PHP processes.

Can you try reproducing the problem using Apache, PWS
or IIS?
Can anyone reproduce this on another platform?



Previous Comments:


[2002-10-13 17:21:54] [EMAIL PROTECTED]

Did this work in any previous versions of PHP?
Is it stricly win32 thing? Does this workin in e.g. Linux?




[2002-10-13 10:40:41] [EMAIL PROTECTED]

May be its because that the stream hasn't enough time to get its new
position. I didn't read streams.c/h well enough too.



[2002-10-13 10:30:31] [EMAIL PROTECTED]

In addition

[frame1.php]
100k File is called. The next output of a >100k File
// will crash again...
sleep(5); 
header("Content-type: application/pdf\n");
readfile("some_100k_large.pdf");
?>



[2002-10-13 10:22:32] [EMAIL PROTECTED]

That last comment should let us open it back.

Removing the "big-files-passthrough" let the scripts run properly.

@Wez: can you check it? may be its because of the position of the
stream at the end of the execution of the first checksize?



[2002-10-13 10:19:11] [EMAIL PROTECTED]

The following snippets illustrate the environment


[frameset.php]
->frame1.php
->frame2.php
->frame3.php


[frame1.php]


[frame2.php]


[frame3.php]




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19886

-- 
Edit this bug report at http://bugs.php.net/?id=19886&edit=1







#19689 [Com]: 4.2.3 and higher "include" operator mistake


2002-10-13

Thread
webdevguy1


 ID:   19689
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows
 PHP Version:  4CVS-2002-10-01
 New Comment:

I may be experiencing a related problem with php.ini. It seems PHP does
not recognize subdirectories (Windows only?). For example, the
following is OK:

include_path = ".;C:\PHPinc;C:\Templates"

and the following is not OK:

include_path = ".;C:\PHPinc;C:\PHPinc\Templates"

I am running:

PHP 4.2.3
Windows 2000 Pro
Apache 1.3.27
Mod_SSL 2.8.11
OpenSSL 0.9.6g


Previous Comments:


[2002-10-01 10:35:20] [EMAIL PROTECTED]

DO NOT open more bug reports about this SAME issue.
Thank you.




[2002-10-01 10:15:27] [EMAIL PROTECTED]

All I want is only to make this bug "open", but not "bogus".
Now it is all right. Thank you.



[2002-10-01 09:09:34] [EMAIL PROTECTED]

Hello,

A lot of people work very hard on PHP for no money, there is a general
etiquette which is advisable to stick to when reporting a bug and that
is to be nice. Now I havnt looked at your other reports personally and
I dont know why they were marked as bogus (perhaps someone was tired,
could not understand exactly what you mean or for many other reasons)
and I appolgize for that, a better way to approach it is to ask why the
bug has been marked as bogus rather than ranting that it has. 

We deal with many bugs each day and have limited time thus those that
get fixed are those which either are highly important to us (If Im
affected by a bug Ill fix it myself I wont expect other people too) or
one that affects a lot of people. 

Remember you have not paid for PHP and are asking us to do work for you
for free. Now you have spent an hour fixing that bug and Ill have a
look at the patch now check it fixes it and does not break anything
else and if that is the case then it will be applied before the next
version and I thank you for your time, but I promise you it will still
use up at least 20 mins of my time (and IMHO my time is more important
to me than your time is).

So what I am saying is that yes you have a bug in PHP you want fixed
but dont expect it to happen straight away, localizing and fixing a bug
and checking its implications is a slow and boring game and we dont
always get it right but we do it for free so have a touch more patience
with us and we are likley to be more helpful.

Sorry to rant.

- James





[2002-10-01 08:58:29] [EMAIL PROTECTED]

OK, if you cannot correct your own program without misleading words
(you said before TWICE that there is no bug, and it is the ONLY thing
disagreeable to me), get it:

php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56:

- #define IS_ABSOLUTE_PATH(path, len) \
-   (len >= 2 && isalpha(path[0]) && path[1] == ':')

+ #define IS_ABSOLUTE_PATH(path, len) \
+   (len >= 2 && isalpha(path[0]) && path[1] == ':') \
+   || (len >= 1 && IS_SLASH(path[0]))

This section is under #ifdef TSRM_WIN32 block (of course). 

I'm not a specialist in PHP core, so I have spent about an hour to find
bug location. Unfortunately I CANNOT stop on that, because our users
still download PHP from your site. I will be very glad if you correct
this bug in the next version (4.3.0 I suppose?).



[2002-10-01 08:58:28] [EMAIL PROTECTED]

OK, if you cannot correct your own program without misleading words
(you said before TWICE that there is no bug, and it is the ONLY thing
disagreeable to me), get it:

php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56:

- #define IS_ABSOLUTE_PATH(path, len) \
-   (len >= 2 && isalpha(path[0]) && path[1] == ':')

+ #define IS_ABSOLUTE_PATH(path, len) \
+   (len >= 2 && isalpha(path[0]) && path[1] == ':') \
+   || (len >= 1 && IS_SLASH(path[0]))

This section is under #ifdef TSRM_WIN32 block (of course). 

I'm not a specialist in PHP core, so I have spent about an hour to find
bug location. Unfortunately I CANNOT stop on that, because our users
still download PHP from your site. I will be very glad if you correct
this bug in the next version (4.3.0 I suppose?).



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/19689

-- 
Edit this bug report at http://bugs.php.net/?id=19689&edit=1







#19872 [Fbk]: ssl:// doesn't appear to work correctly


2002-10-13

Thread
wez


 ID:   19872
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Sockets related
 Operating System: Solaris
 PHP Version:  4.3.0-pre1
 New Comment:

I've improved the SSL error handling, so please
try again with a new snapshot (use the most recent one
dated after this entry).
Also, remember that if you are rolling your own https
support, the default port for SSL is 443.
(You could just use fopen("https://";) in that case).


Previous Comments:


[2002-10-11 19:27:38] [EMAIL PROTECTED]

We need more information than that...
Please post a short script that reproduces the problem,
and include the output you are getting and also the output you were
expecting.



[2002-10-11 16:52:54] [EMAIL PROTECTED]

using $fp=fsockopen("ssl://".$hostname,$port,$errno,$errstr,100); the
connection doesn't seem to work correctly. There's either no connection
being made or the response is not being gotten correctly.

Also, according to the docs on
http://www.php.net/manual/en/function.stream-get-meta-data.php, there
are additional items in the array returned which aren't there.




-- 
Edit this bug report at http://bugs.php.net/?id=19872&edit=1







#19881 [Fbk->Bgs]: phpinfo() Security Problem


2002-10-13

Thread
sniper


 ID:   19881
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: Win32
 PHP Version:  4.2.3
 New Comment:

This is the solution, not workaround..



Previous Comments:


[2002-10-12 23:54:13] [EMAIL PROTECTED]

That setting does indeed eliminate the image tag bug.  It could be used
as a temporary workaround for this issue.  The correct behavior would
be for PHP to eradicate the query string before using it in a URL.



[2002-10-12 22:42:53] [EMAIL PROTECTED]

If I understood your concern correctly, only thing you
have to do is to set 'expose_php=off' in your php.ini file.




[2002-10-12 18:16:16] [EMAIL PROTECTED]

phpinfo() in PHP 4.2.3 uses a special query string to cause a script to
return the PHP logo.  phpinfo() fails to strip any query string off of
the URI before writing it to the browser.  This opens up two issues,
one a nuisance, and the other a more serious security issue:

--- INFO.PHP ---

--- INFO.PHP ---

Yes, I know that's a security risk to allow anonymous users access to
debug information, but this is actually an example of a default script
in many web applications/servers (BadBlue web server, for example).

http://localhost/info.php?";>alert(document.URL)=x

Some browsers will not encode this, and this results in:

alert(document.URL)?=PHPE9568F34-D428-11d2-A769-00AA001ACF42"
border=0 align="right" alt="PHP Logo">

The security issue here is a cross-site scripting exposure -- not only
does PHP fail to strip the query string, it also fails to filter any
HTML entities contained in it.

The nuisance problem is that the ALT tag is displayed, but the script
executes a regular phpinfo(), and returns a bogus image.




-- 
Edit this bug report at http://bugs.php.net/?id=19881&edit=1







#19689 [Opn->Ctl]: 4.2.3 and higher "include" operator mistake


2002-10-13

Thread
sniper


 ID:   19689
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Critical
 Bug Type: Scripting Engine problem
 Operating System: Windows
 PHP Version:  4CVS-2002-10-01
 New Comment:

This really should be fixed before 4.3.0-dev is released..



Previous Comments:


[2002-10-13 19:24:37] [EMAIL PROTECTED]

I may be experiencing a related problem with php.ini. It seems PHP does
not recognize subdirectories (Windows only?). For example, the
following is OK:

include_path = ".;C:\PHPinc;C:\Templates"

and the following is not OK:

include_path = ".;C:\PHPinc;C:\PHPinc\Templates"

I am running:

PHP 4.2.3
Windows 2000 Pro
Apache 1.3.27
Mod_SSL 2.8.11
OpenSSL 0.9.6g



[2002-10-01 10:35:20] [EMAIL PROTECTED]

DO NOT open more bug reports about this SAME issue.
Thank you.




[2002-10-01 10:15:27] [EMAIL PROTECTED]

All I want is only to make this bug "open", but not "bogus".
Now it is all right. Thank you.



[2002-10-01 09:09:34] [EMAIL PROTECTED]

Hello,

A lot of people work very hard on PHP for no money, there is a general
etiquette which is advisable to stick to when reporting a bug and that
is to be nice. Now I havnt looked at your other reports personally and
I dont know why they were marked as bogus (perhaps someone was tired,
could not understand exactly what you mean or for many other reasons)
and I appolgize for that, a better way to approach it is to ask why the
bug has been marked as bogus rather than ranting that it has. 

We deal with many bugs each day and have limited time thus those that
get fixed are those which either are highly important to us (If Im
affected by a bug Ill fix it myself I wont expect other people too) or
one that affects a lot of people. 

Remember you have not paid for PHP and are asking us to do work for you
for free. Now you have spent an hour fixing that bug and Ill have a
look at the patch now check it fixes it and does not break anything
else and if that is the case then it will be applied before the next
version and I thank you for your time, but I promise you it will still
use up at least 20 mins of my time (and IMHO my time is more important
to me than your time is).

So what I am saying is that yes you have a bug in PHP you want fixed
but dont expect it to happen straight away, localizing and fixing a bug
and checking its implications is a slow and boring game and we dont
always get it right but we do it for free so have a touch more patience
with us and we are likley to be more helpful.

Sorry to rant.

- James





[2002-10-01 08:58:29] [EMAIL PROTECTED]

OK, if you cannot correct your own program without misleading words
(you said before TWICE that there is no bug, and it is the ONLY thing
disagreeable to me), get it:

php-4.2.3/TSRM/tsrm_virtual_cwd.h, line 56:

- #define IS_ABSOLUTE_PATH(path, len) \
-   (len >= 2 && isalpha(path[0]) && path[1] == ':')

+ #define IS_ABSOLUTE_PATH(path, len) \
+   (len >= 2 && isalpha(path[0]) && path[1] == ':') \
+   || (len >= 1 && IS_SLASH(path[0]))

This section is under #ifdef TSRM_WIN32 block (of course). 

I'm not a specialist in PHP core, so I have spent about an hour to find
bug location. Unfortunately I CANNOT stop on that, because our users
still download PHP from your site. I will be very glad if you correct
this bug in the next version (4.3.0 I suppose?).



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/19689

-- 
Edit this bug report at http://bugs.php.net/?id=19689&edit=1






      1   2    >

1 - 100 of 111 matches

Mail list logo