#24416 [Com]: Apache2 won't start with PHP5 beta

[luke at vanblerks dot co dot za]

 ID:   24416
 Comment by:   luke at vanblerks dot co dot za
 Reported By:  ldf13 at hotmail dot com
 Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP
 PHP Version:  5CVS-2003-06-30 (dev)
 New Comment:

Was trying to install php5 beta 2 and apache wouldn't start. I realized
I hadn't removed my php 4 php.ini from the windows folder. Once I did
that it worked.

Cheers
Luke


Previous Comments:


[2003-08-14 06:59:03] etianova at hotmail dot com

I searched on google for this problem and i found your comments which
helped me so much. Thanks a lot now i have apache 2 and php 5 running
perfectly. Thanks u !!!



[2003-08-07 22:04:18] citking at hotmail dot com

You guys rock!I was fighting this for an hour before I decided to "pull
over and ask for directions"!

Thanks all.



[2003-07-27 16:23:11] levi at levifig dot net

I'm using Windows XP, Apache 2.0.47 and PHP 5.0.0b1 and i'm running
everything without a problem!

I changed the line to php5_module and i have all my 3 files
(php4ts.dll, php4apache2.dll and php.ini) in my Apache's /bin
directory. I load the module with a "php5_module bin/php4apache2.dll".

My Apache installation is under C:\Program Files\Apache Group\Apache2
and my PHP install is at (it doesn't matter as the needed files are
under the Apache's installation directory) c:\php

As a note, i do have all my dlls from php\dlls copied to
c:\windows\system32... i don't believe it makes any difference to this
subject, but i say it just in case! ;)

Good Luck to y'all! :> And gr33ts from Portugal! :X



[2003-07-02 12:54:49] nuno at dbforums dot com

Sure Aaron, copy the files:

php4ts.dll
iconv.dll

to c:/php/sapi/

Then simply add this to your httpd.conf file:

LoadModule php5_module c:/php/sapi/php4apache2.dll
AddType application/x-httpd-php .php

Once that's all done, restart Apache. :)
NET STOP APACHE2
NET START APACHE2



[2003-07-01 22:06:05] nuno at dbforums dot com

Thankfully to strace (an amazing little tool BTW) and install.txt
(duh), I finally managed to install PHP5 with Apache2.0.46.

Therefore, I need to eat my words and I would like to take this
opportunity to present my sincere apologies to the PHP Team.
To sniper, a special thank you for his support.

Best wishes,

nuno :)



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

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

#25975 [Bgs->Opn]: PHP 5 object references don't survive serialization

[reiersol at online dot no]

 ID:   25975
 User updated by:  reiersol at online dot no
 Reported By:  reiersol at online dot no
-Status:   Bogus
+Status:   Open
 Bug Type: Session related
 Operating System: Linux RedHat 9.0
 PHP Version:  5CVS-2003-10-24 (dev)
 New Comment:

I guess I'll have to expand my example:

class Bar { var $value = 0; }
class Foo {
var $v1;
var $v2;
function Foo() {
$this->v1 = new Bar;
$this->v2 = $this->v1;
}
}

$f = new Foo;
$f->v2->value = 42;
var_dump($f);
$g = unserialize(serialize($f));
$g->v2->value = 'and now for something completely different';
var_dump($g);

Here's the output:

object(foo)#1 (2) {
  ["v1"]=>
  object(bar)#2 (1) {
["value"]=>
int(42)
  }
  ["v2"]=>
  object(bar)#2 (1) {
["value"]=>
int(42)
  }
}
object(foo)#3 (2) {
  ["v1"]=>
  object(bar)#4 (1) {
["value"]=>
int(42)
  }
  ["v2"]=>
  object(bar)#5 (1) {
["value"]=>
string(42) "and now for something completely different"
  }
}

That should at least make it clear that there's a difference in
behavior before and after serialization. And the behavior before
serialization is the behavior of a normal object-oriented language. (I
ported the example to Java just to make sure I wasn't crazy.)

I'm not trying to split hairs. I tried creating the kind of
sophiticated object-oriented structure that PHP 5 makes so much easier.
It worked wonderfully. But then I discovered that the structure didn't
persist across sessions. So I made this simplified example to
demonstrate the problem.


Previous Comments:


[2003-10-30 20:59:30] [EMAIL PROTECTED]

There are no references in the before serialize object, so why should
there be references after serializing/unserializing?




[2003-10-24 08:11:44] reiersol at online dot no

The last line of the code example (print $1) is meaningless. Sorry.



[2003-10-24 08:08:59] reiersol at online dot no

Description:

Object references inside PHP5 objects are not preserved through
serialize/unserialize like traditional PHP4 references. This means they
cannot be used in session-based applications.

Reproduce code:
---
class Bar {}
class Foo {
var $v1;
var $v2;
function Foo() {
$this->v1 = new Bar;
$this->v2 = $this->v1;
}
}

$f = new Foo;
var_dump($f);
$g = unserialize(serialize($f));
var_dump($g);
print $s1;


Expected result:

This is what I get if I use $this->v2 = &this->$v1 instead of $this->v2
= $this->v1:

object(foo)#1 (2) {
  ["v1"]=>
  &object(bar)#2 (0) {
  }
  ["v2"]=>
  &object(bar)#2 (0) {
  }
}
object(foo)#3 (2) {
  ["v1"]=>
  &object(bar)#4 (0) {
  }
  ["v2"]=>
  &object(bar)#4 (0) {
  }
}

Actual result:
--
object(foo)#1 (2) {
  ["v1"]=>
  object(bar)#2 (0) {
  }
  ["v2"]=>
  object(bar)#2 (0) {
  }
}
object(foo)#3 (2) {
  ["v1"]=>
  object(bar)#4 (0) {
  }
  ["v2"]=>
  object(bar)#5 (0) {
  }
}






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

#26035 [Fbk->Opn]: Opening existing CDB does not work

[a dot stagl at gmx dot at]

 ID:   26035
 User updated by:  a dot stagl at gmx dot at
 Reported By:  a dot stagl at gmx dot at
-Status:   Feedback
+Status:   Open
 Bug Type: DBM/DBA related
 Operating System: Win2k
 PHP Version:  4.3.3
 New Comment:

Unfortunatly, I cannot provide you the DB which I'm refering to,
because - as already mentioned - it is the contacts-database from a
nokia 9210i which contains sensitive data. I tried to get a sample
contacts.cdb directly from nokia, but they haven't been supportive :-(

But I found the following two cdb-databases on the internet:

http://web.mit.edu/cascon/updates/cascon.cdb (does not work with the
provided code)

http://cvs.sourceforge.net/viewcvs.py/*checkout*/cdbfile/cdbFile/cdbFile/Attic/test.cdb?rev=1.1.1.1
(works fine with my code)

HTH


Previous Comments:


[2003-10-30 20:36:06] [EMAIL PROTECTED]

Please provide the information HERE, not via private mail!




[2003-10-30 10:12:05] a dot stagl at gmx dot at

I sent it to yob by PM.



[2003-10-30 08:21:03] [EMAIL PROTECTED]

Could you please provide the database in question.



[2003-10-30 05:30:43] a dot stagl at gmx dot at

Description:

I'm trying to open the contacts-databse from a nokia 9210i mobile, but
it doesn't work.


Reproduce code:
---
$db_conn = dba_open("contacts.cdb","r","cdb");
if (!$db_conn) die ("opening failed");
$key = dba_firstkey ($db_conn);
while ($key != false)
{
  echo $key."";
  echo dba_fetch ($key, $db_conn)."";
  $key = dba_nextkey ($db_conn);
}
dba_close($db_conn);

Expected result:

...to get a list of key-value pairs.

Actual result:
--
The code didn't produce the expected output nor any error message. It
seems that the commands dba_firstkey and dba_nextkey always return
false instead of a key.






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

#21926 [Com]: Apache process hangs

[huberfelix at web dot de]

 ID:   21926
 Comment by:   huberfelix at web dot de
 Reported By:  arinto at almedina dot net
 Status:   No Feedback
 Bug Type: Java related
 Operating System: Red Hat Linux 7.1
 PHP Version:  4CVS-2003-01-28 (stable)
 New Comment:

Sorry I opened a other ticket for nearly the same problem
http://bugs.php.net/bug.php?id=25663



Description:

I use the Java feature to call a Lucene Proxy,
after a few hundert calls I get segmentation faults.

My php.ini:

java.class.path=/usr/share/php_java.jar:/usr/lib/j2sdk1.4.2_01/lib/tools
.jar:/usr/lib/j2sdk1.4.2_01/lib/dt.jar:/u
sr/lib/j2sdk1.4.2_01/jre/lib/rt.jar:/opt/jakarta/lucene/lucene.jar:/opt/
mysql-connector-java/mysql-connector-java
-3.0.8-stable-bin.jar:/opt/wddx/Java/wddx.jar
java.home = /usr/lib/j2sdk1.4.2_01 
java.library = /usr/lib/j2sdk1.4.2_01/jre/lib/i386/libjava.so 
java.library.path = /usr/share/extensions/no-debug-non-zts-20020429

Reproduce code:
---
$query = trim(urldecode($_REQUEST["keywords"]));

$index = "/srv/www/lucene/index";

$obj = new Java("org.ew.lucene.SearchEngine")
or die("ARGHHHS");

$result = $obj->search($index,"AND",$query)
or die("ARGHHHS");

$rs = wddx_deserialize($result);
$meta = $rs["meta_data"];
$rows = $rs["rows"];

if (!stristr($rs,"No matches found for") && strlen(trim($rs)) >= 1)
{


Expected result:

A array with the Lucene results (works)

I get 50 segmentation faults on 10.000 searches

Actual result:
--
#0  0x45ceb300 in ?? ()
#1  0x45c8e0f1 in ?? ()
#2  0x45c8ddeb in ?? ()
#3  0x45c8ddeb in ?? ()
#4  0x45c8e0f1 in ?? ()
#5  0x45c8ddeb in ?? ()
#6  0x45c8ddeb in ?? ()
#7  0x45c8e0f1 in ?? ()
#8  0x45c8ddeb in ?? ()
#9  0x45c8ddeb in ?? ()
#10 0x45c8dd14 in ?? ()
#11 0x45c8dd14 in ?? ()
#12 0x45c8e01a in ?? ()
#13 0x45c8dd14 in ?? ()
#14 0x45c8b104 in ?? ()
#15 0x438b73f4 in JavaCalls::call_helper ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#16 0x4399c05d in os::os_exception_wrapper ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#17 0x438b7646 in JavaCalls::call ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#18 0x438bfe47 in jni_invoke_nonstatic ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#19 0x438c55ae in jni_CallVoidMethod ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#20 0x406a0160 in php4_module ()
   from /usr/share/extensions/no-debug-non-zts-20020429/java.so
#21 0x405e1a15 in setenvif_module () from /usr/lib/apache/libphp4.so
---Type  to continue, or q  to quit---

#12 0x45c8e01a in ?? ()
#13 0x45c8dd14 in ?? ()
#14 0x45c8b104 in ?? ()
#15 0x438b73f4 in JavaCalls::call_helper ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#16 0x4399c05d in os::os_exception_wrapper ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#17 0x438b7646 in JavaCalls::call ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#18 0x438bfe47 in jni_invoke_nonstatic ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#19 0x438c55ae in jni_CallVoidMethod ()
   from /usr/lib/j2sdk1.4.2_01/jre/lib/i386/server/libjvm.so
#20 0x406a0160 in php4_module ()
   from /usr/share/extensions/no-debug-non-zts-20020429/java.so
#21 0x405e1a15 in setenvif_module () from /usr/lib/apache/libphp4.so
---Type  to continue, or q  to quit---
#22 0x405e4bec in setenvif_module () from /usr/lib/apache/libphp4.so
#23 0x405d30cb in setenvif_module () from /usr/lib/apache/libphp4.so
#24 0x4059c052 in setenvif_module () from /usr/lib/apache/libphp4.so
#25 0x405e9870 in setenvif_module () from /usr/lib/apache/libphp4.so
#26 0x405ea826 in setenvif_module () from /usr/lib/apache/libphp4.so
#27 0x405ea8ac in setenvif_module () from /usr/lib/apache/libphp4.so
#28 0x08054f7a in ap_invoke_handler ()
#29 0x080692f4 in ap_some_auth_required ()
#30 0x0806957e in ap_process_request ()
#31 0x08061208 in ap_child_terminate ()
#32 0x080614b5 in ap_child_terminate ()
#33 0x0806154d in ap_child_terminate ()
#34 0x080620db in ap_child_terminate ()
#35 0x0806246e in main ()
#36 0x4015d4c2 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)


Previous Comments:


[2003-08-18 19:45:05] [EMAIL PROTECTED]

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





[2003-08-13 12:15:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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



---

#26047 [Opn->WFx]: Access to supervariables via $$variable does not function as documented.

[andi]

 ID:   26047
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dw-bugs dot php dot net at botanicus dot net
-Status:   Open
+Status:   Wont fix
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Hi,

This is by-design and it's the price you have to pay for these special
superglobals. A price which is worth paying...
If this is not documented in the online docs then feel free to drop a
line to [EMAIL PROTECTED] with the wording you think should be added


Previous Comments:


[2003-10-30 23:38:43] dw-bugs dot php dot net at botanicus dot net

Description:

>From the implementation I suppose this is pretty obvious, but the
following does not work:

   $data_source = '_POST';
   $data =& $$data_source;

'$data' does not point at $_POST as expected. I'd consider this a
problem - your implementation is showing through. Either re-label
$_POST, etc. as not actually being superglobals, or fix the underlying
implementation (which does not at present match up with your
documentation).

"""This is a 'superglobal', or automatic global, variable. This simply
means that it is available in all scopes throughout a script."""

This statement is not true, since the variable is only 'automatic
global' when referred to by name directly (and thus gets caught by your
special case code). It does not actually exist in every scope.

I beg you not to mark this as a documentation problem and change the
docs to mention this. Fix it! It's a horrible inconsistancy. This,
along with a million other sour points, is the reason why I absolutely
detest my day job at the minute. Come on guys! Do it for me!

Reproduce code:
---
$data_source = '_POST';
$data =& $$data_source;

echo gettype($data);

Expected result:

array

Actual result:
--
NULL





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

#26027 [Bgs]: settype($array, 'string') always raises a notice

[[EMAIL PROTECTED]]

 ID:  26027
 User updated by: [EMAIL PROTECTED]
 Reported By: [EMAIL PROTECTED]
 Status:  Bogus
 Bug Type:Arrays related
 PHP Version: 4.3.3
 New Comment:

But what for is the Notice if I call setType explicitely?

I understand `echo $array;` raising a Notice, but setType()?

Ciao,
Michael


Previous Comments:


[2003-10-29 19:52:58] [EMAIL PROTECTED]

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





[2003-10-29 09:02:05] [EMAIL PROTECTED]

Description:

setType($array, 'string') always raises a notice

Reproduce code:
---
$ php -r '$r=array(); settype($r,'string'); var_dump($r);'


Expected result:

string(5) "Array"


Actual result:
--
PHP Notice:  Array to string conversion in Command line code on line 1
string(5) "Array"






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

#26049 [NEW]: Cannot connect to ODBC source (MyODBC)

[miroslav dot sulc at startnet dot cz]

From: miroslav dot sulc at startnet dot cz
Operating system: Linux (Gentoo)
PHP version:  4.3.3
PHP Bug Type: ODBC related
Bug description:  Cannot connect to ODBC source (MyODBC)

Description:

I cannot connect with:
$var=odbc_connect('myodbc-test','root','password');
to my MyODBC data source.

Here is the error:
Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Can't open
lib '/usr/lib/libmyodbc3.so' : unknown error, SQL state IM003 in
SQLConnect in /home/httpd/bagr/docs/test.php on line 2

I would appreciate any help. Below is some more info.

isql command work fine:
echo "show tables;
> " | isql myodbc-test root password
+---+
| Connected!|
|   |
| sql-command   |
| help [tablename]  |
| quit  |
|   |
+---+
SQL> +-+
| Tables_in_test  |
+-+
+-+
0 rows affected


Here is PHP configuration:
'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--without-readline' '--with-apxs2=/usr/sbin/apxs2' '--with-ndbm=/usr'
'--with-db4=/usr' '--with-mcrypt=/usr' '--with-mhash=/usr'
'--with-ming=/usr' '--with-swf=/usr' '--with-sybase=/usr'
'--with-gdbm=/usr' '--with-java=/opt/blackdown-jdk-1.4.1'
'--with-mcal=/usr' '--with-unixODBC=/usr' '--with-pgsql=/usr'
'--with-snmp=/usr' '--enable-ucd-snmp-hack' '--with-pdflib=/usr'
'--with-gd' '--enable-gd-native-ttf' '--with-png' '--with-png-dir=/usr'
'--with-jpeg' '--with-jpeg-dir=/usr' '--enable-exif' '--with-tiff'
'--with-tiff-dir=/usr' '--with-mysql=/usr'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-freetype-dir=/usr'
'--with-ttf=/usr' '--with-t1lib=/usr' '--with-gettext' '--without-qtdom'
'--with-pspell=/usr' '--with-openssl=/usr' '--with-imap=/usr'
'--with-ldap=/usr' '--with-dom=/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-kerberos=/usr' '--with-pam'
'--disable-memory-limit' '--disable-ipv6' '--with-curlwrappers'
'--with-curl=/usr' '--enable-dbx' '--with-imap-ssl' '--with-zlib'
'--with-zlib-dir=/usr' '--with-sablot=/usr' '--enable-xslt'
'--with-xslt-sablot' '--with-xmlrpc' '--enable-wddx' '--with-xml'
'--enable-mbstring=all' '--enable-mbregex' '--with-bz2=/usr'
'--with-crack=/usr' '--with-cdb' '--enable-bcmath' '--enable-calendar'
'--enable-dbase' '--enable-filepro' '--enable-ftp' '--with-mime-magic'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvipc' '--with-iconv' '--enable-shmop' '--enable-dio'
'--enable-inline-optimization' '--enable-track-vars' '--enable-trans-sid'
'--enable-versioning' '--with-config-file-path=/etc/php/apache2-php4'

Here are versions:
unixODBC: 2.0.6
MyODBC: 3.51.06

/etc/unixODBC/odbc.ini:
[myodbc-test]
Description = MySQL ODBC myodbc-3.51.06 Driver Testing DSN
Driver  = /usr/lib/libmyodbc3.so
Socket  = /var/run/mysqld/mysqld.sock
Server  = localhost
User= root
Database= test
Option  = 3

/etc/unixODBC/odbcinst.ini:
[myodbc]
Description = MySQL ODBC Driver
Driver  = /usr/lib/libmyodbc3.so
FileUsage   = 1

File permissions:
ls -l /usr/lib/libmyodbc3*
-rwxr-xr-x1 root root   157984 Oct 30 10:28
/usr/lib/libmyodbc3-3.51.06.so
-rw-r--r--1 root root   175340 Oct 30 10:28
/usr/lib/libmyodbc3.a
-rwxr-xr-x1 root root  861 Oct 30 10:28
/usr/lib/libmyodbc3.la
lrwxrwxrwx1 root root   21 Oct 30 10:28
/usr/lib/libmyodbc3.so -> libmyodbc3-3.51.06.so

Apache runs as user apache and group apache.

php.ini diff against unpacked php.ini-dist from src distribution.
diff /etc/php/apache2-php4/php.ini php-4.3.3/php.ini-dist
428c428
< extension_dir = /usr/lib/php/extensions/no-debug-non-zts-20020429
---
> extension_dir = "./"
490,492c490
< ; allow_url_fopen = On
< ; Closed for security - <[EMAIL PROTECTED]>
< allow_url_fopen = Off
---
> allow_url_fopen = On
530c528
< ; extension_dir = /usr/lib/php/extensions/no-debug-non-zts-20020429
---
> ; extension_dir directive above.
556c554
< extension = java.so
---
> ;extension=php_java.dll
603c601
< java.class.path =
/usr/lib/php/extensions/no-debug-non-zts-20020429/php_java.jar
---
> ;java.class.path = .\php_java.jar
605,606c603,604
< java.library = /opt/blackdown-jdk-1.4.1/jre/lib/i386/libjava.so
< java.library.path = /usr/lib/php/extensions/no-debug-non-zts-20020429
---
> ;java.library = c:\jdk\jre\bin\hotspot\jvm.dll
> ;java.library.path = .\

I hope it's enough.

Repro

#26047 [WFx]: Access to supervariables via $$variable does not function as documented.

[dw-bugs dot php dot net at botanicus dot net]

 ID:   26047
 User updated by:  dw-bugs dot php dot net at botanicus dot net
 Reported By:  dw-bugs dot php dot net at botanicus dot net
 Status:   Wont fix
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Will this be fixed in Zend2?


Previous Comments:


[2003-10-31 04:44:04] [EMAIL PROTECTED]

Hi,

This is by-design and it's the price you have to pay for these special
superglobals. A price which is worth paying...
If this is not documented in the online docs then feel free to drop a
line to [EMAIL PROTECTED] with the wording you think should be added



[2003-10-30 23:38:43] dw-bugs dot php dot net at botanicus dot net

Description:

>From the implementation I suppose this is pretty obvious, but the
following does not work:

   $data_source = '_POST';
   $data =& $$data_source;

'$data' does not point at $_POST as expected. I'd consider this a
problem - your implementation is showing through. Either re-label
$_POST, etc. as not actually being superglobals, or fix the underlying
implementation (which does not at present match up with your
documentation).

"""This is a 'superglobal', or automatic global, variable. This simply
means that it is available in all scopes throughout a script."""

This statement is not true, since the variable is only 'automatic
global' when referred to by name directly (and thus gets caught by your
special case code). It does not actually exist in every scope.

