#24005 [Ana]: Distributions version of mnoGoSearch extension does not work with MySQL 4

[gluke]

 ID:   24005
 Updated by:   [EMAIL PROTECTED]
 Reported By:  paul at ensigma dot com dot au
 Status:   Analyzed
 Bug Type: mnoGoSearch related
 Operating System: RedHat 9
 PHP Version:  4.3.2
 Assigned To:  gluke
 New Comment:

Yes. I will update PHP_4_3 source code branch soon.
It means that updates extension will go to possible PHP-4.3.3 release
in future.


Previous Comments:


[2003-06-10 23:09:28] paul at ensigma dot com dot au

There is still the issue of the old version of mnoGoSearch in the 4.3.2
source code... has that been updated??



[2003-06-10 09:34:41] [EMAIL PROTECTED]

It seems to be because of buggy gcc-3.x compiler in your distribution.
The normal gcc behavior is to ignore -l switch dupes.



[2003-06-06 06:32:32] [EMAIL PROTECTED]

Sergey, deal with this.




[2003-06-03 21:24:12] paul at ensigma dot com dot au

I tried to compile PHP-4.3.2 with the --with-mnogosearch option and
with MySQL 4.0.13 installed from RPM .

./configure --with-mysql=/usr --with-gd --with-ttf --enable-track-vars 
--with-apxs2=/usr/local/apache2/bin/apxs --with-mnogosearch
--with-jpeg-dir=/root/source/jpeg-6b/ 
--with-png-dir=/usr/local/lib/libpng.a
--with-zlib-dir=/usr/local/lib/zlib.a
--with-tiff-dir=/usr/local/lib/libtiff.a --with-mnogosearch 

It failed complaining about "ext/mysql/phpmysql.c: undefined reference
to mysql_create_db". I downloaded the latest php-extension from
www.mnogosearch.org (mnogosearch-php-extension-1.7.3.tar.gz) and
replaced the contents of ext/mnogosearch with the files in this archive
and it all worked a treat (with a quick edit to remove the second
reference to -lmysqlclient in the EXTRA_LIBS line the PHP Makefile...
but I think that mnoGo's fault!)






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

#24096 [Opn]: session_regenerate_id not delete the old session file

[pablo_sole at myp dot net dot ar]

 ID:   24096
 User updated by:  pablo_sole at myp dot net dot ar
 Reported By:  pablo_sole at myp dot net dot ar
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: linux rh8 apache 1.3.27
 PHP Version:  4.3.2
 New Comment:

You're right, in my own case i use this function to do a per-page
session (following OWASP's "Guide to Build Secure Web Applications" or
something like that), so what i'm doing is to refresh the id every time
a user do a request, but without lost the "statefulness". So, if you
think this need to be supported by the php sessions code, was an honor
help you, if not... i already do a little patch to support it on my own
server.

pablo.


Previous Comments:


[2003-06-09 23:11:00] [EMAIL PROTECTED]

-> Open



[2003-06-09 23:10:25] [EMAIL PROTECTED]

It is debatable whether the function should destroy the old session. 
The current behaviour is useful under a number of circumstances.
Auto-destruction could be added as a new feature though.

 -> Feature/Change request.



[2003-06-09 09:42:08] pablo_sole at myp dot net dot ar

testing the new session_regenerate_id i see that after upgrade de SID,
not unlink the old session file so, when you regenerate many times the
session could be used to make a DoS, or at least is not what it's
expected from the function.

Checking the source code, the routine free the SID and assign the new,
but not unlink the old file (just like in the php_session_destroy
routine).

A workaround could be unlink manualy on the fly, or patch the session.c
file.

Sorry my poor english, but is not my native language.

Any question, mail me.

pablo.

PD: I not have any "specific setup" or extra modules compiled in, and
for that reason i don't put it here.





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

#24005 [Ana]: Distributions version of mnoGoSearch extension does not work with MySQL 4

[paul at ensigma dot com dot au]

 ID:   24005
 User updated by:  paul at ensigma dot com dot au
 Reported By:  paul at ensigma dot com dot au
 Status:   Analyzed
 Bug Type: mnoGoSearch related
 Operating System: RedHat 9
 PHP Version:  4.3.2
 Assigned To:  gluke
 New Comment:

There is still the issue of the old version of mnoGoSearch in the 4.3.2
source code... has that been updated??


Previous Comments:


[2003-06-10 09:34:41] [EMAIL PROTECTED]

It seems to be because of buggy gcc-3.x compiler in your distribution.
The normal gcc behavior is to ignore -l switch dupes.



[2003-06-06 06:32:32] [EMAIL PROTECTED]

Sergey, deal with this.




[2003-06-03 21:24:12] paul at ensigma dot com dot au

I tried to compile PHP-4.3.2 with the --with-mnogosearch option and
with MySQL 4.0.13 installed from RPM .

./configure --with-mysql=/usr --with-gd --with-ttf --enable-track-vars 
--with-apxs2=/usr/local/apache2/bin/apxs --with-mnogosearch
--with-jpeg-dir=/root/source/jpeg-6b/ 
--with-png-dir=/usr/local/lib/libpng.a
--with-zlib-dir=/usr/local/lib/zlib.a
--with-tiff-dir=/usr/local/lib/libtiff.a --with-mnogosearch 

It failed complaining about "ext/mysql/phpmysql.c: undefined reference
to mysql_create_db". I downloaded the latest php-extension from
www.mnogosearch.org (mnogosearch-php-extension-1.7.3.tar.gz) and
replaced the contents of ext/mnogosearch with the files in this archive
and it all worked a treat (with a quick edit to remove the second
reference to -lmysqlclient in the EXTRA_LIBS line the PHP Makefile...
but I think that mnoGo's fault!)






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

#3 [NEW]: sum

[ZX at nukecops dot com]

From: ZX at nukecops dot com
Operating system: os
PHP version:  4.3.2
PHP Bug Type: *General Issues
Bug description:  sum

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

#16043 [Com]: $_SESSION can't use in PHP 4.1.2

[php at rjs3 dot com]

 ID:   16043
 Comment by:   php at rjs3 dot com
 Reported By:  tokimeki at pchome dot com dot tw
 Status:   Closed
 Bug Type: Session related
 Operating System: Windows XP
 PHP Version:  4.1.2
 New Comment:

I thought I was having this problem when I discovered that my cookie
domain in php.ini was set.  I host multiple virtual domains, and when I
was trying use sessions on a different domain they would always fail. 
I have since changed the cookie domain to blank so it defaults to the
server which issues the cookie.  Just something else to check for
anyone still having problems.


Previous Comments:


[2003-04-19 10:41:29] no at bulk-e-mail-marketing dot com

WOW,  I have been working on this problem for days,  I am running php
4.0.6 on suse linux7.3 and had the same problem.  This IS what fixxed
me.

// $HTTP_SESSION_VARS bugfix
while(list($key , $value) = each($HTTP_SESSION_VARS)){
session_register($key);
$$key = $value;
}

which was listed on this page by bluefoot project. THXS guys :-)



[2003-04-01 18:53:47] madstarr at bellsouth dot net

Noticed that most of these emails related to the $_Session not
maintaining the variable value occurred in 2002. Has this been
resolved? I saw mentioned it was resolved with 4.2.0. I am running
4.2.2 on an NT 5.0 system, and experiencing the same problem trying to
process form data from 3 forms. I combined the forms into 1, got rid of
the $_SESSION and just used $_POST, works perfectly. What's the deal,
is it fixed?



[2003-02-21 17:20:39] twjohnso at hotmail dot com

I too am having the same issue... here is my info...
PHP Version: 4.3.1 (Windows Binary)
OS Version: Win2K Pro, SP2
Webserver: IIS
MySQL version: 4.0.10 gamma (win32)

PHP Settings...
file_uploads = On/Off (someone said this helped for them, didnt seem
to
make a difference for me)
register_globals = On/Off (someone said this helped for them, didnt
seem
to make a difference for me)
session support = enabled

Regards,
Tj



[2003-01-24 13:14:48] sbeam at rtint dot net

ok I will ask Redhat to send the aspirin and cake



[2003-01-24 13:12:16] sbeam at rtint dot net

rant rant rant rant rant rant rant. I have a splitting headache thanks
to this bug - thought it was DESIGNED that way until I found this
report. You should send out aspirin and cake to everyone who uses
Redhat 7.3 as the php RPM as of RIGHT NOW is 4.1.2.



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

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

#24116 [Opn]: Enhancement: extract() takes array of keys

[kop at meme dot com]

 ID:   24116
 User updated by:  kop at meme dot com
 Reported By:  kop at meme dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.3.2
 New Comment:

There is a glitch in my proposal, what if (in my example) there is no
user supplied value for $foo, in that case if my program assigns a
value to $foo, that value is local.  But, if the user does supply a
value for $foo, then $foo is a reference into $_POST, and the value can
be seen elsewhere in the program.  It's not a happy circumstance to
have the scope of a value depend upon the presence or absence of some
data in a data structure.  It'd make for bugs.

This could be solved with another kludge, like so:

Instead of:

extract($_POST, EXTR_REFS, '', array('foo', 'bar', 'baz'));

do

extract($_POST
, EXTR_REF_INITS
, ''
, array('foo' => 'mydefaultval'
, bar => 'mydefaultval'
, 'baz' => UNASSIGNED));

UNASSIGNED is new.  It is a php predefined constant containing the
value you get if you reference a variable which has not had a value
assigned to it.

EXTR_REF_INITS is a new extract_type.  It works like EXTR_REFS, but
when the (new) array argument is present it will put key/value pairs
into the first extract() argument iff the key does not already exist in
the first argument.

Clear like mud? 

I can't say for certain my proposal for extract() is the best solution.
 Any of it.  It does seem a little of an aftermarket bolt-on.  Not that
there shouldn't be a solution to what I want to accomplish.


Previous Comments:


[2003-06-10 12:16:47] kop at meme dot com

I want to get variables passed from the client into local (not global)
variables.  If the variable has not been passed from the client I do
not want a local variable defined.  While this can be coded for each
variable I want to do this with, there is no way to abstract this
operation into a function.

The (untested) code to get a form variable 'foo' would be:

if (array_key_exists($_POST, 'foo') {
  $foo = &{$_POST['foo'])}
}
// $foo may or may not be defined, so if I've got strict
// error checking on I get a nice error if I ref an undefined
//variable.  And, $foo is nice and local so it won't show
// where I don't send it.

If extract() took an array of keys as another argument, extracting only
those keys that are in the list, I could get the form variables, foo,
bar, and baz with:

extract($_POST, EXTR_REFS, '', array('foo', 'bar', 'baz'));





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

#2 [NEW]: summary

[zx at nukecops dot com]

From: zx at nukecops dot com
Operating system: os
PHP version:  4.3.2
PHP Bug Type: *XML functions
Bug description:  summary

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

#1 [NEW]: summary

[zx at nukecops dot com]

From: zx at nukecops dot com
Operating system: os
PHP version:  4.3.2
PHP Bug Type: *XML functions
Bug description:  summary

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

#14837 [Com]: getlastmod() returning file access time, not modification time

[mf22cs at student dot hik dot se]

 ID:   14837
 Comment by:   mf22cs at student dot hik dot se
 Reported By:  wls at wwco dot com
 Status:   Closed
 Bug Type: Directory function related
 Operating System: Linux Slackware, kernel 2.4.16
 PHP Version:  4.1.0
 New Comment:

I don´t see how the status could be "closed".

My ISP runs:
PHP 4.3.1
Apache 1.3.27
Slackware Linux 2.4.18

And the problem remains. I don´t get the correct timestamp out of
getlastmod() until i do a "touch filename".

/Marcus Farrington
mf22cs_at_student_dot_hik_dot_se


Previous Comments:


[2003-05-20 06:19:28] ffyk3s at home dot se

It also seems that getlastmod() doesn't work under Novell with Apache
1.3.27 and PHP-4.2.4-dev (the latest available), might be worth
checking out...



[2002-01-27 01:15:00] [EMAIL PROTECTED]

Works fine in CVS.



[2002-01-03 22:11:20] wls at wwco dot com

I've just upgraded to PHP 4.1.0 and I have code on my site
(Linux/Apache) that displays when the page was last modified:



This used to work like a champ.  However, I noticed after upgrading
that the date/time stamp it displays is that of the last _access_, not
modification.

Thus, I'm *expect* the date as shown by:
  $ ls -l index.php
Instead, I'm *seeing* the date as shown by:
  $ ls -lu index.php

I didn't notice it in the bug-fix list for PHP 4.1.1.  I didn't see it
in the PHP Reported Bug List.

-Walt Stoneburner,
 [EMAIL PROTECTED]




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

#24119 [NEW]: PHP timesout after adding php_mssql.dll

[brad at eznetideas dot com]

From: brad at eznetideas dot com
Operating system: win 2000
PHP version:  4.3.2
PHP Bug Type: *General Issues
Bug description:  PHP timesout after adding php_mssql.dll

PHP works great until I try to load the extension php_mssql.dll in the
php.ini file. When I enable the php_mssql.dll the page will just timeout.
When I disable the extension php runs fine.
-- 
Edit bug report at http://bugs.php.net/?id=24119&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24119&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24119&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24119&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24119&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24119&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24119&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24119&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24119&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24119&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24119&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24119&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24119&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24119&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24119&r=gnused

#18670 [Asn]: strtotime() bug

[iliaa]

 ID:   18670
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nic at bbmcarlson dot com
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: RedHat Linux Linux linux1 2.2.16
-PHP Version:  4.2.2
+PHP Version:  4.3.2
 Assigned To:  rasmus
 New Comment:

updated version.


Previous Comments:


[2003-02-11 14:12:37] mphillips at lufkin dot org

I have noticed that when you do something like
$sdate = date9'Y-m-d', strtotime('02-09-2003'));

$sdate is getting '2008-02-24'.

Is this a common occurance



[2002-10-31 12:07:20] matt at codewalkers dot com

I also can confirm that strtotime acts funny when the same day does not
exist in the next month:



displays:

December



[2002-09-24 17:07:42] spud at nothingness dot org

In PHP 4.2.3, the difference between "2" and "next" are still screwy in
strtotime(). I'm trying to parse icalendar recurrence formats, so I
need to calculate things like the "second Monday" in a month. Sample
code below illustrates the difference between "2" and "next" (which
should be identical).

');
echo ('Start date: Sunday, Sep 1 2002');
$first = strtotime('first Monday',$start);
echo ('"First" Monday: '.date('l, M d Y',$first).'');
$oneth = strtotime('1 Monday',$start);
echo ('"1" Monday: '.date('l, M d Y',$oneth).'');
$next = strtotime('next Monday',$start);
echo ('"Next" Monday: '.date('l, M d Y',$next).'');
$twoth = strtotime('2 Monday',$start);
echo ('"2" Monday: '.date('l, M d Y',$twoth).'');
$third = strtotime('third Monday',$start);
echo ('"Third" Monday: '.date('l, M d Y',$third).'');
$threeth = strtotime('3 Monday',$start);
echo ('"3" Monday: '.date('l, M d Y',$threeth).'');
?>



[2002-07-31 18:07:05] [EMAIL PROTECTED]

Assigning to rasmus as it sounds like he already knows whats wrong.



[2002-07-31 10:51:09] [EMAIL PROTECTED]

so can we assign this bug to you Rasmus?



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

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

#21984 [Ver->Csd]: in 4.3.0 strtotime says next monday is Feb 10th 2003, thats wrong (4.2.3 works)

[iliaa]

 ID:   21984
 Updated by:   [EMAIL PROTECTED]
 Reported By:  krueger at bundes-verlag dot de
-Status:   Verified
+Status:   Closed
 Bug Type: Date/time related
 Operating System: SuSE Linux 8.1
 PHP Version:  4.3.0
 New Comment:

