#20539 [Com]: PHP CLI Segmentation Fault

[boris]

 ID:   20539
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2002-11-21 (stable)
 New Comment:

After a very long night I solved the problem. Don't hurt me ! The
standard php make install doesn't create the php-cli.ini and if this
file is missing my php-cli segfaults. If it's present - all is fine.


Previous Comments:


[2002-11-27 07:30:32] [EMAIL PROTECTED]

Recently I set up a second linux box and repeated all. It works - but
why. I updated bcc, bison, etc to the newest version on both machines.
The new one is okay, the old one segfaults. Any Ideas how I can check
the differences which can cause the fault ?



[2002-11-27 02:58:43] [EMAIL PROTECTED]

If it's broken hard- or software. Why the php4 apache module works
perfect? The same script called by web is running w/o any error.

Well, broken sofware may cause the fault - but which software is needed
by CLI SAPI and NOT by the apache module. This would help me to find a
possible broken piece of software.

Because the segfault is produced neither in the apache module nor CGI
and only in CLI, imho it's bug in php. Perhaps in assembly to other
software packages, right.

But - "It's not PHPs fault" Isn't a good solution for me. Guess what?
Shall I reinstall the complete server? I can't.

I will be very appreciated for any hints that solve my problem apart
from reinstalling all the software I'm running.



[2002-11-27 02:38:42] [EMAIL PROTECTED]

he is probably not, see #20604



[2002-11-26 20:42:46] [EMAIL PROTECTED]

This can be anything from broken hardware to some file errors..but
surely it's not bug in PHP since you're the only one reporting it.




[2002-11-26 06:27:59] [EMAIL PROTECTED]

Today I tried snap php4-STABLE-200211261030.tar.gz. It produces the
same segfault like reported above.



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

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

#20408 [NoF->Opn]: doesn't work in $make install

[whpark70]

 ID:   20408
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   No Feedback
+Status:   Open
 Bug Type: Java related
 Operating System: Compaq tru64
 PHP Version:  4CVS-2002-11-13
 New Comment:

I received the reqeust.
Other tester provided feedback. therefore
I do it


Previous Comments:


[2002-11-26 20:03:34] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-11-19 10:25:59] [EMAIL PROTECTED]

I've got the same problem so here's an attenmpt at some feedback.
This is what "make install" is doing when it fails:

sapi/cli/php -n
/usr/local/src/php4-STABLE-200211141630/pear/install-pear.php
/usr/local/src/php4-STABLE-200211141630/pear/package-Archive_Tar.
xml

/usr/local/src/php4-STABLE-200211141630)$ gdb sapi/cli/php core
GNU gdb 5.0-tru64-010710
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "alphaev56-dec-osf5.1"...

warning: big endian file does not match little endian target.
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /sbin/loader...done.
Loaded symbols for /sbin/loader
Reading symbols from /usr/local/pgsql/lib/libpq.so.2.2...done.
Loaded symbols for /usr/local/pgsql/lib/libpq.so.2.2
Reading symbols from /usr/local/lib/libldap.so...done.
Loaded symbols for /usr/local/lib/libldap.so
Reading symbols from /usr/local/lib/liblber.so...done.
Loaded symbols for /usr/local/lib/liblber.so
Reading symbols from /usr/local/lib/libintl.so...done.
Loaded symbols for /usr/local/lib/libintl.so
Reading symbols from /usr/local/lib/libiconv.so...done.
Loaded symbols for /usr/local/lib/libiconv.so
Reading symbols from /usr/shlib/libc.so...done.
Loaded symbols for /usr/shlib/libc.so
Reading symbols from /usr/local/lib/libpng.so.3.1.2.5...done.
Loaded symbols for /usr/local/lib/libpng.so.3.1.2.5
Reading symbols from /usr/local/lib/libz.so...done.
Loaded symbols for /usr/local/lib/libz.so
Reading symbols from /usr/local/lib/libgdbm.so...done.
Loaded symbols for /usr/local/lib/libgdbm.so
Reading symbols from /usr/shlib/libcrypt.so...done.
Loaded symbols for /usr/shlib/libcrypt.so
Reading symbols from /usr/shlib/libm.so...done.
Loaded symbols for /usr/shlib/libm.so
Reading symbols from /usr/shlib/libbasecrypt.so...done.
Loaded symbols for /usr/shlib/libbasecrypt.so
Reading symbols from /usr/shlib/librt.so...done.
Loaded symbols for /usr/shlib/librt.so
Reading symbols from /usr/shlib/libcxx.so...done.
Loaded symbols for /usr/shlib/libcxx.so
Reading symbols from /usr/shlib/libpthread.so...done.
Loaded symbols for /usr/shlib/libpthread.so
Reading symbols from /usr/shlib/libexc.so...done.
Loaded symbols for /usr/shlib/libexc.so
#0  0x3ff8057d728 in __nxm_thread_kill () from
/usr/shlib/libpthread.so
(gdb) bt
#0  0x3ff8057d728 in __nxm_thread_kill () from
/usr/shlib/libpthread.so
#1  0x3ff80576564 in pthread_kill () from /usr/shlib/libpthread.so
#2  0x3ff80581aec in __excInit () from /usr/shlib/libpthread.so
#3  0x3ff807e3aa4 in exc_unwind_rfp () from /usr/shlib/libexc.so
warning: Hit beginning of text section without finding
warning: enclosing function for address 0x11ffed270
This warning occurs if you are debugging a function without any
symbols
(for example, in a stripped executable).  In that case, you may wish
to
increase the size of the search with the `set heuristic-fence-post'
command.

Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.
(gdb) set heuristic-fence-post 0
(gdb) bt
#0  0x3ff8057d728 in __nxm_thread_kill () from
/usr/shlib/libpthread.so
#1  0x3ff80576564 in pthread_kill () from /usr/shlib/libpthread.so
#2  0x3ff80581aec in __excInit () from /usr/shlib/libpthread.so
#3  0x3ff807e3aa4 in exc_unwind_rfp () from /usr/shlib/libexc.so
warning: Hit beginning of text section without finding
warning: enclosing function for address 0x11ffed270

- Pat.



[2002-11-13 08:10:57] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http:

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

[rreham]

 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:

please help me because this is my 4th week
i have pws on my computer and i have installed the mysql and then i
have installed the phpmyadin(sharing the folder and give him alias name
phpmyadmin) and correct its config file(user id-password)to match the
mysql then when i open the php myadmin from the browser at
url:http://localhost/phpmyadmin   i recive this message:
no outhentication to view this page 
i do not know where is the problem so please help me 
thank you in advance


Previous Comments:


[2002-11-27 09:02:00] [EMAIL PROTECTED]

please this bug is not a php bug 
is a bull shit bug of phpmyadmin
this application is a nightmare totaly unsecure and uggly

i'm writing a kernel mysql admin in php with classes (sic)
and api in the same time in java

i think i'll be ready in two months.

i haven't any problems with this version of php
and all my hold big applications doesn't bug and run 
correctly

so i say php bug or phpmyadmin bug ?



[2002-11-26 14:37:55] [EMAIL PROTECTED]

Does this problem exist in the PHP 4.2.3 Win 32 download binary?



[2002-11-24 16:55:57] [EMAIL PROTECTED]

Maybe stupid hint... for people who are having problems with
phpMyAdmin. Did you checked php.ini for directive magic_quotes_gpc? It
_MUST_ be set to Off, this directive can not be overwritten in PHP code
(as mentioned in PHP documentation). If you can not turn it off for
whole webserver in php.ini, use .htaccess and put "php_flag
magic_quotes_gpc off" in (without quotes :).



[2002-11-22 13:21:27] [EMAIL PROTECTED]

I forgot to mention --disable-mbstring.
If you can make your build from the source, still want to use 4.2.3,
please specify --disable-mbstring in configure params, and the problem
would be gone. However the case you cannot make use of mysql from
within your php scripts is not directly relevant to this bug. Anyway
all that I can say is this bug was really fixed...




[2002-11-22 11:10:01] [EMAIL PROTECTED]

Well, I guess any one interested in using phpMyAdmin just can't use php
4.2.3? that's really pathetic. I love php and so on, but at least they
could *fix* the 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/19404

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

#20691 [NEW]: strftime("%u")

[ManfredRauer]

From: [EMAIL PROTECTED]
Operating system: Windows
PHP version:  4.2.3
PHP Bug Type: Date/time related
Bug description:  strftime("%u")


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

#20539 [Bgs->Fbk]: PHP CLI Segmentation Fault

[sniper]

 ID:   20539
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Bogus
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2002-11-21 (stable)
 New Comment:

Is the backtrace still the same?
And do you have any other php-*.ini files anywhere in your system? If
you do have, please make a diff between it and
the php.ini-dist



Previous Comments:


[2002-11-28 02:09:28] [EMAIL PROTECTED]

After a very long night I solved the problem. Don't hurt me ! The
standard php make install doesn't create the php-cli.ini and if this
file is missing my php-cli segfaults. If it's present - all is fine.



[2002-11-27 07:30:32] [EMAIL PROTECTED]

Recently I set up a second linux box and repeated all. It works - but
why. I updated bcc, bison, etc to the newest version on both machines.
The new one is okay, the old one segfaults. Any Ideas how I can check
the differences which can cause the fault ?



[2002-11-27 02:58:43] [EMAIL PROTECTED]

If it's broken hard- or software. Why the php4 apache module works
perfect? The same script called by web is running w/o any error.

Well, broken sofware may cause the fault - but which software is needed
by CLI SAPI and NOT by the apache module. This would help me to find a
possible broken piece of software.

Because the segfault is produced neither in the apache module nor CGI
and only in CLI, imho it's bug in php. Perhaps in assembly to other
software packages, right.

But - "It's not PHPs fault" Isn't a good solution for me. Guess what?
Shall I reinstall the complete server? I can't.

I will be very appreciated for any hints that solve my problem apart
from reinstalling all the software I'm running.



[2002-11-27 02:38:42] [EMAIL PROTECTED]

he is probably not, see #20604



[2002-11-26 20:42:46] [EMAIL PROTECTED]

This can be anything from broken hardware to some file errors..but
surely it's not bug in PHP since you're the only one reporting it.




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

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

#20539 [Com]: PHP CLI Segmentation Fault

[boris]

 ID:   20539
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2002-11-21 (stable)
 New Comment:

If I remove the php-cli.ini from my /usr/local/lib directory the
backtrace is the same. And no - I do not have multiple php-*.ini files.
One php.ini and a php-cli.ini ( since today morning ).

I copied the original php.ini-dist to /usr/local/lib/php-cli.ini and
everything is fine. ( I will customize the file later )


Previous Comments:


[2002-11-28 02:23:54] [EMAIL PROTECTED]

Is the backtrace still the same?
And do you have any other php-*.ini files anywhere in your system? If
you do have, please make a diff between it and
the php.ini-dist




[2002-11-28 02:09:28] [EMAIL PROTECTED]

After a very long night I solved the problem. Don't hurt me ! The
standard php make install doesn't create the php-cli.ini and if this
file is missing my php-cli segfaults. If it's present - all is fine.



[2002-11-27 07:30:32] [EMAIL PROTECTED]

Recently I set up a second linux box and repeated all. It works - but
why. I updated bcc, bison, etc to the newest version on both machines.
The new one is okay, the old one segfaults. Any Ideas how I can check
the differences which can cause the fault ?



[2002-11-27 02:58:43] [EMAIL PROTECTED]

If it's broken hard- or software. Why the php4 apache module works
perfect? The same script called by web is running w/o any error.

Well, broken sofware may cause the fault - but which software is needed
by CLI SAPI and NOT by the apache module. This would help me to find a
possible broken piece of software.

Because the segfault is produced neither in the apache module nor CGI
and only in CLI, imho it's bug in php. Perhaps in assembly to other
software packages, right.

But - "It's not PHPs fault" Isn't a good solution for me. Guess what?
Shall I reinstall the complete server? I can't.

I will be very appreciated for any hints that solve my problem apart
from reinstalling all the software I'm running.



[2002-11-27 02:38:42] [EMAIL PROTECTED]

he is probably not, see #20604



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

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

#20539 [Fbk]: PHP CLI Segmentation Fault

[sniper]

 ID:   20539
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2002-11-21 (stable)
 New Comment:

Is that php.ini loaded by php then when this crash happens?



Previous Comments:


[2002-11-28 02:28:09] [EMAIL PROTECTED]

If I remove the php-cli.ini from my /usr/local/lib directory the
backtrace is the same. And no - I do not have multiple php-*.ini files.
One php.ini and a php-cli.ini ( since today morning ).

I copied the original php.ini-dist to /usr/local/lib/php-cli.ini and
everything is fine. ( I will customize the file later )



[2002-11-28 02:23:54] [EMAIL PROTECTED]

Is the backtrace still the same?
And do you have any other php-*.ini files anywhere in your system? If
you do have, please make a diff between it and
the php.ini-dist




[2002-11-28 02:09:28] [EMAIL PROTECTED]

After a very long night I solved the problem. Don't hurt me ! The
standard php make install doesn't create the php-cli.ini and if this
file is missing my php-cli segfaults. If it's present - all is fine.



[2002-11-27 07:30:32] [EMAIL PROTECTED]

Recently I set up a second linux box and repeated all. It works - but
why. I updated bcc, bison, etc to the newest version on both machines.
The new one is okay, the old one segfaults. Any Ideas how I can check
the differences which can cause the fault ?



[2002-11-27 02:58:43] [EMAIL PROTECTED]

If it's broken hard- or software. Why the php4 apache module works
perfect? The same script called by web is running w/o any error.

Well, broken sofware may cause the fault - but which software is needed
by CLI SAPI and NOT by the apache module. This would help me to find a
possible broken piece of software.

Because the segfault is produced neither in the apache module nor CGI
and only in CLI, imho it's bug in php. Perhaps in assembly to other
software packages, right.

But - "It's not PHPs fault" Isn't a good solution for me. Guess what?
Shall I reinstall the complete server? I can't.

I will be very appreciated for any hints that solve my problem apart
from reinstalling all the software I'm running.



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

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

#20691 [Opn->Bgs]: strftime("%u")

[jan]

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

RTFM :)
http://de.php.net/manual/en/function.strftime.php states:
  Note:  Not all conversion specifiers may be supported by your C
library, in which case they will not be supported by PHP's strftime().
This means that e.g. %e, %T and %D (there might be more) will not work
on Windows


Previous Comments:


[2002-11-28 02:23:54] [EMAIL PROTECTED]






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

#20692 [NEW]: incrementing in for loop

[kuba]

From: [EMAIL PROTECTED]
Operating system: RH Linux 7.2
PHP version:  4.2.3
PHP Bug Type: Output Control
Bug description:  incrementing in for loop

there is a problem with for loop
code:

$a=1;
$b=1.5;
$step=0.1;

for ($i=$a;$i<=$b;$i=$i+$step) {
  echo "$i";
}



prints:
1
1.1
1.2
1.3
1.4


and 1.5 value is skipped
when changing this values
to $a=10;$b=15;$step=1;
everything is OK (15 is printed)
so I guess problem is with floating point values




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

#20539 [Com]: PHP CLI Segmentation Fault

[boris]

 ID:   20539
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  4CVS-2002-11-21 (stable)
 New Comment:

I can't tell. Is php.ini loaded if php-cli.ini doesn't exists by
default ?


Previous Comments:


[2002-11-28 02:32:59] [EMAIL PROTECTED]

Is that php.ini loaded by php then when this crash happens?




[2002-11-28 02:28:09] [EMAIL PROTECTED]

If I remove the php-cli.ini from my /usr/local/lib directory the
backtrace is the same. And no - I do not have multiple php-*.ini files.
One php.ini and a php-cli.ini ( since today morning ).

I copied the original php.ini-dist to /usr/local/lib/php-cli.ini and
everything is fine. ( I will customize the file later )



[2002-11-28 02:23:54] [EMAIL PROTECTED]

Is the backtrace still the same?
And do you have any other php-*.ini files anywhere in your system? If
you do have, please make a diff between it and
the php.ini-dist




[2002-11-28 02:09:28] [EMAIL PROTECTED]

After a very long night I solved the problem. Don't hurt me ! The
standard php make install doesn't create the php-cli.ini and if this
file is missing my php-cli segfaults. If it's present - all is fine.



[2002-11-27 07:30:32] [EMAIL PROTECTED]

Recently I set up a second linux box and repeated all. It works - but
why. I updated bcc, bison, etc to the newest version on both machines.
The new one is okay, the old one segfaults. Any Ideas how I can check
the differences which can cause the fault ?



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

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

#20693 [NEW]: round() doesn't always work

[bero]

From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux (pool)
PHP version:  4.2.3
PHP Bug Type: *Math Functions
Bug description:  round() doesn't always work

In a simple script consisting a single line like 

round() produces a proper output. However in one of my scripts, where
round() is used inside a method of a sophisticated object, it gives the
folowig results:
echo round(195.583, 2); -> 195
echo round(195.583, 1); -> 195
echo round(195.583, 0); -> 195
echo round(195.583, -1); -> 200
echo round(195.583, -2); -> 200

I use PHP4.2.3 with Apache 1.3.26, both of them are original Debian's
binaries. I have reproduced this behaviour on several machines.


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

#20692 [Opn->Bgs]: incrementing in for loop

[derick]

 ID:   20692
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: RH Linux 7.2
 PHP Version:  4.2.3
 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-11-28 02:44:06] [EMAIL PROTECTED]

there is a problem with for loop
code:

$a=1;
$b=1.5;
$step=0.1;

for ($i=$a;$i<=$b;$i=$i+$step) {
  echo "$i";
}



prints:
1
1.1
1.2
1.3
1.4


and 1.5 value is skipped
when changing this values
to $a=10;$b=15;$step=1;
everything is OK (15 is printed)
so I guess problem is with floating point values








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

#20539 [Fbk->Ctl]: PHP CLI Segmentation Fault

[sniper]

 ID:   20539
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Critical
-Bug Type: Reproducible crash
+Bug Type: Session related
 Operating System: Linux
 PHP Version:  4CVS-2002-11-21 (stable)
 New Comment:

This crash happens when php.ini (or php-cli.ini :) contains
'session.auto_start = 1' AND 'magic_quotes_gpc = On'




Previous Comments:


[2002-11-28 02:46:31] [EMAIL PROTECTED]

I can't tell. Is php.ini loaded if php-cli.ini doesn't exists by
default ?



[2002-11-28 02:32:59] [EMAIL PROTECTED]

Is that php.ini loaded by php then when this crash happens?




[2002-11-28 02:28:09] [EMAIL PROTECTED]

If I remove the php-cli.ini from my /usr/local/lib directory the
backtrace is the same. And no - I do not have multiple php-*.ini files.
One php.ini and a php-cli.ini ( since today morning ).

I copied the original php.ini-dist to /usr/local/lib/php-cli.ini and
everything is fine. ( I will customize the file later )



[2002-11-28 02:23:54] [EMAIL PROTECTED]

Is the backtrace still the same?
And do you have any other php-*.ini files anywhere in your system? If
you do have, please make a diff between it and
the php.ini-dist




[2002-11-28 02:09:28] [EMAIL PROTECTED]

After a very long night I solved the problem. Don't hurt me ! The
standard php make install doesn't create the php-cli.ini and if this
file is missing my php-cli segfaults. If it's present - all is fine.



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

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

#20694 [NEW]: html not properly going to browser

[briantmeyer]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 Server
PHP version:  4.3.0RC2
PHP Bug Type: *General Issues
Bug description:  html not properly going to browser

Just installed 4.3.0RC2 zip binary on windows 2000 server 
and iis 5.0 to check it out on my server.
normally use 4.2.3 and seem to be able to swap out installs 
as needed by putting files in and out of my php directory.

4.3.0RC2 seems to not like pages that work fine in 4.2.3. 
Some Pages using the new release display as raw text 
instead of html in some cases. When i look at source in a 
browser the beginning lines are missing although they are 
included. It seems no php is missed as all work i assign is 
completed as expected, just the html sent after the fact 
has missing lines at the top. I would expect it to die as 
it moves through the script, instead it is as if all works 
correctly but at the last moment only sends partial ending 
text to the browser.


As an example, changing the order only of an index page has 
the following results. (The includes here are very simple 
containing mainly html) 

The following works fine but the first line that shows up 
is the 4th with title tags, not :-->





 



HTML content here

While this is much worse and the first tag that shows up is 
 tags that are in classes.php followed by the <
SCRIPT> tag. It skips the title tag.--->





 



HTML content here


Changing php.ini does not help, adjusted it for over 2 
hours to see if a setting affected this. (expose_php and 
various error directives, using the two provided ini files, 
and many random changes) Of course all extensions were 
disabled. Different pages are affected differently.

My gut feeling is that php parses my script and assembles a 
completed html page. At this point something happens that 
deletes the top x lines (it never does half a line) and 
sends the rest to the browser. If enough header shows up i 
get a web page, usually with text at the top of exposed 
javascripts, sometimes i get text.

testing with pages that are simple text or simple html had 
the entire page show up just fine. The requires i used seem 
to be part of the issue as above. I tried looking at the 
index page from phpmyadmin but it would not even load due 
to not being able to find include files.

Switching back to php 4.2.3 fixes all above problems and 
pages again display the doctype and the html head tags. I 
hope someone can make sense of this, or that it is in fact 
a bogus/support issue.

I probably would not have submitted it, except that it is 
the preview release and that my other version works 
splendidly.

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

#20695 [NEW]: substr does not always return a string

[RNova]

From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  substr does not always return a string

substr($s,$n,$m) is supposed to always return a string (at least if $s is a
string and $n and $m are integers).

However:

   is_string(substr($s,strlen($s),$m)) 

returns false, so substr did not return a string.

Example:
$s="";
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";

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

#20695 [Opn]: substr does not always return a string

[RNova]

 ID:   20695
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows 98
 PHP Version:  4.2.3
 New Comment:

substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).

However:

   is_string(substr($s,strlen($s),$m)) 

returns false, so substr did not return a string.

Example:
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";


Previous Comments:


[2002-11-28 04:40:53] [EMAIL PROTECTED]

substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).

However:

   is_string(substr($s,strlen($s),$m)) 

returns false, so substr did not return a string.

Example:
$s="";
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";





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

#20389 [Opn]: user defined session handler is broken

[sniper]

 ID:   20389
 Updated by:   [EMAIL PROTECTED]
-Summary:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: Solaris
 PHP Version:  4.2.3
 New Comment:

Fixed the summary line..and you propably don't have JAVA_LIBPATH set
when you get that java error..
(it's required)



Previous Comments:


[2002-11-27 15:50:58] [EMAIL PROTECTED]

Hi. I decided to go for a snapshot, and chose the latest and greatest:
php4-STABLE-200211271830.

Seems to be a bug in configure:

checking Checking for libjava... 
configure: error: unable to find Java VM libraries in /usr/java

The Java libraries on this machine have not moved since the 4.2.3 build
and the configure options are identical, so I think that there is a
good chance that the problem is with configure, around line 37071 -
part of the libjava.so search process. Do you want a copy of the
config.log?

I've run out time this evening, but I'll ahve another look at the
problem soon.



[2002-11-27 07:37:22] [EMAIL PROTECTED]

The choice is yours; we'd really appreciate some feedback on the 4.3
branch, but you do have the option of the 4.2 branch.

IMO, 4.3 branch is more likely to fix the problem, but may introduce
others (but is actually pretty stable, as far as we can tell so far).

Apparently, our snaps page no longer carries the 4.2 branch as the
stable snap; if you want to try it, you can check it out of CVS
(php.net/anoncvs.php; the branch tag is PHP_4_2).
[You will need some build tools to generate configure]



[2002-11-27 06:43:17] [EMAIL PROTECTED]

OK, fair comment - I can do that. It's just that I had so many problems
with the last upgrade that I didn't want to do it again (our system
layout is *very* unusual) but your request is a reasonable one  and I
would like to help - so, to clarify, we're talking about moving 4.3.0
here, right?



[2002-11-27 06:24:33] [EMAIL PROTECTED]

"The 4.2.x branch is as stable (or more stable) than the 4.2.3."

did you mean the 4.3.x branch? :)





[2002-11-27 06:18:31] [EMAIL PROTECTED]

You have the option of trying 4.2.3 + some fixes or trying the release
candidate of 4.3.

The 4.2.x branch is as stable (or more stable) than the 4.2.3.  If we
were going to release a 4.2.4, that would be it.

However, we are not going to do that; we are focusing on 4.3 instead.

There is not much more we can do for you without access to your boxes,
and why should we do that?  You are the one being paid to look after
your boxes, not us.

Please test a newer version as suggested so that we can determine if
the problem has been corrected already.
If it has not, then someone may *volunteer* to look into the problem
and resolve it.

[Remember; you can test a newer version of PHP by running a separate
apache instance on another port.]




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

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

#20695 [Opn->Fbk]: substr does not always return a string

[jan]

 ID:   20695
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Windows 98
 PHP Version:  4.2.3
 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

jan@dahlia ~> php bug_20695.php
1
substr("A",0,1):1
substr("A",0,0):1
substr("A",1,1):
substr("A",1,0):
jan@dahlia ~> php -v
PHP 4.4.0-dev (cli)

works fine here



Previous Comments:


[2002-11-28 04:45:55] [EMAIL PROTECTED]

substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).

However:

   is_string(substr($s,strlen($s),$m)) 

returns false, so substr did not return a string.

Example:
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";



[2002-11-28 04:40:53] [EMAIL PROTECTED]

substr($s,$n,$m) is supposed to always return a string (at least if $s
is a string and $n and $m are integers).

However:

   is_string(substr($s,strlen($s),$m)) 

returns false, so substr did not return a string.

Example:
$s="";
echo is_string("")."\n";
echo "substr(\"A\",0,1):".is_string(substr("A",0,1))."\n";
echo "substr(\"A\",0,0):".is_string(substr("A",0,0))."\n";
echo "substr(\"A\",1,1):".is_string(substr("A",1,1))."\n";
echo "substr(\"A\",1,0):".is_string(substr("A",1,0))."\n";





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

#20487 [Opn->Fbk]: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite

[sniper]

 ID:   20487
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2000
 PHP Version:  4.3.0RC1
 New Comment:

Please test with RC2. Or preferrably with the latest STABLE snapshot
from http://snaps.php.net




Previous Comments:


[2002-11-27 15:07:59] [EMAIL PROTECTED]

I think we can move this Report to "closed" because it seems to be
fixed in RC2 (-> I haven't tried under heavy load)

I've tried with 2,4 and even 100 Frames ;-)
Apache and Apache2 didn't crash.

mfg DMIII



[2002-11-22 18:09:32] [EMAIL PROTECTED]

i've experienced this same bug with 4.3.0RC1 (Apache 2.0.43 on Windows
XP Pro (Service Pack 1)... In my experience it seems to recurr
randomly, but the logic presented here, does hold true. I've also
witnessed similar crashes with 4.2.4-dev, but 4.3 does it far more
frequently.. Presumably as long as two requests are going on at the
same time.. it doesn't have to be from the same origin..



[2002-11-21 09:24:59] [EMAIL PROTECTED]

There is the same Problem with Apache2 (2.0.43) and PHP 4.3.0RC1!!



[2002-11-21 06:14:17] [EMAIL PROTECTED]

The more frames you load the earlier the bug occours!

I've tried with 4 frames -> 2xReload and it crashes!



[2002-11-20 22:51:00] [EMAIL PROTECTED]

Seems to be Apache version independent.
Same crashes on same test cases reproduced with:
Apache 1.3.27, 2.0.42 and 2.0.43.
Windows 2000 SP3
Mozilla 1.1
Standart php.ini and httpd.conf.

Also I do had the same problems whatever the value of
MaxRequestsPerChild in httpd.conf.

This is new to 4.3.0RC1.
Never had such things with 4.2.3.


Thanks.



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

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

#20686 [Opn->Bgs]: problems with the session.save_path variable

[sniper]

 ID:   20686
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session 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-11-27 16:57:22] [EMAIL PROTECTED]

Forget to tell you that I'm running php in module mode...



[2002-11-27 16:41:31] [EMAIL PROTECTED]

Hi folks,

I really don't know if this is a bug but I have a problem that I can't
solve on my own. I'm running windows xp with the apache2 webserver and
php 4.2.3. 

Today I tried to use start_session() command but got some uggly message
that /tmp directory can't be found. Now problem here is that I have
changed session.save_path variable in php.ini from /tmp to the
c:\windows\temp\phptemp and offcourse restarted appache after that.

Now I hope that some can help me with this one.

Thanks
Darren




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

#20696 [NEW]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[jason]

From: [EMAIL PROTECTED]
Operating system: Linux Red Hat 7.3
PHP version:  4.2.3
PHP Bug Type: Filesystem function related
Bug description:  Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

When uploading a large file > 8192K, this problem comes up. 

HTML Page





Testing.php

The variable of $HTTP_POST_FILES["file_attachment"]["size"] will equal
8192K if the uploaded file is greater than 8192K, however the file is say
4000K, then the variable $HTTP_POST_FILES["file_attachment"]["size"] will
be equal to 4000K. 

We have made the necessary adjustments to php.ini. 

post_max_size = "14M"
upload_max_filesize = "12M"

We have increased the memory limit to "16M". 

Everything is working fine, except when the file size is greater than
8192K

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

#20687 [Opn->Fbk]: Compile error on dbase module

[sniper]

 ID:   20687
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: linux redhat 7.1 gcc 2.96
 PHP Version:  4.2.3
 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


Previous Comments:


[2002-11-27 19:26:21] [EMAIL PROTECTED]

Hi... 

I was trying to compile module dbase and during the process he returns
me the following mistake: 

dbf_head.c:249:49: too many arguments for macro "VCWD_OPEN"
dbf_head.c:252:48: too many arguments for macro "VCWD_OPEN"
make[1]: *** [dbf_head.slo] Error 1
make[1]: Leaving directory `/root/php-4.2.3/ext/dbase'
make: *** [all-recursive] Error 1