I beg you not to mark this as a documentation problem and change the
docs to mention this. Fix it! It's a horrible inconsistancy. This,
along with a million other sour points, is the reason why I absolutely
detest my day job at the minute. Come on guys! Do it for me!

Reproduce code:
---
$data_source = '_POST';
$data =& $$data_source;

echo gettype($data);

Expected result:

array

Actual result:
--
NULL





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

#26050 [NEW]: Unable to use CONST vars in other CONST vars

[kris dot hofmans at pandora dot be]

From: kris dot hofmans at pandora dot be
Operating system: Linux 2.4.21
PHP version:  5CVS-2003-10-31 (dev)
PHP Bug Type: Scripting Engine problem
Bug description:  Unable to use CONST vars in other CONST vars

Description:

I have had code that has been running with php5-dev versions since July,
wich now won't parse anymore.

I had declared a CONST in a class wich I used in another CONST below it,
this now gives a: 
Parse error: parse error, expecting `','' or `';'' in
/home/blacky/public_html/php5-dev/zen/ext/types.class.php on line 127

I am using PHP 5 Beta 2 (currently not in the list)

Reproduce code:
---
const NUMERIC   = '0-9';
const SPACE = '\s';
const PUNCTUATION   = SPACE . '\.,;\:&"\'\?\!\(\)';
const ALPHA_LCASE   = 'a-z';
const E_ALPHA_LCASE = ALPHA_LCASE . 'áéíóúàèìòùäëïöüâêîôûñç';
const ALPHA_UCASE   = 'A-Z';
const E_ALPHA_UCASE = ALPHA_UCASE . 'ÁÉÍÓÚÀÈÌÒÙÄËÏÖÜÂÊÎÔÛÑÇ';
const ALPHA = ALPHA_LCASE . ALPHA_UCASE;
const E_ALPHA   = E_ALPHA_LCASE . E_ALPHA_UCASE;
const ALPHA_NUM = ALPHA . NUMERIC;

Expected result:

I expect the behaviour to be something like.

const FOO = 'foo';
const BAR = 'bar';
const FOOBAR = FOO . BAR;

and that an echo FOOBAR would give me the string 'foobar'

Actual result:
--
Parse error: parse error, expecting `','' or `';'' in
/home/blacky/public_html/php5-dev/zen/ext/types.class.php on line 127

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

#11059 [Com]: PHP does not register GET variables $HTTP_GET_VARS is empty. POST works OK.

[kiryaka at mail dot ru]

 ID:   11059
 Comment by:   kiryaka at mail dot ru
 Reported By:  bub at seznam dot cz
 Status:   Closed
 Bug Type: Variables related
 Operating System: RedHat 5.1
 PHP Version:  4.0.5
 New Comment:

just turn on the register_globals directive in php.ini and restart
apache.


Previous Comments:


[2003-06-05 11:17:27] php at netcrusher dot org

Hello,

I have the same problem. Im running SuSE Linux 8.1 with Apache 1.3.26
and PHP4. I just installed ist from the source-cds. Everything looks
fine, but PHP doesnt get the Variables from links.

I'll try to download the newer versions of Apache an PHP.

Thanks for help!



[2001-05-28 07:41:09] bub at seznam dot cz

I've recompiled php and apache and it works. 

Thanks anyway



[2001-05-24 13:22:12] bub at seznam dot cz

It doesn't work either and $PHP_SELF is empty as well. I did not know
that, because I didn't use it my scripts. 



[2001-05-24 13:14:30] bub at seznam dot cz

It doesn't work either and $PHP_SELF is empty as well. I did not know
that, because I didn't use it my scripts. 



[2001-05-24 12:48:57] [EMAIL PROTECTED]

The system speed wouldn't impact behavior, no.

Your script refers to $data['n_id'] though, not $data['id'].  Let's
remove any confusion and work with a very basic script:

Click here
Getvariable is: 

Try that one out.




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

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

#26038 [Fbk->Opn]: session_start(): Failed to initialize storage module

[pedro at dehumanizer dot com]

 ID:   26038
 User updated by:  pedro at dehumanizer dot com
 Reported By:  pedro at dehumanizer dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.9
 PHP Version:  4CVS-2003-10-30 (stable)
 New Comment:

I can basically rip, with a few alterations, the "expected/actual"
results from bug 25876:

Expected result:

not to see this message in logs, see the page expected

Actual result:
--

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in
/var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

and we get just a blank page instead of seeing of what actually
expected. Refreshing, or going back then clicking again, usually
works.

I can copy my php.ini and the results of "make test" and phpinfo() and
post them here, but it may be too big. Is it OK?


Previous Comments:


[2003-10-30 21:08:26] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




[2003-10-30 07:34:12] pedro at dehumanizer dot com

By the way, if I use Apache 1.3.28 instead, configuring the same
version of PHP with exactly the same options (except replacing
--with-apxs2 with --with-apxs), the problem disappears.



[2003-10-30 07:30:51] pedro at dehumanizer dot com

Description:

I believe this bug had already been reported by someone else (#25876),
but it was marked as "bogus".

I'm using FreeBSD 4.9 (and 4.8-STABLE before), Apache 2.0.48 from ports
(and 2.0.47 before), and tried several PHP versions from 4.3.2 to
4CVS-20031030 (today's). All of them exhibit this problem, with
SquirrelMail 1.4.2. 

I don't think it's a SquirrelMail problem, however, as the line in
question is a simple

session_start();

The problem is intermitent - when navigating through the webmail, from
time to time, when I click on a link, a blank page appears *very
quickly*, just in the frame which was supposed to be changed. In the
logs, I get this error:

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in /var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

If I reload the page, or go back from the blank page and click on the
same link again, it usually works then. The error rate is hard to
calculate, but it should be less than 1 in 10 times.

I've tried changing the sessions handler between files and mm, but it
doesn't solve the problem. Neither does activating register_globals,
which SquirrelMail doesn't need, anyway.

PHP configure options:

./configure  --disable-cgi --with-apxs2=/usr/local/sbin/apxs
--with-openssl --with-zlib --with-gdbm --with-imap --with-iconv
--enable-ftp --with-mysql=/usr/local/mysql --with-curl --disable-debug
--enable-exif --enable-sockets --disable-ipv6 --with-gd --with-jpeg-dir
--with-png-dir --enable-dio --with-gettext=/usr/local --with-bz2
--enable-mbstring --enable-mbregex --enable-zend-multibyte
--with-mysql-sock=/tmp/mysql.sock --with-mm=/usr/local







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

#26033 [Bgs->Opn]: imageftbbox gives anomalous values when first called

[robertks at hotmail dot com]

 ID:   26033
 User updated by:  robertks at hotmail dot com
 Reported By:  robertks at hotmail dot com
-Status:   Bogus
+Status:   Open
 Bug Type: GD related
 Operating System: OpenBSD 3.1
-PHP Version:  4.3.1
+PHP Version:  4.3.3
 New Comment:

I updated to PHP 4.3.3.

Now I get

Array ( [0] => -1 [1] => 1393 [2] => 598 [3] => 1393 [4] => 598 [5] =>
-16 [6] => -1 [7] => -16 ) 
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 ) 

the first time I run the test code.  Note this is still an anomalous
result (the two outputted arrays should be identical) but different
than the result I was posted before.  Refresh, and I get the same. 
Refresh again, and I get the same.  Refresh a third time, and I get

Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 ) 
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

which was the anomalous result I posted before.  Refresh thrice more
and it goes back to the first result, and stays at that result ever
after with further refreshes.

All the best,
Robert K S


Previous Comments:


[2003-10-30 20:53:05] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

And use the bundled GD. (--with-gd)




[2003-10-29 20:15:24] robertks at hotmail dot com

Description:

Can anyone explain the bizarre behavior of this code?

ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
echo '';
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
?>

Output:
Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

Particulars:
Freetype 2.0.4
GD 2.0.9
PHP 4.3.1

What's going on?  The [5] and [7] values of the output array (Y
positions of the upper corners of the bounding box) are anomalous the
first time the imageftbbox function is called.  When the function is
called again in an identical manner, the values are good.

imagettfbbox does not exhibit this behavior on my system.

If this is a known bug, cursory searches haven't brought up anything
about it.

Help!

All the best,
Robert K S

Reproduce code:
---
ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
echo '';
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
?>

Expected result:

Output:
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

Actual result:
--
Output:
Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )





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

#26033 [Opn]: imageftbbox gives anomalous values when first called

[robertks at hotmail dot com]

 ID:   26033
 User updated by:  robertks at hotmail dot com
 Reported By:  robertks at hotmail dot com
 Status:   Open
 Bug Type: GD related
 Operating System: OpenBSD 3.1
 PHP Version:  4.3.3
 New Comment:

Note in the above that I updated to an October 31st, 2003 snapshot of
PHP in the 4.3.x-dev category from http://snaps.php.net/, and not the
August 25th, 2003 distribution available from
http://www.php.net/downloads.php.


Previous Comments:


[2003-10-31 06:00:07] robertks at hotmail dot com

I updated to PHP 4.3.3.

Now I get

Array ( [0] => -1 [1] => 1393 [2] => 598 [3] => 1393 [4] => 598 [5] =>
-16 [6] => -1 [7] => -16 ) 
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 ) 

the first time I run the test code.  Note this is still an anomalous
result (the two outputted arrays should be identical) but different
than the result I was posted before.  Refresh, and I get the same. 
Refresh again, and I get the same.  Refresh a third time, and I get

Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 ) 
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

which was the anomalous result I posted before.  Refresh thrice more
and it goes back to the first result, and stays at that result ever
after with further refreshes.

All the best,
Robert K S



[2003-10-30 20:53:05] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

And use the bundled GD. (--with-gd)




[2003-10-29 20:15:24] robertks at hotmail dot com

Description:

Can anyone explain the bizarre behavior of this code?

ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
echo '';
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
?>

Output:
Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

Particulars:
Freetype 2.0.4
GD 2.0.9
PHP 4.3.1

What's going on?  The [5] and [7] values of the output array (Y
positions of the upper corners of the bounding box) are anomalous the
first time the imageftbbox function is called.  When the function is
called again in an identical manner, the values are good.

imagettfbbox does not exhibit this behavior on my system.

If this is a known bug, cursory searches haven't brought up anything
about it.

Help!

All the best,
Robert K S

Reproduce code:
---
ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
echo '';
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
?>

Expected result:

Output:
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

Actual result:
--
Output:
Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )





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

#26051 [NEW]: filetype() returns wrong type for device drivers

[six at t0x dot net]

From: six at t0x dot net
Operating system: win2k
PHP version:  4.3.4RC3
PHP Bug Type: Filesystem function related
Bug description:  filetype() returns wrong type for device drivers

Description:

As the subject states, filetype() on windows (w2k at least) returns wrong
type for device drivers. Actually, it seems to always return the type
"file".



Reproduce code:
---


Expected result:

type : char

Actual result:
--
type : file

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

#26052 [NEW]: setlocale() does not work under FreeBSD

[nicos at worldakt dot com]

From: nicos at worldakt dot com
Operating system: FreeBSD
PHP version:  4.3.3
PHP Bug Type: *Languages/Translation
Bug description:  setlocale() does not work under FreeBSD

Description:

setlocale() fails under FreeBSD 4.8:

[Fri Oct 31 - 17:56:28 - root /httpd/php-4.3.3]# cat configure.log | grep
locale
checking for locale.h... (cached) yes
checking for setlocale... (cached) yes
checking for localeconv... (cached) yes
[Fri Oct 31 - 17:56:45 - root /httpd/php-4.3.3]# 

In fact, setlocale returns FALSE but no E_WARNING or anything.

After looking in ext/standard/string.c it looks like it can happen when
HAVE_SETLOCALE is not defined...

But HAVE_SETLOCALE is defined.

Another solution is that, setlocale() call fails:

retval = setlocale (cat, loc);

We've got an if (retval) { } but no else... 
According to freebsd's man, setlocale returns NULL on failure. 

I added:
else {
 /* setlocale failed */
 efree(args);
 php_error_docref(NULL TSRMLS_CC, E_WARNING, "setlocale failed!");
 RETURN_FALSE;
}

And I get the E_WARNING, so it means setlocale() call failed, but why ?
the same scripts works fine under linux but not under freebsd4.8. 

After looking in /usr/share/locale, we have:

/usr/share/locale/fr_FR.ISO8859-1:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY LC_NUMERIC
 LC_TIME

/usr/share/locale/fr_FR.ISO8859-15:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY LC_NUMERIC
 LC_TIME

/usr/share/locale/fr_FR.ISO_8859-1:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY LC_NUMERIC
 LC_TIME

/usr/share/locale/fr_FR.ISO_8859-15:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY LC_NUMERIC
 LC_TIME

so it should work.

If I have change fr_FR to fr_FR.ISO_8859-1 in the setlocale call, the
script works fine, isn't setlocale() supposed to use default charset which
is ISO_8859-1 ? In any case the documentation does not mention that we
have to add the charset under FreeBSD...

Reproduce code:
---
setlocale(LC_TIME, "fr_FR");
echo strftime("%B %Y",$timestamp);


Expected result:

TRUE
Octobre 2003

Actual result:
--
FALSE
October 2003

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

#26052 [Opn->Ver]: setlocale() does not work under FreeBSD

[nicos]

 ID:   26052
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nicos at worldakt dot com
-Status:   Open
+Status:   Verified
 Bug Type: *Languages/Translation
 Operating System: FreeBSD
 PHP Version:  4.3.3
 New Comment:

To resume this, FreeBSD needs fr_FR.charset and not only fr_FR,
shouldn't we automaticly add the charset if it is not already present
at least under BSD systems so we can have portable codes? :-)


Previous Comments:


[2003-10-31 06:16:49] nicos at worldakt dot com

Description:

setlocale() fails under FreeBSD 4.8:

[Fri Oct 31 - 17:56:28 - root /httpd/php-4.3.3]# cat configure.log |
grep locale
checking for locale.h... (cached) yes
checking for setlocale... (cached) yes
checking for localeconv... (cached) yes
[Fri Oct 31 - 17:56:45 - root /httpd/php-4.3.3]# 

In fact, setlocale returns FALSE but no E_WARNING or anything.

After looking in ext/standard/string.c it looks like it can happen when
HAVE_SETLOCALE is not defined...

But HAVE_SETLOCALE is defined.

Another solution is that, setlocale() call fails:

retval = setlocale (cat, loc);

We've got an if (retval) { } but no else... 
According to freebsd's man, setlocale returns NULL on failure. 

I added:
else {
 /* setlocale failed */
 efree(args);
 php_error_docref(NULL TSRMLS_CC, E_WARNING, "setlocale failed!");
 RETURN_FALSE;
}

And I get the E_WARNING, so it means setlocale() call failed, but why ?
the same scripts works fine under linux but not under freebsd4.8. 

After looking in /usr/share/locale, we have:

/usr/share/locale/fr_FR.ISO8859-1:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY
LC_NUMERIC  LC_TIME

/usr/share/locale/fr_FR.ISO8859-15:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY
LC_NUMERIC  LC_TIME

/usr/share/locale/fr_FR.ISO_8859-1:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY
LC_NUMERIC  LC_TIME

/usr/share/locale/fr_FR.ISO_8859-15:
LC_COLLATE  LC_CTYPELC_MESSAGES LC_MONETARY
LC_NUMERIC  LC_TIME

so it should work.

If I have change fr_FR to fr_FR.ISO_8859-1 in the setlocale call, the
script works fine, isn't setlocale() supposed to use default charset
which is ISO_8859-1 ? In any case the documentation does not mention
that we have to add the charset under FreeBSD...

Reproduce code:
---
setlocale(LC_TIME, "fr_FR");
echo strftime("%B %Y",$timestamp);


Expected result:

TRUE
Octobre 2003

Actual result:
--
FALSE
October 2003





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

#26038 [Opn]: session_start(): Failed to initialize storage module

[pedro at dehumanizer dot com]

 ID:   26038
 User updated by:  pedro at dehumanizer dot com
 Reported By:  pedro at dehumanizer dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.9
 PHP Version:  4CVS-2003-10-30 (stable)
 New Comment:

Just a little bit from "make test" (from today's CVS, 2003-10-31):

=
FAILED TEST SUMMARY
-
Bug #25547 (error_handler and array index with function call)
[tests/lang/bug25547.phpt]
Gettext basic test [ext/gettext/tests/gettext_basic.phpt]
Bug #16069 [ext/iconv/tests/bug16069.phpt]
Check for mktime with out-of-range parameters
[ext/standard/tests/time/003.phpt]
mktime() [ext/standard/tests/time/mktime.phpt]
=

I don't know if this is relevant...


Previous Comments:


[2003-10-31 05:50:30] pedro at dehumanizer dot com

I can basically rip, with a few alterations, the "expected/actual"
results from bug 25876:

Expected result:

not to see this message in logs, see the page expected

Actual result:
--

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in
/var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

and we get just a blank page instead of seeing of what actually
expected. Refreshing, or going back then clicking again, usually
works.

I can copy my php.ini and the results of "make test" and phpinfo() and
post them here, but it may be too big. Is it OK?



[2003-10-30 21:08:26] [EMAIL PROTECTED]

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

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

Thank you for your interest in PHP.




[2003-10-30 07:34:12] pedro at dehumanizer dot com

By the way, if I use Apache 1.3.28 instead, configuring the same
version of PHP with exactly the same options (except replacing
--with-apxs2 with --with-apxs), the problem disappears.



[2003-10-30 07:30:51] pedro at dehumanizer dot com

Description:

I believe this bug had already been reported by someone else (#25876),
but it was marked as "bogus".

I'm using FreeBSD 4.9 (and 4.8-STABLE before), Apache 2.0.48 from ports
(and 2.0.47 before), and tried several PHP versions from 4.3.2 to
4CVS-20031030 (today's). All of them exhibit this problem, with
SquirrelMail 1.4.2. 

I don't think it's a SquirrelMail problem, however, as the line in
question is a simple

session_start();

The problem is intermitent - when navigating through the webmail, from
time to time, when I click on a link, a blank page appears *very
quickly*, just in the frame which was supposed to be changed. In the
logs, I get this error:

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in /var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

If I reload the page, or go back from the blank page and click on the
same link again, it usually works then. The error rate is hard to
calculate, but it should be less than 1 in 10 times.

I've tried changing the sessions handler between files and mm, but it
doesn't solve the problem. Neither does activating register_globals,
which SquirrelMail doesn't need, anyway.

PHP configure options:

./configure  --disable-cgi --with-apxs2=/usr/local/sbin/apxs
--with-openssl --with-zlib --with-gdbm --with-imap --with-iconv
--enable-ftp --with-mysql=/usr/local/mysql --with-curl --disable-debug
--enable-exif --enable-sockets --disable-ipv6 --with-gd --with-jpeg-dir
--with-png-dir --enable-dio --with-gettext=/usr/local --with-bz2
--enable-mbstring --enable-mbregex --enable-zend-multibyte
--with-mysql-sock=/tmp/mysql.sock --with-mm=/usr/local







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

#26033 [Opn->Bgs]: imageftbbox gives anomalous values when first called

[robertks at hotmail dot com]

 ID:   26033
 User updated by:  robertks at hotmail dot com
 Reported By:  robertks at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: GD related
 Operating System: OpenBSD 3.1
 PHP Version:  4.3.3
 New Comment:

Compiling with the built-in version of gd fixed the issue.

--with-gd

is to be used instead of

--with-gd={$LOCALBASE}


Previous Comments:


[2003-10-31 06:03:57] robertks at hotmail dot com

Note in the above that I updated to an October 31st, 2003 snapshot of
PHP in the 4.3.x-dev category from http://snaps.php.net/, and not the
August 25th, 2003 distribution available from
http://www.php.net/downloads.php.



[2003-10-31 06:00:07] robertks at hotmail dot com

I updated to PHP 4.3.3.

Now I get

Array ( [0] => -1 [1] => 1393 [2] => 598 [3] => 1393 [4] => 598 [5] =>
-16 [6] => -1 [7] => -16 ) 
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 ) 

the first time I run the test code.  Note this is still an anomalous
result (the two outputted arrays should be identical) but different
than the result I was posted before.  Refresh, and I get the same. 
Refresh again, and I get the same.  Refresh a third time, and I get

Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 ) 
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

which was the anomalous result I posted before.  Refresh thrice more
and it goes back to the first result, and stays at that result ever
after with further refreshes.

All the best,
Robert K S



[2003-10-30 20:53:05] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

And use the bundled GD. (--with-gd)




[2003-10-29 20:15:24] robertks at hotmail dot com

Description:

Can anyone explain the bizarre behavior of this code?

ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
echo '';
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
?>

Output:
Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

Particulars:
Freetype 2.0.4
GD 2.0.9
PHP 4.3.1

What's going on?  The [5] and [7] values of the output array (Y
positions of the upper corners of the bounding box) are anomalous the
first time the imageftbbox function is called.  When the function is
called again in an identical manner, the values are good.

