#27831 [Bgs]: Problem with mssql_fetch_array
ID: 27831
User updated by: mhabr at sszn dot cz
Reported By: mhabr at sszn dot cz
Status: Bogus
Bug Type: MSSQL related
Operating System: MS SBS 2003
PHP Version: 4.3.5
New Comment:
Whats the number of that existing bug please?
Previous Comments:
[2004-04-02 02:18:28] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Already filed.
[2004-04-02 00:32:39] mhabr at sszn dot cz
Description:
I connect to ms sql server.When I use mssql_fetch_array and then i
wonna get collumns values , every value has an additional space at its
end.
Thanks a lot
Reproduce code:
---
$query = mssql_query(SELECT id,email,password,name FROM users WHERE
login='$login');
$row = mssql_fetch_array($query);
if (mssql_num_rows($query) != 0) {
1) echo '*'.md5($passwd).'*';
2) echo '*'.$row[password].'*';
first echo 1) shows something like *4sdfdsf6ddt*
but echo 2) shows *4sdfdsf6ddt *
___
this space isnt needed.
Expected result:
no space at the end of $row[column_name]
Actual result:
--
additional space at the end of $row[].
--
Edit this bug report at http://bugs.php.net/?id=27831edit=1
#27833 [Bgs-Asn]: Concatenating overloaded objects fails
ID: 27833
Updated by: [EMAIL PROTECTED]
Reported By: steph dot fox at virgin dot net
-Status: Bogus
+Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: win98
PHP Version: 5CVS-2004-04-02 (dev)
-Assigned To:
+Assigned To: andi
New Comment:
It doesn't work without the concat either.
Previous Comments:
[2004-04-02 02:01:51] [EMAIL PROTECTED]
The advertising is wrong. This method was changed in RC
1 to prevent some potential crashes. You can no longer
concat it. Hopefully this will be fixed in PHP 5.1.
[2004-04-02 01:56:46] steph dot fox at virgin dot net
Description:
__toString() works more or less as currently advertised, until I try to
concat it..
Reproduce code:
---
?php
class Foo {
function __toString() {
return Blah;
}
}
$obj = new Foo();
echo $obj.\n;
?
Expected result:
Blah
Actual result:
--
Object id #1
--
Edit this bug report at http://bugs.php.net/?id=27833edit=1
#27832 [Bgs]: Bad Version number in phpinfo()
ID: 27832 User updated by: tanguy dot pruvot at laposte dot net Reported By: tanguy dot pruvot at laposte dot net Status: Bogus Bug Type: *General Issues Operating System: Win 2000 SP4 PHP Version: 4.3.6RC1 New Comment: In phpinfo : apache2handler : Apache Version Apache/2.0.49 (Win32) PHP/4.3.6RC1 and env values : SERVER_SIGNATURE addressApache/2.0.49 (Win32) PHP/4.3.6RC1 Server at localhost Port 80/address SERVER_SOFTWARE Apache/2.0.49 (Win32) PHP/4.3.6RC1 are ok Previous Comments: [2004-04-02 02:18:51] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You are loading the old version then! [2004-04-02 00:50:56] tanguy dot pruvot at laposte dot net Description: phpinfo() title is : PHP Version 4.3.2 in versions 4.3.5 and 4.3.6 (i use php4apache2) Reproduce code: --- phpinfo(); Expected result: PHP Version 4.3.2 -- Edit this bug report at http://bugs.php.net/?id=27832edit=1
#27832 [Bgs]: Bad Version number in phpinfo()
ID: 27832 User updated by: tanguy dot pruvot at laposte dot net Reported By: tanguy dot pruvot at laposte dot net Status: Bogus Bug Type: *General Issues Operating System: Win 2000 SP4 PHP Version: 4.3.6RC1 New Comment: I dont have any php 4.3.2 version ! Previous Comments: [2004-04-02 03:17:44] tanguy dot pruvot at laposte dot net In phpinfo : apache2handler : Apache Version Apache/2.0.49 (Win32) PHP/4.3.6RC1 and env values : SERVER_SIGNATURE addressApache/2.0.49 (Win32) PHP/4.3.6RC1 Server at localhost Port 80/address SERVER_SOFTWARE Apache/2.0.49 (Win32) PHP/4.3.6RC1 are ok [2004-04-02 02:18:51] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You are loading the old version then! [2004-04-02 00:50:56] tanguy dot pruvot at laposte dot net Description: phpinfo() title is : PHP Version 4.3.2 in versions 4.3.5 and 4.3.6 (i use php4apache2) Reproduce code: --- phpinfo(); Expected result: PHP Version 4.3.2 -- Edit this bug report at http://bugs.php.net/?id=27832edit=1
#27833 [Asn]: Concatenating overloaded objects fails
ID: 27833
User updated by: steph dot fox at virgin dot net
Reported By: steph dot fox at virgin dot net
Status: Assigned
Bug Type: Zend Engine 2 problem
Operating System: win98
PHP Version: 5CVS-2004-04-02 (dev)
Assigned To: andi
New Comment:
erm, yes it does -
echo $obj; // works fine
echo (string) $obj; // fails
- but I thought that was _meant_ to fail currently :\
Andi, when you bogus this report, could you please clarify exactly what
should or shouldn't happen at this point? Docs need to reflect
intended behaviour too..
Previous Comments:
[2004-04-02 03:13:58] [EMAIL PROTECTED]
It doesn't work without the concat either.
[2004-04-02 02:01:51] [EMAIL PROTECTED]
The advertising is wrong. This method was changed in RC
1 to prevent some potential crashes. You can no longer
concat it. Hopefully this will be fixed in PHP 5.1.
[2004-04-02 01:56:46] steph dot fox at virgin dot net
Description:
__toString() works more or less as currently advertised, until I try to
concat it..
Reproduce code:
---
?php
class Foo {
function __toString() {
return Blah;
}
}
$obj = new Foo();
echo $obj.\n;
?
Expected result:
Blah
Actual result:
--
Object id #1
--
Edit this bug report at http://bugs.php.net/?id=27833edit=1
#27832 [Bgs]: Bad Version number in phpinfo()
ID: 27832 User updated by: tanguy dot pruvot at laposte dot net Reported By: tanguy dot pruvot at laposte dot net Status: Bogus Bug Type: *General Issues Operating System: Win 2000 SP4 PHP Version: 4.3.6RC1 New Comment: hmmm i dunno why... work nice in service mode.. on my second server Previous Comments: [2004-04-02 03:18:47] tanguy dot pruvot at laposte dot net I dont have any php 4.3.2 version ! [2004-04-02 03:17:44] tanguy dot pruvot at laposte dot net In phpinfo : apache2handler : Apache Version Apache/2.0.49 (Win32) PHP/4.3.6RC1 and env values : SERVER_SIGNATURE addressApache/2.0.49 (Win32) PHP/4.3.6RC1 Server at localhost Port 80/address SERVER_SOFTWARE Apache/2.0.49 (Win32) PHP/4.3.6RC1 are ok [2004-04-02 02:18:51] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You are loading the old version then! [2004-04-02 00:50:56] tanguy dot pruvot at laposte dot net Description: phpinfo() title is : PHP Version 4.3.2 in versions 4.3.5 and 4.3.6 (i use php4apache2) Reproduce code: --- phpinfo(); Expected result: PHP Version 4.3.2 -- Edit this bug report at http://bugs.php.net/?id=27832edit=1
#27832 [Bgs]: Bad Version number in phpinfo()
ID: 27832 User updated by: tanguy dot pruvot at laposte dot net Reported By: tanguy dot pruvot at laposte dot net Status: Bogus Bug Type: *General Issues Operating System: Win 2000 SP4 PHP Version: 4.3.6RC1 New Comment: the only 4.3.2 i have is uncompiled sources in C:\php_src\php-4.3.2 how is determined this version (title) ? Previous Comments: [2004-04-02 03:29:04] tanguy dot pruvot at laposte dot net hmmm i dunno why... work nice in service mode.. on my second server [2004-04-02 03:18:47] tanguy dot pruvot at laposte dot net I dont have any php 4.3.2 version ! [2004-04-02 03:17:44] tanguy dot pruvot at laposte dot net In phpinfo : apache2handler : Apache Version Apache/2.0.49 (Win32) PHP/4.3.6RC1 and env values : SERVER_SIGNATURE addressApache/2.0.49 (Win32) PHP/4.3.6RC1 Server at localhost Port 80/address SERVER_SOFTWARE Apache/2.0.49 (Win32) PHP/4.3.6RC1 are ok [2004-04-02 02:18:51] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You are loading the old version then! [2004-04-02 00:50:56] tanguy dot pruvot at laposte dot net Description: phpinfo() title is : PHP Version 4.3.2 in versions 4.3.5 and 4.3.6 (i use php4apache2) Reproduce code: --- phpinfo(); Expected result: PHP Version 4.3.2 -- Edit this bug report at http://bugs.php.net/?id=27832edit=1
#27832 [Bgs-Csd]: Bad Version number in phpinfo()
ID: 27832 User updated by: tanguy dot pruvot at laposte dot net Reported By: tanguy dot pruvot at laposte dot net -Status: Bogus +Status: Closed Bug Type: *General Issues Operating System: Win 2000 SP4 PHP Version: 4.3.6RC1 New Comment: i found the problem, i had a php4ts.dll in system32 :/ Previous Comments: [2004-04-02 03:34:49] tanguy dot pruvot at laposte dot net the only 4.3.2 i have is uncompiled sources in C:\php_src\php-4.3.2 how is determined this version (title) ? [2004-04-02 03:29:04] tanguy dot pruvot at laposte dot net hmmm i dunno why... work nice in service mode.. on my second server [2004-04-02 03:18:47] tanguy dot pruvot at laposte dot net I dont have any php 4.3.2 version ! [2004-04-02 03:17:44] tanguy dot pruvot at laposte dot net In phpinfo : apache2handler : Apache Version Apache/2.0.49 (Win32) PHP/4.3.6RC1 and env values : SERVER_SIGNATURE addressApache/2.0.49 (Win32) PHP/4.3.6RC1 Server at localhost Port 80/address SERVER_SOFTWARE Apache/2.0.49 (Win32) PHP/4.3.6RC1 are ok [2004-04-02 02:18:51] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You are loading the old version then! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27832 -- Edit this bug report at http://bugs.php.net/?id=27832edit=1
#27828 [Com]: sybase_free_result crashes
ID: 27828
Comment by: tvoigt at informatik dot tu-cottbus dot de
Reported By: deanb at gbtn dot net
Status: Open
Bug Type: Sybase-ct (ctlib) related
Operating System: Digital Unix 4.0F
PHP Version: 4.3.5
New Comment:
Hi there!
The bug ist reproducible here on Debian Woody + apache-1.3.29/php =
4.3.4RC3, too.
It was most probably introduced while fixing
http://bugs.php.net/bug.php?id=26407: sybase_free_result() works
properly up to php-4.3.4RC2, but not with a patched 4.3.4RC2 to solve
bug #26407 (that patch then made it into 4.3.4RC3).
Well, I'm sorry for not testing sybase_free_result() afterwards, never
used it before...
Best regards,
Thomas
Previous Comments:
[2004-04-01 15:59:18] deanb at gbtn dot net
Description:
If I use sybase_free_result() in a script, then php crashes. The exact
same code works fine in php 4.3.4.
./configure --with-sybase-ct=${SYBASE}
--enable-track-vars
--without-mysql
--with-apache=../apache_1.3.29
--disable-dba
--enable-session
Reproduce code:
---
?php
$db = sybase_connect(server, user, pass);
$res = sybase_query(select name from sysdatabases, $db);
while ($data = sybase_fetch_array($res)) {
print db: $data[0]\n;
}
sybase_free_result($res);
sybase_close($db);
?
Expected result:
a list of databases with no crashes
Actual result:
--
php s.php
db: master
db: model
db: sybsystemprocs
db: tempdb
Segmentation fault (core dumped)
dbx php core
dbx version 3.11.10
Type 'help' for help.
Core file created by program php
signal Segmentation fault at [_efree:241 ,0x12013e7c8]
CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(dbx) where
0 _efree(ptr = 0x52667250203a6264)
[/app/apps/web/php-4.3.5/Zend/zend_alloc.c:241, 0x12013e7c8]
1 php_sybase_finish_results(result = 0x1400cd5b8)
[/app/apps/web/php-4.3.5/ext/sybase_ct/php_sybase_ct.c:1011,
0x1200e766c]
2 zif_sybase_free_result(ht = 1, return_value = 0x1400d8298,
this_ptr = (nil), return_value_used = 0)
[/app/apps/web/php-4.3.5/ext/sybase_ct/php_sybase_ct.c:1602,
0x1200e8f20]
3 execute(op_array = 0x1400c52d8)
[/app/apps/web/php-4.3.5/Zend/zend_execute.c:1621, 0x12016fdf4]
4 zend_execute_scripts(type = 8, retval = (nil), file_count = 3)
[/app/apps/web/php-4.3.5/Zend/zend.c:889, 0x120155be0]
5 php_execute_script(primary_file = 0x11fffec10)
[/app/apps/web/php-4.3.5/main/main.c:1731, 0x120116d84]
6 main(argc = 2, argv = 0x11fffef28)
[/app/apps/web/php-4.3.5/sapi/cli/php_cli.c:822, 0x1201722e4]
(dbx) up
php_sybase_finish_results:1011 efree(result-tmp_buffer[i]);
(dbx) up
zif_sybase_free_result:1602 php_sybase_finish_results(result);
--
Edit this bug report at http://bugs.php.net/?id=27828edit=1
#27832 [Csd-Bgs]: Bad Version number in phpinfo()
ID: 27832 Updated by: [EMAIL PROTECTED] Reported By: tanguy dot pruvot at laposte dot net -Status: Closed +Status: Bogus Bug Type: *General Issues Operating System: Win 2000 SP4 PHP Version: 4.3.6RC1 Previous Comments: [2004-04-02 03:38:32] tanguy dot pruvot at laposte dot net i found the problem, i had a php4ts.dll in system32 :/ [2004-04-02 03:34:49] tanguy dot pruvot at laposte dot net the only 4.3.2 i have is uncompiled sources in C:\php_src\php-4.3.2 how is determined this version (title) ? [2004-04-02 03:29:04] tanguy dot pruvot at laposte dot net hmmm i dunno why... work nice in service mode.. on my second server [2004-04-02 03:18:47] tanguy dot pruvot at laposte dot net I dont have any php 4.3.2 version ! [2004-04-02 03:17:44] tanguy dot pruvot at laposte dot net In phpinfo : apache2handler : Apache Version Apache/2.0.49 (Win32) PHP/4.3.6RC1 and env values : SERVER_SIGNATURE addressApache/2.0.49 (Win32) PHP/4.3.6RC1 Server at localhost Port 80/address SERVER_SOFTWARE Apache/2.0.49 (Win32) PHP/4.3.6RC1 are ok 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/27832 -- Edit this bug report at http://bugs.php.net/?id=27832edit=1
#27830 [Opn-Fbk]: PHP segfaults immediately on startup
ID: 27830 Updated by: [EMAIL PROTECTED] Reported By: adconrad at 0c3 dot net -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Debian 3.0/SPARC PHP Version: 4.3.6RC1 New Comment: Could you post your compiler version and the output of 'configure' ? Previous Comments: [2004-04-01 23:00:36] adconrad at 0c3 dot net Description: PHP segfaults immediately on execution, with or without input on SPARC. If the patch[1] applied in CVS (ostensibly to improve portability) is removed, the segfault goes away. 1. A short script that reproduces the problem. [EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php Segmentation fault 2. The list of modules you compiled PHP with (your configure line). './configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1' '--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex' '--enable-ctype' '--enable-overload' '--enable-posix' '--enable-session' '--enable-tokenizer' '--enable-xml' '--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl' '--with-mysql=shared,/usr' '--with-pgsql=shared,/usr' '--with-sybase-ct=shared,/usr/local/freetds' 3. Any other information unique or specific to your setup. Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64) CPU. glibc version 2.2.5-11.5. 4. Any changes made in your php.ini compared to php.ini-dist (not your whole php.ini!) This occurs with or without a php.ini. 5. A gdb backtrace. Program received signal SIGSEGV, Segmentation fault. 0x0005e170 in php_get_inf () at /home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021 1021return HUGE_VAL; (gdb) bt #0 0x0005e170 in php_get_inf () at /home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021 #1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4) at /home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065 #2 0x000ef068 in zend_startup_module (module=0x14647c) at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005 #3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840) at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044 #4 0x00108334 in php_startup_internal_extensions () at main/internal_functions_cli.c:65 #5 0x000bf0b8 in php_module_startup (sf=0x149570, additional_modules=0x0, num_additional_modules=0) at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216 #6 0x001074c8 in main (argc=1, argv=0xeb34) at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576 [1] http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u -- Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27777 [Opn]: basic authentication broken
ID: 2 User updated by: mikx at mikx dot de Reported By: mikx at mikx dot de Status: Open Bug Type: SOAP related Operating System: Windows XP Pro PHP Version: 5.0.0RC1 New Comment: At the momenten i have no non-wsdl demo case available, but it seems soap requests are working fine. If i remove the login/password from the options array i can only call __getFunctions() but none of the functions reported by it. I think that means i have got the wsdl file through uri authentication but the soap calls fail. After adding the login/password also to the options array i can call both __getFuntions() and testFunction() - a hello world testcase. Therefore adding login/password in the array seems to work like expected. Previous Comments: [2004-04-02 00:27:18] [EMAIL PROTECTED] Authentication should work for SOAP requests, but it is not working during requesting of WSDL file (not implemented). Do you have problem only with WSDL loading or with SOAP requests too? [2004-03-30 08:33:57] mikx at mikx dot de Description: When using basic authentication the soap client does not authenticate itself automaticly using the options array. You need to add the login and password in the uri. Reproduce code: --- _NOT working_ $client = new SoapClient(http://foo.com/bar.wsdl;, array( login = yourLogin, password = yourPassword)); _working_ $client = new SoapClient(http://yourLogin:[EMAIL PROTECTED]/bar.wsdl); Expected result: The SOAP client should take the login and password from the options array and automaticly authenticate itself. -- Edit this bug report at http://bugs.php.net/?id=2edit=1
#27828 [Opn-Fbk]: sybase_free_result crashes
ID: 27828
Updated by: [EMAIL PROTECTED]
Reported By: deanb at gbtn dot net
-Status: Open
+Status: Feedback
Bug Type: Sybase-ct (ctlib) related
Operating System: Digital Unix 4.0F
PHP Version: 4.3.5
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2004-04-02 04:21:50] tvoigt at informatik dot tu-cottbus dot de
Hi there!
The bug ist reproducible here on Debian Woody + apache-1.3.29/php =
4.3.4RC3, too.
It was most probably introduced while fixing
http://bugs.php.net/bug.php?id=26407: sybase_free_result() works
properly up to php-4.3.4RC2, but not with a patched 4.3.4RC2 to solve
bug #26407 (that patch then made it into 4.3.4RC3).
Well, I'm sorry for not testing sybase_free_result() afterwards, never
used it before...
Best regards,
Thomas
[2004-04-01 15:59:18] deanb at gbtn dot net
Description:
If I use sybase_free_result() in a script, then php crashes. The exact
same code works fine in php 4.3.4.
./configure --with-sybase-ct=${SYBASE}
--enable-track-vars
--without-mysql
--with-apache=../apache_1.3.29
--disable-dba
--enable-session
Reproduce code:
---
?php
$db = sybase_connect(server, user, pass);
$res = sybase_query(select name from sysdatabases, $db);
while ($data = sybase_fetch_array($res)) {
print db: $data[0]\n;
}
sybase_free_result($res);
sybase_close($db);
?
Expected result:
a list of databases with no crashes
Actual result:
--
php s.php
db: master
db: model
db: sybsystemprocs
db: tempdb
Segmentation fault (core dumped)
dbx php core
dbx version 3.11.10
Type 'help' for help.
Core file created by program php
signal Segmentation fault at [_efree:241 ,0x12013e7c8]
CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(dbx) where
0 _efree(ptr = 0x52667250203a6264)
[/app/apps/web/php-4.3.5/Zend/zend_alloc.c:241, 0x12013e7c8]
1 php_sybase_finish_results(result = 0x1400cd5b8)
[/app/apps/web/php-4.3.5/ext/sybase_ct/php_sybase_ct.c:1011,
0x1200e766c]
2 zif_sybase_free_result(ht = 1, return_value = 0x1400d8298,
this_ptr = (nil), return_value_used = 0)
[/app/apps/web/php-4.3.5/ext/sybase_ct/php_sybase_ct.c:1602,
0x1200e8f20]
3 execute(op_array = 0x1400c52d8)
[/app/apps/web/php-4.3.5/Zend/zend_execute.c:1621, 0x12016fdf4]
4 zend_execute_scripts(type = 8, retval = (nil), file_count = 3)
[/app/apps/web/php-4.3.5/Zend/zend.c:889, 0x120155be0]
5 php_execute_script(primary_file = 0x11fffec10)
[/app/apps/web/php-4.3.5/main/main.c:1731, 0x120116d84]
6 main(argc = 2, argv = 0x11fffef28)
[/app/apps/web/php-4.3.5/sapi/cli/php_cli.c:822, 0x1201722e4]
(dbx) up
php_sybase_finish_results:1011 efree(result-tmp_buffer[i]);
(dbx) up
zif_sybase_free_result:1602 php_sybase_finish_results(result);
--
Edit this bug report at http://bugs.php.net/?id=27828edit=1
#27826 [Fbk-Csd]: Pages loading forever
ID: 27826 User updated by: faraco dot phpbugs at mailnull dot com Reported By: faraco dot phpbugs at mailnull dot com -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows NT4 SP6 PHP Version: 4.3.5 New Comment: The snapshot works perfectly. Thank you, iliaa. Previous Comments: [2004-04-01 14:20:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-04-01 12:22:08] faraco dot phpbugs at mailnull dot com I don't know how to give more information about it but, ok, I will try again. I've installed PHP 4.3.5 on a Windows NT4 SP6 machine. When loading *ANY* script, from a simply phpinfo() to a complex B2B system, the page's content is properly shown but the browser (IE 6 and Firefox 0.8) remains loading forever (animated icon on top-right corner and hourglass cursor). [2004-04-01 11:52:54] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2004-04-01 11:33:21] faraco dot phpbugs at mailnull dot com Description: When loading any script, even a simply ? phpinfo(); ? script, the page continuous loading forever. -- Edit this bug report at http://bugs.php.net/?id=27826edit=1
#27747 [Opn]: ISAPI modul is not working
ID: 27747 User updated by: T dot Hauck at janaserver dot de Reported By: T dot Hauck at janaserver dot de Status: Open Bug Type: *General Issues Operating System: W2k PHP Version: 4.3.5 New Comment: Hallo, i compiled the php source and run it in debugger of the webserver. I'am not sure if i'am right but i found a few strange things. 1.) If the thread on the server exist how called the HttpExtensionProc the DLLMain function in the php4isapi.dll is called and runs this code. case DLL_THREAD_DETACH: ts_free_thread(); break; after that the thread exit procedure in windows it self crashes. I have to tell you the webserver runs every call to the HttpExtensionProc in his own thread, so that DLL_THREAD_DETACH: is called after evry php call. Because the same php4isapi.dll with older php4ts.dll version work, i think the error must be somewhere ts_free_thread(); funktion. To other messager showed in the debugterminal up: c:\work\php-4.3.5\zend\zend_hash.c(544) : ht=0x014f0820 is already destroyed c:\work\php-4.3.5\zend\zend_hash.c(108) : Bailed out without a bailout address! I don't now if they have something todo with it. If you need mor information or what every, i'll be back on monday morning GMT+0200 Thomas Previous Comments: [2004-04-02 02:42:10] T dot Hauck at janaserver dot de No still crashes. and it still is in the php4ts.dll. Useing the ISAPI DLL with a older php4ts.dll is works. I would spend the time and help you find the error, but i can't compile the source code with my VS 6.0 SP4 or VS.NET 2003 It looks for some Header files i don't have. #include arp/inet.h #include zlib.h #include sys/cdefs.h #include netdb.h ... ... [2004-04-01 17:10:17] [EMAIL PROTECTED] Could you please try http://downloads.php.net/ilia/php-4.3.6RC1-Win32.zip [2004-03-30 11:17:54] T dot Hauck at janaserver dot de No, i do not have the Zend extensions loaded, i don't have any extension loaded right now. [2004-03-30 10:35:44] [EMAIL PROTECTED] Do you have any Zend extensions being loaded in php.ini? [2004-03-30 10:08:03] T dot Hauck at janaserver dot de With the isapi dll from version 4.3.4 is now diffrent, php crashes. Useing the php4isapi.dll from version 4.3.5 and the php4ts.dll from version 4.3.4 does NOT crash, and everything works fine. So the error must be in the php4ts.dll So i think the php4ts.dll raises some kind of exeption, what is catched in the php4isapi.dll, how is than terminating the thread (on the server) how called the HttpExtensionProc function. Thomas 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/27747 -- Edit this bug report at http://bugs.php.net/?id=27747edit=1
#27836 [NEW]: zend.ze1_compatibility_mode = On gives errors
From: Robin at RHarmsen dot nl Operating system: Windows XP PHP version: 5.0.0RC1 PHP Bug Type: Zend Engine 2 problem Bug description: zend.ze1_compatibility_mode = On gives errors Description: When I turn on zend Engine1 Compatibility mode my code stops working (It worked perfect on PHP4 and PHP5 withoud the compatibility mode) PHP.ini diffreances: zend.ze1_compatibility_mode = On (off when error doesn't occure) allow_call_time_pass_reference = Off error_reporting = E_ALL register_long_arrays = Off register_argc_argv = Off extension=php_mysql.dll configure line (according to phpinfo()) Configure Command cscript /nologo configure.js --enable-snapshot-build --with-gd=shared I think it is realy strange that an error occures when the mode is activated. though it works on PHP4 and PHP5 withoud the mode activated. It looks like $db in the Menu class is'nt set Reproduce code: --- I got the source files located here to reproduce the bug http://www.rharmsen.nl/bugfiles/main.phps http://www.rharmsen.nl/bugfiles/clsDB.phps http://www.rharmsen.nl/bugfiles/clsMenu.phps Expected result: I expected that the menu was displayed Actual result: -- What I got was: Fatal error: Call to a member function query() on a non-object in clsMenu.php on line 36 -- Edit bug report at http://bugs.php.net/?id=27836edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27836r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27836r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27836r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27836r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27836r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27836r=needscript Try newer version: http://bugs.php.net/fix.php?id=27836r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27836r=support Expected behavior: http://bugs.php.net/fix.php?id=27836r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27836r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27836r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27836r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27836r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27836r=dst IIS Stability: http://bugs.php.net/fix.php?id=27836r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27836r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27836r=float
#27836 [Opn-Fbk]: zend.ze1_compatibility_mode = On gives errors
ID: 27836 Updated by: [EMAIL PROTECTED] Reported By: Robin at RHarmsen dot nl -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Windows XP PHP Version: 5.0.0RC1 New Comment: 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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Previous Comments: [2004-04-02 08:06:31] Robin at RHarmsen dot nl Description: When I turn on zend Engine1 Compatibility mode my code stops working (It worked perfect on PHP4 and PHP5 withoud the compatibility mode) PHP.ini diffreances: zend.ze1_compatibility_mode = On (off when error doesn't occure) allow_call_time_pass_reference = Off error_reporting = E_ALL register_long_arrays = Off register_argc_argv = Off extension=php_mysql.dll configure line (according to phpinfo()) Configure Command cscript /nologo configure.js --enable-snapshot-build --with-gd=shared I think it is realy strange that an error occures when the mode is activated. though it works on PHP4 and PHP5 withoud the mode activated. It looks like $db in the Menu class is'nt set Reproduce code: --- I got the source files located here to reproduce the bug http://www.rharmsen.nl/bugfiles/main.phps http://www.rharmsen.nl/bugfiles/clsDB.phps http://www.rharmsen.nl/bugfiles/clsMenu.phps Expected result: I expected that the menu was displayed Actual result: -- What I got was: Fatal error: Call to a member function query() on a non-object in clsMenu.php on line 36 -- Edit this bug report at http://bugs.php.net/?id=27836edit=1
#27836 [Fbk-Opn]: zend.ze1_compatibility_mode = On gives errors
ID: 27836
User updated by: Robin at RHarmsen dot nl
Reported By: Robin at RHarmsen dot nl
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Windows XP
PHP Version: 5.0.0RC1
New Comment:
I made a version withoud a DB...
It seems that when I set a property of a class in the constructor it
suddenly disappears
with this code I get the following error:
Fatal error: Call to a member function query() on a non-object in
bugcode.php on line 24
?php
class A
{
var $queryCount;
function A() {
$this-queryCount = 0;
}
function query() {
$this-queryCount = $this-queryCount + 1;
}
}
class B
{
var $a;
var $pageID;
function B($a,$pageID = 1) {
$this-a = $a;
$this-pageID = $pageID;
}
function showB() {
$result = $this-a-query();
if(is_null($this-a))
echo a = NULLbr/;
else
echo a = $this-a;br/;
echo pageID = $this-pageIDbr?;
}
}
$a = new A();
$b = new B($a);
$b-showB();
?
Previous Comments:
[2004-04-02 08:35:37] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-04-02 08:06:31] Robin at RHarmsen dot nl
Description:
When I turn on zend Engine1 Compatibility mode my code stops working
(It worked perfect on PHP4 and PHP5 withoud the compatibility mode)
PHP.ini diffreances:
zend.ze1_compatibility_mode = On (off when error doesn't occure)
allow_call_time_pass_reference = Off
error_reporting = E_ALL
register_long_arrays = Off
register_argc_argv = Off
extension=php_mysql.dll
configure line (according to phpinfo())
Configure Command cscript /nologo configure.js
--enable-snapshot-build --with-gd=shared
I think it is realy strange that an error occures when the mode is
activated. though it works on PHP4 and PHP5 withoud the mode
activated.
It looks like $db in the Menu class is'nt set
Reproduce code:
---
I got the source files located here to reproduce the bug
http://www.rharmsen.nl/bugfiles/main.phps
http://www.rharmsen.nl/bugfiles/clsDB.phps
http://www.rharmsen.nl/bugfiles/clsMenu.phps
Expected result:
I expected that the menu was displayed
Actual result:
--
What I got was:
Fatal error: Call to a member function query() on a non-object in
clsMenu.php on line 36
--
Edit this bug report at http://bugs.php.net/?id=27836edit=1
#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
Previous Comments:
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27837 [NEW]: Access Violation at 0104A7EE - xml_parse
From: seang at moosecat dot com dot au Operating system: XP Pro - IIS 5.1 PHP version: 5.0.0RC1 PHP Bug Type: XML related Bug description: Access Violation at 0104A7EE - xml_parse Description: Trying out 5.0.0 + SQLite with phpSQLiteAdmin (http://www.phpguru.org/phpSQLiteAdmin.html) The error seems to occur in /pear/XML/Parser.php line 302 which is: return xml_parse($this-parser, $data, $eof); I could not reproduce it with a simple script even with the same data - so I would guess that it only happens with more load on the memory. - the time when it does happen the resource id of the xml was 21. Hope it helps -- Edit bug report at http://bugs.php.net/?id=27837edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27837r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27837r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27837r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27837r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27837r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27837r=needscript Try newer version: http://bugs.php.net/fix.php?id=27837r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27837r=support Expected behavior: http://bugs.php.net/fix.php?id=27837r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27837r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27837r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27837r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27837r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27837r=dst IIS Stability: http://bugs.php.net/fix.php?id=27837r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27837r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27837r=float
#27838 [NEW]: SoapServer-setClass does not trigger __construct(), but only ClassName()
From: ron at xit dot nl
Operating system: Debian
PHP version: 5.0.0RC1
PHP Bug Type: Zend Engine 2 problem
Bug description: SoapServer-setClass does not trigger __construct(), but only
ClassName()
Description:
Hi,
When I use the SetClass method in my SoapServer object, it only triggers a
constructor with the name of the class: ClassName() and not __construct.
It happens when I don't even have a constructor called ClassName(), so
it's not a problem of the order in which the Zend Engine looks for
constructors. It simply always ignores __construct().
Reproduce code:
---
class SoapHandler
{
function __construct($param)
{
die($param);
}
}
$soap = new SoapServer(NULL, array(uri = urn:myurn));
$soap-setClass(SoapHandler, myparam);
Expected result:
output:
myparam
Actual result:
--
no output
rename the __construct to SoapHandler() and it will work as expected
--
Edit bug report at http://bugs.php.net/?id=27838edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27838r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27838r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27838r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27838r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27838r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27838r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27838r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27838r=support
Expected behavior: http://bugs.php.net/fix.php?id=27838r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27838r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27838r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27838r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27838r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27838r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27838r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27838r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27838r=float
#27759 [Com]: bcadd() causes crash if first parameter is empty string
ID: 27759 Comment by: marwan at marvonline dot org Reported By: patrick at rap-x dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.0.0RC1 New Comment: I've tested the April 1st build and it still has the problem. This affects all the bcmath functions and happens when either of the first two arguments evaluates to zero (this means 0, '0', and ''). I have the same setup as the original submitter. Previous Comments: [2004-03-29 16:29:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-29 15:43:37] patrick at rap-x dot com Description: The following code causes PHP5 RC1 (module)/ WINXP / Apache2 to crash. The same code doesn't cause a crash on PHP 4.3.4 / WINXP/ IIS (CGI) Fault discovered by using PEAR :: Benchmark Workaround is to mess around line 230ish in pear Timer.php so that the bcadd is not called. Reproduce code: --- $total = 0; $diff = ; bcadd($total, $diff, 6); Expected result: n/a Actual result: -- Apache2 crashes Windows Event Log records: Faulting application Apache.exe, version 2.0.49.0, faulting module php5ts.dll, version 5.0.0.0, fault address 0x0003c773. Apache error log: Parent: child process exited with status 3221225477 -- Restarting. [notice] Parent: Created child process 2120 [notice] Child 2120: Child process is running [notice] Child 2120: Acquired the start mutex. [notice] Child 2120: Starting 250 worker threads. [notice] Parent: Created child process 2120 [notice] Child 2120: Child process is running [notice] Child 2120: Acquired the start mutex. [notice] Child 2120: Starting 250 worker threads. [notice] Parent: child process exited with status 2147483649 -- Restarting. -- Edit this bug report at http://bugs.php.net/?id=27759edit=1
#27839 [NEW]: Similar problems to #27291 when using parse_ini_file() NOT get_browser()
From: little_miss_goth at hotmail dot com
Operating system: Linux(/others?)
PHP version: 4.3.4
PHP Bug Type: *General Issues
Bug description: Similar problems to #27291 when using parse_ini_file() NOT
get_browser()
Description:
I'm using the parse_ini_file() function as the basis for a
reimplementation of get_browser(). I'm having to process browscap.ini
without using the get_browser() function as the hosting people I'm using
won't set the browscap path in php.ini. Until fairly recently this was
working fine.
I'm receiving parse errors on the browscap.ini against the browser=Yahoo!
Slurp line, the same as Gary Keith mentions in one of his comments in Bug
#27291 [get_browser matches browscap.ini patterns incorrectly].
The browscap.ini section that causes this reads:
[Mozilla/5.0 (compatible; Yahoo! Slurp;
http://help.yahoo.com/help/us/ysearch/slurp)]
parent=Yahoo
browser=Yahoo! Slurp
From the ChangeLog and #27291's comment listing, issues with get_browser()
have apparently been fixed in 4.3.5.
However, I'm not using get_browser(), and so I was wondering if the fix
implemented for that will also remedy the parse_ini_file() issue? For
example, does get_browser() call parse_ini_file() [or does the engine do
something along those lines]?
Oh, BTW, editting the browscap.ini manually so that browser=Yahoo Slurp
rather than the sourced browser=Yahoo! Slurp causes everything to
function properly.
The hosting people are running under PHP 4.3.4 at the moment.
Reproduce code:
---
function browserCapabilities($userAgent, $browscapLocation) {
[..Some initialisation if variables..]
print Processing: $userAgent\n;
$this-browscapFile = parse_ini_file ($browscapLocation, TRUE);
[..Some array processing..]
[.. Print statements for browser capabilities..]
}
Expected result:
Processing: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; (R1
1.3); .NET CLR 1.1.4322)
Browser supports JavaScript: Yes
Browser supports CSS Level 2: Yes
Browser is text-only: No
Browser is MSIE: Yes
Browser detection complete. Browser type set to: msie.
Actual result:
--
Processing: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; (R1
1.3); .NET CLR 1.1.4322)
br /
bWarning/b: Error parsing
/nfs/home/air-cr2/public_html/anneharris/includes/browscap.ini on line
521
in b/nfs/home/air-cr2/public_html/includes/processBrowscap.hpi/b on
line b164/bbr /
Browser supports JavaScript: No
Browser supports CSS Level 2: No
Browser is text-only: No
Browser is MSIE: No
Browser detection complete. Browser type set to: incapable.
--
Edit bug report at http://bugs.php.net/?id=27839edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27839r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27839r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27839r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27839r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27839r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27839r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27839r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27839r=support
Expected behavior: http://bugs.php.net/fix.php?id=27839r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27839r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27839r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27839r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27839r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27839r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27839r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27839r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27839r=float
#20435 [Com]: $_POST not filled with enctype=multipart/form-data
ID: 20435 Comment by: robotech at mixmail dot com Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4CVS-2002-11-14 New Comment: I have already always_populate_raw_post_data in Off and I still having problem with $POST when I use enctye='multipart/form-data' Also I tried always_populate_raw_post_data in On and I had the same problem. Could someone give a solution at last to this problem. Thank you Axl Laruse Previous Comments: [2002-11-15 01:33:57] [EMAIL PROTECTED] Yes, hartmut fixed it already couple of days ago. [2002-11-15 01:15:02] [EMAIL PROTECTED] I found the source of the error. If always_populate_raw_post_data is set to On (and enctype=multipart/form-data), then $_POST is empty. If Off, then it has the correct values . In 4.2 it did work with always_... = On. I know hartmut was working on this stuff and I'm not sure if this is a real bug, or if it's a known bug. But at least, there should be some warning somewhere about that. chregu [2002-11-14 18:16:13] [EMAIL PROTECTED] I can't reproduce this problem even with mbstring... input type=test name=hello value=world Is this a typo for either [type=hidden] or [type=text]? [2002-11-14 18:00:56] [EMAIL PROTECTED] does not work = $_POST is empty... chregu [2002-11-14 17:59:47] [EMAIL PROTECTED] Following form does not work in PHP_4_3 from CVS. htmlheadtitle/title/head body ?php print_r($_POST);? form name=Master action=./post.php method=post enctype=multipart/form-data input type=test name=hello value=world input type=submit /form ?php phpinfo();? /body /html enctype=application/x-www-form-urlencoded does work. maybe it has something to do with the recent changes in the POST area. chregu -- Edit this bug report at http://bugs.php.net/?id=20435edit=1
#20298 [Com]: odbc.check_persistent not working
ID: 20298 Comment by: phpbugs at kevin dot offwhite dot net Reported By: phpbug at tab1 dot clara dot co dot uk Status: Open Bug Type: ODBC related Operating System: Windows 2000 Server SP4 PHP Version: 4CVS, 5CVS New Comment: I'm seeing this problem on a Red Hat 9 system running PHP 4.3.5 on Apache 2.0. I have check_persistent and allow_persistent On, and phpinfo() reports 1 active persistent link. I'm not clear if the problem is in the ODBC Driver not reporting back to php that the server has terminated the link, or if PHP is not properly checking if the persistent link needs to be re-established, but I thought it wouldn't hurt to report the bug here and see what we can come up with. An interesting thing is that while phpinfo() reports only one persistent link, a netstat on the webserver shows 6 connections to the database server. When I load the page with the odbc_pconnect call, it will alternate between working and not working from pageload to pageload, so it seems that some of those connections are good and others are not, and php is not removing the bad connection from the hash list. The error message I get is: Warning: odbc_exec(): SQL error: [unixODBC][IBM][iSeries Access ODBC Driver]Communication link failure. comm rc=10054 - CWBCO1047 - The iSeries server application disconnected the connection, SQL state 08S01 in SQLExecDirect in /usr/local/apache/htdocs/test.php on line 15 Previous Comments: [2003-12-02 04:47:47] phpbug at tab1 dot clara dot co dot uk okay this was tested with: php4-win32-STABLE-200312020930 1st run: resource(2) of type (odbc link persistent) followed by the correct query results 2nd run (after killing db connection): resource(1) of type (odbc link persistent) Warning: odbc_exec(): SQL error: [Informix][Informix ODBC Driver]Communication link failure., SQL state 08S01 in SQLExecDirect in C:\InetPub\wwwroot\test.php on line 8 [2003-12-01 03:00:17] [EMAIL PROTECTED] Can you add 'var_dump($dbconn);' after that odbc_pconnect() call..? What does it output? (in the re-run) [2003-02-20 04:58:12] t_o_m_ at yahoo dot com Having reread all of this I see that nowhere have I mentioned I'm using IIS (ISAPI) not Apache, if that makes a difference? I thought when I put Windows in the OS box whoever read it would assume IIS. In answer to your question no, the behaviour is the same if odbc.check_persistent is on or off. The point is when it is off I would expect it to be my responsibility to check the connection and would expect the error if I did not. I would expect that when odbc.check_persistent was on odbc_pconnect was supposed to check the connection for me if the connection it is about to return from its pool is dead then it should discard it and create a new one as when the pool is empty. Which is clearly not happening. [2003-02-18 12:01:03] [EMAIL PROTECTED] Well the nature of CGI doesn't really lend itself to supporting persistant connections. It's run when requested and then exited after that. So no data can really presist between pages that exists solely in the CGI. So this behavior only exists when odbc.check_persistent is turned on? [2003-02-17 10:08:22] t_o_m_ at yahoo dot com Yes still a problem under 4.3.0 I am using the ISAPI module. I don't believe that persistent connections are supported at all under CGI. So odbc_pconnect == odbc_connect which would give the illusion of working, although the connection would not actually be persisting. The first time you reload the page after killing the database connection you get: Warning: SQL error: No response from the backend; Subsequent reloads give: Warning: SQL error: Could not send Query(connection dead); 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/20298 -- Edit this bug report at http://bugs.php.net/?id=20298edit=1
#20708 [Com]: 'foo'==0 returns true
ID: 20708
Comment by: milos at mcservices dot com
Reported By: wb at sapo dot pt
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: linux 2.2.20, linux 2.4.19
PHP Version: 4.2.3
New Comment:
This should be BOLDED in RED in documentation!
Previous Comments:
[2002-11-28 18:34:32] wb at sapo dot pt
thank you for very fast information.
type juggling is a great feature but really hard to learn. now i
learned that it casts my string to numeric for the comparison with an
integer - my coding would have needed the integer casted to a string.
sorry for bothering you. i will go and look for more information about
precedence of type casting in comparisons if it is that way it works.
[2002-11-28 18:13:07] [EMAIL PROTECTED]
The numerical value of 'foo' is 0. If you want to compare both value
*and* type, use ===
[2002-11-28 18:11:16] wb at sapo dot pt
another summary
[2002-11-28 18:02:32] wb at sapo dot pt
sorry, im really not sure if this is a kind of bug or if i'm getting
something wrong: the two lines
echo 'foo'==0 ? 'is true ' : 'is false ';
if('bar'==0) echo 'is true '; else echo 'is false ';
will output:
is true is true
i dont understand why 'foo'==0 returns true.
the way i understand the manual, php should consider 'foo' a nonempty
string and 0 a zero integer. even if it would do a boolean comparison,
according to the manual 'foo' should be juggled to true and 0 should be
juggled to false. how can 'foo'==0 return true? have i missed
something?
i hope i do not resubmit a known issue, i tried some queries but i
really didnt know how to lookup this issue.
this happens with variables as well. i ran into this problem in my
programming when comparing array keys that could be numeric or string.
a 0 array key compared against any nonempty string array key always
returned true. it took me a while to find out that's why my program
didn´t work the way i thought it should.
i hope this is not something that happens only to me, but i have tested
the two lines on three different boxes before writing to you.
my configure line:
./configure' '--with-mysql=/usr/local/mysql'
'--with-apache=../apache_1.3.26' '--enable-ftp'
'--with-zlib-dir=/usr/lib'
Best regards,
wolfgang
--
Edit this bug report at http://bugs.php.net/?id=20708edit=1
#19022 [Com]: PHP Warning: Failed to write session data (files)
ID: 19022
Comment by: phpbugs at chime dot tv dot cutthis
Reported By: phpbugs at mx4k dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:
I'm losing session variables randomly too. Sometimes I get the Failed
to write... error but not always.
Since I don't host my servers I can't give full server details. However
here's a test script on both servers with the relevant PHPInfo:
Server A: http://chir.ag/test.php
Server B: https://secure.magictanorders.com/test.php
Test script:
?php
session_cache_expire(30);
session_start();
if($_SESSION[test] == 1)
{
echo centerSessions work./centerbrbr;
}
else
{
$_SESSION[test] = 1;
echo centerStarting Session... Click refresh to see if the
session works or not./centerbrbr;
}
phpinfo();
?
Basically Server A works ALWAYS and remembers the session for upto 30
minutes. Server B randomly forgets the session in 1 second to 5
minutes. No session on Server B lasts more than 5 minutes.
The problem randomly started on Server B yesterday (Apr 1). We thought
it was output_buffering (and turned it ON) but that didn't help.
Problem was back this morning. The site was working perfectly for 3
weeks before breaking down randomly. If anyone can give any suggestions
I will be very thankful.
Previous Comments:
[2004-03-26 16:40:43] guertin at brucemaudesign dot com
Ok .. i got my setup working again .. an old bug that I
had forgotten the workaround for
I added (right before my initial session_start()):
session_destroy();
This destroys (presumably) any previous sessions
leftover after an older login. Maybe a php bug? Maybe
a browser issue? Maybe a bit of both? (I have it set
to not use cookies but yet it still does).
Perplexing, but hopefully this helps out others that
might run into this issue.
[2004-03-26 16:15:52] guertin at brucemaudesign dot com
Experiencing the same problems here... out of the blue.
Machine was running beautifully then all of a sudden it
stopped. No one can log in. I changed nothing... there
was not so much as a shell login on the machine for 30+
days.
sessions seem very fragile (as do many things in php
lately, it's getting scarier to keep running in
production environment).
[Fri Mar 26 16:14:04 2004] [error] PHP Warning: Failed
to write session data (files). Please verify that the
current setting of session.save_path is correct (/
websites/sessions) in Unknown on line 0
I've done so far almost everything suggested that worked
for others in here, none of it solved the problems. I
can tell you that:
1) it's NOT a permissions problem, my user running
apache/php has full write access to /tmp
2) it's not required for this user to have a home
directory. For those that need to do this to 'fix' the
problem, you OS is broken! (complain to your vendors)
3) it works for exactly one session. The first login
works fine and it seems that from there on in PHP tries
to use the same session ID for everyone ?
4) manually deleting the existing session file allows on
single login again after this.
Trying to track down more things. Really perplexing as
to why/how it stopped working when it ran fine for a 8+
months.
[2004-03-11 01:05:01] haccel at email dot com
After weeks of testing, I have fixed the problem at least for me.
The problem is the Zend Optimizer was corrupting/wiping (presumably)
the session data. Turning Zend Optimizer off completely fixed the
problem. When I turned Zend Optimizer back on and rebooted the session
problem was back again, this is the first reproducible action for me so
far.
Would be interesting to know how many others with this problem have
Zend Optimizer running.
[2004-03-01 20:15:09] stewart dot james at vu dot edu dot au
Just started to expience this after a shift to a new server.
php 4.3.3 on Debian Sarge
I get the error when I return to the site after logging out.
Looking at the cookie data the cookie data PHPSESSID is being set to
null, which my browser is recording in it's cookie database. Then on
return the site attempts to access informaiotn for PHPSESSID=(NULL)
which is what I think is causing the problem with this error.
Does anyone else see the same problem on their respective sites?
Stewart
[2004-01-21 08:45:26] august24_70 at yahoo dot com
I was having the problem on OpenBSD 3.2, Apache 1.3.26, PHP 3.2.3 when
running phpBB. I deleted all my cookies and logged
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810 Comment by: loki at arete dot cc Reported By: renato at galle dot com dot br Status: Closed Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment: This bug is also present in PHP-5.0.0RC1, and it is also present in the current CVS HEAD for PHP5 (as of 12:00 EST). Previous Comments: [2004-04-01 22:16:15] noackjr at alumni dot rice dot edu Please REOPEN: I just tried PHP 4.3.6-RC1 and the crash is still present. I also run FreeBSD 5.2.1-RELEASE-p4 with Apache 2.0.49. Also, what commit was supposed to fix this? Why no mention in NEWS or Changelog? [2004-04-01 13:20:39] nti at w4w dot net --- Don't work: --- +apache 2.0.49 +php5.0.0RC1 with pcre = Not OK +apache 2.0.49 +php4.3.5with pcre = Not OK --- works: --- +apache 2.0.49 +php5.0.0RC1 w/o pcre = OK +apache 2.0.49 +php4.3.5w/o pcre = OK +apache 2.0.48 +php5.0.0RC1 with pcre = OK +apache 2.0.48 +php4.3.5with pcre = OK [2004-04-01 10:36:45] nti at w4w dot net The same issue with ***php5RC1*** !!! ... - Install apache-2.0.49 - Compile php-5RC1 with PCRE support using apxs - run apachectl start - run apachectl restart or apachectl graceful and apache will die [2004-04-01 05:39:52] packager at rabbito dot org The exact same issue occurs on Windows as well, but was marked Bogus: http://bugs.php.net/bug.php?id=27751 An update to Changelog or NEWS on this bug may be good [2004-04-01 05:39:51] packager at rabbito dot org The exact same issue occurs on Windows as well, but was marked Bogus: http://bugs.php.net/bug.php?id=27751 An update to Changelog or NEWS on this bug may be good 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/27810 -- Edit this bug report at http://bugs.php.net/?id=27810edit=1
#27842 [NEW]: unable to run stored procedure (sp_monitor)
From: pop501 at hotmail dot com Operating system: windows NT SP6 PHP version: 4.3.5 PHP Bug Type: Sybase-ct (ctlib) related Bug description: unable to run stored procedure (sp_monitor) Description: Upgraded from PHP 4.2.1 to 4.3.5 (Had number of chalanges (espacially with sockets)) Using sybase-ct lib to gather staistics on Sybase database. Using NT with service pack 6, Sybase 12 openclient. After upgrade getting this messages 4 times on each run: Notice: sybase_query(): Sybase: Unexpected results, cancelling current in foo.php on line 1000 Reproduce code: --- sybase_query(sp_monitor,$con); Expected result: Empty result with no errors expected. Actual result: -- Notice: sybase_query(): Sybase: Unexpected results, cancelling current in foo.php on line 1000 -- Edit bug report at http://bugs.php.net/?id=27842edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27842r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27842r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27842r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27842r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27842r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27842r=needscript Try newer version: http://bugs.php.net/fix.php?id=27842r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27842r=support Expected behavior: http://bugs.php.net/fix.php?id=27842r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27842r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27842r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27842r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27842r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27842r=dst IIS Stability: http://bugs.php.net/fix.php?id=27842r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27842r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27842r=float
#27843 [NEW]: sybase_query() triggers (spurious?) notices when query is a stored procedure
From: michaels at crye-leike dot com
Operating system: Linux
PHP version: 4.3.5
PHP Bug Type: Sybase-ct (ctlib) related
Bug description: sybase_query() triggers (spurious?) notices when query is a stored
procedure
Description:
Using FreeTDS 0.62.1 compiled with:
./configure --with-tdsver=4.2 --enable-msdblib --with-gnu-ld
--enable-shared --enable-static
Using PHP 4.3.5 compiled with:
./configure --with-mysql=/usr/local/mysql/ --enable-track-vars
--enable-trans-sid --with-sybase-ct=/usr/local/
--with-pgsql=/usr/local/pgsql/ --enable-xslt --with-xslt-sablot
--with-zlib --with-ldap --with-apxs=/usr/local/apache/bin/apxs
Using TDS version 7.0
Using Microsoft SQL Server 7.0
It seems that sybase_query() triggers an E_NOTICE (Sybase: Unexpected
results, cancelling current) whenever the query in question is a stored
procedure. This notice is not triggered when using either --with-sybase
or --with-mssql (using dblib). For those of us running with an
error_reporting level of E_ALL, this causes a problem, as we'd either have
to preface every call to sybase_query() with @ and handle all Sybase
errors manually, or lower the error_reporting level.
Reproduce code:
---
?
$dbh = sybase_connect('db_host', 'user', 'pass');
sybase_select_db('db_name', $dbh);
sybase_query(
create procedure test_bug
as
begin
select 1
end
, $dbh);
sybase_query(exec test_bug, $dbh);
sybase_query(drop procedure test_bug, $dbh);
?
Expected result:
Expected empty output with no notices triggered.
Actual result:
--
Notice: sybase_query(): Sybase: Unexpected results, cancelling current in
- on line 13
--
Edit bug report at http://bugs.php.net/?id=27843edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27843r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27843r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27843r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27843r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27843r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27843r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27843r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27843r=support
Expected behavior: http://bugs.php.net/fix.php?id=27843r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27843r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27843r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27843r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27843r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27843r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27843r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27843r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27843r=float
#10250 [Com]: UnixODBC can make use of SQLDriverConnect functionality too
ID: 10250 Comment by: vanderwl at us dot ibm dot com Reported By: dzoll at nyscul dot org Status: Closed Bug Type: ODBC related Operating System: linux PHP Version: 4.0.4pl1 New Comment: This also applies to the iODBC driver manager. Can this also be added to the #ifdef? Previous Comments: [2001-05-08 15:49:15] [EMAIL PROTECTED] now in cvs. thank you! [2001-04-18 21:41:53] [EMAIL PROTECTED] have you tried this fix with an older version of UnixODBC? [2001-04-09 15:15:59] dzoll at nyscul dot org In ext/odbc/php_odbc.c: odbc_sqlconnect(), only Openlink and Empress can make use of the SQLDriverConnect function. UnixODBC can use SQLDriverConnect as well, and in the case of some Easysoft ODBC connections, it *must* be able to use the SQLDriverConnect format in order to actually connect to the database. I have tried changing the #ifdef HAVE_EMPRESS to #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC) and everything worked fine, giving full access to the SQLDriverConnect method of calling odbc_connect and odbc_pconnect. If this could be incorporated into a later release, it would be very useful. (BTW, this was tested with UnixODBC 2.0.5) -- Edit this bug report at http://bugs.php.net/?id=10250edit=1
#27768 [Com]: Apache crashes with Mysql
ID: 27768 Comment by: codejysper at lesitedejp dot com Reported By: mathieuparent at infonie dot fr Status: Open Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.0.0RC1 New Comment: In my case, php_mysql.dll and libmysql.dll MUST be copied in C:\WINNT. If these files are copied in 'C:\Program Files\Apache Group\Apache' where we can find apache.exe, then apache crashes unexpectedly (process returns 1067 error code). Previous Comments: [2004-04-02 09:29:57] marwan at marvonline dot org Did you copy libmysql.dll to where apache can find it? Either the system32 directory or in the same folder as apache itself. [2004-03-30 01:51:39] mathieuparent at infonie dot fr # Note if I run 'net start apache' many times, sometimes it work's. No it crashes everytime as well as doing ..\Apache.exe [2004-03-30 01:44:14] mathieuparent at infonie dot fr Description: When I use Apache Mysql services without mysql extension in php, no problem. But if I uncomment ;extension=mysql in php.ini, apache crashes. I have php5rc1, apache 1.3.29, mysql 4.0.18, WinXP SP1. With the default php.ini. (-recommended). I think that one dll is not at the good place (but which). Reproduce code: --- net stop apache uncomment ;extension=mysql in php.ini net start apache Expected result: Apache shouldn't crash. Note if I run 'net start apache' many times, sometimes it work's. (sorry it is not a good report) Actual result: -- Error : |szAppName : Apache.exe |szModName : php5ts.dll |szModVer : 5.0.0.0 offset : 0003c773 -- Edit this bug report at http://bugs.php.net/?id=27768edit=1
#27828 [Fbk-Opn]: sybase_free_result crashes
ID: 27828
User updated by: deanb at gbtn dot net
Reported By: deanb at gbtn dot net
-Status: Feedback
+Status: Open
Bug Type: Sybase-ct (ctlib) related
Operating System: Digital Unix 4.0F
PHP Version: 4.3.5
New Comment:
Nope, same crash with php4-STABLE-200404021630.
Previous Comments:
[2004-04-02 06:12:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-04-02 04:21:50] tvoigt at informatik dot tu-cottbus dot de
Hi there!
The bug ist reproducible here on Debian Woody + apache-1.3.29/php =
4.3.4RC3, too.
It was most probably introduced while fixing
http://bugs.php.net/bug.php?id=26407: sybase_free_result() works
properly up to php-4.3.4RC2, but not with a patched 4.3.4RC2 to solve
bug #26407 (that patch then made it into 4.3.4RC3).
Well, I'm sorry for not testing sybase_free_result() afterwards, never
used it before...
Best regards,
Thomas
[2004-04-01 15:59:18] deanb at gbtn dot net
Description:
If I use sybase_free_result() in a script, then php crashes. The exact
same code works fine in php 4.3.4.
./configure --with-sybase-ct=${SYBASE}
--enable-track-vars
--without-mysql
--with-apache=../apache_1.3.29
--disable-dba
--enable-session
Reproduce code:
---
?php
$db = sybase_connect(server, user, pass);
$res = sybase_query(select name from sysdatabases, $db);
while ($data = sybase_fetch_array($res)) {
print db: $data[0]\n;
}
sybase_free_result($res);
sybase_close($db);
?
Expected result:
a list of databases with no crashes
Actual result:
--
php s.php
db: master
db: model
db: sybsystemprocs
db: tempdb
Segmentation fault (core dumped)
dbx php core
dbx version 3.11.10
Type 'help' for help.
Core file created by program php
signal Segmentation fault at [_efree:241 ,0x12013e7c8]
CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size);
(dbx) where
0 _efree(ptr = 0x52667250203a6264)
[/app/apps/web/php-4.3.5/Zend/zend_alloc.c:241, 0x12013e7c8]
1 php_sybase_finish_results(result = 0x1400cd5b8)
[/app/apps/web/php-4.3.5/ext/sybase_ct/php_sybase_ct.c:1011,
0x1200e766c]
2 zif_sybase_free_result(ht = 1, return_value = 0x1400d8298,
this_ptr = (nil), return_value_used = 0)
[/app/apps/web/php-4.3.5/ext/sybase_ct/php_sybase_ct.c:1602,
0x1200e8f20]
3 execute(op_array = 0x1400c52d8)
[/app/apps/web/php-4.3.5/Zend/zend_execute.c:1621, 0x12016fdf4]
4 zend_execute_scripts(type = 8, retval = (nil), file_count = 3)
[/app/apps/web/php-4.3.5/Zend/zend.c:889, 0x120155be0]
5 php_execute_script(primary_file = 0x11fffec10)
[/app/apps/web/php-4.3.5/main/main.c:1731, 0x120116d84]
6 main(argc = 2, argv = 0x11fffef28)
[/app/apps/web/php-4.3.5/sapi/cli/php_cli.c:822, 0x1201722e4]
(dbx) up
php_sybase_finish_results:1011 efree(result-tmp_buffer[i]);
(dbx) up
zif_sybase_free_result:1602 php_sybase_finish_results(result);
--
Edit this bug report at http://bugs.php.net/?id=27828edit=1
#27801 [Com]: networking issue..
ID: 27801 Comment by: tibyke at tibyke dot hu Reported By: ury at iptel dot by Status: Feedback Bug Type: Sockets related Operating System: linux PHP Version: 4.3.5 New Comment: same scenario here with same results. 1 minute wait, then timeout without trying to authenticate to mail server (no sql connection to check user/password) 4.3.6RC1 is still buggy regards, tibyke Previous Comments: [2004-03-31 09:38:52] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2004-03-31 08:32:36] ury at iptel dot by Description: i try use ilohawebmail http://ilohamail.org/ with php 4.3.5 and... it doesn't working, tcpdump says that php wait about 1 minute after pop3 server says first '+OK' during login to pop3 server... with 4.3.3 version - no any problems. -- Edit this bug report at http://bugs.php.net/?id=27801edit=1
#27844 [NEW]: $_POST and $_FILES empty when upload_max_size exceeded
From: marco at opus dot ch Operating system: Windows 2000 PHP version: 4.3.6RC1 PHP Bug Type: Unknown/Other Function Bug description: $_POST and $_FILES empty when upload_max_size exceeded Description: I've got a form which uploads a file along with other information (including and ID that identifies location in the site). When I upload a file that exceeds the size limits, I get no $_FILES and no $_POST information. That means if the user chooses a large file, they are redirected to a 'not allowed to do that here' page instead of a form error, because the ID is missing and their request can't be validated. This bug has been documented in the user comments in the documentation, but is still in the latest release: http://php.planetmirror.com/manual/en/features.file-upload.common-pitfalls.php Reproduce code: --- html body form action=test.html enctype=multipart/form-data method=post input type=hidden name=SID value=XXX input type=file name=test input type=submit /form /html ?php print_r( $_REQUEST ); ? -- Edit bug report at http://bugs.php.net/?id=27844edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27844r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27844r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27844r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27844r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27844r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27844r=needscript Try newer version: http://bugs.php.net/fix.php?id=27844r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27844r=support Expected behavior: http://bugs.php.net/fix.php?id=27844r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27844r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27844r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27844r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27844r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27844r=dst IIS Stability: http://bugs.php.net/fix.php?id=27844r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27844r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27844r=float
#27814 [Asn]: Multiple small packets send for HTTP request
ID: 27814 User updated by: Olaf at XCC dot TMFWeb dot NL Reported By: Olaf at XCC dot TMFWeb dot NL Status: Assigned Bug Type: Performance problem Operating System: Linux, Windows XP, 2003 PHP Version: 5.0 Assigned To: wez New Comment: iliaa, are you talking about ob_start()? I'm not talking about the output traffic between PHP script/server and browser/client, but about the input traffic between script/server and php.net generated by file_get_contents(). Previous Comments: [2004-03-31 18:04:36] [EMAIL PROTECTED] [2004-03-31 17:55:02] [EMAIL PROTECTED] You're correct; there is no write buffering for the http request. [2004-03-31 14:49:43] [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 Turn on output buffering. [2004-03-31 14:48:37] Olaf at XCC dot TMFWeb dot NL Description: This code sends two packets, one of 16 bytes and one of 17 bytes. I guess this is caused by multiple calls to php_stream_write in http_fopen_wrapper.c: php_stream_url_wrap_http_ex Preparing the entire request in one buffer and sending it via one call should produce less packets (and be faster). Reproduce code: --- ?php echo strlen(file_get_contents(http://php.net/;)); ? Expected result: One packet of 33 bytes. Actual result: -- Two packets. -- Edit this bug report at http://bugs.php.net/?id=27814edit=1
#27839 [Opn-Bgs]: Similar problems to #27291 when using parse_ini_file() NOT get_browser()
ID: 27839
Updated by: [EMAIL PROTECTED]
Reported By: little_miss_goth at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux(/others?)
PHP Version: 4.3.4
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Duplicate of bug #27372.
In both instances internal ini parsing mechanism is being
used.
Previous Comments:
[2004-04-02 10:10:32] little_miss_goth at hotmail dot com
Description:
I'm using the parse_ini_file() function as the basis for a
reimplementation of get_browser(). I'm having to process browscap.ini
without using the get_browser() function as the hosting people I'm
using won't set the browscap path in php.ini. Until fairly recently
this was working fine.
I'm receiving parse errors on the browscap.ini against the
browser=Yahoo! Slurp line, the same as Gary Keith mentions in one of
his comments in Bug #27291 [get_browser matches browscap.ini patterns
incorrectly].
The browscap.ini section that causes this reads:
[Mozilla/5.0 (compatible; Yahoo! Slurp;
http://help.yahoo.com/help/us/ysearch/slurp)]
parent=Yahoo
browser=Yahoo! Slurp
From the ChangeLog and #27291's comment listing, issues with
get_browser() have apparently been fixed in 4.3.5.
However, I'm not using get_browser(), and so I was wondering if the fix
implemented for that will also remedy the parse_ini_file() issue? For
example, does get_browser() call parse_ini_file() [or does the engine
do something along those lines]?
Oh, BTW, editting the browscap.ini manually so that browser=Yahoo
Slurp rather than the sourced browser=Yahoo! Slurp causes everything
to function properly.
The hosting people are running under PHP 4.3.4 at the moment.
Reproduce code:
---
function browserCapabilities($userAgent, $browscapLocation) {
[..Some initialisation if variables..]
print Processing: $userAgent\n;
$this-browscapFile = parse_ini_file ($browscapLocation, TRUE);
[..Some array processing..]
[.. Print statements for browser capabilities..]
}
Expected result:
Processing: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
(R1 1.3); .NET CLR 1.1.4322)
Browser supports JavaScript: Yes
Browser supports CSS Level 2: Yes
Browser is text-only: No
Browser is MSIE: Yes
Browser detection complete. Browser type set to: msie.
Actual result:
--
Processing: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
(R1 1.3); .NET CLR 1.1.4322)
br /
bWarning/b: Error parsing
/nfs/home/air-cr2/public_html/anneharris/includes/browscap.ini on line
521
in b/nfs/home/air-cr2/public_html/includes/processBrowscap.hpi/b
on line b164/bbr /
Browser supports JavaScript: No
Browser supports CSS Level 2: No
Browser is text-only: No
Browser is MSIE: No
Browser detection complete. Browser type set to: incapable.
--
Edit this bug report at http://bugs.php.net/?id=27839edit=1
#27845 [NEW]: 64bit compile warnings
From: asloan at antarctica dot net Operating system: Mandrake 9.2 AMD64 PHP version: 4.3.5 PHP Bug Type: *General Issues Bug description: 64bit compile warnings Description: Compile warnings on 64bit Linux (Opteron) platform: Thank you for using PHP. /home/asloan/php-4.3.5/ext/standard/exec.c: In function `proc_open_rsrc_dtor': /home/asloan/php-4.3.5/ext/standard/exec.c:600: warning: cast from pointer to integer of different size /home/asloan/php-4.3.5/ext/standard/exec.c: In function `zif_proc_open': /home/asloan/php-4.3.5/ext/standard/exec.c:1019: warning: cast to pointer from integer of different size /home/asloan/php-4.3.5/ext/standard/file.c: In function `zif_fgetcsv': /home/asloan/php-4.3.5/ext/standard/file.c:2308: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /home/asloan/php-4.3.5/ext/standard/file.c:2373: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /home/asloan/php-4.3.5/ext/standard/var_unserializer.c: In function `php_var_unserialize': /home/asloan/php-4.3.5/ext/standard/var_unserializer.c:308: warning: comparison is always false due to limited range of data type ext/mysql/libmysql/my_tempnam.lo(.text+0x47): In function `my_tempnam': /home/asloan/php-4.3.5/ext/mysql/libmysql/my_tempnam.c:115: the use of `tempnam' is dangerous, better use `mkstemp' Build complete. (It is safe to ignore warnings about tempnam and tmpnam). -- Edit bug report at http://bugs.php.net/?id=27845edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27845r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27845r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27845r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27845r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27845r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27845r=needscript Try newer version: http://bugs.php.net/fix.php?id=27845r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27845r=support Expected behavior: http://bugs.php.net/fix.php?id=27845r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27845r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27845r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27845r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27845r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27845r=dst IIS Stability: http://bugs.php.net/fix.php?id=27845r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27845r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27845r=float
#9673 [Com]: Relative paths in require(), require_once(), include(), include_once()
ID: 9673 Comment by: chapwest at hotmail dot com Reported By: vvo at geocities dot com Status: Feedback Bug Type: Scripting Engine problem Operating System: RedHat Linux PHP Version: 4.3.2 New Comment: I have no idea what this means in regard to my sight. Michael Previous Comments: [2004-04-01 18:36:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-04-01 18:32:42] vvo at geocities dot com setting version to 4.3.2 [2004-04-01 18:31:04] vvo at geocities dot com Not clear to me why the issue status was changed to Bogus. As far as I can tell multiple people have same issue. [2004-03-24 15:14:47] chunan at zingy dot com I am also having problems with the include() function. I also agree that relative includes should always be relative to the current script. [2004-03-18 17:51:28] schapht at drexel dot edu I am using version 4.3.2, and I have this problem. I also agree that the php include behavior hurts modularity. I can't reuse classes w/o modifying the code to handle the new parent-script path. Please tell me there's a fix for this. 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/9673 -- Edit this bug report at http://bugs.php.net/?id=9673edit=1
#27845 [Opn-Bgs]: 64bit compile warnings
ID: 27845 Updated by: [EMAIL PROTECTED] Reported By: asloan at antarctica dot net -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Mandrake 9.2 AMD64 PHP Version: 4.3.5 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Previous Comments: [2004-04-02 15:33:42] asloan at antarctica dot net Description: Compile warnings on 64bit Linux (Opteron) platform: Thank you for using PHP. /home/asloan/php-4.3.5/ext/standard/exec.c: In function `proc_open_rsrc_dtor': /home/asloan/php-4.3.5/ext/standard/exec.c:600: warning: cast from pointer to integer of different size /home/asloan/php-4.3.5/ext/standard/exec.c: In function `zif_proc_open': /home/asloan/php-4.3.5/ext/standard/exec.c:1019: warning: cast to pointer from integer of different size /home/asloan/php-4.3.5/ext/standard/file.c: In function `zif_fgetcsv': /home/asloan/php-4.3.5/ext/standard/file.c:2308: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /home/asloan/php-4.3.5/ext/standard/file.c:2373: warning: passing arg 4 of `_php_stream_get_line' from incompatible pointer type /home/asloan/php-4.3.5/ext/standard/var_unserializer.c: In function `php_var_unserialize': /home/asloan/php-4.3.5/ext/standard/var_unserializer.c:308: warning: comparison is always false due to limited range of data type ext/mysql/libmysql/my_tempnam.lo(.text+0x47): In function `my_tempnam': /home/asloan/php-4.3.5/ext/mysql/libmysql/my_tempnam.c:115: the use of `tempnam' is dangerous, better use `mkstemp' Build complete. (It is safe to ignore warnings about tempnam and tmpnam). -- Edit this bug report at http://bugs.php.net/?id=27845edit=1
#27836 [Opn-Csd]: zend.ze1_compatibility_mode = On gives errors
ID: 27836
User updated by: Robin at RHarmsen dot nl
Reported By: Robin at RHarmsen dot nl
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows XP
PHP Version: 5.0.0RC1
New Comment:
I just downloaded this CVS version:
php5-win32-200404011830.zip
Built On: Apr 01, 2004 18:30 GMT
and it alreadt seems to be fixed :D
I gues it was one of these (From the news.txt)
- Reimplement zend.ze1_compatibility_mode to have better PHP 4
complicance.
(Dmitry, Andi)
- Fixed bug #27641 (Object cloning in ze1_compatibility_mode was
reimplemented)
(Dmitry, Andi)
Previous Comments:
[2004-04-02 08:55:03] Robin at RHarmsen dot nl
I made a version withoud a DB...
It seems that when I set a property of a class in the constructor it
suddenly disappears
with this code I get the following error:
Fatal error: Call to a member function query() on a non-object in
bugcode.php on line 24
?php
class A
{
var $queryCount;
function A() {
$this-queryCount = 0;
}
function query() {
$this-queryCount = $this-queryCount + 1;
}
}
class B
{
var $a;
var $pageID;
function B($a,$pageID = 1) {
$this-a = $a;
$this-pageID = $pageID;
}
function showB() {
$result = $this-a-query();
if(is_null($this-a))
echo a = NULLbr/;
else
echo a = $this-a;br/;
echo pageID = $this-pageIDbr?;
}
}
$a = new A();
$b = new B($a);
$b-showB();
?
[2004-04-02 08:35:37] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-04-02 08:06:31] Robin at RHarmsen dot nl
Description:
When I turn on zend Engine1 Compatibility mode my code stops working
(It worked perfect on PHP4 and PHP5 withoud the compatibility mode)
PHP.ini diffreances:
zend.ze1_compatibility_mode = On (off when error doesn't occure)
allow_call_time_pass_reference = Off
error_reporting = E_ALL
register_long_arrays = Off
register_argc_argv = Off
extension=php_mysql.dll
configure line (according to phpinfo())
Configure Command cscript /nologo configure.js
--enable-snapshot-build --with-gd=shared
I think it is realy strange that an error occures when the mode is
activated. though it works on PHP4 and PHP5 withoud the mode
activated.
It looks like $db in the Menu class is'nt set
Reproduce code:
---
I got the source files located here to reproduce the bug
http://www.rharmsen.nl/bugfiles/main.phps
http://www.rharmsen.nl/bugfiles/clsDB.phps
http://www.rharmsen.nl/bugfiles/clsMenu.phps
Expected result:
I expected that the menu was displayed
Actual result:
--
What I got was:
Fatal error: Call to a member function query() on a non-object in
clsMenu.php on line 36
--
Edit this bug report at http://bugs.php.net/?id=27836edit=1
#27830 [Opn]: PHP segfaults immediately on startup
ID: 27830
Updated by: [EMAIL PROTECTED]
Reported By: adconrad at 0c3 dot net
Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
Could you try and compile with gcc-3.3 ? (I'm not
suggesting this as a fix, I'm just curious if it will work
around the problem)
I would do it myself if I had access to a Sparc64/linux
machine.
Previous Comments:
[2004-04-02 08:57:24] adconrad at 0c3 dot net
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27830 [Opn-Fbk]: PHP segfaults immediately on startup
ID: 27830
Updated by: [EMAIL PROTECTED]
Reported By: adconrad at 0c3 dot net
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
Previous Comments:
[2004-04-02 17:19:22] [EMAIL PROTECTED]
Could you try and compile with gcc-3.3 ? (I'm not
suggesting this as a fix, I'm just curious if it will work
around the problem)
I would do it myself if I had access to a Sparc64/linux
machine.
[2004-04-02 08:57:24] adconrad at 0c3 dot net
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27847 [NEW]: deplibs_check_method is being defined as unknown and pgsql.so won't build
From: shorej at sktc dot net Operating system: Redhat 9 PHP version: 4.3.6RC1 PHP Bug Type: PostgreSQL related Bug description: deplibs_check_method is being defined as unknown and pgsql.so won't build Description: I gave 4.3.6rc1 a whirl today. It sounded like it was fairly stable. I compiled it with: --prefix=/usr/local --with-pgsql=shared,/usr/local/pgsql --with-kerberos --with-imap --with-imap-ssl --with-openssl -- with-ldap --with-gd --with-zlib --with-apache=../../apache/apache_1.3.29 pgsql support was critical here. I tried 3 different variants of --with-pgsql. None of the times was pgsql.so built and installed. Tech support for a company that we're buying a product from that requires PHP w/ pgsql support gave us a hand finding the problem. One of the errors I was getting was: *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module pgsql. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. /bin/sh /usr/local/src/php/php-4.3.6RC1/libtool --silent --preserve-dup-deps --mode=install cp ext/pgsql/pgsql.la /usr/local/src/php/php-4.3.6RC1/modules PATH=$PATH:/sbin ldconfig -n /usr/local/src/php/php-4.3.6RC1/modules This tech support guy finally found that apparently $deplibs_check_method is being defined as unknown in libtool for whatever reason. We decided to back off to 4.3.5 for grins and sure enough it configured, compiled, and instaled like a champ. I started searching for why it was set to unknown in configure but could never figure enough of out what was going on there to be of any good. Expected result: I'd expect deplibs_check_method in 4.3.6rc1 to be detected and set the same as deplibs_check_method in 4.3.5. It is the same box after all. That seems to be the underlying problem as to why pgsql.so wasn't compiling. Actual result: -- deplibs_check_method is defined as unknown and libtool refuses to build pgsql.so on 4.3.6rc1, but not 4.3.5. I'm listing this under PostgreSQL even though I really don't think it has anything to do with this particular pgsql problem. I think it's a configure script issue, not detecting something correctly in 4.3.6rc1. pgsql 7.4.2 is compiled in a very standard manner and installed to the default /usr/local/pgsql base directory. ld.so.conf of course has /usr/local/pgsql/lib in it and ldconfig has been run multiple times. I can't think of anything else I could add to this report other than that even though this is techically a RH9 box, I've upgraded most every important library (except c) on this box and made the installation my own. Most of the stupid RH9 hacks have been undone. Looking back through the other posts with similar problems, it appears that libtool has been known to have issues in the past. Could 4.3.6rc1 have brought out another one? -- Edit bug report at http://bugs.php.net/?id=27847edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27847r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27847r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27847r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27847r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27847r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27847r=needscript Try newer version: http://bugs.php.net/fix.php?id=27847r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27847r=support Expected behavior: http://bugs.php.net/fix.php?id=27847r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27847r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27847r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27847r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27847r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27847r=dst IIS Stability: http://bugs.php.net/fix.php?id=27847r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27847r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27847r=float
#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
I'll build a Debian unstable chroot with gcc-3.3 and give it a whirl.
Of course, that'll also be using a new glibc, among other things, so
it's not terribly scientific.
I could also try gcc-3.0 on a stable system and see if that makes it
happy. Either way, gcc-2.95 and glibc 2.2 is a combination that should
probably be on the supported list for a while yet, I'd say.
Previous Comments:
[2004-04-02 17:19:22] [EMAIL PROTECTED]
Could you try and compile with gcc-3.3 ? (I'm not
suggesting this as a fix, I'm just curious if it will work
around the problem)
I would do it myself if I had access to a Sparc64/linux
machine.
[2004-04-02 08:57:24] adconrad at 0c3 dot net
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27830 [Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
Okay, there isn't much point in testing with gcc-3.3 on an unstable
system. I just install gcc-3.0.4 on the same stable system I was
testing this bug on, and it seems to work just fine.
config.{out,log}-gcc-3.0 and build.log-gcc-3.0 at the same URL as
previous logs.
So, to repeat: This bug appears to vanish building with gcc-3.0.4 (and
presumably any gcc 3.x), but manifests with gcc-2.95.
Previous Comments:
[2004-04-02 18:52:11] adconrad at 0c3 dot net
I'll build a Debian unstable chroot with gcc-3.3 and give it a whirl.
Of course, that'll also be using a new glibc, among other things, so
it's not terribly scientific.
I could also try gcc-3.0 on a stable system and see if that makes it
happy. Either way, gcc-2.95 and glibc 2.2 is a combination that should
probably be on the supported list for a while yet, I'd say.
[2004-04-02 17:19:22] [EMAIL PROTECTED]
Could you try and compile with gcc-3.3 ? (I'm not
suggesting this as a fix, I'm just curious if it will work
around the problem)
I would do it myself if I had access to a Sparc64/linux
machine.
[2004-04-02 08:57:24] adconrad at 0c3 dot net
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27762 [Csd]: S_ISSOCK undefined
ID: 27762 User updated by: ppporch at theporch dot com Reported By: ppporch at theporch dot com Status: Closed Bug Type: Compile Failure Operating System: SCO Openserver 5.0.6A PHP Version: 4.3.5 New Comment: I finally got back in town and recompiled php after your patch. It works great! Thanks. Previous Comments: [2004-03-30 05:59:19] [EMAIL PROTECTED] The next snapshot should contain the fix. (try http://snaps.php.net in a couple of hours; look for the stable snapshot) Note that the lack of S_ISSOCK on your platform means that you might not have much success using CLI version of PHP run from inetd (just in case you were thinking about it). [2004-03-29 17:04:39] ppporch at theporch dot com Description: When trying to compile the php-4.3.5 code with Openserver 5.0.6A using gcc, I receive a symbol undefined error in the link phase for S_ISSOCK referenced in mail/streams.lo In looking at the code, #if defined (S_ISFIFO) || defined(S_ISSOCK) on line 2019 is where the problem is. SCO Openserver has S_ISFIFO defined but not S_ISSOCK and so the if statement is true (from the S_ISFIFO) but the code the gets ececuted below it assumes that S_ISSOCK is defined which it is not on this system. A grep -rl S_ISSOCK * and grep -rl S_IFSOCK * in the /usr/include directory produces nothing. *grep -rl (recurse and list files that match). Expected result: The compile to complete. Actual result: -- /bin/sh /software/apache/php-4.3.5/libtool --silent --preserve-dup-deps --mode=link gcc -export-dynamic -g -O2 ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo
#27848 [NEW]: stripslashes removes single trailing slash
From: spam at pasher dot org Operating system: Debian (Linux 2.4.18-bf2.4) PHP version: 4.3.4 PHP Bug Type: Strings related Bug description: stripslashes removes single trailing slash Description: The stripslashes() function strips off a single trailing \ when altering a string. I can see that according to bug report http://bugs.php.net/bug.php?id=19947 , this function is not supposed to be an exact opposite of addslashes(), but it seems as thought a string that ends in a single \ should not have that slash removed, as the slash is not actually backslashing any part of the string. The only reasoning I could see behind this is that either any slash is stripped by stripslashes, or the \0 stored at the end of the C code string to terminate it (but not actually part of the PHP code string) is considered a character being escaped. If stripslashes() is designed to simple strip any slash from a string, it seems like the design should be rethought a bit, as it can potentially produced undesired results. Reproduce code: --- ? echo stripslashes(this is a test\\); ? Expected result: Displays this is a test\ Actual result: -- Displays this is a test -- Edit bug report at http://bugs.php.net/?id=27848edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27848r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27848r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27848r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27848r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27848r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27848r=needscript Try newer version: http://bugs.php.net/fix.php?id=27848r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27848r=support Expected behavior: http://bugs.php.net/fix.php?id=27848r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27848r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27848r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27848r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27848r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27848r=dst IIS Stability: http://bugs.php.net/fix.php?id=27848r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27848r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27848r=float
#27849 [NEW]: configure craps out on trivial syntax error
From: douzzer at mega dot nu Operating system: FreeBSD PHP version: 5.0.0RC1 PHP Bug Type: Compile Failure Bug description: configure craps out on trivial syntax error Description: line #47725 of configure script as distributed in 5.0.0RC1: if test $ext_shared = no || ! test -e $ext_builddir/config.h.in; then this blows up on FreeBSD (though note that I'm running a 4.0 userspace for complicated reasons). the fix is to change || ! test to -o ! That done, I got 5.0.0RC1 up and running and behaving itself. phpbb2.0.8/mysql4.x is my only app at present, but it's a pretty good workout I figure. -- Edit bug report at http://bugs.php.net/?id=27849edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27849r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27849r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27849r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27849r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27849r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27849r=needscript Try newer version: http://bugs.php.net/fix.php?id=27849r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27849r=support Expected behavior: http://bugs.php.net/fix.php?id=27849r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27849r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27849r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27849r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27849r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27849r=dst IIS Stability: http://bugs.php.net/fix.php?id=27849r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27849r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27849r=float
#27850 [NEW]: didnt get forms value in php
From: kalpeshchhatrola at compeersolutions dot com Operating system: Fedora PHP version: 4.3.4 PHP Bug Type: *General Issues Bug description: didnt get forms value in php Description: I didint get any value of the forms in php file, -- Edit bug report at http://bugs.php.net/?id=27850edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27850r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27850r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27850r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27850r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27850r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27850r=needscript Try newer version: http://bugs.php.net/fix.php?id=27850r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27850r=support Expected behavior: http://bugs.php.net/fix.php?id=27850r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27850r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27850r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27850r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27850r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27850r=dst IIS Stability: http://bugs.php.net/fix.php?id=27850r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27850r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27850r=float
#27850 [Opn-Fbk]: didnt get forms value in php
ID: 27850 Updated by: [EMAIL PROTECTED] Reported By: kalpeshchhatrola at compeersolutions dot com -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: Fedora PHP Version: 4.3.4 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Think paragraphs. Previous Comments: [2004-04-03 00:14:23] kalpeshchhatrola at compeersolutions dot com Description: I didint get any value of the forms in php file, -- Edit this bug report at http://bugs.php.net/?id=27850edit=1
#27850 [Fbk-Opn]: didnt get forms value in php files
ID: 27850 User updated by: kalpeshchhatrola at compeersolutions dot com -Summary: didnt get forms value in php Reported By: kalpeshchhatrola at compeersolutions dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Fedora PHP Version: 4.3.4 New Comment: i have code like, file name is test.php ?php ? html body form action='test.php' method=post input type=text name=name1 value='' input type=text name=lanme value='' input type=submit name=save value='save' /body /html so while after submit this page, and i want to echo $name1 and $lname in php file, there i didnt get any value which is i have inputed in to text field. if you know about this so please let us know you views Previous Comments: [2004-04-03 00:20:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Think paragraphs. [2004-04-03 00:14:23] kalpeshchhatrola at compeersolutions dot com Description: I didint get any value of the forms in php file, -- Edit this bug report at http://bugs.php.net/?id=27850edit=1
#27611 [Csd-Bgs]: segfault in xbuf_format_converter
ID: 27611
Updated by: [EMAIL PROTECTED]
Reported By: jan at horde dot org
-Status: Closed
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2004-03-15 (dev)
Previous Comments:
[2004-03-29 03:18:09] jan at horde dot org
Looks like this was rather a userland error. End endless loop due to an
object not being cloned in PHP 5 anymore (as it was in PHP 4) seems to
have causes the segfault.
[2004-03-15 23:04:32] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-03-15 18:24:48] jan at horde dot org
No, because the instructions how to find out where the crash happens
don't work anymore with php 5.
[2004-03-15 18:08:33] [EMAIL PROTECTED]
Please provide a short script that can be used to replicate
the problem.
[2004-03-15 17:09:27] jan at horde dot org
The line that appeared in the backtrace looks like:
if (is_a($date, 'Kronolith_Date')) {
If I comment it out, it still segfaults, but with a different bt:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 20318)]
0x406b31c7 in xbuf_format_converter (xbuf=0xbfe010b0,
fmt=0x40892d27 %sobject(%s)#%d (%d) {\n,
---Type return to continue, or q return to quit---
ap=0xbfe01104 É,[EMAIL PROTECTED])
at /home/jan/cvs/php5/main/spprintf.c:179
179 {
(gdb) bt
#0 0x406b31c7 in xbuf_format_converter (xbuf=0xbfe010b0,
fmt=0x40892d27 %sobject(%s)#%d (%d) {\n,
ap=0xbfe01104 É,[EMAIL PROTECTED])
at /home/jan/cvs/php5/main/spprintf.c:179
#1 0x406b45c9 in vspprintf (pbuf=0xbfe010e8, max_len=0,
format=0x40892d27 %sobject(%s)#%d (%d) {\n,
ap=0xbfe01104 É,[EMAIL PROTECTED])
at /home/jan/cvs/php5/main/spprintf.c:725
#2 0x406af365 in php_printf (format=0x40892d27 %sobject(%s)#%d (%d)
{\n)
at /home/jan/cvs/php5/main/main.c:397
#3 0x4067ccc0 in php_var_dump (struc=0x41cde8bc, level=1)
at /home/jan/cvs/php5/ext/standard/var.c:111
#4 0x4067cea6 in zif_var_dump (ht=1, return_value=0x41d32a28,
this_ptr=0x0,
return_value_used=0) at /home/jan/cvs/php5/ext/standard/var.c:156
#5 0x4071eb2d in zend_do_fcall_common_helper
(execute_data=0xbfe01270,
opline=0x80d6db8, op_array=0x81daba0)
at /home/jan/cvs/php5/Zend/zend_execute.c:2648
#6 0x4071f27d in zend_do_fcall_handler (execute_data=0xbfe01270,
opline=0x80d6db8, op_array=0x81daba0)
at /home/jan/cvs/php5/Zend/zend_execute.c:2777
#7 0x4071af4a in execute (op_array=0x81daba0)
at /home/jan/cvs/php5/Zend/zend_execute.c:1339
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/27611
--
Edit this bug report at http://bugs.php.net/?id=27611edit=1
#27850 [Opn-Bgs]: didnt get forms value in php files
ID: 27850 Updated by: [EMAIL PROTECTED] Reported By: kalpeshchhatrola at compeersolutions dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Fedora PHP Version: 4.3.4 New Comment: In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. Try using $_POST['name1'], $_POST['lanme'], etc... Previous Comments: [2004-04-03 00:58:19] kalpeshchhatrola at compeersolutions dot com i have code like, file name is test.php ?php ? html body form action='test.php' method=post input type=text name=name1 value='' input type=text name=lanme value='' input type=submit name=save value='save' /body /html so while after submit this page, and i want to echo $name1 and $lname in php file, there i didnt get any value which is i have inputed in to text field. if you know about this so please let us know you views [2004-04-03 00:20:49] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Think paragraphs. [2004-04-03 00:14:23] kalpeshchhatrola at compeersolutions dot com Description: I didint get any value of the forms in php file, -- Edit this bug report at http://bugs.php.net/?id=27850edit=1