Sequence of commands:

/root/php-4.2.3/ext/dbase/phpize
/root/php-4.2.3/ext/dbase/./configure
/root/php-4.2.3/ext/dbase/make






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

#20690 [Opn]: fopen should check with uploaded_file not only open_basedir

[sniper]

 ID:   20690
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
-Bug Type: Filesystem function related
+Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.2.3
 New Comment:

reclassified.



Previous Comments:


[2002-11-27 20:57:25] [EMAIL PROTECTED]

(feature request)
in restrict mode, php check fopen() file with uploaded_file when it's
not in open_basedir
by now, i have to move_uploaded_file() to my {open_basedir}/tmp, read
it, and delete it in shutdown_function.

i know, we can config php to use stand alone uploadtmp instead of /tmp,
and add it to open_basedir, e.g.: /www/tmp
but would'nt it nice to check with uploaded_file ?
:)




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

#20693 [Opn->Fbk]: round() doesn't always work

[sniper]

 ID:   20693
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: *Math Functions
 Operating System: Debian GNU/Linux (pool)
 PHP Version:  4.2.3
 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


Previous Comments:


[2002-11-28 03:22:38] [EMAIL PROTECTED]

In a simple script consisting a single line like 

round() produces a proper output. However in one of my scripts, where
round() is used inside a method of a sophisticated object, it gives the
folowig results:
echo round(195.583, 2); -> 195
echo round(195.583, 1); -> 195
echo round(195.583, 0); -> 195
echo round(195.583, -1); -> 200
echo round(195.583, -2); -> 200

I use PHP4.2.3 with Apache 1.3.26, both of them are original Debian's
binaries. I have reproduced this behaviour on several machines.






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

#20696 [Opn->Fbk]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[sniper]

 ID:   20696
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.2.3
 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


Previous Comments:


[2002-11-28 05:15:49] [EMAIL PROTECTED]

When uploading a large file > 8192K, this problem comes up. 

HTML Page





Testing.php

The variable of $HTTP_POST_FILES["file_attachment"]["size"] will equal
8192K if the uploaded file is greater than 8192K, however the file is
say 4000K, then the variable
$HTTP_POST_FILES["file_attachment"]["size"] will be equal to 4000K. 

We have made the necessary adjustments to php.ini. 

post_max_size = "14M"
upload_max_filesize = "12M"

We have increased the memory limit to "16M". 

Everything is working fine, except when the file size is greater than
8192K

Thanks, 
Jason.




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

#20696 [Fbk]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[sniper]

 ID:   20696
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.2.3
 New Comment:

And are you sure that php.ini is really used by PHP?
(check those values from phpinfo() output)



Previous Comments:


[2002-11-28 05:27: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



[2002-11-28 05:15:49] [EMAIL PROTECTED]

When uploading a large file > 8192K, this problem comes up. 

HTML Page





Testing.php

The variable of $HTTP_POST_FILES["file_attachment"]["size"] will equal
8192K if the uploaded file is greater than 8192K, however the file is
say 4000K, then the variable
$HTTP_POST_FILES["file_attachment"]["size"] will be equal to 4000K. 

We have made the necessary adjustments to php.ini. 

post_max_size = "14M"
upload_max_filesize = "12M"

We have increased the memory limit to "16M". 

Everything is working fine, except when the file size is greater than
8192K

Thanks, 
Jason.




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

#20696 [Fbk->Opn]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[jason]

 ID:   20696
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.2.3
 New Comment:

We will do a phpinfo(); on the very receiving script. 

But a phpinfo(); does show the new values of max_post_size, etc. 

Secondly, before the increased these values in php.ini, the script
would not work and it would generate a file of 0 bytes. 

Thanks, 
Jason.


Previous Comments:


[2002-11-28 05:28:10] [EMAIL PROTECTED]

And are you sure that php.ini is really used by PHP?
(check those values from phpinfo() output)




[2002-11-28 05:27: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



[2002-11-28 05:15:49] [EMAIL PROTECTED]

When uploading a large file > 8192K, this problem comes up. 

HTML Page





Testing.php

The variable of $HTTP_POST_FILES["file_attachment"]["size"] will equal
8192K if the uploaded file is greater than 8192K, however the file is
say 4000K, then the variable
$HTTP_POST_FILES["file_attachment"]["size"] will be equal to 4000K. 

We have made the necessary adjustments to php.ini. 

post_max_size = "14M"
upload_max_filesize = "12M"

We have increased the memory limit to "16M". 

Everything is working fine, except when the file size is greater than
8192K

Thanks, 
Jason.




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

#3697 [Ana->Csd]: open_basedir prevents creating files with fopen

[wez]

 ID:   3697
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Analyzed
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: BSD/OS 4.0.1
 PHP Version:  4.0 Beta 4 Patch Level 1
 New Comment:

seems to be fixed.


Previous Comments:


[2000-08-01 01:01:08] [EMAIL PROTECTED]

DJM reports that problem is fixed. However, he suggests that there is a
better solution to the problem than was implemented.  See message
below.

"I just checked the CVS version.  The primary bug I reported is fixed
in the current sources, though in a somewhat less robust (but simpler)
way than I suggested.  I would still like to have more warning messages
instead of silent failures in various exceptional conditions, as
suggested in my patch; that has not been done so far.  Also, spurious
whitespace has been added in a comment in main/php_realpath.c:260:
/* Check for overflow */
"



[2000-07-29 23:59:54] [EMAIL PROTECTED]

Have you tried a recent release?  If so, does the problem still occur?



[2000-03-02 01:24:46] [EMAIL PROTECTED]

Some more warning messages to alert about exceptional conditions would
be helpful.  Also, there's a misformatted warning message due to the
appending of " in 

#20696 [Opn->Fbk]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[sniper]

 ID:   20696
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.2.3
 New Comment:

Please try the snapshot..I can not reproduce this.



Previous Comments:


[2002-11-28 05:35:33] [EMAIL PROTECTED]

We will do a phpinfo(); on the very receiving script. 

But a phpinfo(); does show the new values of max_post_size, etc. 

Secondly, before the increased these values in php.ini, the script
would not work and it would generate a file of 0 bytes. 

Thanks, 
Jason.



[2002-11-28 05:28:10] [EMAIL PROTECTED]

And are you sure that php.ini is really used by PHP?
(check those values from phpinfo() output)




[2002-11-28 05:27: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



[2002-11-28 05:15:49] [EMAIL PROTECTED]

When uploading a large file > 8192K, this problem comes up. 

HTML Page





Testing.php

The variable of $HTTP_POST_FILES["file_attachment"]["size"] will equal
8192K if the uploaded file is greater than 8192K, however the file is
say 4000K, then the variable
$HTTP_POST_FILES["file_attachment"]["size"] will be equal to 4000K. 

We have made the necessary adjustments to php.ini. 

post_max_size = "14M"
upload_max_filesize = "12M"

We have increased the memory limit to "16M". 

Everything is working fine, except when the file size is greater than
8192K

Thanks, 
Jason.




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

#20686 [Bgs]: problems with the session.save_path variable

[pretorian_g]

 ID:   20686
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: Windows XP
 PHP Version:  4.2.3
 New Comment:

Maybe not... But it's a PHP Manual who told me to change that variable
in php.ini if I wanted to run sessions on win32 system. And when I
change it, as manual says, it isn't working... I'm not asking for help
on using start_session() command. I just wonder why things aren't
working as they should according to the PHP manual.

Thanks anyway for your response :-) I will try to ask my question on
some of the php forum.

Regards
Darren


Previous Comments:


[2002-11-28 05:06:45] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.



[2002-11-27 16:57:22] [EMAIL PROTECTED]

Forget to tell you that I'm running php in module mode...



[2002-11-27 16:41:31] [EMAIL PROTECTED]

Hi folks,

I really don't know if this is a bug but I have a problem that I can't
solve on my own. I'm running windows xp with the apache2 webserver and
php 4.2.3. 

Today I tried to use start_session() command but got some uggly message
that /tmp directory can't be found. Now problem here is that I have
changed session.save_path variable in php.ini from /tmp to the
c:\windows\temp\phptemp and offcourse restarted appache after that.

Now I hope that some can help me with this one.

Thanks
Darren




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

#20697 [NEW]: Could not get Full URL

[agarwal_kapil]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.0
PHP Bug Type: PHP options/info functions
Bug description:  Could not get Full URL 

I was trying to get current url of the page to determine which protocol
site is using...please suggest something so that i can find out that site
is using HTTPS or http protocol..

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

#20697 [Opn->Bgs]: Could not get Full URL

[jan]

 ID:   20697
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Linux
 PHP Version:  4.2.0
 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-11-28 06:01:48] [EMAIL PROTECTED]

I was trying to get current url of the page to determine which protocol
site is using...please suggest something so that i can find out that
site is using HTTPS or http protocol..

Thanks And Regards
kapil




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

#9212 [Opn]: fpassthru ignoring output buffering

[wez]

 ID:   9212
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Linux 2.2.12-20
 PHP Version:  4.0.4
 New Comment:

Seems to use buffers now (in 4.3).
I'm not sure if this is the case in 4.2, or even if we
want this behaviour.
Derick?


Previous Comments:


[2001-02-11 13:39:51] [EMAIL PROTECTED]

Actually, fpassthru seems to partial support the output buffering as
placing it between ob_start / ob_end_clean generates no output.
ob_get_contents() placed after the fpassthru correctly returns the
output fpassthru would have generated. My concern here was that
fpassthru seems to be generating a header (headers_sent() returns true)
even though the rest of the output is being correctly buffered. Is the
buffering happening by a happy accident?

Is there a list of functions that work (or don't work) with output
buffering?



[2001-02-11 11:17:15] [EMAIL PROTECTED]

passtru doesn't use the output buffering functions. It's not meant to
be, so changing to Feature request.



[2001-02-11 11:06:21] [EMAIL PROTECTED]

When fpassthru() is used within an ob_start / ob_end_clean block, a
subsequent call to header() fails because headers have already been
sent. The following script reproduces the problem:



Ran as cgi (ie 'php head.php'), but the apache module exhibits the same
problem. This problem may be similar to bug #8807

./configure --with-apxs=/usr/local/etc/httpd/bin/apxs
--enable-versioning --with-mysql --enable-track-vars

no php.ini is used




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

#10262 [Opn->Csd]: fgets/fputs timeout

[wez]

 ID:   10262
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  4.0.4pl1
 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:


[2001-04-10 11:10:45] [EMAIL PROTECTED]

How about an optional timeout argument on fgets/fputs in case
connections are taking too long to respond?

Or even better a set_timeout() function which could be given a function
to run, a timeout and the arguments to pass to said function which
would return if the timeout is reached.




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

#20696 [Fbk->Opn]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[jason]

 ID:   20696
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.2.3
 New Comment:

I've isolated the whole situation and I couldn't replicate the problem.


However, I've found that it's because the filesize is stored to the
mysql database and the field is mediumint(9), and when I increased it
to BigInt(12), it started workingThis is perhaps weird of
Mysql

Sorry to have bothered you. We've got the problem isolated. 

thanks for your time, I hope that we may be able to contribute
something to PHP development one day. 

thanks, 
Jason.


Previous Comments:


[2002-11-28 05:50:17] [EMAIL PROTECTED]

Please try the snapshot..I can not reproduce this.




[2002-11-28 05:35:33] [EMAIL PROTECTED]

We will do a phpinfo(); on the very receiving script. 

But a phpinfo(); does show the new values of max_post_size, etc. 

Secondly, before the increased these values in php.ini, the script
would not work and it would generate a file of 0 bytes. 

Thanks, 
Jason.



[2002-11-28 05:28:10] [EMAIL PROTECTED]

And are you sure that php.ini is really used by PHP?
(check those values from phpinfo() output)




[2002-11-28 05:27: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



[2002-11-28 05:15:49] [EMAIL PROTECTED]

When uploading a large file > 8192K, this problem comes up. 

HTML Page





Testing.php

The variable of $HTTP_POST_FILES["file_attachment"]["size"] will equal
8192K if the uploaded file is greater than 8192K, however the file is
say 4000K, then the variable
$HTTP_POST_FILES["file_attachment"]["size"] will be equal to 4000K. 

We have made the necessary adjustments to php.ini. 

post_max_size = "14M"
upload_max_filesize = "12M"

We have increased the memory limit to "16M". 

Everything is working fine, except when the file size is greater than
8192K

Thanks, 
Jason.




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

#20698 [NEW]: preg_match_all causes php to fail with "unknow software exception"

[thingol]

From: [EMAIL PROTECTED]
Operating system: Win32
PHP version:  4.2.3
PHP Bug Type: PCRE related
Bug description:  preg_match_all causes php to fail with "unknow software exception"

If the text for preg_match_all is bigger than some value, many regexp
constructions causes php to terminate.

This code crashes php (on win32 only):


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

#20696 [Opn->Bgs]: Large File Upload problem $HTTP_POST_FILES["file_attachment"]["size"]

[jan]

 ID:   20696
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Linux Red Hat 7.3
 PHP Version:  4.2.3
 New Comment:

bogus then


Previous Comments:


[2002-11-28 06:17:13] [EMAIL PROTECTED]

I've isolated the whole situation and I couldn't replicate the problem.


However, I've found that it's because the filesize is stored to the
mysql database and the field is mediumint(9), and when I increased it
to BigInt(12), it started workingThis is perhaps weird of
Mysql

Sorry to have bothered you. We've got the problem isolated. 

thanks for your time, I hope that we may be able to contribute
something to PHP development one day. 

thanks, 
Jason.



[2002-11-28 05:50:17] [EMAIL PROTECTED]

Please try the snapshot..I can not reproduce this.




[2002-11-28 05:35:33] [EMAIL PROTECTED]

We will do a phpinfo(); on the very receiving script. 

But a phpinfo(); does show the new values of max_post_size, etc. 

Secondly, before the increased these values in php.ini, the script
would not work and it would generate a file of 0 bytes. 

Thanks, 
Jason.



[2002-11-28 05:28:10] [EMAIL PROTECTED]

And are you sure that php.ini is really used by PHP?
(check those values from phpinfo() output)




[2002-11-28 05:27: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



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

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

#20698 [Opn->Fbk]: preg_match_all causes php to fail with "unknow software exception"

[sniper]

 ID:   20698
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: Win32
 PHP Version:  4.2.3
 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


Previous Comments:


[2002-11-28 06:26:10] [EMAIL PROTECTED]

If the text for preg_match_all is bigger than some value, many regexp
constructions causes php to terminate.

This code crashes php (on win32 only):






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

#14976 [Opn->Csd]: gzopen URLs like fopen() does

[wez]

 ID:   14976
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: ANY (Linux)
 PHP Version:  4.1.1
 New Comment:

You can do this in 4.3:

fopen("compress.zlib://http://foobar.com";);

It would be great if you could test RC2 and verify that
this works.
RC2 available from http://qa.php.net


Previous Comments:


[2002-01-10 15:06:18] [EMAIL PROTECTED]

One feature of PHP that I find REALLY handy is the 
transparent handling of 'remote' files (i.e. http:// and 
ftp:// URL's).  

Currently gzopen "doesn't quite" handle anything but local 
files.  Attempting to gzopen, for example, an 
"ftp://some.host.net/pub/somefile.gz"; URL currently 
returns a strange error (the error itself reported as 
Bug#14814).

I traced a gzopen("ftp://some.host.net/pub/somefile.gz";) 
sort of connection with ethereal, and noticed that 
connection to the ftp server IS made, login is performed, 
passive mode switched to, and the file is STARTED 
downloading (about 3 1k packets came across) but the 
script dies with a "Warning: Success in " error 
message.

As I'm running the script from the command line as a 
standalone utility, I can instead do something like :
wget -q ftp://some.host.net/pub/somefile.gz | php 
gzfilething.php > gzoutput.txt

and gzopen("php://stdin") to process the text, and it does 
work fine, but it's a bit awkward to use and is 
inconsistent with fopen()'s behavior.

Note that the fopen with "zlib:" URL's doesn't work for 
remote files, either (how would you write such a thing?  
fopen("zlib:ftp://some.host.net/pub/somefile.gz","r";)?  I
tried several variations and confirmed that zlib: 
automatically assumes a local filehandle.

Thanks!





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

#20665 [Fbk->Opn]: Memory leaks and allocation problems

[msopacua]

 ID:   20665
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Apache related
 Operating System: BSD/OS 4.2
 PHP Version:  4.3.0RC1
 New Comment:

Yes, it does put out the scriptname, with the mem leaks -it's always
the same script, which is nothing more than a static file which echo's
the current timestamp into 8 different places for banners - that's why
it doesn't make sence.

However - when an emalloc call fails, it doesn't output the scriptname
nor the c file, which called the emalloc.

It only happens a few times a day, so the cause could be the memory
leaks or it could be a script which isn't requested too much.

I see a SIGSEV afterwards, but no core dump and it's not like I can
startup Apache from gdb and request a certain file to reproduce it,
since I have no idea where to look.

I will recheck settings to make it dump core.

What's also strange is that these leaks only get reported on a SIGHUP.
Through the entire error log, there are no other leak reports. This
would suggest something in the SIGCHILD and therefore the shutdown
handler.


Previous Comments:


[2002-11-27 17:03:22] [EMAIL PROTECTED]

The code that reports memory leaks also outputs PHP script name where
the leak had occured. I am not sure if this was part of the RC1, so
just to be sure, try RC2 and make sure to clear the error log so that
old messages do not get confused for new ones.



[2002-11-27 03:05:26] [EMAIL PROTECTED]

Yep apache.



[2002-11-26 20:19:13] [EMAIL PROTECTED]

Was this with Apache? Please reclassify if so.
This is NOT "Performance problem"..




[2002-11-26 19:47:48] [EMAIL PROTECTED]

Running 4.3RC1 in production, I see a returning problem, for the
allocation of 129 bytes. Since no executed file is being reported it's
hard for me to track down which is the cause.

Additionally, on logrotation and a SIGHUP, there are leaks being
reported, broken down to:
/home/mdev/_src/php-4.3.0RC1/Zend/zend_opcode.c(295) :  Freeing
0x082F6024 (7200 bytes)

Zend/zend_language_scanner.c(4365) :  Freeing 0x082E2824 (50 bytes)
Last leak repeated 112 times

Zend/zend_language_scanner.c(4450) :  Freeing 0x082DFAE4 (4 bytes)Last
leak repeated 2 times
/home/mdev/_src/php-4.3.0RC1/Zend/zend_hash.c(262) :  Freeing
0x082DE324 (100 bytes)
Last leak repeated 76 times

Zend/zend_language_scanner.c(3060) :  Freeing 0x082E01A4 (84 bytes)
/home/mdev/_src/php-4.3.0RC1/Zend/zend_execute.c(478) :  Freeing
0x082DF7A4 (12 bytes)
/home/mdev/_src/php-4.3.0RC1/Zend/zend_hash.c(406) :  Freeing
0x082E2124 (35 bytes)
etc.

Full log here:
http://melvyn.idg.nl/php43/leaks.log

I stripped the script= part as it doesn't make any sence.

Note that this is the only point where these leaks are reported.




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

#20698 [Fbk->Opn]: preg_match_all causes php to fail with "unknow software exception"

[thingol]

 ID:   20698
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: PCRE related
 Operating System: Win32
 PHP Version:  4.2.3
 New Comment:

Nothing new.

Bug is repeated.


Previous Comments:


[2002-11-28 06:29:17] [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-11-28 06:26:10] [EMAIL PROTECTED]

If the text for preg_match_all is bigger than some value, many regexp
constructions causes php to terminate.

This code crashes php (on win32 only):






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

#14366 [Csd]: exit signal Floating point exception (8)

[sander]

 ID:   14366
 Updated by:   [EMAIL PROTECTED]
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.4-RELEASE #0
 PHP Version:  4.0.6
 New Comment:

Changing e-mail address on user request to avoid spam.


Previous Comments:


[2001-12-06 19:22:54] [EMAIL PROTECTED]

Can not reproduce in FreeBSD 4.4 with PHP 4.1.0RC5. 

Try it from: http://download.php.net/~zeev/php-4.1.0RC5.tar.gz
and reopen this bug report if this doesn't work with that version
either.
(4.1.0 should be released very soon)




[2001-12-06 16:37:33] [EMAIL PROTECTED]

Please help! We get this weird error on ANY php page that uses
decimals. 

The simpliest code we found to produce the error is:

echo (0.1);

That's it. Apache just dies 90% of the time if you call the page, with
a 404 error. If you refresh, the page comes up, but the log still shows
the following errors:

/var/log/messages:
Dec  6 16:07:17 julian /kernel: pid 38937 (httpd), uid 65534: exited on
signal 8

Apache error log:
[Thu Dec  6 16:07:17 2001] [notice] child pid 38937 exit signal
Floating point exception (8)

There is no error if the # has no decimals, or it is .0 
I.E.:
0.0 or 4.0 or 345.0 no error
0.3 or 5.3 or 345.24 gives error
Any calculation using or generating the above give error.

System:
 './configure' '--with-mysql=/usr/local/mysql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-imap=../imap'
'--with-gettext'

Using stock php.ini except magic_quotes_gpc = Off

This error came since we upgraded to FreeBSD from Linux and the latest
PHP Apache MySql combo.

It doesn't matter if we use PHP as a module or compile into Apache. The
bug is annoying, and our users complain a lot.




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

#20479 [Opn->Csd]: handler 'ob_gzhandler' cannot be used twice in Unknown on line 0

[helly]

 ID:   20479
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: Output Control
 Operating System: Linux 2.4.18
 PHP Version:  4.3.0RC1
 New Comment:

This check was added in 4.3.0dev some time ago to prevent
missconfiguration. There simply was no check in earlier versions.


Previous Comments:


[2002-11-18 11:09:08] [EMAIL PROTECTED]

Humm, indeed, output_buffering was set to 4096, now it works.
How this case was handled in php 4.2.3 ?



[2002-11-18 11:01:14] [EMAIL PROTECTED]

You propably have set it in php.ini too?




[2002-11-18 07:31:42] [EMAIL PROTECTED]

Sorry, the complete error message is :

Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler'
cannot be used twice in Unknown on line 0



[2002-11-18 07:30:51] [EMAIL PROTECTED]

Hi,

When using :

ob_start("ob_gzhandler") in my code, I obtain the following error :

handler 'ob_gzhandler' cannot be used twice in Unknown on line 0

No problem so far with PHP 4.2.3

Regards,
  Jocelyn




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

#14366 [Csd]: exit signal Floating point exception (8)

[sander]

 ID:   14366
 Updated by:   [EMAIL PROTECTED]
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.4-RELEASE #0
 PHP Version:  4.0.6
 New Comment:

Another try... doesn't seem to work...


Previous Comments:


[2002-11-28 06:39:55] [EMAIL PROTECTED]

Changing e-mail address on user request to avoid spam.



[2001-12-06 19:22:54] [EMAIL PROTECTED]

Can not reproduce in FreeBSD 4.4 with PHP 4.1.0RC5. 

Try it from: http://download.php.net/~zeev/php-4.1.0RC5.tar.gz
and reopen this bug report if this doesn't work with that version
either.
(4.1.0 should be released very soon)




[2001-12-06 16:37:33] [EMAIL PROTECTED]

Please help! We get this weird error on ANY php page that uses
decimals. 

The simpliest code we found to produce the error is:

echo (0.1);

That's it. Apache just dies 90% of the time if you call the page, with
a 404 error. If you refresh, the page comes up, but the log still shows
the following errors:

/var/log/messages:
Dec  6 16:07:17 julian /kernel: pid 38937 (httpd), uid 65534: exited on
signal 8

Apache error log:
[Thu Dec  6 16:07:17 2001] [notice] child pid 38937 exit signal
Floating point exception (8)

There is no error if the # has no decimals, or it is .0 
I.E.:
0.0 or 4.0 or 345.0 no error
0.3 or 5.3 or 345.24 gives error
Any calculation using or generating the above give error.

System:
 './configure' '--with-mysql=/usr/local/mysql'
'--with-apxs=/usr/local/apache/bin/apxs' '--with-imap=../imap'
'--with-gettext'

Using stock php.ini except magic_quotes_gpc = Off

This error came since we upgraded to FreeBSD from Linux and the latest
PHP Apache MySql combo.

It doesn't matter if we use PHP as a module or compile into Apache. The
bug is annoying, and our users complain a lot.




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

#20698 [Opn->Ver]: preg_match_all causes php to fail with "unknow software exception"

[sniper]

 ID:   20698
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: PCRE related
-Operating System: Win32
+Operating System: *
-PHP Version:  4.2.3
+PHP Version:  4.3.0-dev
 New Comment:

It crashes also here (on Linux) so it's not specific to windows.
Backtrace is way too long to put here..



Previous Comments:


[2002-11-28 06:34:47] [EMAIL PROTECTED]

Nothing new.

Bug is repeated.



[2002-11-28 06:29:17] [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-11-28 06:26:10] [EMAIL PROTECTED]

If the text for preg_match_all is bigger than some value, many regexp
constructions causes php to terminate.

This code crashes php (on win32 only):






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

#20675 [Opn->Bgs]: namespace attribute for element stylesheet

[chregu]

 ID:   20675
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: XSLT related
 Operating System: win2k/Linux
 PHP Version:  4.3.0RC1
 New Comment:

Not a PHP Bug.

Either you wrote your xslt-stylesheet in the wrong way (be sure to set
output="xml" otherwise namespaces are discarded) or your xslt-processor
(Sablotron? libxslt?) has a bug

The following works just fine with Sablotron 0.96 and libxslt 1.0.21

http://www.w3.org/1999/XSL/Transform";>


http://www.w3.org/1999/XSL/Transform";>
1.0





Previous Comments:


[2002-11-27 09:13:02] [EMAIL PROTECTED]

When I generate a stylesheet from a xsl transformation (xml+xsl =>
xsl), I am willing to apply the namespace attribute.

in xsl, this writes :
http://www.w3.org/1999/XSL/Transform";>
1.0


but PHP xslt transformer applies the version number all right, and
forgets the namespace attribute.

Thanks !





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

#20698 [Ver]: preg_match_all causes php to fail with "unknow software exception"

[wez]

 ID:   20698
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  4.3.0-dev
 New Comment:

Not really a PHP bug; bug is in the PCRE library itself
and is because you are asking it to capture a very large
number of individual character matches.
Increasing your stack size might help (ulimit).



Previous Comments:


[2002-11-28 06:55:54] [EMAIL PROTECTED]

It crashes also here (on Linux) so it's not specific to windows.
Backtrace is way too long to put here..




[2002-11-28 06:34:47] [EMAIL PROTECTED]

Nothing new.

Bug is repeated.



[2002-11-28 06:29:17] [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-11-28 06:26:10] [EMAIL PROTECTED]

If the text for preg_match_all is bigger than some value, many regexp
constructions causes php to terminate.

This code crashes php (on win32 only):






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

#15702 [Opn->Fbk]: Segmentation fault (using jdk1.4 with php 4.2.3)

[chregu]

 ID:   15702
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Java related
 Operating System: Red Hat Linux 7.1
 PHP Version:  4.2.3
 New Comment:

first. you have to make a symlink from to
libphp_java.so not php_java.so...

second. sablotron < 0.97 and jdk >= 1.3 does not work together.
Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't
find a link to download it), which should solve the problem..

chregu


Previous Comments:


[2002-11-11 09:41:56] [EMAIL PROTECTED]

As you suggested above changing the extension=php_java.so without
creating a symbolic link doesn't even load the extension.

So I tried it by creating a symbolic link to
/wwwroot/php/lib/php/extensions/no-debug-zts-20020429/java.so as
/wwwroot/php/lib/php/extensions/no-debug-zts-20020429/php_java.so and
used the following setting in php.ini:

[Java]
extension_dir = /wwwroot/php/lib/php/extensions/no-debug-zts-20020429
java.class.path = /wwwroot/php/lib/php/php_java.jar
extension=php_java.so
;java.home = /usr/java/j2sdk1.4.0
;java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/client/libjvm.so
;java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/libjava.so
java.library.path =
/wwwroot/php/lib/php/extensions/no-debug-zts-20020429


PHP loaded the java extension but it still displayed:

Fatal error: java.lang.UnsatisfiedLinkError: no php_java in
java.library.path in /wwwroot/htdocs/jver.php on line 4

I don't know what it isn't able to find php_java.jar or php_java.so?
PHP is able to find java.so thats why it loads the extension.

I also want to know what is the purpose of java.library.path? What
should be specified here?

Does it work for you or others who use Sun jdk 1.4?

If yes then please try to update the README file in ext/java directory
with settings which use Jdk 1.3 or 1.4 and which work on your own
systems? Because not many these days use jdk 1.2.2.

I must mention that java extension on windows works without any problem
even when using jdk1.4.



[2002-11-05 19:09:17] [EMAIL PROTECTED]

I believe the current answer to this is to make a link to the library
like so:

$extensiondir$/java.so to $extensiondir$/libphp_java.so

You can find more about this in Bug #19327

Does this solve the problem?  I know it's a hack at the moment, but the
other bug details some of the issues with possible solutions.



[2002-11-05 18:24:13] [EMAIL PROTECTED]

Just wanted to change email so that I recevie the notification whenever
this page is updated.



[2002-11-02 17:42:26] [EMAIL PROTECTED]

I used php 4.2.3 this time with apache 2.0.43

Apache
--
./configure --prefix=/wwwroot --enable-so

php

/configure --prefix=/wwwroot/php --with-apxs2=/wwwroot/bin/apxs
--with-java --with-mysql --with-config-file-path=/wwwroot/php

export
LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client


php.ini Setting
---
[Java]

java.class.path = /wwwroot/php/lib/php/php_java.jar
extension=java.so
java.home = /usr/java/j2sdk1.4.0
java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/libjava.so
;java.library = /usr/java/j2sdk1.4.0/jre/lib/i386/client/libjvm.so
;java.library.path = /usr/java/j2sdk1.4.0/jre/lib/i386/client


Apache Start

$ export
LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client

$ /wwwroot/bin/apachectl start


Fatal error: java.lang.UnsatisfiedLinkError: no php_java in
java.library.path in /wwwroot/htdocs/jver.php on line 4

Then I changed java setting in php.ini like this:

[Java]
java.class.path = /wwwroot/php/lib/php/php_java.jar
extension=java.so
java.library.path = /wwwroot/php/lib/php


But same error was displayed.

Fatal error: java.lang.UnsatisfiedLinkError: no php_java in
java.library.path in /wwwroot/htdocs/jver.php on line 4

I also want to know what has to be specified in java.library.path?
In php.ini I also tried to use
java.library.path=/usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/lib/i386/client


But it was unable to find other java libraries and this error was
displayed:

Fatal error: Unable to load Java Library
/usr/java/j2sdk1.4.0/./jre/lib/i386/libjava.so, error: libverify.so:
cannot load shared object file: No such file or
directory in /wwwroot/htdocs/jver.php on line 4

So I had to mannual export LD_LIBRARY_PATH as above and then it
displayed the
unsatisfied link error.



[2002-10-31 01:00:04] [EMAIL PROTECTED]

No feedback was provided for this bu

#20270 [Opn->Fbk]: Apache processes don't clean up

[chregu]

 ID:   20270
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Java related
 Operating System: RHL7.3
 PHP Version:  4.3.0-pre2
 New Comment:

Do you have xslt support enabled, then

sablotron < 0.97 and jdk >= 1.3 does not work together.
Sablotron 0.97 is not out yet, but there is an RC1 in their CVS (didn't
find a link to download it), which should solve the problem..

chregu






Previous Comments:


[2002-11-22 13:11:07] [EMAIL PROTECTED]

I get the same result using:

Linux 2.4.19
glibc 2.3.1
pthread 0.10
php 4.3.0RC1
apache 1.3.27
Sun's j2sdk1.4.0_03



[2002-11-14 08:57:14] [EMAIL PROTECTED]

There seems to be a problem with the way threads are handled between
php and java that keeps the apache child process from cleaning up after
itself.  If MaxRequestsPerChild is set to anything other than 1, a
number of threads are started by a httpd child and are never reused. 
It also appears that the httpd child process that spawns these threads
can not be reused by apache and the httpd controlling process never
starts another child process to take the place of the disabled one.

My testing setup is:
Linux 2.4.18
glibc 2.2.5
apache 1.3.27
libpthread 0.9
php 4.2.3

Blackdown JDK 1.3.1, IBM JDK 1.3..1, Blackdown JDK 1.4.1b2 all produce
the same results.

It should be noted that apache is stable if MaxRequestsPerChild is set
to 1, but there's quite a performance hit involved.



[2002-11-05 18:20:09] [EMAIL PROTECTED]

I have tried to use the Java extension with JDK1.4.1 and PHP 4.2.3 and
4.3.0-pre2.

Each time a page with embedded Java runs, the Apache (1.3.27) spawns
MaxSpareServers processes, which never seem to get cleaned up.

The tests I conducted with 4.2.3 ended up crashing after a few runs,
being unable to run the JVM. This version also had trouble reading
php.ini class path settings.

The 4.3.0-pre2 seems to stop spawning processes after reaching about 90
httpds (not sure what this number is related to). The execution time of
the code is much faster after the spawning stops also - probably the
JVMs are loaded for all httpds?

Is there a way to control this process spawning and to get the whole
thing more stable?





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

#20698 [Ver->Bgs]: preg_match_all causes php to fail with "unknow software exception"

[sniper]

 ID:   20698
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Verified
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: *
 PHP Version:  4.3.0-dev
 New Comment:

not php bug -> bogus.



Previous Comments:


[2002-11-28 07:06:26] [EMAIL PROTECTED]

Not really a PHP bug; bug is in the PCRE library itself
and is because you are asking it to capture a very large
number of individual character matches.
Increasing your stack size might help (ulimit).




[2002-11-28 06:55:54] [EMAIL PROTECTED]

It crashes also here (on Linux) so it's not specific to windows.
Backtrace is way too long to put here..




[2002-11-28 06:34:47] [EMAIL PROTECTED]

Nothing new.

Bug is repeated.



[2002-11-28 06:29:17] [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-11-28 06:26:10] [EMAIL PROTECTED]

If the text for preg_match_all is bigger than some value, many regexp
constructions causes php to terminate.

This code crashes php (on win32 only):






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

#20505 [Opn->Ana]: configure --with-java fails

[chregu]

 ID:   20505
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Analyzed
 Bug Type: Java related
 Operating System: Linux
 PHP Version:  4.3.0RC1
 New Comment:

the configure of ext/java is quite old and was only tested for suns jdk
stuff recently (well, they didn't change their paths )

I would recommend using the sun jdk. Or someone fixes the configure
line ...

chregu


Previous Comments:


[2002-11-19 16:35:33] [EMAIL PROTECTED]

It seems I was a bit hasty in my testing.  I forgot to rm config.cache
for each of the runs.

The only JDK's that fail are IBMJava2-131 and Kaffe 1.0.7.  All of the
Blackdown JDK's work fine (with configure that is).

IBM's JDK puts libjava.so inside of jre/bin as opposed to jre/lib/i386
as Blackdown does.  There should be a test for this in configure, but 
I'm not sure of the best spot.  I was able to build 4.3.0RC1
sucessfully 
by manually adjusting JAVA_LIBPATH.

Kaffe seems to have changed into an entirely different beast in 1.0.6
and 1.0.7.  It looks like several things configure looks for are no 
longer in the same place as they were in older versions of Kaffe as
they are now in .jar files.  I'm unable to test out the older versions

of Kaffe because I can't get them to build on my system.  I'm also 
not experienced enough in Kaffe to try to tweak PHP to build with it.



[2002-11-19 15:14:06] [EMAIL PROTECTED]


./configure --with-java=/usr/local/jdk 

fails with 

checking for Java support... yes
checking Java Jar location... /usr/local/jdk/bin/jar cf
checking Java C location... /usr/local/jdk/bin/javac
checking Checking for libjava... 
configure: error: unable to find Java VM libraries in /usr/local/jdk

Same result for /usr/local/jdk equal to:

IBMJava2-131 (IBM's Java2 JDK)
j2sdk1.3.1 (Blackdown 1.3.1 JDK)
j2sdk1.4.1 (Blackdown 1.4.1 JDK)
jdk1.2.2 (Blackdown 1.2.2 JDK)
kaffe_1.0.7 (Kaffe 1.0.7)






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

#18600 [Opn->Fbk]: Unable to create Java Virtual Machine

[chregu]

 ID:   18600
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Java related
 Operating System: Windows 2000
 PHP Version:  4.2.3
 New Comment:

Hi

I'm asking it again:

Is anyone using sablotron (ext/xslt) together with the java extension,
then you're in bad luck, because:

sablotron < 0.97 and jdk >= 1.3 does not work together.
Sablotron 0.97 is not out yet, but there is an RC1 in their CVS
(didn't
find a link to download it), which should solve the problem..


try not loading the sablotron extension and see if it solves the
problem

unix people which have problem with even starting up, should try the
symlink trick:

make a symlink from java.so to libphp_java.so and see if that works.

chregu




Previous Comments:


[2002-11-05 05:43:54] [EMAIL PROTECTED]

I am also seeing this bug, unfortunatly I'm running apache 1.x on
Solaris 8.

Works fine for a little while, then stops working after a number of
requests. I can stop the symtoms by turning off keep-alive in apache or
by reducing the requests per child to a very low number. Of course,
none of these solutions are acceptable. I am trying to test 4.3.0pre2
just now but having compilation errors. More later.



[2002-10-31 08:51:16] [EMAIL PROTECTED]

Yeah the only real issue I can see here is that this is a Windows
specific issue.  I've looked through the the DSP file, and read up on
specific linking issues in Windows... everything looks right from the
end of PHP.  

I'm guessing this can be one of (or possibly all of) these things:

A) specific to a JVM version - in which case we'd need to find out
which one works, and then update the specific hooks into PHP to use the
newer versions.
B) Windows not liking Java at all - not much we can do about that.
C) specific to PHP alone - in which case someone with more Windows dev
experience will have to take a look at this.  As I don't see any real
issue with the way we're linking and calling things (beyond the really
resource intensive comments).





[2002-10-31 07:44:50] [EMAIL PROTECTED]

I found this problem using Apache 1.x on Win2k.
PHP 4.2.3 causes the JVM create failure (although I couldn't get any
access violations).

Under IIS4 , the access violation causes some serious problems, albeit
intermittently. I found that starting small with Java-inclusive scripts
allowed some java work to be done (such as retrieving JVM versions,
etc).

However, when I started some more serious Java work with some custom
classes I got both the JVM create failure and an access violation which
crashed IIS. A reboot was necessary to bring IIS back up (Win2k
wouldn't even let me force kill the process!!).

I took a look at the latest snapshot posted below, but this caused an
immediate crash in Apache upon starting the service. 

Any other suggestions?



[2002-09-27 12:00:04] [EMAIL PROTECTED]

just to add to the list of symptoms.

First time I run a script, I get 
Warning: Unknown list entry type in request shutdown (0) in Unknown on
line 0

when the script is ending. The next time I try to load the same script,
I get 

Fatal error: Unable to create Java Virtual Machine in
c:\web\qvc\reports\test.php on line 2

win2k, j2sdk1.4, php 4.2.3.
Does that help?



[2002-09-25 05:02:59] [EMAIL PROTECTED]

FYI have tried it now on another system under Apache 2 / Windows NT 4.

Exactly the same problem: runs for a limited time period then reports
"Unable to load virtual machine".

Made sure Sablotron is not running also.



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

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

#19562 [Opn->Csd]: xml_parse_into_struct does not follow XML 1.0 specs w.r.t. default attributes

[chregu]

 ID:   19562
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: XML related
 Operating System: Solaris 2.8
 PHP Version:  4.2.3
 New Comment:

xml_parse_into_struct uses expat as xml-parser and expat is a
non-validating parser which does not care about DTDs (AFAIK)

chregu


Previous Comments:


[2002-09-23 13:21:52] [EMAIL PROTECTED]

XML 1.0 specs say that default attribute values will be parsed as if
those attributes were directly specified:

>From the XML 1.0 Spec
(http://www.w3.org/TR/2000/REC-xml-20001006#attdecls)

"[Definition: If the declaration is neither #REQUIRED nor #IMPLIED,
then the AttValue value contains the declared default value; the #FIXED
keyword states that the attribute must always have the default value.
If a default value is declared, when an XML processor encounters an
omitted attribute, it is to behave as though the attribute were present
with the declared default value.]"

I have the following DTD:




and the following XML:


...


The xml_parse_into_struct function does NOT place the attribute
"att=20" into the struct.  Furthermore, if I change the XML to read:


...


xml_parse_into_struct WILL place the attribute "att=45" into the struct
(so non-default attributes DO work), but in actuality, this should
fail, because the #FIXED keyword specifies that the value cannot be
changed.

-MM




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

#20694 [Opn->Fbk]: html not properly going to browser

[iliaa]

 ID:   20694
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows 2000 Server
 PHP Version:  4.3.0RC2
 New Comment:

Which SAPI are you using, cgi os isapi?


Previous Comments:


[2002-11-28 04:14:13] [EMAIL PROTECTED]

Just installed 4.3.0RC2 zip binary on windows 2000 server 
and iis 5.0 to check it out on my server.
normally use 4.2.3 and seem to be able to swap out installs 
as needed by putting files in and out of my php directory.

4.3.0RC2 seems to not like pages that work fine in 4.2.3. 
Some Pages using the new release display as raw text 
instead of html in some cases. When i look at source in a 
browser the beginning lines are missing although they are 
included. It seems no php is missed as all work i assign is 
completed as expected, just the html sent after the fact 
has missing lines at the top. I would expect it to die as 
it moves through the script, instead it is as if all works 
correctly but at the last moment only sends partial ending 
text to the browser.


As an example, changing the order only of an index page has 
the following results. (The includes here are very simple 
containing mainly html) 

The following works fine but the first line that shows up 
is the 4th with title tags, not :-->





 



HTML content here

While this is much worse and the first tag that shows up is 
 tags that are in classes.php followed by the <
SCRIPT> tag. It skips the title tag.--->





 



HTML content here


Changing php.ini does not help, adjusted it for over 2 
hours to see if a setting affected this. (expose_php and 
various error directives, using the two provided ini files, 
and many random changes) Of course all extensions were 
disabled. Different pages are affected differently.

My gut feeling is that php parses my script and assembles a 
completed html page. At this point something happens that 
deletes the top x lines (it never does half a line) and 
sends the rest to the browser. If enough header shows up i 
get a web page, usually with text at the top of exposed 
javascripts, sometimes i get text.

testing with pages that are simple text or simple html had 
the entire page show up just fine. The requires i used seem 
to be part of the issue as above. I tried looking at the 
index page from phpmyadmin but it would not even load due 
to not being able to find include files.

Switching back to php 4.2.3 fixes all above problems and 
pages again display the doctype and the html head tags. I 
hope someone can make sense of this, or that it is in fact 
a bogus/support issue.

I probably would not have submitted it, except that it is 
the preview release and that my other version works 
splendidly.





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

#20699 [NEW]: Comparison between 0 and string returns TRUE

[cornecNOSPAM]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.2.3
PHP Bug Type: *Compile Issues
Bug description:  Comparison between 0 and string returns TRUE

PHP Evaluates the following as TRUE, is this right ?

if (0 == "Whacked")
   print "Whacked";
else
   print "Sane";


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

#20699 [Opn->Bgs]: Comparison between 0 and string returns TRUE

[sander]

 ID:   20699
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: *Compile Issues
 Operating System: Linux
 PHP Version:  4.2.3
 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-11-28 07:39:34] [EMAIL PROTECTED]

PHP Evaluates the following as TRUE, is this right ?

if (0 == "Whacked")
   print "Whacked";
else
   print "Sane";






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

#20482 [Fbk]: Segmentation fault in zend_execute_API.c

[chregu]

 ID:   20482
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: DOM XML related
 Operating System: RedHat 7.2 kernel 2.4.9-13
 PHP Version:  4.4.0-dev
 New Comment:

Could you please provide the shortest possible example, which
segfaults. I'm willing to investigate into it and hopefully provide a
solution for 4.3, but this will be released soon, so you have to hurry
up :)

chregu


Previous Comments:


[2002-11-18 11:08:00] [EMAIL PROTECTED]

And also a short example script which can be used to reproduce this
would be nice to have here.. :)




[2002-11-18 11:07:13] [EMAIL PROTECTED]

Reclassified as DOM XML bug as the segfault seems to be caused by it.

Please provide a backtrace with the CVS snapshot too.




[2002-11-18 11:01:09] [EMAIL PROTECTED]

I just tried the "latest" snapshot (20021118) but it didn't
help. Still segmentation fault =-(
-- 
Björn Smith <[EMAIL PROTECTED]>



[2002-11-18 09:58:13] [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-11-18 09:55:51] [EMAIL PROTECTED]

PHP 4.2.3 built with
libxml2-2.4.26
Sablot-0.96

During certain XML/XSLT transforms I get the following stack dump:

#0  0x401d4588 in chunk_free (ar_ptr=0x40288300, p=0x846dd10) at
malloc.c:3252
#1  0x401d43f4 in __libc_free (mem=0x846dd70) at malloc.c:3154
#2  0x4033ec68 in _efree (ptr=0x846dd7c) at zend_alloc.c:246
#3  0x4035a1f1 in zend_hash_destroy (ht=0x846dbac) at zend_hash.c:546
#4  0x40354c67 in _zval_dtor (zvalue=0x846db8c) at zend_variables.c:60
#5  0x4034d691 in _zval_ptr_dtor (zval_ptr=0xbfffea50)
at zend_execute_API.c:274
#6  0x40373d0b in php_free_xml_node (rsrc=0x846dd04) at
php_domxml.c:505
#7  0x4035b53d in list_entry_destructor (ptr=0x846dd04) at
zend_list.c:177
#8  0x4035a338 in zend_hash_apply_deleter (ht=0x404ec15c, p=0x846dccc)
at zend_hash.c:596
#9  0x4035a48a in zend_hash_graceful_reverse_destroy (ht=0x404ec15c)
at zend_hash.c:662
#10 0x4035b68c in zend_destroy_rsrc_list (ht=0x404ec15c) at
zend_list.c:233
#11 0x4034d4b6 in shutdown_executor () at zend_execute_API.c:196
#12 0x40355bca in zend_deactivate () at zend.c:598
#13 0x403620e3 in php_request_shutdown (dummy=0x0) at main.c:789
#14 0x4035f1cc in apache_php_module_main (r=0x80fe78c,
display_source_mode=0)
at sapi_apache.c:96
#15 0x4035fc4e in send_php (r=0x80fe78c, display_source_mode=0,
filename=0x0)
at mod_php4.c:575
#16 0x4035fca2 in send_parsed_php (r=0x80fe78c) at mod_php4.c:590
#17 0x08053dd3 in ap_invoke_handler ()
#18 0x08068d57 in process_request_internal ()
#19 0x08068db8 in ap_process_request ()
#20 0x0805fbf5 in child_main ()
#21 0x0805fda0 in make_child ()
#22 0x0805ff14 in startup_children ()
#23 0x0806058c in standalone_main ()
#24 0x08060def in main ()
#25 0x4016f657 in __libc_start_main (main=0x8060a48 , argc=2,
ubp_av=0xb8e4, init=0x804e34c <_init>, fini=0x807e760 <_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb8dc)
at ../sysdeps/generic/libc-start.c:129
(gdb)

