#28240 [Opn->Bgs]: class member assigment without declaration defines new member

2004-05-04 Thread derick
 ID:   28240
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at jort dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Class/Object related
 Operating System: Win2000 Pro
 PHP Version:  5.0.0RC2
 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:


[2004-05-04 05:51:30] phpbug at gb404 dot com

It is totally normal.

As far as I can remember, PHP never needed to declare a variable before
using it.



[2004-04-30 22:30:09] php at jort dot net

Description:

When you assign a value to a class member that was not declared the
system defines a new class member.
I'm not sure this is a feature or a bug.
I would expect an error or at least a notice or a warning.

Reproduce code:
---
foo = "test";
 }
}

$bar = new foo();

print $bar->foo;

?>


Expected result:

Notice/Warning/Error

Actual result:
--
test





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


#28270 [Opn->Bgs]: any call to error_log(...) crashes - revisited

2004-05-04 Thread derick
 ID:   28270
 Updated by:   [EMAIL PROTECTED]
 Reported By:  leha2 at mail dot ru
-Status:   Open
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Win32 (in my case WinXPPro+SP1)
 PHP Version:  4.3.6
 New Comment:

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

Thank you for your interest in PHP.

Reopen the old report, NEVER refile an existing bug please.


Previous Comments:


[2004-05-04 07:30:22] leha2 at mail dot ru

Description:

This report is just a reminder about "Bug #16787any call to
error_log(...) crashes", that was posted to bugtrace two years ago.
I've added a comment there with description of troubles I've encounter
after migrating from PHP v.4.1.0 to 4.3.5, and then to 4.3.6.
Quick URL for viewing that post is:
http://bugs.php.net/bug.php?id=16787

Thanks for help in advance,
LeXa2

Reproduce code:
---
Here is a fragment of modified FastTemplate class, where the trouble
was first encountered:
function show_unknowns ($Line)
{
$unknown = array();
if (ereg("({[A-Z0-9_]+})",$Line,$unknown))
{
$UnkVar = $unknown[0];
if(!(empty($UnkVar)))
{
this is the trouble line =>  
@error_log("[FastTemplate] Warning: no value found for variable:
$UnkVar ",0);
}
}
}// end show_unknowns()


Expected result:

just to log error as usual

Actual result:
--
PHP stalls and I have to kill it's process via Task Manager. After that
I got 500 Internal Server Error (not surprising, really ;)





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


#28175 [Com]: compile failure

2004-05-04 Thread paul dot gardiner at barleychalu dot co dot uk
 ID:   28175
 Comment by:   paul dot gardiner at barleychalu dot co dot uk
 Reported By:  martin dot kenney at i2net dot com
 Status:   Feedback
 Bug Type: Compile Failure
 Operating System: slackware 9.1, 2.4.25 kernel
 PHP Version:  4.3.6
 New Comment:

Iliaa,

I looked at your patch to gdft.c and modified it as there was a ')'
missing from the end of the main line and it needed repeating further
down in the file. Once this was applied it compiled OK :)

I've included a basic diff below.

Thanks,
- Paul -

476c476
< #if (defined(FREETYPE_MAJOR) && (FREETYPE_MAJOR >=2 ) &&
(FREETYPE_MINOR >= 1))
---
> #if (defined(FREETYPE_MAJOR) && ((FREETYPE_MAJOR == 2 &&
((FREETYPE_MINOR == 1 && FREETYPE_PATCH >= 3) || FREETYPE_MINOR > 1) ||
FREETYPE_MAJOR > 2)))
485c485
< #endif /* Freetype 2.1 or better */
---
> #endif /* Freetype 2.1.3 or better */
973c973
< #if (defined(FREETYPE_MAJOR) && (FREETYPE_MAJOR >=2 ) &&
(FREETYPE_MINOR >= 1))
---
> #if (defined(FREETYPE_MAJOR) && ((FREETYPE_MAJOR == 2 &&
((FREETYPE_MINOR == 1 && FREETYPE_PATCH >= 3) || FREETYPE_MINOR > 1) ||
FREETYPE_MAJOR > 2)))
983c983
< #endif /* Freetype 2.1 or better */
---
> #endif /* Freetype 2.1.3 or better */


Previous Comments:


[2004-04-29 15:25:13] [EMAIL PROTECTED]

Try the following patch: http://ilia.ws/stuff/gd.txt 



[2004-04-28 14:37:01] paul dot gardiner at barleychalu dot co dot uk

I get the same on redhat 8. Removing the --with-freetype-dir=/usr from
configure results in a successful compile. It used to work on 4.3.5.
I'd guess it would probably be the upgrade of the bundled gd. Not had
time to take a proper look though.



[2004-04-27 03:53:07] martin dot kenney at i2net dot com

Description:

./configure  --prefix=/usr/php --with-apxs=/usr/sbin/apxs
--with-openssl=/usr --enable-sigchild --enable-libgcc --enable-bcmath
--with-bz2=/usr --enable-calendar --enable-ctype --enable-dba=shared
--enable-gdbm=/usr --enable-ndbm=/usr --enable-db2=/usr
--enable-db3=/usr --enable-dbase --with-zlib --enable-ftp
--with-mhash=/usr/local --with-gd --with-jpeg-dir=/usr
--with-png-dir=/usr --with-mysql=/usr/local --with-pgsql=/usr/local
--enable-shmop --enable-sockets --enable-inline-optimization
--enable-sysvsem --enable-sysvshm --enable-wddx --with-gnu-ld
--with-gettext --with-freetype-dir=/usr --enable-gd-native-ttf

when making this is where error starts

/bin/sh /usr/local/src/servers/php-4.3.6/libtool --silent
--preserve-dup-deps --mode=compile gcc
-I/usr/local/src/servers/php-4.3.6/ext/gd/libgd -DHAVE_LIBPNG
-DHAVE_LIBJPEG -DHAVE_LIBFREETYPE -Iext/gd/
-I/usr/local/src/servers/php-4.3.6/ext/gd/ -DPHP_ATOM_INC
-I/usr/local/src/servers/php-4.3.6/include
-I/usr/local/src/servers/php-4.3.6/main
-I/usr/local/src/servers/php-4.3.6
-I/usr/local/src/servers/php-4.3.6/Zend -I/usr/include/freetype2
-I/usr/local/include -I/usr/local/include/mysql
-I/usr/local/src/servers/php-4.3.6/ext/xml/expat 
-I/usr/local/src/servers/php-4.3.6/TSRM  -g -O2  -prefer-pic -c
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c -o
ext/gd/libgd/gdft.lo
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c: In function
`fontFetch':
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:478:
`FT_ENCODING_MS_SYMBOL' undeclared (first use in this function)
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:478: (Each
undeclared identifier is reported only once
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:478: for each
function it appears in.)
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:479:
`FT_ENCODING_ADOBE_CUSTOM' undeclared (first use in this function)
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:479:
`FT_ENCODING_ADOBE_STANDARD' undeclared (first use in this function)
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c: In function
`gdImageStringFTEx':
/usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:974:
`FT_ENCODING_MS_SYMBOL' undeclared (first use in this function)
make: *** [ext/gd/libgd/gdft.lo] Error 1

version of gd: gd-2.0.3
./configure --prefix /usr

tried going back to php-4.3.4 and compiles fine with same ./configure
listed above






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


#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting

2004-05-04 Thread gaida at gmxpro dot net
 ID:   26286
 Comment by:   gaida at gmxpro dot net
 Reported By:  igg10 at alu dot ua dot es
 Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: Windows 2000
 PHP Version:  4.3.4
 New Comment:

Apache: Apache 2.0.49 (Win32)
PHP   : PHP 4.3.6
MySQL : MySQL 4.0.14-NT
OS: Windows XP Pro SP1

Server crashes only (Parent: child process exited with status
3221225477 -- Restarting.) when Turck MMCache (version 2.4.6 for php
4.3.6) is enabled and JPGraph generated images were accessed. If
mmcache is disabled in php.ini (mmcache.enable="0") everythings runs a
lot slower but at least without crashes.


Previous Comments:


[2004-05-01 06:38:56] peter at helpnet dot com dot au

I get both
Parent: child process exited with status 3221225477
and
Parent: child process exited with status 1073807364
alternating in a seemingly random order.

Win2000.
Apache 2 2.0.47. I am about to try 2.0.49.
PHP 4.3.4 then 4.3.6. I upgraded to 4.3.6 but it did not solve the
problem.

I get the error in code using XML but not MySQL. The error first
occurred when I opened lots of classes and created lots of objects.
Each element in a small XML file became an object which in turn may
include other objects. Some objects are from classes extending
classes.

I figured it might be a memory problem so extended memory from 8MB to
18 MB. That did not change anything.

My next guess was a file open resource problem. Some of the objects
read directories to count input files. I removed some of the files to
decrease files within a directory. That did not work. I can understand
that as I have had 10 or more files in one directory and the script
has worked. My tests are currently using less than 100 files per
directory.

I removed some of the directories but that did not stop the problem. I
removed some of the lower level directories and that stopped the
problem for a while. There appears to be a resource issue when working
down through a directory tree several levels.

I added print statements to trace the execution. Adding lots of print
statements made the problem happen faster but on some occasions I have
used many more print statements without this problem.

The print statements did not always print up to where the code stopped
so I added file logging. Opening output files made the problem worse.
That reinforces the idea that there is a resource problem.

I set the log code to open, write to, and close a log file. At first
that worked. As soon as I run xml_parser_free, the file logging stops.
The file log code can write the next message but no more. After that it
can open and write to the file but not close the file.

This error occurs with modpython and some other Apache stuff. I think
we are hitting a resource limit within Apache. Neither PHP nor Apache
has code to detect the problem.



[2004-04-19 08:39:10] cpuidle at gmx dot de

Windows error reporting mentions:
szModName: php5ts.dll
szModVer:  5.0.0.0
offset:00052dc6

Can provide full memory dump from winXP error reporting on request (12m
unzipped).

Cheers,
Andi



[2004-04-19 07:34:56] cpuidle at gmx dot de

Same issue for me, using Apache 2.0.49, PHP5RC1
Seems to be happening in conjunction with MySQL?



[2004-04-09 09:51:28] hagen at xiag dot ch