This bug has been fixed in CVS.

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

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

Appears to work correctly in latest CVS.


Previous Comments:


[2003-02-03 10:22:43] m dot ford at lmu dot ac dot uk

Well, yeah, you'd think wouldn't you? -- but the sequence is explicitly
"first, next, third, ...".

Perhaps you want to turn this into a Feature Request?

Mike



[2003-02-03 08:17:06] [EMAIL PROTECTED]

Then, how about "second monday"?



[2003-02-03 08:00:15] m dot ford at lmu dot ac dot uk

It *is* correct now, because that's how it always should have worked. 
I agree that it's less intuitive, but that doesn't make it any less
correct.  (Blame the people who defined the GNU date format!)

"Monday", or "first Monday", or "1 Monday" will give you the first
Monday which is zero or more days after the specified date (or today).

"next Monday" or "2 Monday" will give you the Monday after that.

"third Monday" or "3 Monday" will give you the one after that.

And so on (except that the text versions run out at "twelfth", so from
there onward you can only use "13 Monday", "14 Monday", etc.).

Cheers!

Mike



[2003-02-03 05:44:09] krueger at bundes-verlag dot de

Well, but it isn't correct now, but was before... or is there a new
term with with a can determine the "coming Monday" with strtotime?



[2003-02-03 05:36:56] m dot ford at lmu dot ac dot uk

H'rumph!  Actually, both of your servers are producing the answer they
should!

In PHP versions prior to 4.3.0, the handling of "next" in strtotime()
was incorrect; it was fixed for 4.3.0, so your script will require a
minor update.  Please see bug http://bugs.php.net/bug.php?id=18655 for
the relevent discussion.

This bug should be set to Bogus -- I don't think I have karma yet, so
would somebody do it, please?

Cheers!

Mike



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

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

#22092 [Opn->Fbk]: Strange warning and no functionality in imagettfbbox and imagettftext

[iliaa]

 ID:   22092
 Updated by:   [EMAIL PROTECTED]
 Reported By:  davidl at tocquigny dot com
-Status:   Open
+Status:   Feedback
 Bug Type: GD related
 Operating System: Redhat 7.1
 PHP Version:  4.3.2
 New Comment:

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




Previous Comments:


[2003-05-29 10:47:42] davidl at tocquigny dot com

The problem with spaces in the font name continues in 4.3.2.  A font
"arial.ttf" works but "futura bold.ttf" generates the error:

Warning: imagettfbbox(): Could not find/open font in
/xxx/xxx/xxx/custom_class.php on line 535



[2003-05-27 17:30:59] paul at thewall dot de

I can confirm this bug, it still persist. A Full path did not help, as
well as renaming the font file and cutting off the extension (which is
reported to work).

I have tried GD extension versions 1 and 2, same result. PHP Version is
4.2.3.



[2003-04-10 08:51:29] kadlcakd at yahoo dot com

I have the same problem with 4.3.1

I have GD 2.0.4 compiled with TTF support, php 4.3.1 compiled --with-gd
--with-ttf --with-freetype-dir


ImageTTFBBox( 18, 0, "fonts/times.ttf", "Hello" );

Gives an error:
Warning: imagettfbbox() [function.imagettfbbox]: Could not find/open
font in /usr2/accnts/theuser/www/tests/button.php

Dave.



[2003-03-13 14:00:41] FR at ncis dot ca

We also have this bug with 4.3.1



[2003-02-20 08:08:16] [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.





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

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

#22175 [Opn->Fbk]: session_decode does not work

[iliaa]

 ID:   22175
 Updated by:   [EMAIL PROTECTED]
 Reported By:  michel at ziobudda dot net
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux Redhat 7.3
 PHP Version:  5CVS-2003-02-11 (dev)
 New Comment:

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




Previous Comments:


[2003-02-11 15:52:35] michel at ziobudda dot net

Sure, you can find the script for

PHP4 (it works): http://www.ziobudda.net/test/session4-3.php (.phps for
the source)

PHP5 (not work): http://www.ziobudda.net:81/test/session4-3.php



[2003-02-11 15:25:21] [EMAIL PROTECTED]

Can you please provide a _short_ example script?
And without the mysql stuff..




[2003-02-11 14:20:00] michel at ziobudda dot net

I intend PHP5 from 10 Feb 2003's cvs.
Sorry.



[2003-02-11 14:18:55] michel at ziobudda dot net

There is a problem with session_decode and PHP5. 
The script at url

PHP4: http://www.ziobudda.net/test/session4-2.php (.phps for the
source) 
PHP5: http://www.ziobudda.net:81/test/session4-2.php

works with PHP4.3.0, but does not work with PHP5. 
Does not work because session_decode does not populate the $_SESSION[]
array.

register_global=on and off is identical.

Tnx in advance.





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

#22505 [Opn]: no way to specify the input charset for imap_sort() and imap_search()

[iliaa]

 ID:  22505
 Updated by:  [EMAIL PROTECTED]
 Reported By: yamamoto at trustbee dot com
 Status:  Open
 Bug Type:IMAP related
 PHP Version: 4.3.1
-Assigned To: 
+Assigned To: iliaa
 New Comment:

assigning to myself


Previous Comments:


[2003-03-02 07:07:25] yamamoto at trustbee dot com

I'm localizing IMP of Horde project to Japanese.
I need to search by Japanese for imap_sort function, but no way to
specify the input charset.
I made a patch to add input charset for imap_sort() and imap_search().

Please see below.
http://www.imp-jp.org/tarballs/php_imap_cvs.patch





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

#22495 [Opn->Bgs]: namespaces cause 'internal compiler error' on includes

[iliaa]

 ID:   22495
 Updated by:   [EMAIL PROTECTED]
 Reported By:  andrew at evilwalrus dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: WinXP
 PHP Version:  5CVS-2003-03-01 (dev)
 New Comment:

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

Thank you for your interest in PHP.

namespaces were removed from php5


Previous Comments:


[2003-04-18 20:22:12] thekid at thekid dot de

No compiler error here, but this actually won't work anyway.
require_once is nothing like "inline" or "#define" in C. It is not as
if code was simply at this place instead of in the file:)



[2003-03-01 13:38:45] andrew at evilwalrus dot com

Also, adding $this->baz to _debug() does not help.



[2003-03-01 13:36:43] andrew at evilwalrus dot com

The following script(s) cause an internal compiler error:

- foo.php -
_debug();

?>

- include.php -


---

Running foo.php via CLI causes the following fatal error to occur:

*Fatal error:  Internal compiler error.  Please report! in include.php
on line 6*

Running the script without the 'foo' namespace simply outputs a blank
line to the console, with no text returned, and no error generated.

~ Andrew Heebner




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

#23524 [Ver->Csd]: Improper handling of constants in array indeces.

[iliaa]

 ID:   23524
 Updated by:   [EMAIL PROTECTED]
 Reported By:  d dot stogov at turck dot spb dot ru
-Status:   Verified
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: Any
 PHP Version:  4.3.2-RC3-dev
 New Comment:

This bug has been fixed in CVS.

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

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




Previous Comments:


[2003-05-07 04:03:09] d dot stogov at turck dot spb dot ru

This bug exists in PHP version 4.1.2 - 4.3.1 and 5.0.0-dev.
It is similar to bug #18872 (Improper handling of class constants used
as default function argument values).

See the following PHP code:

PHP_VERSION)) {
print_r($a);
echo "\n";
  }
  f();
  f();
?>

The function "f" should print the same result at first and at second
invocation but it is not true. The output is:

Array
(
[4.3.1] => 4.3.1
)

Array
(
[PHP_VERSION] => 4.3.1
)


The error is in handling of "ZEND_RECV_INIT" opcode and in
function "zval_update_constant" that resets "IS_CONSTANT_INDEX" flag in
original "zval" instead of copy.




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

#22513 [Opn->Fbk]: imagettfbbox() returning bogus array values

[iliaa]

 ID:   22513
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jeremy at nirvani dot net
-Status:   Open
+Status:   Feedback
 Bug Type: GD related
 Operating System: linux 2.4.19
 PHP Version:  5CVS-2003-03-03 (dev)
 New Comment:

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




Previous Comments:


[2003-06-03 10:06:02] veronique at talafone dot com

I have the latest PHP build (4.3.2, 29-May-2003), running Apache 2 on
Redhat 8.0, and I am still experiencing this bug. My configure line is
as follows:

'./configure' '--with-apxs2=/usr/local/apache2/current/bin/apxs'
'--with-mysql=/usr/local/mysql' '--with-zlib-dir=/usr/lib/'
'--enable-versioning' '--enable-track-vars=yes' '--enable-url-includes'
'--enable-sysvshm=yes' '--enable-sysvsem=yes' '--enable-ftp'
'--with-config-file-path=/etc' '--with-gettext=/usr/local' '--with-gd'
'--with-jpeg-dir=/usr/local/lib' '--with-imap=/usr/local/imap-2002c1'
'--with-imap-ssl=/usr/local/openssl' '--with-pear'
'--enable-gd-native-ttf' '--with-ttf' 

A print_r of the array returned by the function gives me something like
this:
Array ( [0] => 1108521344 [1] => 138256048 [2] => -1073758568 [3] =>
1075360060 [4] => 1108521360 [5] => 1108517584 [6] => -1073758536 [7]
=> 1107767671 )



[2003-03-03 13:36:21] jeremy at nirvani dot net

Yes, as you may know, thttpd is not a threaded web server.

Jeremy



[2003-03-03 13:33:51] [EMAIL PROTECTED]

You may experience problems if you use freetype in threaded enviroment,
since that library is not thread-safe. But that does not affect thttpd
afaik.



[2003-03-03 13:21:50] jeremy at nirvani dot net

Without calculating what exactly it should show back, your example is
probably correct (as my build does not work, so I don't know exactly).

I have no idea why the build I am using is returning bogus data.  Does
it have something to do with using the thttpd sapi (I hope not) - as I
would hope that the gd_functions were abstracted enough to not be
interfered by a particular sapi implementation.  

I assume (as most bugs go) that if I were running this on Apache1,
there would be no problem - because I have never seen this problem on
apache1+php, but was shocked when it occured using thttpd+php. 
However, in theory, should this break with a particular sapi?  I mean,
what if this doesn't work with php-cgi or php, roxen, or apache2?  Do
we just say who cares, run apache1, or do we try and fix it?

I can run anything else anyone needs me to to try and get to the bottom
of this - just let me know.

Back to what is expected:
as the man page (http://php.net/imagettfbbox) says, those array
elements from 0->7 are positions of the image (X,Y) at the corners - so
the values I am getting are obviously wrong - and the ones you are
getting are what I would expect to see.  Any number over 1000 (positive
or negative) would seem to indicate something wrong.  If you look at
the values in the page I posted, you will see some really strange
numbers - almost like the pointers are getting printed, or something -
but anything but the correct values.

Jeremy



[2003-03-03 13:07:59] [EMAIL PROTECTED]

Can you show that is the 'expected' output of this function?

On my system it returns
array(8) {
  [0]=>
  int(-3)
  [1]=>
  int(1)
  [2]=>
  int(79)
  [3]=>
  int(1)
  [4]=>
  int(79)
  [5]=>
  int(-34)
  [6]=>
  int(-3)
  [7]=>
  int(-34)
}

But since no position for the text is provided the positioning is
completely random. What matters is the difference between the various
numbers, which you can use to determine the how much space the text
will occupy.



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

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

#24118 [Asn]: Error while using foreach

[elmicha]

 ID:   24118
 Updated by:   [EMAIL PROTECTED]
 Reported By:  young at sl dot com dot ua
 Status:   Assigned
 Bug Type: Scripting Engine problem
-Operating System: FreeBSD 4.7
+Operating System: FreeBSD 4.7, Linux
-PHP Version:  4.3.3-dev, 5.0.0-dev
+PHP Version:  4.3.2, 4.3.3-dev, 5.0.0-dev
 Assigned To:  zeev
 New Comment:

Yes; more evidence:

";
}
?>

Output: 12344

";
}
?>

Output: 12345


Previous Comments:


[2003-06-10 17:56:08] [EMAIL PROTECTED]

Zeev, here is first one I verified with both 4.3.3-dev and 5.0.0-dev.
Have fun fixing this one. :)




[2003-06-10 17:32:00] young at sl dot com dot ua

Sample code to make this bug:
";
}
?>
Return
1
4
9
16
16



[2003-06-10 17:24:46] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




[2003-06-10 17:20:10] young at sl dot com dot ua

Source code N1:
-
foreach ($sqldata as $row) {
$item = $row;
print_r($item);
}
-
Result 1:
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 230
)
-
Source code 2:
-
foreach ($sqldata as $item) {
print_r($item);
}
-
Result 2:
-
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 50
)
--




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

#24118 [Opn->Asn]: Error while using foreach

[sniper]

 ID:   24118
 Updated by:   [EMAIL PROTECTED]
 Reported By:  young at sl dot com dot ua
-Status:   Open
+Status:   Assigned
-Bug Type: Arrays related
+Bug Type: Scripting Engine problem
 Operating System: FreeBSD 4.7
-PHP Version:  4.3.2
+PHP Version:  4.3.3-dev, 5.0.0-dev
-Assigned To:  
+Assigned To:  zeev
 New Comment:

Zeev, here is first one I verified with both 4.3.3-dev and 5.0.0-dev.
Have fun fixing this one. :)



Previous Comments:


[2003-06-10 17:32:00] young at sl dot com dot ua

Sample code to make this bug:
";
}
?>
Return
1
4
9
16
16



[2003-06-10 17:24:46] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




[2003-06-10 17:20:10] young at sl dot com dot ua

Source code N1:
-
foreach ($sqldata as $row) {
$item = $row;
print_r($item);
}
-
Result 1:
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 230
)
-
Source code 2:
-
foreach ($sqldata as $item) {
print_r($item);
}
-
Result 2:
-
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 50
)
--




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

#24013 [Com]: Missing Form Post Data

[luser at abv dot bg]

 ID:   24013
 Comment by:   luser at abv dot bg
 Reported By:  webmaster at dtshowtime dot lu dot eu dot org
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows XP Pro SP1
 PHP Version:  4.3.2
 New Comment:

I have this problem two, but I'm using OmniHTTPd 2.10 @ win98se


Previous Comments:


[2003-06-04 06:48:10] [EMAIL PROTECTED]

Duplicate of #22427, add your comments there.



[2003-06-04 06:16:20] webmaster at dtshowtime dot lu dot eu dot org

I have exactly the same problem described in bug 22427 (seems nobody is
looking at that one anymore, thus I'm submitting this dupe)

-
I am currently experincing some problems with missing post form data. 

There seem two be 2 problems:
1) When a variable is long (for example a textarea and lots of text is
in it), the post data is not sent.
2) Sometimes even with small textarea, the post is still not outputed,
but if you hit refresh and click reload post data, it sometimes works.


I have also set the max post size to 20MB which should be plenty for
just text.

I seem to have this problems on all browsers / computers.
--

I'm experiencing this when trying to install postnuke: The first screen
(Language selection) sometimes submits correctly, sometimes it doesn't.
The second screen (with the GPL license agreement in a textared) NEVER
gets submitted correctly, the POST variables remain empty.

I DO have register_globals set to on and post_max_size = 10M which
should be sufficient.

My webserver: Apache/1.3.27 (Win32) mod_gzip/1.3.19.1a PHP/4.3.2.
(using the PHP SAPI module) The problem also occurs in PHP/4.2.3 and
PHP/4.3.1.

If you need any further information or want me to test something,
please let me know. This bug is very annoying and the way I see it I'm
not the only one experiencing it.




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

#24118 [Fbk->Opn]: Error while using foreach