-- 
Björn Smith <[EMAIL PROTECTED]>




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

#20487 [Fbk->Csd]: mod_php crashes under Apache 1.3.27 & MaxRequestsPerChild=infinite

[dmitry]

 ID:   20487
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Windows 2000
 PHP Version:  4.3.0RC1
 New Comment:

RC2 seems to be OK. Thanks.


Previous Comments:


[2002-11-28 05:05:16] [EMAIL PROTECTED]

Please test with RC2. Or preferrably with the latest STABLE snapshot
from http://snaps.php.net





[2002-11-27 15:07:59] [EMAIL PROTECTED]

I think we can move this Report to "closed" because it seems to be
fixed in RC2 (-> I haven't tried under heavy load)

I've tried with 2,4 and even 100 Frames ;-)
Apache and Apache2 didn't crash.

mfg DMIII



[2002-11-22 18:09:32] [EMAIL PROTECTED]

i've experienced this same bug with 4.3.0RC1 (Apache 2.0.43 on Windows
XP Pro (Service Pack 1)... In my experience it seems to recurr
randomly, but the logic presented here, does hold true. I've also
witnessed similar crashes with 4.2.4-dev, but 4.3 does it far more
frequently.. Presumably as long as two requests are going on at the
same time.. it doesn't have to be from the same origin..



[2002-11-21 09:24:59] [EMAIL PROTECTED]

There is the same Problem with Apache2 (2.0.43) and PHP 4.3.0RC1!!



[2002-11-21 06:14:17] [EMAIL PROTECTED]

The more frames you load the earlier the bug occours!

I've tried with 4 frames -> 2xReload and it crashes!



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

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

#20665 [Opn->Fbk]: Memory leaks and allocation problems

[iliaa]

 ID:   20665
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Apache related
 Operating System: BSD/OS 4.2
 PHP Version:  4.3.0RC1
 New Comment:

As a security procution Apache does not write core files, in order to
make it do so you must tell it where to write core files using:
CoreDumpDirectory /tmp.
In debug builds Zend will segfault if emalloc() fails to allocate
memory.
Also, could you please include the list of extensions you've compiled
your PHP with (put config.nice online somewhere?).


Previous Comments:


[2002-11-28 06:34:38] [EMAIL PROTECTED]

Yes, it does put out the scriptname, with the mem leaks -it's always
the same script, which is nothing more than a static file which echo's
the current timestamp into 8 different places for banners - that's why
it doesn't make sence.

However - when an emalloc call fails, it doesn't output the scriptname
nor the c file, which called the emalloc.

It only happens a few times a day, so the cause could be the memory
leaks or it could be a script which isn't requested too much.

I see a SIGSEV afterwards, but no core dump and it's not like I can
startup Apache from gdb and request a certain file to reproduce it,
since I have no idea where to look.

I will recheck settings to make it dump core.

What's also strange is that these leaks only get reported on a SIGHUP.
Through the entire error log, there are no other leak reports. This
would suggest something in the SIGCHILD and therefore the shutdown
handler.



[2002-11-27 17:03:22] [EMAIL PROTECTED]

The code that reports memory leaks also outputs PHP script name where
the leak had occured. I am not sure if this was part of the RC1, so
just to be sure, try RC2 and make sure to clear the error log so that
old messages do not get confused for new ones.



[2002-11-27 03:05:26] [EMAIL PROTECTED]

Yep apache.



[2002-11-26 20:19:13] [EMAIL PROTECTED]

Was this with Apache? Please reclassify if so.
This is NOT "Performance problem"..




[2002-11-26 19:47:48] [EMAIL PROTECTED]

Running 4.3RC1 in production, I see a returning problem, for the
allocation of 129 bytes. Since no executed file is being reported it's
hard for me to track down which is the cause.

Additionally, on logrotation and a SIGHUP, there are leaks being
reported, broken down to:
/home/mdev/_src/php-4.3.0RC1/Zend/zend_opcode.c(295) :  Freeing
0x082F6024 (7200 bytes)

Zend/zend_language_scanner.c(4365) :  Freeing 0x082E2824 (50 bytes)
Last leak repeated 112 times

Zend/zend_language_scanner.c(4450) :  Freeing 0x082DFAE4 (4 bytes)Last
leak repeated 2 times
/home/mdev/_src/php-4.3.0RC1/Zend/zend_hash.c(262) :  Freeing
0x082DE324 (100 bytes)
Last leak repeated 76 times

Zend/zend_language_scanner.c(3060) :  Freeing 0x082E01A4 (84 bytes)
/home/mdev/_src/php-4.3.0RC1/Zend/zend_execute.c(478) :  Freeing
0x082DF7A4 (12 bytes)
/home/mdev/_src/php-4.3.0RC1/Zend/zend_hash.c(406) :  Freeing
0x082E2124 (35 bytes)
etc.

Full log here:
http://melvyn.idg.nl/php43/leaks.log

I stripped the script= part as it doesn't make any sence.

Note that this is the only point where these leaks are reported.




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

#20686 [Bgs]: problems with the session.save_path variable

[pretorian_g]

 ID:   20686
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Session related
 Operating System: Windows XP
 PHP Version:  4.2.3
 New Comment:

It's working now... It was a php.ini location problem. According to
install.txt file php.ini should be placed in the c:\windows\system32
directory but that wasn't working and when I placed php.ini in
c:\windows directory it began to work.

So now I can use session on my win32 system :-)