imagettfbbox does not exhibit this behavior on my system.

If this is a known bug, cursory searches haven't brought up anything
about it.

Help!

All the best,
Robert K S

Reproduce code:
---
ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
echo '';
print_r(imageftbbox($size, 0, $fontfile, $text, array()));
?>

Expected result:

Output:
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )

Actual result:
--
Output:
Array ( [0] => -1 [1] => 5 [2] => 598 [3] => 5 [4] => 598 [5] =>
-33554432 [6] => -1 [7] => -33554432 )
Array ( [0] => -1 [1] => 37 [2] => 598 [3] => 37 [4] => 598 [5] => -16
[6] => -1 [7] => -16 )





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

#26053 [NEW]: returning references crash

[ikaraszi at prim dot hu]

From: ikaraszi at prim dot hu
Operating system: Debian GNU/Linux unstable
PHP version:  4.3.3
PHP Bug Type: Reproducible crash
Bug description:  returning references crash

Description:

Our scripts (both mod_php and CGI/command line version) segfaulted.
Tracing the problem showed that the errors occured after a return()
statement. (The program ran ok until the return statement, but it never
did return into the function calling it.)

We have been able to reproduce the possible basis of the problem, see the
attached code. This code doesn't segfault, but does display an error. We
think that more complex usage leads to segfaults.

The following backtrace has been produced with one of our complex scripts,
not the one attached, so it's only provided for reference.
---
Program received signal SIGSEGV, Segmentation fault.
0x081455c9 in _mem_block_check (ptr=0x81ceaa4, silent=0,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:675
675 memcpy(&end_magic, (((char *)
p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long));
(gdb) bt
#0  0x081455c9 in _mem_block_check (ptr=0x81ceaa4, silent=0,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:675
#1  0x081456ce in _mem_block_check (ptr=0x81ceaa4, silent=1,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:683
#2  0x08144b42 in _efree (ptr=0x81ceaa4,
__zend_filename=0x3038 ,
__zend_lineno=1073737784,
__zend_orig_filename=0x3038 ,
__zend_orig_lineno=1073737784) at
/root/php4-4.3.3/Zend/zend_alloc.c:243
#3  0x081609f0 in zend_assign_to_variable_reference (result=0x83cfa18,
variable_ptr_ptr=0x847aef8,
value_ptr_ptr=0x83d95e0, Ts=0xbfffe6cc) at
/root/php4-4.3.3/Zend/zend_execute.c:271
#4  0x08162845 in execute (op_array=0x83cdfa8) at
/root/php4-4.3.3/Zend/zend_execute.c:163
#5  0x0814c72f in call_user_function_ex (function_table=0x0,
object_pp=0x0, function_name=0x0,
retval_ptr_ptr=0xb038, param_count=0, params=0x8344c7c,
no_separation=1, symbol_table=0x0)
at /root/php4-4.3.3/Zend/zend_execute_API.c:567
#6  0x0814c152 in call_user_function (function_table=0x3038,
object_pp=0x3038,
function_name=0x3038, retval_ptr=0xb070, param_count=0,
params=0x83d93d0)
at /root/php4-4.3.3/Zend/zend_execute_API.c:409
#7  0x080bd610 in user_shutdown_function_call
(shutdown_function_entry=0x83d8d74)
at /root/php4-4.3.3/ext/standard/basic_functions.c:2007
#8  0x08159c88 in zend_hash_apply (ht=0x833be3c, apply_func=0x80bd5d0
)
at /root/php4-4.3.3/Zend/zend_hash.c:698
#9  0x080bd929 in php_call_shutdown_functions ()
at /root/php4-4.3.3/ext/standard/basic_functions.c:2088
#10 0x08124da2 in php_request_shutdown (dummy=0x0) at
/root/php4-4.3.3/main/main.c:980
#11 0x08168bf0 in main (argc=4, argv=0xb804) at
/root/php4-4.3.3/sapi/cli/php_cli.c:869



Reproduce code:
---
getNull();
var_dump($x);
if (is_object($x['element'])) {
return(true);
}
return(false);
}
  
   
function &getNull() {
/**
 * uncomment following (two) lines to work around the
problem
 */
//if (isset($testarray['test']))
return($testarray['test']);
//return(NULL);
  
   
return($testarray['test']);
}
}
  
   
$t = new Test();
$t->testCase();
?>

Expected result:

NULL

Actual result:
--
NULL
/root/php4-4.3.3/Zend/zend_execute.c(1711) :  Freeing 0x0820E0C4 (12
bytes), script=test-case2.php


-- 
Edit bug report at http://bugs.php.net/?id=26053&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=26053&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=26053&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=26053&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=26053&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26053&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=26053&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26053&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=26

#26053 [Com]: returning references crash

[phpbugs at spam dot johnzero dot hu]

 ID:   26053
 Comment by:   phpbugs at spam dot johnzero dot hu
 Reported By:  ikaraszi at prim dot hu
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Debian GNU/Linux unstable
 PHP Version:  4.3.3
 New Comment:

You must use a debug build of PHP4 to see the error message.

Otherwise you see everything as OK! (Although it's not.)


Previous Comments:


[2003-10-31 07:04:35] ikaraszi at prim dot hu

Description:

Our scripts (both mod_php and CGI/command line version) segfaulted.
Tracing the problem showed that the errors occured after a return()
statement. (The program ran ok until the return statement, but it never
did return into the function calling it.)

We have been able to reproduce the possible basis of the problem, see
the attached code. This code doesn't segfault, but does display an
error. We think that more complex usage leads to segfaults.

The following backtrace has been produced with one of our complex
scripts, not the one attached, so it's only provided for reference.
---
Program received signal SIGSEGV, Segmentation fault.
0x081455c9 in _mem_block_check (ptr=0x81ceaa4, silent=0,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:675
675 memcpy(&end_magic, (((char *)
p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long));
(gdb) bt
#0  0x081455c9 in _mem_block_check (ptr=0x81ceaa4, silent=0,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:675
#1  0x081456ce in _mem_block_check (ptr=0x81ceaa4, silent=1,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:683
#2  0x08144b42 in _efree (ptr=0x81ceaa4,
__zend_filename=0x3038 ,
__zend_lineno=1073737784,
__zend_orig_filename=0x3038 ,
__zend_orig_lineno=1073737784) at
/root/php4-4.3.3/Zend/zend_alloc.c:243
#3  0x081609f0 in zend_assign_to_variable_reference (result=0x83cfa18,
variable_ptr_ptr=0x847aef8,
value_ptr_ptr=0x83d95e0, Ts=0xbfffe6cc) at
/root/php4-4.3.3/Zend/zend_execute.c:271
#4  0x08162845 in execute (op_array=0x83cdfa8) at
/root/php4-4.3.3/Zend/zend_execute.c:163
#5  0x0814c72f in call_user_function_ex (function_table=0x0,
object_pp=0x0, function_name=0x0,
retval_ptr_ptr=0xb038, param_count=0, params=0x8344c7c,
no_separation=1, symbol_table=0x0)
at /root/php4-4.3.3/Zend/zend_execute_API.c:567
#6  0x0814c152 in call_user_function (function_table=0x3038,
object_pp=0x3038,
function_name=0x3038, retval_ptr=0xb070, param_count=0,
params=0x83d93d0)
at /root/php4-4.3.3/Zend/zend_execute_API.c:409
#7  0x080bd610 in user_shutdown_function_call
(shutdown_function_entry=0x83d8d74)
at /root/php4-4.3.3/ext/standard/basic_functions.c:2007
#8  0x08159c88 in zend_hash_apply (ht=0x833be3c, apply_func=0x80bd5d0
)
at /root/php4-4.3.3/Zend/zend_hash.c:698
#9  0x080bd929 in php_call_shutdown_functions ()
at /root/php4-4.3.3/ext/standard/basic_functions.c:2088
#10 0x08124da2 in php_request_shutdown (dummy=0x0) at
/root/php4-4.3.3/main/main.c:980
#11 0x08168bf0 in main (argc=4, argv=0xb804) at
/root/php4-4.3.3/sapi/cli/php_cli.c:869



Reproduce code:
---
getNull();
var_dump($x);
if (is_object($x['element'])) {
return(true);
}
return(false);
}
   
  
function &getNull() {
/**
 * uncomment following (two) lines to work around the
problem
 */
//if (isset($testarray['test']))
return($testarray['test']);
//return(NULL);
   
  
return($testarray['test']);
}
}
   
  
$t = new Test();
$t->testCase();
?>

Expected result:

NULL

Actual result:
--
NULL
/root/php4-4.3.3/Zend/zend_execute.c(1711) :  Freeing 0x0820E0C4 (12
bytes), script=test-case2.php






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

#26054 [NEW]: using unreferenced variables does not produce errors

[sascha dot wildgrube at steganos dot com]

From: sascha dot wildgrube at steganos dot com
Operating system: all
PHP version:  4.3.2
PHP Bug Type: *Programming Data Structures
Bug description:  using unreferenced variables does not produce errors

Description:

Any variable identifier can be used in a statement - even if it hasn't
been referenced before - without producing an error.

Most of the time when debuggong php code is spent for searching typos in
variable names.

I consider it a bug that php does not produce and display error if it
encounters an unreferenced variable in a statement.

A solution could be a "strict" statement. That tells php to throw errors
in that case to stay backward compatible.

An even better solution would be the need to 

Reproduce code:
---
$nValue1 = 10;
$nValue2 = 20;
print($nVale1 + $nValue2);

Expected result:

Expected:

30

No, it is:

20

Why, because of the typo in line 3. What I want to happen in that case is
this:

Parse error: parse error in /somefile.php4 on line 3: unreferenced object
"$nVale1"

Actual result:
--
20

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

#26054 [Opn]: using unreferenced variables does not produce errors

[sascha dot wildgrube at steganos dot com]

 ID:   26054
 User updated by:  sascha dot wildgrube at steganos dot com
 Reported By:  sascha dot wildgrube at steganos dot com
 Status:   Open
 Bug Type: *Programming Data Structures
 Operating System: all
 PHP Version:  4.3.2
 New Comment:

An even better solution would be the need to initialize variables like
that "var $nValue;". This way even typos in  in lvalues would not do
any harm.

We once observed how much percent of the time was consumed by this bug.
We found out that 30% of the time when working on php code could be
saved if php had strict variable usage.


Previous Comments:


[2003-10-31 07:26:30] sascha dot wildgrube at steganos dot com

Description:

Any variable identifier can be used in a statement - even if it hasn't
been referenced before - without producing an error.

Most of the time when debuggong php code is spent for searching typos
in variable names.

I consider it a bug that php does not produce and display error if it
encounters an unreferenced variable in a statement.

A solution could be a "strict" statement. That tells php to throw
errors in that case to stay backward compatible.

An even better solution would be the need to 

Reproduce code:
---
$nValue1 = 10;
$nValue2 = 20;
print($nVale1 + $nValue2);

Expected result:

Expected:

30

No, it is:

20

Why, because of the typo in line 3. What I want to happen in that case
is this:

Parse error: parse error in /somefile.php4 on line 3: unreferenced
object "$nVale1"

Actual result:
--
20





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

#26047 [WFx]: Access to supervariables via $$variable does not function as documented.

[sniper]

 ID:   26047
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dw-bugs dot php dot net at botanicus dot net
 Status:   Wont fix
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

No. 


Previous Comments:


[2003-10-31 05:01:47] dw-bugs dot php dot net at botanicus dot net

Will this be fixed in Zend2?



[2003-10-31 04:44:04] [EMAIL PROTECTED]

Hi,

This is by-design and it's the price you have to pay for these special
superglobals. A price which is worth paying...
If this is not documented in the online docs then feel free to drop a
line to [EMAIL PROTECTED] with the wording you think should be added



[2003-10-30 23:38:43] dw-bugs dot php dot net at botanicus dot net

Description:

>From the implementation I suppose this is pretty obvious, but the
following does not work:

   $data_source = '_POST';
   $data =& $$data_source;

'$data' does not point at $_POST as expected. I'd consider this a
problem - your implementation is showing through. Either re-label
$_POST, etc. as not actually being superglobals, or fix the underlying
implementation (which does not at present match up with your
documentation).

"""This is a 'superglobal', or automatic global, variable. This simply
means that it is available in all scopes throughout a script."""

This statement is not true, since the variable is only 'automatic
global' when referred to by name directly (and thus gets caught by your
special case code). It does not actually exist in every scope.

I beg you not to mark this as a documentation problem and change the
docs to mention this. Fix it! It's a horrible inconsistancy. This,
along with a million other sour points, is the reason why I absolutely
detest my day job at the minute. Come on guys! Do it for me!

Reproduce code:
---
$data_source = '_POST';
$data =& $$data_source;

echo gettype($data);

Expected result:

array

Actual result:
--
NULL





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

#26055 [NEW]: problem withs strings

[kiran_jack at rediffmail dot com]

From: kiran_jack at rediffmail dot com
Operating system: apache
PHP version:  4.3.1
PHP Bug Type: Strings related
Bug description:  problem withs strings

Description:

I have a problem with a query. I'd like to make a search in a  table
inserting 2 or more words in the input form, using the OR.  Everything
works fine with 1 word but with more I obtain result only for  the LAST
inserted one
Please reply me soon,
Jack



Reproduce code:
---
go back and try some different search terms.";
}

   else {
echo "";
echo "Search Results:"; 
while ($r = mysql_fetch_array($result))
 { // Begin while 
echo "";
$id1=$r["id"];
$link1= $r["link"];
$meta= $r["description"]; 
$keywords1= $r["keywords"];
$figure=$r["picture"]; 
$price=$r["cost"];

echo "";
echo "";
echo "";
echo "$id1";
echo "";
echo "";
echo "";
echo "$meta";
echo "";
echo "";
echo "$keywords1";
echo "";
echo "";
echo "Rs";
echo "$price";
echo "/-";
echo "";
echo "";

echo "";
echo "";

 } // end while 
echo "";
echo "";
} 
}
 else  
 echo "You did not enter anything to search for. Please go back and enter a search word.";
?>

Expected result:

i want to search the entire string


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

#26054 [Opn->Bgs]: using unreferenced variables does not produce errors

[alan_k]

 ID:   26054
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sascha dot wildgrube at steganos dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Programming Data Structures
 Operating System: all
 PHP Version:  4.3.2
 New Comment:

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

try error_reporting(E_ALL);




Previous Comments:


[2003-10-31 07:37:12] sascha dot wildgrube at steganos dot com

An even better solution would be the need to initialize variables like
that "var $nValue;". This way even typos in  in lvalues would not do
any harm.

We once observed how much percent of the time was consumed by this bug.
We found out that 30% of the time when working on php code could be
saved if php had strict variable usage.



[2003-10-31 07:26:30] sascha dot wildgrube at steganos dot com

Description:

Any variable identifier can be used in a statement - even if it hasn't
been referenced before - without producing an error.

Most of the time when debuggong php code is spent for searching typos
in variable names.

I consider it a bug that php does not produce and display error if it
encounters an unreferenced variable in a statement.

A solution could be a "strict" statement. That tells php to throw
errors in that case to stay backward compatible.

An even better solution would be the need to 

Reproduce code:
---
$nValue1 = 10;
$nValue2 = 20;
print($nVale1 + $nValue2);

Expected result:

Expected:

30

No, it is:

20

Why, because of the typo in line 3. What I want to happen in that case
is this:

Parse error: parse error in /somefile.php4 on line 3: unreferenced
object "$nVale1"

Actual result:
--
20





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

#26055 [Opn->Bgs]: problem withs strings

[sniper]

 ID:   26055
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kiran_jack at rediffmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Strings related
 Operating System: apache
 PHP Version:  4.3.1
 New Comment:

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

Thank you for your interest in PHP.

This is not support forum. 



Previous Comments:


[2003-10-31 07:51:18] kiran_jack at rediffmail dot com

Description:

I have a problem with a query. I'd like to make a search in a  table
inserting 2 or more words in the input form, using the OR.  Everything
works fine with 1 word but with more I obtain result only for  the LAST
inserted one
Please reply me soon,
Jack



Reproduce code:
---
go back and try some different search
terms.";
}

   else {
echo "";
echo "Search Results:"; 
while ($r = mysql_fetch_array($result))
 { // Begin while 
echo "";
$id1=$r["id"];
$link1= $r["link"];
$meta= $r["description"]; 
$keywords1= $r["keywords"];
$figure=$r["picture"]; 
$price=$r["cost"];

echo "";
echo "";
echo "";
echo "$id1";
echo "";
echo "";
echo "";
echo "$meta";
echo "";
echo "";
echo "$keywords1";
echo "";
echo "";
echo "Rs";
echo "$price";
echo "/-";
echo "";
echo "";

echo "";
echo "";

 } // end while 
echo "";
echo "";
} 
}
 else  
 echo "You did not enter anything to search for. Please go back and enter a search word.";
?>

Expected result:

i want to search the entire string






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

#26038 [Opn]: session_start(): Failed to initialize storage module

[pedro at dehumanizer dot com]

 ID:   26038
 User updated by:  pedro at dehumanizer dot com
 Reported By:  pedro at dehumanizer dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.9
 PHP Version:  4CVS-2003-10-30 (stable)
 New Comment:

I can basically rip, with a few alterations, the "expected/actual"
results from bug 25876:

Expected result:

not to see this message in logs, see the page expected

Actual result:
--

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in
/var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

and we get just a blank page instead of seeing of what actually
expected. Refreshing, or going back then clicking again, usually
works.

I can copy my php.ini and the results of "make test" and phpinfo() and
post them here, but it may be too big. Is it OK?


Previous Comments:


[2003-10-30 07:34:12] pedro at dehumanizer dot com

By the way, if I use Apache 1.3.28 instead, configuring the same
version of PHP with exactly the same options (except replacing
--with-apxs2 with --with-apxs), the problem disappears.



[2003-10-30 07:30:51] pedro at dehumanizer dot com

Description:

I believe this bug had already been reported by someone else (#25876),
but it was marked as "bogus".

I'm using FreeBSD 4.9 (and 4.8-STABLE before), Apache 2.0.48 from ports
(and 2.0.47 before), and tried several PHP versions from 4.3.2 to
4CVS-20031030 (today's). All of them exhibit this problem, with
SquirrelMail 1.4.2. 

I don't think it's a SquirrelMail problem, however, as the line in
question is a simple

session_start();

The problem is intermitent - when navigating through the webmail, from
time to time, when I click on a link, a blank page appears *very
quickly*, just in the frame which was supposed to be changed. In the
logs, I get this error:

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in /var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

If I reload the page, or go back from the blank page and click on the
same link again, it usually works then. The error rate is hard to
calculate, but it should be less than 1 in 10 times.

I've tried changing the sessions handler between files and mm, but it
doesn't solve the problem. Neither does activating register_globals,
which SquirrelMail doesn't need, anyway.

PHP configure options:

./configure  --disable-cgi --with-apxs2=/usr/local/sbin/apxs
--with-openssl --with-zlib --with-gdbm --with-imap --with-iconv
--enable-ftp --with-mysql=/usr/local/mysql --with-curl --disable-debug
--enable-exif --enable-sockets --disable-ipv6 --with-gd --with-jpeg-dir
--with-png-dir --enable-dio --with-gettext=/usr/local --with-bz2
--enable-mbstring --enable-mbregex --enable-zend-multibyte
--with-mysql-sock=/tmp/mysql.sock --with-mm=/usr/local







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

#26038 [Opn]: session_start(): Failed to initialize storage module

[pedro at dehumanizer dot com]

 ID:   26038
 User updated by:  pedro at dehumanizer dot com
 Reported By:  pedro at dehumanizer dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.9
 PHP Version:  4CVS-2003-10-30 (stable)
 New Comment:

Just a little bit from "make test" (from today's CVS, 2003-10-31):

=
FAILED TEST SUMMARY
-
Bug #25547 (error_handler and array index with function call)
[tests/lang/bug25547.phpt]
Gettext basic test [ext/gettext/tests/gettext_basic.phpt]
Bug #16069 [ext/iconv/tests/bug16069.phpt]
Check for mktime with out-of-range parameters
[ext/standard/tests/time/003.phpt]
mktime() [ext/standard/tests/time/mktime.phpt]
=

I don't know if this is relevant... The problem remains with this
compiled PHP.


Previous Comments:


[2003-10-31 08:01:40] pedro at dehumanizer dot com

I can basically rip, with a few alterations, the "expected/actual"
results from bug 25876:

Expected result:

not to see this message in logs, see the page expected

Actual result:
--

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in
/var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

and we get just a blank page instead of seeing of what actually
expected. Refreshing, or going back then clicking again, usually
works.

I can copy my php.ini and the results of "make test" and phpinfo() and
post them here, but it may be too big. Is it OK?



[2003-10-30 07:34:12] pedro at dehumanizer dot com

By the way, if I use Apache 1.3.28 instead, configuring the same
version of PHP with exactly the same options (except replacing
--with-apxs2 with --with-apxs), the problem disappears.



[2003-10-30 07:30:51] pedro at dehumanizer dot com

Description:

I believe this bug had already been reported by someone else (#25876),
but it was marked as "bogus".

I'm using FreeBSD 4.9 (and 4.8-STABLE before), Apache 2.0.48 from ports
(and 2.0.47 before), and tried several PHP versions from 4.3.2 to
4CVS-20031030 (today's). All of them exhibit this problem, with
SquirrelMail 1.4.2. 

I don't think it's a SquirrelMail problem, however, as the line in
question is a simple

session_start();

The problem is intermitent - when navigating through the webmail, from
time to time, when I click on a link, a blank page appears *very
quickly*, just in the frame which was supposed to be changed. In the
logs, I get this error:

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in /var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

If I reload the page, or go back from the blank page and click on the
same link again, it usually works then. The error rate is hard to
calculate, but it should be less than 1 in 10 times.

I've tried changing the sessions handler between files and mm, but it
doesn't solve the problem. Neither does activating register_globals,
which SquirrelMail doesn't need, anyway.

PHP configure options:

./configure  --disable-cgi --with-apxs2=/usr/local/sbin/apxs
--with-openssl --with-zlib --with-gdbm --with-imap --with-iconv
--enable-ftp --with-mysql=/usr/local/mysql --with-curl --disable-debug
--enable-exif --enable-sockets --disable-ipv6 --with-gd --with-jpeg-dir
--with-png-dir --enable-dio --with-gettext=/usr/local --with-bz2
--enable-mbstring --enable-mbregex --enable-zend-multibyte
--with-mysql-sock=/tmp/mysql.sock --with-mm=/usr/local







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

#26038 [Opn]: session_start(): Failed to initialize storage module

[sniper]

 ID:   26038
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pedro at dehumanizer dot com
 Status:   Open
 Bug Type: Apache2 related
 Operating System: FreeBSD 4.9
 PHP Version:  4CVS-2003-10-30 (stable)
 New Comment:

Don't re-add those irrelevant notes anymore.



Previous Comments:


[2003-10-30 07:34:12] pedro at dehumanizer dot com

By the way, if I use Apache 1.3.28 instead, configuring the same
version of PHP with exactly the same options (except replacing
--with-apxs2 with --with-apxs), the problem disappears.



[2003-10-30 07:30:51] pedro at dehumanizer dot com

Description:

I believe this bug had already been reported by someone else (#25876),
but it was marked as "bogus".

I'm using FreeBSD 4.9 (and 4.8-STABLE before), Apache 2.0.48 from ports
(and 2.0.47 before), and tried several PHP versions from 4.3.2 to
4CVS-20031030 (today's). All of them exhibit this problem, with
SquirrelMail 1.4.2. 

I don't think it's a SquirrelMail problem, however, as the line in
question is a simple

session_start();

The problem is intermitent - when navigating through the webmail, from
time to time, when I click on a link, a blank page appears *very
quickly*, just in the frame which was supposed to be changed. In the
logs, I get this error:

[client 62.169.69.5] PHP Fatal error:  session_start(): Failed to
initialize storage module. in /var/www/htdocs/mail/functions/global.php
on line 295, referer: https://www.dehumanizer.com/mail/src/webmail.php

If I reload the page, or go back from the blank page and click on the
same link again, it usually works then. The error rate is hard to
calculate, but it should be less than 1 in 10 times.

I've tried changing the sessions handler between files and mm, but it
doesn't solve the problem. Neither does activating register_globals,
which SquirrelMail doesn't need, anyway.

PHP configure options:

./configure  --disable-cgi --with-apxs2=/usr/local/sbin/apxs
--with-openssl --with-zlib --with-gdbm --with-imap --with-iconv
--enable-ftp --with-mysql=/usr/local/mysql --with-curl --disable-debug
--enable-exif --enable-sockets --disable-ipv6 --with-gd --with-jpeg-dir
--with-png-dir --enable-dio --with-gettext=/usr/local --with-bz2
--enable-mbstring --enable-mbregex --enable-zend-multibyte
--with-mysql-sock=/tmp/mysql.sock --with-mm=/usr/local







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

#21926 [NoF->WFx]: Apache process hangs

[sniper]

 ID:   21926
 Updated by:   [EMAIL PROTECTED]
 Reported By:  arinto at almedina dot net
-Status:   No Feedback
+Status:   Wont fix
 Bug Type: Java related
 Operating System: Red Hat Linux 7.1
 PHP Version:  4CVS-2003-01-28 (stable)
 New Comment:

Java support in PHP 4 was experimental to begin with and will not be
fixed. PHP 5 might have better support.



Previous Comments:


[2003-08-18 19:45:05] [EMAIL PROTECTED]

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





[2003-08-13 12:15:50] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-02-14 12:03:46] minusone at yahoo dot com

I would like to ammend this report by saying I am seeing something
similar... using Lucene...

Now... here's some more information. Using the CLI... my PHP script
works just fine. It instantiates my java object and executes perfectly
and returns results as I would expect... so it appears to be definitely
something with the libphp4.so module. 

I have rebuilt it many many times. 

I should also say that running on RedHat 8.0 everything works
perfectly... its just on RedHat 7.x appears to be a problem.

I am using Sun JDK 1.3.1_07 for Linux
Apache 1.24



[2003-01-28 13:16:59] arinto at almedina dot net

Hi.

I'm using the PHP Java extension to run Jakarta Lucene to power my
internal site search. Whenever I call a Java object, Apache starts
between 1 to 5 new httpd processes and it keeps growing with each
subsequent call to the object.
After some time (and after more than 50 httpd processes are started)
the web site stops respondig for some clients. For others it continues
running as usual.
This happens with PHP 4.3.0 and the latest CVS (2003-01-28)

My configure line is as follows:

'./configure' '--with-mysql' '--with-imap' '--with-imap-ssl'
'--with-kerberos' '--with-apxs=/var/www/bin/apxs' '--enable-xslt'
'--with-xslt-sablot' '--with-xml' '--with-iconv' '--with-pgsql'
'--with-dom' '--with-zlib' '--with-gd'
'--with-java=/usr/java/j2sdk1.4.1_01' 

Java Version: Sun J2SE 1.4.1
Apache Version 1.3.24

This also seems to be the same bug as #20270, that is closed.




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

#26035 [Opn->Asn]: Opening existing CDB does not work

[sniper]

 ID:   26035
 Updated by:   [EMAIL PROTECTED]
 Reported By:  a dot stagl at gmx dot at
-Status:   Open
+Status:   Assigned
 Bug Type: DBM/DBA related
-Operating System: Win2k
+Operating System: *
-PHP Version:  4.3.3
+PHP Version:  4CVS, 5CVS
-Assigned To:  
+Assigned To:  helly
 New Comment:

It actually returns empty string. When you change the
check to while ($key !== false) it'll crash:

(gdb) bt
#0  0x4072cf51 in kill () from /lib/i686/libc.so.6
#1  0x082762ac in _emalloc (size=1735290733, __zend_filename=0x8327600
"/usr/src/web/php/php4/ext/dba/dba_cdb.c", 
__zend_lineno=303, __zend_orig_filename=0x84a6220
"/usr/src/web/php/php4/Zend/zend_alloc.c", __zend_orig_lineno=218)
at /usr/src/web/php/php4/Zend/zend_alloc.c:166
#2  0x082765c1 in _safe_emalloc (nmemb=1735290732, size=1, offset=1, 
__zend_filename=0x8327600
"/usr/src/web/php/php4/ext/dba/dba_cdb.c", __zend_lineno=303,
__zend_orig_filename=0x0, 
__zend_orig_lineno=0) at
/usr/src/web/php/php4/Zend/zend_alloc.c:218
#3  0x080bce64 in dba_nextkey_cdb (info=0x864eb74, newlen=0xbfffd4ec)
at /usr/src/web/php/php4/ext/dba/dba_cdb.c:303
#4  0x080bbfa4 in zif_dba_nextkey (ht=1, return_value=0x86401ec,
this_ptr=0x0, return_value_used=1)
at /usr/src/web/php/php4/ext/dba/dba.c:914

Assigned to Marcus who added this thing.



Previous Comments:


[2003-10-31 03:55:39] a dot stagl at gmx dot at

Unfortunatly, I cannot provide you the DB which I'm refering to,
because - as already mentioned - it is the contacts-database from a
nokia 9210i which contains sensitive data. I tried to get a sample
contacts.cdb directly from nokia, but they haven't been supportive :-(

But I found the following two cdb-databases on the internet:

http://web.mit.edu/cascon/updates/cascon.cdb (does not work with the
provided code)

http://cvs.sourceforge.net/viewcvs.py/*checkout*/cdbfile/cdbFile/cdbFile/Attic/test.cdb?rev=1.1.1.1
(works fine with my code)

HTH



[2003-10-30 20:36:06] [EMAIL PROTECTED]

Please provide the information HERE, not via private mail!




[2003-10-30 10:12:05] a dot stagl at gmx dot at

I sent it to yob by PM.



[2003-10-30 08:21:03] [EMAIL PROTECTED]

Could you please provide the database in question.



[2003-10-30 05:30:43] a dot stagl at gmx dot at

Description:

I'm trying to open the contacts-databse from a nokia 9210i mobile, but
it doesn't work.


Reproduce code:
---
$db_conn = dba_open("contacts.cdb","r","cdb");
if (!$db_conn) die ("opening failed");
$key = dba_firstkey ($db_conn);
while ($key != false)
{
  echo $key."";
  echo dba_fetch ($key, $db_conn)."";
  $key = dba_nextkey ($db_conn);
}
dba_close($db_conn);

Expected result:

...to get a list of key-value pairs.

Actual result:
--
The code didn't produce the expected output nor any error message. It
seems that the commands dba_firstkey and dba_nextkey always return
false instead of a key.






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

#26035 [Asn]: Opening existing CDB does not work

[sniper]

 ID:   26035
 Updated by:   [EMAIL PROTECTED]
 Reported By:  a dot stagl at gmx dot at
 Status:   Assigned
 Bug Type: DBM/DBA related
 Operating System: *
 PHP Version:  4CVS, 5CVS
 Assigned To:  helly
 New Comment:

OTOH, I don't think that Nokia/Cascon are using the CDB but something
of their own invention.



Previous Comments:


[2003-10-31 08:26:33] [EMAIL PROTECTED]

It actually returns empty string. When you change the
check to while ($key !== false) it'll crash:

(gdb) bt
#0  0x4072cf51 in kill () from /lib/i686/libc.so.6
#1  0x082762ac in _emalloc (size=1735290733, __zend_filename=0x8327600
"/usr/src/web/php/php4/ext/dba/dba_cdb.c", 
__zend_lineno=303, __zend_orig_filename=0x84a6220
"/usr/src/web/php/php4/Zend/zend_alloc.c", __zend_orig_lineno=218)
at /usr/src/web/php/php4/Zend/zend_alloc.c:166
#2  0x082765c1 in _safe_emalloc (nmemb=1735290732, size=1, offset=1, 
__zend_filename=0x8327600
"/usr/src/web/php/php4/ext/dba/dba_cdb.c", __zend_lineno=303,
__zend_orig_filename=0x0, 
__zend_orig_lineno=0) at
/usr/src/web/php/php4/Zend/zend_alloc.c:218
#3  0x080bce64 in dba_nextkey_cdb (info=0x864eb74, newlen=0xbfffd4ec)
at /usr/src/web/php/php4/ext/dba/dba_cdb.c:303
#4  0x080bbfa4 in zif_dba_nextkey (ht=1, return_value=0x86401ec,
this_ptr=0x0, return_value_used=1)
at /usr/src/web/php/php4/ext/dba/dba.c:914

Assigned to Marcus who added this thing.




[2003-10-31 03:55:39] a dot stagl at gmx dot at

Unfortunatly, I cannot provide you the DB which I'm refering to,
because - as already mentioned - it is the contacts-database from a
nokia 9210i which contains sensitive data. I tried to get a sample
contacts.cdb directly from nokia, but they haven't been supportive :-(

But I found the following two cdb-databases on the internet:

http://web.mit.edu/cascon/updates/cascon.cdb (does not work with the
provided code)

http://cvs.sourceforge.net/viewcvs.py/*checkout*/cdbfile/cdbFile/cdbFile/Attic/test.cdb?rev=1.1.1.1
(works fine with my code)

HTH



[2003-10-30 05:30:43] a dot stagl at gmx dot at

Description:

I'm trying to open the contacts-databse from a nokia 9210i mobile, but
it doesn't work.


Reproduce code:
---
$db_conn = dba_open("contacts.cdb","r","cdb");
if (!$db_conn) die ("opening failed");
$key = dba_firstkey ($db_conn);
while ($key != false)
{
  echo $key."";
  echo dba_fetch ($key, $db_conn)."";
  $key = dba_nextkey ($db_conn);
}
dba_close($db_conn);

Expected result:

...to get a list of key-value pairs.

Actual result:
--
The code didn't produce the expected output nor any error message. It
seems that the commands dba_firstkey and dba_nextkey always return
false instead of a key.






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

#26051 [Opn->Bgs]: filetype() returns wrong type for device drivers

[sniper]

 ID:   26051
 Updated by:   [EMAIL PROTECTED]
 Reported By:  six at t0x dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: win2k
 PHP Version:  4.3.4RC3
 New Comment:

PHP returns whatever the libc stat() function returns for the filetype.
No bug.



Previous Comments:


[2003-10-31 06:06:43] six at t0x dot net

Description:

As the subject states, filetype() on windows (w2k at least) returns
wrong type for device drivers. Actually, it seems to always return the
type "file".



Reproduce code:
---


Expected result:

type : char

Actual result:
--
type : file





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

#26050 [Opn->Bgs]: Unable to use CONST vars in other CONST vars

[sniper]

 ID:   26050
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kris dot hofmans at pandora dot be
-Status:   Open
+Status:   Bogus
 Bug Type: Zend Engine 2 problem
 Operating System: Linux 2.4.21
 PHP Version:  5CVS-2003-10-31 (dev)
 New Comment:

"Head up! I'm reverting the patch which allows for expressions in
constant declerations. Allowing the access of other constants in this
code is flawed. We are reverting back to PHP 4's static scalars." --
Andi



Previous Comments:


[2003-10-31 05:23:49] kris dot hofmans at pandora dot be

Description:

I have had code that has been running with php5-dev versions since
July, wich now won't parse anymore.

I had declared a CONST in a class wich I used in another CONST below
it, this now gives a: 
Parse error: parse error, expecting `','' or `';'' in
/home/blacky/public_html/php5-dev/zen/ext/types.class.php on line 127

I am using PHP 5 Beta 2 (currently not in the list)

Reproduce code:
---
const NUMERIC   = '0-9';
const SPACE = '\s';
const PUNCTUATION   = SPACE . '\.,;\:&"\'\?\!\(\)';
const ALPHA_LCASE   = 'a-z';
const E_ALPHA_LCASE = ALPHA_LCASE . 'áéíóúàèìòùäëïöüâêîôûñç';
const ALPHA_UCASE   = 'A-Z';
const E_ALPHA_UCASE = ALPHA_UCASE . 'ÁÉÍÓÚÀÈÌÒÙÄËÏÖÜÂÊÎÔÛÑÇ';
const ALPHA = ALPHA_LCASE . ALPHA_UCASE;
const E_ALPHA   = E_ALPHA_LCASE . E_ALPHA_UCASE;
const ALPHA_NUM = ALPHA . NUMERIC;

Expected result:

I expect the behaviour to be something like.

const FOO = 'foo';
const BAR = 'bar';
const FOOBAR = FOO . BAR;

and that an echo FOOBAR would give me the string 'foobar'

Actual result:
--
Parse error: parse error, expecting `','' or `';'' in
/home/blacky/public_html/php5-dev/zen/ext/types.class.php on line 127





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

#17593 [Com]: mssql_query doesn't fetch results properly

[adimuraru at rdslink dot ro]

 ID:   17593
 Comment by:   adimuraru at rdslink dot ro
 Reported By:  alexp at mail dot lv
 Status:   Closed
 Bug Type: MSSQL related
 Operating System: Win2k prof. SP2
 PHP Version:  4.2.1
 New Comment:

This error occurs when you try to send a new command to the server
before all the results of the previous command on the same connection
have been completely processed. A connection in mssql library used in
php is single-threaded and synchronous; it can handle only one request
to the server at a time.

So, if you want to pass multiple query  to a database make a single
batch query(with multiple queries):
 $RS=mssql_query(select * from table1 select * from tabel2);
and use mysql_next_result to fetch all records.

After use result set make sure you  deallocate resources with
mssql_free_result($rs) before make another request to sql server in the
same script


Previous Comments:


[2002-12-03 12:07:05] [EMAIL PROTECTED]

In PHP 4.3.0 you will be able to fix this problem by calling
mssql_free_result($r1); after the first statement.

When you use if statements MSSQL server seams to hold the result
(blocing for other statements) until the result is released.



[2002-06-04 06:38:50] alexp at mail dot lv

It seems that mssql_query fails to get results properly after executing
some arbitrary queries.



..causes..


Warning: MS SQL error: Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in d:\htdocs\t\bug.php on line 4

Warning: MS SQL: Query failed in d:\htdocs\t\bug.php on line 4

Warning: MS SQL error: Attempt to initiate a new SQL Server operation
with results pending. (severity 7) in d:\htdocs\t\bug.php on line 5

Warning: MS SQL: Query failed in d:\htdocs\t\bug.php on line 5


First query is correct and executes properly (checked with SQL server
profiler running). But 2nd,3rd..n-th fail to execute. Though if I
comment out 1st one, others work ok. Another dirty hack to avoid these
errors is to embed entire query in exec(""). But then temporary #tables
won't be available in next queries.

I've found another similar bug in database, #9379. Using sql variables
in query causes same weird behaviour...

In a few days I will test this script on Linux/apache/php/freedts
connecting to same sql database and see if it works.

Any ideas?




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

#24394 [Com]: Session feature unusable.

[hoesh at dorsum dot hu]

 ID:   24394
 Comment by:   hoesh at dorsum dot hu
 Reported By:  hos dot endre at axelero dot hu
 Status:   No Feedback
 Bug Type: Session related
 Operating System: *
 PHP Version:  5CVS-2003-07-24 (dev)
 New Comment:

Now tested with 5.0.0.B2 and bug still exists. Apache restarts
immediately after running the test script.


Previous Comments:


[2003-10-04 01:23:57] [EMAIL PROTECTED]

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





[2003-09-28 16:13:07] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-07-07 08:24:55] [EMAIL PROTECTED]

Works 'fine' in PHP_4_3 branch, segfaults with PHP 5:

#0  0x813de25 in fast_call_user_function (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8, 
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0, 
function_pointer=0xbfe020b4) at
/usr/src/web/php/php5/Zend/zend_execute_API.c:477
#1  0x813de10 in call_user_function_ex (function_table=0x81c3338,
object_pp=0x4029b688, function_name=0xbfe021a8, 
retval_ptr_ptr=0xbfe02178, param_count=0, params=0x0,
no_separation=1, symbol_table=0x0)
at /usr/src/web/php/php5/Zend/zend_execute_API.c:476
#2  0x80fdd63 in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:555
#3  0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#4  0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#5  0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b5a0, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
#6  0x80fe90e in php_var_serialize_intern (buf=0xbfffd024,
struc=0x4029b688, var_hash=0xbfffd030)
at /usr/src/web/php/php5/ext/standard/var.c:620
.
.
.
.
Frame #6 is repeated couple of thousand times.. :)




[2003-07-06 06:56:32] hos dot endre at axelero dot hu

Okay: The subjected problem was solved by un-double-quoting the
session.save_path and remove the backslash from the end of line.
Anyway, until this the engine was able to create the file. After that I
had to get familiar with the new php_dom exension, which I think is
great, but not documented yet. So then comes a serialization problem:
objects in my project held reference to each other, and the
last-time-workin-good serialization crashed on this extra. Right now I
solved the problem by unbuilding theese references before
serialization, and rebuilding them on wakeup. Now I can test the ZE2
editions new features, thank you for the help!

Also, here is a sample script that doesn't work for me:

b = new b;
}

function setupb()
{
$this->b->setupa($this);
}
}

class b
{
var $a;

function setupa($a)
{
$this->a = $a;
}
}

$a = new a;
$a->setupb();
echo "This workx!\r\n";
echo serialize($a);

?>



[2003-06-30 04:18:01] hos dot endre at dorsum dot hu