[young at sl dot com dot ua]

 ID:   24118
 User updated by:  young at sl dot com dot ua
 Reported By:  young at sl dot com dot ua
-Status:   Feedback
+Status:   Open
 Bug Type: Arrays related
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.2
 New Comment:

Sample code to make this bug:
";
}
?>
Return
1
4
9
16
16


Previous Comments:


[2003-06-10 17:24:46] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




[2003-06-10 17:20:10] young at sl dot com dot ua

Source code N1:
-
foreach ($sqldata as $row) {
$item = $row;
print_r($item);
}
-
Result 1:
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 230
)
-
Source code 2:
-
foreach ($sqldata as $item) {
print_r($item);
}
-
Result 2:
-
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 50
)
--




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

#22169 [Com]: Undefined variable

[DontGiveOut at BecauseOfBots dot com]

 ID:   22169
 Comment by:   DontGiveOut at BecauseOfBots dot com
 Reported By:  jjeca at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Win 2k pro
 PHP Version:  4.3.0
 New Comment:

I am attempting to port an existing app from php 4.2.2 linux (apache)
to Windows XP (iis 5.1) php 4.3.2 -> I do have register globals turned
on but I am still getting the Underfined variable messages on any
session vars.  Any one else encounter this problem?

Thanks!


Previous Comments:


[2003-02-20 08:17:35] [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-02-11 10:48:49] [EMAIL PROTECTED]

There are times when submit buttons don't pass values. I always forget
the exact circumstances so rarely rely on them but anyway, assuming
this is a post form, do:

var_dump(array('p' => $_POST, 'r' => ini_get('register_globals')));

Of course, use $_GET for GET.



[2003-02-11 10:37:59] jjeca at hotmail dot com

YES, register_globals is On!



[2003-02-11 10:20:26] [EMAIL PROTECTED]

run phpinfo() to make sure your register_globals (I assume that is the
option you are referring to) is enabled.



[2003-02-11 10:10:55] jjeca at hotmail dot com

I read all your posts about the "Undefined variable" and I changed the
php.ini global variable to On, but I still have that message when I
want to referance a $submit variable!!!

Message is : 
Notice: Undefined variable: submit in "..." on line 4
I tested it with php3 and php4 --->same thing




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

#24118 [Opn->Fbk]: Error while using foreach

[elmicha]

 ID:   24118
 Updated by:   [EMAIL PROTECTED]
 Reported By:  young at sl dot com dot ua
-Status:   Open
+Status:   Feedback
 Bug Type: Arrays related
 Operating System: FreeBSD 4.7
 PHP Version:  4.3.2
 New Comment:

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

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

Thank you for your interest in PHP.



Previous Comments:


[2003-06-10 17:20:10] young at sl dot com dot ua

Source code N1:
-
foreach ($sqldata as $row) {
$item = $row;
print_r($item);
}
-
Result 1:
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 230
)
-
Source code 2:
-
foreach ($sqldata as $item) {
print_r($item);
}
-
Result 2:
-
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 50
)
--




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

#24118 [NEW]: Error while using foreach

[young at sl dot com dot ua]

From: young at sl dot com dot ua
Operating system: FreeBSD 4.7
PHP version:  4.3.2
PHP Bug Type: Arrays related
Bug description:  Error while using foreach

Source code N1:
-
foreach ($sqldata as $row) {
$item = $row;
print_r($item);
}
-
Result 1:
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 230
)
-
Source code 2:
-
foreach ($sqldata as $item) {
print_r($item);
}
-
Result 2:
-
Array
(
[DURATION] => 7
)
Array
(
[DURATION] => 230
)
Array
(
[DURATION] => 50
)
--
-- 
Edit bug report at http://bugs.php.net/?id=24118&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24118&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24118&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24118&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24118&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24118&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24118&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24118&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24118&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24118&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24118&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24118&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24118&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24118&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24118&r=gnused

#22937 [Fbk]: Valid http:// URL does not open with fopen()

[elmicha]

 ID:   22937
 Updated by:   [EMAIL PROTECTED]
 Reported By:  freddie at bingham dot net
 Status:   Feedback
 Bug Type: HTTP related
 Operating System: Redhat 7.3
 PHP Version:  4.3.2
 Assigned To:  wez
 New Comment:

Wow - this works for me, both with 4.3.2 and the same 4.3.3-dev from
yesterday.

I don't have the slightest idea why this works, though. 


Previous Comments:


[2003-06-10 16:13:15] [EMAIL PROTECTED]

Try the following test:

http://pub133.ezboard.com/bonesixthwarriors', 'rb');
  $p2 = fopen('http://www.microsoft.com', 'rb');

?>




[2003-06-10 14:43:06] [EMAIL PROTECTED]

According to
,
this "SmallWebServer" is their own software, written in SmallTalk.
Google finds only pages inside the ezboard.com domain, so they are
probably the only ones using it.



[2003-06-09 16:12:38] [EMAIL PROTECTED]

It looks like the web server at that address doesn't like the request
headers coming in multiple packets.

Performing a strace on php shows that it is conforming to the HTTP
protocol, but the remote host does not send a response (recv call
returns 0).

To me, this sounds like a bug in the web server (I've never heard of
SmallWebServer; anyone have any info on it?).

I'm working on a write buffer for streams that will act as a workaround
for this problem, but my time is limited, so please be patient.



[2003-06-09 16:01:07] [EMAIL PROTECTED]

I'm afraid I can verify this one, both with 4.3.2 and 4.3.3-dev as of
today:

# sapi/cli/php -c php.ini-recommended -r '
$p = fopen("http://pub133.ezboard.com/bonesixthwarriors";, "rb");
var_dump($http_response_headers);
'
PHP Warning:  fopen(http://pub133.ezboard.com/bonesixthwarriors):
failed to open stream: HTTP request failed! à|ïc  in Command
line code on line 2
PHP Notice:  Undefined variable:  http_response_headers in Command line
code on line 3
NULL
# 

Configured only with --enable-debug --disable-mbstring, it's the same
problem, but slightly different junk characters in the error message.
Otherwise these junk characters are always the same (for the same
build).



[2003-06-09 10:33:14] freddie at bingham dot net

NULL

The fact that you are asking me this implies that it works for you on
4.3.2 or you are unable to test it on 4.3.2. Is that the case?



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

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

#24117 [Opn->Bgs]: Would be useful if PHP with "enable-trans-sid" modified "Location" header field

[derick]

 ID:   24117
 Updated by:   [EMAIL PROTECTED]
 Reported By:  marekm at aptus dot pl
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.3.2
 New Comment:

1. You need to always use a full absolute URI in the Location: header,
and 2. You can add the SID yourself as described here:
http://www.php.net/manual/en/ref.session.php#session.constants


Previous Comments:


[2003-06-10 16:15:25] marekm at aptus dot pl

I've just tested my session-using-site with cookies disabled in the
browser and noticed, that PHP doesn't always propagate session SID
(even with enable-trans-sid).
The problem is that I often use:

Header("Location: somewhere.php");

which doesn't propagate session id. 

I think, it would be nice if PHP modified the header field
automatically the same way it is done in A HREF's.

Regards,
Marek Matula





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

#24117 [NEW]: Would be useful if PHP with "enable-trans-sid" modified "Location" header field

[marekm at aptus dot pl]

From: marekm at aptus dot pl
Operating system: Linux
PHP version:  4.3.2
PHP Bug Type: Feature/Change Request
Bug description:  Would be useful if PHP with "enable-trans-sid" modified "Location" 
header field

I've just tested my session-using-site with cookies disabled in the browser
and noticed, that PHP doesn't always propagate session SID (even with
enable-trans-sid).
The problem is that I often use:

Header("Location: somewhere.php");

which doesn't propagate session id. 

I think, it would be nice if PHP modified the header field automatically
the same way it is done in A HREF's.

Regards,
Marek Matula

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

#22937 [Asn->Fbk]: Valid http:// URL does not open with fopen()

[pollita]

 ID:   22937
 Updated by:   [EMAIL PROTECTED]
 Reported By:  freddie at bingham dot net
-Status:   Assigned
+Status:   Feedback
 Bug Type: HTTP related
 Operating System: Redhat 7.3
 PHP Version:  4.3.2
 Assigned To:  wez
 New Comment:

Try the following test:

http://pub133.ezboard.com/bonesixthwarriors', 'rb');
  $p2 = fopen('http://www.microsoft.com', 'rb');

?>



Previous Comments:


[2003-06-10 14:43:06] [EMAIL PROTECTED]

According to
,
this "SmallWebServer" is their own software, written in SmallTalk.
Google finds only pages inside the ezboard.com domain, so they are
probably the only ones using it.



[2003-06-09 16:12:38] [EMAIL PROTECTED]

It looks like the web server at that address doesn't like the request
headers coming in multiple packets.

Performing a strace on php shows that it is conforming to the HTTP
protocol, but the remote host does not send a response (recv call
returns 0).

To me, this sounds like a bug in the web server (I've never heard of
SmallWebServer; anyone have any info on it?).

I'm working on a write buffer for streams that will act as a workaround
for this problem, but my time is limited, so please be patient.



[2003-06-09 16:01:07] [EMAIL PROTECTED]

I'm afraid I can verify this one, both with 4.3.2 and 4.3.3-dev as of
today:

# sapi/cli/php -c php.ini-recommended -r '
$p = fopen("http://pub133.ezboard.com/bonesixthwarriors";, "rb");
var_dump($http_response_headers);
'
PHP Warning:  fopen(http://pub133.ezboard.com/bonesixthwarriors):
failed to open stream: HTTP request failed! à|ïc  in Command
line code on line 2
PHP Notice:  Undefined variable:  http_response_headers in Command line
code on line 3
NULL
# 

Configured only with --enable-debug --disable-mbstring, it's the same
problem, but slightly different junk characters in the error message.
Otherwise these junk characters are always the same (for the same
build).



[2003-06-09 10:33:14] freddie at bingham dot net

NULL

The fact that you are asking me this implies that it works for you on
4.3.2 or you are unable to test it on 4.3.2. Is that the case?



[2003-06-09 09:41:10] [EMAIL PROTECTED]

*sigh*

Please provide the information I requested.

http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?>

and paste the result here.




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

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

#22937 [Asn]: Valid http:// URL does not open with fopen()

[elmicha]

 ID:   22937
 Updated by:   [EMAIL PROTECTED]
 Reported By:  freddie at bingham dot net
 Status:   Assigned
 Bug Type: HTTP related
 Operating System: Redhat 7.3
 PHP Version:  4.3.2
 Assigned To:  wez
 New Comment:

According to
,
this "SmallWebServer" is their own software, written in SmallTalk.
Google finds only pages inside the ezboard.com domain, so they are
probably the only ones using it.


Previous Comments:


[2003-06-09 16:12:38] [EMAIL PROTECTED]

It looks like the web server at that address doesn't like the request
headers coming in multiple packets.

Performing a strace on php shows that it is conforming to the HTTP
protocol, but the remote host does not send a response (recv call
returns 0).

To me, this sounds like a bug in the web server (I've never heard of
SmallWebServer; anyone have any info on it?).

I'm working on a write buffer for streams that will act as a workaround
for this problem, but my time is limited, so please be patient.



[2003-06-09 16:01:07] [EMAIL PROTECTED]

I'm afraid I can verify this one, both with 4.3.2 and 4.3.3-dev as of
today:

# sapi/cli/php -c php.ini-recommended -r '
$p = fopen("http://pub133.ezboard.com/bonesixthwarriors";, "rb");
var_dump($http_response_headers);
'
PHP Warning:  fopen(http://pub133.ezboard.com/bonesixthwarriors):
failed to open stream: HTTP request failed! à|ïc  in Command
line code on line 2
PHP Notice:  Undefined variable:  http_response_headers in Command line
code on line 3
NULL
# 

Configured only with --enable-debug --disable-mbstring, it's the same
problem, but slightly different junk characters in the error message.
Otherwise these junk characters are always the same (for the same
build).



[2003-06-09 10:33:14] freddie at bingham dot net

NULL

The fact that you are asking me this implies that it works for you on
4.3.2 or you are unable to test it on 4.3.2. Is that the case?



[2003-06-09 09:41:10] [EMAIL PROTECTED]

*sigh*

Please provide the information I requested.

http://pub133.ezboard.com/bonesixthwarriors', 'rb');
var_dump($http_response_headers);
?>

and paste the result here.




[2003-06-09 09:19:19] freddie at bingham dot net

Can we please stick to the bug that I have reported. Thanks.

My script works in everything before 4.3.0. What had changed to break a
valid URL from being opened with fopen() and why was I told it was
fixed in the PRE released 4.3.2, to only find it is still broken in
4.3.2



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

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

#23760 [Bgs]: bizarre session variable behavior only in RC4

[php-general at pennysaverusa dot net]

 ID:   23760
 User updated by:  php-general at pennysaverusa dot net
 Reported By:  php-general at pennysaverusa dot net
 Status:   Bogus
 Bug Type: Apache related
 Operating System: RedHat 7.3
 PHP Version:  4.3.2RC4
 New Comment:

Hi Sniper, 

I have session_auto_start ON.

I didn't think that the extension was that meaningful (as is usually
the case in UNIX). I made it .php for security (so no one can list the
file in a browser). The docs did not seem to indicate that this would
be a problem.

Also, the docs now say you can use virtual with php.

It does crash... "child pid 7413 exit signal Segmentation
fault (11)" in apache error log.

If it won't/can't be fixed, I suggest:
1. improve the documentation to say what not to do.
2. have the virtual function give a warning or error if the user does
something bad.

Thank you,
Barry


Previous Comments:


[2003-06-09 23:39:00] [EMAIL PROTECTED]

First of all, your example stuff is totally bogus. 
. There is no session_start() anywhere
. You include pure html as php using virtual when you should be using
include()

Second, it never crashes, of course you don't get any core files.

Third, there are easier ways to shoot yourself in leg too,
but we still don't suggest you should do it.

Fourth, as long as you can't provide us any example that actually has
any far possibility on working and uses some
sane ways on doing things, this is bogus.

Phillip: virtual() might work for including php files, but the result
is still unpredictable..






[2003-06-09 20:00:24] barrygould at pennysaverusa dot net

Philip, did you try the test files I linked?

Thanks,
Barry



[2003-06-09 19:57:36] php-general at pennysaverusa dot net

Someone changed the online docs VERY recently, however I'm sure there
is a problem here.

I did "ulimit -c unlimited", and then ran apache manually (with all the
-DHAVEs) but no core file was produced.

Thanks,
Barry



[2003-06-07 09:21:59] [EMAIL PROTECTED]

virtual() works fine on PHP files, as documented (although I can't test
old versions), so I believe sniper was just mistaken and don't see
anything here to document.

Barry, are you sure you set the ulimit before the backtrace?  That's
extremely important.  I'm unable to reproduce and changing back to
Apache related.



[2003-06-07 05:04:30] [EMAIL PROTECTED]

What sniper says is not in line with the current manual. The current
manual says that as of PHP 4.0.6 virtual() can be used on PHP files. So
the manual is not correct I assume. Changing this to be a doc 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/23760

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

#24103 [Com]: After I upgraded from PHP-4.3.1 to 4.3.2 my Apache module mod_rewrite crashes

[php at gorf dot org]

 ID:   24103
 Comment by:   php at gorf dot org
 Reported By:  hlj at viamidia dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: FreeBSD 4.6
 PHP Version:  4.3.2
 New Comment:

I'm having the same problem using FreeBSD 4.8-STABLE.

I thought I had the problem fixed when I upgraded cclient to
2002c1_1,1, but now it crashes with signal-10 instead of 11 8-(


Previous Comments:


[2003-06-09 17:11:09] hlj at viamidia dot com

- To reproduce the problem, you can install apache-1.3.27(default 
modules including mod_rewrite)+php-4.3.1(linked with the imap-uw 
imap access library) and configure some rewrite rules in httpd.conf,
this 
will work (it works for me for years).  After you upgrade php to 4.3.2

version (and don't change anything else) the mod_rewrite rules simply 
stop working and crashes the httpd process that was serving the 
request (Jun  8 00:01:58 www /kernel: pid 59615 (httpd), uid 80: exited

on signal 11)

-my configure line was: ./configure  --with-apxs=/usr/local/sbin/apxs 
--disable-debug --enable-track-vars --disable-pear --without-gd 
--with-imap=/usr/local --with-mysql

- Nothing else was changed.  The problem started right after the PHP 
upgrade (from 4.3.1 to 4.3.2) that I did exactly as I am doing for
years 
(since php 3.x).




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

#24115 [Opn->Fbk]: dbase_get_record() crashes on some files

[sniper]

 ID:   24115
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hensle at teq-services dot com
-Status:   Open
+Status:   Feedback
-Bug Type: Reproducible crash
+Bug Type: dBase related
 Operating System: winNT
 PHP Version:  4.3.2
 New Comment:

Please provide a full URL to this file in question.



Previous Comments:


[2003-06-10 12:19:59] hensle at teq-services dot com

using php_dbase.dll dated feb 15 2003



[2003-06-10 12:10:05] hensle at teq-services dot com

The following code will crash with *some*
dbf files. The dbf can be found
at the US census site: Congressional districts
for the entire US=cd99_108.zip







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

#24115 [Opn]: dbase_get_record() crashes on some files

[hensle at teq-services dot com]

 ID:   24115
 User updated by:  hensle at teq-services dot com
 Reported By:  hensle at teq-services dot com
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: winNT
 PHP Version:  4.3.2
 New Comment:

using php_dbase.dll dated feb 15 2003


Previous Comments:


[2003-06-10 12:10:05] hensle at teq-services dot com

The following code will crash with *some*
dbf files. The dbf can be found
at the US census site: Congressional districts
for the entire US=cd99_108.zip







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

#24116 [NEW]: Enhancement: extract() takes array of keys

[kop at meme dot com]

From: kop at meme dot com
Operating system: All
PHP version:  4.3.2
PHP Bug Type: Arrays related
Bug description:  Enhancement: extract() takes array of keys

I want to get variables passed from the client into local (not global)
variables.  If the variable has not been passed from the client I do not
want a local variable defined.  While this can be coded for each variable
I want to do this with, there is no way to abstract this operation into a
function.

The (untested) code to get a form variable 'foo' would be:

if (array_key_exists($_POST, 'foo') {
  $foo = &{$_POST['foo'])}
}
// $foo may or may not be defined, so if I've got strict
// error checking on I get a nice error if I ref an undefined
//variable.  And, $foo is nice and local so it won't show
// where I don't send it.

If extract() took an array of keys as another argument, extracting only
those keys that are in the list, I could get the form variables, foo, bar,
and baz with:

extract($_POST, EXTR_REFS, '', array('foo', 'bar', 'baz'));

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

#24104 [Fbk->Opn]: make failure

[wax at y12 dot doe dot gov]

 ID:   24104
 User updated by:  wax at y12 dot doe dot gov
 Reported By:  wax at y12 dot doe dot gov
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: OSF1 V4.0 878 alpha
 PHP Version:  4.3.2
 New Comment:

OK ran it with GCC 2.7.2.2 and this happened:

gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend 
-I/u00/wax/php-4.3.2/TSRM  -g -O2  -c
/u00/wax/php-4.3.2/Zend/zend_variables.c -o Zend/zend_variables.o  &&
echo > Zend/zend_variables.lo
gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend 
-I/u00/wax/php-4.3.2/TSRM  -g -O2  -c /u00/wax/php-4.3.2/Zend/zend.c -o
Zend/zend.o  && echo > Zend/zend.lo
/u00/wax/php-4.3.2/Zend/zend.c: In function `zend_error':
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__base' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
*** Exit 1

Ran it with GCC 2.95.2

gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend 
-I/u00/wax/php-4.3.2/TSRM  -g -O2  -c
/u00/wax/php-4.3.2/Zend/zend_variables.c -o Zend/zend_variables.o  &&
echo > Zend/zend_variables.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend_variables.c:22:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend 
-I/u00/wax/php-4.3.2/TSRM  -g -O2  -c /u00/wax/php-4.3.2/Zend/zend.c -o
Zend/zend.o  && echo > Zend/zend.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend.c:21:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
/u00/wax/php-4.3.2/Zend/zend.c: In function `zend_error':
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__base' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
make: *** [Zend/zend.lo] Error 1

OK I have tried that on php-4.3.2 & php4-STABLE-200306092130... Same
result.  Due to this I am trying to get php-3.0.18 installed just to
see if that will work and then work my way up...  Does that sound like
a good idea??  I have tried doing the CC=cc ./configure thing... no
good... also tried CC=cc make and still nothing... Is there any
information you need from me to help debug this issue?


Previous Comments:


[2003-06-10 11:56:52] [EMAIL PROTECTED]

Yes, try this:

# rm config.cache && ./configure --disable-all --disable-cgi && make
clean && make






[2003-06-10 10:23:30] wax at y12 dot doe dot gov

OK I have it using GCC 2.95.2 ...

Here is the error message now:

gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend -I/opt/local/include
-I/u00/wax/php-4.3.2/ext/xml/expat  -I/u00/wax/php-4.3.2/TSRM  -g -O2 
-c /u00/wax/php-4.3.2/Zend/zend_variables.c -o Zend/zend_variables.o 
&& echo > Zend/zend_variables.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend_variables.c:22:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/inc

#24115 [NEW]: dbase_get_record() crashes on some files

[hensle at teq-services dot com]

From: hensle at teq-services dot com
Operating system: winNT
PHP version:  4.3.2
PHP Bug Type: Reproducible crash
Bug description:  dbase_get_record() crashes on some files

The following code will crash with *some*
dbf files. The dbf can be found
at the US census site: Congressional districts
for the entire US=cd99_108.zip



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

#21653 [Com]: Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect failed

[laudanp at yahoo dot com]

 ID:   21653
 Comment by:   laudanp at yahoo dot com
 Reported By:  support at hostcolor dot com
 Status:   No Feedback
 Bug Type: Sockets related
 Operating System: RedHat 7.2
 PHP Version:  4.3.0
 New Comment:

My current host has not done this whatsoever, we have obtained another
server with another host.  We'll be working on it this week.  On the
new server we see the same exact error as on the current server at
computercops.biz.  So the new server will have the CVS build
installed.

Cross your fingers.  (crossing ours)


Previous Comments:


[2003-06-03 14:37:29] scmvs at cs dot cf dot ac dot uk

I experience the same problem with fsockopen. Is this ever going to be
fixed? (I am using PHP 4.3.2)



[2003-05-15 01:02:18] davideturner at hotmail dot com

Warning: fsockopen() [function.fsockopen]: php_hostconnect: connect
failed in /home/x/include/EnomInterface_inc.php on line 140

Warning: fsockopen() [function.fsockopen]: unable to connect to
resellertest.enom.com:80 in
/home/x/include/EnomInterface_inc.php on line 140

Fatal error: Call to undefined function: strerror() in
/home/x/include/EnomInterface_inc.php on line 142



Line 140+
$address = gethostbyname( $host );

// Create a TCP/IP socket.
$socket = fsockopen($host,80); 
if ( !$socket ) {
$this->AddError( "socket() failed: " . strerror( $socket ) );



[2003-05-15 00:56:40] davideturner at hotmail dot com

I am receiving the same issue with eNoms app. Worked in 4.2.3 now
receive that error with 4.3.1.



[2003-05-09 07:25:56] [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-05-05 13:39:43] laudanp at yahoo dot com

My issue still hasn't been resolved because we still haven't traveled
down your recommended path.  Someone at my provider is looking into
this for me.



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

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

#24104 [Opn->Fbk]: make failure

[sniper]

 ID:   24104
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wax at y12 dot doe dot gov
-Status:   Open
+Status:   Feedback
 Bug Type: Compile Failure
 Operating System: OSF1 V4.0 878 alpha
 PHP Version:  4.3.2
 New Comment:

Yes, try this:

# rm config.cache && ./configure --disable-all --disable-cgi && make
clean && make





Previous Comments:


[2003-06-10 10:23:30] wax at y12 dot doe dot gov

OK I have it using GCC 2.95.2 ...

Here is the error message now:

gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend -I/opt/local/include
-I/u00/wax/php-4.3.2/ext/xml/expat  -I/u00/wax/php-4.3.2/TSRM  -g -O2 
-c /u00/wax/php-4.3.2/Zend/zend_variables.c -o Zend/zend_variables.o 
&& echo > Zend/zend_variables.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend_variables.c:22:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend -I/opt/local/include
-I/u00/wax/php-4.3.2/ext/xml/expat  -I/u00/wax/php-4.3.2/TSRM  -g -O2 
-c /u00/wax/php-4.3.2/Zend/zend.c -o Zend/zend.o  && echo >
Zend/zend.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend.c:21:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
/u00/wax/php-4.3.2/Zend/zend.c: In function `zend_error':
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__base' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
make: *** [Zend/zend.lo] Error 1


webdev# gcc -v 

Reading specs from /opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/specs
gcc version 2.95.2 19991024 (release)


Anymore suggesionts?



[2003-06-09 23:04:01] [EMAIL PROTECTED]

Please ignore the previous comment, neither of those compilers are
'stable' in the way 2.95.3 is for example.




[2003-06-09 18:52:48] [EMAIL PROTECTED]

Please try with a stable compiler such as gcc 2.96 or 
3.2.3. 
You could also try with Tru64's compiler (CC=cc 
./configure). I personally haven't seen anything like this 
with 4.3.2 on Tru64. 



[2003-06-09 17:45:18] wax at y12 dot doe dot gov

I do this as a configure string:

./configure --prefix=/opt/local/stow/php-4.3.2 --with-mysql
--with-apache=/usr/local/apache --with-zlib=/opt/local
--with-zlib-dir=~wax/zlib --with-gd=/opt/local
--with-jpeg-dir=/opt/local --with-png=/opt/local

My GCC version is 2.7.2.2 .

It works fine it seems... I then run make and I get this:

gcc  -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main
-I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include
-I/u00/wax/php-4.3.3/ext/xml/expat  -I/u00/wax/php-4.3.3/TSRM  -g -O2 
-c /u00/wax/php-4.3.3/Zend/zend_stack.c -o Zend/zend_stack.o  && echo >
Zend/zend_stack.lo
gcc  -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main
-I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include
-I/u00/wax/php-4.3.3/ext/xml/expat  -I/u00/wax/php-4.3.3/TSRM  -g -O2 
-c /u00/wax/php-4.3.3/Zend/zend_variables.c -o Zend/zend_variables.o 
&& echo > Zend/zend_variables.lo
gcc  -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main
-I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include
-I/u00/wax/php-4.3.3/ext/xml/expat  -I/u00/wax/php-4.3.3/TSRM  -g -O2 
-c /u00/wax/php-4.3.3/Zend/zend.c -o Zend/zend.o  && echo >
Zend/zend.lo
/u00/wax/php-4.3.3/Zend/zend.c: In function `zend_error':
/u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__base'

#24114 [Opn->Bgs]: include_path option

[sniper]

 ID:   24114
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stefano dot cecconi at staff dot aruba dot it
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: windows 2000
 PHP Version:  4.3.2
 New Comment:

This was already 'broken' (actually it was another bug that was fixed)
in PHP 4.3.0. Current behaviour is the correct and documented one.

There is no reason to break it again.




Previous Comments:


[2003-06-10 10:35:09] stefano dot cecconi at staff dot aruba dot it

Php 4.2.3 works in a different way.

Even with the / it works. 

A lot of free php scripts are written with this notation.

Now they don't work anymore.

Try to think to 200.000 domain in hosting (we are the web hosting
company) where all people working with php and includes have to change
their scripts.

It's not so easy, right?



[2003-06-10 09:44:09] [EMAIL PROTECTED]

Your version should never have worked... it's not a bug at all that you
need to strip that / (it will make PHP to open
c:/call_php/counter.php)...



[2003-06-10 09:09:41] stefano dot cecconi at staff dot aruba dot it

This is my include_path option value :

include_path = ".;c:\php\includes"

Before 4.3.2 everything worked using this path in a script : 

include "/call_php/counter.php"

With 4.3.2 is mandatory to remove the first / so it works only with
this path :

include "call_php/counter.php"

or 

include "./call_php/counter.php"

I can't understand this change and it's creating a lot of problems for
our web hosting service, simply because there are thousands of scripts
based on the old way to use relative paths.








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

#16249 [Com]: redeclare class when session_start()

[phpbugs at sauen dot com]

 ID:   16249
 Comment by:   phpbugs at sauen dot com
 Reported By:  ilker dot cetinkaya at ease dot de
 Status:   Closed
 Bug Type: Session related
 Operating System: Windows 2000
 PHP Version:  4.1.1
 New Comment:

This problem persists in 4.1.2 as well, although not so severe
(perhaps). Debian Woody uptodate packages of Apache 1.3.2x and PHP
4.1.2, Kernel 2.4.18 (LIDS patched). Up and running fine for 60 days,
all the sudden giving such "Cannot redeclare class.." errors on
frequent reloads, wait a minute and it works again for a while.. I have
both Apache and Apache-SSL installed, seems to be the same no matter
which I try. Stopping and starting Apache and Apache-SSL made no
difference.. Rebooting the machine did, we'll see how long it lasts
now, I have no idea if it is mod_php, apache or kernel related (or
LIDS)..


Previous Comments:


[2002-03-25 07:41:47] [EMAIL PROTECTED]

If it works, we close it.

Derick



[2002-03-25 04:40:31] ilker dot cetinkaya at ease dot de

hint:

on php4.1.2 with same config as above the problem does not exist.

good work.
thanks
ilker



[2002-03-25 03:48:40] ilker dot cetinkaya at ease dot de

first of all, i want to mention that this behaviour appeared several
times before i experienced it; please refer to 
http://bugs.php.net/bug.php?id=10790

which has been set to closed (although nothing was fixed on it).

what i want to report you as a definitive bug is reproduceable with a
simple script:



on first hit, i see following output:

Warning: open(/tmp\sess_62fb47f4ea53d0ee595c5c7ebce98559, O_RDWR)
failed: No such file or directory (2) in C:\test_bug.php on line 8

this is correct because default session provider in php.ini is file and
my tmp directory doesn't have sufficient permissions.

hittig the script again produces this:

Fatal error: Cannot redeclare class tester in C:\test_bug.php on line
3

this is totally wrong. i do not redeclare anything on this script. it
is the very first coding line which this fatal error references.

if you hit the page more often you'll see the fatal error every 2nd
hit. this behaviour has been also complained in bug id 10790.

but i guess sniper didn't see it serious enough to make some heavy
reproducement tests.

the reason why this is a session related bug is because of
session_start() function call.

if you leave out session_start(), everything works fine.

i want to empasize once more that i could reproduce the bug on several
boxes running php4.1.1 on w2k/iis5.

here's my config:
windows 2000 (pro & server), sp2
iis5 running php_isapi.dll
extensions oci, xslt, gd, dom
php 4.1.1 isapi enabled

hth
ilker





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

#24114 [Fbk->Opn]: include_path option

[stefano dot cecconi at staff dot aruba dot it]

 ID:   24114
 User updated by:  stefano dot cecconi at staff dot aruba dot it
 Reported By:  stefano dot cecconi at staff dot aruba dot it
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: windows 2000
 PHP Version:  4.3.2
 New Comment:

Php 4.2.3 works in a different way.

Even with the / it works. 

A lot of free php scripts are written with this notation.

Now they don't work anymore.

Try to think to 200.000 domain in hosting (we are the web hosting
company) where all people working with php and includes have to change
their scripts.

It's not so easy, right?


Previous Comments:


[2003-06-10 09:44:09] [EMAIL PROTECTED]

Your version should never have worked... it's not a bug at all that you
need to strip that / (it will make PHP to open
c:/call_php/counter.php)...



[2003-06-10 09:09:41] stefano dot cecconi at staff dot aruba dot it

This is my include_path option value :

include_path = ".;c:\php\includes"

Before 4.3.2 everything worked using this path in a script : 

include "/call_php/counter.php"

With 4.3.2 is mandatory to remove the first / so it works only with
this path :

include "call_php/counter.php"

or 

include "./call_php/counter.php"

I can't understand this change and it's creating a lot of problems for
our web hosting service, simply because there are thousands of scripts
based on the old way to use relative paths.








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

#17606 [Com]: File upload fails on large files

[j dot henshaw at ulster dot ac dot uk]

 ID:   17606
 Comment by:   j dot henshaw at ulster dot ac dot uk
 Reported By:  luimarma at iti dot upv dot es
 Status:   Closed
 Bug Type: HTTP related
 Operating System: RedHat 7.3
 PHP Version:  4.2.1
 New Comment:

with reference to "[9 Jan 8:56am CST] OK, problem solved - here's what
I did" 

(I just found this thread ... and thanks to all that contributed, 'cos
you helped me fix my box.)

The reboot was not necessary. 

However, the php.ini file is only read when apache starts. So issue
"service httpd restart" command and your changes to php.ini are read
when apache restarts.

No way will Linux ever behave like a windoze box!


Previous Comments:


[2003-06-03 02:42:26] luimarma at iti dot upv dot es

Use a newer php version, versions under 4.2 have this feature 
broken.



[2003-06-02 19:45:56] aiphuong1001 at yahoo dot com

It doesn't work for my case. What did I do wrong?
I'm using PHP version 4.1.2, apache 1.3.26 on Mac OS X and 
trying to upload a 200M file via Internet Explorer with the 
setting in php.ini:

max_execution_time = 3
max_input_time = 3
memory_limit = 2000M
post_max_size = 2000M
file_uploads = On
;upload_tmp_dir = 
upload_max_filesize = 2000M
allow_url_fopen = On

and in http.conf:
Timeout = 3
MaxKeepAliveRequests = 5

The result is that the progress bar keeps showing 3/10 of 
the bar, the spinning wheel keeps spinning  and the 
uploading never ends for hours.

Files under 50M are uploaded successfully though. In my php 
code, I direct the uploaded files to a specific folder in 
the server. So, Is the upload_tmp_dir used at all? By the 
way, where is this folder? How can I check whether the 
upload eats sytem memory or not?
This task is so important to me. Please help!!!
Thanks so much.



[2003-02-12 02:33:12] simone at cisbic dot com

Someone found a solution for old PHP like 4.0.6?



[2003-01-09 08:56:03] mlampard at excite dot com

OK, problem solved - here's what I did:
Initially this box had redhat stock apache and php installs, so I blew
those installs away (rpm -e) and installed apache 1.3.26 and PHP 4.2.3
from source. This is when I first posted my issue here, as I still
couldn't upload large files. I played with all the ini file parameters
and a few of the apache conf parameters, but all to no avail - the
script just would not write to any temp directory. The ulimit was set
to unlimited, no disk quotas, plenty of available disk space, memory
available etc etc. Everything looked fine and healthy and everything
else on the box worked just fine. In desperation, I finally rebooted
the box (it hadn't been down in years) and voila, now it magically
works! This scares me somewhat - a linux box behaving like a windows
box! So, I still don't know the cause of the issue, but thankfully it
now works and I guess this one will go into the "unknown" black
cloud
Thanks to everyone, especially Luis, for your help with this.
Marty.



[2002-12-24 13:52:00] mlampard at excite dot com

Not yet - still unresolved! I've had to setup a different machine for
these people to use. Funnily enough, the new machine is configured
identically (and I mean IDENTICALLY) to the old machine, but it works
just fine. I'm starting to wonder if there's some sort of kernel
bug.



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

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

#24104 [Fbk->Opn]: make failure

[wax at y12 dot doe dot gov]

 ID:   24104
 User updated by:  wax at y12 dot doe dot gov
 Reported By:  wax at y12 dot doe dot gov
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: OSF1 V4.0 878 alpha
 PHP Version:  4.3.2
 New Comment:

OK I have it using GCC 2.95.2 ...

Here is the error message now:

gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend -I/opt/local/include
-I/u00/wax/php-4.3.2/ext/xml/expat  -I/u00/wax/php-4.3.2/TSRM  -g -O2 
-c /u00/wax/php-4.3.2/Zend/zend_variables.c -o Zend/zend_variables.o 
&& echo > Zend/zend_variables.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend_variables.c:22:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
gcc  -IZend/ -I/u00/wax/php-4.3.2/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.2/include -I/u00/wax/php-4.3.2/main
-I/u00/wax/php-4.3.2 -I/u00/wax/php-4.3.2/Zend -I/opt/local/include
-I/u00/wax/php-4.3.2/ext/xml/expat  -I/u00/wax/php-4.3.2/TSRM  -g -O2 
-c /u00/wax/php-4.3.2/Zend/zend.c -o Zend/zend.o  && echo >
Zend/zend.lo
In file included from
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/stdarg.h:36,
 from /u00/wax/php-4.3.2/Zend/zend.h:63,
 from /u00/wax/php-4.3.2/Zend/zend.c:21:
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
/u00/wax/php-4.3.2/Zend/zend.c: In function `zend_error':
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__base' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.2/Zend/zend.c:763: request for member `__offset' in
something not a structure or union
make: *** [Zend/zend.lo] Error 1


webdev# gcc -v 

Reading specs from /opt/gnu/lib/gcc-lib/alpha-dec-osf4.0d/2.95.2/specs
gcc version 2.95.2 19991024 (release)


Anymore suggesionts?


Previous Comments:


[2003-06-09 23:04:01] [EMAIL PROTECTED]

Please ignore the previous comment, neither of those compilers are
'stable' in the way 2.95.3 is for example.




[2003-06-09 18:52:48] [EMAIL PROTECTED]

Please try with a stable compiler such as gcc 2.96 or 
3.2.3. 
You could also try with Tru64's compiler (CC=cc 
./configure). I personally haven't seen anything like this 
with 4.3.2 on Tru64. 



[2003-06-09 17:45:18] wax at y12 dot doe dot gov

I do this as a configure string:

./configure --prefix=/opt/local/stow/php-4.3.2 --with-mysql
--with-apache=/usr/local/apache --with-zlib=/opt/local
--with-zlib-dir=~wax/zlib --with-gd=/opt/local
--with-jpeg-dir=/opt/local --with-png=/opt/local

My GCC version is 2.7.2.2 .

It works fine it seems... I then run make and I get this:

gcc  -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main
-I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include
-I/u00/wax/php-4.3.3/ext/xml/expat  -I/u00/wax/php-4.3.3/TSRM  -g -O2 
-c /u00/wax/php-4.3.3/Zend/zend_stack.c -o Zend/zend_stack.o  && echo >
Zend/zend_stack.lo
gcc  -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main
-I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include
-I/u00/wax/php-4.3.3/ext/xml/expat  -I/u00/wax/php-4.3.3/TSRM  -g -O2 
-c /u00/wax/php-4.3.3/Zend/zend_variables.c -o Zend/zend_variables.o 
&& echo > Zend/zend_variables.lo
gcc  -IZend/ -I/u00/wax/php-4.3.3/Zend/ -DPHP_ATOM_INC
-I/u00/wax/php-4.3.3/include -I/u00/wax/php-4.3.3/main
-I/u00/wax/php-4.3.3 -I/u00/wax/php-4.3.3/Zend -I/opt/local/include
-I/u00/wax/php-4.3.3/ext/xml/expat  -I/u00/wax/php-4.3.3/TSRM  -g -O2 
-c /u00/wax/php-4.3.3/Zend/zend.c -o Zend/zend.o  && echo >
Zend/zend.lo
/u00/wax/php-4.3.3/Zend/zend.c: In function `zend_error':
/u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__base' in
something not a structure or union
/u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in
something not a structure or union
/u00/wax/php-4.3.3/Zend/zend.c:780: request for member `__offset' in
someth

#24101 [Bgs]: socket_select call is blocking and never returning

[wzaccone at telcordia dot com]

 ID:   24101
 User updated by:  wzaccone at telcordia dot com
 Reported By:  wzaccone at telcordia dot com
 Status:   Bogus
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

I can only assume it was working by accident with 4.1.2.  We have
changed our code today to use streams_select as per your advice, and
the problem has been solved. Thanks very much for your assistance.


Previous Comments:


[2003-06-10 09:39:45] [EMAIL PROTECTED]

Looking at the CVS history, there is no way that your code should work
in 4.1.2 (socket_select() didn't even accept arrays as parameters back
then), nor even in 4.2.x (which only accepted the socket extensions own
descriptors).  The chances are that it only worked as a fluke.

The sockets extension has always been documented as experimental, so
functionality change from flaky code that is 18 months old is allowed,
without notice.

It is highly recommended that you update your code to use the
stream_select() function provided in PHP 4.3.x, as it is more flexible
and an officially supported (stable!) API.

This is not a bug in PHP, so I'm marking this report as Bogus.



[2003-06-10 09:23:25] wzaccone at telcordia dot com

thank you for the info.. we were previously using socket_select and
fread successfully with 4.1.2 and went live with an application doing
so.  For our next release, we upgraded to PHP 4.3.2 and it stopped
working.  Can I assume that this behavior has changed with 4.3.2??
therefore we must migrate to using streams_select to upgrade to 4.3.2?



[2003-06-10 09:19:12] [EMAIL PROTECTED]

You can't use fread() on sockets returned from the sockets extension,
and likewise, you can use socket_select() on streams returned from
fopen() or fsockopen().

Perhaps you meant to use stream_select() instead?



[2003-06-10 09:02:26] wzaccone at telcordia dot com

function readMsgsFromHosts($sockets){
  
   set_time_limit(0);
   $numSockets = count($sockets);
   
   $keys = array_keys($sockets);

   $socketsCopy = Array();

foreach ($keys as $key){
  $socketsCopy[$key] = $sockets[$key];
}

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL)
!== FALSE){

  foreach($socketsCopy as $sock){

  $string = fread($sock, $readAmount);



[2003-06-09 23:40:31] [EMAIL PROTECTED]

Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)




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

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

#24114 [Opn->Fbk]: include_path option

[derick]

 ID:   24114
 Updated by:   [EMAIL PROTECTED]
 Reported By:  stefano dot cecconi at staff dot aruba dot it
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: windows 2000
 PHP Version:  4.3.2
 New Comment:

Your version should never have worked... it's not a bug at all that you
need to strip that / (it will make PHP to open
c:/call_php/counter.php)...


Previous Comments:


[2003-06-10 09:09:41] stefano dot cecconi at staff dot aruba dot it

This is my include_path option value :

include_path = ".;c:\php\includes"

Before 4.3.2 everything worked using this path in a script : 

include "/call_php/counter.php"

With 4.3.2 is mandatory to remove the first / so it works only with
this path :

include "call_php/counter.php"

or 

include "./call_php/counter.php"

I can't understand this change and it's creating a lot of problems for
our web hosting service, simply because there are thousands of scripts
based on the old way to use relative paths.








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

#24112 [Opn]: php_admin_value defaults - open_basedir

[pd at pauldemarco dot com]

 ID:   24112
 User updated by:  pd at pauldemarco dot com
 Reported By:  pd at pauldemarco dot com
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: redhat 7.3
 PHP Version:  4.3.2
 New Comment:

ignore the message about /tmp, due to the previousily mentioned
randomness, it appeared to go away, but is still present, explicitly
setting the open_basedir at the virtual host level is the only thing
that removes the error consistently


Previous Comments:


[2003-06-10 09:32:23] pd at pauldemarco dot com

if someone can confirm the behavorial difference on this between 4.3.0
and 4.3.2

Does 4.3.0 automatically add /tmp/ to open_basedir, but 4.3.2 does not?
 This is a phpbb installation, its failing on its cached templating
files, and occasionally on file uploads.  If the above /tmp behavior is
correct, then that would explain why it breaks in 4.3.2, however the
error messages are still very wrong as they list other virtual-hosts
open_basedir settings



[2003-06-10 08:19:07] pd at pauldemarco dot com

This problem does not occur on 4.3.0, with the same configure line (any
basic configuration will do).  Sadly, I cannot provide any real error
information, as it is not crashing, but the behavior is fairly
predictable.

I have a open_basedir setting in php.ini, confirmed via phpinfo(), its
value is not important.  On each of the configured virtual hosts I have
a different value using php_admin_value.  However, on some virtual
hosts I turn safe_mode off using php_admin_flag and do not set an
open_basedir value, so it should be using the php.ini setting.  Turning
safe mode off is probably not relevant, but trying to provide any
related information.

When requesting pages on that virtual host (the one with no overriding
open_basedir setting, and safe mode off), the requests will randomly
fail.  When checking the error log, it is a normal exit and php is
logging that 'open_basedir restriction in effect ... '

The path that it provides as the active open_basedir value is not
correct.  It in fact randomly changes to other virtual hosts settings. 
It does not always fail, it may take 20 requests before it does (even a
simple auto-refreshing page, will fail shortly with that error).

I believe there may be a bug in reverting to the default configuration
value, and using an old value in memory.  I am using prefork in apache,
so it would most likely have to be an uninitialized pointer to the same
memory space, memory spaces for new forked processes should be
repeatable.  

Well thats about all I can provide, it can be fixed by explicitly
stating the open_basedir value in each virtual host (so ones where
before I kept it at the default value, now explicitly set the default
value).

I'm more than happy to follow any instructions to get further
information on this, just not sure what to do as its not an actual
crash or anything.




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

#24101 [Opn->Bgs]: socket_select call is blocking and never returning

[wez]

 ID:   24101
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wzaccone at telcordia dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

Looking at the CVS history, there is no way that your code should work
in 4.1.2 (socket_select() didn't even accept arrays as parameters back
then), nor even in 4.2.x (which only accepted the socket extensions own
descriptors).  The chances are that it only worked as a fluke.

The sockets extension has always been documented as experimental, so
functionality change from flaky code that is 18 months old is allowed,
without notice.

It is highly recommended that you update your code to use the
stream_select() function provided in PHP 4.3.x, as it is more flexible
and an officially supported (stable!) API.

This is not a bug in PHP, so I'm marking this report as Bogus.


Previous Comments:


[2003-06-10 09:23:25] wzaccone at telcordia dot com

thank you for the info.. we were previously using socket_select and
fread successfully with 4.1.2 and went live with an application doing
so.  For our next release, we upgraded to PHP 4.3.2 and it stopped
working.  Can I assume that this behavior has changed with 4.3.2??
therefore we must migrate to using streams_select to upgrade to 4.3.2?



[2003-06-10 09:19:12] [EMAIL PROTECTED]

You can't use fread() on sockets returned from the sockets extension,
and likewise, you can use socket_select() on streams returned from
fopen() or fsockopen().

Perhaps you meant to use stream_select() instead?



[2003-06-10 09:02:26] wzaccone at telcordia dot com

function readMsgsFromHosts($sockets){
  
   set_time_limit(0);
   $numSockets = count($sockets);
   
   $keys = array_keys($sockets);

   $socketsCopy = Array();

foreach ($keys as $key){
  $socketsCopy[$key] = $sockets[$key];
}

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL)
!== FALSE){

  foreach($socketsCopy as $sock){

  $string = fread($sock, $readAmount);



[2003-06-09 23:40:31] [EMAIL PROTECTED]

Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)




[2003-06-09 14:02:38] wzaccone at telcordia dot com

we upgraded our application from php 4.1.2 to 4.3.2 and are testing.
and found the following code no longer works:

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){

  foreach($socketsCopy as $sock){

The socket_select call appears to be never returning with php 4.3.2..
code worked correctly with 4.1.2.




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

#24005 [Asn->Ana]: Distributions version of mnoGoSearch extension does not work with MySQL 4

[gluke]

 ID:   24005
 Updated by:   [EMAIL PROTECTED]
 Reported By:  paul at ensigma dot com dot au
-Status:   Assigned
+Status:   Analyzed
 Bug Type: mnoGoSearch related
 Operating System: RedHat 9
 PHP Version:  4.3.2
 Assigned To:  gluke
 New Comment:

It seems to be because of buggy gcc-3.x compiler in your distribution.
The normal gcc behavior is to ignore -l switch dupes.


Previous Comments:


[2003-06-06 06:32:32] [EMAIL PROTECTED]

Sergey, deal with this.




[2003-06-03 21:24:12] paul at ensigma dot com dot au

I tried to compile PHP-4.3.2 with the --with-mnogosearch option and
with MySQL 4.0.13 installed from RPM .

./configure --with-mysql=/usr --with-gd --with-ttf --enable-track-vars 
--with-apxs2=/usr/local/apache2/bin/apxs --with-mnogosearch
--with-jpeg-dir=/root/source/jpeg-6b/ 
--with-png-dir=/usr/local/lib/libpng.a
--with-zlib-dir=/usr/local/lib/zlib.a
--with-tiff-dir=/usr/local/lib/libtiff.a --with-mnogosearch 

It failed complaining about "ext/mysql/phpmysql.c: undefined reference
to mysql_create_db". I downloaded the latest php-extension from
www.mnogosearch.org (mnogosearch-php-extension-1.7.3.tar.gz) and
replaced the contents of ext/mnogosearch with the files in this archive
and it all worked a treat (with a quick edit to remove the second
reference to -lmysqlclient in the EXTRA_LIBS line the PHP Makefile...
but I think that mnoGo's fault!)






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

#24112 [Opn]: php_admin_value defaults - open_basedir

[pd at pauldemarco dot com]

 ID:   24112
 User updated by:  pd at pauldemarco dot com
 Reported By:  pd at pauldemarco dot com
 Status:   Open
 Bug Type: PHP options/info functions
 Operating System: redhat 7.3
 PHP Version:  4.3.2
 New Comment:

if someone can confirm the behavorial difference on this between 4.3.0
and 4.3.2

Does 4.3.0 automatically add /tmp/ to open_basedir, but 4.3.2 does not?
 This is a phpbb installation, its failing on its cached templating
files, and occasionally on file uploads.  If the above /tmp behavior is
correct, then that would explain why it breaks in 4.3.2, however the
error messages are still very wrong as they list other virtual-hosts
open_basedir settings


Previous Comments:


[2003-06-10 08:19:07] pd at pauldemarco dot com

This problem does not occur on 4.3.0, with the same configure line (any
basic configuration will do).  Sadly, I cannot provide any real error
information, as it is not crashing, but the behavior is fairly
predictable.

I have a open_basedir setting in php.ini, confirmed via phpinfo(), its
value is not important.  On each of the configured virtual hosts I have
a different value using php_admin_value.  However, on some virtual
hosts I turn safe_mode off using php_admin_flag and do not set an
open_basedir value, so it should be using the php.ini setting.  Turning
safe mode off is probably not relevant, but trying to provide any
related information.

When requesting pages on that virtual host (the one with no overriding
open_basedir setting, and safe mode off), the requests will randomly
fail.  When checking the error log, it is a normal exit and php is
logging that 'open_basedir restriction in effect ... '

The path that it provides as the active open_basedir value is not
correct.  It in fact randomly changes to other virtual hosts settings. 
It does not always fail, it may take 20 requests before it does (even a
simple auto-refreshing page, will fail shortly with that error).

I believe there may be a bug in reverting to the default configuration
value, and using an old value in memory.  I am using prefork in apache,
so it would most likely have to be an uninitialized pointer to the same
memory space, memory spaces for new forked processes should be
repeatable.  

Well thats about all I can provide, it can be fixed by explicitly
stating the open_basedir value in each virtual host (so ones where
before I kept it at the default value, now explicitly set the default
value).

I'm more than happy to follow any instructions to get further
information on this, just not sure what to do as its not an actual
crash or anything.




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

#24111 [Fbk->Opn]: system(): Unable to fork

[abramov at fromru dot com]

 ID:   24111
 User updated by:  abramov at fromru dot com
 Reported By:  abramov at fromru dot com
-Status:   Feedback
+Status:   Open
 Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  4.3.2
 New Comment:

php -v :
PHP 4.3.2 (cgi-fcgi), Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies

phpinfo():
PHP Version 4.3.2
Server API : CGI/FastCGI 
GATEWAY_INTERFACE : CGI/1.1 

etc.


Previous Comments:


[2003-06-10 08:03:06] [EMAIL PROTECTED]

And what does 'php -v' output?
And what does phpinfo() has to say about the php version
under IIS?




[2003-06-10 07:01:26] abramov at fromru dot com

Web-server: IIS 5
Both CGI and ISAPI installations produced following bug:

Code:


Result:
system(): Unable to fork 




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

#24101 [Fbk->Opn]: socket_select call is blocking and never returning

[wzaccone at telcordia dot com]

 ID:   24101
 User updated by:  wzaccone at telcordia dot com
 Reported By:  wzaccone at telcordia dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

thank you for the info.. we were previously using socket_select and
fread successfully with 4.1.2 and went live with an application doing
so.  For our next release, we upgraded to PHP 4.3.2 and it stopped
working.  Can I assume that this behavior has changed with 4.3.2??
therefore we must migrate to using streams_select to upgrade to 4.3.2?


Previous Comments:


[2003-06-10 09:19:12] [EMAIL PROTECTED]

You can't use fread() on sockets returned from the sockets extension,
and likewise, you can use socket_select() on streams returned from
fopen() or fsockopen().

Perhaps you meant to use stream_select() instead?



[2003-06-10 09:02:26] wzaccone at telcordia dot com

function readMsgsFromHosts($sockets){
  
   set_time_limit(0);
   $numSockets = count($sockets);
   
   $keys = array_keys($sockets);

   $socketsCopy = Array();

foreach ($keys as $key){
  $socketsCopy[$key] = $sockets[$key];
}

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL)
!== FALSE){

  foreach($socketsCopy as $sock){

  $string = fread($sock, $readAmount);



[2003-06-09 23:40:31] [EMAIL PROTECTED]

Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)




[2003-06-09 14:02:38] wzaccone at telcordia dot com

we upgraded our application from php 4.1.2 to 4.3.2 and are testing.
and found the following code no longer works:

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){

  foreach($socketsCopy as $sock){

The socket_select call appears to be never returning with php 4.3.2..
code worked correctly with 4.1.2.




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

#24101 [Opn->Fbk]: socket_select call is blocking and never returning

[wez]

 ID:   24101
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wzaccone at telcordia dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

You can't use fread() on sockets returned from the sockets extension,
and likewise, you can use socket_select() on streams returned from
fopen() or fsockopen().

Perhaps you meant to use stream_select() instead?


Previous Comments:


[2003-06-10 09:02:26] wzaccone at telcordia dot com

function readMsgsFromHosts($sockets){
  
   set_time_limit(0);
   $numSockets = count($sockets);
   
   $keys = array_keys($sockets);

   $socketsCopy = Array();

foreach ($keys as $key){
  $socketsCopy[$key] = $sockets[$key];
}

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL)
!== FALSE){

  foreach($socketsCopy as $sock){

  $string = fread($sock, $readAmount);



[2003-06-09 23:40:31] [EMAIL PROTECTED]

Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)




[2003-06-09 14:02:38] wzaccone at telcordia dot com

we upgraded our application from php 4.1.2 to 4.3.2 and are testing.
and found the following code no longer works:

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){

  foreach($socketsCopy as $sock){

The socket_select call appears to be never returning with php 4.3.2..
code worked correctly with 4.1.2.




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

#24109 [Opn->Bgs]: Console window

[jay]

 ID:   24109
 Updated by:   [EMAIL PROTECTED]
 Reported By:  npeelman at cfl dot rr dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: WinXP Pro
 PHP Version:  4.3.2
 New Comment:

Isn't this exactly what the ncurses extension provides?  
 
http://www.php.net/ncurses 
 
J 


Previous Comments:


[2003-06-10 05:17:58] npeelman at cfl dot rr dot com

I would like to see the ability to open a 'console screen' when running
PHP from the command prompt. Several functions would be needed for
setting size and depth of screen as well as color and cursor control.




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

#24114 [NEW]: include_path option

[stefano dot cecconi at staff dot aruba dot it]

From: stefano dot cecconi at staff dot aruba dot it
Operating system: windows 2000
PHP version:  4.3.2
PHP Bug Type: PHP options/info functions
Bug description:  include_path option

This is my include_path option value :

include_path = ".;c:\php\includes"

Before 4.3.2 everything worked using this path in a script : 

include "/call_php/counter.php"

With 4.3.2 is mandatory to remove the first / so it works only with this
path :

include "call_php/counter.php"

or 

include "./call_php/counter.php"

I can't understand this change and it's creating a lot of problems for our
web hosting service, simply because there are thousands of scripts based
on the old way to use relative paths.




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

#24101 [Fbk->Opn]: socket_select call is blocking and never returning

[wzaccone at telcordia dot com]

 ID:   24101
 User updated by:  wzaccone at telcordia dot com
 Reported By:  wzaccone at telcordia dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

function readMsgsFromHosts($sockets){
  
   set_time_limit(0);
   $numSockets = count($sockets);
   
   $keys = array_keys($sockets);

   $socketsCopy = Array();

foreach ($keys as $key){
  $socketsCopy[$key] = $sockets[$key];
}

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL)
!== FALSE){

  foreach($socketsCopy as $sock){

  $string = fread($sock, $readAmount);


Previous Comments:


[2003-06-09 23:40:31] [EMAIL PROTECTED]

Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)




[2003-06-09 14:02:38] wzaccone at telcordia dot com

we upgraded our application from php 4.1.2 to 4.3.2 and are testing.
and found the following code no longer works:

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){

  foreach($socketsCopy as $sock){

The socket_select call appears to be never returning with php 4.3.2..
code worked correctly with 4.1.2.




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

#24101 [Opn->Fbk]: socket_select call is blocking and never returning

[sniper]

 ID:   24101
 Updated by:   [EMAIL PROTECTED]
 Reported By:  wzaccone at telcordia dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

Please, you can make that shorter.
(last note deleted from DB)



Previous Comments:


[2003-06-09 23:40:31] [EMAIL PROTECTED]

Could you give a complete (but short, please) script
that shows this problem clearly..? (can't reproduce, but I'm propably
missing some part here..)




[2003-06-09 14:02:38] wzaccone at telcordia dot com

we upgraded our application from php 4.1.2 to 4.3.2 and are testing.
and found the following code no longer works:

if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL) !==
FALSE){

  foreach($socketsCopy as $sock){

The socket_select call appears to be never returning with php 4.3.2..
code worked correctly with 4.1.2.




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

#24010 [Opn]: Make failure

[ronald_zeelenberg at hotmail dot com]

 ID:   24010
 User updated by:  ronald_zeelenberg at hotmail dot com
 Reported By:  ronald_zeelenberg at hotmail dot com
 Status:   Open
 Bug Type: Zend Engine 2 problem
 Operating System: Red Hat 8
 PHP Version:  5CVS-2003-06-04 (dev)
 New Comment:

I know get a server hang with the latest build today 13:30 GMT

Still with 434 no problem at all


Previous Comments:


[2003-06-10 01:21:49] ronald_zeelenberg at hotmail dot com

So i cant use it know? And when is PEAR ready for PHP5...? Keep in mind
that it did work?

Does anyone knows where i can find an older (3 weeks ago) PHP5 dev
version...



[2003-06-09 23:02:06] [EMAIL PROTECTED]

It's PHP5. And PEAR is not ready for it.. :)




[2003-06-09 16:37:52] ronald_zeelenberg at hotmail dot com

I can now link again (been able since 4 days ago) saw this in my system
log. But pages with PEAR are still crashing. I do not have these
problems in version 43x.

What is this thing?



[2003-06-09 04:17:13] ronald_zeelenberg at hotmail dot com

After setting LogLevel to debug in httpd.conf i found this extra info.

[Mon Jun 09 06:12:27 2003] [notice] Apache/2.0.46 (Unix) DAV/2
PHP/5.0.0-dev configured -- resuming 

normal operations
[Mon Jun 09 10:55:58 2003] [notice] child pid 21213 exit signal
Segmentation fault (11)
[Mon Jun 09 10:55:58 2003] [notice] child pid 21168 exit signal
Segmentation fault (11)
[Mon Jun 09 10:55:58 2003] [notice] child pid 21167 exit signal
Segmentation fault (11)
[Mon Jun 09 11:11:25 2003] [notice] caught SIGTERM, shutting down
[Mon Jun 09 11:11:25 2003] [notice] Apache/2.0.46 (Unix) DAV/2
PHP/5.0.0-dev configured -- resuming 

normal oper
ations
[Mon Jun 09 11:11:25 2003] [info] Server built: Jun  1 2003 13:15:30
[Mon Jun 09 11:11:25 2003] [debug] prefork.c(1039): AcceptMutex:
sysvsem (default: sysvsem)
[Mon Jun 09 11:12:13 2003] [notice] child pid 21487 exit signal
Segmentation fault (11)
[Mon Jun 09 11:12:13 2003] [notice] child pid 21486 exit signal
Segmentation fault (11)
[Mon Jun 09 11:12:13 2003] [notice] child pid 21485 exit signal
Segmentation fault (11)



[2003-06-09 03:55:03] ronald_zeelenberg at hotmail dot com

Okay since two day i can make a "correct" version of the daily based
PHP5 version. Accept some php-pages with DB-actions and PEAR based are
crashing... Apache2 says killed the child etc.

Daily based 4.3x does not have this problem.

Is something changed in PHP5 which ic causing this? I did not change my
code...



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

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

#24113 [Opn->WFx]: new function "str_replace_once"

[derick]

 ID:   24113
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dave at netready dot biz
-Status:   Open
+Status:   Wont fix
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.3.1
 New Comment:

preg_replace already supports this:

mixed preg_replace ( mixed pattern, mixed replacement, mixed subject [,
int limit])

regards,
Derick


Previous Comments:


[2003-06-10 08:32:16] dave at netready dot biz

Hi, 

I have been using str_replace to search and replace over large strings.
 Replacing strings I know for certain only occur once.  I was just
thinking that maybe if there was a str_replace_once function that would
stop searching after it had replaced one instance of search string this
could save considerable time checking the rest of the string.

To make it really useful it could have a backward/forward option so If
you knew the string you are searching for occurs near the end of your
string you could search backwards for it.  Or would that be a separate
function? I'm not sure what your guidlines are on that.

This would have even more speed impact on str_ireplace because by it's
nature it is slower, so maybe a str_ireplace_once would be a good idea
too?




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

#24113 [NEW]: new function "str_replace_once"

[dave at netready dot biz]

From: dave at netready dot biz
Operating system: Linux
PHP version:  4.3.1
PHP Bug Type: Feature/Change Request
Bug description:  new function "str_replace_once"

Hi, 

I have been using str_replace to search and replace over large strings. 
Replacing strings I know for certain only occur once.  I was just thinking
that maybe if there was a str_replace_once function that would stop
searching after it had replaced one instance of search string this could
save considerable time checking the rest of the string.

To make it really useful it could have a backward/forward option so If you
knew the string you are searching for occurs near the end of your string
you could search backwards for it.  Or would that be a separate function?
I'm not sure what your guidlines are on that.

This would have even more speed impact on str_ireplace because by it's
nature it is slower, so maybe a str_ireplace_once would be a good idea
too?
-- 
Edit bug report at http://bugs.php.net/?id=24113&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24113&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24113&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24113&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24113&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24113&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24113&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24113&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24113&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24113&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24113&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24113&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24113&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24113&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24113&r=gnused

#24112 [NEW]: php_admin_value defaults - open_basedir

[pd at pauldemarco dot com]

From: pd at pauldemarco dot com
Operating system: redhat 7.3
PHP version:  4.3.2
PHP Bug Type: PHP options/info functions
Bug description:  php_admin_value defaults - open_basedir

This problem does not occur on 4.3.0, with the same configure line (any
basic configuration will do).  Sadly, I cannot provide any real error
information, as it is not crashing, but the behavior is fairly
predictable.

I have a open_basedir setting in php.ini, confirmed via phpinfo(), its
value is not important.  On each of the configured virtual hosts I have a
different value using php_admin_value.  However, on some virtual hosts I
turn safe_mode off using php_admin_flag and do not set an open_basedir
value, so it should be using the php.ini setting.  Turning safe mode off
is probably not relevant, but trying to provide any related information.

When requesting pages on that virtual host (the one with no overriding
open_basedir setting, and safe mode off), the requests will randomly fail.
 When checking the error log, it is a normal exit and php is logging that
'open_basedir restriction in effect ... '

The path that it provides as the active open_basedir value is not correct.
 It in fact randomly changes to other virtual hosts settings.  It does not
always fail, it may take 20 requests before it does (even a simple
auto-refreshing page, will fail shortly with that error).

I believe there may be a bug in reverting to the default configuration
value, and using an old value in memory.  I am using prefork in apache, so
it would most likely have to be an uninitialized pointer to the same
memory space, memory spaces for new forked processes should be repeatable.
 

Well thats about all I can provide, it can be fixed by explicitly stating
the open_basedir value in each virtual host (so ones where before I kept
it at the default value, now explicitly set the default value).

I'm more than happy to follow any instructions to get further information
on this, just not sure what to do as its not an actual crash or anything.
-- 
Edit bug report at http://bugs.php.net/?id=24112&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24112&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24112&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24112&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24112&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24112&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24112&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24112&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24112&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24112&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24112&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24112&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24112&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24112&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24112&r=gnused

#24101 [Fbk->Opn]: socket_select call is blocking and never returning

[wzaccone at telcordia dot com]

 ID:   24101
 User updated by:  wzaccone at telcordia dot com
 Reported By:  wzaccone at telcordia dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Sockets related
 Operating System: Solaris 5.8 / Sparc
 PHP Version:  4.3.2
 New Comment:

Here is the complete function that calls socket_select.  we put some
tracing (echos) around the socket_select, and saw it never returned.  

 
function readMsgsFromHosts($sockets){
  
  // needs to read a "message" from each server where message has the
following format:
  // STX - 1 byte
  // pad bytes - 1 byte
  // msg len - 2 bytes
  // data - variable number of bytes
  // padding - variable number of bytes - from 0 to 3
  // ETX - 1 byte
 
  set_time_limit(0);
  $numSockets = count($sockets);

  // the following are the available states for the sockets
  $STXSTATE = 1;
  $PADBYTES = 2;
  $MSGLEN = 3;
  $DATA = 4;
  $PADDING = 5;
  $ETXSTATE = 6;
  $FINISHED = 7;
  
  $STX=chr(02);
  $ETX=chr(03);
  
  $socketsPadBytes = array();
  $socketsMsgLen = array();
  $socketsByteCount = array();
  $socketsState = array();
  $dataFromSockets = array();
  $keys = array_keys($sockets);

  foreach ($keys as $key){
$socketsPadBytes[$key] = 0;
$socketsMsgLen[$key] = 0;
$socketsByteCount[$key] = 0;
$socketsState[$key] = $STXSTATE;
$dataFromSockets[$key] = "";
  }
  
  $finishedCount = 0;
  while ($finishedCount != $numSockets){
$socketsCopy = Array();
//$keys = array_keys($sockets);
foreach ($keys as $key){
  $socketsCopy[$key] = $sockets[$key];
}
if (@socket_select($socketsCopy, $w = NULL, $e = NULL, $tv = NULL)
!== FALSE){
  foreach($socketsCopy as $sock){
$index = array_search($sock, $socketsCopy, true);
if ($socketsState[$index] != $FINISHED){
  $readAmount = 4;
  if ($socketsByteCount[$index] >= 4){
$readAmount = $socketsMsgLen[$index] -
$socketsByteCount[$index];
  }
  $string = fread($sock, $readAmount);
  //echo "\n\nRead: ".$string."(".strlen($string)."
bytes)\n\n";
  if ($string === FALSE){
// error while reading from socket
return array("error while reading from socket");
  }
  else if (strlen($string) == 0){
// end of file was reached
// shouldn't happen since we use ETX to determine the end
of message
return array("Reached end of file before ETX");
  }
  else {
// data was read from socket
while (strlen($string) > 0){
  //echo "\n\nString left: " .
$string."(".strlen($string)." bytes)\n\n";
  if ($socketsState[$index] == $STXSTATE ||
$socketsState[$index] == ""){
// read in the STX and update state
if ($string[0] != $STX){
  // error
  // ignore and keep looping
}
else {
  $socketsState[$index] = $PADBYTES;
  $socketsByteCount[$index] = $socketsByteCount[$index]
+ 1;
}
$string = substr($string, 1);
  }
  else if ($socketsState[$index] == $PADBYTES){
// read in the pad bytes and update state
$socketsPadBytes[$index] = ord($string[0]);
$string = substr($string, 1);
$socketsState[$index] = $MSGLEN;
$socketsByteCount[$index] = $socketsByteCount[$index] +
1;
  }
  else if ($socketsState[$index] == $MSGLEN){
// read in the message length and update state

if ($socketsMsgLen[$index] == 0){
  // have not yet read any msglen info
  if (strlen($string) == 1){
$socketsMsgLen[$index] = ord($string[0]) * 256;
  
// only a partial read - don't update state
$string = substr($string, 1);
$socketsByteCount[$index] =
$socketsByteCount[$index] + 1;
  
  }
  else {
// this should be the normal occurence
$socketsMsgLen[$index] = ord($string[0]) * 256 +
ord($string[1]);
  
// full read
$string = substr($string, 2);
$socketsByteCount[$index] =
$socketsByteCount[$index] + 2;
$socketsState[$index] = $DATA;
  }
}
else {
  // this is the rest of the msg len - add to existing
number
  
  $socketsMsgLen[$index] = $socketsMsgLen[$index] +
ord($string[0]);
  $string = substr($string, 1);
  $socketsByteCount[$index] = $socketsByteCount[$index]
+ 1;
  $socketsState[$index] = $DATA;
}
  }
  else if (

#24111 [Opn->Fbk]: system(): Unable to fork

[sniper]

 ID:   24111
 Updated by:   [EMAIL PROTECTED]
 Reported By:  abramov at fromru dot com
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: Windows XP
 PHP Version:  4.3.2
 New Comment:

And what does 'php -v' output?
And what does phpinfo() has to say about the php version
under IIS?



Previous Comments:


[2003-06-10 07:01:26] abramov at fromru dot com

Web-server: IIS 5
Both CGI and ISAPI installations produced following bug:

Code:


Result:
system(): Unable to fork 




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

#24110 [Opn->Bgs]: LDAP support

[sniper]

 ID:   24110
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mx5gr at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: IIS related
 Operating System: OS
 PHP Version:  4.3.2
 New Comment:

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

Thank you for your interest in PHP.

Please ask any such support questions elsewhere.
Thank you.



Previous Comments:


[2003-06-10 05:26:02] mx5gr at hotmail dot com

I want to enable LDAP authentication in some php pages. I have copied
both php_ldap.dll & libsasl.dll to both system32 and the declared
extensions directories but I still receive the following message, even
though the php_ldap.dll exists! 

Application popup: Warning : Unknown(): Unable to load dynamic library
'C:\PHP\extensions\php_ldap.dll' - The specified module could not be
found.

Any ideas? I am using the SAPI module of PHP to provide PHP support in
IIS 5.0 (system Win2K server SP3)




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

#24075 [Opn]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions

[sniper]

 ID:   24075
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Sven dot Schnitzke at t-online dot de
 Status:   Open
-Bug Type: *General Issues
+Bug Type: Feature/Change Request
 Operating System: WIN98SE
 PHP Version:  4.3.2
 New Comment:

fine, let's make this a feature request. 



Previous Comments:


[2003-06-10 03:44:27] Sven dot Schnitzke at t-online dot de

Before we start flaming (_real_ OS, ...) I would like to turn your
attention to the first sentence of my message.
I will happily be settling with calling it a feature request:
Please base relative path specs for extension dir on the
folder the executable resides in (and re-think the decision
of packing php-cli into another folder, btw. what's the rationale
behind that?).
There are bulks of user comments and recommendations to put all the
dlls into WINSYS folder which is a _very_ bad startegy when it comes to
upgrading. And it is caused by 
this feature.
IMHO program extensions do by all means belong to the program and not
to the data (in the sense that for PHP
scripts are data).
Second: (Just curious) I use Apache with mod_php. How do you get any
relevant information on this config out of calling PHP.EXE?
Last: Using a PIF to start PHP comes from 2 points: I use the pif to
customize the command window and to set the current folder so PHP
starts in a defined environment.
I don't believe anything discussed around this issue has
anything to do with the _flavor_ of WIN (98SE is not the only one I use
- it just happens to be the one on the machine I first loaded PHP 4.3.2
on)



[2003-06-10 03:04:01] [EMAIL PROTECTED]

Can't see any bug here..




[2003-06-10 02:38:12] [EMAIL PROTECTED]



It tries to detect the current SAPI. Why do you use a pif do launch
php? Then I do not know what is related with PEAR if php launched with
a pif does not find some dlls. Comments?

btw, have you think about moving to real OS? like something newer than
win98se? win2K?

pierre



[2003-06-09 08:18:15] [EMAIL PROTECTED]

I've no idea what PHP 4.4-dev is..last release is 4.3.2..
Reclassified as pear bug.




[2003-06-09 03:36:18] Sven dot Schnitzke at t-online dot de

(IMHO the reason for this trouble is that relative extension dir spec
is based upon cwd whereas it should be based upon the folder php
resides in).
Sorry, the problem was in go-pear.php. It tries to invoke
php.exe -v to learn something of the returned string. With
my inst the cli version of php is supposed to be invoked via
PIF and cannot be launched directly via exec. It was this
'inner' call that issued the complaints about the missing 
dlls.
Obviously with absolute path spec this call finds the extensions and
everything is fine. Still don't know why 
e.g. a PHP4.4-dev (feb03 approx) works with relative specs?



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

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

#20449 [Com]: sessions randomly fail

[phpbugs at virtua dot ch]

 ID:   20449
 Comment by:   phpbugs at virtua dot ch
 Reported By:  josh at zebotech dot com
 Status:   No Feedback
 Bug Type: Session related
 Operating System: redhat 7.3
 PHP Version:  4.3.0-dev
 New Comment:

We are still having the same issue here with php-4.3.3 ... Currently
testing latest snapshots. Config : FreeBSD 4.7 UP, Apache 1.3.27,
standard /tmp session handling. One of our developers even tried a
print_r($_SESSION) and found part of the php source file in it !!

There seem to be some leakage somewhere !


Previous Comments:


[2003-06-09 08:44:10] [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-06-02 17:09:32] [EMAIL PROTECTED]

This should be fixed in PHP 4.3.2, so please give it a try.




[2003-06-02 14:44:35] radek at pinkbike dot com

I also have seen behaviour of missing session data.  I have detected
this in the custom shopping cart I have written.  Every 20 or 30 orders
we get a "blank" order.  This blank order is a result of the session
cart is not picked up on the last stage of the purchase process.  I
went through my code a million times to try to figure out how I could
of caused this but reading this bug report I starting to think it maybe
a result of php session/serialization.  Like the other person with the
shopping cart stated, who knows how many users don't even make it to
the last step and their cart disappears. 

I store associative arrays in the session
I run on a dual CPU intel box
The site is relatively high load - 3 million hits a day
I have not been able to reproduce the problem myself
It has been happening regularly since January when i put up the
software - it happens on a few versions of php since Jan 2003

What are options here?  Any documentation, warnings about what not to
store in php sessions?
Should I be writting my own handler/serializer?



here are the box details
Apache/1.3.26 
PHP Version 4.3.1 
System  Linux superlight 2.4.20-xfs #2 SMP Mon Apr 7 21:06:32 CDT 2003
i686  
Build Date  May 1 2003 00:21:10  
Configure Command  './configure' '--with-apxs=/usr/bin/apxs'
'--with-mysql=/usr/local/mysql' '--with-openssl' '--with-zlib'
'--with-mcrypt' '--enable-shmop' '--enable-sysvshm' '--enable-sysvsem'
'--enable-mbstring' '--with-gd' '--with-png-dir=/usr'
'--with-jpeg-dir=/usr' '--enable-mbstring' '--with-curl=/usr/local'
'--enable-exif'  
Server API  Apache  
Virtual Directory Support  disabled  
Configuration File (php.ini) Path  /usr/local/lib/php.ini  
PHP API  20020918  
PHP Extension  20020429  
Zend Extension  20021010  
Debug Build  no  
Thread Safety  disabled  
Registered PHP Streams  php, http, ftp, https, ftps, compress.zlib



[2003-05-24 01:15:44] brian dot diekelman at andrews dot af dot mil

I just upgraded from snaps.php.net yesterday and am still experiencing
this bug.  I am running a very simple authentication script at the
beginning of every page to check a generic $_SESSION['user'] to see if
there is an active session.  If there is not it prompts for login.

  The session only holds the user name and password.  Now I have heard
a lot of people in my organization complaining that they'll be browsing
the site and it will randomly prompt for login.  I have also
experienced this myself.  I have heard a couple people in this bug
thread attribute losing the session to php's handing of arrays, which
very well may be true but in my case I am losing sessions on a lot more
basic level.

System:
--
Win2K SP2
Apache 2.0.45
PHP 4.3.x (downloaded from snaps yesterday)



[2003-05-21 08:30:40] stefandekonink at xs4all dot nl

Currently I have the same session problem. As the page in a frameset
get a POST (login user/pass) the page gets the content. The next page
presented in this frame is to fill in content, after posting, it goes
again thru the login procedure.
After the login the SessionID is lost even if a GET var is specified.
This behavior occurs on IE6.0.2600 Win2K-SP2, Mozilla Firebird is
working without this annoing behavior.



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

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

#24111 [NEW]: system(): Unable to fork

[abramov at fromru dot com]

From: abramov at fromru dot com
Operating system: Windows XP
PHP version:  4.3.2
PHP Bug Type: IIS related
Bug description:  system(): Unable to fork

Web-server: IIS 5
Both CGI and ISAPI installations produced following bug:

Code:


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

#24110 [NEW]: LDAP support

[mx5gr at hotmail dot com]

From: mx5gr at hotmail dot com
Operating system: OS
PHP version:  4.3.2
PHP Bug Type: IIS related
Bug description:  LDAP support

I want to enable LDAP authentication in some php pages. I have copied both
php_ldap.dll & libsasl.dll to both system32 and the declared extensions
directories but I still receive the following message, even though the
php_ldap.dll exists! 

Application popup: Warning : Unknown(): Unable to load dynamic library
'C:\PHP\extensions\php_ldap.dll' - The specified module could not be
found.

Any ideas? I am using the SAPI module of PHP to provide PHP support in IIS
5.0 (system Win2K server SP3)
-- 
Edit bug report at http://bugs.php.net/?id=24110&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24110&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24110&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24110&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24110&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24110&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24110&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24110&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24110&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24110&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24110&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24110&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24110&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24110&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24110&r=gnused

#23975 [Com]: dba_open locking error with db3

[adam at saki dot com dot au]

 ID:   23975
 Comment by:   adam at saki dot com dot au
 Reported By:  rhalstenbach at t-online dot de
 Status:   Assigned
 Bug Type: DBM/DBA related
 Operating System: Windows
 PHP Version:  4.3.2
 Assigned To:  helly
 New Comment:

This is actually because the locking will prematurely create an empty
file, causing the VCWD_STAT command in dba_db3.c to return 0, resulting
in the wrong parameters to db_open.

This can be verified by putting a stat command after the lock detection
code and before the call to open (line 590 in ext/dba/dba.c).


Previous Comments:


[2003-06-05 01:28:33] [EMAIL PROTECTED]

Marcus, take a look?




[2003-06-03 03:43:56] rhalstenbach at t-online dot de

The new locking feature (introduced with 4.3.0) does not work correctly
in default mode "d". Very annoying because it is the default mode ...

Example:



Same problem for mode "w".

It works correctly for locking mode "l" and for suppressing locking via
"-". Obviously the dba_open() function tries to create a lock file with
exactly the same name as the database file - what fails of course.

Tested on WindowsXP with db3, but i think it will fail for every
db-driver (except gdbm) on every OS.




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

#24109 [NEW]: Console window

[npeelman at cfl dot rr dot com]

From: npeelman at cfl dot rr dot com
Operating system: WinXP Pro
PHP version:  4.3.2
PHP Bug Type: Feature/Change Request
Bug description:  Console window

I would like to see the ability to open a 'console screen' when running PHP
from the command prompt. Several functions would be needed for setting
size and depth of screen as well as color and cursor control.
-- 
Edit bug report at http://bugs.php.net/?id=24109&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24109&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24109&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24109&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24109&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24109&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24109&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24109&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24109&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24109&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24109&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24109&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24109&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24109&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24109&r=gnused

#21944 [Com]: zlib compressed pages can be flushed causing compressed output to be displayed

[piter veniceone dot it at tin dot it]

 ID:   21944
 Comment by:   piter veniceone dot it at tin dot it
 Reported By:  phpbug at paragontech dot com
 Status:   Verified
 Bug Type: Zlib Related
 Operating System: all
 PHP Version:  4.3.x
 New Comment:

I've the same problem with:

apache 2.0.46
php 4.3.2
linux 2.4.21
slackware 8.1


Previous Comments:


[2003-06-01 06:54:27] dennis at darknoise dot de

it also happens to me with a 1.3.x apache and php versions from 4.3.x
on RedHat Linux 7.3



[2003-05-14 21:59:10] [EMAIL PROTECTED]

This problem also occurs on our own gtk.php.net site with latest stable
CVS.



[2003-01-30 03:18:27] [EMAIL PROTECTED]

I noticed this issue before the release of 4.3.0.
A kind of Apache2 oddity. Should be fixed.




[2003-01-29 10:48:20] phpbug at paragontech dot com

This is a problem with IE 6.0.26 as well as Netscape Navigator 4.08.



[2003-01-29 09:50:50] phpbug at paragontech dot com

This is with apache2 2.0.44 on Win NT

If zlib.output_compression = On in the php.ini, and a flush() statement
is sent on a PHP page, the compressed output will be displayed in the
browser, or the user will be asked to "download" the file.  If you do
download this file, all you would see is the compressed output.

I've never seen this behavior in previous versions of PHP, it's quite
possible that this behavior is by design (it does exactly what you tell
it to, it flushes its output, but the results are unexpected.) 
Removing the flush() statements or setting zlib.output_compression =
Off are possible solutions until a fix (if any) is made.





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

#24075 [Bgs->Opn]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions

[Sven dot Schnitzke at t-online dot de]

 ID:   24075
 User updated by:  Sven dot Schnitzke at t-online dot de
 Reported By:  Sven dot Schnitzke at t-online dot de
-Status:   Bogus
+Status:   Open
 Bug Type: *General Issues
 Operating System: WIN98SE
 PHP Version:  4.3.2
 New Comment:

Before we start flaming (_real_ OS, ...) I would like to turn your
attention to the first sentence of my message.
I will happily be settling with calling it a feature request:
Please base relative path specs for extension dir on the
folder the executable resides in (and re-think the decision
of packing php-cli into another folder, btw. what's the rationale
behind that?).
There are bulks of user comments and recommendations to put all the
dlls into WINSYS folder which is a _very_ bad startegy when it comes to
upgrading. And it is caused by 
this feature.
IMHO program extensions do by all means belong to the program and not
to the data (in the sense that for PHP
scripts are data).
Second: (Just curious) I use Apache with mod_php. How do you get any
relevant information on this config out of calling PHP.EXE?
Last: Using a PIF to start PHP comes from 2 points: I use the pif to
customize the command window and to set the current folder so PHP
starts in a defined environment.
I don't believe anything discussed around this issue has
anything to do with the _flavor_ of WIN (98SE is not the only one I use
- it just happens to be the one on the machine I first loaded PHP 4.3.2
on)


Previous Comments:


[2003-06-10 03:04:01] [EMAIL PROTECTED]

Can't see any bug here..




[2003-06-10 02:38:12] [EMAIL PROTECTED]



It tries to detect the current SAPI. Why do you use a pif do launch
php? Then I do not know what is related with PEAR if php launched with
a pif does not find some dlls. Comments?

btw, have you think about moving to real OS? like something newer than
win98se? win2K?

pierre



[2003-06-09 08:18:15] [EMAIL PROTECTED]

I've no idea what PHP 4.4-dev is..last release is 4.3.2..
Reclassified as pear bug.




[2003-06-09 03:36:18] Sven dot Schnitzke at t-online dot de

(IMHO the reason for this trouble is that relative extension dir spec
is based upon cwd whereas it should be based upon the folder php
resides in).
Sorry, the problem was in go-pear.php. It tries to invoke
php.exe -v to learn something of the returned string. With
my inst the cli version of php is supposed to be invoked via
PIF and cannot be launched directly via exec. It was this
'inner' call that issued the complaints about the missing 
dlls.
Obviously with absolute path spec this call finds the extensions and
everything is fine. Still don't know why 
e.g. a PHP4.4-dev (feb03 approx) works with relative specs?



[2003-06-07 11:25:04] Sven dot Schnitzke at t-online dot de

Yes, I am 100% sure. Meanwhile I verified that an absolute path spec
does work. It is _really_ strange: curiously I tried go_pear.php and I
encounter the named problem. When executing other scripts this is not
the case.
There is another strange thing about go_pear.php: it thinks I am using
cgi while I am using php4apache. 
I tried go_pear with a PHP 4.4-dev and it worked (with some minor
gliches) !?!?
I will investigate further. It seems it could be a pear issue.



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

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

#24108 [Opn->Bgs]: troubleshooting php fasttemplate after upgrade php version to 4.3.2

[derick]

 ID:   24108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  remcobreezer at mailandnews dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Class/Object related
 Operating System: unix
 PHP Version:  4.3.2
 New Comment:

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

Thank you for your interest in PHP.

That's a problem in FastTemplates...


Previous Comments:


[2003-06-10 03:33:33] remcobreezer at mailandnews dot com

If you upgrade to php version 4.3.2 you can have some problems with the
php fasttemplate file. To fix this problem you can disable the lines
638 - 641 and your fasttemplate should work again.

Code to disable : 

function clear_parse ()
{
$this->clear_assign();
}






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

#24108 [NEW]: troubleshooting php fasttemplate after upgrade php version to 4.3.2

[remcobreezer at mailandnews dot com]

From: remcobreezer at mailandnews dot com
Operating system: unix
PHP version:  4.3.2
PHP Bug Type: Class/Object related
Bug description:  troubleshooting php fasttemplate after upgrade php version to 4.3.2

If you upgrade to php version 4.3.2 you can have some problems with the php
fasttemplate file. To fix this problem you can disable the lines 638 - 641
and your fasttemplate should work again.

Code to disable : 

function clear_parse ()
{
$this->clear_assign();
}


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

#24075 [Opn->Bgs]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions

[sniper]

 ID:   24075
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Sven dot Schnitzke at t-online dot de
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: WIN98SE
 PHP Version:  4.3.2
 New Comment:

Can't see any bug here..



Previous Comments:


[2003-06-10 02:38:12] [EMAIL PROTECTED]



It tries to detect the current SAPI. Why do you use a pif do launch
php? Then I do not know what is related with PEAR if php launched with
a pif does not find some dlls. Comments?

btw, have you think about moving to real OS? like something newer than
win98se? win2K?

pierre



[2003-06-09 08:18:15] [EMAIL PROTECTED]

I've no idea what PHP 4.4-dev is..last release is 4.3.2..
Reclassified as pear bug.




[2003-06-09 03:36:18] Sven dot Schnitzke at t-online dot de

(IMHO the reason for this trouble is that relative extension dir spec
is based upon cwd whereas it should be based upon the folder php
resides in).
Sorry, the problem was in go-pear.php. It tries to invoke
php.exe -v to learn something of the returned string. With
my inst the cli version of php is supposed to be invoked via
PIF and cannot be launched directly via exec. It was this
'inner' call that issued the complaints about the missing 
dlls.
Obviously with absolute path spec this call finds the extensions and
everything is fine. Still don't know why 
e.g. a PHP4.4-dev (feb03 approx) works with relative specs?



[2003-06-07 11:25:04] Sven dot Schnitzke at t-online dot de

Yes, I am 100% sure. Meanwhile I verified that an absolute path spec
does work. It is _really_ strange: curiously I tried go_pear.php and I
encounter the named problem. When executing other scripts this is not
the case.
There is another strange thing about go_pear.php: it thinks I am using
cgi while I am using php4apache. 
I tried go_pear with a PHP 4.4-dev and it worked (with some minor
gliches) !?!?
I will investigate further. It seems it could be a pear issue.



[2003-06-07 04:50:23] [EMAIL PROTECTED]

Are you 100% sure you have really updated PHP and that you
don't have duplicate php4ts.dll's in your system?
And that the one you have is for PHP 4.3.2?
 
And FYI: earlier extensions might not work with current php.





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

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

#23462 [Com]: Position "php_admin_value open_basedir" in httpd.conf

[admin at xpower dot net]

 ID:   23462
 Comment by:   admin at xpower dot net
 Reported By:  admin at xpower dot nwt
 Status:   No Feedback
 Bug Type: Apache2 related
 Operating System: FreeBSD, Linux
 PHP Version:  4.3.2RC2
 New Comment:

Version  4.3.2
Bug under FreeBSD not resolved.


Previous Comments:


[2003-05-14 11:02:23] [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-05-08 04:34:27] [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





[2003-05-03 05:42:09] admin at xpower dot nwt

For all older PHP version folowing work fine:


php_admin_value open_basedir /home/www/fly/web/


and all Virtual servers under /home/www/fly/web/ use this restriction
as I expect.

But after setup 4.3.2RC i see in error_log something like this:
[client XXX.XXX.XXX.XXX] PHP Warning:  Unknown(): open_basedir
restriction in effect.
File(/usr/home/www/kalimed/web/domain.com/public/wstats.php) is not
within the allowed path(s): (/home/www/fly/web/) in Unknown on line 0

 - the restriction for /home/www/fly/web/ used for
/home/www/kalimed/web/

If I move "php_admin_value open_basedir" into each virtual host section
- this solve the probem. But I think this is more usability to use one
 directive instead of putting config line for each virtual
host. Thanks. Sorry for terrible english :)




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

#24075 [Opn]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions

[pajoye]

 ID:   24075
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Sven dot Schnitzke at t-online dot de
 Status:   Open
-Bug Type: PEAR related
+Bug Type: *General Issues
 Operating System: WIN98SE
 PHP Version:  4.3.2
 New Comment:



It tries to detect the current SAPI. Why do you use a pif do launch
php? Then I do not know what is related with PEAR if php launched with
a pif does not find some dlls. Comments?

btw, have you think about moving to real OS? like something newer than
win98se? win2K?

pierre


Previous Comments:


[2003-06-09 08:18:15] [EMAIL PROTECTED]

I've no idea what PHP 4.4-dev is..last release is 4.3.2..
Reclassified as pear bug.




[2003-06-09 03:36:18] Sven dot Schnitzke at t-online dot de

(IMHO the reason for this trouble is that relative extension dir spec
is based upon cwd whereas it should be based upon the folder php
resides in).
Sorry, the problem was in go-pear.php. It tries to invoke
php.exe -v to learn something of the returned string. With
my inst the cli version of php is supposed to be invoked via
PIF and cannot be launched directly via exec. It was this
'inner' call that issued the complaints about the missing 
dlls.
Obviously with absolute path spec this call finds the extensions and
everything is fine. Still don't know why 
e.g. a PHP4.4-dev (feb03 approx) works with relative specs?



[2003-06-07 11:25:04] Sven dot Schnitzke at t-online dot de

Yes, I am 100% sure. Meanwhile I verified that an absolute path spec
does work. It is _really_ strange: curiously I tried go_pear.php and I
encounter the named problem. When executing other scripts this is not
the case.
There is another strange thing about go_pear.php: it thinks I am using
cgi while I am using php4apache. 
I tried go_pear with a PHP 4.4-dev and it worked (with some minor
gliches) !?!?
I will investigate further. It seems it could be a pear issue.



[2003-06-07 04:50:23] [EMAIL PROTECTED]

Are you 100% sure you have really updated PHP and that you
don't have duplicate php4ts.dll's in your system?
And that the one you have is for PHP 4.3.2?
 
And FYI: earlier extensions might not work with current php.





[2003-06-07 03:49:11] Sven dot Schnitzke at t-online dot de

I just downloaded PHP-4.3.2 final and wanted to install it.
(extension dir is specified as ..\php\extensions)

I have parallel folders with some versions of PHP4 from 4.0.6 thru
4.3.2-RC and some snapshot 
4.4-dev which I arranged to have at hand by just copying PHP.INI to the
Apache folder and 
renaming the PHP folder to be the one supposed to hold the active PHP.
No parts of PHP outside 
these folders except some two PIFS used to start PHP from the command
line.
This works because the Apache folder and the active PHP folder are
parallel in the same tree.

All versions I have work well this way including an earlier 4.3.2-RC.
Now 4.3.2 final does not!

IMHO copying the extensions to the WINSYS folder is not a viable way
because
a) it clutters WINSYS
b) you are unable to quickly go forth (and back in case of trouble)
with upgrading PHP

Maybe absolute path works but I don't think it is a good idea to have a
lot of places where
absolute path specs are required.




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

#24106 [NEW]: UTF8 to SJIS bug

[richard at enfour dot co dot jp]

From: richard at enfour dot co dot jp
Operating system: MacOSX
PHP version:  4.3.2
PHP Bug Type: mbstring related
Bug description:  UTF8 to SJIS bug

It maybe elsewhere but I found a case where UTF-8 to 
SJIS mb_convert_encoding mashes a Japanese text string.

The string is the kanji for "souseki"
Unicode:
U8e2a+8de1

In SJIS it should be:
E748+90D5
but gets mashed.

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