#39181 [NEW]: gmake error --with-curl

[dcalvo at hcuv dot sacyl dot es]

From: dcalvo at hcuv dot sacyl dot es
Operating system: HP-UX 11.11
PHP version:  5.1.6
PHP Bug Type: Compile Failure
Bug description:  gmake error --with-curl

Description:

Hello.
When compile PHP 5.1.6 with the option --with-curl=/users/opt/curl gmake
process fail

Reproduce code:
---
./configure --prefix=/opt/hpws/apache/php \
--with-apxs2=/opt/hpws/apache/bin/apxs \
--with-config-file-path=/opt/hpws/apache/conf \
--enable-libgcc \
--enable-ftp \
--with-informix=/informix/ifx31 \
--with-gd \
--with-unixODBC=/users/opt/unixODBC \
--with-iconv=/usr/local \
--with-zlib=/usr/local \
--with-zlib-dir=/usr/local \
--with-freetype-dir=/usr/local \
--with-gettext=/usr/local \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local \
--with-ttf=/usr/local \
--with-t1lib=/usr/local \
--enable-gd-native-ttf \
--enable-xslt \
--with-xslt-sablot=/usr/local \
--with-curl=/users/opt/curl \
--with-curlwrappers \
--with-ldap=/usr/local \
--with-mhash=/usr/local \
--with-mssql=/users/opt/freetds \
--with-openssl=/usr/local \
--with-libexpat-dir=/usr/local \
--with-libxml-dir=/usr/local \
--with-xsl=/usr/local \
--enable-calendar \
  

Expected result:

Build complete.

Actual result:
--
/bin/sh /users/fuentes/php-5.1.6/libtool --silent --preserve-dup-deps
--mode=link /users/fuentes/php-5.1.6/meta_ccld -I/usr/local/include -g -O2
-pthread -DZTS  -rpath /users/fuentes/php-5.1.6/libs -avoid-version -module
-L/usr/local/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.1 -L/usr/local/lib
-L/users/opt/curl/lib -L/usr/local/bin/lib -L/informix/ifx31/lib
-L/informix/ifx31/lib/esql -L/users/opt/freetds/lib
-L/users/opt/unixODBC/lib  -R
/usr/local/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.1 -R /usr/local/lib -R
/users/opt/curl/lib -R /usr/local/bin/lib -R /informix/ifx31/lib -R
/informix/ifx31/lib/esql -R /users/opt/freetds/lib -R
/users/opt/unixODBC/lib ext/libxml/libxml.lo ext/openssl/openssl.lo
ext/openssl/xp_ssl.lo ext/pcre/pcrelib/pcre_chartables.lo
ext/pcre/pcrelib/pcre_ucp_searchfuncs.lo ext/pcre/pcrelib/pcre_compile.lo
ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_dfa_exec.lo
ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo
ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo
ext/pcre/pcrelib/pcre_info.lo ext/pcre/pcrelib/pcre_maketables.lo
ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo
ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo
ext/pcre/pcrelib/pcre_try_flipped.lo ext/pcre/pcrelib/pcre_valid_utf8.lo
ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo
ext/pcre/php_pcre.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo
ext/zlib/zlib_filter.lo ext/calendar/calendar.lo ext/calendar/dow.lo
ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo
ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo
ext/ctype/ctype.lo ext/curl/interface.lo ext/curl/multi.lo
ext/curl/streams.lo ext/date/php_date.lo ext/date/lib/astro.lo
ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo
ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo
ext/date/lib/unixtime2tm.lo ext/dom/php_dom.lo ext/dom/attr.lo
ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo
ext/dom/domexception.lo ext/dom/namelist.lo
ext/dom/processinginstruction.lo ext/dom/cdatasection.lo
ext/dom/documentfragment.lo ext/dom/domimplementation.lo
ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo
ext/dom/characterdata.lo ext/dom/documenttype.lo
ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo
ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo
ext/dom/domimplementationsource.lo ext/dom/entityreference.lo
ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo
ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo
ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/ftp/php_ftp.lo
ext/ftp/ftp.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/libgd/gd.lo
ext/gd/libgd/gd_gd.lo ext/gd/libgd/gd_gd2.lo ext/gd/libgd/gd_io.lo
ext/gd/libgd/gd_io_dp.lo ext/gd/libgd/gd_io_file.lo ext/gd/libgd/gd_ss.lo
ext/gd/libgd/gd_io_ss.lo ext/gd/libgd/gd_png.lo ext/gd/libgd/gd_jpeg.lo
ext/gd/libgd/gdxpm.lo ext/gd/libgd/gdfontt.lo ext/gd/libgd/gdfonts.lo
ext/gd/libgd/gdfontmb.lo ext/gd/libgd/gdfontl.lo ext/gd/libgd/gdfontg.lo
ext/gd/libgd/gdtables.lo ext/gd/libgd/gdft.lo ext/gd/libgd/gdcache.lo
ext/gd/libgd/gdkanji.lo ext/gd/libgd/wbmp.lo ext/gd/libgd/gd_wbmp.lo
ext/gd/libgd/gdhelpers.lo ext/gd/libgd/gd_topal.lo
ext/gd/libgd/gd_gif_in.lo ext/gd/libgd/xbm.lo ext/gd/libgd/gd_gif_out.lo
ext/gettext/gettext.lo ext/h

#39177 [NEW]: Need mechanism to identifed calling class in static methods

[acarheden at gmail dot com]

From: acarheden at gmail dot com
Operating system: Windows 2K3 Server
PHP version:  5.1.6
PHP Bug Type: Feature/Change Request
Bug description:  Need mechanism to identifed calling class in static methods

Description:

This bug is a duplicate of all of these bugs, but I have a new argument.
I've also filed it correctly as a feature request:
http://bugs.php.net/bug.php?id=30140
http://bugs.php.net/bug.php?id=30423
http://bugs.php.net/bug.php?id=30934
http://bugs.php.net/bug.php?id=30235

When you call a static method on a subclass, the superclass has no way of
knowning what, if any, subclass it was called from.

Say you wanted to implement an Object-Relational Model like ActiveRecord
(Ruby) in PHP (I do). You write an abstract ActiveRecord class with a
static method find() that gets records from the database. Users write some
subclass, the name of which coorisponds to a database table. 

In Ruby's ActiveRecord something like
  class User extends ActiveRecord {}
is my entire implementation of the User class. I call User::find() and it
returns all the User records (As User objects) from the database. The same
thing is impossible in PHP because ActiveRecord::find() doesn't know it was
called as User::find().

I understand that C++ and Java don't work the way Ruby does. I also
understand that it's not a simple change to make and that it may have
performance implications. But Ruby is slower, doesn't work well on
Windows, and doesn't have as much code available as PHP, so it would be
specacular if PHP could provide such functionality as well. 

Also, shouldn't you simply be able to include some method like
get_called_class() that walks the stack trace to find this info. That
doesn't seem like it should be very difficult OR impact the performance of
things that don't use the new functionality.

Oh, and one more thing. Plaaasss!

Reproduce code:
---
class test {

 static function whoami() {
   print "I am " . __CLASS__; // Maybe __CALLED_CLASS__
 }
}

class test1 extends test {
}

test::whoami -> I am test

Expected result:

I expect the results I get...

Actual result:
--
..but I'd LIKE a way to get 'test1'.

-- 
Edit bug report at http://bugs.php.net/?id=39177&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39177&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39177&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39177&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39177&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39177&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39177&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39177&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39177&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39177&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39177&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39177&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39177&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39177&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39177&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39177&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39177&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39177&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39177&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39177&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39177&r=mysqlcfg

#36853 [Com]: Worker process crashes after application pool recycle

[kamikazie at comcast dot net]

 ID:   36853
 Comment by:   kamikazie at comcast dot net
 Reported By:  kleef84 at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 SP1
 PHP Version:  5CVS-2006-03-24 (CVS)
 New Comment:

I've noticed this error, too, but only after a PHP page has been
loaded.

Same basic setup as most, Server 2003, IIS 6, PHP 5.1.4,  painstakingly
followed the setup instructions.