However you could change that information in install.txt that comes
with the php distribution (zip file).

Best regards
Darren


Previous Comments:


[2002-11-28 05:57:26] [EMAIL PROTECTED]

Maybe not... But it's a PHP Manual who told me to change that variable
in php.ini if I wanted to run sessions on win32 system. And when I
change it, as manual says, it isn't working... I'm not asking for help
on using start_session() command. I just wonder why things aren't
working as they should according to the PHP manual.

Thanks anyway for your response :-) I will try to ask my question on
some of the php forum.

Regards
Darren



[2002-11-28 05:06:45] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.



[2002-11-27 16:57:22] [EMAIL PROTECTED]

Forget to tell you that I'm running php in module mode...



[2002-11-27 16:41:31] [EMAIL PROTECTED]

Hi folks,

I really don't know if this is a bug but I have a problem that I can't
solve on my own. I'm running windows xp with the apache2 webserver and
php 4.2.3. 

Today I tried to use start_session() command but got some uggly message
that /tmp directory can't be found. Now problem here is that I have
changed session.save_path variable in php.ini from /tmp to the
c:\windows\temp\phptemp and offcourse restarted appache after that.

Now I hope that some can help me with this one.

Thanks
Darren




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

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

[graved]

 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:

@ [EMAIL PROTECTED]:
have you set the default page to index.php?
or try http://localhost/phpmyadmin/index.php


Previous Comments:


[2002-11-28 02:16:13] [EMAIL PROTECTED]

please help me because this is my 4th week
i have pws on my computer and i have installed the mysql and then i
have installed the phpmyadin(sharing the folder and give him alias name
phpmyadmin) and correct its config file(user id-password)to match the
mysql then when i open the php myadmin from the browser at
url:http://localhost/phpmyadmin   i recive this message:
no outhentication to view this page 
i do not know where is the problem so please help me 
thank you in advance



[2002-11-27 09:02:00] [EMAIL PROTECTED]

please this bug is not a php bug 
is a bull shit bug of phpmyadmin
this application is a nightmare totaly unsecure and uggly

i'm writing a kernel mysql admin in php with classes (sic)
and api in the same time in java

i think i'll be ready in two months.

i haven't any problems with this version of php
and all my hold big applications doesn't bug and run 
correctly

so i say php bug or phpmyadmin bug ?



[2002-11-26 14:37:55] [EMAIL PROTECTED]

Does this problem exist in the PHP 4.2.3 Win 32 download binary?



[2002-11-24 16:55:57] [EMAIL PROTECTED]

Maybe stupid hint... for people who are having problems with
phpMyAdmin. Did you checked php.ini for directive magic_quotes_gpc? It
_MUST_ be set to Off, this directive can not be overwritten in PHP code
(as mentioned in PHP documentation). If you can not turn it off for
whole webserver in php.ini, use .htaccess and put "php_flag
magic_quotes_gpc off" in (without quotes :).



[2002-11-22 13:21:27] [EMAIL PROTECTED]

I forgot to mention --disable-mbstring.
If you can make your build from the source, still want to use 4.2.3,
please specify --disable-mbstring in configure params, and the problem
would be gone. However the case you cannot make use of mysql from
within your php scripts is not directly relevant to this bug. Anyway
all that I can say is this bug was really fixed...




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

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

#19191 [Com]: file() doesn't work

[pfister]

 ID:   19191
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   No Feedback
 Bug Type: Filesystem function related
 Operating System: Win2000
 PHP Version:  4.1.2
 New Comment:

Good afternoon,

i've got the same problem, but it appeared for the first time this
afternoon. The time before it worked perfectly. I haven't changed the
configuration or anything else. What can i do, the URL i tried to open
exists.

Please reply

Greetings from Germany

Philipp Pfister


Previous Comments:


[2002-09-23 08:00:44] [EMAIL PROTECTED]

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.





[2002-08-30 04:08:16] [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

This is most likely fixed...



[2002-08-30 04:07:20] [EMAIL PROTECTED]

Hi,

I used file() function at the moment, and i realized that, file()
tries to connect and open the , and than reads it .
But these warning came out
"Warning: php_hostconnect: connect ".

And I have tried direct the  is ok.
I think file() can't  connect to all urladdress, just some of it.




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

#20482 [Fbk->Opn]: Segmentation fault in zend_execute_API.c

[smith]

 ID:   20482
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: DOM XML related
 Operating System: RedHat 7.2 kernel 2.4.9-13
 PHP Version:  4.4.0-dev
 New Comment:

tor 2002-11-28 klockan 15.00 skrev PHP Bug Database:

> Could you please provide the shortest possible example, which
> segfaults. I'm willing to investigate into it and hopefully provide
a
> solution for 4.3, but this will be released soon, so you have to
hurry
> up :)

The problem was not related to PHP. I found out the real reason for
this
segfault. My PHP module was built with unixODBC 2.2.3 and Freetds
(snapshot 20021118).
There are some ODBC driver function call related to cursors made
within
unixODBC. It appears that these functions (badly or not implemented)
in
Freetds messes up the dynamic memory areas.

What I did was to comment out some odbc option calls in the unixODBC
code and the problem was solved. This is not the proper way to solve
the
problem but it helped me for now. I suppose I shold pass this case
over
to the unixODBC/Freetds people or...?


Previous Comments:


[2002-11-28 08:00:52] [EMAIL PROTECTED]

Could you please provide the shortest possible example, which
segfaults. I'm willing to investigate into it and hopefully provide a
solution for 4.3, but this will be released soon, so you have to hurry
up :)

chregu



[2002-11-18 11:08:00] [EMAIL PROTECTED]

And also a short example script which can be used to reproduce this
would be nice to have here.. :)




[2002-11-18 11:07:13] [EMAIL PROTECTED]

Reclassified as DOM XML bug as the segfault seems to be caused by it.

Please provide a backtrace with the CVS snapshot too.




[2002-11-18 11:01:09] [EMAIL PROTECTED]

I just tried the "latest" snapshot (20021118) but it didn't
help. Still segmentation fault =-(
-- 
Björn Smith <[EMAIL PROTECTED]>



[2002-11-18 09:58:13] [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/20482

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

#20631 [Opn->Ver]: PCRE_CASELESS doesn't work

[iliaa]

 ID:   20631
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: PCRE related
 Operating System: Linux 2.4.19
 PHP Version:  4.3.0RC1
 New Comment:

This is indeed a bug, you are correct. The bug is due to us bundling a
pcre library which appears to have a bug, which causes the behaviour
you describe.
As an intermittent solution, you can compile your own pcre library and
compile php with --with-pcre-regex=/path/to/pcre/lib


Previous Comments:


[2002-11-27 19:26:19] [EMAIL PROTECTED]

Forgot to change back to open...



[2002-11-27 19:25:35] [EMAIL PROTECTED]

I respectfully disagree... :)

My code definitely was case-insensitive in 4.2.2 and 4.2.3, and when I
installed 4.3.0RC1 it was case-sensitive.  There's definitely something
fishy going on.

The following page details the setting of internal options by using the
(?) construct.
http://www.php.net/manual/en/pcre.pattern.syntax.php#regexp.reference.internal-options

According to this page, what I'm doing is correct.

I really don't mind changing my function to use perhaps eregi_replace
or something else, but I really think this could be an issue for users
who currently use preg_* functions with case-insensitivity (I'm sure
there would be a few of them...)

Matt



[2002-11-27 00:22:41] [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

Unless you specify the 'i' flag your regular expression will NOT be
case-insensetive. For example the regex you've shown should appear like
this:
'/\(name\)(?i)/i'

If you want it not to be case sensetive.



[2002-11-25 16:50:48] [EMAIL PROTECTED]

preg_replace():

This regex was case insensitive in 4.2.3, but is case sensitive in
4.3.0RC1: '/\(name\)(?i)/'

Was not able to test further because I installed it on a production
box, and had to revert to 4.2.3...

I had the search and replace values in arrays which I then passed to
preg_replace().  This may have some effect on it.  I didn't test just
passing a string.

Matt





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

#20665 [Fbk]: Memory leaks and allocation problems

[msopacua]

 ID:   20665
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: BSD/OS 4.2
 PHP Version:  4.3.0RC1
 New Comment:

CFLAGS='-O0' \
./configure \
--prefix=/phpct \
--with-apache=../apache_1.3.27 \
--enable-cli \
--disable-cgi \
--enable-debug \
--enable-magic-quotes \
--disable-short-tags \
--with-zlib \
--with-zlib-dir=/usr \
--enable-calendar \
--enable-ftp \
--with-mhash=/weblib/local \
--enable-shmop \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm

waiting for a coredump.. :)


Previous Comments:


[2002-11-28 08:17:25] [EMAIL PROTECTED]

As a security procution Apache does not write core files, in order to
make it do so you must tell it where to write core files using:
CoreDumpDirectory /tmp.
In debug builds Zend will segfault if emalloc() fails to allocate
memory.
Also, could you please include the list of extensions you've compiled
your PHP with (put config.nice online somewhere?).



[2002-11-28 06:34:38] [EMAIL PROTECTED]

Yes, it does put out the scriptname, with the mem leaks -it's always
the same script, which is nothing more than a static file which echo's
the current timestamp into 8 different places for banners - that's why
it doesn't make sence.

However - when an emalloc call fails, it doesn't output the scriptname
nor the c file, which called the emalloc.

It only happens a few times a day, so the cause could be the memory
leaks or it could be a script which isn't requested too much.

I see a SIGSEV afterwards, but no core dump and it's not like I can
startup Apache from gdb and request a certain file to reproduce it,
since I have no idea where to look.

I will recheck settings to make it dump core.

What's also strange is that these leaks only get reported on a SIGHUP.
Through the entire error log, there are no other leak reports. This
would suggest something in the SIGCHILD and therefore the shutdown
handler.



[2002-11-27 17:03:22] [EMAIL PROTECTED]

The code that reports memory leaks also outputs PHP script name where
the leak had occured. I am not sure if this was part of the RC1, so
just to be sure, try RC2 and make sure to clear the error log so that
old messages do not get confused for new ones.



[2002-11-27 03:05:26] [EMAIL PROTECTED]

Yep apache.



[2002-11-26 20:19:13] [EMAIL PROTECTED]

Was this with Apache? Please reclassify if so.
This is NOT "Performance 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/20665

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

#20482 [Opn->Bgs]: Segmentation fault in zend_execute_API.c

[iliaa]

 ID:   20482
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: RedHat 7.2 kernel 2.4.9-13
 PHP Version:  4.4.0-dev
 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.

This is definately something for unixODBC/Freetds developers to
address. Since this is not a PHP bug, I am closing the report.


Previous Comments:


[2002-11-28 08:44:35] [EMAIL PROTECTED]

tor 2002-11-28 klockan 15.00 skrev PHP Bug Database:

> Could you please provide the shortest possible example, which
> segfaults. I'm willing to investigate into it and hopefully provide
a
> solution for 4.3, but this will be released soon, so you have to
hurry
> up :)

The problem was not related to PHP. I found out the real reason for
this
segfault. My PHP module was built with unixODBC 2.2.3 and Freetds
(snapshot 20021118).
There are some ODBC driver function call related to cursors made
within
unixODBC. It appears that these functions (badly or not implemented)
in
Freetds messes up the dynamic memory areas.

