#39319 [Bgs]: Problem to connect to SQLSERVER 2005
ID: 39319
User updated by: luiscervantesjane at hotmail dot com
Reported By: luiscervantesjane at hotmail dot com
Status: Bogus
Bug Type: MSSQL related
Operating System: WINDOWS 2003
PHP Version: 5.1.6
New Comment:
Hi.
Who can I configure this?
Have I to install Client Network Tools in the server web o reconfigure
the Client Network Tools has is installed in the MSSQL.
I have runnig other web server (XP Pro) and move the code in the other
PC and the connection is right. Do you know why..
Thanks
Previous Comments:
[2006-10-31 15:45:15] [EMAIL PROTECTED]
The MSSQL extension uses ntwdblib to connect to the server. This
Microsoft library can be configured with Netbios or TCP/IP as the
default library.
Use the Client Network Tools to specify the default protocol and to
create server aliases. A server alias can be defined to use a specific
host name and port numbr and you can use the alias as the first
parameter to mssql_connect().
[2006-10-31 11:03:36] luiscervantesjane at hotmail dot com
Description:
The web server are running in windows 2003, Version Apache/2.0.55
(Win32) PHP/5.1.6. And when I try to connect to MSSQL 2005 over
windows2003, I can`t.
If the code move to another server windows 2000, with the same Apache
Version, PHP 5.1.6. The connection is OK.
I belive that there are a problem the connection with SO windows2003
where are running php.
Thanks
Reproduce code:
---
$SERVER=SATURNO\SATURNO;
$USER=USER;
$PASSWD=PASSWORD;
$link = mssql_connect($SERVER, $USER, $PASSWD) or die (Could not
connect MSSQL);
mssql_select_db($DATABASE,$link) or die (Could not select database .
$DATABASE. in MSSQL);
$query = Select * form TABLA;
$result = mssql_query($link,$query);
while ($row = mssql_fetch_array($result)){
print $row['ALU_NOMBRE'] . bR;
}
Expected result:
Warning: mssql_connect() [function.mssql-connect]: Unable to connect to
server: SATURNO\SATURNO in C:\WEB\PRUEBAS\SQL2005\index2.php on line 5
Could not connect MSSQL
--
Edit this bug report at http://bugs.php.net/?id=39319edit=1
#39342 [NEW]: is_writable function
From: visit2imran at gmail dot com
Operating system: LInux
PHP version: 5.1.6
PHP Bug Type: Filesystem function related
Bug description: is_writable function
Description:
Hello,
Iam facing a strange problem, we have shifted our site to newserver.
Earlier our code was
if (is_writable($file_path_csv))
{
echo brPath=$file_path_csv;
}
This was working fine
now my code is not working..rather if is use
if (!is_writable($file_path_csv))
{
echo brPath=$file_path_csv;
}
it is working..
what could be the Problem?
please help.
Regards
--
Edit bug report at http://bugs.php.net/?id=39342edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39342r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39342r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39342r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39342r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39342r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39342r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39342r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39342r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39342r=support
Expected behavior:http://bugs.php.net/fix.php?id=39342r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39342r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39342r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39342r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39342r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39342r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39342r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39342r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39342r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39342r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39342r=mysqlcfg
#39343 [NEW]: PHP wont compile with latest Curl
From: steve dot kirtley at gmail dot com Operating system: Red Hat / Apache/1.3.26 PHP version: 4.4.4 PHP Bug Type: cURL related Bug description: PHP wont compile with latest Curl Description: Installed latest libcurl and curl libraries (no previous version) which worked fine with PHP 4.4.2 - however will not compile with 4.4.4 Reproduce code: --- Using following configure command, (which worked and still works with 4.4.2): ./configure --with-db --with-gdbm --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-oci8=/usr/local/oracle --enable-sigchild --enable-trans-sid --with-pgsq --with-curl=/usr/lib Configure is successful but errors shown below appear when running 'make' /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo Expected result: With PHP 4.4.2 installs without issues using same process. Have posted onto the curl mailing list who advised these PHP ext files are referencing deprecated functions. -- Edit bug report at http://bugs.php.net/?id=39343edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39343r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39343r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39343r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39343r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39343r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39343r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39343r=needscript Try newer version:http://bugs.php.net/fix.php?id=39343r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39343r=support Expected behavior:http://bugs.php.net/fix.php?id=39343r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39343r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39343r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39343r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39343r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39343r=dst IIS Stability:http://bugs.php.net/fix.php?id=39343r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39343r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39343r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39343r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39343r=mysqlcfg
#39344 [NEW]: Unnecessary calls to OnModify callback routine for an extension INI directive
From: wharmby at uk dot ibm dot com
Operating system: Windows XP
PHP version: 4CVS-2006-11-02 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Unnecessary calls to OnModify callback routine for an
extension INI directive
Description:
Unnecessary calls to OnModify callback routine for an
extension INI directives in ZTS enabled builds.
Please note the problem reported here only applies to ZTS
enabled builds.
I have tried the supplied testcase on the latest snap-shot
build for Windows (Nov 2, 2006 09:30 GMT)and the problem
persists. phpinfo() shows PHP Version = 5.2.1-dev.
Problem also persists in latest checked in version of file
in CVS.
If I define a OnMOdify callback routine for an extension INI
directive the routine is called multiple times during
startup even though the directive is not being continually
modified. I expected one call as a result of modification to
the directive in php.ini but instead I got 3 calls.
I spotted this behaviour reviewing the engine code whilst
reading Sara Golemon's book Extending and Embedding PHP
and include a slightly modified version of sample code
from her book to illustrate the unnecessary calls.
The first problem is that in a ZTS enabled build
zend_ini_refresh_caches() is called twice for each new
thread. The method zend_new_thread_end_handler() calls it
directly as follows:
static void zend_new_thread_end_handler(THREAD_T thread_id TSRMLS_DC)
{
zend_copy_ini_directives(TSRMLS_C);
zend_ini_refresh_caches(ZEND_INI_STAGE_STARTUP TSRMLS_CC);
}
However, zend_copy_ini_directives() itself also calls
zend_ini_refresh_caches() so we end up calling any OnModifty callback
routines twice for each new thread.
I believe that:
(1) the call in zend_copy_ini_directives() can safely be
removed, and
(2) the call in zend_new_thread_end_handler() should
really be conditional on the success of the copy
operation, otherwise we could attempt to iterate
over a non-existent hash and die.
This will reduce the number of calls to 2 on ZTS emabled builds but any
OnModifycallback routine will still be called twice on the startup thread
in ZTS enabled builds; once by zend_register_ini_entries() during MINIT
processing when an extension registers its INI directives and again on
ZTS
builds during zend_post_startup() processing, i.e
zend_post_startup() - zend_new_thread_end_handler() -
zend_ini_refresh_caches()
Whilst the call to the OnModify callback routine from
zend_register_ini_entries() is required for non-ZTS builds
to work correctly I can see no need for a call from
zend_ini_refresh_caches() during zend_post-startup
processing. I believe this can easily be resolved by
modifying zend_post_startup() to call
zend_copy_ini_directives()
instead of
zend_new_thread_end_handler()
My patch for zend.c is here: http://pastebin.ca/234196
and for zend_ini.c here: http://pastebin.ca/234200
Reproduce code:
---
Reproduce code is here: http://pastebin.ca/234201
I tested by adding the following to php.ini:
sample4.greeting=Hello Andy
or via command line as:
-dsample4.greeting=Hello Andy
Expected result:
When running using CLI on Windows, i.e a ZTS enabled build, I
expected to see 1 call to my extensions OnModify callback
routine for each thread attached; so in this simple case I expected to see
just the 1 call as follows:
sample 4: thread 0xfbc minit
sample 4: thread 0xfbc greeting modified..new value is Hello Andy
sample 4: thread 0xfbc minit
Hello Andy
Actual result:
--
The OnModify call back routine is in fact called 3 times; once
during MINIT processing and twice further. These last 2 are during the
call to zend_new_thread-end_handler().
sample 4: thread 0x16f8 minit
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
sample 4: thread 0x16f8 minit
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
Hello Andy
--
Edit bug report at http://bugs.php.net/?id=39344edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39344r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39344r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39344r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39344r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39344r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39344r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39344r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39344r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39344r=support
Expected behavior:http://bugs.php.net/fix.php?id=39344r=notwrong
Not enough info:
#39345 [NEW]: foreach($query as $row) gives PDO exception at ext\pdo_odbc\odbc_stmt.c:363
From: frederic dot fanchamps at skynet dot be
Operating system: Windows XP
PHP version: 5.1.6
PHP Bug Type: ODBC related
Bug description: foreach($query as $row) gives PDO exception at
ext\pdo_odbc\odbc_stmt.c:363
Description:
foreach($query as $row), $query coming from PDO, gives PDO exception at
ext\pdo_odbc\odbc_stmt.c:363 after reading the last row
Reproduce code:
---
?php
$d = new PDO('odbc:localdb2', 'frf', 'password');
$d-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
foreach ($d-query('select * from employee') as $row) {
/* some code, or not, does not matter */
}
?
Expected result:
no exception in the foreach
Actual result:
--
After reading the last row,
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[]: Unknown error: 0 (SQLFetchScroll[0] at
ext\pdo_odbc\odbc_stmt.c:363)' in C:\_work\test.php:5
Stack trace:
#0 C:\_work\test.php(5): unknown()
#1 {main}
thrown in C:\_work\test.php on line 5
--
Edit bug report at http://bugs.php.net/?id=39345edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39345r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39345r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39345r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39345r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39345r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39345r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39345r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39345r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39345r=support
Expected behavior:http://bugs.php.net/fix.php?id=39345r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39345r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39345r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39345r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39345r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39345r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39345r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39345r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39345r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39345r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39345r=mysqlcfg
#39346 [NEW]: Unsetting a static variable inside a destructor causes segfault later on
From: daan at parse dot nl
Operating system: Slackware 10.2
PHP version: 5.2.0RC5
PHP Bug Type: Reproducible crash
Bug description: Unsetting a static variable inside a destructor causes
segfault later on
Description:
Tested on 5.2.0RC6
Unsetting a static variable referring to the object itself causes a
segfault later on. (possible alloc problems)
I was able to reproduce segfaults in this situation with other functions
besides debug_backtrace(), for instance with mysqli_fetch_assoc(). The
resulting backtrace also led to _zend_mm_alloc_int. (I am presuming it is
the same bug)
PS. The print_r() is not required to trigger the crash.
Reproduce code:
---
?php
class test
{
protected $_id;
static $instances;
public function __construct($id)
{
$this-test();
$this-_id = $id;
self::$instances[$this-_id] = $this;
}
function __destruct()
{
unset(self::$instances[$this-_id]);
}
function test()
{
print_r(debug_backtrace());
}
}
$test = new test(2);
$test = new test(1);
$test = new test(2);
$test = new test(3);
?
Expected result:
No crash.
Actual result:
--
#0 _zend_mm_alloc_int (heap=0x80ebbb8, size=16) at
/usr/src/php-5.2.0RC6/Zend/zend_alloc.c:1090
#1 0x4063f953 in add_assoc_long_ex (arg=0x3, key=0x40769a60 line,
key_len=5, n=16) at /usr/src/php-5.2.0RC6/Zend/zend_API.c:977
#2 0x4064d2d8 in zend_fetch_debug_backtrace (return_value=0x40f289cc,
skip_last=1, provide_object=1)
at /usr/src/php-5.2.0RC6/Zend/zend_builtin_functions.c:1962
#3 0x40658d54 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffacc0) at
/usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:200
#4 0x40658489 in execute (op_array=0x40f282c8) at
/usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:92
#5 0x40658709 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffae80) at
/usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:234
#6 0x40658489 in execute (op_array=0x40f28fd4) at
/usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:92
#7 0x40658709 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffb0e0) at
/usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:234
#8 0x40658489 in execute (op_array=0x40f24194) at
/usr/src/php-5.2.0RC6/Zend/zend_vm_execute.h:92
#9 0x4063ebfc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/src/php-5.2.0RC6/Zend/zend.c:1097
#10 0x40604e2a in php_execute_script (primary_file=0xbfffd440) at
/usr/src/php-5.2.0RC6/main/main.c:1758
#11 0x406bf882 in apache_php_module_main (r=0x80cb5bc,
display_source_mode=0) at
/usr/src/php-5.2.0RC6/sapi/apache/sapi_apache.c:53
#12 0x406c0296 in send_php (r=0x80cb5bc, display_source_mode=0,
filename=0x0) at /usr/src/php-5.2.0RC6/sapi/apache/mod_php5.c:660
#13 0x406c04a6 in send_parsed_php (r=0x80cb5bc) at
/usr/src/php-5.2.0RC6/sapi/apache/mod_php5.c:675
#14 0x08053ff7 in ap_invoke_handler ()
#15 0x08069039 in process_request_internal ()
#16 0x08069098 in ap_process_request ()
#17 0x080600ba in child_main ()
#18 0x08060262 in make_child ()
#19 0x080603c8 in startup_children ()
#20 0x08060a88 in standalone_main ()
#21 0x080612a6 in main ()
--
Edit bug report at http://bugs.php.net/?id=39346edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39346r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39346r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39346r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39346r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39346r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39346r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39346r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39346r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39346r=support
Expected behavior:http://bugs.php.net/fix.php?id=39346r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39346r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39346r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39346r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39346r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39346r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39346r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39346r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39346r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39346r=nozend
MySQL Configuration
#39347 [NEW]: Error message
From: angela dot linden at atu dot edu
Operating system: Windows
PHP version: 4.4.4
PHP Bug Type: Compile Failure
Bug description: Error message
Description:
I get the following error:
Parse error: parse error, expecting `T_STRING' or `T_VARIABLE' or
`T_NUM_STRING' in /home/alinden/public_html/acme/register.php on line 21
I saw where someone else had sent this in with the same problem, but it
was an issue of one of the variables being inside quotes and mine is not
inside quotes.
Any insight you have would be appreciated. Thanks!
Reproduce code:
---
if (!$errors) {
mysql_connect('localhost','alinden','freeman')or
die(mysql_error());
mysql_select_db('alinden') or die(mysql_error());
$query = insert into Users (Name, Address, City, State, Zip,
Phone, Email, Username, Password, Approved, Admin) values '$Name',
'$Address', '$City',
'$State', '$Zip', '$Phone', '$Email', '$Username',
'$Password', '0', '0');
$result=mysql_query($query) or die(mysql_error());
$_SESSION[success]= p class=\success\Registration complete!
You will receive a confirmation email when you are approved./p;
$destination=template.php;
Header(Location:$destination);
exit;
}
else {
$errors[login]= p class=\error\There was an error with
your registration. Please try again./p;
$Name=;
$Address=;
$City=;
$State=;
$Zip=;
$Phone=;
$Email=;
$Username=;
$Password=;
}
--
Edit bug report at http://bugs.php.net/?id=39347edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39347r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39347r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39347r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39347r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39347r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39347r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39347r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39347r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39347r=support
Expected behavior:http://bugs.php.net/fix.php?id=39347r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39347r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39347r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39347r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39347r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39347r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39347r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39347r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39347r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39347r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39347r=mysqlcfg
#39347 [Opn-Bgs]: Error message
ID: 39347
Updated by: [EMAIL PROTECTED]
Reported By: angela dot linden at atu dot edu
-Status: Open
+Status: Bogus
Bug Type: Compile Failure
Operating System: Windows
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-11-02 17:26:14] angela dot linden at atu dot edu
Description:
I get the following error:
Parse error: parse error, expecting `T_STRING' or `T_VARIABLE' or
`T_NUM_STRING' in /home/alinden/public_html/acme/register.php on line
21
I saw where someone else had sent this in with the same problem, but it
was an issue of one of the variables being inside quotes and mine is not
inside quotes.
Any insight you have would be appreciated. Thanks!
Reproduce code:
---
if (!$errors) {
mysql_connect('localhost','alinden','freeman')or
die(mysql_error());
mysql_select_db('alinden') or die(mysql_error());
$query = insert into Users (Name, Address, City, State, Zip,
Phone, Email, Username, Password, Approved, Admin) values '$Name',
'$Address', '$City',
'$State', '$Zip', '$Phone', '$Email', '$Username',
'$Password', '0', '0');
$result=mysql_query($query) or die(mysql_error());
$_SESSION[success]= p class=\success\Registration
complete! You will receive a confirmation email when you are
approved./p;
$destination=template.php;
Header(Location:$destination);
exit;
}
else {
$errors[login]= p class=\error\There was an error with
your registration. Please try again./p;
$Name=;
$Address=;
$City=;
$State=;
$Zip=;
$Phone=;
$Email=;
$Username=;
$Password=;
}
--
Edit this bug report at http://bugs.php.net/?id=39347edit=1
#39319 [Bgs]: Problem to connect to SQLSERVER 2005
ID: 39319
Updated by: [EMAIL PROTECTED]
Reported By: luiscervantesjane at hotmail dot com
Status: Bogus
Bug Type: MSSQL related
Operating System: WINDOWS 2003
PHP Version: 5.1.6
New Comment:
The client tools are installed on the MSSQL server by default.
If the Web server and MSSQL server are running on the same box there is
no need for special actions.
If the web server is running on another box you can install the client
tools from the CD on the web server.
Previous Comments:
[2006-11-02 09:34:45] luiscervantesjane at hotmail dot com
Hi.
Who can I configure this?
Have I to install Client Network Tools in the server web o reconfigure
the Client Network Tools has is installed in the MSSQL.
I have runnig other web server (XP Pro) and move the code in the other
PC and the connection is right. Do you know why..
Thanks
[2006-10-31 15:45:15] [EMAIL PROTECTED]
The MSSQL extension uses ntwdblib to connect to the server. This
Microsoft library can be configured with Netbios or TCP/IP as the
default library.
Use the Client Network Tools to specify the default protocol and to
create server aliases. A server alias can be defined to use a specific
host name and port numbr and you can use the alias as the first
parameter to mssql_connect().
[2006-10-31 11:03:36] luiscervantesjane at hotmail dot com
Description:
The web server are running in windows 2003, Version Apache/2.0.55
(Win32) PHP/5.1.6. And when I try to connect to MSSQL 2005 over
windows2003, I can`t.
If the code move to another server windows 2000, with the same Apache
Version, PHP 5.1.6. The connection is OK.
I belive that there are a problem the connection with SO windows2003
where are running php.
Thanks
Reproduce code:
---
$SERVER=SATURNO\SATURNO;
$USER=USER;
$PASSWD=PASSWORD;
$link = mssql_connect($SERVER, $USER, $PASSWD) or die (Could not
connect MSSQL);
mssql_select_db($DATABASE,$link) or die (Could not select database .
$DATABASE. in MSSQL);
$query = Select * form TABLA;
$result = mssql_query($link,$query);
while ($row = mssql_fetch_array($result)){
print $row['ALU_NOMBRE'] . bR;
}
Expected result:
Warning: mssql_connect() [function.mssql-connect]: Unable to connect to
server: SATURNO\SATURNO in C:\WEB\PRUEBAS\SQL2005\index2.php on line 5
Could not connect MSSQL
--
Edit this bug report at http://bugs.php.net/?id=39319edit=1
#39342 [Com]: is_writable function
ID: 39342
Comment by: phpbugs at thequod dot de
Reported By: visit2imran at gmail dot com
Status: Open
Bug Type: Filesystem function related
Operating System: LInux
PHP Version: 5.1.6
New Comment:
Have you checked permissions on the file?
Probably, PHP is running with another user.
Previous Comments:
[2006-11-02 09:57:40] visit2imran at gmail dot com
Description:
Hello,
Iam facing a strange problem, we have shifted our site to newserver.
Earlier our code was
if (is_writable($file_path_csv))
{
echo brPath=$file_path_csv;
}
This was working fine
now my code is not working..rather if is use
if (!is_writable($file_path_csv))
{
echo brPath=$file_path_csv;
}
it is working..
what could be the Problem?
please help.
Regards
--
Edit this bug report at http://bugs.php.net/?id=39342edit=1
#39345 [Opn]: foreach($query as $row) gives PDO exception at ext\pdo_odbc\odbc_stmt.c:363
ID: 39345
User updated by: frederic dot fanchamps at skynet dot be
Reported By: frederic dot fanchamps at skynet dot be
Status: Open
Bug Type: ODBC related
Operating System: Windows XP
PHP Version: 5.1.6
New Comment:
I have tried with PHP 5.2.1-dev (cli) (built: Oct 31 2006 08:22:42) and
with this version the problem does not occur.
Previous Comments:
[2006-11-02 16:12:56] frederic dot fanchamps at skynet dot be
Description:
foreach($query as $row), $query coming from PDO, gives PDO exception at
ext\pdo_odbc\odbc_stmt.c:363 after reading the last row
Reproduce code:
---
?php
$d = new PDO('odbc:localdb2', 'frf', 'password');
$d-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
foreach ($d-query('select * from employee') as $row) {
/* some code, or not, does not matter */
}
?
Expected result:
no exception in the foreach
Actual result:
--
After reading the last row,
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[]: Unknown error: 0 (SQLFetchScroll[0] at
ext\pdo_odbc\odbc_stmt.c:363)' in C:\_work\test.php:5
Stack trace:
#0 C:\_work\test.php(5): unknown()
#1 {main}
thrown in C:\_work\test.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=39345edit=1
#39316 [Com]: extension_dir has no effect on Windows
ID: 39316 Comment by: noah dot rusnock at echo-digitaldesign dot com Reported By: aren at cambre dot biz Status: Open Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 5.1.6 New Comment: I have been dealing with this problem for months! I am using Windows XP SP2 with Apache 2.0.59 and PHP 5.1.6. I think I have had this issue since 5.1.4 or 5.1.3; I don't remember. I am new to PHP and Apache, but setup my own localhost server earlier this year (2006) and have had this problem from the beginning. (I added a vote, but submitted it as a 3; should be a 5; I need this working to start learning MySQL) Previous Comments: [2006-10-31 19:51:40] aren at cambre dot biz That did not fix it. I deleted everything in C:\php, including directories, except for php.ini. Then I copied over the contents of php5.2-win32-latest.zip and did an iisreset (a command line program that restarts the web server). By the way, it looks like php is checking a couple of additional directories besides those specified in the path. Here is my path (each directory on a separate line): %SystemRoot%\system32 %SystemRoot% %SystemRoot%\System32\Wbem c:\Program Files\Intel\DMIX C:\Program Files\Microsoft SQL Server\80\Tools\Binn\ c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\php Here is what PHP checks: C:\windows\system32\inetsrv\php_mysql.dll C:\WINDOWS\system32\php_mysql.dll C:\WINDOWS\system\php_mysql.dll C:\WINDOWS\php_mysql.dll C:\WINDOWS\system32\inetsrv\php_mysql.dll C:\WINDOWS\system32\php_mysql.dll C:\WINDOWS\php_mysql.dll C:\WINDOWS\System32\Wbem\php_mysql.dll C:\Program Files\Intel\DMIX\php_mysql.dll C:\Program Files\Microsoft SQL Server\80\Tools\Binn\php_mysql.dll C:\Program Files\Microsoft SQL Server\90\Tools\binn\php_mysql.dll C:\php\php_mysql.dll PHP follows the path exactly starting with the 6th line. The first 5 lines are some unknown set of directories. PHP checks those directories twice in a row. [2006-10-31 11:32:17] [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 [2006-10-31 04:49:18] aren at cambre dot biz Description: extension_dir (in php.ini) has no effect in Windows. I installed a relatively clean installation of PHP 5.1.6 on Windows 2003. I configured the extension_dir line in php.ini using all these forms: extension_dir = c:\PHP\ext extension_dir = c:\php\ext extension_dir = c:/PHP/ext extension_dir = c:\php\ext Regardless of the form used, php does not even attempt to search the c:\php\ext directory to find extensions. Reproduce code: --- 1. Install php 5.1.6 on a clean Windows system. Only configure what is necessary to get it running. Be sure to set extension_dir to your actual ext directory. (Preferably, c:\php\ext.) Do a hello world php to test functionality. 2. Uncomment this line in php.ini: extension=php_mysql.dll 3. Download the latest phpMyAdmin. Extract files and copy to a directory in your web server. 4. Get File Monitor from sysinternals (www.sysinternals.com). 5. Load File Monitor, and set its filter to php_mysql.dll. (This is so that it just reports on attempts to find php_mysql.dll and not hundreds of other filesystem hits.) 6. Start File Monitor so that it's catching filesystem hits. 7. Browse myPhpAdmin's index.php in a browser. You'll get an error saying that the mysql drivers cannot be used. 8. Go back to File Monitor. Notice how none of the directories searched were the directory specified in extension_dir. Installing mySql is optional. Its presence has no effect on the above problem. (Of course, if the system actually found php_mysql.dll, then it would be a problem if mySql was not installed!) Expected result: phpMyAdmin should find the mySql extension, and File Monitor should confirm that php actually searches the c:\php\ext directory for the extensions. Actual result: -- Php searches all directories in the system path! extension_dir has no effect under Windows. You have to add c:\php AND c:\php\ext to the system path. I think this is likely an application bug because the documentation is quite clear on how extension_dir should be configured. -- Edit this bug report at http://bugs.php.net/?id=39316edit=1
#39349 [NEW]: Core dump on preg_replace
From: nikolas dot hagelstein at gmail dot com
Operating system: Netbsd 3.0.1
PHP version: 5.2.0
PHP Bug Type: Reproducible crash
Bug description: Core dump on preg_replace
Description:
Passing large text to the beyond mentioned regexp makes php core dump
Reproduce code:
---
$out=preg_replace(/\{(?:[^{}]|\{(?:[^{}]|\{(?:[^{}]|\{[^{}]*\})*\})*\})*\}/,,$out);
Where $out is content xml:space=preserve of
http://en.wikipedia.org/w/query.php?what=contenttitles=moon
Probably related to some libc issues.
--
Edit bug report at http://bugs.php.net/?id=39349edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39349r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39349r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39349r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39349r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39349r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39349r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39349r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39349r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39349r=support
Expected behavior:http://bugs.php.net/fix.php?id=39349r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39349r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39349r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39349r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39349r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39349r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39349r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39349r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39349r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39349r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39349r=mysqlcfg
#39316 [Com]: extension_dir has no effect on Windows
ID: 39316 Comment by: noah dot rusnock at echo-digitaldesign dot com Reported By: aren at cambre dot biz Status: Open Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 5.1.6 New Comment: I just setup a Windows 2000 SP4 virtual machine using Microsoft VirturalPC 2007 beta. I used the exact same setup as I did for my Windows XP (non-virtual machine) Apache server with PHP and I am still unable to load any extensions. Previous Comments: [2006-11-02 20:50:11] noah dot rusnock at echo-digitaldesign dot com I have been dealing with this problem for months! I am using Windows XP SP2 with Apache 2.0.59 and PHP 5.1.6. I think I have had this issue since 5.1.4 or 5.1.3; I don't remember. I am new to PHP and Apache, but setup my own localhost server earlier this year (2006) and have had this problem from the beginning. (I added a vote, but submitted it as a 3; should be a 5; I need this working to start learning MySQL) [2006-10-31 19:51:40] aren at cambre dot biz That did not fix it. I deleted everything in C:\php, including directories, except for php.ini. Then I copied over the contents of php5.2-win32-latest.zip and did an iisreset (a command line program that restarts the web server). By the way, it looks like php is checking a couple of additional directories besides those specified in the path. Here is my path (each directory on a separate line): %SystemRoot%\system32 %SystemRoot% %SystemRoot%\System32\Wbem c:\Program Files\Intel\DMIX C:\Program Files\Microsoft SQL Server\80\Tools\Binn\ c:\Program Files\Microsoft SQL Server\90\Tools\binn\ c:\php Here is what PHP checks: C:\windows\system32\inetsrv\php_mysql.dll C:\WINDOWS\system32\php_mysql.dll C:\WINDOWS\system\php_mysql.dll C:\WINDOWS\php_mysql.dll C:\WINDOWS\system32\inetsrv\php_mysql.dll C:\WINDOWS\system32\php_mysql.dll C:\WINDOWS\php_mysql.dll C:\WINDOWS\System32\Wbem\php_mysql.dll C:\Program Files\Intel\DMIX\php_mysql.dll C:\Program Files\Microsoft SQL Server\80\Tools\Binn\php_mysql.dll C:\Program Files\Microsoft SQL Server\90\Tools\binn\php_mysql.dll C:\php\php_mysql.dll PHP follows the path exactly starting with the 6th line. The first 5 lines are some unknown set of directories. PHP checks those directories twice in a row. [2006-10-31 11:32:17] [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 [2006-10-31 04:49:18] aren at cambre dot biz Description: extension_dir (in php.ini) has no effect in Windows. I installed a relatively clean installation of PHP 5.1.6 on Windows 2003. I configured the extension_dir line in php.ini using all these forms: extension_dir = c:\PHP\ext extension_dir = c:\php\ext extension_dir = c:/PHP/ext extension_dir = c:\php\ext Regardless of the form used, php does not even attempt to search the c:\php\ext directory to find extensions. Reproduce code: --- 1. Install php 5.1.6 on a clean Windows system. Only configure what is necessary to get it running. Be sure to set extension_dir to your actual ext directory. (Preferably, c:\php\ext.) Do a hello world php to test functionality. 2. Uncomment this line in php.ini: extension=php_mysql.dll 3. Download the latest phpMyAdmin. Extract files and copy to a directory in your web server. 4. Get File Monitor from sysinternals (www.sysinternals.com). 5. Load File Monitor, and set its filter to php_mysql.dll. (This is so that it just reports on attempts to find php_mysql.dll and not hundreds of other filesystem hits.) 6. Start File Monitor so that it's catching filesystem hits. 7. Browse myPhpAdmin's index.php in a browser. You'll get an error saying that the mysql drivers cannot be used. 8. Go back to File Monitor. Notice how none of the directories searched were the directory specified in extension_dir. Installing mySql is optional. Its presence has no effect on the above problem. (Of course, if the system actually found php_mysql.dll, then it would be a problem if mySql was not installed!) Expected result: phpMyAdmin should find the mySql extension, and File Monitor should confirm that php actually searches the c:\php\ext directory for the extensions. Actual result: -- Php searches all directories in the system path! extension_dir has no effect under Windows. You have to add c:\php AND c:\php\ext to the system path. I think this is likely an application bug because the documentation is quite clear on how extension_dir should be configured. --
#39350 [NEW]: Segfault with implode(\n, array(false))
From: phpbugs at thequod dot de Operating system: Ubuntu Linux PHP version: 5CVS-2006-11-02 (CVS) PHP Bug Type: Reproducible crash Bug description: Segfault with implode(\n, array(false)) Description: When imploding/joining an array with only false in it, PHP segfaults (on shutdown?). I've found this in a more complex use case, where it segfaulted during execution, but probably because of this root problem. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208198976 (LWP 4071)] 0x083dd4f0 in _zval_dtor_func (zvalue=0xb7ebd8ec, __zend_filename=0x868524c /usr/local/src/PHP_5_2/Zend/zend_variables.h, __zend_lineno=35) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:35 35 CHECK_ZVAL_STRING_REL(zvalue); (gdb) bt #0 0x083dd4f0 in _zval_dtor_func (zvalue=0xb7ebd8ec, __zend_filename=0x868524c /usr/local/src/PHP_5_2/Zend/zend_variables.h, __zend_lineno=35) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:35 #1 0x083d02f8 in _zval_dtor (zvalue=0xb7ebd8ec, __zend_filename=0x86851e4 /usr/local/src/PHP_5_2/Zend/zend_execute_API.c, __zend_lineno=414) at /usr/local/src/PHP_5_2/Zend/zend_variables.h:35 #2 0x083d04ba in _zval_ptr_dtor (zval_ptr=0xb7ebd92c, __zend_filename=0x8686238 /usr/local/src/PHP_5_2/Zend/zend_variables.c, __zend_lineno=175) at /usr/local/src/PHP_5_2/Zend/zend_execute_API.c:414 #3 0x083dd92c in _zval_ptr_dtor_wrapper (zval_ptr=0xb7ebd92c) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:175 #4 0x083eb689 in zend_hash_apply_deleter (ht=0x86e2bb0, p=0xb7ebd920) at /usr/local/src/PHP_5_2/Zend/zend_hash.c:606 #5 0x083eb80d in zend_hash_graceful_reverse_destroy (ht=0x86e2bb0) at /usr/local/src/PHP_5_2/Zend/zend_hash.c:641 #6 0x083cff2b in shutdown_executor () at /usr/local/src/PHP_5_2/Zend/zend_execute_API.c:239 #7 0x083df05a in zend_deactivate () at /usr/local/src/PHP_5_2/Zend/zend.c:840 #8 0x0838b2fc in php_request_shutdown (dummy=0x0) at /usr/local/src/PHP_5_2/main/main.c:1300 #9 0x0845807b in main (argc=3, argv=0xbf81bf24) at /usr/local/src/PHP_5_2/sapi/cli/php_cli.c:1259 Reproduce code: --- ?php $a = array(false); $b = join(\n, $a); var_dump($b); echo 'bar'; ? Expected result: string(0) bar (PHP 5.1.6) Actual result: -- string(0) barSegmentation fault (core dumped) (PHP_5_2) -- Edit bug report at http://bugs.php.net/?id=39350edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39350r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39350r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39350r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39350r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39350r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39350r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39350r=needscript Try newer version:http://bugs.php.net/fix.php?id=39350r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39350r=support Expected behavior:http://bugs.php.net/fix.php?id=39350r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39350r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39350r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39350r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39350r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39350r=dst IIS Stability:http://bugs.php.net/fix.php?id=39350r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39350r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39350r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39350r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39350r=mysqlcfg
#39350 [Opn]: Segfault with implode(\n, array(false))
ID: 39350 User updated by: phpbugs at thequod dot de Reported By: phpbugs at thequod dot de Status: Open Bug Type: Reproducible crash Operating System: Ubuntu Linux PHP Version: 5CVS-2006-11-02 (CVS) New Comment: The crash can be reproduced inline, by $b = trim($b); after the implode(). Previous Comments: [2006-11-02 22:17:30] phpbugs at thequod dot de Description: When imploding/joining an array with only false in it, PHP segfaults (on shutdown?). I've found this in a more complex use case, where it segfaulted during execution, but probably because of this root problem. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208198976 (LWP 4071)] 0x083dd4f0 in _zval_dtor_func (zvalue=0xb7ebd8ec, __zend_filename=0x868524c /usr/local/src/PHP_5_2/Zend/zend_variables.h, __zend_lineno=35) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:35 35 CHECK_ZVAL_STRING_REL(zvalue); (gdb) bt #0 0x083dd4f0 in _zval_dtor_func (zvalue=0xb7ebd8ec, __zend_filename=0x868524c /usr/local/src/PHP_5_2/Zend/zend_variables.h, __zend_lineno=35) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:35 #1 0x083d02f8 in _zval_dtor (zvalue=0xb7ebd8ec, __zend_filename=0x86851e4 /usr/local/src/PHP_5_2/Zend/zend_execute_API.c, __zend_lineno=414) at /usr/local/src/PHP_5_2/Zend/zend_variables.h:35 #2 0x083d04ba in _zval_ptr_dtor (zval_ptr=0xb7ebd92c, __zend_filename=0x8686238 /usr/local/src/PHP_5_2/Zend/zend_variables.c, __zend_lineno=175) at /usr/local/src/PHP_5_2/Zend/zend_execute_API.c:414 #3 0x083dd92c in _zval_ptr_dtor_wrapper (zval_ptr=0xb7ebd92c) at /usr/local/src/PHP_5_2/Zend/zend_variables.c:175 #4 0x083eb689 in zend_hash_apply_deleter (ht=0x86e2bb0, p=0xb7ebd920) at /usr/local/src/PHP_5_2/Zend/zend_hash.c:606 #5 0x083eb80d in zend_hash_graceful_reverse_destroy (ht=0x86e2bb0) at /usr/local/src/PHP_5_2/Zend/zend_hash.c:641 #6 0x083cff2b in shutdown_executor () at /usr/local/src/PHP_5_2/Zend/zend_execute_API.c:239 #7 0x083df05a in zend_deactivate () at /usr/local/src/PHP_5_2/Zend/zend.c:840 #8 0x0838b2fc in php_request_shutdown (dummy=0x0) at /usr/local/src/PHP_5_2/main/main.c:1300 #9 0x0845807b in main (argc=3, argv=0xbf81bf24) at /usr/local/src/PHP_5_2/sapi/cli/php_cli.c:1259 Reproduce code: --- ?php $a = array(false); $b = join(\n, $a); var_dump($b); echo 'bar'; ? Expected result: string(0) bar (PHP 5.1.6) Actual result: -- string(0) barSegmentation fault (core dumped) (PHP_5_2) -- Edit this bug report at http://bugs.php.net/?id=39350edit=1
#39343 [Com]: PHP wont compile with latest Curl
ID: 39343 Comment by: daniel at haxx dot se Reported By: steve dot kirtley at gmail dot com Status: Open Bug Type: cURL related Operating System: Red Hat / Apache/1.3.26 PHP Version: 4.4.4 New Comment: 1. You cut off the build error too early so the error doesn't really show 2. They aren't deprecated _functions_, they are deprecated symbols == defines in the curl public header file. Previous Comments: [2006-11-02 11:04:23] steve dot kirtley at gmail dot com Description: Installed latest libcurl and curl libraries (no previous version) which worked fine with PHP 4.4.2 - however will not compile with 4.4.4 Reproduce code: --- Using following configure command, (which worked and still works with 4.4.2): ./configure --with-db --with-gdbm --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-oci8=/usr/local/oracle --enable-sigchild --enable-trans-sid --with-pgsq --with-curl=/usr/lib Configure is successful but errors shown below appear when running 'make' /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo Expected result: With PHP 4.4.2 installs without issues using same process. Have posted onto the curl mailing list who advised these PHP ext files are referencing deprecated functions. -- Edit this bug report at http://bugs.php.net/?id=39343edit=1
#33595 [Com]: recursive references leak memory
ID: 33595
Comment by: judas dot iscariote at gmail dot com
Reported By: rodricg at sellingsource dot com
Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 6CVS-2005-08-02
Assigned To: dmitry
New Comment:
taneli at crasman dot fi :
- This is a well known gotcha see [1]
- for the gory details, please see [2], this is not that easy to
fix.
1.
http://en.wikipedia.org/wiki/Reference_counting#Advantages_and_disadvantages
2. ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
Previous Comments:
[2006-11-01 09:07:48] taneli at crasman dot fi
Please address this bug, it's very short-sighted to rely on the fact
that memory is freed on shutdown (especially when your either your box
starts trashing or memory_limit kicks in and fails your request because
of a bug in the interpreter).
[2006-08-15 12:02:00] ruslan dot kyrychuk at gmail dot com
Maybe solutution can be to call destructor every time when new object
is assigned to old reference?
Example:
?php
class A {
function __construct () {
$this-b = new B($this);
}
function __destruct () {
$this-b-__destruct();
}
}
class B {
function __construct ($parent = NULL) {
$this-parent = $parent;
}
function __destruct () {
unset($this-parent);
}
}
for ($i = 0 ; $i 100 ; $i++) {
$a = new A();
$a-__destruct();
}
echo number_format(memory_get_usage());
?
$a-__destruct(); can be called automatically because new reference is
created. Then writing correct destructors will solve this issue.
Or maybe I missing something?
[2006-05-04 14:08:22] frode at coretrek dot com
I worked around this exact problem by using a proxy class with a
destructor that explicitly breaks the cycle; I got the idea from a
perl.com[1] article describing how perl suffers from the same problem.
It's also interesting to note that perl has chosen a different (less
elegant) solution to the problem than python, by introducing weak
references.
[1] http://www.perl.com/pub/a/2002/08/07/proxyobject.html
[2006-04-13 06:24:02] seufert at gmail dot com
I have been experiencing this problem. Unfortunately i have an
application which relies heavily on a class-driver arrangement where
both the class and the driver class need a reference to each other. I
was wondering if we could have a way of getting an uncounted reference
to the object to pass to the child? So the child would have a reference
to the parent, but it would not be counted, and therefore when all
external references to the parent are removed/unset, the parent will
GC, and then the child will be freed as usual.
Is this a workable solution? Even just a reference count decrement
would work. Not a perfect solution, but it would solve calling
descructors all the time.
[2006-02-22 15:12:21] K dot Londenberg at librics dot de
The problem with circular references is a known weakness of reference
counting schemes. Python uses a workaround (cycle detector).
Excerpt from
http://wingware.com/psupport/python-manual/2.4/ext/refcounts.html:
While Python uses the traditional reference counting implementation, it
also offers a cycle detector that works to detect reference cycles. This
allows applications to not worry about creating direct or indirect
circular references; these are the weakness of garbage collection
implemented using only reference counting. Reference cycles consist of
objects which contain (possibly indirect) references to themselves, so
that each object in the cycle has a reference count which is non-zero.
Typical reference counting implementations are not able to reclaim the
memory belonging to any objects in a reference cycle, or referenced
from the objects in the cycle, even though there are no further
references to the cycle itself.
Maybe this would also be a viable Strategy for PHP..
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33595
--
Edit this bug report at http://bugs.php.net/?id=33595edit=1
#39351 [NEW]: require and include fails to open file in current directory
From: lampiluoto at gmail dot com
Operating system: Solaris10
PHP version: 5.2.0
PHP Bug Type: *Directory/Filesystem functions
Bug description: require and include fails to open file in current directory
Description:
I upgraded to PHP 5.2.0 on Solaris 10 (amd64). Executing PHP code failed
and produced errors as any require() or include() with relative path
fails. With absolute path it's ok.
The same code in same environment works fine on PHP 5.1.6.
Reason might be that on Solaris getcwd() does not return current working
directory unless user has read privileges from root directory to the
current dir. Has something changed in 5.2.0 ?
User running httpd does not have read privileges to every directory in
Apache HTTPd's DocumentRoot path - it has only execute (x) privilege to
part of the directories.
Reproduce code:
---
// this fails on 5.2.0 but works fine on 5.1.6
require('config.php');
// this works also on 5.2.0
require('/absolute/path/to/config.php');
Expected result:
File config.inc should be read successfully. This require('config.php')
works fine on PHP 5.1.6 but after upgrading to 5.2.0 on same environment,
it does not.
Actual result:
--
// with relative path
[Fri Nov 03 00:13:15 2006] [error] [client x.x.x.x] PHP Warning:
require(config.php) [a href='function.require'function.require/a]:
failed to open stream: No such file or directory in /path/to/index.php on
line 3, referer: http://mysite/index.php
[Fri Nov 03 00:13:15 2006] [error] [client x.x.x.x] PHP Fatal error:
require() [a href='function.require'function.require/a]: Failed
opening required 'config.php' (include_path='.:/opt/httpd/php5/lib/php')
in /path/to/index.php on line 3, referer: http://mysite/index.php
--
Edit bug report at http://bugs.php.net/?id=39351edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39351r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39351r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39351r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39351r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39351r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39351r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39351r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39351r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39351r=support
Expected behavior:http://bugs.php.net/fix.php?id=39351r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39351r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39351r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39351r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39351r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39351r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39351r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39351r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39351r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39351r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39351r=mysqlcfg
#39352 [NEW]: oci_close fails with global keyword
From: david at acz dot org
Operating system: SuSE Linux 9.3
PHP version: 5.2.0
PHP Bug Type: OCI8 related
Bug description: oci_close fails with global keyword
Description:
oci_close() fails if the connection resource is a global accessed via the
global keyword, but works if accessed using the $GLOBALS array.
Reproduce code:
---
$conn = oci_connect(DB_USER, DB_PASS, DB_NAME);
var_dump($conn);
global_keyword();
global_array();
function global_keyword()
{
global $conn;
var_dump($conn);
oci_close($conn); // this seems to do nothing
var_dump($conn);
}
function global_array()
{
var_dump($GLOBALS[conn]);
oci_close($GLOBALS[conn]); // this works
var_dump($GLOBALS[conn]);
}
Expected result:
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
NULL
NULL
PHP Warning: oci_close() expects parameter 1 to be resource, null given
NULL
Actual result:
--
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
NULL
--
Edit bug report at http://bugs.php.net/?id=39352edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39352r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39352r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39352r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39352r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39352r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39352r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39352r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39352r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39352r=support
Expected behavior:http://bugs.php.net/fix.php?id=39352r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39352r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39352r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39352r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39352r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39352r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39352r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39352r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39352r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39352r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39352r=mysqlcfg
#34793 [Opn]: php-cli searches php.ini from current dir which can be abused
ID: 34793 User updated by: glen at delfi dot ee Reported By: glen at delfi dot ee Status: Open Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.1.0RC1 New Comment: you should close this bug with message like RESOLVED in 5.2.0 Previous Comments: [2006-01-17 15:49:05] glen at delfi dot ee to put this into another light. how should i run php cli program, with *not* reading ./php.ini? a real live situation: i have a PHP program defined as CVS loginfo handler. CVS server accessed via ssh. now if i happen to commit php.ini in such CVS setup, the php.ini is first uploaded to cvs server and then a PHP program is executed in that directory (where commited files were uploaded). as the php.ini is not for the OS where the PHP program is ran. i get fatal error from PHP interpreter and no code is executed: # cvs ci -m '- disable zend, broken' php.ini Checking in php.ini; /usr/local/cvs/sw/apache/php.ini,v -- php.ini new revision: 1.7; previous revision: 1.6 done PHP Warning: PHP Startup: Unable to load dynamic library './pcre.so' - ./pcre.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 PHP Warning: Unknown: Failed opening '/www/vars.inc' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 [2005-10-10 00:06:59] adamg at agmk dot net I believe this behaviour is wrong and PHP should be fixed not to look for php.ini in the current directory for the reasons described by glen. Ideally (as I see it) is a fixed location in /etc and (optionally) in home dir of user running the script. Why do you think this bug report is bogus? What are the reasons for keeping such behaviour? [2005-10-10 00:05:36] glen at delfi dot ee in fact i know that documentation says so. but that doesn't mean it supposed to be like this? can't you at least consider securing it, by adding some option to enable/disable this? so i changed category to feature request! [2005-10-09 19:14:38] [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 [2005-10-09 18:13:31] glen at delfi dot ee Description: php cli searches for php.ini from current dir, and when current directory appears to be world writable directory, then malicious user can put there php.ini loading malicious extension. php cli is used for example to install PEAR packages, and for PEAR install to succeed it needs to be run as root. Reproduce code: --- 1. create /tmp/php.ini containing [PHP] extension=/../../../tmp/malicious.so 2. create php extension and save it to /tmp/malicious.so 3. wait for root run any php-cli program in /tmp 4. your code in malicious.so gets executed. Expected result: php should not read php.ini from arbitary locations, it should read it only from hardcoded paths, or one specified from commandline. Actual result: -- $ strace -eopen php -m open(/etc/ld.so.cache, O_RDONLY) = 6 open(/usr/lib/libphp_common-5.1.0RC1.so, O_RDONLY) = 6 open(/lib/libcrypt.so.1, O_RDONLY)= 6 open(/lib/libm.so.6, O_RDONLY)= 6 open(/lib/libz.so.1, O_RDONLY)= 6 open(/lib/libresolv.so.2, O_RDONLY) = 6 open(/lib/libpthread.so.0, O_RDONLY) = 6 open(/usr/lib/libxml2.so.2, O_RDONLY) = 6 open(/lib/libdl.so.2, O_RDONLY) = 6 open(/lib/libhistory.so.5, O_RDONLY) = 6 open(/lib/libreadline.so.5, O_RDONLY) = 6 open(/lib/libncurses.so.5, O_RDONLY) = 6 open(/lib/libc.so.6, O_RDONLY)= 6 open(/lib/libtinfo.so.5, O_RDONLY)= 6 open(/etc/localtime, O_RDONLY)= 6 open(/tmp/php.ini, O_RDONLY) = 6 open(/tmp/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/etc/php/php-cli.ini, O_RDONLY) = 6 open(/etc/php/conf.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE| O_DIRECTORY) = 6 open(/etc/php/conf.d/pcre.ini, O_RDONLY) = 6 open(/etc/php/conf.d/xml.ini, O_RDONLY) = 6 open(/usr/lib/php//../../../tmp/malicious.so, O_RDONLY) = 6 open(/usr/lib/php/pcre.so, O_RDONLY) = 6 -- Edit this bug report at http://bugs.php.net/?id=34793edit=1
#34793 [Opn-Csd]: php-cli searches php.ini from current dir which can be abused
ID: 34793 Updated by: [EMAIL PROTECTED] Reported By: glen at delfi dot ee -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: PLD Linux PHP Version: 5.1.0RC1 -Assigned To: +Assigned To: edink New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php :) Previous Comments: [2006-11-02 23:36:53] glen at delfi dot ee you should close this bug with message like RESOLVED in 5.2.0 [2006-01-17 15:49:05] glen at delfi dot ee to put this into another light. how should i run php cli program, with *not* reading ./php.ini? a real live situation: i have a PHP program defined as CVS loginfo handler. CVS server accessed via ssh. now if i happen to commit php.ini in such CVS setup, the php.ini is first uploaded to cvs server and then a PHP program is executed in that directory (where commited files were uploaded). as the php.ini is not for the OS where the PHP program is ran. i get fatal error from PHP interpreter and no code is executed: # cvs ci -m '- disable zend, broken' php.ini Checking in php.ini; /usr/local/cvs/sw/apache/php.ini,v -- php.ini new revision: 1.7; previous revision: 1.6 done PHP Warning: PHP Startup: Unable to load dynamic library './pcre.so' - ./pcre.so: cannot open shared object file: No such file or directory in Unknown on line 0 PHP Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0 PHP Warning: Unknown: Failed opening '/www/vars.inc' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 [2005-10-10 00:06:59] adamg at agmk dot net I believe this behaviour is wrong and PHP should be fixed not to look for php.ini in the current directory for the reasons described by glen. Ideally (as I see it) is a fixed location in /etc and (optionally) in home dir of user running the script. Why do you think this bug report is bogus? What are the reasons for keeping such behaviour? [2005-10-10 00:05:36] glen at delfi dot ee in fact i know that documentation says so. but that doesn't mean it supposed to be like this? can't you at least consider securing it, by adding some option to enable/disable this? so i changed category to feature request! [2005-10-09 19:14:38] [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 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/34793 -- Edit this bug report at http://bugs.php.net/?id=34793edit=1
#39353 [NEW]: more imagecopyresized() alpha problems
From: seth at pricepages dot org
Operating system: Mac 10.4
PHP version: 5CVS-2006-11-02 (snap)
PHP Bug Type: GD related
Bug description: more imagecopyresized() alpha problems
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http://pricepages.org/temp/partialTrans.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW, $srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
The image is filled with red, and a partially transparent
black-and-white image is composited on top of it. Because
alpha blending is set to false, there should be no red showing
in the final image. (bug#1, squashed above)
Also, because the greyscale image should have partial
transparency, there should be a gradient between black and
red, but there is none. It is only black or only red. (bug#2)
--
Edit bug report at http://bugs.php.net/?id=39353edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39353r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39353r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39353r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39353r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39353r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39353r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39353r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39353r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39353r=support
Expected behavior:http://bugs.php.net/fix.php?id=39353r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39353r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39353r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39353r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39353r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39353r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39353r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39353r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39353r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39353r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39353r=mysqlcfg
#39354 [NEW]: PHP 5.2.0 x curl 7.16.0
From: fraga at abusar dot org Operating system: Linux 2.6.18 PHP version: 5.2.0 PHP Bug Type: Compile Failure Bug description: PHP 5.2.0 x curl 7.16.0 Description: PHP 5.2.0 is incompatible with the new curl 7.16.0. The solution I found is to comment lines 372, 412 and 1164 from php-5.2.0/ext/curl/interface.c Actual result: -- /bin/sh /home/fraga/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/zlib/ -I/home/fraga/php-5.2.0/ext/zlib/ -DPHP_ATOM_INC -I/home/fraga/php-5.2.0/include -I/home/fraga/php-5.2.0/main -I/home/fraga/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/fraga/php-5.2.0/ext/date/lib -I/home/fraga/php-5.2.0/ext/mbstring/oniguruma -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/include/mysql -I/home/fraga/php-5.2.0/TSRM -I/home/fraga/php-5.2.0/Zend-I/usr/include -O2 -march=athlon-xp -pipe -ftree-vectorize -mfpmath=sse -prefer-non-pic -c /home/fraga/php-5.2.0/ext/zlib/zlib_filter.c -o ext/zlib/zlib_filter.lo /bin/sh /home/fraga/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/ctype/ -I/home/fraga/php-5.2.0/ext/ctype/ -DPHP_ATOM_INC -I/home/fraga/php-5.2.0/include -I/home/fraga/php-5.2.0/main -I/home/fraga/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/fraga/php-5.2.0/ext/date/lib -I/home/fraga/php-5.2.0/ext/mbstring/oniguruma -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/include/mysql -I/home/fraga/php-5.2.0/TSRM -I/home/fraga/php-5.2.0/Zend-I/usr/include -O2 -march=athlon-xp -pipe -ftree-vectorize -mfpmath=sse -prefer-non-pic -c /home/fraga/php-5.2.0/ext/ctype/ctype.c -o ext/ctype/ctype.lo /bin/sh /home/fraga/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/fraga/php-5.2.0/ext/curl/ -DPHP_ATOM_INC -I/home/fraga/php-5.2.0/include -I/home/fraga/php-5.2.0/main -I/home/fraga/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/fraga/php-5.2.0/ext/date/lib -I/home/fraga/php-5.2.0/ext/mbstring/oniguruma -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/include/mysql -I/home/fraga/php-5.2.0/TSRM -I/home/fraga/php-5.2.0/Zend-I/usr/include -O2 -march=athlon-xp -pipe -ftree-vectorize -mfpmath=sse -prefer-non-pic -c /home/fraga/php-5.2.0/ext/curl/interface.c -o ext/curl/interface.lo /home/fraga/php-5.2.0/ext/curl/interface.c: In function 'zm_startup_curl': /home/fraga/php-5.2.0/ext/curl/interface.c:372: error: 'CURLOPT_FTPASCII' undeclared (first use in this function) /home/fraga/php-5.2.0/ext/curl/interface.c:372: error: (Each undeclared identifier is reported only once /home/fraga/php-5.2.0/ext/curl/interface.c:372: error: for each function it appears in.) /home/fraga/php-5.2.0/ext/curl/interface.c:412: error: 'CURLOPT_PASSWDFUNCTION' undeclared (first use in this function) /home/fraga/php-5.2.0/ext/curl/interface.c: In function 'zif_curl_copy_handle': /home/fraga/php-5.2.0/ext/curl/interface.c:1164: error: 'CURLOPT_PASSWDDATA' undeclared (first use in this function) make: *** [ext/curl/interface.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=39354edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39354r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39354r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39354r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39354r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39354r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39354r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39354r=needscript Try newer version:http://bugs.php.net/fix.php?id=39354r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39354r=support Expected behavior:http://bugs.php.net/fix.php?id=39354r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39354r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39354r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39354r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39354r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39354r=dst IIS Stability:http://bugs.php.net/fix.php?id=39354r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39354r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39354r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39354r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39354r=mysqlcfg
#39356 [NEW]: in_array() causes Nesting level too deep fatal error
From: 7am dot online at gmail dot com
Operating system: Windows XP
PHP version: 5.2.0
PHP Bug Type: Arrays related
Bug description: in_array() causes Nesting level too deep fatal error
Description:
Doing a in_array() check against an array containing objects with
recursive dependency causes a Nesting level too deep - recursive
dependency? fatal error.
Reproduce code:
---
?php
class A
{
public $b;
}
class B
{
public $a;
}
$a = new A;
$b = new B;
$b-a = $a;
$a-b = $b;
$test = array($a, $b);
var_dump(in_array($a, $test));
Expected result:
bool(true), as in PHP5.1.6
Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in [FILENAME]
on line 19
--
Edit bug report at http://bugs.php.net/?id=39356edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39356r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39356r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39356r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39356r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39356r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39356r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39356r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39356r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39356r=support
Expected behavior:http://bugs.php.net/fix.php?id=39356r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39356r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39356r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39356r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39356r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39356r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39356r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39356r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39356r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39356r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39356r=mysqlcfg