Now a webpage that loads only HTML does not give this error.  When I
load a page that calls PHP, it throws this error about 5 to 10 minutes
after the first page is loaded.


Previous Comments:


[2006-07-12 14:25:19] ferrante at aracnet dot com

Windows 2003 Server, IIS6, .NET 1.1 & .NET 2.0,
php5.2-win32-200607120630 from the snapshots. (Fully Microsoft patched
Windows 2003 server machine).

Even with all PHP dynamic extensions turned off, crash occurs during
IISreset or w3svc service restart.

Event as it appears in event log:

Event Type: Error
Event Source:   Application Error
Event Category: (100)
Event ID:   1000
Date:   07/12/2006
Time:   06:26:45
User:   N/A
Computer:   COMPUTER-NAME
Description:
Faulting application w3wp.exe, version 6.0.3790.1830, faulting module
unknown, version 0.0.0.0, fault address 0x01bba980.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 77 33 77   ure  w3w
0018: 70 2e 65 78 65 20 36 2e   p.exe 6.
0020: 30 2e 33 37 39 30 2e 31   0.3790.1
0028: 38 33 30 20 69 6e 20 75   830 in u
0030: 6e 6b 6e 6f 77 6e 20 30   nknown 0
0038: 2e 30 2e 30 2e 30 20 61   .0.0.0 a
0040: 74 20 6f 66 66 73 65 74   t offset
0048: 20 30 31 62 62 61 39 3801bba98
0050: 300   



Visual Studio 2005 Debugger gives this for the stack trace:
*1  01bba980()
 2  msvcrt.dll!__endthread() 
 3  [EMAIL PROTECTED]()

WinDBG gives this:
+0x26a980
msvcrt!endthread+0xab
kernel32!GetModuleFileNameA+0xeb

the Debug Diagnostic Tool gives this
Function Arg 1 Arg 2 Arg 3   Source 
+26a980 01782ee8     

msvcrt!endthread+ab 02108c80  
kernel32!GetModuleFileNameA+eb 77bcb35a 02108c80 



[2006-07-12 09:54:10] ferrante at aracnet dot com

These are related issues that seem to be describing the same problem:
Bug #33373 IIS worker Process continually restarts
Bug #37575 Faulting application w3wp.exe
Bug #35263 Crash during IIS Restart

Adding the w3wp.exe process to the DEP exception list will also mask
the problem.



[2006-05-28 17:42:23] sschefer at scheferonline dot net

Deeper investigation of the problem indicates that the reason you are
now getting this is because of .NET 2.0. In verison 1.0 and 1.1 it did
not throw this exception because it was set to ignore it. If you don't
have any security issues, you could probably just ignore them and be
O.K. That would not be my choice.

The solution is to recompile the DLL's (all of them) with Visual Studio
8. This will then correctly place them within the scope of the IIS
authorized extension list. 

Workaround, back level your server to .NET 1.0 and do not apply any of
the security patches. Once done, test and then start applying the
security patches. Test each one don't just download them all install
them.  

In a previous post my suggestion of proper ordering does work but it is
exremely tedious and not something you want to endure everytime you add
or remove functionality.



[2006-05-25 19:54:28] sschefer at scheferonline dot net

Applies to all W2K3 versions after SP1 with DEP.
My Installation is W2K3-R2 64bit -- 

The problem described is in the order in which the extensions are
loading from the ini file. IIS fails to register the out of order dll.
When a dependency is run agains the unregistered dll, windows DEP sees
it as a threat and shuts down the worker process. Pretty sweet
actually.

The immediate solution is to comment out all of the extensions in your
ini file and then one at a time, (very important), uncomment them and
do a full reboot. DEP needs to be restarted clean so an IIS restart is
not enough.

When the offending extension causes the fault, cut and paste it one
level above the last uncommented extension. You're probably going to do
this several times before you get it right but eventually you will hit
the sweet spot. The key is not to load extension you don't need.  

If this were any other vendors product I would find something better
but the fact is that the product is so good that its worth t

#39170 [Bgs]: dbase_open no longer functions

[cory dot nemelka at nemelkaitgroup dot com]

 ID:   39170
 User updated by:  cory dot nemelka at nemelkaitgroup dot com
 Reported By:  cory dot nemelka at nemelkaitgroup dot com
 Status:   Bogus
 Bug Type: dBase related
 Operating System: RHEL 3.0
 PHP Version:  5.1.6
 New Comment:

The smallest production file I have is 17MB (the file shown in hex).  I
can post a link if you'd like to look at it.

If not, I'll figure it out sometime in the future and post the answer. 
It's clearly a byte-ordering problem.  Since the files can't be opened
by Msoft's products, I suspect that it is something local to our
environment.  Either way, PHP no longer reads *our* .dbf files.


Previous Comments:


[2006-10-17 09:08:58] [EMAIL PROTECTED]

The file is currupted, even dbview is unable to open it.



[2006-10-17 04:48:07] cory dot nemelka at nemelkaitgroup dot com

previous version that could read these files was PHP v5.0.4, not
v5.0.3.



[2006-10-17 04:15:12] cory dot nemelka at nemelkaitgroup dot com

Also, to clarify, the dbase_open function works fine with non-Visual
Foxpro .dbf files.

If you'd like, I'll dig into this further by downloading the C code for
the dbase functions.  

lmk,
--cnemelka



[2006-10-17 04:11:29] cory dot nemelka at nemelkaitgroup dot com

You can download a small .dbf file at the following url that should not
open:

http://tinyurl.com/yce3bn



NOTE:
The .dbf files that won't open will also not open in Excel or Access
(they should).  However, PHP v5.0.3? was able to open these files ok.



[2006-10-17 04:08:54] cory dot nemelka at nemelkaitgroup dot com





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

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

#39180 [Opn->Bgs]: Image_Graph load issue

[tony2001]

 ID:   39180
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ryan000 at yahoo dot com
-Status:   Open
+Status:   Bogus
-Bug Type: Dynamic loading
+Bug Type: Unknown/Other Function
 Operating System: Linux 2.6.15-1
 PHP Version:  5.2.0RC5
 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.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2006-10-17 19:55:00] ryan000 at yahoo dot com

Description:

5.2 will not run when you include Pear Image_Graph 7.2.
The php will not run and will not give an error.  
 

Reproduce code:
---
include 'Image/Graph.php';

once this code is removed the script will run as normal

Expected result:

php script to execute as normal

Actual result:
--
blank screen with no error





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

#39180 [NEW]: Image_Graph load issue

[ryan000 at yahoo dot com]

From: ryan000 at yahoo dot com
Operating system: Linux 2.6.15-1
PHP version:  5.2.0RC5
PHP Bug Type: Dynamic loading
Bug description:  Image_Graph load issue

Description:

5.2 will not run when you include Pear Image_Graph 7.2.
The php will not run and will not give an error.  
 

Reproduce code:
---
include 'Image/Graph.php';

once this code is removed the script will run as normal

Expected result:

php script to execute as normal

Actual result:
--
blank screen with no error

-- 
Edit bug report at http://bugs.php.net/?id=39180&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39180&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39180&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39180&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39180&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39180&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39180&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39180&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39180&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39180&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39180&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39180&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39180&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39180&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39180&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39180&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39180&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39180&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39180&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39180&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39180&r=mysqlcfg

#39179 [Opn->Fbk]: Abstract types not handled by SoapClient in WSDL mode

[tony2001]

 ID:   39179
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jchernia at netsuite dot com
-Status:   Open
+Status:   Feedback
 Bug Type: SOAP related
 Operating System: Windows XP
 PHP Version:  5.1.6
 New Comment:

Please try using this CVS snapshot:

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




Previous Comments:


[2006-10-17 17:47:11] jchernia at netsuite dot com

Description:

This is very similar to bug 36575
http://bugs.php.net/bug.php?id=36575), but I still see this in the
latest code.

If an operation takes an abstract type, I can not get SoapClient (in
WSDL mode) to produce one of the subclass instances of it, even if I
set type, etc.

