#21491 [Com]: Hang during ociexecute

[michael . mauch]

 ID:   21491
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: OCI8 related
 Operating System: Suse Linux 8.0
 PHP Version:  4.2.3
 New Comment:

Does it help if you 'do it by the book',
, i.e. don't use putenv() or
Apache's SetEnv, but set the environment variables before you start
Apache? And did you check whether your Apache is linked to pthread (see
the page mentioned above)?


Previous Comments:


[2003-01-07 09:32:33] [EMAIL PROTECTED]

Works fine on Solaris in DSO and CGI.  You might want to test the
connection to see if it happened and call OCIError as well.



[2003-01-07 08:19:04] [EMAIL PROTECTED]

I'm trying to get some (existing) records oput of an Oracle8-Database.
As long as I do a query, which can't have any results, everything works
fine. But if I write a SELECT-statement, which should give at least one
result, the whole thing hangs or I get the message 'The page cannot be
displayed'.


example (which causes me troubles):




The 'echo-statement' is only used to verify that the script has
finished! The statement "select max(id_pers) from t_person" for example
works fine.

Thanks in advance!
Greetings
Stephan




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

#21773 [Com]: The process is killed after OCIFetch()

[michael . mauch]

 ID:   21773
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Solaris 2.8
 PHP Version:  4.3.0
 New Comment:

This is not an infinite loop, it runs only while ($error==0).

And then there's a time limit for every PHP script, see
.

Better ask such questions in the php.db mailing list, see
.


Previous Comments:


[2003-01-20 10:01:14] [EMAIL PROTECTED]

Hello,

we have a PHP script that run in a infinite loop looking 
on ORACLE DB (8.1.7). In each loop a SELECT is done, if this doesn't
return data then the SELECT is executed after two seconds. If after not
certain time the SELECT doesn't return data then when it returns data
the process is killed after OCIFetch(), view code for understand
better.

//START

$dbConnection = @OCILogon(USER_ID, PASSWORD, SID);
// infinite loop
$error=0;
do  
{
   $query="SELECT DATA FROM PROV";
   $stmt = @OCIParse($dbConnection,$query);
   @OCIDefineByName($stmt,"DATA",&$data);
   @OCIExecute($stmt);
   $err_ora = @OCIError($stmt);
   if ($err_ora)  
   {
$error=1;   
 
   }

   While (@OCIFetch($stmt) && ($error==0))
   {
   
   

   }
   @OCIFreeStatement($stmt);
   sleep(2);

}while ($error==0);



Thanks for any suggestion




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

#21773 [Com]: The process is killed after OCIFetch()

[michael . mauch]

 ID:   21773
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Solaris 2.8
 PHP Version:  4.3.0
 New Comment:

Can you please try without these @ signs? If you don't like the
errors/warnings being displayed on your webpages, you can turn
display_errors off and log_errors on, so you can find the
errors/warnings in your log file.

ini_set('display_errors','0');
ini_set('log_errors','1');


Previous Comments:


[2003-01-21 03:19:26] [EMAIL PROTECTED]

I don't receive any error or I don't perhaps succeed in capturing it.



[2003-01-20 14:52:10] [EMAIL PROTECTED]

Do you see "OCI8 Recursive call!" such an error message?



[2003-01-20 10:51:56] [EMAIL PROTECTED]

Before the connection to the db it is present the following statement:

//Set max execution time to infinite

set_time_limit(0);

The loop is stopped when there is an error, in this case the variable
$error=1.

Thanks



[2003-01-20 10:51:54] [EMAIL PROTECTED]

Before the connection to the db it is present the following statement:

//Set max execution time to infinite

set_time_limit(0);

The loop is stopped when there is an error, in this case the variable
$error=1.

Thanks



[2003-01-20 10:19:01] [EMAIL PROTECTED]

This is not an infinite loop, it runs only while ($error==0).

And then there's a time limit for every PHP script, see
.

Better ask such questions in the php.db mailing list, see
.



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

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

#21816 [Com]: preg_replace has problem with arrays

[michael . mauch]

 ID:   21816
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Regular Expressions
 Operating System: Windows XP
 PHP Version:  4.3.0
 New Comment:

The search strings used in the preg_replace() function are regular
expressions. "[abc]" is a regular expression which matches any of the
characters "a", "b" or "c".

Either use str_replace() to replace your strings, or learn to use
regular expressions
.


Previous Comments:


[2003-01-22 08:41:20] [EMAIL PROTECTED]

" . $string2;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
// if you add a ksort it works fine:

ksort($search,SORT_NUMERIC);
ksort($replace,SORT_NUMERIC);   
reset($search);
reset($replace);

$string3 = preg_replace($search,$replace,$string);
echo "Corrected (ksort) Result is:" . $string3;

//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>



[2003-01-22 07:43:39] [EMAIL PROTECTED]

" . $string;
echo "Result should be: Say a [betterWord0] about
[betterWord1] and [betterWord2]";

// result should be:
//Say a [betterWord0] about [betterWord1] and [betterWord2]
//
// but produces: 
//Say a [betterWord0] about [betterWord2] and [betterWord1]
//
// Seems like the order in which i build my array
// is the order for replacing...and not the index
// of $array[$index]
//
//
// Has someone an idea, about what's happening here?
//
// just a guy addicted to php ;-)
?>




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

#21797 [Com]: compile stops, commad-line too long

[michael . mauch]

 ID:   21797
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Solaris 6
 PHP Version:  4.3.0
 New Comment:

Could "we" please add GNU sed to the list of prerequisites on
?


Previous Comments:


[2003-01-22 09:41:45] [EMAIL PROTECTED]

it's not a bug, so we leave it at "bogus"



[2003-01-22 09:40:58] [EMAIL PROTECTED]

fixed by an upgrade of sed.



[2003-01-21 09:57:31] [EMAIL PROTECTED]

Due to a bug in the installed sed on your system the build
fails. Install GNU sed and it should be okay.
 
Thank you for your interest in PHP.

 



[2003-01-21 09:54:35] [EMAIL PROTECTED]

Hi,
I have a problem compiling php on my sun workstation. The make stops
with the error message:

/bin/sh libtool ..
Command line too long
Command line too long
Command line too long
gcc: main/php_ini: No such file or directory

I replaced the very long list of arguments with .. Its more than
3kb long.

The problem was reported prior and solved in earlier versions  but It
appeared again.




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

#21825 [Com]: Fatal error: Nesting level too deep

[michael . mauch]

 ID:   21825
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Linux 2.4.19
 PHP Version:  4.3.0
 New Comment:

Can you please find the extension_dir setting in your php.ini and make
sure that it points to the directory with your newly built modules?
There have been reports where this "Nesting level too deep" was caused
by an extension_dir that pointed to the modules of a previous PHP
installation.


Previous Comments:


[2003-01-22 14:31:54] [EMAIL PROTECTED]

This error occurs at the bottom of every PHP-parsed page:

"Fatal error: Nesting level too deep - recursive dependency? in Unknown
on line 0"

The pages seem to render okay, but the error appears to end each page. 
It even spit out the same error dozens of times on make test, and after
sending in the test results.

./configure  --with-apxs=/usr/local/apache/bin/apxs  
 --enable-trans-sid
 --enable-track-vars
 --with-gd
 --with-pdflib
 --with-jpeg-dir  
 --with-tiff-dir
 --with-pspell
 --with-freetype-dir
 --enable-gd-native-ttf
 --with-png-dir 
 --with-zlib-dir
 --with-ttf
 --with-mysql=/usr/local/mysql

The system is MDK9 and Apache 1.3.26




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

#21897 [Com]: ORA-03113: end-of-file on communication channel

[michael . mauch]

 ID:   21897
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Solaris
 PHP Version:  4.2.3
 New Comment:

Make sure you set the environment variables mentioned on 
 before you start your
httpd. _Don't_ set them in PHP with putenv() or in httpd.conf with
SetEnv.

If this doesn't help, maybe you can find the cause of the problem by
reading .


Previous Comments:


[2003-01-27 04:24:39] [EMAIL PROTECTED]

This error occurs very often but not allways:
FEHLER: Database error: ALTER SESSION SET NLS_DATE_FORMAT="-MM-DD
HH24:MI:SS"
Oracle8 Error: O (ORA-03113: end-of-file on communication channel )

Session halted.
Warning: failed to rollback outstanding transactions!: ORA-03114: not
connected to ORACLE in Unknown on line 0

it seems that the Oracle connection died, but the oci8 extension
doesen't know this. The sql-statement above is the first after
OCIPlogon(), changing to OCINLogon() doesen't solved this problem.
We run the same application on other platforms with Oracle without any
problems, this problem seems to be Solaris related.

The Oracle Version is 8.1.7.4. Apache 1.3.26.

The problem also occurs with PHP4.1.1




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

#21919 [Com]: wrong PHP superglobalname in apache environment

[michael . mauch]

 ID:   21919
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Apache related
 Operating System: AIX 4.3.3
 PHP Version:  4.3.0
 New Comment:

@ Ilia: probably he is using tr_TR. I can see that problem if I set and
export LC_ALL=tr_TR before starting Apache (1.3.27). If I do this,
Apache starts to complain:

Invalid command 'MIMEMagicFile', perhaps mis-spelled or defined by a
module not included in the server configuration

so I commented this line in the httpd.conf.

So there might be a problem in Apache. I get the same strange results
with a little Perl script (/cgi-bin/test.pl, I think it comes with
Apache):

print "Content-type: text/html\n\n";
print "%ENV: \n", map { "$_ = $ENV{$_} \n" } keys %ENV;

This script also prints HTTP_CONNECTİON and so on (this is with
mod_perl; the test.cgi shell script works ok).

@Tolga: can you please try and put the following lines into your
apachectl:

unset LC_ALL
LC_CTYPE=C
export LC_CTYPE

You might get other problems with these settings, unless you use
setlocale(LC_CTYPE,"tr_TR") in your PHP scripts, though.


Previous Comments:


[2003-01-28 10:41:31] [EMAIL PROTECTED]

What locale are you using, is it tr_TR?



[2003-01-28 08:05:39] [EMAIL PROTECTED]

additional info for sniper's request;
i checkedvar_dump($_SERVER)  and
only these vars mangled :
HTTP_ACCEPT_ENCOD0NG
HTTP_CONNECT0ON
HTTP_COOK0E

other vars (such as SCRIPT_FILENAME , SERVER_ADMIN) fine...

i use that script  :   
--

--

and script's output :
--
array(30) { ["DOCUMENT_ROOT"]=> string(28)
"/usr/HTTPServer/htdocs/en_US" ["HTTP_ACCEPT"]=> string(164)
"image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*"
["HTTP_ACCEPT_ENCOD0NG"]=> string(13) "gzip, deflate"
["HTTP_ACCEPT_LANGUAGE"]=> string(2) "tr" ["HTTP_CONNECT0ON"]=>
string(10) "Keep-Alive" ["HTTP_COOK0E"]=> string(74)
"4images_lastvisit=1043070424; 4images_userid=1; seysin=hoIIo;
seyIIn=hoIIo" ["HTTP_HOST"]=> string(22) "www.kadikoy-bld.gov.tr"
["HTTP_USER_AGENT"]=> string(69) "Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.0; .NET CLR 1.0.3705)" ["HTTPS"]=> string(3) "OFF"
["PATH"]=> string(51)
"/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin" ["REMOTE_ADDR"]=>
string(12) "172.22.1.250" ["REMOTE_PORT"]=> string(4) "2779"
["SCRIPT_FILENAME"]=> string(40)
"/usr/HTTPServer/htdocs/en_US/sniper1.php" ["SERVER_ADDR"]=> string(14)
"195.155.224.19" ["SERVER_ADMIN"]=> string(24)
"[EMAIL PROTECTED]" ["SERVER_NAME"]=> string(22)
"www.kadikoy-bld.gov.tr" ["SERVER_PORT"]=> string(2) "80"
["SERVER_SIGNATURE"]=> string(0) "" ["SERVER_SOFTWARE"]=> string(45)
"IBM_HTTP_Server/1.3.12.3 Apache/1.3.12 (Unix)" ["UNIQUE_ID"]=>
string(19) "PjaKrsOb4BMAAIkMcL4" ["GATEWAY_INTERFACE"]=> string(7)
"CGI/1.1" ["SERVER_PROTOCOL"]=> string(8) "HTTP/1.1"
["REQUEST_METHOD"]=> string(3) "GET" ["QUERY_STRING"]=> string(0) ""
["REQUEST_URI"]=> string(12) "/sniper1.php" ["SCRIPT_NAME"]=>
string(12) "/sniper1.php" ["PATH_TRANSLATED"]=> string(40)
"/usr/HTTPServer/htdocs/en_US/sniper1.php" ["PHP_SELF"]=> string(12)
"/sniper1.php" ["argv"]=> array(0) { } ["argc"]=> int(0) }
--