What I did was to comment out some odbc option calls in the unixODBC
code and the problem was solved. This is not the proper way to solve
the
problem but it helped me for now. I suppose I shold pass this case
over
to the unixODBC/Freetds people or...?



[2002-11-28 08:00:52] [EMAIL PROTECTED]

Could you please provide the shortest possible example, which
segfaults. I'm willing to investigate into it and hopefully provide a
solution for 4.3, but this will be released soon, so you have to hurry
up :)

chregu



[2002-11-18 11:08:00] [EMAIL PROTECTED]

And also a short example script which can be used to reproduce this
would be nice to have here.. :)




[2002-11-18 11:07:13] [EMAIL PROTECTED]

Reclassified as DOM XML bug as the segfault seems to be caused by it.

Please provide a backtrace with the CVS snapshot too.




[2002-11-18 11:01:09] [EMAIL PROTECTED]

I just tried the "latest" snapshot (20021118) but it didn't
help. Still segmentation fault =-(
-- 
Björn Smith <[EMAIL PROTECTED]>



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

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

#20700 [NEW]: Boolean worked, but Integer..?

[admin]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.x
PHP version:  4.2.3
PHP Bug Type: Session related
Bug description:  Boolean worked, but Integer..?

Hey,

I`m using the $_SESSION array at all my session stuff,
Now is the first time at the actual script that i need to store a integer
in the session.

I did this:

$_SESSION[uid] = $result[uid];

echo $result[uid];
echo $_SESSION[uid];

Both returned "18".

Now as I tried to echo the var again, It outputs "8212".

I`ve tried to find any error at my script (maybe an access or change to
the $_SESSION[uid] field...but nothing found).

Maybe this is a bug?

I`m a little bit confused now, because $_SESSION array should be used at
best, and It doesn`t work :-(

BTW, The fieldtype in the mysql db is 'TINYINT'

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

#20700 [Opn]: Boolean worked, but Integer..?

[admin]

 ID:   20700
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Session related
 Operating System: RedHat Linux 7.x
 PHP Version:  4.2.3
 New Comment:

Update: By the way...the entry in the database is "12", not 18, and not
8212...hmm


Previous Comments:


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

Hey,

I`m using the $_SESSION array at all my session stuff,
Now is the first time at the actual script that i need to store a
integer in the session.

I did this:

$_SESSION[uid] = $result[uid];

echo $result[uid];
echo $_SESSION[uid];

Both returned "18".

Now as I tried to echo the var again, It outputs "8212".

I`ve tried to find any error at my script (maybe an access or change to
the $_SESSION[uid] field...but nothing found).

Maybe this is a bug?

I`m a little bit confused now, because $_SESSION array should be used
at best, and It doesn`t work :-(

BTW, The fieldtype in the mysql db is 'TINYINT'

Any idea?




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

#20577 [Opn->Csd]: security vulnerability

[sesser]

 ID:   20577
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Closed
 Bug Type: *General Issues
 Operating System: all
 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.

No feedback via e-mail.


Previous Comments:


[2002-11-22 12:56:17] [EMAIL PROTECTED]

In accordance with iDEFENSE's security vulnerability disclosure policy
(www.idefense.com/disclosure.html), we wanted to bring a security issue
to your attention.  Please acknowledge receipt of this information so
we can work toward a public disclosure date that is convenient to you
in building a fix.

Attackers are able to disclose arbitrary files by exploiting a
vulnerability in the PHP Group's PHP project's handling of file
uploads. This vulnerability is a variation of a vulnerability that was
discovered in early April of 2000 (CVE-2000-0860) that affects all
versions of PHP prior to version 4.0.3. 

Scripts that utilize the legacy method for handling file uploads follow
these steps: When registering a global variable php_mime_split() calls
safe_php_register_variable(). This function in turn runs a check with
is_protected_variable(), and if it's not dealing with a protected
variable will then call php_register_variable().
is_protected_variable() calls zend_hash_exists() on the
rfc1867_protected_variables hash. The php_mime_split() function adds
protected variables to the hash with a call to zend_hash_add(). If a
user tries to register a variable that is protected (such as the
uploaded file's path) the request will be denied since the requested
variable name exists in the rfc1867_protected_variables hash. 

The problem stems from the fact that php_register_variable_ex()
manipulates the variable name before it is stored. Leading spaces are
removed, and spaces and dots are swapped with underscores. Therefore,
if the variable 'file_path' is protected, an attacker can submit '
file_path', thereby bypassing the security checks from the Zend hash
functions. However, php_register_variable_ex() will transform '
file_path' into 'file_path' and register it as a global variable. 

An attacker can utilize this vulnerability to modify the value of the
temporary path of an uploaded file to point to another arbitrary file.
File uploads are generally handled by either copying uploaded temporary
files to another (normally web accessible) directory or by storing them
within a database. In either case, an attacker can cause disclosure of
arbitrary system files.  
Sources: iDEFENSE Labs, Nov. 06, 2002  

Analysis: (iDEFENSE US) Any remote user can exploit this vulnerability
against a script running in an affected server provided that the script
is using the legacy register_globals approach to uploaded file
management as opposed to the new method that stores file info in the
$_FILES array. Successful exploitation of the above-described
vulnerability can result in: 
• Disclosure of PHP code. 
• Disclosure of database authentication data. 
• Disclosure of sensitive files on the target server. 
PHP is a widely-used general-purpose scripting language that is
especially suited for Web development and can be embedded into HTML.
More information is available at http://www.php.net. 

Detection: iDEFENSE has verified the existence of this vulnerability in
PHP version 4.2.2. It is suspected and reported that all versions
between 4.0.3 and 4.2.3 inclusive are vulnerable. To determine if the
vulnerability exists in a specific implementation experiment with the
following snippet of code: 




File 1: 
File 2: 





\n";
echo "File2 location: $file2 \n";
?>

 

The target server is vulnerable if after submitting the form the script
prints: 

File2 location: /evil/file/location 

Workaround: Modify your upload handling scripts to utilize the
$_FILES[] array method instead of the legacy register_globals method.
More information is available at
http://www.php.net/manual/en/features.file-upload.php. 

The code base for PHP v4.3.0pre2 appears to fix the problem since
add_protected_variable() now calls normalize_protected_variable(),
which removes leading spaces. This fix however does not asses the
situation where a variable name contains an underscore, in which an
attacker can still submit a '.' that will pass through
normalize_protected_

#20701 [NEW]: ld: can't locate file for: -laprutil and after

[esj]

From: [EMAIL PROTECTED]
Operating system: Mac OS 10.2.2
PHP version:  4CVS-2002-11-28 (dev)
PHP Bug Type: Apache2 related
Bug description:  ld: can't locate file for: -laprutiland after

I tried to install php 4.4.0dev with Apache 2.0.43 by doing:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-pgsql
make

and got:

ld: can't locate file for: -laprutil

I deduced from bug reports on other OS that my be this file
was not necessary, and removed "-laprutil" from the makefile.
Then, make goes further, with similar problems.
You will find below the diff between the original Makefile
and the final. With this, make achieve its goal, and php
seems to work, and to connect to the pgsql server through
my browser. 
However, ld produced a lot of warnings about multiple
definition

ld: warning multiple definitions of symbol _XmlInitEncodingNS
ext/xml/expat/xmltok.o definition of _XmlInitEncodingNS in section
(__TEXT,__text)
/usr/local/apache2/bin/httpd definition of _XmlInitEncodingNS

and lot of others. Is there any problems with this ?


Here is the diff :

14c14
< MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd
-L/Users/Shared/httpd-2.0.43/srclib/apr-util/xml/expat/lib
-L/usr/local/apache2/lib -laprutil
/Users/Shared/httpd-2.0.43/srclib/apr-util/xml/expat/lib/libexpat.la
-L/usr/local/apache2/lib -lapr-0 -lm
---
> MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd
-L/Users/Shared/httpd-2.0.43/srclib/apr-util/xml/expat/lib
-L/usr/local/apache2/lib -L/usr/lib -lssl -lcrypto
69c69
< EXTRA_LIBS = -lpq -lm
---
> EXTRA_LIBS = -lpq -lm -lssl -lcrypto
84c84
< PHP_LDFLAGS = -L/usr/local/pgsql/lib
---
> PHP_LDFLAGS = -L/usr/local/pgsql/lib -L/usr/lib


---

E. Saint-James

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

#20694 [Com]: html not properly going to browser

[briantmeyer]

 ID:   20694
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows 2000 Server
 PHP Version:  4.3.0RC2
 New Comment:

cgi

php.exe specifically


Previous Comments:


[2002-11-28 07:30:54] [EMAIL PROTECTED]

Which SAPI are you using, cgi os isapi?



[2002-11-28 04:14:13] [EMAIL PROTECTED]

Just installed 4.3.0RC2 zip binary on windows 2000 server 
and iis 5.0 to check it out on my server.
normally use 4.2.3 and seem to be able to swap out installs 
as needed by putting files in and out of my php directory.

4.3.0RC2 seems to not like pages that work fine in 4.2.3. 
Some Pages using the new release display as raw text 
instead of html in some cases. When i look at source in a 
browser the beginning lines are missing although they are 
included. It seems no php is missed as all work i assign is 
completed as expected, just the html sent after the fact 
has missing lines at the top. I would expect it to die as 
it moves through the script, instead it is as if all works 
correctly but at the last moment only sends partial ending 
text to the browser.


As an example, changing the order only of an index page has 
the following results. (The includes here are very simple 
containing mainly html) 

The following works fine but the first line that shows up 
is the 4th with title tags, not :-->





 



HTML content here

While this is much worse and the first tag that shows up is 
 tags that are in classes.php followed by the <
SCRIPT> tag. It skips the title tag.--->





 



HTML content here


Changing php.ini does not help, adjusted it for over 2 
hours to see if a setting affected this. (expose_php and 
various error directives, using the two provided ini files, 
and many random changes) Of course all extensions were 
disabled. Different pages are affected differently.

My gut feeling is that php parses my script and assembles a 
completed html page. At this point something happens that 
deletes the top x lines (it never does half a line) and 
sends the rest to the browser. If enough header shows up i 
get a web page, usually with text at the top of exposed 
javascripts, sometimes i get text.

testing with pages that are simple text or simple html had 
the entire page show up just fine. The requires i used seem 
to be part of the issue as above. I tried looking at the 
index page from phpmyadmin but it would not even load due 
to not being able to find include files.

Switching back to php 4.2.3 fixes all above problems and 
pages again display the doctype and the html head tags. I 
hope someone can make sense of this, or that it is in fact 
a bogus/support issue.

I probably would not have submitted it, except that it is 
the preview release and that my other version works 
splendidly.





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

#20687 [Fbk->Opn]: Compile error on dbase module

[aboos]

 ID:   20687
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: linux redhat 7.1 gcc 2.96
 PHP Version:  4.2.3
 New Comment:

after to use lastest cvs version... 
[root@fw-adm dbase]# phpize
aclocal: macro `AC_ADD_LIBRARY' defined in acinclude.m4 but never used
aclocal: macro `AC_ADD_INCLUDE' defined in acinclude.m4 but never used
aclocal: macro `AC_ADD_LIBPATH' defined in acinclude.m4 but never used
aclocal: macro `AC_ADD_LIBRARY_WITH_PATH' defined in acinclude.m4 but
never used
[root@fw-adm dbase]# ./configure
configure: error: can not find sources in . or ..
[root@fw-adm dbase]#


[]'s


Previous Comments:


[2002-11-28 05:22:39] [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-11-27 19:26:21] [EMAIL PROTECTED]

Hi... 

I was trying to compile module dbase and during the process he returns
me the following mistake: 

dbf_head.c:249:49: too many arguments for macro "VCWD_OPEN"
dbf_head.c:252:48: too many arguments for macro "VCWD_OPEN"
make[1]: *** [dbf_head.slo] Error 1
make[1]: Leaving directory `/root/php-4.2.3/ext/dbase'
make: *** [all-recursive] Error 1

Sequence of commands:

/root/php-4.2.3/ext/dbase/phpize
/root/php-4.2.3/ext/dbase/./configure
/root/php-4.2.3/ext/dbase/make






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

#20702 [NEW]: strtoupper

[xcrap]

From: [EMAIL PROTECTED]
Operating system: Windows XP
PHP version:  4.2.2
PHP Bug Type: Feature/Change Request
Bug description:  strtoupper

It's not a bug.. it's more than a feature i guess.. the strtoupper don't
convert characters like áóç.. etc.

I don't know if it's because of the character system i'm using in php.ini

;default_charset = "iso-8859-1"

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

#20703 [NEW]: session object's array is restored corruptly

[khayll]

From: [EMAIL PROTECTED]
Operating system: debian woody latest
PHP version:  4.2.2
PHP Bug Type: Class/Object related
Bug description:  session object's array is restored corruptly

I'am not sure, if this is a in bug php, could be in my code, but I have
looked my code over and over and could not find anything...

So I describe my problem:

I have a session object, and it has an array variable.
In the code I do some array_shift, and array_push on one of the elements
of this array, wich is also an array. And I do something like this:

"get" return by reference from the session objects array:
$keyArray=&$object->get("key");

then I do array_shift, and array_push to maintain a FIFO like thing to
store the previous pagenames.

Now the problem:

normally this works in a number of pages, but in case of one page it acts
strangely: for some reason an extra element into the array appears like
this:

normally the array values should change when going from page5 to page6

from (now I am on page5):

page1
page2
page3
page4
page5

into (here there is a request for a new page: page6):

page2
page3
page4
page5
page6

but instead !!! it changes to:

page1
page5
page1
page6
page1


I tried to track down where this happens, and I found out, that is
happening between the __sleep and __wakeup methods, which would mean, that
serialize, and unserialize does not work correctly.

Another wery strange thing is that this work perfecly on the local
development server, which runs the same version of php...


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

#18251 [Com]: Lost variables from post action

[sk]

 ID:   18251
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Variables related
 Operating System: WindowsXP, Linux
 PHP Version:  4.1.2
 New Comment:

My problem might be affected by this bug.

I'm using PHP 4.2.3 (sapi) on Windows 2000 Server running Apache 1.3.27
as Webserver. 
My form:

  
  


Then I'm dumping $_POST, where the following happens:
When input was an integer from 1-999 it is displayed correctly. From
1000 on the corresponding post value is "false". Inserting "abcdefgh"
in the form results in "efgh"...
Any Ideas?

Copying that example to my debian system, running PHP 4.2.3 on an
apache 1.3.26, the result is fine and works as expected.

Hope that helps finding another bug,
Stefan


Previous Comments:


[2002-07-09 18:08:31] [EMAIL PROTECTED]

Update to 4.2.1. If this happens with it too, then reopen 
this report.




[2002-07-09 18:04:24] [EMAIL PROTECTED]

I meet this problem 1/100 (aproximetly) post actions



[2002-07-09 18:03:44] [EMAIL PROTECTED]

yes



[2002-07-09 18:02:26] [EMAIL PROTECTED]

Is register_globals=On in your php.ini?




[2002-07-09 17:45:13] [EMAIL PROTECTED]

I tried before, we had a lot of GD support problems in PHP 4.2
This is the reason we use of 4.1.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/18251

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

#20681 [Opn]: array_search(:object, :array) fails

[moriyoshi]

 ID:   20681
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Win 2K SP3
 PHP Version:  4.2.3
 New Comment:

My apologies, I should have give more explanation on this.

The following script is nearly an equivalent of array_search().



This function actually accepts objects as a needle, but array_search()
doesn't. In this sense, array_search() should go along with objects as
you said.

However IMO it might be too kind to offer this functionality.

value = val;
}
}

$a = new foo(1);
$b = new foo(2);
$c = $a;
$d = &$a;

var_dump($a == $b);
var_dump($a == $c);
var_dump($a == $d);
var_dump($c == $d);
var_dump($a === $b);
var_dump($a === $c);
var_dump($a === $d);
var_dump($c === $d);
var_dump($a == new foo(1));
var_dump($a == new foo(2));
var_dump($b === new foo(2));
?>

What do you think of the result? Some say this could be preferrable,
but others couldn't.

That's the reason I said the function doesn't need that feature. Isn't
this enough?



Previous Comments:


[2002-11-27 14:31:45] [EMAIL PROTECTED]

I don't understand what this has to do with how equality is handled by
the Zend engine. The documentation states that array_search can accept
"mixed" data in the first parameter, which would seem to imply that
objects should work. They don't. Therefore, array_search() is broken.
What am I missing?

Also, I have seen no mention in the PHP manual about how equality is
handled by the Zend engine. Should I file a documentation bug?

Thanks,

Daniel



[2002-11-27 14:08:01] [EMAIL PROTECTED]

As it's been said enough that identity or equalness of two objects is
somewhat obscure in ZendEngine1, I don't see any reason to implement
this feature unless ZendEngine2 becomes ready for release versions.

So I'm reclassifying this report as a feature request in this point of
view.




[2002-11-27 11:48:56] [EMAIL PROTECTED]



Seems to work as I exect it to:

int(0)
int(2)
int(1)

Also, the original example still produces warnings and doesn't find the
elements if you change the array_search() calls to in_array().



[2002-11-27 11:41:45] [EMAIL PROTECTED]

array_search() does not seem to work when the needle is an object.

Sample code:



Output:

Warning:  Wrong datatype for first argument in call to
array_search in C:\dparks\Documents\html\tmp.php on line
17
bool(false)

Warning:  Wrong datatype for first argument in call to
array_search in C:\dparks\Documents\html\tmp.php on line
20
bool(false)
int(1)

Environment:
This is PHP 4.2.3 (binary from Zend or PHP.net) running on Apache
2.0.40 on Win 2K SP3.

Please email me if you would like me to run more tests, or try another
build (it may be awhile before I can try another build though --
someone else here had trouble with 4.3rc1 and I am behind schedule).

Thanks,

Daniel





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

#20704 [NEW]: reproducible crash

[nytral]

From: [EMAIL PROTECTED]
Operating system: Windows2000+SP3/Dual
PHP version:  4.3.0RC2
PHP Bug Type: MSSQL related
Bug description:  reproducible crash

It's a flat PHP setup with only mssql module loaded.
Since the last MSSQL2000 (SP2+hotfix) and MDAC 2.7, SQL queries returning
more than a few results crash (either Access Violation using ISAPI, or no
output at all with php-cgi.exe past the mssql_query() call).
Each time I install a different php build, the first script load will
output something before dying in the middle of returning results;
reloading the page will give CGI errors.
Weird thing is, calling php.exe on the command line works each time;
calling php-cgi.exe doesn't (problem described above show up).
I can't even move those scripts to Unix, since some are using
mssql_next_result() which Sybase doesn't provide. Ouch! It looks like
using PHP to talk to MSSQL is not a good idea on any OS.

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

#20705 [NEW]: openssl_pkey_new does not seem to generate a new key

[Troubleum]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 Professional
PHP version:  4.2.3
PHP Bug Type: OpenSSL related
Bug description:  openssl_pkey_new does not seem to generate a new key

OS: Windows 2000 Professional
PHP version: 4.2.3
Apache version: 1.3.24 Win32
openssl: 0.9.6c

Problem: openssl_pkey_new does not seem to generate a new key

how to reproduces the problem:
I have the following script to test openssl..

--

--

The output is the following:
Warning: cannot get key from parameter 1 in c:\dev\htdocs\openssl\test.php
on line 9
not correct

--
I first compiled openssl 0.9.6c using Visual C++ and copied libeay32.dll
and ssley32.dll to c:/winnt/system32.
Then I upgraded to php 4.2.3 and replaced the two files with ones in the
folder "dlls".

Openssl seems to be installed:
> OpenSSL support enabled 
> OpenSSL Version OpenSSL 0.9.6c 21 dec 2001
-- 
Edit bug report at http://bugs.php.net/?id=20705&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20705&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20705&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20705&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20705&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20705&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20705&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20705&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20705&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20705&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20705&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20705&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20705&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20705&r=isapi

#20705 [Opn]: openssl_pkey_new does not seem to generate a new key

[Troublegum]

 ID:   20705
 User updated by:  [EMAIL PROTECTED]
-Reported By:  [EMAIL PROTECTED]
+Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OpenSSL related
 Operating System: Windows 2000 Professional
 PHP Version:  4.2.3
 New Comment:

wrong email address entered..
correct one: [EMAIL PROTECTED]


Previous Comments:


[2002-11-28 14:25:05] [EMAIL PROTECTED]

OS: Windows 2000 Professional
PHP version: 4.2.3
Apache version: 1.3.24 Win32
openssl: 0.9.6c

Problem: openssl_pkey_new does not seem to generate a new key

how to reproduces the problem:
I have the following script to test openssl..

--

--

The output is the following:
Warning: cannot get key from parameter 1 in
c:\dev\htdocs\openssl\test.php on line 9
not correct

--
I first compiled openssl 0.9.6c using Visual C++ and copied
libeay32.dll and ssley32.dll to c:/winnt/system32.
Then I upgraded to php 4.2.3 and replaced the two files with ones in
the folder "dlls".

Openssl seems to be installed:
> OpenSSL support enabled 
> OpenSSL Version OpenSSL 0.9.6c 21 dec 2001




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

#20704 [Opn]: reproducible crash

[nytral]

 ID:   20704
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Windows2000+SP3/Dual
 PHP Version:  4.3.0RC2
 New Comment:

I just tried ISAPI with RC2; first script load is Ok,  
resubmit and it's an access violation.


Previous Comments:


[2002-11-28 14:16:28] [EMAIL PROTECTED]

It's a flat PHP setup with only mssql module loaded.
Since the last MSSQL2000 (SP2+hotfix) and MDAC 2.7, SQL queries
returning more than a few results crash (either Access Violation using
ISAPI, or no output at all with php-cgi.exe past the mssql_query()
call).
Each time I install a different php build, the first script load will
output something before dying in the middle of returning results;
reloading the page will give CGI errors.
Weird thing is, calling php.exe on the command line works each time;
calling php-cgi.exe doesn't (problem described above show up).
I can't even move those scripts to Unix, since some are using
mssql_next_result() which Sybase doesn't provide. Ouch! It looks like
using PHP to talk to MSSQL is not a good idea on any OS.

Thanks for your help,
-Martin




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

#20706 [NEW]: skipping an optional argument

[jeremyirons]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.2.3
PHP Bug Type: Feature/Change Request
Bug description:  skipping an optional argument

Any reason why the following has never been implemented for optional
function arguments?

function test($a, $b = 1, $c = 2)
{
//do something
}

test("hello",,7);

What I would like the test function to see would be
$a = "hello"
$b = 1
$c = 7

Since I skipped the second argument, I would like the default value to
kick in. This would be really useful!
-- 
Edit bug report at http://bugs.php.net/?id=20706&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20706&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20706&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20706&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20706&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20706&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20706&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20706&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20706&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20706&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20706&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20706&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20706&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20706&r=isapi

#20702 [Com]: strtoupper

[michael . mauch]

 ID:   20702
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  4.2.2
 New Comment:

Is your locale correctly set?


Try setlocale(LC_ALL,'Portuguese')  or something like that
(I don't know what your locale is, look it up in the manual of your
OS).


Previous Comments:


[2002-11-28 12:45:08] [EMAIL PROTECTED]

It's not a bug.. it's more than a feature i guess.. the strtoupper
don't convert characters like áóç.. etc.

I don't know if it's because of the character system i'm using in
php.ini

;default_charset = "iso-8859-1"

But.. anyway.. it's just a suggestion :)




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

#20707 [NEW]: incorrect behavior of mail() with Bcc:

[support]

From: [EMAIL PROTECTED]
Operating system: win 2000
PHP version:  4.3.0RC2
PHP Bug Type: Mail related
Bug description:  incorrect behavior of mail() with Bcc:

A bug in the SendText() function in php-4.3.0RC2\win32\sendmail.c module
can cause incorrect sending of messages to addresses in Cc: and Bcc:
fields in the additional headers string.

mail($recipient, $subject, $message, $headers);
Example:
assume $recipient, adr1, adr2 etc represent valid addresses, and XX any
other headers

$headers = "Cc: adr1, adr2\nXX" 
sends messages for recipient, adr1 and adr2, ie. OK
$headers = "Bcc: adr1, adr2\nXX" 
sends messages for recipient, and two copies for both adr1 and adr2.
$headers = "Cc: adr1\nBcc: adr2\nXX" 
sends messages for recipient, adr1 and two copies for adr2.
$headers = "BCc: adr1\nCc: adr2\nXX" 
sends messages for recipient, two copies for adr1 and none for adr2.

The cause is in the SendText() parsing headers string for cc and bcc
fields (from line 418 on). The code:
if (headers && (pos1 = strstr(headers_lc, "cc:"))) {
recognize cc: substring in the bcc: resulting in duplicating messages for
bcc: addresses

more robust code could look like:
char *pos;
if (headers) {
pos=headers_lc;
while ((pos=strstr(pos,"cc:"))) {
if((pos>headers_lc)&&(*(pos-1)=='b')) {
pos+=3;   //bcc: found, skip it now
} else {
pos+=3;
pos1=headers+(pos-headers_lc);
... the rest of the routine lines 423 to 444
}
} // in case of more cc lines or bcc prior to cc
}
... lines 447 to 471
// similar loop for bcc ie.
pos=headers_lc;
while ((pos=strstr(pos,"bcc:"))) {
pos +=4;
pos1=headers+(pos-headers_lc);
... the rest of the routine lines 477 to 519 with respective
modifications to generating the stripped_header string.

zbynek




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

#20694 [Fbk->Opn]: html not properly going to browser

[briantmeyer]

 ID:   20694
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: Windows 2000 Server
 PHP Version:  4.3.0RC2
 New Comment:

CGI
c:\php\php.exe %s %s
is the command line in the application mappings

I can install it again if you want me to try something
(i just swap out contents of the php folder, iis isn't 
changed)


Previous Comments:


[2002-11-28 11:48:33] [EMAIL PROTECTED]

cgi

php.exe specifically



[2002-11-28 07:30:54] [EMAIL PROTECTED]

Which SAPI are you using, cgi os isapi?



[2002-11-28 04:14:13] [EMAIL PROTECTED]

Just installed 4.3.0RC2 zip binary on windows 2000 server 
and iis 5.0 to check it out on my server.
normally use 4.2.3 and seem to be able to swap out installs 
as needed by putting files in and out of my php directory.

4.3.0RC2 seems to not like pages that work fine in 4.2.3. 
Some Pages using the new release display as raw text 
instead of html in some cases. When i look at source in a 
browser the beginning lines are missing although they are 
included. It seems no php is missed as all work i assign is 
completed as expected, just the html sent after the fact 
has missing lines at the top. I would expect it to die as 
it moves through the script, instead it is as if all works 
correctly but at the last moment only sends partial ending 
text to the browser.


As an example, changing the order only of an index page has 
the following results. (The includes here are very simple 
containing mainly html) 

The following works fine but the first line that shows up 
is the 4th with title tags, not :-->





 



HTML content here

While this is much worse and the first tag that shows up is 
 tags that are in classes.php followed by the <
SCRIPT> tag. It skips the title tag.--->





 



HTML content here


Changing php.ini does not help, adjusted it for over 2 
hours to see if a setting affected this. (expose_php and 
various error directives, using the two provided ini files, 
and many random changes) Of course all extensions were 
disabled. Different pages are affected differently.

My gut feeling is that php parses my script and assembles a 
completed html page. At this point something happens that 
deletes the top x lines (it never does half a line) and 
sends the rest to the browser. If enough header shows up i 
get a web page, usually with text at the top of exposed 
javascripts, sometimes i get text.

testing with pages that are simple text or simple html had 
the entire page show up just fine. The requires i used seem 
to be part of the issue as above. I tried looking at the 
index page from phpmyadmin but it would not even load due 
to not being able to find include files.

Switching back to php 4.2.3 fixes all above problems and 
pages again display the doctype and the html head tags. I 
hope someone can make sense of this, or that it is in fact 
a bogus/support issue.

I probably would not have submitted it, except that it is 
the preview release and that my other version works 
splendidly.





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

#20708 [NEW]: echo 'foo'==0 ? 'is true ' : 'is false ' outputs 'is true'

[wb]

From: [EMAIL PROTECTED]
Operating system: linux 2.2.20, linux 2.4.19
PHP version:  4.2.3
PHP Bug Type: Scripting Engine problem
Bug description:  echo 'foo'==0 ? 'is true ' : 'is false ' outputs 'is true'

sorry, im really not sure if this is a kind of bug or if i'm getting
something wrong: the two lines

echo 'foo'==0 ? 'is true ' : 'is false ';
if('bar'==0) echo 'is true '; else echo 'is false ';

will output:
is true is true

i dont understand why 'foo'==0 returns true.

the way i understand the manual, php should consider 'foo' a nonempty
string and 0 a zero integer. even if it would do a boolean comparison,
according to the manual 'foo' should be juggled to true and 0 should be
juggled to false. how can 'foo'==0 return true? have i missed something?

i hope i do not resubmit a known issue, i tried some queries but i really
didnt know how to lookup this issue.

this happens with variables as well. i ran into this problem in my
programming when comparing array keys that could be numeric or string. a 0
array key compared against any nonempty string array key always returned
true. it took me a while to find out that's why my program didn´t work the
way i thought it should. 

i hope this is not something that happens only to me, but i have tested
the two lines on three different boxes before writing to you.

my configure line:
./configure' '--with-mysql=/usr/local/mysql'
'--with-apache=../apache_1.3.26' '--enable-ftp'
'--with-zlib-dir=/usr/lib'

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

#20708 [Opn]: 'foo'==0 returns true

[wb]

 ID:   20708
 User updated by:  [EMAIL PROTECTED]
-Summary:  echo 'foo'==0 ? 'is true ' : 'is false ' outputs 'is
   true'
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: linux 2.2.20, linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

another summary


Previous Comments:


[2002-11-28 18:02:32] [EMAIL PROTECTED]

sorry, im really not sure if this is a kind of bug or if i'm getting
something wrong: the two lines

echo 'foo'==0 ? 'is true ' : 'is false ';
if('bar'==0) echo 'is true '; else echo 'is false ';

will output:
is true is true

i dont understand why 'foo'==0 returns true.

the way i understand the manual, php should consider 'foo' a nonempty
string and 0 a zero integer. even if it would do a boolean comparison,
according to the manual 'foo' should be juggled to true and 0 should be
juggled to false. how can 'foo'==0 return true? have i missed
something?

i hope i do not resubmit a known issue, i tried some queries but i
really didnt know how to lookup this issue.

this happens with variables as well. i ran into this problem in my
programming when comparing array keys that could be numeric or string.
a 0 array key compared against any nonempty string array key always
returned true. it took me a while to find out that's why my program
didn´t work the way i thought it should. 

i hope this is not something that happens only to me, but i have tested
the two lines on three different boxes before writing to you.

my configure line:
./configure' '--with-mysql=/usr/local/mysql'
'--with-apache=../apache_1.3.26' '--enable-ftp'
'--with-zlib-dir=/usr/lib'

Best regards,
wolfgang




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

#20708 [Opn->Bgs]: 'foo'==0 returns true

[rasmus]

 ID:   20708
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: linux 2.2.20, linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

The numerical value of 'foo' is 0.  If you want to compare both value
*and* type, use ===


Previous Comments:


[2002-11-28 18:11:16] [EMAIL PROTECTED]

another summary



[2002-11-28 18:02:32] [EMAIL PROTECTED]

sorry, im really not sure if this is a kind of bug or if i'm getting
something wrong: the two lines

echo 'foo'==0 ? 'is true ' : 'is false ';
if('bar'==0) echo 'is true '; else echo 'is false ';

will output:
is true is true

i dont understand why 'foo'==0 returns true.

the way i understand the manual, php should consider 'foo' a nonempty
string and 0 a zero integer. even if it would do a boolean comparison,
according to the manual 'foo' should be juggled to true and 0 should be
juggled to false. how can 'foo'==0 return true? have i missed
something?

i hope i do not resubmit a known issue, i tried some queries but i
really didnt know how to lookup this issue.

this happens with variables as well. i ran into this problem in my
programming when comparing array keys that could be numeric or string.
a 0 array key compared against any nonempty string array key always
returned true. it took me a while to find out that's why my program
didn´t work the way i thought it should. 

i hope this is not something that happens only to me, but i have tested
the two lines on three different boxes before writing to you.

my configure line:
./configure' '--with-mysql=/usr/local/mysql'
'--with-apache=../apache_1.3.26' '--enable-ftp'
'--with-zlib-dir=/usr/lib'

Best regards,
wolfgang




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

#20708 [Com]: 'foo'==0 returns true

[wb]

 ID:   20708
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: linux 2.2.20, linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

thank you for very fast information.

type juggling is a great feature but really hard to learn. now i
learned that it casts my string to numeric for the comparison with an
integer - my coding would have needed the integer casted to a string. 

sorry for bothering you. i will go and look for more information about
precedence of type casting in comparisons if it is that way it works.


Previous Comments:


[2002-11-28 18:13:07] [EMAIL PROTECTED]

The numerical value of 'foo' is 0.  If you want to compare both value
*and* type, use ===



[2002-11-28 18:11:16] [EMAIL PROTECTED]

another summary



[2002-11-28 18:02:32] [EMAIL PROTECTED]

sorry, im really not sure if this is a kind of bug or if i'm getting
something wrong: the two lines

echo 'foo'==0 ? 'is true ' : 'is false ';
if('bar'==0) echo 'is true '; else echo 'is false ';

will output:
is true is true

i dont understand why 'foo'==0 returns true.

the way i understand the manual, php should consider 'foo' a nonempty
string and 0 a zero integer. even if it would do a boolean comparison,
according to the manual 'foo' should be juggled to true and 0 should be
juggled to false. how can 'foo'==0 return true? have i missed
something?

i hope i do not resubmit a known issue, i tried some queries but i
really didnt know how to lookup this issue.

this happens with variables as well. i ran into this problem in my
programming when comparing array keys that could be numeric or string.
a 0 array key compared against any nonempty string array key always
returned true. it took me a while to find out that's why my program
didn´t work the way i thought it should. 

i hope this is not something that happens only to me, but i have tested
the two lines on three different boxes before writing to you.

my configure line:
./configure' '--with-mysql=/usr/local/mysql'
'--with-apache=../apache_1.3.26' '--enable-ftp'
'--with-zlib-dir=/usr/lib'

Best regards,
wolfgang




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

#20693 [Fbk->Csd]: round() doesn't always work

[bero]

 ID:   20693
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: *Math Functions
 Operating System: Debian GNU/Linux (pool)
 PHP Version:  4.2.3
 New Comment:

upps,the real problem was setlocale()


Previous Comments:


[2002-11-28 05:26:41] [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-11-28 03:22:38] [EMAIL PROTECTED]

In a simple script consisting a single line like 

round() produces a proper output. However in one of my scripts, where
round() is used inside a method of a sophisticated object, it gives the
folowig results:
echo round(195.583, 2); -> 195
echo round(195.583, 1); -> 195
echo round(195.583, 0); -> 195
echo round(195.583, -1); -> 200
echo round(195.583, -2); -> 200

I use PHP4.2.3 with Apache 1.3.26, both of them are original Debian's
binaries. I have reproduced this behaviour on several machines.






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

#20709 [NEW]: Session variable getting mysteriously set

[DChri36990]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.2.3
PHP Bug Type: Class/Object related
Bug description:  Session variable getting mysteriously set

When my code does the following in sequence:

1) $_SESSION['League'] = 1; /* or any other number */

2) unset($_SESSION['League']);

3) $League = new AnyObject(...);

The variable $_SESSION['League'] gets set to the contents of "AnyObject".

This doesn't occur if the Session variable had never been set/unset, nor
does it occur when the Session variable has an existing value in it when
statement (3) occurs.
Addtionally, this assignment doesn't occur immediately at the time that
statement (3) is executed.  It is somehow delayed until after the script
completes.  It's only when I go on to execute another script when I
encounter the "mystery" assignment.

I haven't tried this with names other than 'League', but common sense
suggests this is likely a generic problem independant of the specific name
I happened to use.

FYI, I'm running Apache version 1.3, the latest stable release for
Windows. My PHP configuration is generic, with the exception of including
the module(s) required to do XML/XSLT transforms.


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

#20701 [Opn->Fbk]: ld: can't locate file for: -laprutil and after

[iliaa]

 ID:   20701
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Apache2 related
 Operating System: Mac OS 10.2.2
 PHP Version:  4CVS-2002-11-28 (dev)
 New Comment:

Does it compile if you remove the 
--with-apxs2=/usr/local/apache2/bin/apxs configure option?


Previous Comments:


[2002-11-28 10:54:26] [EMAIL PROTECTED]

I tried to install php 4.4.0dev with Apache 2.0.43 by doing:

./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-pgsql
make

and got:

ld: can't locate file for: -laprutil

I deduced from bug reports on other OS that my be this file
was not necessary, and removed "-laprutil" from the makefile.
Then, make goes further, with similar problems.
You will find below the diff between the original Makefile
and the final. With this, make achieve its goal, and php
seems to work, and to connect to the pgsql server through
my browser. 
However, ld produced a lot of warnings about multiple
definition

ld: warning multiple definitions of symbol _XmlInitEncodingNS
ext/xml/expat/xmltok.o definition of _XmlInitEncodingNS in section
(__TEXT,__text)
/usr/local/apache2/bin/httpd definition of _XmlInitEncodingNS

and lot of others. Is there any problems with this ?


Here is the diff :

14c14
< MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd
-L/Users/Shared/httpd-2.0.43/srclib/apr-util/xml/expat/lib
-L/usr/local/apache2/lib -laprutil
/Users/Shared/httpd-2.0.43/srclib/apr-util/xml/expat/lib/libexpat.la
-L/usr/local/apache2/lib -lapr-0 -lm
---
> MH_BUNDLE_FLAGS = -bundle -bundle_loader /usr/local/apache2/bin/httpd
-L/Users/Shared/httpd-2.0.43/srclib/apr-util/xml/expat/lib
-L/usr/local/apache2/lib -L/usr/lib -lssl -lcrypto
69c69
< EXTRA_LIBS = -lpq -lm
---
> EXTRA_LIBS = -lpq -lm -lssl -lcrypto
84c84
< PHP_LDFLAGS = -L/usr/local/pgsql/lib
---
> PHP_LDFLAGS = -L/usr/local/pgsql/lib -L/usr/lib


---

E. Saint-James





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

#20673 [Opn->Ver]: Inexplicable arithmetical error due to references

[iliaa]

 ID:   20673
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Verified
 Bug Type: Scripting Engine problem
-Operating System: Win 2000 NT
+Operating System: Win 2000 NT/Linux
-PHP Version:  4.2.1
+PHP Version:  4.3.0-dev/4.4.0-dev


Previous Comments:


[2002-11-27 07:04:52] [EMAIL PROTECTED]



When I add a reference to $a, the behavior of $a + $a++ becomes
inexplicable different. Note that $a isn't changed anywhere!



The only difference is $b =& $a, but why $a takes care of references to
itself?




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

#20704 [Opn->Fbk]: reproducible crash

[iliaa]

 ID:   20704
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: MSSQL related
 Operating System: Windows2000+SP3/Dual
 PHP Version:  4.3.0RC2
 New Comment:

Could you show the smallest possible version of the script, which
causes the problem?


Previous Comments:


[2002-11-28 14:30:33] [EMAIL PROTECTED]

I just tried ISAPI with RC2; first script load is Ok,  
resubmit and it's an access violation.



[2002-11-28 14:16:28] [EMAIL PROTECTED]

It's a flat PHP setup with only mssql module loaded.
Since the last MSSQL2000 (SP2+hotfix) and MDAC 2.7, SQL queries
returning more than a few results crash (either Access Violation using
ISAPI, or no output at all with php-cgi.exe past the mssql_query()
call).
Each time I install a different php build, the first script load will
output something before dying in the middle of returning results;
reloading the page will give CGI errors.
Weird thing is, calling php.exe on the command line works each time;
calling php-cgi.exe doesn't (problem described above show up).
I can't even move those scripts to Unix, since some are using
mssql_next_result() which Sybase doesn't provide. Ouch! It looks like
using PHP to talk to MSSQL is not a good idea on any OS.

Thanks for your help,
-Martin




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

#20704 [Fbk->Opn]: reproducible crash

[nytral]

 ID:   20704
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Windows2000+SP3/Dual
 PHP Version:  4.3.0RC2
 New Comment:

Good news: 4.2.3 doesn't crash so far. I upgraded because after some
time I would randomly get Access Violations. But I prefer to have a few
here and there than 100% of the time .


Previous Comments:


[2002-11-28 22:04:19] [EMAIL PROTECTED]

Could you show the smallest possible version of the script, which
causes the problem?



[2002-11-28 14:30:33] [EMAIL PROTECTED]

I just tried ISAPI with RC2; first script load is Ok,  
resubmit and it's an access violation.



[2002-11-28 14:16:28] [EMAIL PROTECTED]

It's a flat PHP setup with only mssql module loaded.
Since the last MSSQL2000 (SP2+hotfix) and MDAC 2.7, SQL queries
returning more than a few results crash (either Access Violation using
ISAPI, or no output at all with php-cgi.exe past the mssql_query()
call).
Each time I install a different php build, the first script load will
output something before dying in the middle of returning results;
reloading the page will give CGI errors.
Weird thing is, calling php.exe on the command line works each time;
calling php-cgi.exe doesn't (problem described above show up).
I can't even move those scripts to Unix, since some are using
mssql_next_result() which Sybase doesn't provide. Ouch! It looks like
using PHP to talk to MSSQL is not a good idea on any OS.

Thanks for your help,
-Martin




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

#20613 [Opn->Fbk]: PHP Crashes SIGSEGV under iPlanet

[iliaa]

 ID:   20613
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: iPlanet related
 Operating System: Solaris 8
 PHP Version:  4.2.2
 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




Previous Comments:


[2002-11-24 21:39:46] [EMAIL PROTECTED]

Sorry forgot the configure line:

./configure --with-ldap=/usr/local/ --enable-thread-safety
--enable-libgcc --ena
ble-ftp --with-mysql=/usr/local/mysql --with-custom-odbc=/opt/odbc
--with-curl=/
opt --with-openssl=/usr/local/ssl --enable-discard-path --enable-wddx
--enable-x
slt --with-xslt-sablot --enable-track-vars --enable-sysvsem
--with-oci8=/oracle/
home/product/8.1.7 --with-nsapi=/db/www/netscape/server4
--enable-debug=yes --wi
th-msession



[2002-11-24 21:06:57] [EMAIL PROTECTED]

This seems similar to 15439 and 20109 but it is on iPlanet Web Server
4.1SP10 on Solaris 8.

PHP crashes the webserver SIGSEGV, I have so far been unable to find
the exact script that causes the problem, as it seems fairly random. I
do however have a backtrace reproduced below:


#0  0xfec33344 in strlen () from /usr/lib/libc.so.1
#1  0xfdd96a9c in php_register_variable () from
/db/www/netscape/bin/libphp4.so
#2  0xfdd794b8 in sapi_nsapi_register_server_variables ()
   from /db/www/netscape/bin/libphp4.so
#3  0xfdd7f1cc in php_register_server_variables ()
   from /db/www/netscape/bin/libphp4.so
#4  0xfdd7f938 in php_hash_environment () from
/db/www/netscape/bin/libphp4.so
#5  0xfdd7d75c in php_request_startup () from
/db/www/netscape/bin/libphp4.so
#6  0xfdd79d98 in nsapi_module_main () from
/db/www/netscape/bin/libphp4.so
#7  0xfdd7a0e8 in php4_execute () from /db/www/netscape/bin/libphp4.so
#8  0xff256ccc in
__0Fafunc_native_pool_wait_workPFP6GpblockP6HSessionP6HRequest_iUiP6GpblockP6HSessionP6HRequest
()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#9  0xff2562ec in
__0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest
() from /db/www/netscape/bin/https/lib/libns-httpd40.so
#10 0xff257284 in INTobject_execute ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#11 0xff25bec8 in
__0FQ_perform_serviceP6HSessionP6HRequestP6Mhttpd_object ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#12 0xff25bf84 in INTservact_service ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#13 0xff25c29c in INTservact_handle_processed ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
---Type  to continue, or q  to quit--- 
#14 0xff28a8a4 in __0fLHttpRequestUUnacceleratedRespondPCcPcTC ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#15 0xff289680 in __0fLHttpRequestNHandleRequestP6Gnetbuf ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#16 0xff285e9c in __0fNDaemonSessionHRespondv ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#17 0xff285d28 in __0fNDaemonSessionKThreadMainv ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#18 0xff2857b4 in CThreadMain ()
   from /db/www/netscape/bin/https/lib/libns-httpd40.so
#19 0xfef42ad8 in _pt_root () from
/db/www/netscape/bin/https/lib/libnspr3.so





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

#20709 [Opn->Fbk]: Session variable getting mysteriously set

[iliaa]

 ID:   20709
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: Class/Object related
 Operating System: Windows 2000
 PHP Version:  4.2.3
 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

This is something that I believe was fixed in 4.3.0, please try the RC2
and report if the problem persists. Also, is you register_globals on?


Previous Comments:


[2002-11-28 20:50:29] [EMAIL PROTECTED]

When my code does the following in sequence:

1) $_SESSION['League'] = 1; /* or any other number */

2) unset($_SESSION['League']);

3) $League = new AnyObject(...);

The variable $_SESSION['League'] gets set to the contents of
"AnyObject".

This doesn't occur if the Session variable had never been set/unset,
nor does it occur when the Session variable has an existing value in it
when statement (3) occurs.
Addtionally, this assignment doesn't occur immediately at the time that
statement (3) is executed.  It is somehow delayed until after the
script completes.  It's only when I go on to execute another script
when I encounter the "mystery" assignment.

I haven't tried this with names other than 'League', but common sense
suggests this is likely a generic problem independant of the specific
name I happened to use.

FYI, I'm running Apache version 1.3, the latest stable release for
Windows. My PHP configuration is generic, with the exception of
including the module(s) required to do XML/XSLT transforms.






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

#20630 [Opn->Fbk]: IIS does not create session first time

[iliaa]

 ID:   20630
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Win2k Server
 PHP Version:  4.2.3
 New Comment:

What sort of a session mechanism are you using, URLs, Cookies or both
and what kind of session managment are you using, user, php or
something else?


Previous Comments:


[2002-11-25 14:11:03] [EMAIL PROTECTED]

When I log in with IIS it does not create my session I have to log out
and then log back in to have my session start. I installed Apache on
Win2k server and it works fine first time around. Any ideas on why this
is? All my updates and service paks are up to date on IIS, Internet
Explorer, and Win2k

thanks,

Dustin




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

#20658 [Com]: segfault after calling array_walk

[chris-php]

 ID:   20658
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux 2.4.19-pre4
 PHP Version:  4CVS-2002-11-26 (stable)
 New Comment:

Seems to be fixed now, thanks for the help.


Previous Comments:


[2002-11-26 17:02:17] [EMAIL PROTECTED]

Yep. I found a bug in error reporting code while investigating
array_walk() and fixed it. Now please try the latest one and it will
give you a bit more useful information, I suppose.



[2002-11-26 16:48:36] [EMAIL PROTECTED]

The one I tried and quoted in the bug report was less than 2 hours old
at the time of the reporting.

Has anything changed between then and now?



[2002-11-26 15:38:46] [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-11-26 13:41:48] [EMAIL PROTECTED]

I get a segfault after calling array_walk, in this portion of a
script:

function get_flat($packageid = 0) {
if ($packageid == $this->lastflatid)
return $this->flat;
$this->lastflatid = $packageid;
$this->flat = array();
array_walk(&$this->tree[$packageid], array(&$this,
"get_flat_callback"));
return $this->flat;
}

function get_flat_callback($val, $key) {
if (is_array($val)) {
if (is_int($key))
$this->flat[$key] =& $val;
array_walk(&$val, array(&$this, "get_flat_callback"));
}
}

The entire script can be viewed here:

http://dali.deviantart.com/~chris/themetree.phps

For some odd reason, this code is called twice in the page, however the
bug only manifests itself the second time the function is called (which
was why I added the first three lines of get_flat() as a temporary
workaround) however it is completely reproducible. I could also
reproduce it in 4.2.2, and it printed an error message to the php
error_log:

[26-Nov-2002 10:16:31] PHP Warning:  Unable to call (null)() - function
does not exist in /www/shared/themetree.php on line 67

A backtrace from a snapshot from an hour or two ago is below:

Program received signal SIGSEGV, Segmentation fault.
0x4038fd10 in xbuf_format_converter (xbuf=0xbfff9a78,
fmt=0x403ddd60 "Unable to call %s() - function does not exist",
ap=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/spprintf.c:438
438 s_len =
strlen(s);
(gdb) bt
#0  0x4038fd10 in xbuf_format_converter (xbuf=0xbfff9a78,
fmt=0x403ddd60 "Unable to call %s() - function does not exist",
ap=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/spprintf.c:438
#1  0x403902e1 in vspprintf (pbuf=0xbfff9ad8, max_len=0,
format=0x403ddd60 "Unable to call %s() - function does not exist",
ap=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/spprintf.c:622
#2  0x4038c3cc in php_verror (docref=0x0, params=0x403e9f93 "",
type=2,
format=0x403ddd60 "Unable to call %s() - function does not exist",
args=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/main.c:399
#3  0x4038c723 in php_error_docref0 (docref=0x0, type=2,
format=0x403ddd60 "Unable to call %s() - function does not exist")
at /home/chris/php4-STABLE-200211261830/main/main.c:484
#4  0x403178bb in php_array_walk (target_hash=0x81ca984, userdata=0x0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:983
#5  0x403179fd in zif_array_walk (ht=2, return_value=0x8254c8c,
this_ptr=0x0,
return_value_used=0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:1023
#6  0x403cb211 in execute (op_array=0x8254b7c)
at /home/chris/php4-STABLE-200211261830/Zend/zend_execute.c:1598
#7  0x403aff76 in call_user_function_ex (function_table=0x8253a00,
object_pp=0x8209a68, function_name=0x8253644,
retval_ptr_ptr=0xbfffa1a8,
param_count=2, params=0xbfffa1c0, no_separation=0,
symbol_table=0x0)
at
/home/chris/php4-STABLE-200211261830/Zend/zend_execute_API.c:557
#8  0x40317889 in php_array_walk (target_hash=0x824e4c4, userdata=0x0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:978
#9  0x403179fd in zif_array_walk (ht=2, return_value=0x825547c,
this_ptr=0x0,
return_value_used=0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:1023
#10 0x403cb211 in execute (op_array=0x8254b7c)
at /home/chris/php4-STABLE-200211261830/Zend/zend_execute.c:1598
#11 0x403aff76 in call_user_function_ex (function_table=0x8253a00,
object_pp=0x820aab0, function_name=0x825646c

#20658 [Fbk->Csd]: segfault after calling array_walk

[chris-php]

 ID:   20658
 User updated by:  [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Linux 2.4.19-pre4
 PHP Version:  4CVS-2002-11-26 (stable)
 New Comment:

Closing...


Previous Comments:


[2002-11-28 23:25:56] [EMAIL PROTECTED]

Seems to be fixed now, thanks for the help.



[2002-11-26 17:02:17] [EMAIL PROTECTED]

Yep. I found a bug in error reporting code while investigating
array_walk() and fixed it. Now please try the latest one and it will
give you a bit more useful information, I suppose.



[2002-11-26 16:48:36] [EMAIL PROTECTED]

The one I tried and quoted in the bug report was less than 2 hours old
at the time of the reporting.

Has anything changed between then and now?



[2002-11-26 15:38:46] [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-11-26 13:41:48] [EMAIL PROTECTED]

I get a segfault after calling array_walk, in this portion of a
script:

function get_flat($packageid = 0) {
if ($packageid == $this->lastflatid)
return $this->flat;
$this->lastflatid = $packageid;
$this->flat = array();
array_walk(&$this->tree[$packageid], array(&$this,
"get_flat_callback"));
return $this->flat;
}

function get_flat_callback($val, $key) {
if (is_array($val)) {
if (is_int($key))
$this->flat[$key] =& $val;
array_walk(&$val, array(&$this, "get_flat_callback"));
}
}

The entire script can be viewed here:

http://dali.deviantart.com/~chris/themetree.phps

For some odd reason, this code is called twice in the page, however the
bug only manifests itself the second time the function is called (which
was why I added the first three lines of get_flat() as a temporary
workaround) however it is completely reproducible. I could also
reproduce it in 4.2.2, and it printed an error message to the php
error_log:

[26-Nov-2002 10:16:31] PHP Warning:  Unable to call (null)() - function
does not exist in /www/shared/themetree.php on line 67

A backtrace from a snapshot from an hour or two ago is below:

Program received signal SIGSEGV, Segmentation fault.
0x4038fd10 in xbuf_format_converter (xbuf=0xbfff9a78,
fmt=0x403ddd60 "Unable to call %s() - function does not exist",
ap=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/spprintf.c:438
438 s_len =
strlen(s);
(gdb) bt
#0  0x4038fd10 in xbuf_format_converter (xbuf=0xbfff9a78,
fmt=0x403ddd60 "Unable to call %s() - function does not exist",
ap=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/spprintf.c:438
#1  0x403902e1 in vspprintf (pbuf=0xbfff9ad8, max_len=0,
format=0x403ddd60 "Unable to call %s() - function does not exist",
ap=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/spprintf.c:622
#2  0x4038c3cc in php_verror (docref=0x0, params=0x403e9f93 "",
type=2,
format=0x403ddd60 "Unable to call %s() - function does not exist",
args=0xbfff9b30) at
/home/chris/php4-STABLE-200211261830/main/main.c:399
#3  0x4038c723 in php_error_docref0 (docref=0x0, type=2,
format=0x403ddd60 "Unable to call %s() - function does not exist")
at /home/chris/php4-STABLE-200211261830/main/main.c:484
#4  0x403178bb in php_array_walk (target_hash=0x81ca984, userdata=0x0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:983
#5  0x403179fd in zif_array_walk (ht=2, return_value=0x8254c8c,
this_ptr=0x0,
return_value_used=0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:1023
#6  0x403cb211 in execute (op_array=0x8254b7c)
at /home/chris/php4-STABLE-200211261830/Zend/zend_execute.c:1598
#7  0x403aff76 in call_user_function_ex (function_table=0x8253a00,
object_pp=0x8209a68, function_name=0x8253644,
retval_ptr_ptr=0xbfffa1a8,
param_count=2, params=0xbfffa1c0, no_separation=0,
symbol_table=0x0)
at
/home/chris/php4-STABLE-200211261830/Zend/zend_execute_API.c:557
#8  0x40317889 in php_array_walk (target_hash=0x824e4c4, userdata=0x0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:978
#9  0x403179fd in zif_array_walk (ht=2, return_value=0x825547c,
this_ptr=0x0,
return_value_used=0)
at /home/chris/php4-STABLE-200211261830/ext/standard/array.c:1023
#10 0x403cb211 in execute (op_array=0x8254b7c)
at /home/chris/php4-STABLE-20

#20700 [Opn->Bgs]: Boolean worked, but Integer..?

[sniper]

 ID:   20700
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: RedHat Linux 7.x
 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-11-28 09:28:04] [EMAIL PROTECTED]

Update: By the way...the entry in the database is "12", not 18, and not
8212...hmm



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

Hey,

I`m using the $_SESSION array at all my session stuff,
Now is the first time at the actual script that i need to store a
integer in the session.

I did this:

$_SESSION[uid] = $result[uid];

echo $result[uid];
echo $_SESSION[uid];

Both returned "18".

Now as I tried to echo the var again, It outputs "8212".

I`ve tried to find any error at my script (maybe an access or change to
the $_SESSION[uid] field...but nothing found).

Maybe this is a bug?

I`m a little bit confused now, because $_SESSION array should be used
at best, and It doesn`t work :-(

BTW, The fieldtype in the mysql db is 'TINYINT'

Any idea?




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