Both Axis and .NET generated client classes will send the correct
subclass if you specify it.

NuSoap does not, but allows you to specify additional attributes in
WSDL mode.




Reproduce code:
---
Operation

 
  
 
 


XSD:








 
 
 
  
  
  
  
 


Expected result:





Either this, or the ability to set these attributes in WSDL mode.

Actual result:
--

 






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

#39179 [NEW]: Abstract types not handled by SoapClient in WSDL mode

[jchernia at netsuite dot com]

From: jchernia at netsuite dot com
Operating system: Windows XP
PHP version:  5.1.6
PHP Bug Type: SOAP related
Bug description:  Abstract types not handled by SoapClient in WSDL mode

Description:

This is very similar to bug 36575 http://bugs.php.net/bug.php?id=36575),
but I still see this in the latest code.

If an operation takes an abstract type, I can not get SoapClient (in WSDL
mode) to produce one of the subclass instances of it, even if I set type,
etc.

Both Axis and .NET generated client classes will send the correct subclass
if you specify it.

NuSoap does not, but allows you to specify additional attributes in WSDL
mode.




Reproduce code:
---
Operation

 
  
 
 


XSD:








 
 
 
  
  
  
  
 


Expected result:





Either this, or the ability to set these attributes in WSDL mode.

Actual result:
--

 


-- 
Edit bug report at http://bugs.php.net/?id=39179&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39179&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39179&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39179&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39179&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39179&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39179&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39179&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39179&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39179&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39179&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39179&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39179&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39179&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39179&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39179&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39179&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39179&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39179&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39179&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39179&r=mysqlcfg

#39178 [Opn->Bgs]: Trying to install PHP 5.2 with oci8 support (Oracle10G)

[tony2001]

 ID:   39178
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sinu_chinthala at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Compile Issues
 Operating System: HP Unix 11
 PHP Version:  5.2.0RC5
 New Comment:

This is Oracle bug 4901517.
The most recent version of Oracle Instant Client should have this
problem fixed.


Previous Comments:


[2006-10-17 17:28:55] sinu_chinthala at hotmail dot com

Description:

I tried to compile both PHP 5.1 and 5.2 (latest from cvs) with oci8
support but make failed.

Below is what I tried for configure

#./configure --with-oci8=shared,instantclient,/opt/oracle/STAGE10G/lib


Note: /opt/oracle/STAGE10G/lib contains oracle instant client basic and
sdk libararies

#make


D_XOPEN_SOURCE_EXTENDED  -I/usr/local/include -g -O2   -c
/home/sra01/php5.2-200610080230/ext/oci8/oci8.c -o ext/oci8/oci8.lo
In file included from
/home/sra01/php5.2-200610080230/ext/oci8/oci8.c:50:
/home/sra01/php5.2-200610080230/ext/oci8/php_oci8_int.h:343: error:
expected declaration specifiers or '...' before 'oraub8'
/home/sra01/php5.2-200610080230/ext/oci8/php_oci8_int.h:343: error:
expected declaration specifiers or '...' before 'oraub8'
*** Error exit code 1






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

#39178 [NEW]: Trying to install PHP 5.2 with oci8 support (Oracle10G)

[sinu_chinthala at hotmail dot com]

From: sinu_chinthala at hotmail dot com
Operating system: HP Unix 11
PHP version:  5.2.0RC5
PHP Bug Type: *Compile Issues
Bug description:  Trying to install PHP 5.2 with oci8 support (Oracle10G)

Description:

I tried to compile both PHP 5.1 and 5.2 (latest from cvs) with oci8
support but make failed.

Below is what I tried for configure

#./configure --with-oci8=shared,instantclient,/opt/oracle/STAGE10G/lib


Note: /opt/oracle/STAGE10G/lib contains oracle instant client basic and
sdk libararies

#make


D_XOPEN_SOURCE_EXTENDED  -I/usr/local/include -g -O2   -c
/home/sra01/php5.2-200610080230/ext/oci8/oci8.c -o ext/oci8/oci8.lo
In file included from /home/sra01/php5.2-200610080230/ext/oci8/oci8.c:50:
/home/sra01/php5.2-200610080230/ext/oci8/php_oci8_int.h:343: error:
expected declaration specifiers or '...' before 'oraub8'
/home/sra01/php5.2-200610080230/ext/oci8/php_oci8_int.h:343: error:
expected declaration specifiers or '...' before 'oraub8'
*** Error exit code 1


-- 
Edit bug report at http://bugs.php.net/?id=39178&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39178&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39178&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39178&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39178&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39178&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39178&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39178&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39178&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39178&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39178&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39178&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39178&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39178&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39178&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39178&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39178&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39178&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39178&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39178&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39178&r=mysqlcfg

#39176 [Opn->Fbk]: php segfaults in zend_get_extension

[iliaa]

 ID:   39176
 Updated by:   [EMAIL PROTECTED]
 Reported By:  prometheus__0 at hotmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux Sles10
 PHP Version:  5.1.6
 New Comment:

What zend extensions do you have loaded?

Also can you print the value of extension->name ?


Previous Comments:


[2006-10-17 15:37:44] prometheus__0 at hotmail dot com

Description:

a pointer isn't checked within zend_extension.c which can cause
segfaults

i had the problem using current version of DBG extension no as
zend_extension installed

but the cause of this is a not validated pointer

i checked actual php5.2 CSV and the bug can also be found there on line
221 of file Zend/zend_extension.c
---
zend_extension *extension = (zend_extension *) element->data;
if (!strcmp(extension->name, extension_name)) {
return extension;
}
---
extension isn't checked if it is NULL and strcmp doesn't care
extension_name was correct as seen in the backtrace

Reproduce code:
---
host:/home/testuser # php5 -r 'print "BUGG";'
BUGGSegmentation fault
host:/home/testuser #


Expected result:

host:/home/testuser # php5 -r 'print "BUGG";'
BUGG
host:/home/testuser #

Actual result:
--
(gdb) run -r 'print "BUGG";'
Starting program: /usr/bin/php5 -r 'print "BUGG";'
[Thread debugging using libthread_db enabled]
[New Thread 182910915616 (LWP 20652)]
BUGG
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182910915616 (LWP 20652)]
0x002a963b73c3 in strcmp () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x002a963b73c3 in strcmp () from /lib64/tls/libc.so.6
#1  0x0054cb96 in zend_get_extension
(extension_name=0x2a9727629d "DBG") at
/usr/src/debug/php-5.1.6/Zend/zend_extensions.c:221
#2  0x002a9726e50c in zm_shutdown_dbg (type=,
module_number=18) at /home/mcls/dbg-2.15.1/dbg.c:926
#3  0x00548613 in module_destructor (module=0x7fe030) at
/usr/src/debug/php-5.1.6/Zend/zend_API.c:1811
#4  0x0054dc86 in zend_hash_apply_deleter (ht=0x79ed20,
p=0x7fdfd0) at /usr/src/debug/php-5.1.6/Zend/zend_hash.c:576
#5  0x0054de68 in zend_hash_graceful_reverse_destroy
(ht=0x79ed20) at /usr/src/debug/php-5.1.6/Zend/zend_hash.c:642
#6  0x005443d7 in zend_shutdown () at
/usr/src/debug/php-5.1.6/Zend/zend.c:728
#7  0x0050699a in php_module_shutdown () at
/usr/src/debug/php-5.1.6/main/main.c:1618
#8  0x005b70d0 in main (argc=3, argv=0x7fb498) at
/usr/src/debug/php-5.1.6/sapi/cli/php_cli.c:1252
(gdb)






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

#38842 [Com]: PDO nextRowset not working on MySQL

[mike at we11er dot co dot uk]

 ID:   38842
 Comment by:   mike at we11er dot co dot uk
 Reported By:  stochnagara at hotmail dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: windows xp
 PHP Version:  5CVS-2006-09-15 (snap)
 New Comment:

Err, sorry... that last error should be:

PDOStatement::execute() [function.PDOStatement-execute]:
SQLSTATE[HY000]: General error: 2013 Lost connection to MySQL server
during query


Previous Comments:


[2006-10-17 16:03:32] mike at we11er dot co dot uk

IMO this is a bug. If a stored procedure is called, it returns multiple
row sets, one for each query inside it that returns results, and one for
the return status.

Because all the results from a statement must be fetched before
subsequent statements can be made, we NEED nextRowset to work otherwise
the following error is received:

PDOStatement::nextRowset() [function.PDOStatement-nextRowset]:
SQLSTATE[HYC00]: Optional feature not implemented

closeCursor() does not work when multiple rowsets are present.



[2006-09-18 07:35:53] [EMAIL PROTECTED]

"Optional feature not implemented" means this functionality is not yet
available. Which in turn means it's feature request.



[2006-09-18 06:35:02] stochnagara at hotmail dot com

Sorry, this is not a feature request but a PDO related bug.



[2006-09-15 11:20:21] stochnagara at hotmail dot com

Description:

Calling nextRowset on PDOStatement generates an error.

Reproduce code:
---
$pdo = new PDO ('mysql:...');
$q = $pdo->query ("CALL some_proc");
$q->nextRowset();

or for example

$pdo = new PDO ('mysql:...');
$q = $pdo->query ("SELECT 1; SELECT 2;");
$q->nextRowset();


Expected result:

No errors.

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HYC00]: Optional feature not implemented' in ...





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

#38842 [Com]: PDO nextRowset not working on MySQL

[mike at we11er dot co dot uk]

 ID:   38842
 Comment by:   mike at we11er dot co dot uk
 Reported By:  stochnagara at hotmail dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: windows xp
 PHP Version:  5CVS-2006-09-15 (snap)
 New Comment:

IMO this is a bug. If a stored procedure is called, it returns multiple
row sets, one for each query inside it that returns results, and one for
the return status.

Because all the results from a statement must be fetched before
subsequent statements can be made, we NEED nextRowset to work otherwise
the following error is received:

PDOStatement::nextRowset() [function.PDOStatement-nextRowset]:
SQLSTATE[HYC00]: Optional feature not implemented

closeCursor() does not work when multiple rowsets are present.


Previous Comments:


[2006-09-18 07:35:53] [EMAIL PROTECTED]

"Optional feature not implemented" means this functionality is not yet
available. Which in turn means it's feature request.



[2006-09-18 06:35:02] stochnagara at hotmail dot com

Sorry, this is not a feature request but a PDO related bug.



[2006-09-15 11:20:21] stochnagara at hotmail dot com

Description:

Calling nextRowset on PDOStatement generates an error.

Reproduce code:
---
$pdo = new PDO ('mysql:...');
$q = $pdo->query ("CALL some_proc");
$q->nextRowset();

or for example

$pdo = new PDO ('mysql:...');
$q = $pdo->query ("SELECT 1; SELECT 2;");
$q->nextRowset();


Expected result:

No errors.

Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HYC00]: Optional feature not implemented' in ...





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

#39176 [NEW]: php segfaults in zend_get_extension

[prometheus__0 at hotmail dot com]

From: prometheus__0 at hotmail dot com
Operating system: Linux Sles10
PHP version:  5.1.6
PHP Bug Type: Reproducible crash
Bug description:  php segfaults in zend_get_extension

Description:

a pointer isn't checked within zend_extension.c which can cause segfaults

i had the problem using current version of DBG extension no as
zend_extension installed

but the cause of this is a not validated pointer

i checked actual php5.2 CSV and the bug can also be found there on line
221 of file Zend/zend_extension.c
---
zend_extension *extension = (zend_extension *) element->data;
if (!strcmp(extension->name, extension_name)) {
return extension;
}
---
extension isn't checked if it is NULL and strcmp doesn't care
extension_name was correct as seen in the backtrace

Reproduce code:
---
host:/home/testuser # php5 -r 'print "BUGG";'
BUGGSegmentation fault
host:/home/testuser #


Expected result:

host:/home/testuser # php5 -r 'print "BUGG";'
BUGG
host:/home/testuser #

Actual result:
--
(gdb) run -r 'print "BUGG";'
Starting program: /usr/bin/php5 -r 'print "BUGG";'
[Thread debugging using libthread_db enabled]
[New Thread 182910915616 (LWP 20652)]
BUGG
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182910915616 (LWP 20652)]
0x002a963b73c3 in strcmp () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x002a963b73c3 in strcmp () from /lib64/tls/libc.so.6
#1  0x0054cb96 in zend_get_extension (extension_name=0x2a9727629d
"DBG") at /usr/src/debug/php-5.1.6/Zend/zend_extensions.c:221
#2  0x002a9726e50c in zm_shutdown_dbg (type=,
module_number=18) at /home/mcls/dbg-2.15.1/dbg.c:926
#3  0x00548613 in module_destructor (module=0x7fe030) at
/usr/src/debug/php-5.1.6/Zend/zend_API.c:1811
#4  0x0054dc86 in zend_hash_apply_deleter (ht=0x79ed20,
p=0x7fdfd0) at /usr/src/debug/php-5.1.6/Zend/zend_hash.c:576
#5  0x0054de68 in zend_hash_graceful_reverse_destroy (ht=0x79ed20)
at /usr/src/debug/php-5.1.6/Zend/zend_hash.c:642
#6  0x005443d7 in zend_shutdown () at
/usr/src/debug/php-5.1.6/Zend/zend.c:728
#7  0x0050699a in php_module_shutdown () at
/usr/src/debug/php-5.1.6/main/main.c:1618
#8  0x005b70d0 in main (argc=3, argv=0x7fb498) at
/usr/src/debug/php-5.1.6/sapi/cli/php_cli.c:1252
(gdb)


-- 
Edit bug report at http://bugs.php.net/?id=39176&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39176&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39176&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39176&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39176&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39176&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39176&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39176&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39176&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39176&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39176&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39176&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39176&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39176&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39176&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39176&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39176&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39176&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39176&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39176&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39176&r=mysqlcfg

#39107 [Opn->Bgs]: Double PHPSESSID when accessing www.mysite.com Or mysite.com

[mgf]

 ID:   39107
 Updated by:   [EMAIL PROTECTED]
 Reported By:  misc05 at blueyonder dot co dot uk
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.4.4
 New Comment:

This is really a support issue that should be aired in the php-general
mailing list, but I'll drop a couple of hints here anyway.

(i) if you're relying on cookies to pass the session-id, that cannot
work as cookies set at example.com can't be read at www.example.com

(ii) PHP's URL-rewriter also doesn't work, for similar security
reasons, for URLs that are at a different apparent domain (nor, come to
that, for any URL in header()!).

(iii) therefore you have to pass it manually as either a GET or a POST
parameter; session_name() and session_id() are useful here.


Previous Comments:


[2006-10-17 12:28:50] misc05 at blueyonder dot co dot uk

No eric - the issue is neither complicated nor is it bogus.

Try the simple code I placed in the first message and you will see 2
sessions started if the site in not originally accessed using www.
pre-pended to the address instead of one session.

QUOTE:
When accessing "example.com", the same session will be available at
"www.example.com".

This is not true and is exactly what I'm reporting.

Connect to  "example.com" and the second file above (store.php) will
have a different session to the first file.



[2006-10-17 11:48:46] eric at footsteps dot nl

Nigel, I'm not sure wether I understand your issue, but it seems to be
a bogus.

When accessing "example.com", the same session will be available at
"www.example.com".

Hoewever. When accessing "www.example.com", the sessions cookie set
there, is outside the scope for "example.com" which is fixed by the
session_set_cookie_params function call. Which takes similar parameters
as setcookie. With this function you should set the cookie domain scope
to "example.com" instead of the default current domain.

If the PHPSESSID cookie would be correct for both domains but the
session is just "lost" (which prob. trigger php to regenerate a session
id) you should check what "session_save_path" both sites use. Your
server may be using different save paths for both subdomains.

Good luck and regards,
Eric