[2003-01-28 07:46:37] [EMAIL PROTECTED]

This looks to be related to (or even duplicate of) #21771.



[2003-01-28 07:05:21] [EMAIL PROTECTED]

of course i'm using register_globals = On



[2003-01-28 07:03:21] [EMAIL PROTECTED]

Hello,
Apache version : IBM_HTTP_Server/1.3.12.3 Apache/1.3.12 
OS : AIX 4.3.3 Maintenance Level 10 applied
I'm trying build a cookie based session system but an interesting
problem occurs.When i use setcookie() function, it sends cookie to
browser (and browser stores it) but i don't use cookie with
$cookievariable.After a little inspection ( :) ) i found this result :
--
Apache env. superglobal name   : value
HTTP_COOK0E: mytestcookie=mytestval
HTTP_CONNECT0ON: Keep-Alive  
--
it seems wrong superglobal names here (I -> zero)
if i use echo "$HTTP_COOK0E";   it works fine but if i use $HTTP_COOKIE
not work.




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

#21922 [Com]: suggestion for a new function

[michael . mauch]

 ID:   21922
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.2.3
 New Comment:

Have a look at the preg_replace function, which can do all kinds of
this, e.g. try:

echo preg_replace("/[[:alpha:]]/","","123hi456ho");

echo preg_replace("/[^[:alpha:]]/","","123hi456ho");


Previous Comments:


[2003-01-28 09:14:01] [EMAIL PROTECTED]


Hi,
I was just in the #php irc channel and I asked 'how to strip all
non-text characters from a string'
and two minutes later another guy comes in and asks the same q',

there is 'trim()' but it only does starts and ends,

there is a function in unix that is called 'strings' that does approx
this,

can you look into it do you think,

and if you do, maybe make it so it can be used the other way around too
(strip all text),

maybe call it 'strip_notext' or so

thanks,

Re






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

#21912 [Com]: getimagesize weirdness

[michael . mauch]

 ID:   21912
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Verified
 Bug Type: GetImageSize related
 Operating System: Linux
 PHP Version:  4.3.1-dev
 New Comment:

php -r '$size =
getimagesize("http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg";);
print_r($size); echo "\n";'

works without problems here (PHP 4.3.0), while

php -r '$size =
getimagesize("http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg";);
print_r($size); echo "\n";'

prints nothing. ImageMagick's "identify" sees some strange ipct data in
the second image; probably these make getimagesize() misbehave.


Previous Comments:


[2003-01-27 17:25:35] [EMAIL PROTECTED]

I can reproduce this with latest stable CVS (4.3.1-dev)
It does work if the image is local..but not if it's remote.




[2003-01-27 16:12:37] [EMAIL PROTECTED]

Hallo,

I have a weird problem, which I think is a bug. The following script
works with PHP 4.1.2 (I know, very outdated), but DOES NOT work with
PHP 4.3.0:

http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg";;
$image_size=getimagesize($foto);
$width=$image_size[0];
$height=$image_size[1];
$type=$image_size[2];
print ("\n");
print ("\n");
print ("width: $width; height: $height; type: $type\n");

print ("\n");

$foto="http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg";;
$image_size=getimagesize($foto);
$width=$image_size[0];
$height=$image_size[1];
$type=$image_size[2];
print ("\n");
print ("\n");
print ("width: $width; height: $height; type: $type\n");
?>

The problem is :

The first image works fine, it shows the height, width and type.
However, the information about the second image is only beeing
displayed if using PHP 4.1.2. With PHP 4.3.0 no information is beeing
displayed.





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

#13907 [Com]: Oracle Fetch row by row number

[michael . mauch]

 ID:   13907
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  4.0.6
 Assigned To:  maxim
 New Comment:

Probably he/she doesn't really need a new function, but only a hint how
to simulate the limit/offset syntax of MySQL/Postgresql.

Without the help of  (in
German, but not much text), I certainly would not know how to do it,
although I asked our local SQL gurus.


Previous Comments:


[2003-01-29 08:59:05] [EMAIL PROTECTED]

Well, this wouldn't make much sence as this should be controlled by
your SQL. What's the point to grab the whole table in your buffer to
then fetch only a few rows somewhere in the middle?

Anyhow, will assign it to myself for now.



[2001-11-02 05:37:16] [EMAIL PROTECTED]

Currently there's no way of fetching a row by row number.
OCIFetchStatement() fetches all rows returned by a query. 
OCIFetchInto() only allows to return the NEXT row.

It would make sense to be able to selectively fetch a subset of rows or
single rows by row number for large
row lists.





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

#21771 [Com]: variable names changing in turkish locale

[michael . mauch]

 ID:   21771
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Variables related
 Operating System: linux kernel 2.4.18
 PHP Version:  4.3.0
 New Comment:

Tufan, can you please (after answering Sniper's questions) try and put
the following lines into your apachectl:

unset LC_ALL
LC_CTYPE=C
export LC_CTYPE

See my comments on http://bugs.php.net/bug.php?id=21919 (in short:
perhaps this is Apache's problem, because it happens also with
mod_perl).


Previous Comments:


[2003-01-28 23:19:43] [EMAIL PROTECTED]

And are the names mangled in $GLOBALS too?
try:



And check the output for the _COOKIE / _SESSION indexes.




[2003-01-21 19:10:33] [EMAIL PROTECTED]

restore mangled summary and OS entries.




[2003-01-21 11:26:21] [EMAIL PROTECTED]

strange ... this was fixed for functions constants
but should not affect variables, as these are 
case insensitive (so no conversions take place
while resolving them)
or is there something different going on with
the super-globals?

does this affect $_SESSION only? what if you have
register_globals enabled and try to pass something
like "...script.php?ID=test"? do you have $ID or
$ÝD set in your script then?



[2003-01-21 06:27:16] [EMAIL PROTECTED]

by the way, it's turkish locale
tr_TR
iso8859-9



[2003-01-21 06:24:08] [EMAIL PROTECTED]

no code works. even the example in the php session documentation...
:)





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

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

#21933 [Com]: Date/Sec bug

[michael . mauch]

 ID:   21933
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: WinXP
 PHP Version:  4.3.0
 New Comment:

When I run your script, it exits at this line:
1049065200 2003.03.31 01:00:00 <-> 1049061600 2003.03.31 01:00:00
 ERROR 

As you can see on ,
March 30th does not have 24*60*60 seconds, because that's when Hungary
switches to daylight savings time.


Previous Comments:


[2003-01-29 03:48:44] [EMAIL PROTECTED]

When I run this script, it has make an error.
While I increment the an date with secsperday, it is make an wrong
result !

The example:

\n";

 $date=EncodeDate(2003,01,01);
 for ($i=0;$i<1000;$i++) {
  DecodeDate($date,$y,$m,$d);
  $a1=DateTimeToStr($date);
  $date2=EncodeDate($y,$m,$d);
  $a2=DateTimeToStr($date);
  print "$date $a1 <-> $date2 $a2\n";
  if (($a1<>$a2) or ($date<>$date2)) {print " ERROR \n";
exit;}
  $date=$date+SECSPERDAY;
 }
 print "DONE WITHOUT ERRORS !\n";
 print '';
?>




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

#21771 [Com]: variable names changing in turkish locale

[michael . mauch]

 ID:   21771
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Variables related
 Operating System: linux kernel 2.4.18
 PHP Version:  4.3.0
 New Comment:

Thanks for checking it out. Can you please close or "bogusify" the bug,
then (I can't, since I'm neither the submitter nor a PHP developer)?

As a last note: probably you will need to use something like

  setlocale(LC_CTYPE,"tr_TR") 

if you use strtoupper("i") etc., because otherwise PHP cannot know that
you want to get an uppercase I with dot.


Previous Comments:


[2003-01-30 03:30:53] [EMAIL PROTECTED]

Hmm...
Indeed, this seems to be a apache problem.

I took a look at the locale definition files for my OS (RedHat 7.2) and
they seem to contain correct definitions of uppercase and lowercase
letters (and their correspondance).

when

register_globals=on
LC_CTYPE=tr_TR

script.php?ID=some_value works perfectly.

with the same settings, a var_dump($GLOBALS) gives:

  ["HTTP_ACCEPT_ENCODÝNG"]=>
  string(38) "deflate, gzip, x-gzip, identity, *;q=0"
  ["HTTP_CONNECTÝON"]=>
  string(14) "Keep-Alive, TE"
  ["HTTP_COOKÝE"]=>
  string(42) "PHPSESSID=4035cdd7974d97ccdcd79f9f711299c1"
  ["HTTP_COOKÝE2"]=>
  string(10) "$Version=1"

Note the Ý in the variable names. However, names of variables such as
SCRIPT_FILENAME, SERVER_ADMIN, or SERVER_SIGNATURE are correct, i.e.
they contain an I and not an Ý.

In fact, as much as I can see, variables with this problem are only
those containing "COOKIE", "ENCODING", and "CONNECTION" words (whether
they are global or indices in the _SERVER or HTTP_SERVER_VARS). The
other variables containing "I" are correct.

So my original problem was actually: Since the register_globals off and
since apache did not pass cookies due to the incorrect variable name
(when it started with LC_CTYPE=tr_TR), my session script didn't work.

The same (or similar) problem occurs with mod_mime_magic.so, when
enabled, apache does not start at all, giving the error message
"Invalid command 'MIMEMagicFile', perhaps mis-spelled or...".

So,

unset LC_ALL
LC_CTYPE=C(or LC_CTYPE=en_US)
export LC_CTYPE

works (but you should do apachectl stop and apachectl start, instead of
apachectl restart).

Since this is probably a problem at the server side itself, a
setlocale(LC_ALL,"en_US") in the php script itself does not work (a
friend of mine had recommended trying, I gave a shot).

Thank you all for your help.



[2003-01-29 12:21:06] [EMAIL PROTECTED]

Tufan, can you please (after answering Sniper's questions) try and put
the following lines into your apachectl:

unset LC_ALL
LC_CTYPE=C
export LC_CTYPE

See my comments on http://bugs.php.net/bug.php?id=21919 (in short:
perhaps this is Apache's problem, because it happens also with
mod_perl).



[2003-01-28 23:19:43] [EMAIL PROTECTED]

And are the names mangled in $GLOBALS too?
try:



And check the output for the _COOKIE / _SESSION indexes.




[2003-01-21 19:10:33] [EMAIL PROTECTED]

restore mangled summary and OS entries.




[2003-01-21 11:26:21] [EMAIL PROTECTED]

strange ... this was fixed for functions constants
but should not affect variables, as these are 
case insensitive (so no conversions take place
while resolving them)
or is there something different going on with
the super-globals?

does this affect $_SESSION only? what if you have
register_globals enabled and try to pass something
like "...script.php?ID=test"? do you have $ID or
$ÝD set in your script then?



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

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

#21966 [Com]: date() or mktime() returning bad value for mktime month param of '2'

[michael . mauch]

 ID:   21966
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Gentoo Linux 1.4
 PHP Version:  4.2.2
 New Comment:

See what you get if you use the "r" format:

# php -r 'for($x=1; $x<=3; $x++) {
echo "$x = ".date("r", mktime(0,0,0,$x))."\n"; }'
1 = Thu, 30 Jan 2003 00:00:00 +0100
2 = Sun,  2 Mar 2003 00:00:00 +0100
3 = Sun, 30 Mar 2003 00:00:00 +0100

So apparently the "February, 30th" is turned into its normal
representation by mktime(). Although that doesn't seem to be
documented, I think that's a feature, because it helps doing date
calculations.


Previous Comments:


[2003-01-30 12:40:30] [EMAIL PROTECTED]

#!/usr/bin/php -q

1 = 01
2 = 03
3 = 03
4 = 04
5 = 05
6 = 06
7 = 07
8 = 08
9 = 09
10 = 10
11 = 11
12 = 12





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

#21971 [Com]: include() and Variables

[michael . mauch]

 ID:   21971
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: All
 PHP Version:  4.3.0
 New Comment:

I'm not sure what you mean by "accept a variable as input".

a) php -r '$s = "./hmm.php"; include($s);'
Works for me.

b) 


Previous Comments:


[2003-01-30 16:56:00] [EMAIL PROTECTED]

What follows is a feature request.  Searching the existing feature
requests have not turned up any similar results.

I have found that it might be convenient to allow include() and/or
require() to be able to accept a variable as input.

A couple of scenarios that this might be useful:

* Caching script segments
* Evaluating PHP inside of templates

My workaround has been to dump a variable to disk and then include it
as a file, after determining a unique file name to use.  After
including the file, it was deleted from disk.  This was for a
templating system that could recursively include other templates that
may or may not include php.

The reason for the approach was to reuse php as a the template
scripting language, as well.  Performance on my test server has been
okay, but I am sure that with a large amount of traffic, the file i/o
would slow the process down considerably.




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

#21131 [Com]: fopen with "a+" and the a rewind does'nt work anymore

[michael . mauch]

 ID:   21131
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Directory/Filesystem functions
 Operating System: Linux 2.4.18 (Redhat)
 PHP Version:  4.3.0RC4
 Assigned To:  wez
 New Comment:

Also on other systems (Solaris, some Linux versions). I think that test
case is a bit wrong. There's no guarantee in the C standard that
ftell() will point to the end of the file directly after
fopen(...,"a+"). You are guaranteed that you can read from anywhere in
the file, and that you can't overwrite anything in the file - writes go
always to the end of the file, no matter how hard you fseek() or
fsetpos().

Please see also:





Previous Comments:


[2003-02-02 14:35:16] [EMAIL PROTECTED]

ext/standard/tests/file/bug21131.phpt failed on W2k server with
latetest win32-snap:

 EXPECTED OUTPUT
int(6)
int(0)
foobar
 ACTUAL OUTPUT
int(0)
int(0)
foobar
 FAILED



[2002-12-22 12:16:59] [EMAIL PROTECTED]

This bug has been fixed in CVS.

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

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





[2002-12-21 08:25:00] [EMAIL PROTECTED]

With 4.2.3 and below the next code did give the contents of $file only
when the Apache runtime user was allowed to update that file. Now it
nevers gives the content of the file anymore.

$fp = fopen($file,"a+"); 
rewind($fp);
$fstr = fread($fp, filesize($file));

The PHP version box did not give 4.3.0RC4, but it's still there.

./configure --with-openssl --enable-cli --prefix=/www --with-mcrypt
--with-config-file-path=/www/conf --with-mysql
--with-apache=../apache_1.3.27 --enable-track-vars --with-gzlib






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

#21908 [Com]: File upload problems beginning in 4.3.0

[michael . mauch]

 ID:   21908
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *General Issues
 Operating System: NetBSD-1.5.2
 PHP Version:  4.3.0
 New Comment:

For file uploads it's $_FILES, not $_POST.

Please read
.


Previous Comments:


[2003-02-04 10:41:43] [EMAIL PROTECTED]

hi -
i set the file upload dir but the problem is still happening and seems
to be a little different. my filename variable does not get passed over
in the post when in the same php program. i have not tried an html that
calls a standalone php yet, but the $afile variable below holds nothing
when you output contents while $crud does. maybe $_POST is not valid
for filenames? or? should i just write email directly to someone? i
promise i've looked at all the docs and grovelled for help locally.  
thank you. 
evatc



[2003-02-03 13:36:48] [EMAIL PROTECTED]

The problem for me was that upload_tmp_dir did not need to be set in
4.2.3.  By default, it used /tmp.  Now if it isn't set, nothing
happens.  However, now that it is set in the php.ini everything is
working again.



[2003-02-03 13:32:40] [EMAIL PROTECTED]

Hello.
I am also finding this error. I am actually running on Linux but
everything else is the same version. this is kind of stolen out of the
wrox book. the variable $afile is empty but $crud gets passed over just
fine. am i referring to it incorrectly? this is making me nuts and i
have an enduser crawling on me to get his scripts fixed. please help.

thank you

[kovacs@darth eva]$ more cispt1test.php
";
print "";
print "";
print "";
print "";
print "";
print "";

}

function upload_file() {
global $afile;
error_reporting(E_ALL);
$afile = $_POST["afile"];
$crud = $_POST["crud"];
print "some stuff";
print "$afile $crud";
if (!@copy($afile,"/tmp/crud")) die ("Can't upload");
var_dump($_FILES);

}
?>


test










[2003-02-03 07:29:34] [EMAIL PROTECTED]

Please try this script:







If $_FILES array is empty after submit and no errors are given, try
this script:

 

And check the file upload related settings from the output:

post_max_size
file_uploads
upload_tmp_dir
upload_max_filesize

Also check your Apache error_log for any errors.




[2003-01-31 09:21:27] [EMAIL PROTECTED]

I also expirienced this problem. In my case I had "file_uploads = Off"
in php.ini and then "php_flag file_uploads on" for every virtual host
that require upload. That works perfectly in 4.2.3. According to
phpinfo() setting private flag have no effect for this option in 4.3.0.
I was forced to enable file uploads on system level in php.ini to solve
the problem.



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

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

#21973 [Com]: 'configure' script can't find libpng.(a|so), openldap...

[michael . mauch]

 ID:   21973
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: *Configuration Issues
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

Yes, you have to install libpng if you don't have it. The download URL
is in the manual, .


Previous Comments:


[2003-02-04 06:23:30] [EMAIL PROTECTED]

Hello there,

I'm having a similar problem as this one. I'm using a Sun Cobalt Qube 3
server on which I try to install PHP 4.3
I have searched for libpng on the harddisk but can't find it anywhere.
So how can I install GD when I don't have libpng on the server ??

Do I have to install libpng first, if yes then where can I get it?? I
guess this is the only problem I'm having right now, first I had a
problem because the qube requires php 4.0.6. for it's admin
functionality, but I managed to create a workaround for that problem.
When I finally have installed php 4.3 I can write a how-to so other
Qube users can update their php too. Sun doesn't support updating PHP
on a Qube just because they don't want to.



[2003-02-02 18:50:10] [EMAIL PROTECTED]

Back to dba:

I tried several combinations and having problems with
shared dba earlier than 3.3. I did some fixes and 
disallowed buildng shared dba with those versions for now.
However i got a short reply from sleepycat that they do
not have any idea how to explain what is happening.

Back to general linking:
I made a configure function which allows me to
handle all libraries required by gd and dba extension.
Since those are the most complicated cases i suppose we
could easily expand that function to handle all external
libraries. If that is done we may even add automatic
detection support for your directory structure.
I will post that function here and as a diff on php-dev
during the week 



[2003-02-01 01:08:15] [EMAIL PROTECTED]

> Anyway, in what version of PHP did LDAP configure
> work without any patches? 

The CVS tag is php_4_3_0pre2. I've done a fresh checkout
with that tag and can verify that the 'configure' script
generated by my copies of autoconf, etc, works. I tried
the following successful combinations:

 - autoconf 2.52, automake 1.5, libtool 1.4
 - autoconf 2.57, automake 1.7.2, libtool 1.4.3
 - flex 2.5.4 and bison 1.75 were used in all cases.

Compiler was gcc 3.2.1 for Sun UltraSPARC v9 using
Sun's CCS assembler Sun's CCS linker (typical scenario).

Notes:
 - first, I applied my int/long correctness patches
   (fortunately, these do not influence the configure step).
 - ldap configures and compiles with no warnings or
   errors. BUT I have to induce -lldap myself (other modules,
   such as database modules, seem to pick up their libraries
   okay, though). So really, ldap configuration wasn't
   entirely working in pre2 but the fault had a different
   manifestation than in the release, and had obvious
   output/cause/workaround.
 - the gd module configures with errors but I commented out
   the 'exit' commands and configure completes.
 - the ldap and gd modules then appear work fine with Apache.
 - I had to comment out _LT_AC_TRY_DLOPEN_SELF when using
   the second lot of auto tools.

But when I do a buildconf, configure, make with php_4_3_0, I
get the problem "Cannot find ldap libraries in $LDAP_LIBDIR."

Notes:
 - first, I applied my int/long correctness patches
   (fortunately, these do not influence the configure step).
 - I can work around the gd & ldap problems by manually
   deleting the 'exit' commands in the configure
   script or inserting the sparcv9 path element into the
   configure script, in which case the ldap module then
   picks up -lldap by itself.
 - the _LT_AC_TRY_DLOPEN_SELF problem has disappeared
   in 4.3.0 release.
 - the ldap and gd modules then appear work fine with Apache.

> Is the only problem really that we check that the actual
> library _file_ exists? Better way of course would be to
> use PHP_CHECK_LIBRARY macro always and not do the
> filesystem checks at all, like Marcus suggested..?

Yes, in my understanding.



[2003-01-31 07:55:59] [EMAIL PROTECTED]

I misunderstood the problem apparently, sorry for that.
Anyway, in what version of PHP did LDAP configure
work without any patches? 

Is the only problem really that we check that the actual library _file_
exists? Better way of course would be to use PHP_CHECK_LIBRARY macro
always and not do the filesystem checks at all, like Marcus
suggested..?





[2003-01-31 06:19:33] [EMAIL PROTECTED]

> we w

#22135 [Com]: PHP confused by America/Los Angeles timezone

[michael . mauch]

 ID:   22135
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

Using tzselect on Debian leads to the assumption that your TZ variable
should probably be "America/Los_Angeles" (with underscore). Can you
test that, please?


Previous Comments:


[2003-02-09 00:56:15] [EMAIL PROTECTED]

\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

The above script gives the following output:

server timezone is: America/Los Angeles
server time is: February 9, 2003, 6:45 am
changing server time zone to US/Pacific
new server time is: February 8, 2003, 10:45 pm
new server timezone for this script is: US/Pacific

the correct date and time in Los Angeles at the time of running the
script is: February 8, 2003, 10:45 pm

The date command on the system gives the correct time and date.

/etc/timezone contains US/Pacific

setting environment variable TZ=US/Pacific before restarting apache has
no effect on the above script. 

PHP configure line:

 './configure' '--with-mysql' '--with-apxs'
'--with-config-file-path=/etc/php4/apache' '--enable-track-vars'
'--enable-trans-sid' '--with-sybase=/usr/local/freetds' '--with-ldap'
'--with-imap' '--with-curl=/usr' '--with-pgsql=/usr/include/postgresql'
'--with-gd' '--with-xml' '--enable-cli'

Apache/1.3.26

Apache modules are: mod_php4, mod_ssl, mod_perl, mod_dav, mod_setenvif,
mod_unique_id, mod_expires, mod_auth, mod_access, mod_rewrite,
mod_alias, mod_userdir, mod_cgi, mod_dir, mod_autoindex, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_macro, mod_so,
http_core

This could be a problem with the underlying debian (2.2.19 kernel)
system, but I thought I should report it.

Thank you.










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

#22135 [Com]: PHP confused by America/Los Angeles timezone

[michael . mauch]

 ID:   22135
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

"apachectl restart" does not pick up the new TZ environment variable.
Did you try apachectl stop / apachectl start? I get the same results as
you with TZ="America/Los Angeles", but "America/Los_Angeles" or
"US/Pacific" work. As far as I know there's no php.ini setting that
fiddles with timezones.