The same on WindowsXP SP1,
PHP 5RC1 as a module on Apache 2.0.48.



[2004-04-08 20:44:45] colstrom at dxlab dot com

I am running into the same problem, with the following configuration:

Windows XP SP1
Apache 2.0.47
PHP 4.3.4

In an attempt to correct this, I upgraded to the following:

Apache 2.0.49
PHP 4.3.5

And yet the problem persists. As for scripts, I am running a very
heavily hacked phpBB-v2.0.6, and dotProject-v1.0.2. I have tried the
aforementioned fix of turning register_globals ON, and still the error
persists.

What am I doing wrong?



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

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


#28220 [Opn]: mb_strwidth() returns wrong width values for some Hangul characters.

2004-05-04 Thread martin dot t dot kutschker at blackbox dot net
 ID:  28220
 User updated by: martin dot t dot kutschker at blackbox dot net
 Reported By: martin dot t dot kutschker at blackbox dot net
 Status:  Open
 Bug Type:mbstring related
 PHP Version: Irrelevant
 New Comment:

I rechecked EastAsianWidth and have found two more wide chars and
noticed that the range 2E80..4DB5 is in fact split by a single
half-width filler space char

1100..115F  Hangul Choseong
2329LEFT-POINTING ANGLE BRACKET
232ARIGHT-POINTING ANGLE BRACKET
2E80-303E   CJK and Kangxi radicals, ideographic chars
3041-4DB5   Hiragana, Katakana, Bopomofo and Hangul letters
4E00..D7A3  CJK ideographs, Yi and Hangul syllables
F900..FA6A  CJK compatibiliy ideographs
FE30..FE6B  presentation forms, punctuations, etc.
FF01..FF60  full-width Latin letters
FFE0FULLWIDTH CENT SIGN
FFE1FULLWIDTH POUND SIGN
FFE2FULLWIDTH NOT SIGN
FFE3FULLWIDTH MACRON
FFE4FULLWIDTH BROKEN BAR
FFE5FULLWIDTH YEN SIGN
FFE6FULLWIDTH WON SIGN

Please also note that Unicode knows about "ambigous" (A) chars. See
quotes from http://www.unicode.org/reports/tr11/

"In a broad sense, wide characters include W, F, and A (when in EA
context), 
 while narrow characters include N, Na, H, and A (when not in EA
context)."

"Ambiguous characters behave like wide or narrow characters depending
on 
 context (language tag, script identification, associated font, source
of 
 data, or explicit markup; all can provide the context). If the context

 cannot be established reliably they should be treated as narrow
characters 
 by default."

So mb_strwidth could try to auto-detect the context (eg. by locale) or
have an optional east-asian context argument.


Previous Comments:


[2004-05-01 15:30:09] [EMAIL PROTECTED]

This is a valid bug.
# thanks Nuno.




[2004-04-29 18:48:17] martin dot t dot kutschker at blackbox dot net

Description:

The table describing the width of the characters is wrong if you
compare it with the table for Unicode 4.0:

http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt

For the BMP the wide/full-width chars are:

1100..115F  Hangul Choseong
2E80..4DB5  CJK radicals and CJK Ideograph Extension A
4E00..D7A3  CJK Ideographs, Yi syll. and Hangul syll.
F900..FA6A  CJK compatibiliy ideographs
FE30..FE6B  presentation forms, punctuations, etc.
FF01..FF60  full-width Latin letters
FFE0FULLWIDTH CENT SIGN
FFE1FULLWIDTH POUND SIGN
FFE2FULLWIDTH NOT SIGN
FFE3FULLWIDTH MACRON
FFE4FULLWIDTH BROKEN BAR
FFE5FULLWIDTH YEN SIGN
FFE6FULLWIDTH WON SIGN

I didn't check what the actual implementation does, but the docs are
certainly wrong (if they mean Unicoe codepoints).






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


#28265 [Bgs->Opn]: Realpath, getcwd not returning true pathname

2004-05-04 Thread csaba at alum dot mit dot edu
 ID:   28265
 User updated by:  csaba at alum dot mit dot edu
 Reported By:  csaba at alum dot mit dot edu
-Status:   Bogus
+Status:   Open
 Bug Type: Directory function related
 Operating System: Windows - all
-PHP Version:  5CVS-2004-05-03 (dev)
+PHP Version:  5CVS-2004-05-04 (dev)
 New Comment:

This problem is still happening on the latest snapshot of PHP I just
downloaded today (2004-May-04).  If I run the code I included below on
my Win 2000 Pro system, I get three sections, each with distinct
capitalization (mixed, lower case, upper case) of the drive letter and
trailing directory (the inner parts all match up with mixed case).  All
5 lines should appear identical (in mixed case).  This is expecially
noticable on a browser page where you have proportional fonts.

Csaba Gabor

Also, that old bug report (17822) functionally does not exist - it's
been lost (at least large parts of it).  If google can't see it, and I
can't find it by searching, and PHP can't find it by searching (when I
submit almost the same report), I'd call that lost.  So in my book,
it's not a duplicate report.  And what should I do then?


Previous Comments:


[2004-05-04 08:55:57] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

It\'s also fixed.



[2004-05-04 00:07:53] csaba at alum dot mit dot edu

Description:

I am resubmitting this bug report (#17822) since the previous report
seems to have been corrupted and all the developer comments gone
missing!  The bug is still there, too:

[18 Jun 2002 6:20pm CEST] csaba at alum dot mit dot edu 
realpath and getcwd on Windows systems do not actually report the
applicable directory, but rather a string that will !strcasecmp() with
the true directory:

I have a directory name, $dir, on my Win2K system (PHP 4.2.0), but it's
in all lower case, and I'd like to get the actual pathname including
the capitalizations: 

Both realpath() and dirname() only muck around with the $dir string and
don't hit the file system. Not only that, but getcwd() returns $dir
(sans capitalizations) after I've hopped over to it with chdir($dir)! 

My only solution to this point is to pop up a level and use
readdir(...) but this is wasteful, only giving me one level at a time.
Isn't there a REAL realpath() for windows? 

Thanks, 
Csaba Gabor


[27 Jul 2002 11:45am CEST] [EMAIL PROTECTED] 
Looked into this, it looks possible to implement.  Wish me luck :)

[10 Oct 2002 10:47pm CEST] [EMAIL PROTECTED] 
Any news?

[27 Oct 2002 7:27pm CET] [EMAIL PROTECTED] 
This bug has been fixed in CVS.

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

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


[15 Feb 2003 5:38pm CET] csaba at alum dot mit dot edu 
I have marked this bug as open because of the demonstration below on my
PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro
system.

Here is the test:
getcwd Problem
" . getcwd();
print "" . realpath(getcwd());
chdir (strtoupper($cwd));
print "" . getcwd();
print "" . realpath(getcwd());
?>


On my system the first 2 directories show in lower case,
the last two are in caps.
Csaba

[15 Feb 2003 7:32pm CET] [EMAIL PROTECTED] 
Please try using this CVS snapshot:

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

Cannot replicate using latest CVS.

[22 Feb 2003 8:03pm CET] [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.


[23 Apr 12:26am CEST] csaba at alum dot mit dot edu 
I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my
Win 2K Pro system and it is still a problem.  Here are the outputs that
I get (I did an inititial print right after the first cwd() so you can
see what windows thinks the directory is):

C:\Morph\phpDev\40gNiKU5LQ0C

c:\Morph\phpDev\40gniku5lq0c
c:\Morph\phpDev\40gniku5lq0c

C:\Morph\phpDev\40GNIKU5LQ0C
C:\Morph\phpDev\40GNIKU5LQ0C 

So it appears that the middle part is OK but the drive letter and the
final directory 

#28271 [NEW]: proc_open.c:753: error: `TIOCNOTTY' undeclared

2004-05-04 Thread admin at iut-info dot ens dot univ-reims dot fr
From: admin at iut-info dot ens dot univ-reims dot fr
Operating system: HP-UX 11i
PHP version:  5.0.0RC2
PHP Bug Type: Compile Failure
Bug description:  proc_open.c:753: error: `TIOCNOTTY' undeclared

Description:

On HP-UX 11i compilation of PHP-5.0.0RC failed (Ok until
/php5-200403131230)

./configure \
--prefix=/opt/APACHE/php\
--without-sqlite\
--with-oci8 \
--with-apache=../apache_1.3.29  \
--with-gd   \
--with-pdflib=/opt/pdflib   \
--with-jpeg-dir=/usr/local  \
--with-png-dir=/usr/local   \
--with-tiff-dir=/usr/local  \
--with-freetype-dir=/usr/local  \
--with-zlib \
--with-bz2  \
--enable-sigchild   \
--with-mysql=/opt/mysql \
--with-pgsql=/opt/pgsql \
--with-tsrm-pthreads\
--with-dom  \
--with-libxml   \
--with-xsl  \
--enable-ftp\
--with-snmp=/usr/local  \
--with-imap=/usr/local/imap \
--with-imap-ssl=/usr/local  \
--with-openssl=/usr/local   \
--enable-sockets

Make failed with :
gcc  -Iext/standard/
-I/home/sys/install/php-5.0.0RC2/ext/standard/ -DPHP_ATOM_INC
-I/home/sys/install/php-5.0.0RC2/include
-I/home/sys/install/php-5.0.0RC2/main -I/home/sys/install/php-5.0.0RC2
-I/home/sys/install/php-5.0.0RC2/Zend -I/usr/local/include/libxml2
-I/usr/local/include -I/usr/local/include/freetype2
-I/usr/local/imap/include -I/opt/mysql/include/mysql
-I/oracle/app/oracle/product/8.1.7/rdbms/public
-I/oracle/app/oracle/product/8.1.7/rdbms/demo -I/opt/pdflib/include
-I/opt/pgsql/include  -I/home/sys/install/php-5.0.0RC2/TSRM  -g -O2  -c
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c -o
ext/standard/proc_open.o  && echo > ext/standard/proc_open.lo
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c: In function
`zif_proc_open':
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error:
`TIOCNOTTY' undeclared (first use in this function)
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: (Each
undeclared identifier is reported only once
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: for
each function it appears in.)
*** Error exit code 1

-
Declaration of `TIOCNOTTY' is present in 

- Workaround 
Adding this declaration in proc_open.c is a temporary solution (build
successed).

---
Cordialy


-- 
Edit bug report at http://bugs.php.net/?id=28271&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28271&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28271&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28271&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28271&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28271&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28271&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28271&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28271&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28271&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28271&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28271&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28271&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28271&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28271&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28271&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28271&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28271&r=float


#11058 [Com]: php_network_getaddresses: getaddrinfo failed

2004-05-04 Thread jeppe at bundsgaard dot net
 ID:   11058
 Comment by:   jeppe at bundsgaard dot net
 Reported By:  pat at mail dot rit dot edu
 Status:   Bogus
 Bug Type: Network related
 Operating System: OpenBSD 2.6
 PHP Version:  4.0.6
 New Comment:

I guess it is connected to the server - the problem occurs on some, but
not all the servers running php4.3 that I am using. Anyway it would be
nice with a solution that solves the problem independent of the servers
- or that tells exactly what is to be done with the server (I know,
this is not the place for such a request - but I don't know where to
turn to).


Previous Comments:


[2004-02-12 21:15:45] cosas at minovela dot com

hello,
my php is PHP Version 4.3.4
i've exatctly the same problem. my server isn't conected by dialup, and
i got ever the message
"php_network_getaddresses: getaddrinfo failed"
when i use this line:
fsockopen ("dummy_ip", 25, &$errno, &$errstr, 10)

it didn't occurs with older versions of php.
this IS NOT a server problem, is a problem of PHP, you only need tho
make a search at google
http://www.google.es/search?hl=es&ie=UTF-8&oe=UTF-8&q=php+php_network_getaddresses%3A+getaddrinfo+failed&meta=
target "php_network_getaddresses: getaddrinfo failed"
and see results, a lot of people get the same errors.

i hope you found a solution for this :)