[2006-10-11 14:42:32] misc05 at blueyonder dot co dot uk

Technically I'm intregued but its way over the top surely tony?

There must be a better way to prevent a spurious sessionID than having
two copies of everything running? I doubt my ISP would like the idea
too much either...

Do we know where PHP gets the host value to put in the PHPSESSID in the
first place?  Could I perhaps just change the value in there before the
first session is created ?

(I did try changing $_SERVER['HTTP_HOST'] but that didnt do it.)

nigel.



[2006-10-11 09:53:40] [EMAIL PROTECTED]

You don't have to touch a working site or a working Apache.
PHP can be installed locally or using different Apache on different
port.



[2006-10-11 07:29:51] misc05 at blueyonder dot co dot uk

Thanks tony but like I said -

"I would appreciate a work-around if anyone can supply one as I use an
ISP and can't update PHP."

If I could I'd upgrade (My development system uses the latest release)
but like many thousands of sites I can't upgrade my live site. Perhaps
a modification of the versions drop-down to this bug system to take
this into account would help others too.

Also CVS would be out of the question for a live eCommerce site anyway.
I would only consider stable releases marked as such. Public access to
CVS is a massive mistake. Huge.

Whatever happens I'm going to need a work-around for this.
I could use suggestions - 
thanks

nigel.



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

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

#39174 [Csd->Bgs]: mysql_connect() returns NULL

[tony2001]

 ID:   39174
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tjerk dot meesters at gmail dot com
-Status:   Closed
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Linux 2.6
 PHP Version:  5.1.6


Previous Comments:


[2006-10-17 14:34:11] tjerk dot meesters at gmail dot com

Argh, I can't believe how stupid that was ... mea culpa



[2006-10-17 13:11:54] [EMAIL PROTECTED]

var_dump() is function you are looking for.
var_export() exports variables to a parsaable strings, but resources
cannot be represented as strings due to their nature.



[2006-10-17 12:05:55] tjerk dot meesters at gmail dot com

Description:

A simple mysql_connect() returned NULL for this particular
configuration of PHP: 
--with-mysql=/usr/lib/mysql
--with-mysql-sock=/var/run/mysqld/mysqld.sock
--with-mysqli=/usr/bin/mysql_config
--with-pdo-mysql=/usr

When the script is ran with wrong login credentials, mysql_connect()
returns false as documented. However, when everything checks out no
errors are thrown and NULL is returned instead of a resource.

This is not documented behaviour as far as I know ;-)

Reproduce code:
---



Expected result:

"Resource #1" (or something similar)

Actual result:
--
"NULL"

A strace on the process returns the following:
...
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_SETFL, O_RDONLY)   = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(3, {sa_family=AF_FILE, path="/var/run/mysqld/mysqld.sock"},
110) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
setsockopt(3, SOL_IP, IP_TOS, [8], 4)   = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 6) = 1
read(3, "9\0\0\0\n5.0.24a-log\0\331\1\0\0TOlT=vZ?\0,\242"..., 16384) =
61
brk(0x8747000)  = 0x8747000
stat64("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0644,
st_size=18221, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY|O_LARGEFILE) = 4
read(4, "[EMAIL PROTECTED]"...,
66) = 66
read(3, "\7\0\0\2\0\0\0\2\0\0\0", 16384) = 11
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f0
write(1, "NULL", 4NULL) = 4
close(0)= 0

An ldd on the php cli:
...
   libmysqlclient.so.15 => /usr/lib/mysql/libmysqlclient.so.15
(0xb78f6000)






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

#39174 [Bgs->Csd]: mysql_connect() returns NULL

[tjerk dot meesters at gmail dot com]

 ID:   39174
 User updated by:  tjerk dot meesters at gmail dot com
 Reported By:  tjerk dot meesters at gmail dot com
-Status:   Bogus
+Status:   Closed
 Bug Type: MySQL related
 Operating System: Linux 2.6
 PHP Version:  5.1.6
 New Comment:

Argh, I can't believe how stupid that was ... mea culpa


Previous Comments:


[2006-10-17 13:11:54] [EMAIL PROTECTED]

var_dump() is function you are looking for.
var_export() exports variables to a parsaable strings, but resources
cannot be represented as strings due to their nature.



[2006-10-17 12:05:55] tjerk dot meesters at gmail dot com

Description:

A simple mysql_connect() returned NULL for this particular
configuration of PHP: 
--with-mysql=/usr/lib/mysql
--with-mysql-sock=/var/run/mysqld/mysqld.sock
--with-mysqli=/usr/bin/mysql_config
--with-pdo-mysql=/usr

When the script is ran with wrong login credentials, mysql_connect()
returns false as documented. However, when everything checks out no
errors are thrown and NULL is returned instead of a resource.

This is not documented behaviour as far as I know ;-)

Reproduce code:
---



Expected result:

"Resource #1" (or something similar)

Actual result:
--
"NULL"

A strace on the process returns the following:
...
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_SETFL, O_RDONLY)   = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(3, {sa_family=AF_FILE, path="/var/run/mysqld/mysqld.sock"},
110) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
setsockopt(3, SOL_IP, IP_TOS, [8], 4)   = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 6) = 1
read(3, "9\0\0\0\n5.0.24a-log\0\331\1\0\0TOlT=vZ?\0,\242"..., 16384) =
61
brk(0x8747000)  = 0x8747000
stat64("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0644,
st_size=18221, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY|O_LARGEFILE) = 4
read(4, "[EMAIL PROTECTED]"...,
66) = 66
read(3, "\7\0\0\2\0\0\0\2\0\0\0", 16384) = 11
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f0
write(1, "NULL", 4NULL) = 4
close(0)= 0

An ldd on the php cli:
...
   libmysqlclient.so.15 => /usr/lib/mysql/libmysqlclient.so.15
(0xb78f6000)






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

#39175 [Opn->Bgs]: We have a php message board, www.thedarkevolution.com, that seems to be down.

[tony2001]

 ID:   39175
 Updated by:   [EMAIL PROTECTED]
 Reported By:  otavio dot maciel at ge dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Web Server problem
 Operating System: Windows XP
 PHP Version:  4.4.4
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2006-10-17 14:00:41] otavio dot maciel at ge dot com

Description:

Hi, I didnt know where to go to submit this, so pls direct it to the
right place if this is not it.  We have a php message board that is
down at the moment, www.thedarkevolution.com
(mxomatrix.com/darkevolution)  - I can't get in touch with the
webmaster at the moment, so Im not sure if its something he did/didnt
do, or if there are server problems in general.  Im also an Admin on
the site and would like to see what can be done to help fix this issue.
 Unfortunately, I dont know the webmasters personal info with your
company, but if its a case of a billing issue, please let me know, and
I will provide my own CC information to get the site back up and
running.  We are a gaming community and that site is the only way we
stay together and its been down since yesterday at noon. Thanks in
advance for your help - contact me at email above. (ps: I put down
version 4.4.4 but im not really sure what we have, I just needed to put
something down)






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

#39175 [NEW]: We have a php message board, www.thedarkevolution.com, that seems to be down.

[otavio dot maciel at ge dot com]

From: otavio dot maciel at ge dot com
Operating system: Windows XP
PHP version:  4.4.4
PHP Bug Type: *Web Server problem
Bug description:  We have a php message board, www.thedarkevolution.com, that 
seems to be down.

Description:

Hi, I didnt know where to go to submit this, so pls direct it to the right
place if this is not it.  We have a php message board that is down at the
moment, www.thedarkevolution.com (mxomatrix.com/darkevolution)  - I can't
get in touch with the webmaster at the moment, so Im not sure if its
something he did/didnt do, or if there are server problems in general.  Im
also an Admin on the site and would like to see what can be done to help
fix this issue.  Unfortunately, I dont know the webmasters personal info
with your company, but if its a case of a billing issue, please let me
know, and I will provide my own CC information to get the site back up and
running.  We are a gaming community and that site is the only way we stay
together and its been down since yesterday at noon. Thanks in advance for
your help - contact me at email above. (ps: I put down version 4.4.4 but
im not really sure what we have, I just needed to put something down)