Previous Comments:


[2003-02-09 10:54:54] [EMAIL PROTECTED]

Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.

I did this, using export TZ='America/Los_Angeles' and restarted apache.
 It made no difference to the php script output. 

In other words, if php believes that the server timezone is
'America/Los_Angeles' it gives the incorrect time.  But if it believes
that timezone is 'US/Pacific' it gives the correct time.  However,
setting TZ to 'US/Pacific' also makes no difference to the script
output.  So I'm wondering where PHP is picking up the timezone
information from and how I can get it to believe that the timezone is
'US/Pacific' from startup.  Can I set that in php.ini?

(Also, there are two timezone commands on debian, tzselect and
tzconfig.  tzconfig lets one choose either 'US/Pacific' or
'America/Los_Angeles' for the timezone, but neither makes a difference
to this script).



[2003-02-09 07:49:05] [EMAIL PROTECTED]

Using tzselect on Debian leads to the assumption that your TZ variable
should probably be "America/Los_Angeles" (with underscore). Can you
test that, please?



[2003-02-09 00:56:15] [EMAIL PROTECTED]

\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

The above script gives the following output:

server timezone is: America/Los Angeles
server time is: February 9, 2003, 6:45 am
changing server time zone to US/Pacific
new server time is: February 8, 2003, 10:45 pm
new server timezone for this script is: US/Pacific

the correct date and time in Los Angeles at the time of running the
script is: February 8, 2003, 10:45 pm

The date command on the system gives the correct time and date.

/etc/timezone contains US/Pacific

setting environment variable TZ=US/Pacific before restarting apache has
no effect on the above script. 

PHP configure line:

 './configure' '--with-mysql' '--with-apxs'
'--with-config-file-path=/etc/php4/apache' '--enable-track-vars'
'--enable-trans-sid' '--with-sybase=/usr/local/freetds' '--with-ldap'
'--with-imap' '--with-curl=/usr' '--with-pgsql=/usr/include/postgresql'
'--with-gd' '--with-xml' '--enable-cli'

Apache/1.3.26

Apache modules are: mod_php4, mod_ssl, mod_perl, mod_dav, mod_setenvif,
mod_unique_id, mod_expires, mod_auth, mod_access, mod_rewrite,
mod_alias, mod_userdir, mod_cgi, mod_dir, mod_autoindex, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_macro, mod_so,
http_core

This could be a problem with the underlying debian (2.2.19 kernel)
system, but I thought I should report it.

Thank you.










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

#22135 [Com]: PHP confused by America/Los Angeles timezone

[michael . mauch]

 ID:   22135
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: Linux (debian)
 PHP Version:  4.2.3
 New Comment:

You don't have a

  SetEnv TZ "America/Los Angeles"

in your httpd.conf, do you? Or maybe TZ is fixed in your apachectl
script?


Previous Comments:


[2003-02-09 13:54:50] [EMAIL PROTECTED]

here's what I do, as root:

# export TZ='America/Los_Angeles'
# set | grep TZ
# TZ=America/Los_Angeles
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# apachectl start
/usr/sbin/apachectl start: httpd started


output of the php script: 

server timezone is: America/Los Angeles
server time is: February 9, 2003, 7:51 pm
changing server time zone to US/Pacific
new server time is: February 9, 2003, 11:51 am
new server timezone for this script is: US/Pacific

I notice that PHP does not pick up the underscore in "Los_Angeles".

What I wondered was whether there's a way to do the equivalent of
putenv("TZ=US/Pacific") in php.ini?

However, I have just noticed that the time is wrong in OTRS running on
the same server -- and it is a set of perl scripts.  So maybe this is
not a PHP bug at all?



[2003-02-09 12:39:25] [EMAIL PROTECTED]

"apachectl restart" does not pick up the new TZ environment variable.
Did you try apachectl stop / apachectl start? I get the same results as
you with TZ="America/Los Angeles", but "America/Los_Angeles" or
"US/Pacific" work. As far as I know there's no php.ini setting that
fiddles with timezones.



[2003-02-09 10:54:54] [EMAIL PROTECTED]

Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.

I did this, using export TZ='America/Los_Angeles' and restarted apache.
 It made no difference to the php script output. 

In other words, if php believes that the server timezone is
'America/Los_Angeles' it gives the incorrect time.  But if it believes
that timezone is 'US/Pacific' it gives the correct time.  However,
setting TZ to 'US/Pacific' also makes no difference to the script
output.  So I'm wondering where PHP is picking up the timezone
information from and how I can get it to believe that the timezone is
'US/Pacific' from startup.  Can I set that in php.ini?

(Also, there are two timezone commands on debian, tzselect and
tzconfig.  tzconfig lets one choose either 'US/Pacific' or
'America/Los_Angeles' for the timezone, but neither makes a difference
to this script).



[2003-02-09 07:49:05] [EMAIL PROTECTED]

Using tzselect on Debian leads to the assumption that your TZ variable
should probably be "America/Los_Angeles" (with underscore). Can you
test that, please?



[2003-02-09 00:56:15] [EMAIL PROTECTED]

\n");
 print("server time is: " . date("F j, Y, g:i a") . "\n");
print("changing server time zone to US/Pacific\n");
putenv("TZ=US/Pacific");
 print("new server time is: " . date("F j, Y, g:i a") . "\n");
print("new server timezone for this script is: " . getenv('TZ'));
?>

The above script gives the following output:

server timezone is: America/Los Angeles
server time is: February 9, 2003, 6:45 am
changing server time zone to US/Pacific
new server time is: February 8, 2003, 10:45 pm
new server timezone for this script is: US/Pacific

the correct date and time in Los Angeles at the time of running the
script is: February 8, 2003, 10:45 pm

The date command on the system gives the correct time and date.

/etc/timezone contains US/Pacific

setting environment variable TZ=US/Pacific before restarting apache has
no effect on the above script. 

PHP configure line:

 './configure' '--with-mysql' '--with-apxs'
'--with-config-file-path=/etc/php4/apache' '--enable-track-vars'
'--enable-trans-sid' '--with-sybase=/usr/local/freetds' '--with-ldap'
'--with-imap' '--with-curl=/usr' '--with-pgsql=/usr/include/postgresql'
'--with-gd' '--with-xml' '--enable-cli'

Apache/1.3.26

Apache modules are: mod_php4, mod_ssl, mod_perl, mod_dav, mod_setenvif,
mod_unique_id, mod_expires, mod_auth, mod_access, mod_rewrite,
mod_alias, mod_userdir, mod_cgi, mod_dir, mod_autoindex, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_macro, mod_so,
http_core

This could be a problem with the underlying debian (2.2.19 kernel)
system, but I thought I should report it.

Thank you.










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

#22230 [Com]: libtool linking fails

[michael . mauch]

 ID:   22230
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Solaris 8
 PHP Version:  4.3.0
 New Comment:

Your sed is broken. Try adjusting your PATH:

export PATH=/usr/xpg4/bin/:$PATH

See , especially the
user notes - or search the bug database for "output line too long".


Previous Comments:


[2003-02-15 00:51:46] [EMAIL PROTECTED]

Compiling PHP as a static apache module with the following command:

./configure --with-apache=../apache_1.3.27 --with-pgsql=/data/postgres

Configure runs fine, and the build runs fine up until the final link
where it calls libtool with an insane number of link objects.  The link
fails because it looks like the command line is too long for libtool to
handle, giving the error:

gcc: main/all: No such file or directory
make: *** [sapi/cli/php] Error 1

main/all is actually a fragment of the libtool command line, several
thousand characters into the command line, which leads me to suspect
the libtool command line is far too long.

The libtool line that fails is this:

/bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 
-L/usr/ucblib
L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2 -L/data/postgres/lib
 -R /us
/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2 -R
/data/postgres/
ib ext/ctype/ctype.lo ext/mysql/php_mysql.lo
ext/mysql/libmysql/libmysql.lo ext
mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo
ext/mysql/libmysql/violite.l
 ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo
ext/mysql/libmysq
/my_lib.lo ext/mysql/libmysql/my_static.lo
ext/mysql/libmysql/my_malloc.lo ext/
ysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo
ext/mysql/libmysql/
y_delete.lo ext/mysql/libmysql/my_tempnam.lo
ext/mysql/libmysql/my_open.lo ext/
ysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo
ext/mysql/libmysql/my
write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo
ext/mysql/
ibmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo
ext/mysql/libmysql/mf_pack.lo
xt/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo
ext/mysql/libmy
ql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo
ext/mysql/libmysql/typelib.lo ex
/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo
ext/mysql/libmysql
mf_format.lo ext/mysql/libmysql/mf_path.lo
ext/mysql/libmysql/mf_unixpath.lo ex
/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo
ext/mysql/libmysq
/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo
ext/mysql/libmysql/thr_mutex.l
 ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo
ext/mysql/libmysql
default.lo ext/mysql/libmysql/my_compress.lo
ext/mysql/libmysql/array.lo ext/my
ql/libmysql/my_once.lo ext/mysql/libmysql/list.lo
ext/mysql/libmysql/my_net.lo
xt/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo
ext/mysql/libmysql/strxm
v.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo
ext/mysql/libm
sql/strend.lo ext/mysql/libmysql/strfill.lo
ext/mysql/libmysql/is_prefix.lo ext
mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo
ext/mysql/libmysql/stri
str.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo
ext/mysql/li
mysql/bchange.lo ext/mysql/libmysql/bmove.lo
ext/mysql/libmysql/bmove_upp.lo ex
/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo
ext/mysql/libmys
l/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo
ext/over
oad/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo
ext/pcre
pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo
ext/pgsql/pgsql.
o ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo
ext/sessio
/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo
ext/standard/base64.lo
ext/standard/basic_functions.lo ext/standard/browscap.lo
ext/standard/crc32.lo
xt/standard/crypt.lo ext/standard/cyr_convert.lo
ext/standard/datetime.lo ext/s
andard/dir.lo ext/standard/dl.lo ext/standard/dns.lo
ext/standard/exec.lo ext/s
andard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo
ext/standa
d/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo
ext/standard/ht
l.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo
ext/standa
d/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo
ext/sta
dard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo
ext/standard/pa
k.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo
ext/standard/quot_print
lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo
ext/standar
/string.lo ext/standard/scanf.lo ext/standard/syslog.lo
ext/standard/type.lo ex
/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo
ext/standar
/var.lo ext/standard/versioning.lo ext/standard/assert.lo
ext/standard/strnatcm
.lo

#19850 [Com]: sorting a String case-sensitive fails

[michael . mauch]

 ID:   19850
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Arrays related
 Operating System: Linux + Windows
 PHP Version:  4CVS-2002-10-10
 New Comment:

You want to use natcasesort().

strcasecmp() compares strings case-_in_sensitively - that means that 
'A' =='a', so your usage of usort() does exactly what it should.


Previous Comments:


[2002-11-17 07:01:12] [EMAIL PROTECTED]

Sorry that I open it again, but what should be the sense of sorting an
array like

Array
(
[0] => A
[1] => a
[2] => AA
[3] => b
[4] => B
[5] => BB
)

usort($test, 'strcasecmp'); 

should sort case-sensitive, that means a,A, b,B, c,C... but what is
A,a, b,B??? There is no logical algorithm to sort this way. What is the
next? c,C or C,c? How can I get a,A, b,B, c,C..., means _real_
case-sensitive?



[2002-10-27 19:56:59] [EMAIL PROTECTED]

it works for me:

Array
(
[0] => A
[1] => a
[2] => AA
[3] => b
[4] => B
[5] => BB
)

Which is exactly what you should get... and the algorithm is platform
independent in CVS



[2002-10-10 10:41:32] [EMAIL PROTECTED]

I tried the following script to sort an Array case-sensitive:




What I expected to get was:

Array
(
[0] => A
[1] => a
[2] => AA
[3] => B
[4] => b
[5] => BB
)

What I got on Win2000/PHP 4.2.4-dev was:

Array
(
[0] => A
[1] => a
[2] => AA
[3] => b
[4] => B
[5] => BB
)