I've tryed the test script I provided yesterday on WinNT, Apache
1.3.12, PHP 5.0.0b1 with php4_apache.dll (configured as php5_module in
httpd.conf). Works well. This bug might be XP specific, or it might be
my own system's special. By the way, the XP was configued to use
php4_apache_hooks.dll, becase php4_apache.dll were missing from one of
the downloaded PHP distributions. I'm willing to figure out what the
hell going on with that stuff. I'll be back with further results.



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

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

#26049 [Opn->Bgs]: Cannot connect to ODBC source (MyODBC)

[kalowsky]

 ID:   26049
 Updated by:   [EMAIL PROTECTED]
 Reported By:  miroslav dot sulc at startnet dot cz
-Status:   Open
+Status:   Bogus
 Bug Type: ODBC related
 Operating System: Linux (Gentoo)
 PHP Version:  4.3.3
 New Comment:

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

Thank you for your interest in PHP.

Please read how to configure your unixODBC system.  


Previous Comments:


[2003-10-31 05:00:28] miroslav dot sulc at startnet dot cz

Description:

I cannot connect with:
$var=odbc_connect('myodbc-test','root','password');
to my MyODBC data source.

Here is the error:
Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Can't
open lib '/usr/lib/libmyodbc3.so' : unknown error, SQL state IM003 in
SQLConnect in /home/httpd/bagr/docs/test.php on line 2

I would appreciate any help. Below is some more info.

isql command work fine:
echo "show tables;
> " | isql myodbc-test root password
+---+
| Connected!|
|   |
| sql-command   |
| help [tablename]  |
| quit  |
|   |
+---+
SQL>
+-+
| Tables_in_test  |
+-+
+-+
0 rows affected


Here is PHP configuration:
'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--without-readline' '--with-apxs2=/usr/sbin/apxs2' '--with-ndbm=/usr'
'--with-db4=/usr' '--with-mcrypt=/usr' '--with-mhash=/usr'
'--with-ming=/usr' '--with-swf=/usr' '--with-sybase=/usr'
'--with-gdbm=/usr' '--with-java=/opt/blackdown-jdk-1.4.1'
'--with-mcal=/usr' '--with-unixODBC=/usr' '--with-pgsql=/usr'
'--with-snmp=/usr' '--enable-ucd-snmp-hack' '--with-pdflib=/usr'
'--with-gd' '--enable-gd-native-ttf' '--with-png' '--with-png-dir=/usr'
'--with-jpeg' '--with-jpeg-dir=/usr' '--enable-exif' '--with-tiff'
'--with-tiff-dir=/usr' '--with-mysql=/usr'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-freetype-dir=/usr' '--with-ttf=/usr' '--with-t1lib=/usr'
'--with-gettext' '--without-qtdom' '--with-pspell=/usr'
'--with-openssl=/usr' '--with-imap=/usr' '--with-ldap=/usr'
'--with-dom=/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr'
'--with-kerberos=/usr' '--with-pam' '--disable-memory-limit'
'--disable-ipv6' '--with-curlwrappers' '--with-curl=/usr'
'--enable-dbx' '--with-imap-ssl' '--with-zlib' '--with-zlib-dir=/usr'
'--with-sablot=/usr' '--enable-xslt' '--with-xslt-sablot'
'--with-xmlrpc' '--enable-wddx' '--with-xml' '--enable-mbstring=all'
'--enable-mbregex' '--with-bz2=/usr' '--with-crack=/usr' '--with-cdb'
'--enable-bcmath' '--enable-calendar' '--enable-dbase'
'--enable-filepro' '--enable-ftp' '--with-mime-magic'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvipc' '--with-iconv' '--enable-shmop' '--enable-dio'
'--enable-inline-optimization' '--enable-track-vars'
'--enable-trans-sid' '--enable-versioning'
'--with-config-file-path=/etc/php/apache2-php4'

Here are versions:
unixODBC: 2.0.6
MyODBC: 3.51.06

/etc/unixODBC/odbc.ini:
[myodbc-test]
Description = MySQL ODBC myodbc-3.51.06 Driver Testing DSN
Driver  = /usr/lib/libmyodbc3.so
Socket  = /var/run/mysqld/mysqld.sock
Server  = localhost
User= root
Database= test
Option  = 3

/etc/unixODBC/odbcinst.ini:
[myodbc]
Description = MySQL ODBC Driver
Driver  = /usr/lib/libmyodbc3.so
FileUsage   = 1

File permissions:
ls -l /usr/lib/libmyodbc3*
-rwxr-xr-x1 root root   157984 Oct 30 10:28
/usr/lib/libmyodbc3-3.51.06.so
-rw-r--r--1 root root   175340 Oct 30 10:28
/usr/lib/libmyodbc3.a
-rwxr-xr-x1 root root  861 Oct 30 10:28
/usr/lib/libmyodbc3.la
lrwxrwxrwx1 root root   21 Oct 30 10:28
/usr/lib/libmyodbc3.so -> libmyodbc3-3.51.06.so

Apache runs as user apache and group apache.

php.ini diff against unpacked php.ini-dist from src distribution.
diff /etc/php/apache2-php4/php.ini php-4.3.3/php.ini-dist
428c428
< extension_dir = /usr/lib/php/extensions/no-debug-non-zts-20020429
---
> extension_dir = "./"
490,492c490
< ; allow_url_fopen = On
< ; Closed for security - <[EMAIL PROTECTED]>
< allow_url_fopen = Off
---
> allow_url_fopen = On
5

#25972 [Opn->Ver]: ODBC truncates multi-byte text (w/ MSSQL)

[kalowsky]

 ID:   25972
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpbug at chipple dot net
-Status:   Open
+Status:   Verified
 Bug Type: ODBC related
 Operating System: Win2K 5.00.2195 SP4
 PHP Version:  4.3.4RC2
 New Comment:

Is this really a bug?  The debate rages like so:

One the one hand ODBC does not support multi-byte 
characters at all.  On the other, the idea of multi-
byte characters didn't exist (or if it did, not very 
prevailent) at the time of the original authoring of 
the ODBC system.

Next question is, is there an easy fix.  Nope.  I've 
had a fix in the works, I've just lost all time to work 
upon it.  Marking as verified, but not really sure it's 
a bug.  Maybe a feature request really... 

Following the ODBCv2 specs, NVARCHAR is a type that 
doesn't exist, nor does TEXT, NTEXT, and many of the 
other wonderful types found today.  


Previous Comments:


[2003-10-24 00:10:01] phpbug at chipple dot net

Sorry here's the MSSQL extension code that should have been in the 2nd
part of "Reproduce code".

// MSSQL EXTENSION, data retrieved correctly

$oConn = mssql_connect("localhost",C_Gen_sDbUser,C_Gen_sDbPassword);
mssql_select_db("icds",$oConn);
$oRs = mssql_query("SELECT * FROM T_Course WHERE aCourseID=1");
$aRow = mssql_fetch_array($oRs);

// GOOD: Complete title retrieved (60 chars=120 bytes)
echo $aRow["tTitle"];

mssql_close($oConn);



[2003-10-23 23:26:31] phpbug at chipple dot net

Description:

This bug has been observed with PHP 4.3.3 and 4.3.4RC2.
Database: MSSQL 2000 (8.00.760) SP3

I have a MSSQL database with a table containing a column tTitle of type
nvarchar(80) (which stands for 80 multi-byte characters).

When a string of 60 Japanese double-byte characters (120 bytes) stored
in column tTitle is retrieved using PHP's ODBC extension, the value is
truncated to 80 bytes.

The PHP MSSQL extension retrieves the data correctly.
Microsoft's ODBC driver (used from ASP) retrieves the data correctly.


MSSQL table structure:

CREATE TABLE [dbo].[T_Course] (
  [aCourseID] [int] IDENTITY (1, 1) NOT NULL ,
  [tTitle] [nvarchar] (80) COLLATE Japanese_CI_AS NOT NULL
) ON [PRIMARY]
GO


Test data (CSV):
aCourseID,tTitle
1,[string of 60 Japanese double-byte characters]


SQL query:

SELECT * FROM T_Course WHERE aCourseID=1

Reproduce code:
---
// ODBC EXTENSION, data truncated

$oConn = odbc_connect(C_Gen_sDbDSN,C_Gen_sDbUser,C_Gen_sDbPassword);
$oRs = odbc_exec($oConn,"SELECT * FROM T_Course WHERE aCourseID=1");
$aRow = odbc_fetch_array($oRs);

// BAD: Title truncated to 80 _bytes_
echo $aRow["tTitle"];

odbc_close($oConn);


// MSSQL EXTENSION, data retrieved correctly

$oConn = odbc_connect(C_Gen_sDbDSN,C_Gen_sDbUser,C_Gen_sDbPassword);
$oRs = odbc_exec($oConn,"SELECT * FROM T_Course WHERE aCourseID=1");
$aRow = odbc_fetch_array($oRs);

// GOOD: Complete title retrieved (60 chars=120 bytes)
echo $aRow["tTitle"];

odbc_close($oConn);

Expected result:

The ODBC extension should truncate the retrieved data to 80 characters
(instead of 80 bytes).

Actual result:
--
The ODBC extension truncates the retrieved data to 80 bytes.





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

#26051 [Bgs->Opn]: filetype() returns wrong type for device drivers

[six at t0x dot net]

 ID:   26051
 User updated by:  six at t0x dot net
 Reported By:  six at t0x dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: win2k
 PHP Version:  4.3.4RC3
 New Comment:

There are specific win32 API calls (GetFileType comes to my mind) to
get this kind of information.

I don't think this should be classified as "Bogus" because this is a
very confusing behavior, at least, if you don't plan to fix the bug,
the documentation should be updated to clearly state that filetype()
does not work on Win32.


Previous Comments:


[2003-10-31 08:38:17] [EMAIL PROTECTED]

PHP returns whatever the libc stat() function returns for the filetype.
No bug.




[2003-10-31 06:06:43] six at t0x dot net

Description:

As the subject states, filetype() on windows (w2k at least) returns
wrong type for device drivers. Actually, it seems to always return the
type "file".



Reproduce code:
---


Expected result:

type : char

Actual result:
--
type : file





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

#26056 [NEW]: Warnings while compiling exif.c

[AxelLuttgens at swing dot be]

From: AxelLuttgens at swing dot be
Operating system: Darwin 7.0.0 (Panther)
PHP version:  4.3.3
PHP Bug Type: Compile Warning
Bug description:  Warnings while compiling exif.c

Description:

When compiling PHP, I get two warnings related to lines 1555 and 1582 of
exif.c; both warnings read:

warning: passing arg 3 of `php_addslashes' from incompatible pointer type

Function php_addslashes gets called 4 times in file ext/exif/exif.c (/*
$Id: exif.c,v 1.118.2.23 2003/06/25 13:21:54 edink Exp $ */).

In function exif_iif_add_value, where argument 'length' is of type
size_t:
   line 1555: info_value->s = php_addslashes(value, length, &length, 0
TSRMLS_CC);
   line 1582: info_value->s = php_addslashes(value, length, &length, 0
TSRMLS_CC);

In function exif_iif_add_str:
line 1708: info_data->value.s = php_addslashes(value, strlen(value),
NULL, 0 TSRMLS_CC);

In function exif_iif_add_buffer, where argument 'length' is of type int:
line 1756: info_data->value.s = php_addslashes(value, length, &length,
0 TSRMLS_CC);

In ext/standard/string.c, definition of php_addsclashes reads as:

PHPAPI char *php_addslashes(char *str, int length, int *new_length, int
should_free TSRMLS_DC)
{
   ...
}

which is consistent with what appears in ext/standard/php_string.h:

PHPAPI char *php_addslashes(char *str, int length, int *new_length, int
freeit TSRMLS_DC);

Clearly, line 1708 is a don't care, and line 1756 is just compliant with
the definition of php_addslashes.
But lines 1555 and 1582 both use a length of type size_t instead of type
int.

I am wondering what the compiler really compiles (as it just warns and
goes on).
Could this be a source of confusion (such as an unsigned long being
interpreted as a signed one)?

And would it be safe to just change the definition of function
exif_iif_add_value so as to set type of argument 'lentgh' to int instead
of size_t?


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

#26056 [Opn->Csd]: Warnings while compiling exif.c

[sniper]

 ID:   26056
 Updated by:   [EMAIL PROTECTED]
 Reported By:  AxelLuttgens at swing dot be
-Status:   Open
+Status:   Closed
 Bug Type: Compile Warning
 Operating System: Darwin 7.0.0 (Panther)
 PHP Version:  4.3.3
 New Comment:

This bug has been fixed in CVS.

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

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


Previous Comments:


[2003-10-31 09:27:39] AxelLuttgens at swing dot be

Description:

When compiling PHP, I get two warnings related to lines 1555 and 1582
of exif.c; both warnings read:

warning: passing arg 3 of `php_addslashes' from incompatible pointer
type

Function php_addslashes gets called 4 times in file ext/exif/exif.c (/*
$Id: exif.c,v 1.118.2.23 2003/06/25 13:21:54 edink Exp $ */).

In function exif_iif_add_value, where argument 'length' is of type
size_t:
   line 1555: info_value->s = php_addslashes(value, length, &length, 0
TSRMLS_CC);
   line 1582: info_value->s = php_addslashes(value, length, &length, 0
TSRMLS_CC);

In function exif_iif_add_str:
line 1708: info_data->value.s = php_addslashes(value,
strlen(value), NULL, 0 TSRMLS_CC);

In function exif_iif_add_buffer, where argument 'length' is of type
int:
line 1756: info_data->value.s = php_addslashes(value, length,
&length, 0 TSRMLS_CC);

In ext/standard/string.c, definition of php_addsclashes reads as:

PHPAPI char *php_addslashes(char *str, int length, int *new_length, int
should_free TSRMLS_DC)
{
   ...
}

which is consistent with what appears in ext/standard/php_string.h:

PHPAPI char *php_addslashes(char *str, int length, int *new_length, int
freeit TSRMLS_DC);

Clearly, line 1708 is a don't care, and line 1756 is just compliant
with the definition of php_addslashes.
But lines 1555 and 1582 both use a length of type size_t instead of
type int.

I am wondering what the compiler really compiles (as it just warns and
goes on).
Could this be a source of confusion (such as an unsigned long being
interpreted as a signed one)?

And would it be safe to just change the definition of function
exif_iif_add_value so as to set type of argument 'lentgh' to int
instead of size_t?






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

#25958 [Opn->Fbk]: odbc_connect fails to login to remote Dbase 5

[kalowsky]

 ID:   25958
 Updated by:   [EMAIL PROTECTED]
 Reported By:  brian dot garvis at mascommsys dot com
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Windows 2003 Server
 PHP Version:  4.3.2
 New Comment:

If you cannot give me a trace of the SQL connection, I 
cannot help you.  


Previous Comments:


[2003-10-30 18:49:38] brian dot garvis at mascommsys dot com

After working on this for the past week with anyone and everyone we
could find to help out, we are still where we started.  

We have verified that MS ODBC works fine to database on local machine. 
We have tried to connect to different databases on different remote
machines using both php and MS Query.  MS Query has no problem
accessing remote DBase & Access databases using the same DSN's that PHP
is using.  PHP to the same remote databases always returns the same
errors with a "null" "Resource ID #".



[2003-10-23 14:34:06] brian dot garvis at mascommsys dot com

Turning on Machine-Wide tracing using odbctrac.dll in ODBC Data Source
Administrator and reproducing the problem does not create any entries
in the SQL.LOG.  I did make the user "Administrator" invalid for the
shared drive and the SQL.LOG file filled quickly with errors.  Errors
stopped when I added the "Administrator" user back on the shared
drive.

>From my ODBC Data Source Administrator, System DSN, System Data
Sources:
Name: DEMOSASI
Driver: Microsoft dBase Driver (*.dbf)

>From the ODBC dBASE Setup for DSN DEMOSASI:
Data Source Name: DEMOSASI
Database VErsion: dBase 5.0
Directory: Z:\ (mapped shared folder where DB resides on another
machine)
Driver:
  Collating Sequence: ASCII
  Page Timeout: 5



[2003-10-22 19:42:18] [EMAIL PROTECTED]

Please include your DSN entry, and a SQL Log for the connection attempt
if you can.  From the sounds of it, you're not configured properly on
the ODBC Administrator end, and thus not a PHP bug. 



[2003-10-22 18:19:57] brian dot garvis at mascommsys dot com

Description:

odbc_connect fails to connect to a Dbase 5 database which resides on a
separate Windows 2000 machine using Microsoft ODBC Data Source
Administrator.  If move database to local machine and point ODBC to
local database, then works.

PHP reports error: 
Warning: SQL error: [Microsoft][ODBC dBase Driver] '(unknown)' is not a
valid path. Make sure that the path name is spelled correctly and that
you are connected to the server on which the file resides., SQL state
S1009 in SQLConnect in C:\DEMO\wwwroot\login.php on line 16



Reproduce code:
---
http://bugs.php.net/?id=25958&edit=1

#26051 [Opn->Bgs]: filetype() returns wrong type for device drivers

[sniper]

 ID:   26051
 Updated by:   [EMAIL PROTECTED]
 Reported By:  six at t0x dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: win2k
 PHP Version:  4.3.4RC3
 New Comment:

filetype() does work just fine on windows. 
If windows returns 'wrong' types, it's not bug in PHP..



Previous Comments:


[2003-10-31 09:27:18] six at t0x dot net

There are specific win32 API calls (GetFileType comes to my mind) to
get this kind of information.

I don't think this should be classified as "Bogus" because this is a
very confusing behavior, at least, if you don't plan to fix the bug,
the documentation should be updated to clearly state that filetype()
does not work on Win32.



[2003-10-31 08:38:17] [EMAIL PROTECTED]

PHP returns whatever the libc stat() function returns for the filetype.
No bug.




[2003-10-31 06:06:43] six at t0x dot net

Description:

As the subject states, filetype() on windows (w2k at least) returns
wrong type for device drivers. Actually, it seems to always return the
type "file".



Reproduce code:
---


Expected result:

type : char

Actual result:
--
type : file





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

#25757 [Opn->Fbk]: odbc_primarykeys error

[kalowsky]

 ID:   25757
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dlaroche at nobug dot lu
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Windows XP Professional
 PHP Version:  4.3.3
 New Comment:

Try using a NULL value instead of "" for the empty 
slots.  That should solve the problem you're seeing.  


Previous Comments:


[2003-10-05 17:12:12] dlaroche at nobug dot lu

Description:

I'm trying to write a script to convert tables from a Microsoft Access
(version from 97 to 2002) to MySQL. The first step is that I just want
the structure of the tables, so I need several functions from odbc.

But for the primary keys, the function odbc_primarykeys doesn't work.

I read that I can get the key information of a table using the
odbc_statistics function but this function doesn't work aswell.

Reproduce code:
---
$resAccessPrimaryKeyList = odbc_primarykeys($resAccessConnection, "",
"", "tblManif");
echo(odbc_result_all($resAccessPrimaryKeyList));

Expected result:

don't know the result but I want to get a list with the primary keys of
the table.

Actual result:
--
Warning:  odbc_primarykeys(): SQL error: , SQL state 0 in
SQLPrimaryKeys in E:\htdocs\ltam\odbc.php on line 65

Warning:  odbc_result_all(): supplied argument is not a valid ODBC
result resource in E:\htdocs\ltam\odbc.php on line 66





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

#26005 [Fbk->Opn]: Random "cannot change the session's ini settings" errors

[parsnip11 at hotmail dot com]

 ID:   26005
 User updated by:  parsnip11 at hotmail dot com
 Reported By:  parsnip11 at hotmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: windows 2000 iis 5
 PHP Version:  4.3.3
 New Comment:

I have updated to the latest version of php and have also added and
session_write_close() before all of my "exit" statements as some people
have mentioned this helped.

No go... Just checked the logs this morning and this error has popped
up again


Previous Comments:


[2003-10-28 18:13:28] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





[2003-10-27 10:52:27] parsnip11 at hotmail dot com

Description:

I am recently upgraded to php 4.3.3 from 4.2.9 and am using the
php4isapi.dll on iis. My application has been working w/o any problems
for quite awhile and after the upgrade, without rhyme or reason I am
getting the following error every few days:

PHP Warning:  Unknown(): A session is active. You cannot change the
session module's ini settings at this time. in Unknown on line 0

I have no ini_set statement in my application and have even set my
php.ini to read only in the event that it was somehow being modified.
My application is EXTREMELY simple... it's basically just consists of a
few html forms submitting to a sql db. Authentication happens via IIS
and I'm using $AUTH_USER to get the user id. 

Since this error is extremely intermittent and only happens 2 or 3
times a week, I cant seem to figure out what line seems or even what
function is causing this error. I know that bugs cannot be solved w/o a
code example that generates the error but I canAll I know is that the
version of PHP is all that's changed so I'm inclined to think it's a
bug.

Php.ini is set up as follows:

session.save_handler = files
session.save_path = C:\PHP\sessiondata; argument passed to
save_handler
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_maxlifetime = 50400
session.referer_check =
session.entropy_length = 
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = 
;session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 1


Reproduce code:
---
As stated above, I'm really not sure WHAT is causing this error. No
filename is mentioned in the error. My login.php included in every page
is pretty simple:

session_start(); 

if(!isset($logged_in) || $logged_in != "!authenticated!") {
header("Location: http://myurl.com";);
exit;  
} else {
$user_id= str_replace("windows_domain", "",
strtolower($AUTH_USER));
}


Actual result:
--
Generic 500 error page in IE for the user... On one occasion when this
happened I had to restart IIS before PHP would work again





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

#24718 [Asn->Fbk]: odbc_result_all crashes on some results

[kalowsky]

 ID:   24718
 Updated by:   [EMAIL PROTECTED]
 Reported By:  psychosos at gmx dot at
-Status:   Assigned
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: Windows 2000 Professional
 PHP Version:  4.3.2
 Assigned To:  kalowsky
 New Comment:

You are correct that a LONGCHAR is not supported, 
although I haven't a clue what that would actually be.  
A CHAR, VARCHAR, VARBINARY, LONGVARBINARY would all be 
valid substitutions though.

Can you try changing that and see if this solves your 
problem?


Previous Comments:


[2003-07-28 07:14:47] psychosos at gmx dot at

Hello,

Here is a more exact schema of the table called Kommentare, created
with odbc_columns:

TABLE.COLUMN/DATA_TYPE/TYPE_NAME/COLUMN_SIZE
Kommentare.ID/4/INTEGER/10
Kommentare.Kommentar/-1/LONGCHAR/1073741823
Kommentare.Kommentator/12/VARCHAR/50
Kommentare.Datum/11/DATETIME/19
Kommentare.IP/12/VARCHAR/15

So actually column Kommentator it is a VARCHAR, not a Text as I said
before. (That's just how the German version of MS Access likes to call
it.) I have to admit I am not sure whether LONGCHAR is supported
though. Could this be the problem?

You can get the zipped SQLLog for the query "SELECT Kommentar FROM
Kommentare" at http://forum.geizhals.at/files/641/SQL.ZIP (around 4KB).
I hope it helps.



[2003-07-27 23:38:26] [EMAIL PROTECTED]

Well the start is that type TEXT isn't really supported by ODBC v2
(which is what PHP uses).  If you can change to a type VARCHAR that
would work much better (I can't remember if Access cares about this or
not).  

But for further debugging information, if you can turn on SQLLogging
(under your ODBC Administrator) create the connection, run one of the
queries that crashes everything, and post the results here that would
help.  You might need/want to ensure the removal of the site specific
information (i.e. login and password) before you post it here though.



[2003-07-24 16:17:10] psychosos at gmx dot at

Sorry about the delay.

The database I am experiencing the problem with is an Microsoft Access
Database I created with MS Access XP.

The problematic table has the following schema:
Table Kommentare
  ID long integer DEFAULT 0 NOT NULL
  Kommentar Memo NOT NULL
  Kommentator Text (50) 
  Datum Date/Time (standard date)
  IP Text(15)
(sorry about non-SQL conformity; I tried to transcribe the MS Access
information)


"SELECT * FROM Kommentare" crashes PHP.
"SELECT ID, Kommentator, Datum, IP FROM Kommentare" works fine.
"SELECT Kommentar FROM Kommentare" crashes PHP.
"SELECT TOP 200 Kommentar FROM Kommentare" works fine as well.
But "SELECT Kommentar FROM Kommentare" crashes PHP.

If needed/helpful I might try to determine the exact number of records
(bytes) which crashes PHP.
Unfortunately I am not experienced debugging applications.

If I can be of any further help I'd be glad to follow your instructions
:-)

Cheers,
johannes



[2003-07-19 17:30:10] [EMAIL PROTECTED]

A sample schema would help tremendiously.  Also what database?



[2003-07-19 13:35:58] psychosos at gmx dot at

Description:

If I use odbc_result_all() with a result which has around 75 rows or
more it crashes with an Application Error (The instruction at
"0x1000ede5" referenced memory at "0x00ae". The memory could not be
"read".

Unfortunately this only happens to me with one table and only if I
retrieve longer fields (for example it only crashes when trying to
retrieve a longer character field, not with my ID or a short string
field)

(I am sorry about this unexact bug report. If you can give me any hints
how to be more helpful - please do so!)

Reproduce code:
---


Expected result:

The code should output all the fields from the table named
"Kommentare".

Actual result:
--
PHP crashes with an Application Error (The instruction at "0x1000ede5"
referenced memory at "0x00ae". The memory could not be "read".)





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

#26051 [Bgs]: filetype() returns wrong type for device drivers

[six at t0x dot net]

 ID:   26051
 User updated by:  six at t0x dot net
 Reported By:  six at t0x dot net
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: win2k
 PHP Version:  4.3.4RC3
 New Comment:

You seem to assume that the runtime c library is 100% compatible with
the unix ones ...

It's not that windows returns wrong types, just that windows provides
*another way* to get the file type (the GetFileType API call).

And no, filetype() doesn't work on windows ... At least as it's
described in the documentation that says "Returns the type of the file"
and not "Wrapper for the stat() libc call".

This is an important problem, because it's currently impossible to
protect an app from potential security issues regarding access to
critical device files on win32 (like CON, PRN, CLOCK$, ...). A PHP app
running on windows, receiving a file name from an untrusted input has
*no way* to tell what the file really is.


Previous Comments:


[2003-10-31 09:39:31] [EMAIL PROTECTED]

filetype() does work just fine on windows. 
If windows returns 'wrong' types, it's not bug in PHP..




[2003-10-31 09:27:18] six at t0x dot net

There are specific win32 API calls (GetFileType comes to my mind) to
get this kind of information.

I don't think this should be classified as "Bogus" because this is a
very confusing behavior, at least, if you don't plan to fix the bug,
the documentation should be updated to clearly state that filetype()
does not work on Win32.



[2003-10-31 08:38:17] [EMAIL PROTECTED]

PHP returns whatever the libc stat() function returns for the filetype.
No bug.




[2003-10-31 06:06:43] six at t0x dot net

Description:

As the subject states, filetype() on windows (w2k at least) returns
wrong type for device drivers. Actually, it seems to always return the
type "file".



Reproduce code:
---


Expected result:

type : char

Actual result:
--
type : file





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

#26057 [NEW]: domxml_xmltree leaks

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.3.3
PHP Bug Type: DOM XML related
Bug description:  domxml_xmltree leaks

Description:

domxml_xmltree seams to have a memory leak at least with libxml 2.5.11

Reproduce code:
---
php -r "while(1) xmltree('');"

Actual result:
--
process crashes because of exceeded memory limit

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

#26051 [Bgs->Opn]: filetype() returns wrong type for device drivers

[six at t0x dot net]

 ID:   26051
 User updated by:  six at t0x dot net
 Reported By:  six at t0x dot net
-Status:   Bogus
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: win2k
 PHP Version:  4.3.4RC3
 New Comment:

Please consider the security problem stated above before definetly
denying this is a bug


Previous Comments:


[2003-10-31 10:01:30] six at t0x dot net

You seem to assume that the runtime c library is 100% compatible with
the unix ones ...

It's not that windows returns wrong types, just that windows provides
*another way* to get the file type (the GetFileType API call).

And no, filetype() doesn't work on windows ... At least as it's
described in the documentation that says "Returns the type of the file"
and not "Wrapper for the stat() libc call".

This is an important problem, because it's currently impossible to
protect an app from potential security issues regarding access to
critical device files on win32 (like CON, PRN, CLOCK$, ...). A PHP app
running on windows, receiving a file name from an untrusted input has
*no way* to tell what the file really is.



[2003-10-31 09:39:31] [EMAIL PROTECTED]

filetype() does work just fine on windows. 
If windows returns 'wrong' types, it's not bug in PHP..




[2003-10-31 09:27:18] six at t0x dot net

There are specific win32 API calls (GetFileType comes to my mind) to
get this kind of information.

I don't think this should be classified as "Bogus" because this is a
very confusing behavior, at least, if you don't plan to fix the bug,
the documentation should be updated to clearly state that filetype()
does not work on Win32.



[2003-10-31 08:38:17] [EMAIL PROTECTED]

PHP returns whatever the libc stat() function returns for the filetype.
No bug.




[2003-10-31 06:06:43] six at t0x dot net

Description:

As the subject states, filetype() on windows (w2k at least) returns
wrong type for device drivers. Actually, it seems to always return the
type "file".



Reproduce code:
---


Expected result:

type : char

Actual result:
--
type : file





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

#26043 [Fbk->Opn]: pg_lo_import causes crash under all circumstances

[dqj at requesttech dot com]

 ID:   26043
 User updated by:  dqj at requesttech dot com
 Reported By:  dqj at requesttech dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PostgreSQL related
 Operating System: Redhat 9.0
 PHP Version:  4.3.3
 New Comment:

Using the latest snapshot tarball is not easy for us since our platform
is based on RPM installs. I spent a couple of hours this morning trying
to get the right configure commands working so we could rebuild PHP to
work with Postgres 7.3.4 and Apache 2.0, but could not get it to work. 
(I may not have the right "devel" packages around for Apache and
Postgres.)

Is there any other way to look into the bug without having to recompile
PHP to upgrade our system just to find out if the bug has "gone away"?

Thank you in advance for your help.


Previous Comments:


[2003-10-30 20:30:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Try the snapshot first, please.




[2003-10-30 14:32:24] dqj at requesttech dot com

Forgot to mention that the Postgres version is 7.3.4.



[2003-10-30 14:26:13] dqj at requesttech dot com

I was wrong about there not being anything in the logs.  In the httpd
error_log, there was the following:

[Thu Oct 30 14:25:10 2003] [notice] child pid 16877 exit signal
Segmentation fault (11)

This occurs whenever a valid filename is given to pg_lo_import.



[2003-10-30 13:48:23] dqj at requesttech dot com

Description:

No changes to php.ini distribution.  No output shown in logs.  Just
doesn't finish the page.  (I have put echoes and breaks in to narrow it
to the pg_lo_import() call).  We have checked file permissions, etc. 
This code has worked under PHP 4.2 and other versions.  Have tried
switching the pg_lo_import parameters back and forth, just in case, as
described in the bug documentation.



Reproduce code:
---
"; flush();
?>


Expected result:

$oid should have a value. Echoed results should appear.


Actual result:
--
Blank page.  (Or echoed results prior to subroutine call, if debug is
included.)






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

#26058 [NEW]: Could not link binary

[efrangul at mac dot com]

From: efrangul at mac dot com
Operating system: Mac OS X 10.2.8
PHP version:  5CVS-2003-10-31 (dev)
PHP Bug Type: Compile Failure
Bug description:  Could not link binary

Description:

I can not link the executable.

Version used:

apache-2.0.48
mysql-standard-4.1.0-alpha
gd-2.0.15
libxml2-2.6.1
libxslt-1.0.33
oracle-9.2.0.1.0
Java-1.4.1

Reproduce code:
---
./configure --prefix=/usr/local --with-apxs2=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --with-gd=/usr/local/gd --with-openssl=/usr
--with-simplexml --with-libxml-dir=/usr/local/xml --enable-exif
--enable-ftp --enable-sockets --with-sysvshm --with-sysvsem
--enable-safe-mode --enable-track-vars --enable-magic-quotes
--enable-bcmath --enable-memory-limit=yes --with-kerberos=/usr --with-yp
--enable-wddx --enable-shmop --enable-trans-sid --with-tsrm-pthreads
--enable-calendar --with-zlib
--with-java=/System/Library/Frameworks/JavaVM.framework/Home --with-oracle
--with-freetype-dir=/usr/local/lib --with-iconv=/usr/local

Expected result:

php binary created.

Actual result:
--
gcc -bundle -bundle_loader /usr/local/apache-2.0.48/
bin/httpd -L/usr/local/lib -L/usr/local/apache-2.0.48/
lib -laprutil-0 -lexpat -L/usr/local/apache-2.0.48/lib 
-lapr-0 -g -O2   -L/usr/local/xml2/lib -L/usr/local/lib 
-L/usr/local/gd/lib -L/usr/local/mysql/lib -L/oracle/
9.2.0.1.0/lib ext/openssl/openssl.o ext/openssl/
xp_ssl.o ext/zlib/zlib.o ext/zlib/zlib_fopen_wrapper.o 
ext/bcmath/bcmath.o ext/bcmath/libbcmath/src/add.o ext/
bcmath/libbcmath/src/div.o ext/bcmath/libbcmath/src/
init.o ext/bcmath/libbcmath/src/neg.o ext/bcmath/
libbcmath/src/outofmem.o ext/bcmath/libbcmath/src/
raisemod.o ext/bcmath/libbcmath/src/rt.o ext/bcmath/
libbcmath/src/sub.o ext/bcmath/libbcmath/src/compare.o 
ext/bcmath/libbcmath/src/divmod.o ext/bcmath/libbcmath/
src/int2num.o ext/bcmath/libbcmath/src/num2long.o ext/
bcmath/libbcmath/src/output.o ext/bcmath/libbcmath/src/
recmul.o ext/bcmath/libbcmath/src/sqrt.o ext/bcmath/
libbcmath/src/zero.o ext/bcmath/libbcmath/src/debug.o 
ext/bcmath/libbcmath/src/doaddsub.o ext/bcmath/
libbcmath/src/nearzero.o ext/bcmath/libbcmath/src/
num2str.o ext/bcmath/libbcmath/src/raise.o ext/bcmath/
libbcmath/src/rmzero.o ext/bcmath/libbcmath/src/
str2num.o ext/calendar/calendar.o ext/calendar/dow.o 
ext/calendar/french.o ext/calendar/gregor.o ext/
calendar/jewish.o ext/calendar/julian.o ext/calendar/
easter.o ext/calendar/cal_unix.o ext/ctype/ctype.o ext/
dom/php_dom.o ext/dom/attr.o ext/dom/document.o ext/
dom/domerrorhandler.o ext/dom/domstringlist.o ext/dom/
domexception.o ext/dom/namelist.o ext/dom/
processinginstruction.o ext/dom/cdatasection.o ext/dom/
documentfragment.o ext/dom/domimplementation.o ext/dom/
element.o ext/dom/node.o ext/dom/string_extend.o ext/
dom/characterdata.o ext/dom/documenttype.o ext/dom/
domimplementationlist.o ext/dom/entity.o ext/dom/
nodelist.o ext/dom/text.o ext/dom/comment.o ext/dom/
domconfiguration.o ext/dom/domimplementationsource.o 
ext/dom/entityreference.o ext/dom/notation.o ext/dom/
xpath.o ext/dom/typeinfo.o ext/dom/domerror.o ext/dom/
domlocator.o ext/dom/namednodemap.o ext/dom/
userdatahandler.o ext/exif/exif.o ext/ftp/php_ftp.o 
ext/ftp/ftp.o ext/gd/gd.o ext/gd/gdttf.o ext/gd/
gdcache.o ext/iconv/iconv.o ext/libxml/libxml.o ext/
mysql/php_mysql.o ext/oracle/oracle.o ext/pcre/pcrelib/
maketables.o ext/pcre/pcrelib/get.o ext/pcre/pcrelib/
study.o ext/pcre/pcrelib/pcre.o ext/pcre/php_pcre.o 
ext/posix/posix.o ext/session/session.o ext/session/
mod_files.o ext/session/mod_mm.o ext/session/mod_user.o 
ext/shmop/shmop.o ext/simplexml/simplexml.o ext/
sockets/sockets.o ext/sqlite/sqlite.o ext/sqlite/
sess_sqlite.o ext/sqlite/libsqlite/src/opcodes.o ext/
sqlite/libsqlite/src/parse.o ext/sqlite/libsqlite/src/
encode.o ext/sqlite/libsqlite/src/auth.o ext/sqlite/
libsqlite/src/btree.o ext/sqlite/libsqlite/src/build.o 
ext/sqlite/libsqlite/src/delete.o ext/sqlite/libsqlite/
src/expr.o ext/sqlite/libsqlite/src/func.o ext/sqlite/
libsqlite/src/hash.o ext/sqlite/libsqlite/src/insert.o 
ext/sqlite/libsqlite/src/main.o ext/sqlite/libsqlite/
src/os.o ext/sqlite/libsqlite/src/pager.o ext/sqlite/
libsqlite/src/printf.o ext/sqlite/libsqlite/src/
random.o ext/sqlite/libsqlite/src/select.o ext/sqlite/
libsqlite/src/table.o ext/sqlite/libsqlite/src/
tokenize.o ext/sqlite/libsqlite/src/update.o ext/
sqlite/libsqlite/src/util.o ext/sqlite/libsqlite/src/
vdbe.o ext/sqlite/libsqlite/src/attach.o ext/sqlite/
libsqlite/src/btree_rb.o ext/sqlite/libsqlite/src/
pragma.o ext/sqlite/libsqlite/src/vacuum.o ext/sqlite/
libsqlite/src/copy.o ext/sqlite/libsqlite/src/where.o 
ext/sqlite/libsqlite/src/trigger.o regex/regcomp.o 
regex/regexec.o regex/regerror.o regex/regfree.o ext/
standard/array.o ext/standard/base64.o ext/standard/
basic_functions.o ext/standard/browscap.o ext/standard/
crc32.o ext/standard/crypt.o ext/standard/cyr_convert.o 
ext/standard/datetime.o ext/standard/di

#26049 [Bgs]: Cannot connect to ODBC source (MyODBC)

[miroslav dot sulc at startnet dot cz]

 ID:   26049
 User updated by:  miroslav dot sulc at startnet dot cz
 Reported By:  miroslav dot sulc at startnet dot cz
 Status:   Bogus
 Bug Type: ODBC related
 Operating System: Linux (Gentoo)
 PHP Version:  4.3.3
 New Comment:

Does it mean that it is sure that this behaviour is caused by
misconfiguration and not by PHP bug? Do you know what problem I am
dealing with and what is the solution? I have been looking for an
answer to my problem for several hours and found nothing usefull.


Previous Comments:


[2003-10-31 09:22:22] [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.

Please read how to configure your unixODBC system.  



[2003-10-31 05:00:28] miroslav dot sulc at startnet dot cz

Description:

I cannot connect with:
$var=odbc_connect('myodbc-test','root','password');
to my MyODBC data source.

Here is the error:
Warning: odbc_connect(): SQL error: [unixODBC][Driver Manager]Can't
open lib '/usr/lib/libmyodbc3.so' : unknown error, SQL state IM003 in
SQLConnect in /home/httpd/bagr/docs/test.php on line 2

I would appreciate any help. Below is some more info.

isql command work fine:
echo "show tables;
> " | isql myodbc-test root password
+---+
| Connected!|
|   |
| sql-command   |
| help [tablename]  |
| quit  |
|   |
+---+
SQL>
+-+
| Tables_in_test  |
+-+
+-+
0 rows affected


Here is PHP configuration:
'./configure' '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--without-readline' '--with-apxs2=/usr/sbin/apxs2' '--with-ndbm=/usr'
'--with-db4=/usr' '--with-mcrypt=/usr' '--with-mhash=/usr'
'--with-ming=/usr' '--with-swf=/usr' '--with-sybase=/usr'
'--with-gdbm=/usr' '--with-java=/opt/blackdown-jdk-1.4.1'
'--with-mcal=/usr' '--with-unixODBC=/usr' '--with-pgsql=/usr'
'--with-snmp=/usr' '--enable-ucd-snmp-hack' '--with-pdflib=/usr'
'--with-gd' '--enable-gd-native-ttf' '--with-png' '--with-png-dir=/usr'
'--with-jpeg' '--with-jpeg-dir=/usr' '--enable-exif' '--with-tiff'
'--with-tiff-dir=/usr' '--with-mysql=/usr'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-freetype-dir=/usr' '--with-ttf=/usr' '--with-t1lib=/usr'
'--with-gettext' '--without-qtdom' '--with-pspell=/usr'
'--with-openssl=/usr' '--with-imap=/usr' '--with-ldap=/usr'
'--with-dom=/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr'
'--with-kerberos=/usr' '--with-pam' '--disable-memory-limit'
'--disable-ipv6' '--with-curlwrappers' '--with-curl=/usr'
'--enable-dbx' '--with-imap-ssl' '--with-zlib' '--with-zlib-dir=/usr'
'--with-sablot=/usr' '--enable-xslt' '--with-xslt-sablot'
'--with-xmlrpc' '--enable-wddx' '--with-xml' '--enable-mbstring=all'
'--enable-mbregex' '--with-bz2=/usr' '--with-crack=/usr' '--with-cdb'
'--enable-bcmath' '--enable-calendar' '--enable-dbase'
'--enable-filepro' '--enable-ftp' '--with-mime-magic'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-sysvipc' '--with-iconv' '--enable-shmop' '--enable-dio'
'--enable-inline-optimization' '--enable-track-vars'
'--enable-trans-sid' '--enable-versioning'
'--with-config-file-path=/etc/php/apache2-php4'

Here are versions:
unixODBC: 2.0.6
MyODBC: 3.51.06

/etc/unixODBC/odbc.ini:
[myodbc-test]
Description = MySQL ODBC myodbc-3.51.06 Driver Testing DSN
Driver  = /usr/lib/libmyodbc3.so
Socket  = /var/run/mysqld/mysqld.sock
Server  = localhost
User= root
Database= test
Option  = 3

/etc/unixODBC/odbcinst.ini:
[myodbc]
Description = MySQL ODBC Driver
Driver  = /usr/lib/libmyodbc3.so
FileUsage   = 1

File permissions:
ls -l /usr/lib/libmyodbc3*
-rwxr-xr-x1 root root   157984 Oct 30 10:28
/usr/lib/libmyodbc3-3.51.06.so
-rw-r--r--1 root root   175340 Oct 30 10:28
/usr/lib/libmyodbc3.a
-rwxr-xr-x1 root root  861 Oct 30 10:28
/usr/lib/libmyodbc3.la
lrwxrwxrwx1 root root   21 Oct 30 10:28
/usr/lib/libmyodbc3.so -> libmyodbc3-3.51.06.so

Apache runs as user apache and group

#22108 [Asn]: php doesn't ignore the utf-8 BOM

[fujimoto]

 ID:   22108
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bugzilla at jellycan dot com
 Status:   Assigned
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  *
 Assigned To:  moriyoshi
 New Comment:

I added i18n support to Zend Engine 2 (though it's still partial
one...), and one of its features contain awareness of BOM. So now you
can gracefully parse scripts with BOM if you use PHP 5.0.0b2 and
configure it with the option '--enable-zend-multibyte'.

These features are still experimental and under testing, so that I have
not been documented these but I'll add the entry to the manual,
ZEND_CHANGES and so on if I feel certain of the stability and
robustness of my patch, though I do not know when it is:)

Anyway, I'll close this bug if '--enable-zend-multibyte' option in PHP
5.0.0b2 is assured to work well for this problem. Comments are welcome.


Previous Comments:


[2003-10-27 09:24:21] kamor at worldonline dot fr

New and better solution in order to include some UTF-8 files without
including BOM chars. In fact previous solution works well with IE and
Mozilla but XHTML validation fails.

Well, the following solution is not the best but with some restrictions
in the code organisation gives good results:

Solution:
Insert 'ob_start()' before include() commands and 'ob_end_clean()'
after. This will clear all direct outputs produced by inclusions.

example:


This works well for pure function/class libraries.

Other solutions may be explored with other output buffer functions
(ob_*).



[2003-05-05 03:40:23] tokiee at sayclub dot com

for who are not familiar with UTF-8:

UTF-8(UCS Transformation Format 8) is not different to ASCII. it's
compatible with the ASCII: if you write your text in english with
UTF-8. you dont see any difference between the text in ASCII in each
byte. (and UTF-8 BOM is optional).

it's not quite a exact explanation of UTF-8 but: UTF-8 expands ASCII to
support Full UNICODE characters without disurbing any existing alphabet
order or something. so basically the UTF-8 is ASCII. and you dont have
to imagine it as totally new freak.

actually, when a modern Unicode-supported OS reads this UTF-8, the OS
needs to CONVERT it to real UNICODE internally. so the UTF-8 is rather
similar with URL encoding.

in ASCII world, each byte corresponds a character, up to 255
characters.

in UNICODE, two bytes corresponds a character, up to 65535 characters.
and it's totally a new system as you think.

in UTF-8, it's interesting, a character can be one byte, or two bytes,
or even 3, 4 bytes!. why is that so complicated but the rule is simple
and actually you dont have to handle this: OS will do it for you. 

even if you have any software which does not understand the utf-8, it's
totally okay because it's ASCII transparent. so it "can be used with
normal string comparison functions for sorting and such." (quoted in
PHP.NET Reference: utf8_encode())