-- 
Edit bug report at http://bugs.php.net/?id=39175&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39175&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39175&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39175&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39175&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39175&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39175&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39175&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39175&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39175&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39175&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39175&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39175&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39175&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39175&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39175&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39175&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39175&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39175&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39175&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39175&r=mysqlcfg

#39174 [Opn->Bgs]: mysql_connect() returns NULL

[tony2001]

 ID:   39174
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tjerk dot meesters at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Linux 2.6
 PHP Version:  5.1.6
 New Comment:

var_dump() is function you are looking for.
var_export() exports variables to a parsaable strings, but resources
cannot be represented as strings due to their nature.


Previous Comments:


[2006-10-17 12:05:55] tjerk dot meesters at gmail dot com

Description:

A simple mysql_connect() returned NULL for this particular
configuration of PHP: 
--with-mysql=/usr/lib/mysql
--with-mysql-sock=/var/run/mysqld/mysqld.sock
--with-mysqli=/usr/bin/mysql_config
--with-pdo-mysql=/usr

When the script is ran with wrong login credentials, mysql_connect()
returns false as documented. However, when everything checks out no
errors are thrown and NULL is returned instead of a resource.

This is not documented behaviour as far as I know ;-)

Reproduce code:
---



Expected result:

"Resource #1" (or something similar)

Actual result:
--
"NULL"

A strace on the process returns the following:
...
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_SETFL, O_RDONLY)   = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(3, {sa_family=AF_FILE, path="/var/run/mysqld/mysqld.sock"},
110) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
setsockopt(3, SOL_IP, IP_TOS, [8], 4)   = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 6) = 1
read(3, "9\0\0\0\n5.0.24a-log\0\331\1\0\0TOlT=vZ?\0,\242"..., 16384) =
61
brk(0x8747000)  = 0x8747000
stat64("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0644,
st_size=18221, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY|O_LARGEFILE) = 4
read(4, "[EMAIL PROTECTED]"...,
66) = 66
read(3, "\7\0\0\2\0\0\0\2\0\0\0", 16384) = 11
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7f0
write(1, "NULL", 4NULL) = 4
close(0)= 0

An ldd on the php cli:
...
   libmysqlclient.so.15 => /usr/lib/mysql/libmysqlclient.so.15
(0xb78f6000)






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

#39107 [Opn]: Double PHPSESSID when accessing www.mysite.com Or mysite.com

[misc05 at blueyonder dot co dot uk]

 ID:   39107
 User updated by:  misc05 at blueyonder dot co dot uk
 Reported By:  misc05 at blueyonder dot co dot uk
 Status:   Open
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  4.4.4
 New Comment:

No eric - the issue is neither complicated nor is it bogus.

Try the simple code I placed in the first message and you will see 2
sessions started if the site in not originally accessed using www.
pre-pended to the address instead of one session.

QUOTE:
When accessing "example.com", the same session will be available at
"www.example.com".

This is not true and is exactly what I'm reporting.

Connect to  "example.com" and the second file above (store.php) will
have a different session to the first file.


Previous Comments:


[2006-10-17 11:48:46] eric at footsteps dot nl

Nigel, I'm not sure wether I understand your issue, but it seems to be
a bogus.

When accessing "example.com", the same session will be available at
"www.example.com".

Hoewever. When accessing "www.example.com", the sessions cookie set
there, is outside the scope for "example.com" which is fixed by the
session_set_cookie_params function call. Which takes similar parameters
as setcookie. With this function you should set the cookie domain scope
to "example.com" instead of the default current domain.

If the PHPSESSID cookie would be correct for both domains but the
session is just "lost" (which prob. trigger php to regenerate a session
id) you should check what "session_save_path" both sites use. Your
server may be using different save paths for both subdomains.

Good luck and regards,
Eric



[2006-10-11 14:42:32] misc05 at blueyonder dot co dot uk

Technically I'm intregued but its way over the top surely tony?

There must be a better way to prevent a spurious sessionID than having
two copies of everything running? I doubt my ISP would like the idea
too much either...

Do we know where PHP gets the host value to put in the PHPSESSID in the
first place?  Could I perhaps just change the value in there before the
first session is created ?

(I did try changing $_SERVER['HTTP_HOST'] but that didnt do it.)

nigel.



[2006-10-11 09:53:40] [EMAIL PROTECTED]

You don't have to touch a working site or a working Apache.
PHP can be installed locally or using different Apache on different
port.



[2006-10-11 07:29:51] misc05 at blueyonder dot co dot uk

Thanks tony but like I said -

"I would appreciate a work-around if anyone can supply one as I use an
ISP and can't update PHP."

If I could I'd upgrade (My development system uses the latest release)
but like many thousands of sites I can't upgrade my live site. Perhaps
a modification of the versions drop-down to this bug system to take
this into account would help others too.

Also CVS would be out of the question for a live eCommerce site anyway.
I would only consider stable releases marked as such. Public access to
CVS is a massive mistake. Huge.

Whatever happens I'm going to need a work-around for this.
I could use suggestions - 
thanks

nigel.



[2006-10-10 13:45:58] [EMAIL PROTECTED]

Please try using this CVS snapshot:

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





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

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

#39174 [NEW]: mysql_connect() returns NULL

[tjerk dot meesters at gmail dot com]

From: tjerk dot meesters at gmail dot com
Operating system: Linux 2.6
PHP version:  5.1.6
PHP Bug Type: MySQL related
Bug description:  mysql_connect() returns NULL

Description:

A simple mysql_connect() returned NULL for this particular configuration
of PHP: 
--with-mysql=/usr/lib/mysql
--with-mysql-sock=/var/run/mysqld/mysqld.sock
--with-mysqli=/usr/bin/mysql_config
--with-pdo-mysql=/usr

When the script is ran with wrong login credentials, mysql_connect()
returns false as documented. However, when everything checks out no errors
are thrown and NULL is returned instead of a resource.

This is not documented behaviour as far as I know ;-)

Reproduce code:
---



Expected result:

"Resource #1" (or something similar)

Actual result:
--
"NULL"

A strace on the process returns the following:
...
socket(PF_FILE, SOCK_STREAM, 0) = 3
fcntl64(3, F_SETFL, O_RDONLY)   = 0
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0
connect(3, {sa_family=AF_FILE, path="/var/run/mysqld/mysqld.sock"}, 110) =
0
fcntl64(3, F_SETFL, O_RDWR) = 0
setsockopt(3, SOL_IP, IP_TOS, [8], 4)   = -1 EOPNOTSUPP (Operation not
supported)
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 6) = 1
read(3, "9\0\0\0\n5.0.24a-log\0\331\1\0\0TOlT=vZ?\0,\242"..., 16384) = 61
brk(0x8747000)  = 0x8747000
stat64("/usr/share/mysql/charsets/Index.xml", {st_mode=S_IFREG|0644,
st_size=18221, ...}) = 0
open("/usr/share/mysql/charsets/Index.xml", O_RDONLY|O_LARGEFILE) = 4
read(4, "[EMAIL PROTECTED]"..., 66)
= 66
read(3, "\7\0\0\2\0\0\0\2\0\0\0", 16384) = 11
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7f0
write(1, "NULL", 4NULL) = 4
close(0)= 0

An ldd on the php cli:
...
   libmysqlclient.so.15 => /usr/lib/mysql/libmysqlclient.so.15
(0xb78f6000)


-- 
Edit bug report at http://bugs.php.net/?id=39174&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=39174&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=39174&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=39174&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39174&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=39174&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=39174&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39174&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39174&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=39174&r=support
Expected behavior:http://bugs.php.net/fix.php?id=39174&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=39174&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=39174&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39174&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=39174&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39174&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39174&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=39174&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=39174&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=39174&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39174&r=mysqlcfg

#39163 [Fbk->Opn]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.