and using Linux with PHP 4.1.2 I got

Array
(
[0] => a
[1] => A
[2] => AA
[3] => B
[4] => b
[5] => BB
)

both is not correct. 


regards 

Andreas





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

#20484 [Com]: Wrong detection of gnuiconv

[michael . mauch]

 ID:   20484
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: ICONV related
 Operating System: Linux RH 7.3, gnu libiconv
 PHP Version:  4CVS-2002-11-18 (dev)
 New Comment:

Can you please try

  --with-iconv

without "=/usr" and without the "--with-iconv-dir=/usr"? Your Redhat
7.3 should have a glibc 2.2.x, which has iconv builtin, so there's
AFAIK no point in installing an extra libiconv.


Previous Comments:


[2002-11-18 11:37:11] [EMAIL PROTECTED]

Hello,

I used redhat 7.3 and current cvs, iconv installed from sources using
version 1.8 (no rpm previously installed).

Configure options:./configure --prefix=/usr/local \
--enable-cli \
--enable-exif \
--with-calendar=shared \
--enable-magic-quotes \
--enable-trans-sid \
--enable-wddx \
--enable-ftp \
--with-gd \
--with-zlib \
--enable-gd-native-tt \
--with-t1lib="/usr/local" \
--with-jpeg-dir="/usr" \
--with-png-dir="/usr" \
--with-zlib-dir="/usr" \
--with-ttf \
--with-freetype-dir="/usr" \
 --with-mcrypt=/usr \
 --with-unixodbc=/usr \
--with-tiff-dir="/usr" \
--with-jpeg-dir="/usr" \
--with-zlib-dir="/usr" \
--with-xmlrpc \
 --with-openssl="/usr" \
 --with-ming="/usr/local" \
 --enable-bcmath \
 --with-gettext="/usr" \
 --with-mysql=/usr \
 --with-pgsql=/usr \
 --with-ibm-db2 \
 --enable-xslt \
 --with-xslt-sablot=/usr \
 --with-sablot-js=/usr \
 --enable-sockets \
 --with-imagick=/usr/local \
 --with-dom \
 --with-dom-xslt \
 --with-dom-exslt \
 --with-java=/usr/java/jdk1.3.1_03 \
 --with-tokenizer \
 --with-iconv=/usr \
 --with-iconv-dir=/usr \