[2003-04-06 00:53:04] tronxoe at hotpop dot com

The BOM is still fine when the php file does not include another
Unicode file (by using @include()).

Another problem: If a php file is saved in unicode,  session and
cookies can not be used because "headers already sent ...". I think the
first 3 bytes has been sent in this case



[2003-02-08 06:10:51] [EMAIL PROTECTED]

Ok, the UTF-8 BOM was new to me.
If i find the time i'll have a look at it over the weekend.
I think the solution would be somewhere in zend's multibyte support
since i fear adding that bom to mbstring
alone does not do the trick.



[2003-02-07 23:13:07] bugzilla at jellycan dot com

The BOM (byte order mark) is a few bytes at the very front of a file
that act as a signature denoting what type of encoding has been used,
and in UTF16/32 it also makes the byte order (LE or BE). Although utf-8
is byte order independent, it has become popular on windows (perhaps
not so on unix) to make use of the BOM encoded in UTF-8 to flag the
file as being in UTF-8 format. This allows editors to determine the
type of the file from the first few characters instead of trying to
guess what type the file is. Ref: Textpad 4.6 (http://textpad.com)

See the Unicode FAQ for details of the utf-8 BOM...
http://www.unicode.org/unicode/faq/utf_bom.html#25

The use of this should be obvious, you have to leave the
my-language-only mindset that afflicts too many programmers (myself
included before this job) and think about the growing multiplicity of
languages on the web. I am writing web applications in Japan, with
European language and CJK (Chinese/Japanese/Korean) language processing
and interfaces. Thus 

#26053 [Opn->WFx]: returning references crash

[moriyoshi]

 ID:   26053
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ikaraszi at prim dot hu
-Status:   Open
+Status:   Wont fix
 Bug Type: Scripting Engine problem
 Operating System: Debian GNU/Linux unstable
 PHP Version:  4.3.3
 New Comment:

Related to bug #22836, bug #22510, or whatever.
Do not return a scalar that is not a variable by reference.



Previous Comments:


[2003-10-31 07:04:35] ikaraszi at prim dot hu

Description:

Our scripts (both mod_php and CGI/command line version) segfaulted.
Tracing the problem showed that the errors occured after a return()
statement. (The program ran ok until the return statement, but it never
did return into the function calling it.)

We have been able to reproduce the possible basis of the problem, see
the attached code. This code doesn't segfault, but does display an
error. We think that more complex usage leads to segfaults.

The following backtrace has been produced with one of our complex
scripts, not the one attached, so it's only provided for reference.
---
Program received signal SIGSEGV, Segmentation fault.
0x081455c9 in _mem_block_check (ptr=0x81ceaa4, silent=0,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:675
675 memcpy(&end_magic, (((char *)
p)+sizeof(zend_mem_header)+MEM_HEADER_PADDING+p->size), sizeof(long));
(gdb) bt
#0  0x081455c9 in _mem_block_check (ptr=0x81ceaa4, silent=0,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:675
#1  0x081456ce in _mem_block_check (ptr=0x81ceaa4, silent=1,
__zend_filename=0x81aff00 "/root/php4-4.3.3/Zend/zend_execute.c",
__zend_lineno=271,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at
/root/php4-4.3.3/Zend/zend_alloc.c:683
#2  0x08144b42 in _efree (ptr=0x81ceaa4,
__zend_filename=0x3038 ,
__zend_lineno=1073737784,
__zend_orig_filename=0x3038 ,
__zend_orig_lineno=1073737784) at
/root/php4-4.3.3/Zend/zend_alloc.c:243
#3  0x081609f0 in zend_assign_to_variable_reference (result=0x83cfa18,
variable_ptr_ptr=0x847aef8,
value_ptr_ptr=0x83d95e0, Ts=0xbfffe6cc) at
/root/php4-4.3.3/Zend/zend_execute.c:271
#4  0x08162845 in execute (op_array=0x83cdfa8) at
/root/php4-4.3.3/Zend/zend_execute.c:163
#5  0x0814c72f in call_user_function_ex (function_table=0x0,
object_pp=0x0, function_name=0x0,
retval_ptr_ptr=0xb038, param_count=0, params=0x8344c7c,
no_separation=1, symbol_table=0x0)
at /root/php4-4.3.3/Zend/zend_execute_API.c:567
#6  0x0814c152 in call_user_function (function_table=0x3038,
object_pp=0x3038,
function_name=0x3038, retval_ptr=0xb070, param_count=0,
params=0x83d93d0)
at /root/php4-4.3.3/Zend/zend_execute_API.c:409
#7  0x080bd610 in user_shutdown_function_call
(shutdown_function_entry=0x83d8d74)
at /root/php4-4.3.3/ext/standard/basic_functions.c:2007
#8  0x08159c88 in zend_hash_apply (ht=0x833be3c, apply_func=0x80bd5d0
)
at /root/php4-4.3.3/Zend/zend_hash.c:698
#9  0x080bd929 in php_call_shutdown_functions ()
at /root/php4-4.3.3/ext/standard/basic_functions.c:2088
#10 0x08124da2 in php_request_shutdown (dummy=0x0) at
/root/php4-4.3.3/main/main.c:980
#11 0x08168bf0 in main (argc=4, argv=0xb804) at
/root/php4-4.3.3/sapi/cli/php_cli.c:869



Reproduce code:
---
getNull();
var_dump($x);
if (is_object($x['element'])) {
return(true);
}
return(false);
}
   
  
function &getNull() {
/**
 * uncomment following (two) lines to work around the
problem
 */
//if (isset($testarray['test']))
return($testarray['test']);
//return(NULL);
   
  
return($testarray['test']);
}
}
   
  
$t = new Test();
$t->testCase();
?>

Expected result:

NULL

Actual result:
--
NULL
/root/php4-4.3.3/Zend/zend_execute.c(1711) :  Freeing 0x0820E0C4 (12
bytes), script=test-case2.php






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

#25968 [Bgs]: $_SERVER['REQUEST_URI'] - Undefined index

[bob at rsi dot com]

 ID:   25968
 User updated by:  bob at rsi dot com
 Reported By:  bob at rsi dot com
 Status:   Bogus
 Bug Type: CGI related
 Operating System: W2K Server - SP3
 PHP Version:  4.3.3
 New Comment:

The answer to this bug appears to be that IIS is not setting
REQUEST_URI in the environment for PHP under CGI mode.

The above comment about looking in php.ini for clues appears to be
incorrect guidance.

Better off to start reading here:
  http://php.net/reserved.variables
  http://hoohoo.ncsa.uiuc.edu/cgi/env.html
  http://php.net/manual/en/function.getenv.php
  http://php.net/manual/en/function.phpinfo.php
  phpinfo(INFO_ENVIRONMENT);

And here is a code snippet work around:

// Work around REQUEST_URI bug under W2K/IIS/CGI/PHP
if (!isset($_SERVER['REQUEST_URI']) and isset($_SERVER['SCRIPT_NAME']))
{
$_SERVER['REQUEST_URI'] = $_SERVER['SCRIPT_NAME'];
if (isset($_SERVER['QUERY_STRING']) and
!empty($_SERVER['QUERY_STRING']))
$_SERVER['REQUEST_URI'] .= '?' . $_SERVER['QUERY_STRING'];
}


Previous Comments:


[2003-10-30 20:47:39] [EMAIL PROTECTED]

See the php.ini-dist for all the cgi. prefixed options
and tune those. This is not a bug.




[2003-10-24 09:15:07] bob at rsi dot com

System = Windows NT 5.0 build 2195  
Build Date = Aug 24 2003 22:01:16
Server API = CGI/FastCGI
PHP API = 20020918
PHP Extension = 20020429
Zend Extension = 20021010
Debug Build = no
Thread Safety = enabled



[2003-10-23 22:13:19] [EMAIL PROTECTED]

What sapi are you using?



[2003-10-23 10:43:35] bob at rsi dot com

Description:

Somewhere between PHP4.2.3 and PHP 4.3.1 REQUEST_URI disappeared.



Reproduce code:
---
echo $_SERVER['REQUEST_URI'];


Expected result:

echo _SERVER['SCRIPT_NAME'] . '?' . _SERVER['QUERY_STRING'];


Actual result:
--
Notice: Undefined index: REQUEST_URI in ...






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

#26059 [NEW]: Call to __set() crashes Apache when setting array element!

[myle34 at hotmail dot com]

From: myle34 at hotmail dot com
Operating system: Windows XP
PHP version:  5CVS-2003-10-31 (dev)
PHP Bug Type: Reproducible crash
Bug description:  Call to __set() crashes Apache when setting array element!

Description:

I am using PHP5-b2 and Apache 2.0.47 with Windows XP. Apache crashes when
the below code is run.

Reproduce code:
---
class Foo {
private $bar = array();
function __get($var) {
return(isset($this->bar[$var]) ? $this->bar[$var] : NULL);
}
function __set($var,$val) {
$this->bar[$var] = $val;
}
}

$foo = new Foo();

// Works
// $foo->test = array('testing'=>'testing, 1...2...3...');

// Doesn't work, crashes Apache
$foo->test = array();
$foo->test['testing'] = 'testing, 1...2...3...';

print_r($foo->test);

Expected result:

Array
(
[testing] => testing, 1...2...3...
)

Actual result:
--
Apache crashes! No output.

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

#26060 [NEW]: Not closing download handles

[datacompboy at mail dot ru]

From: datacompboy at mail dot ru
Operating system: Win2003 adv server
PHP version:  4.3.3
PHP Bug Type: cURL related
Bug description:  Not closing download handles

Description:

I tried to download file with curl, parse it with external app, show
output and kill temp file. But:
1. if php as isapi module - when several requests at one time some inputs
are locked! Filemon says that it frees by some cmd.exe after all runned
sub-processes already finished. Very strange!
2. if php as fastcgi - it often crashes with error in php_curl (all latest
dlls in system32 upgraded; php4ts only in c:\php, php4isapi also in c:\php
and no in c:\windows\system)
3. if php as cgi - all OK, except of when user cancelled download the
script terminated, but shotdown_procedure not called, so temp files left.