[tony dot stone at gmail dot com]

 ID:   39163
 User updated by:  tony dot stone at gmail dot com
 Reported By:  tony dot stone at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Win32API related
 Operating System: Windows Vista RC 1 Build 5600
 PHP Version:  5.1.6
 New Comment:

No it doesn't.  I installed the following version:

16 Oct 2006 12:40:40 +0200
Version: 5.2.0RC6-dev
Branch


Previous Comments:


[2006-10-17 07:42:10] [EMAIL PROTECTED]

Does it work with 5.2.0 snapshots from http://snaps.php.net/ ?




[2006-10-17 00:43:25] tony dot stone at gmail dot com

PHP isn't crashing so there's no way to get a backtrace (that I know
of).  I did download the debug files and install them, but there's no
popup or window of any sort that would allow me to click Cancel or
enter a debug view.  PHP isn't technically crashing.  php5isapi.dll
is making an API call to the OS via the DefaultAppPool in IIS7 and the
DefaultAppPool is shutting down and generating an event log error,
which reads, "Failed to find the RegisterModule entrypoint in the
module DLL C:\Inetpub\PHP\php5isapi.dll.  The data is the error."

Maybe I'm just not getting it, but I don't see any way to get the
backtrace info per the directions
(http://bugs.php.net/bugs-generating-backtrace-win32.php) based on this
behavior.



[2006-10-16 07:30:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2006-10-16 02:45:27] tony dot stone at gmail dot com

Description:

I've seen a few other people post concerning random crashes, but my
issue can be reproduced every time I try to access any web page on my
server since configuring it to use php5isapi.dll

I am running Vista RC1 build 5600 with IIS 7 installed.  php5isapi.dll
appears to be making an API call not recognized by the OS.  Ever since
I installed PHP my DefaultAppPool stops when I access any web page on
my server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.

Details from App Log:
- System 

  - Provider 

   [ Name]  Microsoft-Windows-IIS-W3SVC-WP 
   [ Guid]  {670080D9-742A-4187-8D16-41143D1290BD} 
   [ EventSourceName]  W3SVC-WP 
 
  - EventID 2295 

   [ Qualifiers]  49152 
 
   Version 0 
 
   Level 2 
 
   Task 0 
 
   Opcode 0 
 
   Keywords 0x80 
 
  - TimeCreated 

   [ SystemTime]  2006-10-16T02:05:59.000Z 
 
   EventRecordID 1205 
 
   Correlation 
 
  - Execution 

   [ ProcessID]  0 
   [ ThreadID]  0 
 
   Channel Application 
 
   Computer epsilon 
 
   Security 
 
- EventData 

  ModuleDll C:\Inetpub\PHP\php5isapi.dll 
   7F00 








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

#39045 [Bgs]: Compilation of php_imap.c fails

[bnies at bluewin dot ch]

 ID:   39045
 User updated by:  bnies at bluewin dot ch
 Reported By:  bnies at bluewin dot ch
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: SunOS adnpool02 5.9 Generic_1122
 PHP Version:  5.1.6
 New Comment:

Answer from Rene Berber at imap-uw@u.washington.edu list:

==CUT==
Not much help from those guys at php's bugzilla...

The interesting part is the actual compile command which you included
in your
bug report, it is wrong but not your fault.

The compilation is wrong because you are using dynamic and at least one
static
library, c-client, so unless things have changed lately with gcc and
they made
it much smarter the link should specify explicitly the static library. 
This is
done in one of two ways, you can link the whole library by including
just its
name (whithout the -l) or you surround the link command (-static
-lc-client -dynamic).

I haven't tested this but the only easy way seems to do the linking
part by hand
(store the output of the build process with 'gmake | tee make.log',
then copy
that long command and execute it in the directory it is being executed
with one
of the changes).

BTW I'm not an imap developer and I don't speak for them; this is a
user's list.
I hope my comments are useful.
-- René Berber
==CUT==


Previous Comments:


[2006-10-16 13:04:50] [EMAIL PROTECTED]

Please report this problem to c-client developers.
Thank you.



[2006-10-16 11:57:44] bnies at bluewin dot ch

Tried snapshot php5.2-200610161030. Compilation goes one step further
but fails when linking against libc-client.a:

==CUT==
/bin/sh /tmp/php5.2-200610161030/libtool --silent --preserve-dup-deps
--mode=link gcc -I/usr/include -g -O2  -rpath
/tmp/php5.2-200610161030/libs
-avoid-version -module -L/usr/ucblib
-L/share/app/gnu/gcc/3.4.1/lib/gcc/sparc-sun-solaris2.8/3.4.1
-L/opt/adnwebmail/lib -R/opt/adnwebmail/lib -L/opt/adnwebmail/lib
-R/opt/adnwebmail/lib/sparcv9 -L/opt/adnwebmail/lib/sparcv9 -R
/usr/ucblib -R
/share/app/gnu/gcc/3.4.1/lib/gcc/sparc-sun-solaris2.8/3.4.1 -R
/opt/adnwebmail/lib ext/libxml/libxml.lo
ext/pcre/pcrelib/pcre_chartables.lo
ext/pcre/pcrelib/pcre_ucp_searchfuncs.lo
ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo
ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo
ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo
ext/pcre/pcrelib/pcre_info.lo ext/pcre/pcrelib/pcre_maketables.lo
ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo
ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo
ext/pcre/pcrelib/pcre_try_flipped.lo
ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo
ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/ctype/ctype.lo
ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo
ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo
ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo
ext/date/lib/unixtime2tm.lo ext/dom/php_dom.lo ext/dom/attr.lo
ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo
ext/dom/domexception.lo ext/dom/namelist.lo
ext/dom/processinginstruction.lo ext/dom/cdatasection.lo
ext/dom/documentfragment.lo ext/dom/domimplementation.lo
ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo
ext/dom/characterdata.lo ext/dom/documenttype.lo
ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo
ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo
ext/dom/domimplementationsource.lo ext/dom/entityreference.lo
ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo
ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo
ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/filter/filter.lo
ext/filter/sanitizing_filters.lo ext/filter/logical_filters.lo
ext/filter/callback_filter.lo
ext/hash/hash.lo ext/hash/hash_md.lo ext/hash/hash_sha.lo
ext/hash/hash_ripemd.lo ext/hash/hash_haval.lo ext/hash/hash_tiger.lo
ext/hash/hash_gost.lo ext/hash/hash_snefru.lo
ext/hash/hash_whirlpool.lo ext/hash/hash_adler32.lo
ext/hash/hash_crc32.lo ext/iconv/iconv.lo ext/imap/php_imap.lo
ext/json/json.lo ext/json/utf8_to_utf16.lo ext/json/utf8_decode.lo
ext/json/JSON_parser.lo ext/ldap/ldap.lo ext/pdo/pdo.lo
ext/pdo/pdo_dbh.lo ext/pdo/pdo_stmt.lo ext/pdo/pdo_sql_parser.lo
ext/pdo/pdo_sqlstate.lo ext/pdo_sqlite/pdo_sqlite.lo
ext/pdo_sqlite/sqlite_driver.lo ext/pdo_sqlite/sqlite_statement.lo
ext/pdo_sqlite/sqlite/src/attach.lo ext/pdo_sqlite/sqlite/src/auth.lo
ext/pdo_sqlite/sqlite/src/btree.lo ext/pdo_sqlite/sqlite/src/build.lo
ext/pdo_sqlite/sqlite/src/callback.lo ext/pdo_sqlite/sqlite/src/date.lo
ext/pdo_sqlite/sqlite/src/delete.lo ext/pdo_sqlite/sqlite/src/expr.lo
ext/pdo_sqlite/sqlite/src/func.lo ext/pdo_sqlite/sqlite/src/hash.lo
ext/pdo_sqlite/sqlite/src/insert.lo ext/pdo_sqlite/sqlite/src/legacy.lo
ext/pdo_sqlite/sqlite/src/main.lo ext/pdo_sq

#39170 [Opn->Bgs]: dbase_open no longer functions

[tony2001]

 ID:   39170
 Updated by:   [EMAIL PROTECTED]
 Reported By:  cory dot nemelka at nemelkaitgroup dot com
-Status:   Open
+Status:   Bogus
 Bug Type: dBase related
 Operating System: RHEL 3.0
 PHP Version:  5.1.6
 New Comment:

The file is currupted, even dbview is unable to open it.


Previous Comments:


[2006-10-17 04:48:07] cory dot nemelka at nemelkaitgroup dot com

previous version that could read these files was PHP v5.0.4, not
v5.0.3.



[2006-10-17 04:15:12] cory dot nemelka at nemelkaitgroup dot com

Also, to clarify, the dbase_open function works fine with non-Visual
Foxpro .dbf files.

If you'd like, I'll dig into this further by downloading the C code for
the dbase functions.  

lmk,
--cnemelka



[2006-10-17 04:11:29] cory dot nemelka at nemelkaitgroup dot com

You can download a small .dbf file at the following url that should not
open:

http://tinyurl.com/yce3bn



NOTE:
The .dbf files that won't open will also not open in Excel or Access
(they should).  However, PHP v5.0.3? was able to open these files ok.



[2006-10-17 04:08:54] cory dot nemelka at nemelkaitgroup dot com





[2006-10-16 20:24:06] [EMAIL PROTECTED]

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

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





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

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

#39173 [Csd->Bgs]: Return of DOMDocument methods misbehave if an error handler is set

[tony2001]

 ID:   39173
 Updated by:   [EMAIL PROTECTED]
 Reported By:  daniel dot gorski at develnet dot org
-Status:   Closed
+Status:   Bogus
-Bug Type: Scripting Engine problem
+Bug Type: DOM XML related
 Operating System: Linux
 PHP Version:  5.2.0RC5


Previous Comments:


[2006-10-17 05:19:25] daniel dot gorski at develnet dot org

Forget about this issue. I was wrong. Sorry.



[2006-10-17 04:39:47] daniel dot gorski at develnet dot org

To make it more clear:




claim that these methods:

[...] "Returns TRUE on success or FALSE on failure."

The behaviour is IMO different to invocations like @fopen, @feof etc.

Let there be light.



[2006-10-17 04:17:01] daniel dot gorski at develnet dot org

Description:

If the set_error_handler() is set, the DOM-methods do not care about
'@' if they run into an error/warning.

When one tries to load a broken XML document via the DOMDocument#load /
DOMDocument#loadXML (maybe others?) the warning won't be supressed, by
using '@' if the set_error_handler() has been set before.

If no set_error_handler() has been set before, the DOM methods behave
as expected in this very case.

The problem here is, that if one wants to use his own error handler,
the mentioned DOM functions will break the program flow, without any
chance of recovery.

>From my POV, this is easy to fix, but important to have. Please take a
look at it. Thank you.

Reproduce code:
---
loadXML('');
  // -^

  echo $flag ? 'Passed' : 'Failed';

?>

Expected result:

Output of 'Failed' string.

Actual result:
--
Error (Warning?):

DOMDocument::loadXML() [function.DOMDocument-loadXML]: Opening and
ending tag mismatch: BROKEN-ELEMENT line 1 and root in Entity, line: 1





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

#39167 [Opn->WFx]: oci8 compile with php on SunOS fails with undeclared symbol

[tony2001]

 ID:   39167
 Updated by:   [EMAIL PROTECTED]
 Reported By:  djdman2000 at hotmail dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: Compile Failure
 Operating System: SunOS 5.9
 PHP Version:  4.4.4
 New Comment:

Please use OCI8 from PECL.


Previous Comments:


[2006-10-16 16:00:25] djdman2000 at hotmail dot com

Description:

Issue make statement and receive:


/bin/sh /tmp/tomtmp/php-4.4.4/libtool --silent --preserve-dup-deps
--mode=compile gcc  -Iext/oci8/ -I/tmp/tomtmp/php-4.4.4/ext/oci8/
-DPHP_ATOM_INC -I/tmp/tomtmp/php-4.4.4/include
-I/tmp/tomtmp/php-4.4.4/main -I/tmp/tomtmp/php-4.4.4
-I/u03/oracle/product/oas101202mt_test/rdbms/public
-I/u03/oracle/product/oas101202mt_test/rdbms/demo
-I/u03/oracle/product/oas101202mt_test/plsql/public
-I/tmp/tomtmp/php-4.4.4/ext/xml/expat -I/tmp/tomtmp/php-4.4.4/TSRM
-I/tmp/tomtmp/php-4.4.4/Zend  -D_POSIX_PTHREAD_SEMANTICS  -g -O2   -c
/tmp/tomtmp/php-4.4.4/ext/oci8/oci8.c -o ext/oci8/oci8.lo
/tmp/tomtmp/php-4.4.4/ext/oci8/oci8.c: In function
`_oci_open_session':
/tmp/tomtmp/php-4.4.4/ext/oci8/oci8.c:2190: `OCI_NLS_CHARSET_ID'
undeclared (first use in this function)
/tmp/tomtmp/php-4.4.4/ext/oci8/oci8.c:2190: (Each undeclared identifier
is reported only once
/tmp/tomtmp/php-4.4.4/ext/oci8/oci8.c:2190: for each function it
appears in.)
*** Error code 1
make: Fatal error: Command failed for target `ext/oci8/oci8.lo'

in the oci.h, there is a similar line: #define OCI_NLS_CHARACTER_SET 55
  /* Character set name */

Reproduce code:
---
bash-2.05$ make

Expected result:

Expect the binary to be built






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

#39163 [Opn->Fbk]: Invalid API call from php5isapi.dll causing IIS7 Application Pool failure.

[edink]

 ID:   39163
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tony dot stone at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Win32API related
 Operating System: Windows Vista RC 1 Build 5600
 PHP Version:  5.1.6
 New Comment:

Does it work with 5.2.0 snapshots from http://snaps.php.net/ ?



Previous Comments:


[2006-10-17 00:43:25] tony dot stone at gmail dot com

PHP isn't crashing so there's no way to get a backtrace (that I know
of).  I did download the debug files and install them, but there's no
popup or window of any sort that would allow me to click Cancel or
enter a debug view.  PHP isn't technically crashing.  php5isapi.dll
is making an API call to the OS via the DefaultAppPool in IIS7 and the
DefaultAppPool is shutting down and generating an event log error,
which reads, "Failed to find the RegisterModule entrypoint in the
module DLL C:\Inetpub\PHP\php5isapi.dll.  The data is the error."

Maybe I'm just not getting it, but I don't see any way to get the
backtrace info per the directions
(http://bugs.php.net/bugs-generating-backtrace-win32.php) based on this
behavior.



[2006-10-16 07:30:10] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.





[2006-10-16 02:45:27] tony dot stone at gmail dot com

Description:

I've seen a few other people post concerning random crashes, but my
issue can be reproduced every time I try to access any web page on my
server since configuring it to use php5isapi.dll

I am running Vista RC1 build 5600 with IIS 7 installed.  php5isapi.dll
appears to be making an API call not recognized by the OS.  Ever since
I installed PHP my DefaultAppPool stops when I access any web page on
my server and it creates an error (Event ID 2295; Data 7F00) in the
Application Log.

Details from App Log:
- System 

  - Provider 

   [ Name]  Microsoft-Windows-IIS-W3SVC-WP 
   [ Guid]  {670080D9-742A-4187-8D16-41143D1290BD} 
   [ EventSourceName]  W3SVC-WP 
 
  - EventID 2295 

   [ Qualifiers]  49152 
 
   Version 0 
 
   Level 2 
 
   Task 0 
 
   Opcode 0 
 
   Keywords 0x80 
 
  - TimeCreated 

   [ SystemTime]  2006-10-16T02:05:59.000Z 
 
   EventRecordID 1205 
 
   Correlation 
 
  - Execution 

   [ ProcessID]  0 
   [ ThreadID]  0 
 
   Channel Application 
 
   Computer epsilon 
 
   Security 
 
- EventData 

  ModuleDll C:\Inetpub\PHP\php5isapi.dll 
   7F00 








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