[2003-06-04 10:08:18] fcartegnie dot at dot free dot dot dot fr at null
dot null

Okay. I identified the problem.
When apache starts, php or apache gets dns servers entry
from /etc/resolv.conf
You're using a dialup connection and when logging in, your dns servers
have been added at this later moment.
So there's a problem with apache or php to get informed that the
content of resolv.conf has been updated.
Confirmed for PHP 4.3.1/apache_1.3.27 so.
Temporary solution is just to reload apache doing a apachectl
stop/start



[2002-04-03 16:27:07] g dot almasi at gigcity dot com

Well you can tell I had nothing to do today but beat my head against a
wall. But I found a solution!

I added my target site to /etc/hosts and restarted apache, and now I
can include a page in that target site from a different site.

It's Miller Time! 



[2002-04-03 16:20:32] [EMAIL PROTECTED]

And that is the cause of the problem (and the reason that
this report is set to bogus).
You need to tell your SuSE box how to resolve the addresses; the SuSE
yast tool should let you set the nameserver in it's network
configuration.
I can't help you any further here, and this is not the place to discuss
this further.  I'd suggest looking at the SuSE support database for
this: it's bound to be a FAQ.



[2002-04-03 15:58:04] g dot almasi at gigcity dot com

another note: I have root to another box (it serves about 20 sites to
the web) that is also running PHP 4.0.6 and php_network_getaddresses
works fine. Does this function require a nameserver? My SuSE 7.3 box is
a development machine on my LAN, so I just use proxies to get to it
with a browser. Getting DNS, BIND, and DHCP to work was beyond me when
I set it up (still is, actually). So I just use a proxy setting for
browsers while I build sites.



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

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


#19263 [Com]: huge POST data corrupt

2004-05-04 Thread richardks666 at hotmail dot com
 ID:   19263
 Comment by:   richardks666 at hotmail dot com
 Reported By:  erwin at isiz dot com
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Solaris 8
 PHP Version:  4CVS-2002-09-06
 New Comment:

Solved!
I removed /etc/httpd/conf.d/php.conf
and updated /etc/httpd/conf/httpd.conf with:
AddType application/x-httpd-php .php .phtml .phtm .inc .oc
and restarted the webserver, things were back to normal. Was quite
frustrating!


Previous Comments:


[2004-05-03 12:46:40] richardks666 at hotmail dot com

Hey

I am on Apache 2.0.40 using PHP5 RC2, experiencing the same problems as
you guys did. Going to try these solutions later on today, but I wanted
to tell  you that as seen, this problem exist in PHP5 RC2 as well.

If these are not the solutions to my problem, which I hope they are,
wrongly linked LIBJPEGs and other libraries might interfere. 

Last night I sniffed the data between the webserver and my dev.
computer, which showed that the instant I choose to upload my image
(depends on filetype of course), that the appropriate library is linked
and executed even there, and at the time, my PHP code hasn't been ran.
In my case the Header dump contained the libjpeg version 1 addon.

One might also wish to comment that, in conjunction with the original
post, I too receive very odd FORM data. The size is somewhat correct (
I didn't doublecheck ) but extra objects are posted, for instance if I
got an array of id[], then it might contain awkward data. Solution for
that was to simply attach a INPUT TYPE HIDDEN nameing it "dummy" or
something with a dummy value, now the objects are passed correctly.

Staying in touch



[2003-11-21 11:11:38] contact at creation-online dot net

Hi !!!

You really help me because I had the same problem with Apache 2 and Php
4.3.4

Now it works very good because of you solution ;-)

Best regards, Aurélien



[2003-11-19 08:38:43] grall at mit dot edu

You are right erwin about this bug.

The bug is in Apache 2.0.40
Possibly upgrading to a newer version will solve this.
In any case, using the 'AddType application/x-httpd-php .php' didn't
work for me, but instead I had to just insert
into my httpd.conf:


SetOutputFilter PHP
SetInputFilter PHP
LimitRequestBody 1024


Some people report that you have to choose between one or the other,
but in my case the second choice is the only one that works.
Incidentally, if you are using MulitViews (as I am), using the 
approach, Multiviews no longer works. This is more of an Apache
problem, but whatever, this thread is about that problem. Any
suggestions?



[2003-10-02 21:07:44] josantri at hotmail dot com

Same experience with RedHat 7.3, Apache 2.0.45 & PHP 4.3.1.
The solution was disabling MIME type for PHP (I don't see new problems
by now with this issue):

#AddType application/x-httpd-php .php

And now, leaving enabled filtering method, but be care with above
example or you get a 'Syntax error [...]:
AddInputFilter requires at least two arguments, input filter name (or ;
delimited names) followed by one or more file extensions' when Apache2
is restarted. The code we use is:


 AddInputFilter PHP .php
 AddOutputFilter PHP .php


(Note the field naming the extension.)

I'm not sure how enable filtering for *php.*, because AddInputFilter
and AddOutputFilter seems not to accept wildcards on extensions (in
files section definition is fine). Probably, independent definitions
for each extension will work as well.

Thanks to all of the above for help provided.



[2003-07-01 02:35:35] php at gijs dot triple-it dot nl

Hi,

On my configuration (RedHat 9.0, Apache 2.0.40, php-4.2.2), I had to
remove one of the following from the conf/httpd.conf or the
/conf.d/php.conf

AddType application/x-httpd-php .php4 .php3 .phtml .php

Or


SetOutputFilter PHP
SetInputFilter PHP
LimitRequestBody 1024


Either of these functions will work, but together they screw up and
create the problem as reported above.

Good Luck!

Gijs Zonneveld



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

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


#28271 [Opn->Csd]: proc_open.c:753: error: `TIOCNOTTY' undeclared

2004-05-04 Thread admin at iut-info dot ens dot univ-reims dot fr
 ID:   28271
 User updated by:  admin at iut-info dot ens dot univ-reims dot fr
 Reported By:  admin at iut-info dot ens dot univ-reims dot fr
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: HP-UX 11i
 PHP Version:  5.0.0RC2
 New Comment:

File is Ok in PHP5-200405041230


Previous Comments:


[2004-05-04 14:33:09] admin at iut-info dot ens dot univ-reims dot fr

Description:

On HP-UX 11i compilation of PHP-5.0.0RC failed (Ok until
/php5-200403131230)

./configure \
--prefix=/opt/APACHE/php\
--without-sqlite\
--with-oci8 \
--with-apache=../apache_1.3.29  \
--with-gd   \
--with-pdflib=/opt/pdflib   \
--with-jpeg-dir=/usr/local  \
--with-png-dir=/usr/local   \
--with-tiff-dir=/usr/local  \
--with-freetype-dir=/usr/local  \
--with-zlib \
--with-bz2  \
--enable-sigchild   \
--with-mysql=/opt/mysql \
--with-pgsql=/opt/pgsql \
--with-tsrm-pthreads\
--with-dom  \
--with-libxml   \
--with-xsl  \
--enable-ftp\
--with-snmp=/usr/local  \
--with-imap=/usr/local/imap \
--with-imap-ssl=/usr/local  \
--with-openssl=/usr/local   \
--enable-sockets

Make failed with :
gcc  -Iext/standard/
-I/home/sys/install/php-5.0.0RC2/ext/standard/ -DPHP_ATOM_INC
-I/home/sys/install/php-5.0.0RC2/include
-I/home/sys/install/php-5.0.0RC2/main -I/home/sys/install/php-5.0.0RC2
-I/home/sys/install/php-5.0.0RC2/Zend -I/usr/local/include/libxml2
-I/usr/local/include -I/usr/local/include/freetype2
-I/usr/local/imap/include -I/opt/mysql/include/mysql
-I/oracle/app/oracle/product/8.1.7/rdbms/public
-I/oracle/app/oracle/product/8.1.7/rdbms/demo -I/opt/pdflib/include
-I/opt/pgsql/include  -I/home/sys/install/php-5.0.0RC2/TSRM  -g -O2  -c
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c -o
ext/standard/proc_open.o  && echo > ext/standard/proc_open.lo
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c: In function
`zif_proc_open':
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error:
`TIOCNOTTY' undeclared (first use in this function)
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error:
(Each undeclared identifier is reported only once
/home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: for
each function it appears in.)
*** Error exit code 1