Reproduce code:
---
http://some.site.com";;
  $oinfile = tempnam ("./", "URLIN");
  $infile = preg_replace("#.*[/](.*?)#","\$1",$oinfile);
  $ooutfile = tempnam ("./", "URLOU");
  $outfile = preg_replace("#.*[/](.*?)#","\$1",$ooutfile);
  register_shutdown_function(create_function('',
"@unlink(\"$infile\"); @unlink(\"$outfile\"); @unlink(\"$oinfile\");
@unlink(\"$ooutfile\"); return 1;"));
  $inf = fopen($infile, "w");
  fwrite($inf, "\n");
  $ch = curl_init();
  curl_setopt ($ch, CURLOPT_URL, $url);
  curl_setopt ($ch, CURLOPT_FILE, $inf);
  $st=curl_exec ($ch);
  curl_close ($ch);
  fclose($inf);
  echo `filter.exe $lang $infile $outfile 2>&1`;
  ob_end_flush();
?>

Expected result:

No .tmp files not in windows\temp\ folder, not in script folder.

Actual result:
--
Some .tmp files left and in windows\temp, and in script folder.

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

#25916 [Fbk]: get_browser() -> PHP Fatal error: Nesting level too deep - recursive dependency?

[thetaphi]

 ID:   25916
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Feedback
 Bug Type: Scripting Engine problem
 Operating System: Solaris 9
 PHP Version:  4.3.4RC1
 New Comment:

I do not think so, because it happens only when a lot of requests are
done. So you cannot test it with CLI/CGI :(
I could debug it when the server goes into this error by attaching dbx
to PID. But to do this it would be good to check where this error could
come from.


Previous Comments:


[2003-10-30 21:05:20] [EMAIL PROTECTED]

Does this happen with CLI build with ZTS enabled?




[2003-10-20 04:30:58] [EMAIL PROTECTED]

Addendum: It is not a problem with wrong extension dir in php.ini
(because all extensions are linked static) like in other bugs.

The configuration phpinfo() can be found at:
http://134.1.2.11/test.php




[2003-10-20 03:39:01] [EMAIL PROTECTED]

Description:

The following error occurs sometimes on the ext/standard function
get_browser():
[20/Oct/2003:08:54:59] info (13034):  for host
p5084725C.dip.t-dialin.net trying to GET /index.php, php4_execute
reports: PHP Fatal error: Nesting level too deep - recursive
dependency? in /pangaea/htdocs/www.pangaea.de/index.php on line 28  

Line 28 contains the call to get_browser(). All other PHP functions do
not fail. In other scripts which use get_browser() the error also
occurs.

The problem is: You cannot reproduce it, because it happens only on
heavy server load and when it happens the first time it does not go
away until server restart.

PHP runs on SunONE with NSAPI, so compiled with ZTS.

I would debug the code and fix the error; but my problem is that I do
not know WHERE in get_browser the error occurs.

Uwe

Reproduce code:
---
http://www.google.de/search?sourceid=navclient&hl=de&q=%22age%2C+error%22+pangaea
//
http://www.google.de/search?q=%22age,+error%22+pangaea&hl=de&lr=&ie=UTF-8&filter=0
if (isset($_GET['query'])) {
$query=$_GET['query'];
} else {
if (isset($_SERVER['HTTP_REFERER']) &&
preg_match('/^http:\/\/.*?google\..*?\/search\?(.*?)$/i',
$_SERVER['HTTP_REFERER'], $matches)) {
$a = split ('&', $matches[1]);
for ($i=0; $icrawler) && isset($_SERVER['PATH_INFO'])) {
if (isset($query)) {
header("Location:
http://".$_SERVER['HTTP_HOST']."/?query=".urlencode($query));
} else {
header("Location: http://".$_SERVER['HTTP_HOST']."/");
}
exit();
}

// if a crawler like google is visiting: prepare keyword list to
display and extract page number
if ($browser->crawler) {
$page=0;
if (isset($_SERVER['PATH_INFO'])) {
if (preg_match('/^\/(.*?)\.html$/', $_SERVER['PATH_INFO'],
$matches)) {
$page=$matches[1];
} else {
header("HTTP/1.0 404 Not Found");
exit();
}
}
$lines=file("../globals/googlelist.txt");
if ($page*1000>=count($lines)) {
header("HTTP/1.0 404 Not Found");
exit();
}
}
?>



...






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

#26061 [NEW]: mail function chops html code when is used with php ver 4.3.3

[soporte at redycomercio dot com]

From: soporte at redycomercio dot com
Operating system: win 2000
PHP version:  4.3.3
PHP Bug Type: Mail related
Bug description:   mail function chops html code when is used with php ver 4.3.3

Description:

Hello!

When we send an html e-mail using the mail function with php ver 4.3.3 we
do not get the same result as if we were using php ver 4.3.1 We have tried
the same e-mail file using the mail function on both versions 4.3.1 and
4.3.3 We notice that ver 4.3.3 chops some characters from the html code
sent. Notice that we have properly formated the html code before using the
email function, also we have use the wordwrap funcion as well. Our html
complains with standars!
Notice that this possible bug is a variant of "Bug #25638: Error in mail()
function -- possibly in headers" On this case we do not get garbage but
some code chopped

Any ideas? Thank you very much for you help!  

Fabio Castaneda


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

#26063 [NEW]: (5.0.0b2) reversal of array_merge() fix for #25494

[mario at erphesfurt dot de]

From: mario at erphesfurt dot de
Operating system: Debian GNU/Linux, glibc2.3
PHP version:  5CVS-2003-10-31 (dev)
PHP Bug Type: Arrays related
Bug description:  (5.0.0b2) reversal of array_merge() fix for #25494

Description:

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

Hi,

The array_merge() fix introduced into beta2 broke my scripts, 'cause they
relied upon array_merge() to return something even if some of the passed
parameters were undef.

I used to merge values into my arrays that way, even if it was unclear
wether there was previously data in it:

$my_array = array_merge(
   $my_array,
   array(
  "fill_up" => "if_unset",
  "this" => "too",
   )
);

Which now doesn't work any longer. - this requires some code bloat to
work around now (introducing a user-level array_merge).

I don't believe the current ext/standard/array.c:php_array_merge_wrapper
addresses the problem described in #25494, it now just fails and sends
eventual paramaters of PHP:ewiki_merge() to hell, making it incompatible
to previous versions (PHP4,beta1).

Why wasn't just a warning message sufficient?!

If you guys really like to change the way that PHP function was used,
then
you could replace E_WARNING with E_ERROR inside the array.c on line 
-
this would be less bogus than a _warning_ message that silently kills
data.

mario



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

#25987 [Bgs]: php and xml tag confusion

[tkwright_233 at hotmail dot com]

 ID:   25987
 User updated by:  tkwright_233 at hotmail dot com
 Reported By:  tkwright_233 at hotmail dot com
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  *
 New Comment:

I get what you mean.

So how come the php engene recognizes '' would cause an
error (comparing to '').


Previous Comments:


[2003-10-30 15:44:15] [EMAIL PROTECTED]

Becasue the first two characters are the same?



[2003-10-30 15:39:15] tkwright_233 at hotmail dot com

So why can't it recognize '' would cause an error.



[2003-10-26 15:24:32] [EMAIL PROTECTED]

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

It does recognize the difference, if you disable 
short_tags, which you should for exactly this reason.



[2003-10-26 14:20:58] tkwright_233 at hotmail dot com

abye there could be another variable in the php.ini, space required
after tag start.



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

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

#26064 [NEW]: Warning: mime_magic: invalid type 0 in mconvert(). in ...

[e05 at freemails dot ch]

From: e05 at freemails dot ch
Operating system: Linux 2.4.20 (Debian)
PHP version:  4.3.3
PHP Bug Type: Unknown/Other Function
Bug description:  Warning: mime_magic: invalid type 0 in mconvert(). in ...

Description:

Well, there isn´t much to tell. The error message is:
Warning: mime_magic: invalid type 0 in mconvert(). in /foo/bar.php on line
2

mconvert doesn´t seems to be a public funktion as
http://www.php.net/mconvert didn´t work.

Reproduce code:
---



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

#25753 [Com]: php_value|flag / php_admin_* settings "leak" from vhosts/.htaccess files

[butch at infowest dot com]

 ID:   25753
 Comment by:   butch at infowest dot com
 Reported By:  [EMAIL PROTECTED]
 Status:   Critical
 Bug Type: Apache related
 Operating System: *
 PHP Version:  4CVS, 5CVS
 New Comment:

For me, I ended up downgrading to 4.3.1 and that seemed to resolve my
issues. Must be something that changed after 4.3.1 which is causing the
issues.


Previous Comments:


[2003-10-30 09:35:44] fs at nessus dot at

no thats false.
this bug occours on apache 1.3.x too (tested it with 1.3.27).
i think thats very essential...

greetings,

Florian Schicker
www.nessus.at



[2003-10-28 04:13:33] mattias at segerdahl dot info

This bug only appears when and if you have overlapping virtualhosts in
apache2. Using fqdn's that have IN A or CNAME to an ipaddress on the
server seems to fix it.

This is only an observation that seems to have gotten rid of the
problem for me.

// bad2da



[2003-10-22 04:01:39] mattias at segerdahl dot info

Sniper,

I accidently ran into this bug a few moments ago. I talked to Derick
about it in the channel and we agreed I would do some testing. There
are some particular strange behaviour.

I will try to explain as well as include the files needed to reproduce
this error. But first let me point out one thing that I find really
weird.

This only occurs when the apache server has not been accessed for a
while, if you reload the page directly after you've encountered this
error message, it will work perfectly.

The error message is:

Warning: Unknown(): open_basedir restriction in effect.
File(/var/www/users.bitcom.se/index.php) is not within the allowed
path(s): (/var/www/www.sol.se) in Unknown on line 0
Warning: Unknown(/var/www/users.bitcom.se/index.php): failed to open
stream: Operation not permitted in Unknown on line 0
Warning: (null)(): Failed opening '/var/www/users.bitcom.se/index.php'
for inclusion (include_path='.:/usr/local/php//lib/php') in Unknown on
line 0

My php.ini file http://www.segerdahl.info/25753/php.ini
My httpd.conf file http://www.segerdahl.info/25753/httpd.conf

Server version: Apache/2.0.47
Server built:   Oct 20 2003 18:39:21

PHP 4.3.4RC4 configured as:

'./configure' '--with-apxs2=/usr/local/httpd/bin/apxs'
'--enable-mbstring' '--with-pear' '--with-mysql'
'--enable-magic-quotes' '--with-ftp' '--sysconfdir=/etc/php'
'--with-config-file-path=/etc/php' '--prefix=/usr/local/php/'
'--enable-mbstring' '--with-curl' '--enable-ftp' 

APACHE configured as:
./configure --sysconfdir=/etc/httpd/conf --enable-ssl
--prefix=/usr/local/httpd --enable-modules=dso,most

Contact me on efnet if you need more information... // bad2da



[2003-10-04 18:58:16] [EMAIL PROTECTED]

We do not know what causes this bug or how it can be reliably
reproduced. If you know exactly HOW this can be reproduced, add the
information here. Any other comments will be deleted.




[2003-10-04 00:48:12] [EMAIL PROTECTED]

Description:

If (for example) one virtualhost configuration has
set "php_admin_flag register_globals off", in some situations the
setting persists between requests.
-> php.ini settings are NOT reset between requests.

1. php.ini has register_globals = On
2. Request is made into www.foobar.com 
(which has "php_admin_flag register_globals off")
3. Next request (same apache child) is made into www.barfoo.com (which
does not have the setting)

This applies to ALL php.ini directives.

Some related reports:

bug #6374 (include_path in .htaccess across multiple vhosts)
bug #7174 (Round-robin -like values for include_path)
bug #19292 (Random error: open_basedir restriction..)
bug #21564 (corrupted paths coming to open_basedir)
bug #23462 ("php_admin_value open_basedir" in httpd.conf)
bug #23580 (Random values for include_path)
bug #24282 (Strange Open Base Dir Restriction Errors)
bug #24974 (random open_basedir errors)
bug #25172 ($HTTP_HOST sometimes empty)

For all who think they're experiencing this problem:
DO NOT add any comments here unless you have some extra information to
give which is not already given in above mentioned reports. 
Any comment which has no extra value will be deleted.







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

#26064 [Opn->Fbk]: Warning: mime_magic: invalid type 0 in mconvert(). in ...

[iliaa]

 ID:   26064
 Updated by:   [EMAIL PROTECTED]
 Reported By:  e05 at freemails dot ch
-Status:   Open
+Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: Linux 2.4.20 (Debian)
 PHP Version:  4.3.3
 New Comment:

Would it be possible for you to make the avi file in question
avaliable?


Previous Comments:


[2003-10-31 16:02:16] e05 at freemails dot ch

Description:

Well, there isn´t much to tell. The error message is:
Warning: mime_magic: invalid type 0 in mconvert(). in /foo/bar.php on
line 2

mconvert doesn´t seems to be a public funktion as
http://www.php.net/mconvert didn´t work.

Reproduce code:
---







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

#26061 [Opn->Csd]: mail function chops html code when is used with php ver 4.3.3

[iliaa]

 ID:   26061
 Updated by:   [EMAIL PROTECTED]
 Reported By:  soporte at redycomercio dot com
-Status:   Open
+Status:   Closed
 Bug Type: Mail related
 Operating System: win 2000
 PHP Version:  4.3.3
 New Comment:

This bug has been fixed in CVS.

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

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




Previous Comments:


[2003-10-31 14:16:09] soporte at redycomercio dot com

Description:

Hello!

When we send an html e-mail using the mail function with php ver 4.3.3
we do not get the same result as if we were using php ver 4.3.1 We have
tried the same e-mail file using the mail function on both versions
4.3.1 and 4.3.3 We notice that ver 4.3.3 chops some characters from the
html code sent. Notice that we have properly formated the html code
before using the email function, also we have use the wordwrap funcion
as well. Our html complains with standars!
Notice that this possible bug is a variant of "Bug #25638: Error in
mail() function -- possibly in headers" On this case we do not get
garbage but some code chopped

Any ideas? Thank you very much for you help!  

Fabio Castaneda






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

#26043 [Opn->Fbk]: pg_lo_import causes crash under all circumstances

[iliaa]

 ID:   26043
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dqj at requesttech dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PostgreSQL related
 Operating System: Redhat 9.0
 PHP Version:  4.3.3
 New Comment:

if you can provide the file used to replicate the crash, it may be
possible for us to test and see if the issue was in fact resolved.


Previous Comments:


[2003-10-31 10:25:57] dqj at requesttech dot com

Using the latest snapshot tarball is not easy for us since our platform
is based on RPM installs. I spent a couple of hours this morning trying
to get the right configure commands working so we could rebuild PHP to
work with Postgres 7.3.4 and Apache 2.0, but could not get it to work. 
(I may not have the right "devel" packages around for Apache and
Postgres.)

Is there any other way to look into the bug without having to recompile
PHP to upgrade our system just to find out if the bug has "gone away"?

Thank you in advance for your help.



[2003-10-30 20:30:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Try the snapshot first, please.




[2003-10-30 14:32:24] dqj at requesttech dot com

Forgot to mention that the Postgres version is 7.3.4.



[2003-10-30 14:26:13] dqj at requesttech dot com

I was wrong about there not being anything in the logs.  In the httpd
error_log, there was the following:

[Thu Oct 30 14:25:10 2003] [notice] child pid 16877 exit signal
Segmentation fault (11)

This occurs whenever a valid filename is given to pg_lo_import.



[2003-10-30 13:48:23] dqj at requesttech dot com

Description:

No changes to php.ini distribution.  No output shown in logs.  Just
doesn't finish the page.  (I have put echoes and breaks in to narrow it
to the pg_lo_import() call).  We have checked file permissions, etc. 
This code has worked under PHP 4.2 and other versions.  Have tried
switching the pg_lo_import parameters back and forth, just in case, as
described in the bug documentation.



Reproduce code:
---
"; flush();
?>


Expected result:

$oid should have a value. Echoed results should appear.


Actual result:
--
Blank page.  (Or echoed results prior to subroutine call, if debug is
included.)






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

#26063 [Opn->Bgs]: (5.0.0b2) reversal of array_merge() fix for #25494

[iliaa]

 ID:   26063
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mario at erphesfurt dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Arrays related
 Operating System: Debian GNU/Linux, glibc2.3
 PHP Version:  5CVS-2003-10-31 (dev)
 New Comment:

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

As with all other functions in PHP, when invalid parameters are passed
E_WARNING is generated. E_ERROR is intended for unrecoverable errors,
such as parse errors.


Previous Comments:


[2003-10-31 15:29:23] mario at erphesfurt dot de

Description:

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

Hi,

The array_merge() fix introduced into beta2 broke my scripts, 'cause
they
relied upon array_merge() to return something even if some of the
passed
parameters were undef.

I used to merge values into my arrays that way, even if it was unclear
wether there was previously data in it:

$my_array = array_merge(
   $my_array,
   array(
  "fill_up" => "if_unset",
  "this" => "too",
   )
);

Which now doesn't work any longer. - this requires some code bloat to
work around now (introducing a user-level array_merge).

I don't believe the current
ext/standard/array.c:php_array_merge_wrapper
addresses the problem described in #25494, it now just fails and sends
eventual paramaters of PHP:ewiki_merge() to hell, making it
incompatible
to previous versions (PHP4,beta1).

Why wasn't just a warning message sufficient?!

If you guys really like to change the way that PHP function was used,
then
you could replace E_WARNING with E_ERROR inside the array.c on line
 -
this would be less bogus than a _warning_ message that silently kills
data.

mario







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

#26059 [Opn->Ver]: Call to __set() crashes Apache when setting array element!

[iliaa]

 ID:   26059
 Updated by:   [EMAIL PROTECTED]
 Reported By:  myle34 at hotmail dot com
-Status:   Open
+Status:   Verified
 Bug Type: Reproducible crash
-Operating System: Windows XP
+Operating System: All
 PHP Version:  5CVS-2003-10-31 (dev)


Previous Comments:


[2003-10-31 12:41:29] myle34 at hotmail dot com

Description:

I am using PHP5-b2 and Apache 2.0.47 with Windows XP. Apache crashes
when the below code is run.

Reproduce code:
---
class Foo {
private $bar = array();
function __get($var) {
return(isset($this->bar[$var]) ? $this->bar[$var] : NULL);
}
function __set($var,$val) {
$this->bar[$var] = $val;
}
}

$foo = new Foo();

// Works
// $foo->test = array('testing'=>'testing, 1...2...3...');

// Doesn't work, crashes Apache
$foo->test = array();
$foo->test['testing'] = 'testing, 1...2...3...';

print_r($foo->test);

Expected result:

Array
(
[testing] => testing, 1...2...3...
)

Actual result:
--
Apache crashes! No output.





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

#26065 [NEW]: Crash when nesting classes

[kester dot everts at wanadoo dot nl]

From: kester dot everts at wanadoo dot nl
Operating system: Windows XP Professional (SP1)
PHP version:  5.0.0b1 (beta1)
PHP Bug Type: Reproducible crash
Bug description:  Crash when nesting classes

Description:

When nesting a class within another class function, PHP crashes.
I have PHP running on an Apache2 (2.0.47) server as a module.
Changes in my php.ini, different from php.ini-dist are my SMTP server
setting, my error reporting level setting to E_ALL and the floating point
number precision to 14. No exentions are enabled.

Reproduce code:
---
class foo {
 function bar() {
  //here comes the line of doom:
  class my_class {}
 }
}


Expected result:

I expected PHP to return a fatal error which says that classes cannot be
nested.

Actual result:
--
PHP crashed...
I am using Windows, so I have not got a backtrace. I have sent an error
report to Microsoft; maybe that helps.

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

#25958 [Fbk->Opn]: odbc_connect fails to login to remote Dbase 5

[brian dot garvis at mascommsys dot com]

 ID:   25958
 User updated by:  brian dot garvis at mascommsys dot com
 Reported By:  brian dot garvis at mascommsys dot com
-Status:   Feedback
+Status:   Open
 Bug Type: ODBC related
 Operating System: Windows 2003 Server
 PHP Version:  4.3.2
 New Comment:

I can give you the trace, but it is a zero byte file.  ODBC does not
see any errors.  The trace only produces a file on error.


Previous Comments:


[2003-10-31 09:38:38] [EMAIL PROTECTED]

If you cannot give me a trace of the SQL connection, I 
cannot help you.  



[2003-10-30 18:49:38] brian dot garvis at mascommsys dot com

After working on this for the past week with anyone and everyone we
could find to help out, we are still where we started.  

We have verified that MS ODBC works fine to database on local machine. 
We have tried to connect to different databases on different remote
machines using both php and MS Query.  MS Query has no problem
accessing remote DBase & Access databases using the same DSN's that PHP
is using.  PHP to the same remote databases always returns the same
errors with a "null" "Resource ID #".



[2003-10-23 14:34:06] brian dot garvis at mascommsys dot com

Turning on Machine-Wide tracing using odbctrac.dll in ODBC Data Source
Administrator and reproducing the problem does not create any entries
in the SQL.LOG.  I did make the user "Administrator" invalid for the
shared drive and the SQL.LOG file filled quickly with errors.  Errors
stopped when I added the "Administrator" user back on the shared
drive.

>From my ODBC Data Source Administrator, System DSN, System Data
Sources:
Name: DEMOSASI
Driver: Microsoft dBase Driver (*.dbf)

>From the ODBC dBASE Setup for DSN DEMOSASI:
Data Source Name: DEMOSASI
Database VErsion: dBase 5.0
Directory: Z:\ (mapped shared folder where DB resides on another
machine)
Driver:
  Collating Sequence: ASCII
  Page Timeout: 5



[2003-10-22 19:42:18] [EMAIL PROTECTED]

Please include your DSN entry, and a SQL Log for the connection attempt
if you can.  From the sounds of it, you're not configured properly on
the ODBC Administrator end, and thus not a PHP bug. 



[2003-10-22 18:19:57] brian dot garvis at mascommsys dot com

Description:

odbc_connect fails to connect to a Dbase 5 database which resides on a
separate Windows 2000 machine using Microsoft ODBC Data Source
Administrator.  If move database to local machine and point ODBC to
local database, then works.

PHP reports error: 
Warning: SQL error: [Microsoft][ODBC dBase Driver] '(unknown)' is not a
valid path. Make sure that the path name is spelled correctly and that
you are connected to the server on which the file resides., SQL state
S1009 in SQLConnect in C:\DEMO\wwwroot\login.php on line 16



Reproduce code:
---
http://bugs.php.net/?id=25958&edit=1

#26065 [Opn]: Crash when nesting classes

[kester dot everts at removethis dot wanadoo dot nl]

 ID:   26065
 User updated by:  kester dot everts at removethis dot wanadoo dot nl
-Reported By:  kester dot everts at wanadoo dot nl
+Reported By:  kester dot everts at removethis dot wanadoo dot nl
 Status:   Open
 Bug Type: Reproducible crash
 Operating System: Windows XP Professional (SP1)
-PHP Version:  5.0.0b1 (beta1)
+PHP Version:  5.0.0b2
 New Comment:

I meant 5.0.0b2...


Previous Comments:


[2003-10-31 17:30:21] kester dot everts at removethis dot wanadoo dot
nl

Description:

When nesting a class within another class function, PHP crashes.
I have PHP running on an Apache2 (2.0.47) server as a module.
Changes in my php.ini, different from php.ini-dist are my SMTP server
setting, my error reporting level setting to E_ALL and the floating
point number precision to 14. No exentions are enabled.

Reproduce code:
---
class foo {
 function bar() {
  //here comes the line of doom:
  class my_class {}
 }
}


Expected result:

I expected PHP to return a fatal error which says that classes cannot
be nested.

Actual result:
--
PHP crashed...
I am using Windows, so I have not got a backtrace. I have sent an error
report to Microsoft; maybe that helps.





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

#26043 [Fbk->Opn]: pg_lo_import causes crash under all circumstances

[dqj at requesttech dot com]

 ID:   26043
 User updated by:  dqj at requesttech dot com
 Reported By:  dqj at requesttech dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PostgreSQL related
 Operating System: Redhat 9.0
 PHP Version:  4.3.3
 New Comment:

Thank you!  To make it really simple and rule out file contents
problems, I just did:

% echo "1" > /tmp/dqj.tmp

to create the file.

It also had failed with a .wav file prior to that.


Previous Comments:


[2003-10-31 16:45:17] [EMAIL PROTECTED]

if you can provide the file used to replicate the crash, it may be
possible for us to test and see if the issue was in fact resolved.



[2003-10-31 10:25:57] dqj at requesttech dot com

Using the latest snapshot tarball is not easy for us since our platform
is based on RPM installs. I spent a couple of hours this morning trying
to get the right configure commands working so we could rebuild PHP to
work with Postgres 7.3.4 and Apache 2.0, but could not get it to work. 
(I may not have the right "devel" packages around for Apache and
Postgres.)

Is there any other way to look into the bug without having to recompile
PHP to upgrade our system just to find out if the bug has "gone away"?

Thank you in advance for your help.



[2003-10-30 20:30:47] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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

Try the snapshot first, please.




[2003-10-30 14:32:24] dqj at requesttech dot com

Forgot to mention that the Postgres version is 7.3.4.



[2003-10-30 14:26:13] dqj at requesttech dot com

I was wrong about there not being anything in the logs.  In the httpd
error_log, there was the following:

[Thu Oct 30 14:25:10 2003] [notice] child pid 16877 exit signal
Segmentation fault (11)

This occurs whenever a valid filename is given to pg_lo_import.



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

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

#26063 [Com]: (5.0.0b2) reversal of array_merge() fix for #25494

[mario-adds-a-notice at erphesfurt dot de]

 ID:   26063
 Comment by:   mario-adds-a-notice at erphesfurt dot de
 Reported By:  mario at erphesfurt dot de
 Status:   Bogus
 Bug Type: Arrays related
 Operating System: Debian GNU/Linux, glibc2.3
 PHP Version:  5CVS-2003-10-31 (dev)
 New Comment:

(the "Add Comment" behaves rather strange here)

Now what is going to happen on that thing? I've visited the CVSweb and
of course noticed, that this inconsistency was also in the PHP 4.3.x
tree (but resolved now).

What is going to happen to PHP5? Will it enforce strict types like the
php5beta2 demonstrates here, or will the support for "implicit
typecasting" (like the current PHP documentation describes it) come
back?

I don't see the problem with NULL being automatically casted to an
empty array(). Even if this is no longer the desired behaviour, a
E_NOTICE would be enough, wouldn't it? Why did the well-known and
established behaviour needed to terminate?

The PHP manual actually described what happened in
http://bugs.php.net/bug.php?id=#25494 (the typecasting of "false" to
"array(0=>false)") quite well. If strong-typing
now gets standard, this should go into the NEWS file and into the PHP
manual. The E_WARNING and function failure right now isn't mentioned
there.


Previous Comments:


[2003-10-31 16:52:47] [EMAIL PROTECTED]

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

As with all other functions in PHP, when invalid parameters are passed
E_WARNING is generated. E_ERROR is intended for unrecoverable errors,
such as parse errors.



[2003-10-31 15:29:23] mario at erphesfurt dot de

Description:

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

Hi,

The array_merge() fix introduced into beta2 broke my scripts, 'cause
they
relied upon array_merge() to return something even if some of the
passed
parameters were undef.

I used to merge values into my arrays that way, even if it was unclear
wether there was previously data in it:

$my_array = array_merge(
   $my_array,
   array(
  "fill_up" => "if_unset",
  "this" => "too",
   )
);

Which now doesn't work any longer. - this requires some code bloat to
work around now (introducing a user-level array_merge).

I don't believe the current
ext/standard/array.c:php_array_merge_wrapper
addresses the problem described in #25494, it now just fails and sends
eventual paramaters of PHP:ewiki_merge() to hell, making it
incompatible
to previous versions (PHP4,beta1).

Why wasn't just a warning message sufficient?!

If you guys really like to change the way that PHP function was used,
then
you could replace E_WARNING with E_ERROR inside the array.c on line
 -
this would be less bogus than a _warning_ message that silently kills
data.

mario







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