make failed on:
/home/paj/projects/phpcvsbuild/php4/ext/iconv/iconv.c: In function
`zm_startup_miconv':
/home/paj/projects/phpcvsbuild/php4/ext/iconv/iconv.c:140:
`_libiconv_version' undeclared (first use in this function)
/home/paj/projects/phpcvsbuild/php4/ext/iconv/iconv.c:140: (Each
undeclared identifier is reported only once
/home/paj/projects/phpcvsbuild/php4/ext/iconv/iconv.c:140: for each
function it appears in.)
/home/paj/projects/phpcvsbuild/php4/ext/iconv/iconv.c: In function
`php_iconv_string':
/home/paj/projects/phpcvsbuild/php4/ext/iconv/iconv.c:255: warning:
assignment makes pointer from integer without a cast
make: *** [ext/iconv/iconv.lo] Error 1

It seems the wrong lib are detected:

136 #if HAVE_LIBICONV
137 {
138 static char buf[16];
139 snprintf(buf, sizeof(buf), "%d.%d",
140 ((_libiconv_version >> 8) & 0x0f),
(_libiconv_version & 0x0f));141 version = buf;
142 }
143 #elif HAVE_GLIBC_ICONV
144 version = (char *)gnu_get_libc_version();
145 #endif


hth

pa




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

#20594 [Com]: Date "W" switch returns 0 and 1 for First week randomly

[michael . mauch]

 ID:   20594
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: FreeBSD
 PHP Version:  4.2.3
 New Comment:

As stated in the manual, date("W", ...) returns the ISO8601 week
number. The first week number of any year is always 1. But January, 1st
is sometimes not in the first week of a year, but in the last week of
the previous year. See e.g.
 for details.


Previous Comments:


[2002-11-23 01:09:02] [EMAIL PROTECTED]

using date and the "W" (shows the week number) switch. Will return the
FIRST week number differantly depending on the year.

date("W", mktime(0,0,0,1,1,2000)); will return 0 
date("W", mktime(0,0,0,1,1,2001)); returns 1.

Only differance is the year. Here is a list of years and there first
week vaules, including Leap year.

for ($q=2001; $q<2021; $q++) {
$test1= date("W",  mktime(0,0,0,1,1,$q));
$leap1= date("L",  mktime(0,0,0,1,1,$q));
echo "Year: $q WeekNum: $test1 LeapYear: $leap1";
}

Year: 2001 WeekNum: 1 LeapYear: 0
Year: 2002 WeekNum: 1 LeapYear: 0
Year: 2003 WeekNum: 1 LeapYear: 0
Year: 2004 WeekNum: 1 LeapYear: 1
Year: 2005 WeekNum: 0 LeapYear: 0
Year: 2006 WeekNum: 0 LeapYear: 0
Year: 2007 WeekNum: 1 LeapYear: 0
Year: 2008 WeekNum: 1 LeapYear: 1
Year: 2009 WeekNum: 1 LeapYear: 0
Year: 2010 WeekNum: 0 LeapYear: 0
Year: 2011 WeekNum: 0 LeapYear: 0
Year: 2012 WeekNum: 0 LeapYear: 1
Year: 2013 WeekNum: 1 LeapYear: 0
Year: 2014 WeekNum: 1 LeapYear: 0
Year: 2015 WeekNum: 1 LeapYear: 0
Year: 2016 WeekNum: 0 LeapYear: 1
Year: 2017 WeekNum: 0 LeapYear: 0
Year: 2018 WeekNum: 1 LeapYear: 0
Year: 2019 WeekNum: 1 LeapYear: 0
Year: 2020 WeekNum: 1 LeapYear: 1



[2002-11-23 01:08:31] [EMAIL PROTECTED]

using date and the "W" (shows the week number) switch. Will return the
FIRST week number differantly depending on the year.

date("W", mktime(0,0,0,1,1,2000)); will return 0 
date("W", mktime(0,0,0,1,1,2001)); returns 1.

Only differance is the year. Here is a list of years and there first
week vaules, including Leap year.

for ($q=2001; $q<2021; $q++) {
$test1= date("W",  mktime(0,0,0,1,1,$q));
$leap1= date("L",  mktime(0,0,0,1,1,$q));
echo "Year: $q WeekNum: $test1 LeapYear: $leap1";
}

Year: 2001 WeekNum: 1 LeapYear: 0
Year: 2002 WeekNum: 1 LeapYear: 0
Year: 2003 WeekNum: 1 LeapYear: 0
Year: 2004 WeekNum: 1 LeapYear: 1
Year: 2005 WeekNum: 0 LeapYear: 0
Year: 2006 WeekNum: 0 LeapYear: 0
Year: 2007 WeekNum: 1 LeapYear: 0
Year: 2008 WeekNum: 1 LeapYear: 1
Year: 2009 WeekNum: 1 LeapYear: 0
Year: 2010 WeekNum: 0 LeapYear: 0
Year: 2011 WeekNum: 0 LeapYear: 0
Year: 2012 WeekNum: 0 LeapYear: 1
Year: 2013 WeekNum: 1 LeapYear: 0
Year: 2014 WeekNum: 1 LeapYear: 0
Year: 2015 WeekNum: 1 LeapYear: 0
Year: 2016 WeekNum: 0 LeapYear: 1
Year: 2017 WeekNum: 0 LeapYear: 0
Year: 2018 WeekNum: 1 LeapYear: 0
Year: 2019 WeekNum: 1 LeapYear: 0
Year: 2020 WeekNum: 1 LeapYear: 1




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

#20592 [Com]: mktime(0,0,0,08,02,2003) get the error result "1038758400"

[michael . mauch]

 ID:   20592
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: FreeBSD 4.7-STABLE
 PHP Version:  4.2.3
 New Comment:

See :

literal numbers starting with 0 are interpreted as octal numbers, so
you should just omit the 0 and write 8 and 9 instead of 08 and 09.


Previous Comments:


[2002-11-22 23:43:17] [EMAIL PROTECTED]

mktime(0,0,0,08,02,2003) is 1038758400
mktime(0,0,0,09,02,2003) is 1038758400
mktime(0,0,0,10,02,2003) is 1065024000



[2002-11-22 22:14:30] [EMAIL PROTECTED]

mktime(0,0,0,08,02,2003) is 1038758400
mktime(0,0,0,09,02,2003) is 1038758400
mktime(0,0,0,10,02,2003) is 1065024000





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

#20596 [Com]: date function gives wrong result for format 't'

[michael . mauch]

 ID:   20596
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Date/time related
 Operating System: WIN 2000
 PHP Version:  4.2.1
 New Comment:

The second argument of date() should be an integer timestamp, not a
string. You can use e.g. mktime() or strtotime() to get such a
timestamp:

# php -r 'echo date("t", mktime(0,0,0,9,1,2002)),"\n";'
30


Previous Comments:


[2002-11-23 09:30:04] [EMAIL PROTECTED]







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

#20678 [Com]: segmentation fault (without PHP, things work fine)

[michael . mauch]

 ID:   20678
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache related
 Operating System: linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

Try configuring your Apache with the pthread library:

LDFLAGS="-lpthread" ./configure ...

(or if your platform doesn't have a pthread library: use "ldd
libphp4.so" and "ldd httpd" and make sure that both of them are linked
to the same thread library).


Previous Comments:


[2002-11-27 16:45:15] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

The crash appears to occur deep inside the Apache code (last 9 steps).
You may get more meaningful data if you compile Apache with debug
symbols, but given the provided backtrace the crash does not appear to
be the fault of PHP.



[2002-11-27 10:33:29] [EMAIL PROTECTED]

Sample script:


apache-1.3.27 configured with:
./configure --enable-module=unique_id --enable-module=rewrite
--enable-module=usertrack --enable-module=so

PHP-4.2.3 configured with:
./configure --with-pgsql --with-interbase
--with-mysql=/usr/local/mysql/ --with-apxs=/www/bin/apxs --with-openssl
--enable-debug

gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x4020f466 in ?? ()
(gdb) bt
#0  0x4020f466 in ?? ()
#1  0x4020b4e2 in ?? ()
#2  0x401f92a3 in ?? ()
#3  0x401d1181 in ?? ()
#4  0x401f9993 in ?? ()
#5  0x4020d4c7 in ?? ()
#6  0x40207a30 in ?? ()
#7  0x402089c8 in ?? ()
#8  0x40208a52 in ?? ()
#9  0x808dd69 in ap_invoke_handler (r=0x81bafdc) at http_config.c:538
#10 0x80a38cf in process_request_internal (r=0x81bafdc) at
http_request.c:1312
#11 0x80a3d36 in ap_internal_redirect (new_uri=0x81bafb4 "/index.php",

r=0x81ba354) at http_request.c:1440
#12 0x8074336 in handle_dir (r=0x81ba354) at mod_dir.c:174
#13 0x808dd69 in ap_invoke_handler (r=0x81ba354) at http_config.c:538
#14 0x80a38cf in process_request_internal (r=0x81ba354) at
http_request.c:1312
#15 0x80a393a in ap_process_request (r=0x81ba354) at
http_request.c:1328
#16 0x809a150 in child_main (child_num_arg=0) at http_main.c:4629
#17 0x809a315 in make_child (s=0x816acdc, slot=0, now=1038414204)
at http_main.c:4744
#18 0x809a496 in startup_children (number_to_start=1) at
http_main.c:4826
#19 0x809ab2d in standalone_main (argc=4, argv=0xb8d4) at
http_main.c:5134
#20 0x809b39c in main (argc=4, argv=0xb8d4) at http_main.c:5482
#21 0x400892e7 in __libc_start_main () from /lib/libc.so.6

/www/logs/error_log:
...[notice] child pid 18177 exit signal Segmentation fault (11)

-

If you'd like me to try different configs, etc, let me know.

Regards
Henry




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

#20678 [Com]: segmentation fault (without PHP, things work fine)

[michael . mauch]

 ID:   20678
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Bogus
 Bug Type: Apache related
 Operating System: linux 2.4.19
 PHP Version:  4.2.3
 New Comment:

Yes, but some libraries are sometimes linked against libpthread, and if
you load such a library into an Apache without libpthread, it dies
sometimes.

See  ,
 and 

(the last one seems to imply that it's not only a bug in glibc-2.1.3,
but also happens elsewhere).


Previous Comments:


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

Apache 1 & PHP do not need to be linked against a threading library.
Apache 1 operates on a pre-fork model, meaning that it forks child
processes rather then making threads.



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

Try configuring your Apache with the pthread library:

LDFLAGS="-lpthread" ./configure ...

(or if your platform doesn't have a pthread library: use "ldd
libphp4.so" and "ldd httpd" and make sure that both of them are linked
to the same thread library).



[2002-11-27 16:45:15] [EMAIL PROTECTED]

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

Thank you for your interest in PHP.

The crash appears to occur deep inside the Apache code (last 9 steps).
You may get more meaningful data if you compile Apache with debug
symbols, but given the provided backtrace the crash does not appear to
be the fault of PHP.



[2002-11-27 10:33:29] [EMAIL PROTECTED]

Sample script:


apache-1.3.27 configured with:
./configure --enable-module=unique_id --enable-module=rewrite
--enable-module=usertrack --enable-module=so

PHP-4.2.3 configured with:
./configure --with-pgsql --with-interbase
--with-mysql=/usr/local/mysql/ --with-apxs=/www/bin/apxs --with-openssl
--enable-debug

gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x4020f466 in ?? ()
(gdb) bt
#0  0x4020f466 in ?? ()
#1  0x4020b4e2 in ?? ()
#2  0x401f92a3 in ?? ()
#3  0x401d1181 in ?? ()
#4  0x401f9993 in ?? ()
#5  0x4020d4c7 in ?? ()
#6  0x40207a30 in ?? ()
#7  0x402089c8 in ?? ()
#8  0x40208a52 in ?? ()
#9  0x808dd69 in ap_invoke_handler (r=0x81bafdc) at http_config.c:538
#10 0x80a38cf in process_request_internal (r=0x81bafdc) at
http_request.c:1312
#11 0x80a3d36 in ap_internal_redirect (new_uri=0x81bafb4 "/index.php",

r=0x81ba354) at http_request.c:1440
#12 0x8074336 in handle_dir (r=0x81ba354) at mod_dir.c:174
#13 0x808dd69 in ap_invoke_handler (r=0x81ba354) at http_config.c:538
#14 0x80a38cf in process_request_internal (r=0x81ba354) at
http_request.c:1312
#15 0x80a393a in ap_process_request (r=0x81ba354) at
http_request.c:1328
#16 0x809a150 in child_main (child_num_arg=0) at http_main.c:4629
#17 0x809a315 in make_child (s=0x816acdc, slot=0, now=1038414204)
at http_main.c:4744
#18 0x809a496 in startup_children (number_to_start=1) at
http_main.c:4826
#19 0x809ab2d in standalone_main (argc=4, argv=0xb8d4) at
http_main.c:5134
#20 0x809b39c in main (argc=4, argv=0xb8d4) at http_main.c:5482
#21 0x400892e7 in __libc_start_main () from /lib/libc.so.6

/www/logs/error_log:
...[notice] child pid 18177 exit signal Segmentation fault (11)

-

If you'd like me to try different configs, etc, let me know.

Regards
Henry




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

#20702 [Com]: strtoupper

[michael . mauch]

 ID:   20702
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  4.2.2
 New Comment:

Is your locale correctly set?


Try setlocale(LC_ALL,'Portuguese')  or something like that
(I don't know what your locale is, look it up in the manual of your
OS).


Previous Comments:


[2002-11-28 12:45:08] [EMAIL PROTECTED]

It's not a bug.. it's more than a feature i guess.. the strtoupper
don't convert characters like áóç.. etc.

I don't know if it's because of the character system i'm using in
php.ini

;default_charset = "iso-8859-1"

But.. anyway.. it's just a suggestion :)




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

#20802 [Com]: memory limit crash

[michael . mauch]

 ID:   20802
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Reproducible crash
 Operating System: Redhat 7.0
 PHP Version:  4.3.0RC2
 New Comment:

I can also verify this with 4.3.0-cvs. With the cli PHP I can get a
core dump showing a nearly endless calling stack - probably the
memory_limit only looks at the data size, not at the stack size (but of
course this huge stack usage should not happen in the first place).

#0  0x081d0c26 in php_error_cb ()
(gdb) bt -30
#29239 0x081d0c4d in php_error_cb ()
#29240 0x08209b38 in zend_error ()
#29241 0x081f5d03 in _emalloc ()
#29242 0x081f5fc1 in _erealloc ()
#29243 0x081d4154 in xbuf_resize ()
#29244 0x081d41ec in xbuf_init ()
#29245 0x081d4f4a in vspprintf ()
#29246 0x081d0c4d in php_error_cb ()
#29247 0x08209b38 in zend_error ()
#29248 0x081f5d03 in _emalloc ()
#29249 0x081f5fc1 in _erealloc ()
#29250 0x081d4154 in xbuf_resize ()
#29251 0x081d41ec in xbuf_init ()
#29252 0x081d4f4a in vspprintf ()
#29253 0x081d0c4d in php_error_cb ()
#29254 0x08209b38 in zend_error ()
#29255 0x081f5d03 in _emalloc ()
#29256 0x081f5fc1 in _erealloc ()
#29257 0x081d4154 in xbuf_resize ()
#29258 0x081d41ec in xbuf_init ()
#29259 0x081d4f4a in vspprintf ()
#29260 0x081d0c4d in php_error_cb ()
#29261 0x08209b38 in zend_error ()
#29262 0x081f61fe in _erealloc ()
#29263 0x08205ab5 in concat_function ()
#29264 0x08218c48 in execute ()
#29265 0x08209fa4 in zend_execute_scripts ()
#29266 0x081d32dc in php_execute_script ()
#29267 0x08221707 in main ()
#29268 0x402718c1 in __libc_start_main (main=0x8220b48 , argc=3,

argv=0xbfffe944, init=0x80792f8 <_init>, fini=0x826c8f4 <_fini>, 
rtld_fini=0x4000a914 <_dl_fini>, stack_end=0xbfffe93c)
at ../sysdeps/generic/libc-start.c:92


Previous Comments:


[2002-12-04 00:33:07] [EMAIL PROTECTED]

Veryfied with PHP 4.4.0-dev (Nov 29 2002) and PHP 4.3.0-dev (Nov 25
2002). With both versions the script just ended without any error
message, but there is no segmentation fault.

Derick



[2002-12-03 16:12:50] [EMAIL PROTECTED]

I have a php installation with a memory limit set to 8MB. If I try to
run this script



I don't receive an error like "memory limit excedeed" (10MB > 8MB),
simply the server kills the connection without any error on the screen
or in the logs.

Server configuration:
Linux Redhat 7.0
Apache 1.3.22
PHP 4.3.0RC2
Zend Optimizer 2.0.3
Mysql 4.0.5

Configure:
'./configure' '--enable-track-vars' '--prefix=/usr'
'--exec-prefix=/usr'
'--libexecdir=/usr/lib/apache' '--bindir=/usr/bin'
'--sbindir=/usr/sbin'
'--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf'
'--localstatedir=/var' '--libdir=/usr/lib/apache'
'--includedir=/usr/include/apache' '--mandir=/usr/man'
'--with-mysql=/usr'
'--enable-memory-limit' '--with-config-file-path=/usr/local/Zend/etc'
'--with-apxs' '--with-zlib'






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

#20887 [Com]: /php.ini

[michael . mauch]

 ID:   20887
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Mandrqke Linux 9.0
 PHP Version:  4.3.0RC2
 New Comment:

I can't see that /php.ini is used here, but php/php-cli.ini is used,
i.e. a file relative to the place from where PHP was started. 
With PHPRC=/xizzy I get:

# strace -eopen php -r 'echo "bla";' 2>&1|grep ini
open("php/php-cli.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file
or directory)
open("/xizzy/php-cli.ini", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such
file or directory)
open("/usr/local/lib/php-cli.ini", O_RDONLY|O_LARGEFILE) = 3
open("/usr/local/lib/php/browscap/browscap.ini", O_RDONLY|O_LARGEFILE)
= 3

And if php/php-cli.ini is there, PHP only reads that one. This is with
4.3.0-cvs from today, and I don't have Mandrake here (once upon a time,
it was a SuSE Linux).


Previous Comments:


[2002-12-08 14:53:59] [EMAIL PROTECTED]

If /php.ini exists, that one is used no matter what PHPRC env is set or
compiled in when starting up apache from a SysV script. Is it a bug in
php, or could it be the Mandrake Linux 9.0 system?




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

#21386 [Com]: Hebrew problem...

[michael . mauch]

 ID:   21386
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Win Nt
 PHP Version:  4.3.0
 New Comment:

This might be a locale problem. Try setting your locale, e.g. like so:

setlocale(LC_CTYPE,"Hebrew");

Without knowing your locale, PHP (or the underlying C library) has no
chance of knowing which character codes are letters and which are
punctuation (the letter you wrote looks like a division symbol in my
locale with its ISO-8859-1 character set).


Previous Comments:


[2003-01-03 05:42:02] [EMAIL PROTECTED]

Hi,
I'm from Israel and I have a problem with Hebrew + PHP.
I am using the function PREG but one of the Hebrew letters, PHP doesn't
recognize as a letter (The letter is "÷").
That makes the following problems:
\b- if the letter start or finish a word PHP won't consider her.
\w-PHP doesn't consider her as a letter… and more…
I hope there is something to do about it.

P.S – Excuse me for any spelling problems, I don't write so good in
English…
Thank you very much.
Ido. 




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

Bug #17449 Updated: sort() does not work

[michael . mauch]

 ID:   17449
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Arrays related
 Operating System: Digital UNIX V4.0G (Rev. 1530)
 PHP Version:  4.2.0
 New Comment:

On Digital UNIX V4.0G (Rev. 1530), sort() does not work with PHP 4.2.1,
either. It does work with PHP 4.0.5 on that same platform. Should I try
PHP 4.1.x to see where things started to go wrong?


Previous Comments:


[2002-05-27 06:38:51] [EMAIL PROTECTED]

Reclassified.



[2002-05-27 06:31:15] [EMAIL PROTECTED]

Example script:

 $d) ? 1 : -1;
}

$arr = array(1, 3, 2, 10, 9);
//print_r($arr);
var_dump($arr);
sort($arr, SORT_NUMERIC);
var_dump($arr);
//reset($arr);
echo "";
print_r($arr);
/*srand((float)microtime()*100);
shuffle($arr);
echo "";
print_r($arr);*/
?>


PHP Version 4.0.6

SunOS xxx 5.7 Generic_106541-15 sun4us sparc FJSV,GPUS

'./configure' '--prefix=/usr/local'
'--with-apache=/usr/local/Apachetoolbox-1.5.34/apache_1.3.20'
'--enable-exif' '--enable-track-vars' '--with-calendar=shared'
'--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid'
'--enable-wddx' '--enable-ftp' '--with-oci8'
'--with-mysql=/usr/local/mysql' 


array(5) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(10)
  [4]=>
  int(9)
}
array(5) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
  [3]=>
  int(9)
  [4]=>
  int(10)
}
Array
(
[0] => 1
[1] => 2
[2] => 3
[3] => 9
[4] => 10
)

So sorting works fine on PHP 4.0.6 on Solaris


PHP Version 4.2.0

OSF1 x V4.0 1530 alpha

'./configure' '--prefix=/usr/local'
'--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24'
'--enable-exif' '--enable-track-vars' '--with-calendar=shared'
'--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid'
'--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local'
'--with-oci8=/appl/oracle/product/8.1.6'
'--with-mysql=/usr/local/mysql'



array(5) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(10)
  [4]=>
  int(9)
}
array(5) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(10)
  [4]=>
  int(9)
}
Array
(
[0] => 1
[1] => 3
[2] => 2
[3] => 10
[4] => 9
)




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

Bug #17449 Updated: sort() does not work

[michael . mauch]

 ID:   17449
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Arrays related
 Operating System: Digital UNIX V4.0G (Rev. 1530)
 PHP Version:  4.2.1
 New Comment:

I checked some older versions:
until PHP-4.1.2, sort() was fine. I didn't check 4.2.0RC*, yet, but
will do so tomorrow.


Previous Comments:


[2002-05-27 10:44:43] [EMAIL PROTECTED]

Updated version according to Michaels tests.



[2002-05-27 10:39:24] [EMAIL PROTECTED]

This would be great. I tested it on PHP 4.2.1 on Win2k, it worked fine.
So it seems to be a platform specific problem. 

I can help you with testing other versions on that machine/fixing the
bug. It would be nice, if some of the core developers (maybe Andrei,
Andi, Rasmus, Zeev, Jeroen, Derick - these are the people who did most
changes in the last months on array.c) could give us some information
on what files may affect this.

I've found that between 4.0.5 and 4.2.1 nearly the whole source for
PHP_FUNCTION(sort) has changed.



[2002-05-27 09:46:54] [EMAIL PROTECTED]

On Digital UNIX V4.0G (Rev. 1530), sort() does not work with PHP 4.2.1,
either. It does work with PHP 4.0.5 on that same platform. Should I try
PHP 4.1.x to see where things started to go wrong?



[2002-05-27 06:38:51] [EMAIL PROTECTED]

Reclassified.



[2002-05-27 06:31:15] [EMAIL PROTECTED]

Example script:

 $d) ? 1 : -1;
}

$arr = array(1, 3, 2, 10, 9);
//print_r($arr);
var_dump($arr);
sort($arr, SORT_NUMERIC);
var_dump($arr);
//reset($arr);
echo "";
print_r($arr);
/*srand((float)microtime()*100);
shuffle($arr);
echo "";
print_r($arr);*/
?>


PHP Version 4.0.6

SunOS xxx 5.7 Generic_106541-15 sun4us sparc FJSV,GPUS

'./configure' '--prefix=/usr/local'
'--with-apache=/usr/local/Apachetoolbox-1.5.34/apache_1.3.20'
'--enable-exif' '--enable-track-vars' '--with-calendar=shared'
'--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid'
'--enable-wddx' '--enable-ftp' '--with-oci8'
'--with-mysql=/usr/local/mysql' 


array(5) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(10)
  [4]=>
  int(9)
}
array(5) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
  [3]=>
  int(9)
  [4]=>
  int(10)
}
Array
(
[0] => 1
[1] => 2
[2] => 3
[3] => 9
[4] => 10
)

So sorting works fine on PHP 4.0.6 on Solaris


PHP Version 4.2.0

OSF1 x V4.0 1530 alpha

'./configure' '--prefix=/usr/local'
'--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24'
'--enable-exif' '--enable-track-vars' '--with-calendar=shared'
'--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid'
'--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local'
'--with-oci8=/appl/oracle/product/8.1.6'
'--with-mysql=/usr/local/mysql'



array(5) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(10)
  [4]=>
  int(9)
}
array(5) {
  [0]=>
  int(1)
  [1]=>
  int(3)
  [2]=>
  int(2)
  [3]=>
  int(10)
  [4]=>
  int(9)
}
Array
(
[0] => 1
[1] => 3
[2] => 2
[3] => 10
[4] => 9
)




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

Bug #17449 Updated: sort() does not work

[michael . mauch]

 ID:   17449
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Arrays related
 Operating System: Digital UNIX V4.0G (Rev. 1530)
 PHP Version:  4.2.1
 New Comment:

Bug #17257 seems to be the same problem ("Digital UNIX OSF/1" is the
old name of "Compaq Tru64"). People there found that all sort functions
broke with PHP-4.2.0RC1, I can confirm this now.

Smallest test program:



Output:

Array
(
[0] => 9
[1] => 7
[2] => 3
[3] => 5
)

It's not compiler-related, both gcc-2.95.2 and Compac C V6.3-129 give
the same results. Maybe endianess-related (the Compaq machine have
Alpha processors)?

If somebody more clueful wants to take a look at this problem: Compaq
provides free test accounts (not only with Tru64, but also with
FreeBSD, NetBSD and Linux), see
.

I compiled PHP-4.2.0RC1 there on FreeBSD/Alpha, and gcc-2.95.3 gives
lots of warnings:

*** The -O2 flag TRIGGERS KNOWN OPTIMIZER BUGS ON THIS PLATFORM

But even with CFLAGS="-O0 -g" sort() does not sort at all.

On FreeBSD/Intel it does work, so it probably is an endianess problem.


Previous Comments:


[2002-05-27 14:29:54] [EMAIL PROTECTED]

Well,
the script runs fine under my IRIX64 6.5.16m on mod_php/Apache 1.3.24
but not when using a 64bit cgi binary with Apache2.

Case 1
http://sgi.takenet.de/php/sort.php

Case 2
http://sgi.takenet.de:8080/php/sort.php



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

I checked some older versions:
until PHP-4.1.2, sort() was fine. I didn't check 4.2.0RC*, yet, but
will do so tomorrow.



[2002-05-27 10:44:43] [EMAIL PROTECTED]

Updated version according to Michaels tests.



[2002-05-27 10:39:24] [EMAIL PROTECTED]

This would be great. I tested it on PHP 4.2.1 on Win2k, it worked fine.
So it seems to be a platform specific problem. 

I can help you with testing other versions on that machine/fixing the
bug. It would be nice, if some of the core developers (maybe Andrei,
Andi, Rasmus, Zeev, Jeroen, Derick - these are the people who did most
changes in the last months on array.c) could give us some information
on what files may affect this.

I've found that between 4.0.5 and 4.2.1 nearly the whole source for
PHP_FUNCTION(sort) has changed.



[2002-05-27 09:46:54] [EMAIL PROTECTED]

On Digital UNIX V4.0G (Rev. 1530), sort() does not work with PHP 4.2.1,
either. It does work with PHP 4.0.5 on that same platform. Should I try
PHP 4.1.x to see where things started to go wrong?



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

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

Bug #17449 Updated: sort() does not work

[michael . mauch]

 ID:   17449
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Arrays related
 Operating System: Digital UNIX V4.0G (Rev. 1530)
 PHP Version:  4.2.1
 New Comment:

php4-20020528.tar.gz doesn't compile here:

% configure --prefix=/Team/local
[...]
gcc  -Imain/ -I/Team/local/src/php4-20020528/main/ -DPHP_ATOM_INC
-I/Team/local/src/php4-20020528/include
-I/Team/local/src/php4-20020528/main
-I/Team/local/src/php4-20020528
-I/Team/local/src/php4-20020528/Zend
-I/Team/local/src/php4-20020528/ext/xml/expat 
-I/Team/local/src/php4-20020528/TSRM -g -O2  -c
/Team/local/src/php4-20020528/main/user_streams.c -o
main/user_streams.o  && echo > main/user_streams.lo
In file included from
/usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36,
 from
/Team/local/src/php4-20020528/Zend/zend.h:59,
 from /Team/local/src/php4-20020528/main/php.h:34,
 from
/Team/local/src/php4-20020528/main/user_streams.c:22:
/usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36:
warning: redefinition of `va_list'
/usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7:
warning: `va_list' previously declared here
Make:  Don't know how to make /zend_language_parser.c.  Stop.

Zend/zend_language_parser.c exists, but the Makefile searches for
/zend_language_parser.c and several other files in /.


Previous Comments:


[2002-05-27 17:28:23] [EMAIL PROTECTED]

This may be related to a casting problem which is supposed to be fixed
in HEAD, please try this version (snapshots are available at
snaps.php.net), thx.



[2002-05-27 17:19:01] [EMAIL PROTECTED]

4.2.0RC1 introduced the new sorting code Zend/zend_qsort.c from
Sterling, maybe that's related?



[2002-05-27 15:42:16] [EMAIL PROTECTED]

Bug #17257 seems to be the same problem ("Digital UNIX OSF/1" is the
old name of "Compaq Tru64"). People there found that all sort functions
broke with PHP-4.2.0RC1, I can confirm this now.

Smallest test program:



Output:

Array
(
[0] => 9
[1] => 7
[2] => 3
[3] => 5
)

It's not compiler-related, both gcc-2.95.2 and Compac C V6.3-129 give
the same results. Maybe endianess-related (the Compaq machine have
Alpha processors)?

If somebody more clueful wants to take a look at this problem: Compaq
provides free test accounts (not only with Tru64, but also with
FreeBSD, NetBSD and Linux), see
.

I compiled PHP-4.2.0RC1 there on FreeBSD/Alpha, and gcc-2.95.3 gives
lots of warnings:

*** The -O2 flag TRIGGERS KNOWN OPTIMIZER BUGS ON THIS PLATFORM

But even with CFLAGS="-O0 -g" sort() does not sort at all.

On FreeBSD/Intel it does work, so it probably is an endianess problem.



[2002-05-27 14:29:54] [EMAIL PROTECTED]

Well,
the script runs fine under my IRIX64 6.5.16m on mod_php/Apache 1.3.24
but not when using a 64bit cgi binary with Apache2.

Case 1
http://sgi.takenet.de/php/sort.php

Case 2
http://sgi.takenet.de:8080/php/sort.php



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

I checked some older versions:
until PHP-4.1.2, sort() was fine. I didn't check 4.2.0RC*, yet, but
will do so tomorrow.



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

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

#19890 [NEW]: --prefix is not honoured for PEAR install

[michael . mauch]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.0-pre1
PHP Bug Type: *Compile Issues
Bug description:  --prefix is not honoured for PEAR install

Trying to install PHP into a directory other than /usr/local results in a
broken PEAR install, because the --prefix directory is not honoured:

Installing PHP SAPI module
Installing shared extensions:
/house/elmicha/spe142/lib/php/extensions/no-debug-non-zts-20020429/
Installing PHP CLI binary:/house/elmicha/spe142/bin/
Installing PEAR environment:  /house/elmicha/spe142/lib/php/

Warning: mkdir(/usr/local/lib/php) [http://www.php.net/function.mkdir]:
Permission denied in
/house/elmicha/local/src/php-4.3.0pre1/pear/System.php on line 236

Warning: mkdir(/usr/local/lib/php/.registry)
[http://www.php.net/function.mkdir]: No such file or directory in
/house/elmicha/local/src/php-4.3.0pre1/pear/System.php on line 236


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

#19893 [Com]: Output not displayed with $_SERVER

[michael . mauch]

 ID:   19893
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: WIndows ME
 PHP Version:  4.2.3
 New Comment:

Is this just I typo in your bug report or is this copied and pasted
from your actual file?

 method=post>
 ^

Should be:

 method=post>


Previous Comments:


[2002-10-14 01:05:25] [EMAIL PROTECTED]

try it with a different client, like wget or cURL.
also, what does this script output?








[2002-10-13 23:18:07] [EMAIL PROTECTED]

I sem to have this problem. I recently upgraded to PHP 4.2.3. Since it
has register_globals turned off, I went through and attempted to modify
my code to the new format. I seem to keep having this one problem
though.

When I view this in a browser(IE 5.5)  method=post> it will not give me any
output, no warnings, no errors, nothing. When I isolated just this
piece of code, and put it in a seperate document, it should have had
the output of
, but for some reason it would not
parse it. I have no clue why this is happening. Is it a bug, or am I
just stupid?




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

#19970 [Com]: feof()/fgets()/fgetcsv() problem

[michael . mauch]

 ID:   19970
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.7-STABLE
 PHP Version:  4.2.2
 New Comment:

I get bool(true) with 4.2.3 and 4.3.0-dev (from yesterday), both
mod_php, Linux 2.4.19.

Maybe it's a documentation problem:

the manual only says about the return value of fgets():

  If an error occurs, returns FALSE.

Nothing is said about the return value on EOF (only "People used to the
'C' semantics of fgets()  should note the difference in how EOF is
returned."), so I guess fgets() is free to return whatever it likes on
EOF. Was this different in previous versions of PHP?


Previous Comments:


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

am I the only one who thinks that this should not output anything?

http://bugs.php.net/?id=19970&edit=1

#19948 [Com]: Broken Function mybe segfault releated

[michael . mauch]

 ID:   19948
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Linux 2.4.19
 PHP Version:  4.3.0-pre1
 New Comment:

Example to reproduce, copied from the manual:



The first result row is empty, subsequent ones are ok.


Previous Comments:


[2002-10-17 04:58:08] [EMAIL PROTECTED]

Here is the DIFF between working version and brocken version. Maybe
this could help to fix the buf

Index: oci8.c
===
RCS file: /repository/php4/ext/oci8/oci8.c,v
retrieving revision 1.177
diff -r1.177 oci8.c
1247c1247
<   if ((! statement->has_data) || (column->indicator == -1)) { /*
column is NULL or statment has no current data */
---
>   if (column->indicator == -1) { /* column is NULL */
1395d1394
< 
1397d1395
<   statement->has_data = 0;
1673,1680c1671
<   if ((outcol->data_type ==
SQLT_DAT) || (outcol->data_type == SQLT_NUM)
< #ifdef SQLT_TIMESTAMP
<   || (outcol->data_type
== SQLT_TIMESTAMP)
< #endif
< #ifdef SQLT_TIMESTAMP_TZ
<   || (outcol->data_type
== SQLT_TIMESTAMP_TZ)
< #endif
<  ) {
---
>   if ((outcol->data_type ==
SQLT_DAT) || (outcol->data_type == SQLT_NUM)) {
1781d1771
<   statement->has_data = 0;
1841,1842d1830
<   statement->has_data = 1;
< 
1849,1850d1836
<   statement->has_data = 0;
< 
3745,3754d3730
< #ifdef SQLT_TIMESTAMP
<   case SQLT_TIMESTAMP:
<   RETVAL_STRING("TIMESTAMP",1);
<   break;
< #endif
< #ifdef SQLT_TIMESTAMP_TZ
<   case SQLT_TIMESTAMP_TZ:
<   RETVAL_STRING("TIMESTAMP_TZ",1);
<   break;
< #endif
4254,4255c4230,4231
<   text errbuf[512];
<   sb4 errcode = 0;
---
> text errbuf[512];
> sb4 errcode = 0;
4258,4261d4233
< #ifdef HAVE_OCI8_ATTR_STATEMENT
<   ub2 errorofs = 0;
<   text *sqltext = NULL;
< #endif
4268,4286d4239
< 
< #ifdef HAVE_OCI8_ATTR_STATEMENT
<   CALL_OCI_RETURN(statement->error, OCIAttrGet(
<   (dvoid *)statement->pStmt,
<   OCI_HTYPE_STMT,
<   (text *) &sqltext,
<   (ub4 *)0,
<   OCI_ATTR_STATEMENT,
<   statement->pError));
< 
<   CALL_OCI_RETURN(statement->error, OCIAttrGet(
<   (dvoid *)statement->pStmt,
<   OCI_HTYPE_STMT,
<   (ub2 *)&errorofs,
<   (ub4 *)0,
<   OCI_ATTR_PARSE_ERROR_OFFSET,
<   statement->pError));
< #endif
< 
4321,4324d4273
< #ifdef HAVE_OCI8_ATTR_STATEMENT
<   add_assoc_long(return_value, "offset", errorofs);
<   add_assoc_string(return_value, "sqltext", sqltext ?
(char *) sqltext : "", 1);
< #endif
Index: php_oci8.h
===
RCS file: /repository/php4/ext/oci8/php_oci8.h,v
retrieving revision 1.24
diff -r1.24 php_oci8.h
122d121
<   int has_data;



[2002-10-17 03:45:03] [EMAIL PROTECTED]

The OCI Function "OCIDefineByName" in combination with "OCIFetch" do
not fill the defined Variable. If the variable
bevore was set it is cleared (unset) after the OCIFetch call.

Since it worked bevore an if i repleace the libphp4.so with 4.2.3 it
work again it is no script fault. And it is reproductable.

Configure for both version's 4.2.3 and 4.3.0-pre1 are the same. CVS
from last week also do not work.

 './configure' '--prefix=/opt/php4' '--exec-prefix=/opt/php4'
'--with-apxs2=/opt/httpd/bin/apxs' '--with-zlib' '--enable-bcmath'
'--with-bz2' '--enable-calendar' '--enable-ftp' '--with-gd'
'--with-imap' '--with-ldap=/opt/openldap' '--with-mysql=/opt/mysql'
'--enable-sockets' '--enable-yp' '--with-gettext' '--with-imap-ssl'
'--with-png-dir=/opt/libpng' '--with-jpeg-dir=/opt/jpeg'
'--with-freetype-dir=/opt/freetype' '--with-t1lib'
'--enable-gd-native-ttf' '--with-ttf' '--enable-tokenizer'
'--enable-sysvshm' '--enable-sysvsem'
'--with-oci8=/opt/oracle/product/8.1.7' '--enable-sigchild'




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

#19970 [Com]: feof()/fgets()/fgetcsv() problem

[michael . mauch]

 ID:   19970
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.7-STABLE
 PHP Version:  4.2.2
 New Comment:

Yes, cynic, you're right, it's a bug.

$fd = fopen(__FILE__, 'r');
while (!feof($fd)) 
{
  $s = fgets($fd);
  if($s === false)
echo "There was an error! And feof() is ",var_dump(feof($fd));
  // echo $s;
}
fclose($fd);

Prints:

There was an error! And feof() is bool(true)


Previous Comments:


[2002-10-18 04:55:18] [EMAIL PROTECTED]

michael: i meant bool(true) of course, sorry for the confusion.

wez: still no banana

roman@freepuppy ~/tmp 1027:0 > php -v
PHP 4.3.0-dev (cli), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
roman@freepuppy ~/tmp 1028:1 > cat feof1.php 
 php feof1.php
bool(true)
roman@freepuppy ~/tmp 1030:0 > 

fgets() gets to read past EOF, but it shouldn't. looks like feof() is
broken.

roman@freepuppy ~/tmp 1031:0 > fc -lf |grep "cvs -q up" 
 1016  10/18/2002 11:35  cvs -q up
roman@freepuppy ~/tmp 1032:0 > date
Fri Oct 18 11:48:31 CEST 2002

roman@freepuppy ~/tmp 1033:0 > cat ~/install/php4/config.nice.cli  
 
#! /bin/sh
#
# Created by configure

'./configure' \
'--enable-cli' \
'--enable-inline-optimization' \
'--enable-ftp' \
'--enable-shmop' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sockets' \
'--enable-tokenizer' \
'--disable-session' \
'--disable-shared' \
'--with-openssl' \
'--with-zlib' \
'--with-bz2' \
'--with-curl' \
'--with-gettext' \
'--with-iconv' \
'--with-mcrypt=/usr/local' \
'--with-mhash=/usr/local' \
'--with-ncurses' \
'--with-readline' \
'--with-pear' \
'--with-config-file-path=/usr/local/etc' \
'--with-mysql=/usr/local' \
"$@"

I ./configure --disable-all --enable-cli with the same result.





[2002-10-18 03:49:52] [EMAIL PROTECTED]

cynic - can you try HEAD or a snapshot from the last day or so?
I fixed an eof related issue recently.



[2002-10-18 03:45:31] [EMAIL PROTECTED]

I get bool(true) with 4.2.3 and 4.3.0-dev (from yesterday), both
mod_php, Linux 2.4.19.

Maybe it's a documentation problem:

the manual only says about the return value of fgets():

  If an error occurs, returns FALSE.

Nothing is said about the return value on EOF (only "People used to the
'C' semantics of fgets()  should note the difference in how EOF is
returned."), so I guess fgets() is free to return whatever it likes on
EOF. Was this different in previous versions of PHP?



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

am I the only one who thinks that this should not output anything?

http://bugs.php.net/?id=19970&edit=1

#20249 [Com]: Apache child segfaults when using OCILogon.

[michael . mauch]

 ID:   20249
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Open
 Bug Type: OCI8 related
 Operating System: Solaris 9
 PHP Version:  4.2.3
 New Comment:

Using Apache's  SetEnv doesn't work for PHP/Oracle. You have to set
these really in Apache's environment (e.g. in apachectl).

If that alone doesn't help: did you see the "big fat note" at
:

If your webserver doesn't start or crashes at startup:  Check that
Apache is linked with the pthread library: [...]


Previous Comments:


[2002-11-04 16:52:18] [EMAIL PROTECTED]

This is with Oracle 9i Release 2.



[2002-11-04 16:43:30] [EMAIL PROTECTED]

I get the following messages in my Apache 1.3.27 error log whenever I
try to use OCILogon:

[Mon Nov  4 15:32:46 2002] [notice] Apache/1.3.27 (Unix) PHP/4.2.3
configured -- resuming normal ope
rations
[Mon Nov  4 15:32:46 2002] [notice] Accept mutex: fcntl (Default:
fcntl)
[Mon Nov  4 15:33:00 2002] [notice] child pid 13088 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:00 2002] [notice] child pid 13086 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:00 2002] [notice] child pid 13085 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:00 2002] [notice] child pid 13084 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:00 2002] [notice] child pid 13083 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:00 2002] [notice] child pid 13082 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:01 2002] [notice] child pid 13090 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:01 2002] [notice] child pid 13089 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:02 2002] [notice] child pid 13092 exit signal
Segmentation Fault (11)
[Mon Nov  4 15:33:02 2002] [notice] child pid 13091 exit signal
Segmentation Fault (11)

Here is the script I tested with:

\n";
?>

Here are my configure lines:

For apache :

OPTIM="-g -m64" CFLAGS="-DDYNAMIC_MODULE_LIMIT=0" ./configure
--mandir=/usr/local/man --activate-module=src/modules/php4/libphp4.a
--enable-module=php4 --server-uid=www --server-gid=www

For PHP

CFLAGS="-g -m64" ./configure --with-apache=../apache_1.3.27 --with-xml
--with-oci8=/usr/local/oracle/OraHome --with-zlib
--enable-inline-optimization --enable-bcmath --enable-debug

They were both compiled with gcc-3.2.

Here are the environment variable settings from my httpd.conf:

SetEnv ORACLE_BASE /usr/local/oracle
SetEnv ORACLE_HOME /usr/local/oracle/OraHome
SetEnv ORACLE_SID TESTDB.WORLD
SetEnv TNS_ADMIN /usr/local/oracle/OraHome/network/admin/tnsnames.ora
SetEnv TWO_TASK /usr/local/oracle/OraHome/network/admin/tnsnames.ora
SetEnv NLS_LANG English_America.WE8ISO8859P1

And here is the backtrace:

bash-2.05# gdb /usr/local/apache/bin/httpd 
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.9"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x7d03b84c in strlen () from /usr/lib/64/libc.so.1
(gdb) bt
#0  0x7d03b84c in strlen () from /usr/lib/64/libc.so.1
#1  0x7d843e68 in snauca_check_adapter ()
   from /usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#2  0x7d841d58 in nau_viat () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#3  0x7d838454 in nau_gettab () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#4  0x7d8360a0 in nau_ini () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#5  0x7d827084 in nainit () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#6  0x7d7ce8b0 in nsnainit () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#7  0x7d7c0070 in nsopen () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#8  0x7d7a59e0 in nscall1 () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#9  0x7d7a4e28 in nscall () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#10 0x7d85e6dc in niotns () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#11 0x7d857fe8 in nigcall () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#12 0x7d7dfd54 in osncon () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#13 0x7d5b39dc in kpuadef () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#14 0x7d67b5fc in upiini () from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0
#15 0x7d666554 in upiah0 () from
/usr/local/oracle/OraHome/lib/