-
Declaration of `TIOCNOTTY' is present in 

- Workaround 
Adding this declaration in proc_open.c is a temporary solution (build
successed).

---
Cordialy






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


#28273 [NEW]: feof() doesn't return TRUE when invalid file handle is passed to it

2004-05-04 Thread mikeboulet at newfangled dot com
From: mikeboulet at newfangled dot com
Operating system: Redhat 7.2 or Redhat AS 2.1
PHP version:  4.3.4
PHP Bug Type: Filesystem function related
Bug description:  feof() doesn't return TRUE when invalid file handle is passed to it

Description:

When a fopen() is done on a file that has permissions that are set to not
allow the current process user to read it or the file doesn't exist it
returns false. This is expected. The problem is when feof() is fed the
invalid handle it doesn't return TRUE() thus creating an infinite loop in
the following code example. 


Reproduce code:
---


Expected result:

feof() would return TRUE to cancel the loop and the script would end.
There would of course be warnings because of the invalid file handle, but
that is expected.

There should be better error handling on the developers part and catch the
invalid file handle, but I would expect the file functions to handle this
situation accordingly.

Actual result:
--
Inifinite loop

-- 
Edit bug report at http://bugs.php.net/?id=28273&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28273&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28273&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28273&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28273&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28273&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28273&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28273&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28273&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28273&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28273&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28273&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28273&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28273&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28273&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28273&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28273&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28273&r=float


#28273 [Opn->Bgs]: feof() doesn't return TRUE when invalid file handle is passed to it

2004-05-04 Thread abies
 ID:   28273
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mikeboulet at newfangled dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Redhat 7.2 or Redhat AS 2.1
 PHP Version:  4.3.4
 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.

feof() does exactly what it's supposed to. 


Previous Comments:


[2004-05-04 15:58:52] mikeboulet at newfangled dot com

Description:

When a fopen() is done on a file that has permissions that are set to
not allow the current process user to read it or the file doesn't exist
it returns false. This is expected. The problem is when feof() is fed
the invalid handle it doesn't return TRUE() thus creating an infinite
loop in the following code example. 


Reproduce code:
---


Expected result:

feof() would return TRUE to cancel the loop and the script would end.
There would of course be warnings because of the invalid file handle,
but that is expected.

There should be better error handling on the developers part and catch
the invalid file handle, but I would expect the file functions to
handle this situation accordingly.

Actual result:
--
Inifinite loop





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


#28273 [Bgs]: feof() doesn't return TRUE when invalid file handle is passed to it

2004-05-04 Thread mikeboulet at newfangled dot com
 ID:   28273
 User updated by:  mikeboulet at newfangled dot com
 Reported By:  mikeboulet at newfangled dot com
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Redhat 7.2 or Redhat AS 2.1
 PHP Version:  4.3.4
 New Comment:

I argue that it is a bug and that it was already addressed in a similar
problem 

see http://bugs.php.net/bug.php?id=25939.

Basically while in the while( feof() ) loop the socket goes away due to
network failure and the stream is no longer there. This causes an
infinite loop in 4.3.4 because feof() would not return TRUE. In 4.3.5
they changed this behavior to return TRUE on socket failure. This would
be similar to saying the file handle is not valid and there is nothing
there feof() thus we are at the end of nothing. I guess you could say
we are at begining of nothing.

I understand this is more of a symantics issue than a bug. If you
google 'feof infinite php' you will see that there are a lot of people
that get stung by this issue. Maybe it should be changed to get around
a common problem.

What do you think?


Previous Comments:


[2004-05-04 16:46: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.

feof() does exactly what it\'s supposed to. 



[2004-05-04 15:58:52] mikeboulet at newfangled dot com

Description:

When a fopen() is done on a file that has permissions that are set to
not allow the current process user to read it or the file doesn't exist
it returns false. This is expected. The problem is when feof() is fed
the invalid handle it doesn't return TRUE() thus creating an infinite
loop in the following code example. 


Reproduce code:
---


Expected result:

feof() would return TRUE to cancel the loop and the script would end.
There would of course be warnings because of the invalid file handle,
but that is expected.

There should be better error handling on the developers part and catch
the invalid file handle, but I would expect the file functions to
handle this situation accordingly.

Actual result:
--
Inifinite loop





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


#28274 [NEW]: register_globals removal petiton

2004-05-04 Thread raniz at gmx dot net
From: raniz at gmx dot net
Operating system: All
PHP version:  4.3.6
PHP Bug Type: Feature/Change Request
Bug description:  register_globals removal petiton

Description:

As register_globals does create som security issues, and therefore is
recommended to be turned off. I think it would be for the best if it was
removed completely in the future.

It also seems like register_globals is causing a lot of trouble for coders
new to PHP (at least on the forums I hang). And I think many of them would
disappear if register_globals were to be removed.

I'm not saying I wan't an immediate removal, marking it as deprecated in
the manual and removing it in a few versions would probably be the best.

/Raniz


-- 
Edit bug report at http://bugs.php.net/?id=28274&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28274&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28274&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28274&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28274&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28274&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28274&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28274&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28274&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28274&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28274&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28274&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28274&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28274&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28274&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28274&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28274&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28274&r=float


#28274 [Opn->WFx]: register_globals removal petiton

2004-05-04 Thread derick
 ID:   28274
 Updated by:   [EMAIL PROTECTED]
 Reported By:  raniz at gmx dot net
-Status:   Open
+Status:   Wont fix
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.3.6
 New Comment:

That's not going to happen.


Previous Comments:


[2004-05-04 17:27:48] raniz at gmx dot net

Description:

As register_globals does create som security issues, and therefore is
recommended to be turned off. I think it would be for the best if it
was removed completely in the future.

It also seems like register_globals is causing a lot of trouble for
coders new to PHP (at least on the forums I hang). And I think many of
them would disappear if register_globals were to be removed.

I'm not saying I wan't an immediate removal, marking it as deprecated
in the manual and removing it in a few versions would probably be the
best.

/Raniz






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


#28261 [Opn->Csd]: Lifting reserved keyword restriction for method names

2004-05-04 Thread helly
 ID:   28261
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Philippe dot Jausions at 11abacus dot com
-Status:   Open
+Status:   Closed
 Bug Type: Class/Object related
-Operating System: Irrelevant
+Operating System: *
-PHP Version:  Irrelevant
+PHP Version:  *
 New Comment:

That's simply impossible.


Previous Comments:


[2004-05-03 17:36:00] Philippe dot Jausions at 11abacus dot com

Description:

Suggestion:

Wouldn't it be possible to lift the reserved keyword restriction for
method names?

It seems to me that there shouldn't be any namespace conflict with the
core PHP language.

Reproduce code:
---


Actual result:
--
Parse error: parse error, unexpected T_EVAL, expecting T_STRING





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


#28222 [Opn->Csd]: DBX module should be bundled

2004-05-04 Thread helly
 ID:   28222
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rycamor at brainscraps dot com
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
-Operating System: all
+Operating System: *
-PHP Version:  5CVS-2004-04-29 (dev)
+PHP Version:  *
 New Comment:

Version 4.3 is a stable version where we do not do further featzre
changes.

PHP 5.0 is in feature freeze mode too. But there is a new database
abstraction extension in development. It may be ready for PHP 5.1. So
please be patient.


Previous Comments:


[2004-05-03 09:09:05] [EMAIL PROTECTED]

I've changed this from bogus=>open as amt misunderstood the feature
request.
Feel free to close this with a valid reason (or actually bundle it, but
then, I'm biased :)

BTW, the dbx version in cvs already contains support for SQLite.




[2004-04-29 23:21:46] rycamor at brainscraps dot com

Thanks, but I think I am being misunderstood here: SQLite is a
stand-alone DBMS, which definitely has its place, but is not at all in
the same problem domain as a database abstraction layer to allow
unified methods for interacting with various server-based database
systems. (http://php.net/dbx). My point is, at present PHP has no
existing *built-in* standardization of database access. DBX is already
available, it is a well-tested solution, and it is a very small
addition to the standard PHP build, because it is really a thin layer
over the existing database modules.

DBX has only a few functions, but these functions are all that is
really needed for true relational DBMS interaction, because all serious
logic should be handled on the database side. Also, by default DBX
returns all results in object form, making it a natural for the strong
OO capabilities of PHP5.

As a long-time user of PHP (since 1999), I strongly urge the PHP
development team to consider this.



[2004-04-29 22:34:30] [EMAIL PROTECTED]

Thanks for the suggestion. We've actually decide to go 
with SQLite instead. See http://www.php.net/sqlite.



[2004-04-29 22:07:43] rycamor at brainscraps dot com

Description:

Please make the dbx database abstraction module part of the default PHP
build. There are many library developers who would like to start using
dbx, but they cannot, because they don't know if the user has built PHP
with dbx.

I'm well aware that there are other abstraction libraries, but dbx is
very simple, fast, and covers all standard interaction needs for a
relational DBMS. Personally, I and many developers prefer it to the
(overly) complex ones like PEAR:DB or ADODB.

I think it would be a great benefit to the PHP project if a simple,
straightforward, universal database module can be used anywhere, and
dbx gets my vote.

Thank you,

Rick Morris






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


#28275 [NEW]: mktime() b0rked for 4-4-YYYY

2004-05-04 Thread escot001 at student dot ucr dot edu
From: escot001 at student dot ucr dot edu
Operating system: FreeBSD 4.9-STABLE
PHP version:  4.3.5
PHP Bug Type: Calendar related
Bug description:  mktime() b0rked for 4-4-

Description:

When feeding mktime() the parameters 4 for month, 4 for date, and any
year, the begining of the UNIX epoch is returned.

Reproduce code:
---
");
   }
   $d = 00;
}
?>


Expected result:

03-22-2010
03-23-2010
03-24-2010
03-25-2010
03-26-2010
03-27-2010
03-28-2010
03-29-2010
03-30-2010
03-31-2010
04-01-2010
04-01-2010
04-02-2010
04-03-2010
04-04-2010
04-05-2010
04-06-2010
04-07-2010
04-08-2010
04-09-2010
04-10-2010
04-11-2010
04-12-2010
04-13-2010
04-14-2010
04-15-2010
04-16-2010
04-17-2010
04-18-2010
04-19-2010
04-20-2010
04-21-2010
04-22-2010
04-23-2010


Actual result:
--
03-22-2010
03-23-2010
03-24-2010
03-25-2010
03-26-2010
03-27-2010
03-28-2010
03-29-2010
03-30-2010
03-31-2010
04-01-2010
04-01-2010
04-02-2010
04-03-2010
12-31-1969
04-05-2010
04-06-2010
04-07-2010
04-08-2010
04-09-2010
04-10-2010
04-11-2010
04-12-2010
04-13-2010
04-14-2010
04-15-2010
04-16-2010
04-17-2010
04-18-2010
04-19-2010
04-20-2010

-- 
Edit bug report at http://bugs.php.net/?id=28275&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28275&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28275&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28275&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28275&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28275&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28275&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28275&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28275&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28275&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28275&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28275&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28275&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28275&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28275&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28275&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28275&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28275&r=float


#28276 [NEW]: function rename stopped working after the last Windows update

2004-05-04 Thread motion4u at hotmail dot com
From: motion4u at hotmail dot com
Operating system: Windows 2000 Advanced
PHP version:  4.3.6
PHP Bug Type: Directory function related
Bug description:  function rename stopped working after the last Windows update

Description:

The function:
rename($oldname, $newname);
stopped working after the last windows update.
I'm using the rename Function to rename a directory

rename($oldname, $newname);

It doesn't work anymore... 
Before making a fool out of myself, I have double checked it.
If you think to answer that it might be that the directory is in use or a
file within it is open ... the answer is no! I have restarted the server
and the client and disconnected the internet plug for it.

Reproduce code:
---
just fill in the path to any subdirectory and call




-- 
Edit bug report at http://bugs.php.net/?id=28276&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28276&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28276&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28276&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28276&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28276&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28276&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28276&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28276&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28276&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28276&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28276&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28276&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28276&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28276&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28276&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28276&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28276&r=float


#28275 [Opn->Bgs]: mktime() b0rked for 4-4-YYYY

2004-05-04 Thread escot001 at student dot ucr dot edu
 ID:   28275
 User updated by:  escot001 at student dot ucr dot edu
 Reported By:  escot001 at student dot ucr dot edu
-Status:   Open
+Status:   Bogus
 Bug Type: Calendar related
 Operating System: FreeBSD 4.9-STABLE
 PHP Version:  4.3.5
 New Comment:

fixed in 4.3.6, sorry guys.


Previous Comments:


[2004-05-04 19:07:37] escot001 at student dot ucr dot edu

Description:

When feeding mktime() the parameters 4 for month, 4 for date, and any
year, the begining of the UNIX epoch is returned.

Reproduce code:
---
");
   }
   $d = 00;
}
?>


Expected result:

03-22-2010
03-23-2010
03-24-2010
03-25-2010
03-26-2010
03-27-2010
03-28-2010
03-29-2010
03-30-2010
03-31-2010
04-01-2010
04-01-2010
04-02-2010
04-03-2010
04-04-2010
04-05-2010
04-06-2010
04-07-2010
04-08-2010
04-09-2010
04-10-2010
04-11-2010
04-12-2010
04-13-2010
04-14-2010
04-15-2010
04-16-2010
04-17-2010
04-18-2010
04-19-2010
04-20-2010
04-21-2010
04-22-2010
04-23-2010


Actual result:
--
03-22-2010
03-23-2010
03-24-2010
03-25-2010
03-26-2010
03-27-2010
03-28-2010
03-29-2010
03-30-2010
03-31-2010
04-01-2010
04-01-2010
04-02-2010
04-03-2010
12-31-1969
04-05-2010
04-06-2010
04-07-2010
04-08-2010
04-09-2010
04-10-2010
04-11-2010
04-12-2010
04-13-2010
04-14-2010
04-15-2010
04-16-2010
04-17-2010
04-18-2010
04-19-2010
04-20-2010





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


#8817 [Com]: $foo->getbar()->getfoobar()->method()

2004-05-04 Thread travis at codegoat dot com
 ID:   8817
 Comment by:   travis at codegoat dot com
 Reported By:  tenshi at cinter dot de
 Status:   Suspended
 Bug Type: Feature/Change Request
 Operating System: linux
 PHP Version:  4.0.4
 Assigned To:  andi
 New Comment:

I am just wondering if this will ever be brought out of `suspended` is
there any intention on putting this in?

If so, is there a timeline attached? I will assume there isn't , but it
would be awesome to have this functionality!


Previous Comments:


[2001-01-20 06:58:57] [EMAIL PROTECTED]

we know :)
it is not available yet 



[2001-01-19 22:24:46] tenshi at cinter dot de

Hi there.

It would imho be useful to be abeled to code
$foo->getbar()->getfoobar()->method();
instead of having to save each return value into a variable like:
$bar = $foo->getbar();
$foobar = $bar->getfoobar();
$foobar->method();

Thanx.




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


#8817 [Sus->Csd]: $foo->getbar()->getfoobar()->method()

2004-05-04 Thread wez
 ID:   8817
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tenshi at cinter dot de
-Status:   Suspended
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: linux
 PHP Version:  4.0.4
 Assigned To:  andi
 New Comment:

Fixed in PHP 5.


Previous Comments:


[2004-05-04 20:47:48] travis at codegoat dot com

I am just wondering if this will ever be brought out of `suspended` is
there any intention on putting this in?

If so, is there a timeline attached? I will assume there isn't , but it
would be awesome to have this functionality!



[2001-01-20 06:58:57] [EMAIL PROTECTED]

we know :)
it is not available yet 



[2001-01-19 22:24:46] tenshi at cinter dot de

Hi there.

It would imho be useful to be abeled to code
$foo->getbar()->getfoobar()->method();
instead of having to save each return value into a variable like:
$bar = $foo->getbar();
$foobar = $bar->getfoobar();
$foobar->method();

Thanx.




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


#28277 [NEW]: Cannot laod /usr/lib/apache/libphp4.so into server : /usr/lib/apache/libphp4.so

2004-05-04 Thread belday at hotmail dot com
From: belday at hotmail dot com
Operating system: Linux Red Hat 7.2
PHP version:  4.3.6
PHP Bug Type: Apache related
Bug description:  Cannot laod /usr/lib/apache/libphp4.so into server : 
/usr/lib/apache/libphp4.so

Description:

Cannot laod /usr/lib/apache/libphp4.so into server :
/usr/lib/apache/libphp4.so: undefined symbol: ap_block_alarms

I get this error when i'm trying to start apache.
Any suggestions?



-- 
Edit bug report at http://bugs.php.net/?id=28277&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28277&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28277&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28277&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28277&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28277&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28277&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28277&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28277&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28277&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28277&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28277&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28277&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28277&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28277&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28277&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28277&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28277&r=float


#28084 [Com]: Crashes when fonts are accessed

2004-05-04 Thread dietrich dot ayala at foundstone dot com
 ID:   28084
 Comment by:   dietrich dot ayala at foundstone dot com
 Reported By:  doormat at sequence-omega dot net
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2000 SP3
 PHP Version:  4.3.6
 New Comment:

here is a simple reproduction script.

the crash only occurs when writing the image to file, and is
reproducible 100% of the time.




Previous Comments:


[2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com

another comment: this is a regression. our code works fine in 4.3.2,
but is broken b/c of this so we cannot upgrade.

here's a quote from the jpgraph people:

"There seems to be a bug with some versions of PHP on Windows. It has a
(known) problem with simultaneous accessing the TTF libraries, (perhaps
some thread-safety issues ?). No known workaround exists (apart from
moving away from Win2000) as far as I'm aware."

is anyone familiar w/ this issue?

thanks, d.



[2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com

sorry, i left a piece of information out: php.exe is crashing for me,
not the webserver. that's the only behavioral difference between what
i'm experiencing from the original bug report.

every time i load my graph scripts, php.exe goes boom.



[2004-05-04 07:28:32] dietrich dot ayala at foundstone dot com

i'm getting this also. it's reproducible 100% of the time. also using
jpGraph.

i'm working on getting this isolated, but as jpGraph is many thousands
of lines long, it's difficult.

i'm using IIS/WinXP&2k/PHP-4.3.6 & 4.3.7-dev.



[2004-04-25 18:21:18] [EMAIL PROTECTED]

Please make a script (as short as possible) that can be 
used to consistently replicate the crash. 



[2004-04-21 18:24:12] doormat at sequence-omega dot net

I'm using Apache 1.3.29. I'm not quite sure how to show that  it
crashes in 10 lines or less, especially since the problem only seems to
happen when multiple images are being generated at the same moment (a
page is requested with multiple images, many images are generated with
php/GD, if the page has a bunch of graphs, apache typically crashes).
I'll work on it and get back to you though.



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

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


#26016 [Com]: Warning: fsockopen(): Bug

2004-05-04 Thread scott at marinar dot com
 ID:   26016
 Comment by:   scott at marinar dot com
 Reported By:  hill at bluecarrots dot com
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

The same is seen here with php 4.3.6 freshly compiled on Debian /
Linux.  Configure command is "./configure --enable-bcmath
--with-openssl=/usr/local/openssl --with-mysql
--with-apxs=/usr/bin/apxs --prefix=/usr/local"

This bug persists through reloads of apache; apache version is 1.3.26. 
With so many people obviously affected by this PHP bug across multiple
platforms, I'm concerned that the answer from PHP seems to be "it's not
a PHP problem" promptly followed by marking threads as bogus.

--Scott!


Previous Comments:


[2004-03-19 03:39:53] andrew at shh dot fi

The error is real except this guy has the wrong script.
I have the same problem - this is the script:

$method = "ssl://";
$host = "myserver.com"; 
$port = 443; 

$fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30);


I get the error:
Warning: fsockopen(): no SSL support in this build 

AND SSL is loaded in php. Its a bug I patch on windows, but need one
for linux



[2003-11-03 14:06:38] [EMAIL PROTECTED]

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





[2003-10-28 04:44:03] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


please provide a sample script to illustrate the problem



[2003-10-28 04:40:30] hill at bluecarrots dot com

Description:

I get the warning at the top of the page. Several refreshes of the
browser rectifies.

Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed:
Name or service not known in /home/.sites/.blahphp on line 14

Warning: fsockopen(): unable to connect to blah.com:80 in
/home/.sites/blah.php on line 14
Resource temporarily unavailable (11)


Reproduce code:
---
Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed:
Name or service not known in /home/.sites/.blahphp on line 14

Warning: fsockopen(): unable to connect to blah.com:80 in
/home/.sites/blah.php on line 14
Resource temporarily unavailable (11)


Expected result:

I expect the page to connect securely to a secure server and send some
secure details.

I get the warning at the top of the page. Several refreshes of the
browser rectifies. I have to use this PHP code, which has been provided
by the Payment provider, to get to a server that takes online payments,
some information is first sent securely in order to reach the payment
page on the Payment providers server. 

Actual result:
--
The simle page takes time to load and when it does the fsockopen
warning is present.





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


#28084 [Com]: Crashes when fonts are accessed

2004-05-04 Thread jpgraph at aditus dot nu
 ID:   28084
 Comment by:   jpgraph at aditus dot nu
 Reported By:  doormat at sequence-omega dot net
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2000 SP3
 PHP Version:  4.3.6
 New Comment:

The following code is said to repeat the crash on Win32 , works fine on
Linux. Unfortunately I don't have access to a Win32 system to be able
to repeat.

The reproduce script was submitted by dietrich at ganx4 com




Previous Comments:


[2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com

here is a simple reproduction script.

the crash only occurs when writing the image to file, and is
reproducible 100% of the time.





[2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com

another comment: this is a regression. our code works fine in 4.3.2,
but is broken b/c of this so we cannot upgrade.

here's a quote from the jpgraph people:

"There seems to be a bug with some versions of PHP on Windows. It has a
(known) problem with simultaneous accessing the TTF libraries, (perhaps
some thread-safety issues ?). No known workaround exists (apart from
moving away from Win2000) as far as I'm aware."

is anyone familiar w/ this issue?

thanks, d.



[2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com

sorry, i left a piece of information out: php.exe is crashing for me,
not the webserver. that's the only behavioral difference between what
i'm experiencing from the original bug report.

every time i load my graph scripts, php.exe goes boom.



[2004-05-04 07:28:32] dietrich dot ayala at foundstone dot com

i'm getting this also. it's reproducible 100% of the time. also using
jpGraph.

i'm working on getting this isolated, but as jpGraph is many thousands
of lines long, it's difficult.

i'm using IIS/WinXP&2k/PHP-4.3.6 & 4.3.7-dev.



[2004-04-25 18:21:18] [EMAIL PROTECTED]

Please make a script (as short as possible) that can be 
used to consistently replicate the crash. 



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

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


#26016 [NoF->WFx]: Warning: fsockopen(): Bug

2004-05-04 Thread wez
 ID:   26016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hill at bluecarrots dot com
-Status:   No Feedback
+Status:   Wont fix
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

You must build the openssl statically to use this feature.
There is a static version for windows, provided by Emini, who are also
responsible for our win32 snapshots:
http://ftp.emini.dk/pub/php/win32/openssl/

We won't fix this in PHP 4, but it has already been fixed in PHP 5 (you
can load openssl dynamically in PHP 5).


Previous Comments:


[2004-05-04 21:57:10] scott at marinar dot com

The same is seen here with php 4.3.6 freshly compiled on Debian /
Linux.  Configure command is "./configure --enable-bcmath
--with-openssl=/usr/local/openssl --with-mysql
--with-apxs=/usr/bin/apxs --prefix=/usr/local"

This bug persists through reloads of apache; apache version is 1.3.26. 
With so many people obviously affected by this PHP bug across multiple
platforms, I'm concerned that the answer from PHP seems to be "it's not
a PHP problem" promptly followed by marking threads as bogus.

--Scott!



[2004-03-19 03:39:53] andrew at shh dot fi

The error is real except this guy has the wrong script.
I have the same problem - this is the script:

$method = "ssl://";
$host = "myserver.com"; 
$port = 443; 

$fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30);


I get the error:
Warning: fsockopen(): no SSL support in this build 

AND SSL is loaded in php. Its a bug I patch on windows, but need one
for linux



[2003-11-03 14:06:38] [EMAIL PROTECTED]

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





[2003-10-28 04:44:03] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


please provide a sample script to illustrate the problem



[2003-10-28 04:40:30] hill at bluecarrots dot com

Description:

I get the warning at the top of the page. Several refreshes of the
browser rectifies.

Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed:
Name or service not known in /home/.sites/.blahphp on line 14

Warning: fsockopen(): unable to connect to blah.com:80 in
/home/.sites/blah.php on line 14
Resource temporarily unavailable (11)


Reproduce code:
---
Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed:
Name or service not known in /home/.sites/.blahphp on line 14

Warning: fsockopen(): unable to connect to blah.com:80 in
/home/.sites/blah.php on line 14
Resource temporarily unavailable (11)


Expected result:

I expect the page to connect securely to a secure server and send some
secure details.

I get the warning at the top of the page. Several refreshes of the
browser rectifies. I have to use this PHP code, which has been provided
by the Payment provider, to get to a server that takes online payments,
some information is first sent securely in order to reach the payment
page on the Payment providers server. 

Actual result:
--
The simle page takes time to load and when it does the fsockopen
warning is present.





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


#26016 [WFx->NoF]: Warning: fsockopen(): Bug

2004-05-04 Thread wez
 ID:   26016
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hill at bluecarrots dot com
-Status:   Wont fix
+Status:   No Feedback
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Err, I obviously was reading the odd-one-out comment.
Restoring status.


Previous Comments:


[2004-05-04 23:01:10] [EMAIL PROTECTED]

You must build the openssl statically to use this feature.
There is a static version for windows, provided by Emini, who are also
responsible for our win32 snapshots:
http://ftp.emini.dk/pub/php/win32/openssl/

We won't fix this in PHP 4, but it has already been fixed in PHP 5 (you
can load openssl dynamically in PHP 5).



[2004-05-04 21:57:10] scott at marinar dot com

The same is seen here with php 4.3.6 freshly compiled on Debian /
Linux.  Configure command is "./configure --enable-bcmath
--with-openssl=/usr/local/openssl --with-mysql
--with-apxs=/usr/bin/apxs --prefix=/usr/local"

This bug persists through reloads of apache; apache version is 1.3.26. 
With so many people obviously affected by this PHP bug across multiple
platforms, I'm concerned that the answer from PHP seems to be "it's not
a PHP problem" promptly followed by marking threads as bogus.

--Scott!



[2004-03-19 03:39:53] andrew at shh dot fi

The error is real except this guy has the wrong script.
I have the same problem - this is the script:

$method = "ssl://";
$host = "myserver.com"; 
$port = 443; 

$fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30);


I get the error:
Warning: fsockopen(): no SSL support in this build 

AND SSL is loaded in php. Its a bug I patch on windows, but need one
for linux



[2003-11-03 14:06:38] [EMAIL PROTECTED]

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





[2003-10-28 04:44:03] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


please provide a sample script to illustrate the problem



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

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


#28278 [NEW]: flakey return by reference under certain circumstances

2004-05-04 Thread jeff at opendbms dot com
From: jeff at opendbms dot com
Operating system: Linux 2.6.1-rc1
PHP version:  5.0.0RC2
PHP Bug Type: Zend Engine 2 problem
Bug description:  flakey return by reference under certain circumstances

Description:

While passing references every which way, I come to a point where I cannot
get my processForm function to return a reference to an object member
variable.

Pretty serious bug I think...

Reproduce code:
---
http://www.opendbms.com/test.phps

80 lines with comments, Ready to run.

Expected result:

I expect the output to look like this:

Request Object
(
[attributes:private] => Array
(
[sequencelist] => Array
(
[0] => Orders.ProductInfo
[1] => NewSequence1.New1
)

)

[parameters:private] => Array
(
[sequence] => Orders.ProductInfo
)

)
Request:Request Object
(
[attributes:private] => Array
(
[sequencelist] => Array
(
[0] => Orders.ProductInfo
[1] => NewSequence1.New1
[2] => NewSequence2.New2
[3] => NewSequence3.New3
)

)

[parameters:private] => Array
(
[sequence] => Orders.ProductInfo
)

)
Reference:Array
(
[0] => Orders.ProductInfo
[1] => NewSequence1.New1
[2] => NewSequence2.New2
[3] => NewSequence3.New3
)


Actual result:
--
Request Object
(
[attributes:private] => Array
(
[sequencelist] => Array
(
[0] => Orders.ProductInfo
[1] => NewSequence1.New1
)

)

[parameters:private] => Array
(
[sequence] => Orders.ProductInfo
)

)
Request:Request Object
(
[attributes:private] => Array
(
[sequencelist] => Array
(
[0] => Orders.ProductInfo
[1] => NewSequence1.New1
[2] => NewSequence2.New2
)

)

[parameters:private] => Array
(
[sequence] => Orders.ProductInfo
)

)
Reference:Array
(
[0] => Orders.ProductInfo
[1] => NewSequence1.New1
[2] => NewSequence2.New2
[3] => NewSequence3.New3
)

The Request object is missing the last element of the array, because it is
no longer a reference at that point.

-- 
Edit bug report at http://bugs.php.net/?id=28278&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28278&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28278&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28278&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28278&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28278&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28278&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28278&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28278&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28278&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28278&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28278&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28278&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28278&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28278&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28278&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28278&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28278&r=float


#28190 [Fbk->NoF]: Page not completely outputted

2004-05-04 Thread php-bugs
 ID:   28190
 Updated by:   [EMAIL PROTECTED]
 Reported By:  prof_moriarty at veryfst dot biz
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: win xp home
 PHP Version:  5.0.0RC2
 New Comment:

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2004-04-27 21:19:09] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.




[2004-04-27 20:52:16] prof_moriarty at veryfst dot biz

Description:

Running PHP5.RC2 as a sapi module (or whatever it is) in apache 2.0.49.
MySQL 4.0.18

When trying to load phpmyadmin (2.5.6) pages, about 4 out of five
times, the server decides to stop serving them mid page. So i end up
with a semi-complete table in front of me.
Using Opera as the browser.
If i try looking at the pages in IE (oh horrors), it just returns a
"The page cannot be displayed" (but hey, it's IE :) ).
I'm guessing IE doesn't like recieving only part of the page, so
doesn't display it because it wants the rest. Opera is more willing to
go part-way.

I'm afraid i can't be more specific as to precisely what the problem
is, because i don't know. All the other scripts i've tried are fine
(though that's not many), however phpmyadmin seems to not be liked
much.

There's no report of this bug on the phpmyadmin web-site, so i'm
guessing it's probably the PHP interface with apache 2 (again :) ).
There are no errors/ notices or anything reported when reporting level
is set to ALL.

Note: This also happens with php4.3.6 whilst using it's php4apache2.dll
file.


Need any more details just ask. I'm sure it's not going to go away over
night. :)

Moriarty






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


#28084 [Fbk->NoF]: Crashes when fonts are accessed

2004-05-04 Thread php-bugs
 ID:   28084
 Updated by:   [EMAIL PROTECTED]
 Reported By:  doormat at sequence-omega dot net
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Windows 2000 SP3
 PHP Version:  4.3.6
 New Comment:

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2004-05-04 22:38:17] jpgraph at aditus dot nu

The following code is said to repeat the crash on Win32 , works fine on
Linux. Unfortunately I don't have access to a Win32 system to be able
to repeat.

The reproduce script was submitted by dietrich at ganx4 com





[2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com

here is a simple reproduction script.

the crash only occurs when writing the image to file, and is
reproducible 100% of the time.





[2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com

another comment: this is a regression. our code works fine in 4.3.2,
but is broken b/c of this so we cannot upgrade.

here's a quote from the jpgraph people:

"There seems to be a bug with some versions of PHP on Windows. It has a
(known) problem with simultaneous accessing the TTF libraries, (perhaps
some thread-safety issues ?). No known workaround exists (apart from
moving away from Win2000) as far as I'm aware."

is anyone familiar w/ this issue?

thanks, d.



[2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com

sorry, i left a piece of information out: php.exe is crashing for me,
not the webserver. that's the only behavioral difference between what
i'm experiencing from the original bug report.

every time i load my graph scripts, php.exe goes boom.



[2004-05-04 07:28:32] dietrich dot ayala at foundstone dot com

i'm getting this also. it's reproducible 100% of the time. also using
jpGraph.

i'm working on getting this isolated, but as jpGraph is many thousands
of lines long, it's difficult.

i'm using IIS/WinXP&2k/PHP-4.3.6 & 4.3.7-dev.



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

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


#28172 [Fbk->NoF]: Crazy error when commenting out a simplexml var

2004-05-04 Thread php-bugs
 ID:   28172
 Updated by:   [EMAIL PROTECTED]
 Reported By:  scholzrobert at web dot de
-Status:   Feedback
+Status:   No Feedback
 Bug Type: SimpleXML related
 Operating System: Fedora C1 (Linux 2.6.5)
 PHP Version:  5.0.0RC2
 New Comment:

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2004-04-27 08:25:50] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.



[2004-04-27 01:02:54] scholzrobert at web dot de

Description:

I have the Object $xml. It has the simplexml Obj $xml::xml. The
"reproduce code" lines stop my apache2 for this one script. Firefox
does not load the page, konqueror says that "Connction to localhost ist
broken" and IE displas a site which says "technical problems".

Reproduce code:
---
// $xml->xml->news->text
/* $xml->xml->news->text */
# $xml->xml->news->text

Expected result:

Nothing, it's only a comment to remember how ot worked before

Actual result:
--
Firefox does not load the page, konqueror says connection broken and IE
displays a "technical error" page.





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


#28183 [Fbk->NoF]: Variables mix up

2004-05-04 Thread php-bugs
 ID:   28183
 Updated by:   [EMAIL PROTECTED]
 Reported By:  patrick dot hagemeister at krankikom dot de
-Status:   Feedback
+Status:   No Feedback
 Bug Type: Scripting Engine problem
 Operating System: Linux SuSE 8.0
 PHP Version:  4.3.6
 New Comment:

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


Previous Comments:


[2004-04-27 21:13:33] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.



[2004-04-27 16:26:38] patrick dot hagemeister at krankikom dot de

Changed category to "Scripting engine problem"



[2004-04-27 16:21:04] patrick dot hagemeister at krankikom dot de

Description:

I have a medium-sized php applications (~2 lines), which starts to
produce a few problems.

Sometimes, variables mix up:
i.e. i create a new instance $root of class "CBXTreeNode", but only 3
lines later, suddenly the class type (checked using get_class()) of
$root is "CBXWorkflow", and the value is the one of another variable in
the same function.

But between these lines, i didn't even touch the variable...

In some places, a similar problem shows up:
I instanciate a class CBXTreeNode, but if i do get_class($variable), it
returns "cbxtreenodd" instead of ctxtreenode.

Unfortunately i could not reproduce it on every server, on my
development server it works, on the production server, it doesn't :( 

Also, the exact same source works outside my application, on the same
server.

I updated PHP from 4.2.3 to 4.3.6, but no change.



Reproduce code:
---
$root = $treemgr->getRootNode();
echo "root is class ".get_class($root)."";

$workflow =& $this->getWorkflow();
echo "workflow is class ".get_class($workflow)."";

echo "root is class ".get_class($root)."";


// **Output in my application**
// root is class CBXTreeNode
// workflow is class SPWorkflow
// root is class SPWorkflow


Expected result:

Output should be:

root is class CBXTreeNode
workflow is class SPWorkflow
root is class CBXTreeNode







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


#28172 [NoF->Csd]: Crazy error when commenting out a simplexml var

2004-05-04 Thread scholzrobert at web dot de
 ID:   28172
 User updated by:  scholzrobert at web dot de
 Reported By:  scholzrobert at web dot de
-Status:   No Feedback
+Status:   Closed
 Bug Type: SimpleXML related
 Operating System: Fedora C1 (Linux 2.6.5)
 PHP Version:  5.0.0RC2
 New Comment:

Can't reproduce this bug (apache 2.0.48/49).


Previous Comments:


[2004-05-05 01:00:06] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2004-04-27 08:25:50] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.



[2004-04-27 01:02:54] scholzrobert at web dot de

Description:

I have the Object $xml. It has the simplexml Obj $xml::xml. The
"reproduce code" lines stop my apache2 for this one script. Firefox
does not load the page, konqueror says that "Connction to localhost ist
broken" and IE displas a site which says "technical problems".

Reproduce code:
---
// $xml->xml->news->text
/* $xml->xml->news->text */
# $xml->xml->news->text

Expected result:

Nothing, it's only a comment to remember how ot worked before

Actual result:
--
Firefox does not load the page, konqueror says connection broken and IE
displays a "technical error" page.





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


#28084 [NoF->Ctl]: Crashes when fonts are accessed

2004-05-04 Thread wez
 ID:   28084
 Updated by:   [EMAIL PROTECTED]
 Reported By:  doormat at sequence-omega dot net
-Status:   No Feedback
+Status:   Critical
 Bug Type: Reproducible crash
 Operating System: Windows 2000 SP3
 PHP Version:  4.3.6


Previous Comments:


[2004-05-05 01:00:05] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2004-05-04 22:38:17] jpgraph at aditus dot nu

The following code is said to repeat the crash on Win32 , works fine on
Linux. Unfortunately I don't have access to a Win32 system to be able
to repeat.

The reproduce script was submitted by dietrich at ganx4 com





[2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com

here is a simple reproduction script.

the crash only occurs when writing the image to file, and is
reproducible 100% of the time.





[2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com

another comment: this is a regression. our code works fine in 4.3.2,
but is broken b/c of this so we cannot upgrade.

here's a quote from the jpgraph people:

"There seems to be a bug with some versions of PHP on Windows. It has a
(known) problem with simultaneous accessing the TTF libraries, (perhaps
some thread-safety issues ?). No known workaround exists (apart from
moving away from Win2000) as far as I'm aware."

is anyone familiar w/ this issue?

thanks, d.



[2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com

sorry, i left a piece of information out: php.exe is crashing for me,
not the webserver. that's the only behavioral difference between what
i'm experiencing from the original bug report.

every time i load my graph scripts, php.exe goes boom.



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

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


#28084 [Ctl->Opn]: Crashes when fonts are accessed

2004-05-04 Thread wez
 ID:   28084
 Updated by:   [EMAIL PROTECTED]
 Reported By:  doormat at sequence-omega dot net
-Status:   Critical
+Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows 2000 SP3
 PHP Version:  4.3.6
 New Comment:

err, I meant open.


Previous Comments:


[2004-05-05 01:00:05] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2004-05-04 22:38:17] jpgraph at aditus dot nu

The following code is said to repeat the crash on Win32 , works fine on
Linux. Unfortunately I don't have access to a Win32 system to be able
to repeat.

The reproduce script was submitted by dietrich at ganx4 com





[2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com

here is a simple reproduction script.

the crash only occurs when writing the image to file, and is
reproducible 100% of the time.





[2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com

another comment: this is a regression. our code works fine in 4.3.2,
but is broken b/c of this so we cannot upgrade.

here's a quote from the jpgraph people:

"There seems to be a bug with some versions of PHP on Windows. It has a
(known) problem with simultaneous accessing the TTF libraries, (perhaps
some thread-safety issues ?). No known workaround exists (apart from
moving away from Win2000) as far as I'm aware."

is anyone familiar w/ this issue?

thanks, d.



[2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com

sorry, i left a piece of information out: php.exe is crashing for me,
not the webserver. that's the only behavioral difference between what
i'm experiencing from the original bug report.

every time i load my graph scripts, php.exe goes boom.



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

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


#22335 [Com]: htmlspecialchars() encodes foriegn chars too!

2004-05-04 Thread mano at cvr dot hu
 ID:   22335
 Comment by:   mano at cvr dot hu
 Reported By:  caleb_ownz at yahoo dot com
 Status:   Bogus
 Bug Type: Strings related
 Operating System: Windows
 PHP Version:  4.3.0
 New Comment:

Hi
Yes, I also recognized this problem with the hungarian chars!
I hope that I'll find the solutions around here...

.mano


Previous Comments:


[2003-02-22 14:27:09] [EMAIL PROTECTED]

set proper status.



[2003-02-22 14:26:55] [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.

Works fine here, the error you are seeing sounds like a result of
COPY/PASTE operation from another Win32 application. Win32 has a nasty
tendency to automatically encode special characters into their HTML
enteties.
The example below should demonstrate that htmlspecialchars()  works
correctly.




[2003-02-21 06:02:01] caleb_ownz at yahoo dot com

hmm after checking some more research i noticed that this happens only
when the browser encoding != language you are writing.

So if you write in hebrew when the browser is set to encode Western
European you will get something similar to this:
"עברית" although i did solve all these
problems by calling html_entities_decode() but still.. why should
htmlspecialchars() encode anything but the SPECIAL chars, and not
language chars..

ùìåí
becomes
שלום



[2003-02-20 17:25:17] [EMAIL PROTECTED]

Could you please supply a simple string with which the problem occures.



[2003-02-20 13:00:33] caleb_ownz at yahoo dot com

Hello,

The htmlspecialchars() function should only convert SPECIAL chars such
as '&' '"' ''' '<' '>'. (at least this is what the documentation says)

But this function also seems to convert foriegn language (non-english)
chars too which is what htmlentities() basically does.

I have tested this on Russian and Hebrew!





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


#28276 [Opn]: function rename stopped working after the last Windows update

2004-05-04 Thread motion4u at hotmail dot com
 ID:   28276
 User updated by:  motion4u at hotmail dot com
 Reported By:  motion4u at hotmail dot com
 Status:   Open
 Bug Type: Directory function related
 Operating System: Windows 2000 Advanced
 PHP Version:  4.3.6
 New Comment:

Sorry, it is not a bug! simply with this version the folders have to
have more access permissions under windows as before.

I'm sure that it is mentioned somewhere in the documentations, which I
have missed.

You may drop this report if you like.


Previous Comments:


[2004-05-04 19:28:58] motion4u at hotmail dot com

Description:

The function:
rename($oldname, $newname);
stopped working after the last windows update.
I'm using the rename Function to rename a directory

rename($oldname, $newname);

It doesn't work anymore... 
Before making a fool out of myself, I have double checked it.
If you think to answer that it might be that the directory is in use or
a file within it is open ... the answer is no! I have restarted the
server and the client and disconnected the internet plug for it.

Reproduce code:
---
just fill in the path to any subdirectory and call








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


#28279 [NEW]: function symlink() crash under windows

2004-05-04 Thread motion4u at hotmail dot com
From: motion4u at hotmail dot com
Operating system: Windows 2000 Advanced
PHP version:  4.3.6
PHP Bug Type: IIS related
Bug description:  function symlink() crash under windows

Description:

Create and Manipulate NTFS Junction Points doesn't work in PHP but it was
solved by www.sysinternals.com. They also offer the c-code free for
download.

I have tested it and it works very well.

You can download the free source code there:

http://www.sysinternals.com/files/jnctnsrc.zip



Reproduce code:
---
$letters = 'abcdefghijklmnopqrstuvwxyz'; 
srand((double) microtime() * 100); 
$string = ''; 
for ($i = 1; $i <= rand(4,12); $i++) { 
   $q = rand(1,24); 
   $string = $string . $letters[$q]; 
} 
//- this part can't work under windows
$handle = opendir($downloaddir); 
while ($dir = readdir($handle)) { 
   if (is_dir($downloaddir . $dir)){ 
 if ($dir != "." && $dir != ".."){ 
 @unlink($downloaddir . $dir . "/" . $filename); 
 @rmdir($downloaddir . $dir); 
 } } } 
closedir($handle); //--
mkdir($downloaddir . $string, 0777); 
// here symlink produce browser crash under windows
symlink($safedir . $filename, $downloaddir . $string . "/" . $filename); 
Header("Location: ".$downloadURL.$string. "/" . $filename);

Expected result:

start downloading but produce browser crash


-- 
Edit bug report at http://bugs.php.net/?id=28279&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28279&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28279&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28279&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28279&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28279&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28279&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28279&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28279&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28279&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28279&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28279&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28279&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28279&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28279&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28279&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28279&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28279&r=float


#25876 [Com]: session_start(): Failed to initialize storage module

2004-05-04 Thread tkaeser at gmx dot net
 ID:   25876
 Comment by:   tkaeser at gmx dot net
 Reported By:  golden at riscom dot com
 Status:   Closed
 Bug Type: Session related
 Operating System: freebsd 4.8
 PHP Version:  4.3.3
 New Comment:

Hi,
had the same error, added the following line before starting the
session:

   ini_set('session.save_handler', 'files');

this fixed it in my case...

I don't have any idea why this works, got it from
http://lists.mushaake.org/pipermail/php/Week-of-Mon-20031117/004091.html


Previous Comments:


[2004-04-05 08:17:56] venkat at ehostpros dot com

#
Problem :
Fatal error: session_start(): Failed to initialize storage module

#

The solution (fingers crossed) was to clear the session.save_path
directory - it got thousands of session files there.

Hope it helps someone out there.

#

The above solution works fine :)


Thanks,
Venkatesh.G



[2004-04-01 16:37:42] php dot net at harrysufehmi dot com

I just experienced this problem with php 4.3.3

The solution (fingers crossed) was to clear the session.save_path
directory - it got thousands of session files there.

Hope it helps someone out there.



[2004-03-08 05:38:31] hck7 at mailcity dot com

We installed PHP 4.3.1 and this problem disappears!!!
Thanks for all !!!



[2004-03-02 04:49:14] ozone at sange dot fi

As suggested by mivox on Feb 12 in comments to bug 26038, which seems
to be a duplicate of this one, I added a line in my apache.conf:

php_value session.save_handler files

(source: http://bugs.php.net/bug.php?id=260389 )

After this I haven't seen any problems (running for a bit less than a
day), but it's hard to say whether it really helped.

Maybe there are still problems with the initialization of session
parameters when PHP is running as a module and the same code is used to
serve lots of requests.

For me the problems started when using FreeBSD 4-STABLE (4.8 I think,
or even earlier) with PHP 4.2.x and continued with PHP 4.3.x, but they
were very infrequent when using Apache 1.3. Upgrading to Apache 2 made
problems turn up much more often and users started complaining loudly.

I applied the patch from CVS that was supposed to fix the problem to
PHP 4.3.4 (from FreeBSD ports) but it didn't help. Of course that's not
quite the same as trying a recent snapshot, but other people have tried
that and it didn't help either.



[2004-02-27 10:30:37] bernoico at netcabo dot pt

I also have made the change you sugested and the problem continues...
You have to reopen this bug report.
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/25876

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


#21772 [Com]: mssql speed when using remote server

2004-05-04 Thread reubs at idsdatanet dot com
 ID:   21772
 Comment by:   reubs at idsdatanet dot com
 Reported By:  pvy at novosoft dot ru
 Status:   Bogus
 Bug Type: MSSQL related
 Operating System: windows 2000/sp3
 PHP Version:  4.2.3
 New Comment:

We have the same problem - but there is an interesting twist. Was
running through the test in a progressive manner.

1. Vanilla install on local machine MSSQL2k/PHP433 - works as expected
without any service packs --- Machine A

2. Vanilla install on remote machine MSSQL2k - unacceptably slow -
response and processing time went from 1 second to 15-20seconds. --
+Machine B - colleague ran a packet sniffer and found fragmented
requests

3. Installed latest service packs on Machine B, fragmented packets are
reduced. Speed is still slow - improvements were minor.

-- here is where you have to read carefully.

4. Installed latest service pack on Machine A (remember machine A had a
version of MSSQL2k but not used as the target DB) - Speed went up to
equivelant of MySQL/PHP, impressive, problem solved(?) - assumption
must install connector service pack upgrade on Web server as well

5. Client complained - no improvement,

6. Uninstalled the MSSQL server on my webserver - installed just the
connectors, ran the MDAC update patches - Result, same as note 2 -
15-20second response time.

Obviously there seems to be a difference in MSSQL Connector DLLs. Have
to look into this (unless someone here know what is going on) but I
must admit my suggestion to them would be a LAMP config.

--sob story - basic rant start
The excessive finger pointing on bug ownership in the end puts us at
risks of losing a key client as we come up to no solution but a lot of
doubts by the client on the platform of choice - and the IS department
having spent a lot of money on MSSQL will blame it on PHP first before
putting the blame on their choice of corporate db.


Previous Comments:


[2003-01-21 12:27:09] [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.

There are some networking issues when Linux & Win32 machines
communicate. For example a stock 100mbit lan only operates at 1/3 - 1/2
speed while if both machines run the same OS all 100mbit are
avaliable.
Since this appears to be a networking issue, I am marking this a bogus
(not a php bug).



[2003-01-21 11:24:59] [EMAIL PROTECTED]

Hi,

I'm unable to reproduce these diferences on my systems.

I have tested the speed on a SQL Server 7.0 and I get almost the same
response times on local and remote connections. In my case the local
connects are slower due to the fact that both PHP and MSSQL server is
competing on the CPU.

If there is a diference from Linux to Windows this must be caused by
old versions of DBLIB used on Windows. I'm working on using FreeTDS on
Windows.

Other factors can be how you configure your MSSQL Server and Clients.
If you don't do anything MSSQL defaults to named pipes (approx 8 times
slover on a network but faster on a local connection compared to
TCP/IP).
You should use the Client Network Configuration tool to specify default
libraries and configure aliases for your local and remote servers. Then
use this alias when connecting to the server.

When you compare PHP and MS Queary Tool you compare apples and oranges.
PHP is build on an old database protocol and MS Query Tool uses the
most modern technology available.

- Frank



[2003-01-21 03:51:35] pvy at novosoft dot ru

Thank you Joey!
Good work!



[2003-01-21 03:49:56] [EMAIL PROTECTED]

We've been using PHP hosted on a win32 machine to connect 
to SQL Server 2000.  When the PHP host and the MSSQL host
are the same machine, everything is fine. But when we try
to use seperate hosts for PHP and MSSQL, query times become
unbearably slow.

The odd thing is that I can run the same scripts on the
same network connecting to the same MSSQL server from a Linux box, and
see acceptable response times.

As an example, I did a script that does 1000 iterations
of 'sp_sproc_columns @procudure_name = "some_proc"' in three
different setups.


Setup 1:
  MSSQL and PHP on the Win2k host, call it machine 'A'
  Average Response time over 5 iterations of script: 18s

Setup 2:
  MSSQL on host 'A', PHP on Linux host ('B')
  Average Response time over 5 iterations of script: 41s
  (Given the size of the result set, this is an acceptable
   response time.)

Setup 3:
  MSSQL on host 'A', PHP on seperate Win2k host ('C')
  Average Response time over 5 iterations: 3