Bug #42659 [Com]: microtime() loses time in long-running scripts
Edit report at http://bugs.php.net/bug.php?id=42659edit=1
ID: 42659
Comment by: jdolecek at NetBSD dot org
Reported by:jdolecek at NetBSD dot org
Summary:microtime() loses time in long-running scripts
Status: No Feedback
Type: Bug
Package:Date/time related
Operating System: win32 only
PHP Version:5.2.4
Block user comment: N
New Comment:
The problem is still there even with PHP 5.3.3:
PHP 5.3.3 (cli) (built: Jul 21 2010 20:36:55)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
The test runs on physical machine (not a virtual) running Windows XP
SP3.
Output after about 21 hours with 5.3.3:
msec: [2010-09-07 09:12:15.7766]
sec : [2010-09-07 09:12:18]
msec: [2010-09-07 09:17:15.7700]
sec : [2010-09-07 09:17:18]
msec: [2010-09-07 09:22:15.7634]
sec : [2010-09-07 09:22:18]
msec: [2010-09-07 09:27:15.7568]
sec : [2010-09-07 09:27:18]
For comparison, here is output from parallelly running PHP 5.2.6:
msec: [2010-09-07 09:19:51.6134]
sec : [2010-09-07 09:19:54]
msec: [2010-09-07 09:24:51.6068]
sec : [2010-09-07 09:24:54]
msec: [2010-09-07 09:29:51.6003]
sec : [2010-09-07 09:29:54]
Both show ~3 sec time difference between microtime() and time()
Unfortunately I can't re-open the PR (it says I can't change the PR to
that state), so just adding a comment.
Previous Comments:
[2008-09-03 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2008-08-26 23:06:36] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
[2007-09-13 15:30:05] jdolecek at NetBSD dot org
Description:
When PHP script runs for long time, the value returned by microtime()
gradually drifts away from time(). The exact value depends on system,
but we've seen 5 hour difference to current time for script running
about a week, with drift about 1 minute per 5 minutes run (system
running under VMware). The script is daemon-like process, i.e. it's
blocked in select() most of time, and only occassionally wakes up to
process request.
Looking at win32/time.c, I spot one problematic spot in that the code
might not notice counter wrap-off if timer happens to be a higher value
after wrap-around then the last time the function was called. However,
that shouldn't be normally problem, since the counter wraps-around very
infrequently.
Reproduce code:
---
?php
ini_set('date.timezone', 'CET');
putenv(TZ=CET);
while(true) {
$sec = microtime(true);
echo msec: . sprintf([%s.%04d],
date(Y-m-d H:i:s, floor($sec)),
(float) ($sec - floor($sec)) *
1).\n;
echo sec : .date('[Y-m-d H:i:s]').\n;
sleep(300);
}
C program which demostrates how the two times diverge (cutpaste from
win32/time.c, so please forgive whitespace/style):
#include windows.h
#include winbase.h
#include time.h
#include winsock2.h
int getfilesystemtime(struct timeval *time_Info)
{
FILETIME ft;
__int64 ff;
LARGE_INTEGER li;
GetSystemTimeAsFileTime(ft); /* 100 ns blocks since 01-Jan-1641
*/
/* resolution seems to be 0.01 sec
*/
li.u.LowPart = ft.dwLowDateTime;
li.u.HighPart = ft.dwHighDateTime;
ff = li.QuadPart;
time_Info-tv_sec =
(int)(ff/(__int64)1000-(__int64)11644473600ULL);
time_Info-tv_usec = (int)(ff % 1000)/10;
return 0;
}
#define PW32G(x)(x)
int
main()
{
LARGE_INTEGER li;
__int64 freq, timer;
double dt;
struct timeval tv, *time_Info = tv, starttime, tv2;
QueryPerformanceFrequency(li);
freq = li.QuadPart;
getfilesystemtime(starttime);
QueryPerformanceCounter(li);
timer = li.QuadPart;
dt = (double)timer/PW32G(freq);
PW32G(starttime).tv_usec -=
(int)((dt-(int)dt)*100);
if (PW32G(starttime).tv_usec 0) {
PW32G(starttime).tv_usec += 100;
--PW32G(starttime).tv_sec;
}
PW32G(starttime).tv_sec -= (int)dt;
while(1
[PHP-BUG] Bug #52789 [NEW]: microtime() loses time in long-running scripts (please reopen)
From: Operating system: Windows XP PHP version: 5.3.3 Package: Date/time related Bug Type: Bug Bug description:microtime() loses time in long-running scripts (please reopen) Description: This is just a reminder for Bug #42659 since I cannot reopen that one. The problem with time difference between time() and microtime() on Windows XP is still there. Please reopen Bug #42659 -- Edit bug report at http://bugs.php.net/bug.php?id=52789edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52789r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52789r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52789r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52789r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52789r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52789r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52789r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52789r=needscript Try newer version: http://bugs.php.net/fix.php?id=52789r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52789r=support Expected behavior: http://bugs.php.net/fix.php?id=52789r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52789r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52789r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52789r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52789r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52789r=dst IIS Stability: http://bugs.php.net/fix.php?id=52789r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52789r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52789r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52789r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52789r=mysqlcfg
#41350 [Com]: Error in my_thread_global_end()
ID: 41350
Comment by: jdolecek at NetBSD dot org
Reported By: graham at directhostinguk dot com
Status: No Feedback
Bug Type: MySQL related
Operating System: Windows 2003
PHP Version: 5.2.3
New Comment:
Downgrading BOTH libmysql.dll AND php_mysql.dll to version bundled with
PHP 5.2.1 fixed the issue for me, too.
Previous Comments:
[2008-04-08 20:14:10] spambox at shad dot pp dot ru
Same bug just happened to me in this example:
C:\echo ?php echo date('T'); ? |php
MSD
Error in my_thread_global_end(): 1 threads didn't exit
MySQL extension was enabled in php.ini, but I didn't use any of it's
functions in example. PHP is 5.2.5, no other mysql related dll's are
available on system.
I posted this just to confirm that bug exists on my system too.
[2008-03-28 22:23:40] stein at visibone dot com
Brilliant, Scottmac, I did have some crufty lurking libmysql.dll's.
But I'm still getting the 5 second hang. Using the 5.2.5 php_mysql.dll
and php_mysqli.dll's the hang happens with a dirt-simple hello-world.
With 5.2.1 it happens if I mysql_connect().
Could it be having both mysql and mysqli enabled? I'm using both for
unit testing.
-- Bob Stein, VisiBone
[2008-03-26 20:56:53] lizwatson02452 at yahoo dot com
Following up briefly on my previous postchanging to an earlier
libmysql.dll appears to have fixed the problem for us, even though we
don't use MySQL.
Two difficulties with that:
1) It was hard for me to believe that was the solution.
2) It took some doing to persuade our hoster that changing the .dll
was not merely a fool's errand.
[2008-03-22 22:01:12] lizwatson02452 at yahoo dot com
I have this problem, and I am *not* using MySQL. I'm on PHP 5.2.4, with
SQL Server. Are there any workarounds that are not MySQL-specific?
[2008-03-20 20:05:06] [EMAIL PROTECTED]
Try PHP 5.2.5 with the libmysql.dll from
http://dev.mysql.com/downloads/mysql/5.0.html#win32
Make sure there are no other libmysql.dll lurking around your path.
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/41350
--
Edit this bug report at http://bugs.php.net/?id=41350edit=1
#43449 [Com]: Segmentation Fault when calling PL/SQL-function wich returns ref cursor
ID: 43449 Comment by: jdolecek at NetBSD dot org Reported By: michael dot virnstein at brodos dot de Status: Open Bug Type: OCI8 related Operating System: Linux PHP Version: 5.2.5 New Comment: I experience the same problem (PHP crash after executing PL/SQL function returning ref cursor via oci8 extension) with PHP 5.2.5 (cli) on Windows. Previous Comments: [2008-01-09 19:25:18] [EMAIL PROTECTED] I can reproduce it with PHP 5.2.5 but there is no crash using OCI8 1.3.0 Beta (from PECL). [2007-12-05 16:25:51] michael dot virnstein at brodos dot de This was the backtrace of another php-script, that's causing the same error. Here's the backtrace of the script containing the reporduce code: #0 0xb6aec13d in kghmkfree () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #1 0xb6af31df in kghaddex () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #2 0xb6af5096 in kghgex () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #3 0xb6af7a5a in kghfnd () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #4 0xb6af7f99 in kghprmalo () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #5 0xb6afa12c in kghalp () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #6 0xb6b03c48 in kghmrk () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #7 0xb66dba9f in kpuhhmrk () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #8 0xb66e209c in kpurclr () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #9 0xb6a76de7 in kpcxc2r () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #10 0xb6acc4d4 in ttcrs2c () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #11 0xb6adae97 in ttcacr () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #12 0xb6a695e2 in ttcdrv () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #13 0xb694fec5 in nioqwa () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #14 0xb67bdd97 in upirtrc () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #15 0xb6733a36 in kpurcsc () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #16 0xb66ea057 in kpuexecv8 () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #17 0xb66eb40a in kpuexec () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #18 0xb67c2902 in OCIStmtExecute () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #19 0xb76adac8 in php_oci_statement_execute (statement=0xb5fa4880, mode=0) at /usr/local/src/php-5.2.5/ext/oci8/oci8_statement.c:442 #20 0xb76b7be9 in zif_oci_execute (ht=2, return_value=0xb5fa9470, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /usr/local/src/php-5.2.5/ext/oci8/oci8_interface.c:1302 #21 0xb792d4cc in zend_do_fcall_common_helper_SPEC (execute_data=0xbf7fd6b4) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #22 0xb7932d96 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbf7fd6b4) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:1681 #23 0xb792d02d in execute (op_array=0x8308038) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #24 0xb792d646 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf7fd894) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #25 0xb792e119 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf7fd894) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:322 #26 0xb792d02d in execute (op_array=0xb5fa458c) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #27 0xb790829f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/src/php-5.2.5/Zend/zend.c:1134 #28 0xb78b6947 in php_execute_script (primary_file=0xbf7ffbd4) at /usr/local/src/php-5.2.5/main/main.c:2004 #29 0xb7981b0b in php_handler (r=0x82fde30) at /usr/local/src/php-5.2.5/sapi/apache2handler/sapi_apache2.c:631 #30 0x0807adf9 in ap_run_handler () #31 0x0807df57 in ap_invoke_handler () #32 0x080c6088 in ap_process_request () #33 0x080c338b in ap_process_http_connection () #34 0x08081d09 in ap_run_process_connection () #35 0x080df640 in child_main () #36 0x080df8a8 in make_child () #37 0x080e0645 in ap_mpm_run () #38 0x08068bce in main () [2007-12-05 14:16:03] michael dot virnstein at brodos dot de here's the backtrace: #0 0xb674607d in kpurclr () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #1 0xb6adade7 in kpcxc2r () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #2 0xb6b304d4 in ttcrs2c () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #3 0xb6b3ee97 in ttcacr () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #4 0xb6acd5e2 in ttcdrv () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #5 0xb69b3ec5 in nioqwa () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #6 0xb6821d97 in upirtrc () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #7 0xb6797a36 in kpurcsc () from /opt/oracle10/product/10/lib/libclntsh.so.10.1 #8 0xb674e057
#43778 [NEW]: SimpleXML regression regarding empty() in 5.2.4
From: jdolecek at netBSD dot org Operating system: Windows 2000 PHP version: 5.2.5 PHP Bug Type: SimpleXML related Bug description: SimpleXML regression regarding empty() in 5.2.4 Description: It seems empty() on simplexml 'array' elements doesn't work same way in 5.2.5 as in 5.2.3. In 5.2.5, empty() returns true even through the elements are actually present. Same code run under 5.2.3 works correctly, i.e. returning true only if the element is not present. Workaround is replace (!empty(...)) condition with isset() and test for count(), but this is inconvenient and breaks backwards compatibility. Reproduce code: --- ?php $str = '?xml version=1.0 encoding=WINDOWS-1250 ? config items item command=overview/ item command=deals/ item command=regions/ item command=estimations/ item command=reports/ item command=import/ /items /config '; $xml = simplexml_load_string($str); echo (empty($xml-items-item) ? EMPTY : full).\n; echo count($xml-items-item) .\n; Expected result: full 6 Actual result: -- EMPTY 6 -- Edit bug report at http://bugs.php.net/?id=43778edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43778r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43778r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43778r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43778r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43778r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43778r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43778r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43778r=needscript Try newer version:http://bugs.php.net/fix.php?id=43778r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43778r=support Expected behavior:http://bugs.php.net/fix.php?id=43778r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43778r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43778r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43778r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43778r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43778r=dst IIS Stability:http://bugs.php.net/fix.php?id=43778r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43778r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43778r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43778r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43778r=mysqlcfg
#42943 [NEW]: mssql.timeout can only be set in php.ini
From: jdolecek at netbsd dot org
Operating system: Windows
PHP version: 5.2.4
PHP Bug Type: MSSQL related
Bug description: mssql.timeout can only be set in php.ini
Description:
Value for mssql.timeout is only consulted on PHP engine startup. The value
is changeable in script in runtime, but setting it has no effect for newly
opened connections. So script gets default timeout set in php.ini, which is
60 seconds in default installation.
This is quite inconvenient in that you need different PHP.INI for web
server CGI PHP (where queries are short and you want to cache runaway
queries) and batch scripts (which execute long queries and need timeout
disabled).
The value used to be applied properly when set in a script in earlier
version, perhaps even as recent as 5.1 (but I don't really recall).
Reproduce code:
---
echo ini_get('mssql.timeout').\n;
ini_set('mssql.timeout', 1);
echo ini_get('mssql.timeout').\n;
$c = mssql_connect(host, user, pass)
$s = mssql_query($c, WAITFOR DELAY '00:00:05');
Expected result:
60
1
Warning: mssql_query(): Query failed in script.php on line 10
Actual result:
--
60
1
--
Edit bug report at http://bugs.php.net/?id=42943edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42943r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42943r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42943r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42943r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42943r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42943r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42943r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42943r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42943r=support
Expected behavior:http://bugs.php.net/fix.php?id=42943r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42943r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42943r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42943r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42943r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42943r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42943r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42943r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42943r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42943r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42943r=mysqlcfg
#42659 [NEW]: microtime() loses time in long-running scripts
From: jdolecek at NetBSD dot org
Operating system: Windows XP
PHP version: 5.2.4
PHP Bug Type: Date/time related
Bug description: microtime() loses time in long-running scripts
Description:
When PHP script runs for long time, the value returned by microtime()
gradually drifts away from time(). The exact value depends on system, but
we've seen 5 hour difference to current time for script running about a
week, with drift about 1 minute per 5 minutes run (system running under
VMware). The script is daemon-like process, i.e. it's blocked in select()
most of time, and only occassionally wakes up to process request.
Looking at win32/time.c, I spot one problematic spot in that the code
might not notice counter wrap-off if timer happens to be a higher value
after wrap-around then the last time the function was called. However, that
shouldn't be normally problem, since the counter wraps-around very
infrequently.
Reproduce code:
---
?php
ini_set('date.timezone', 'CET');
putenv(TZ=CET);
while(true) {
$sec = microtime(true);
echo msec: . sprintf([%s.%04d],
date(Y-m-d H:i:s, floor($sec)),
(float) ($sec - floor($sec)) *
1).\n;
echo sec : .date('[Y-m-d H:i:s]').\n;
sleep(300);
}
C program which demostrates how the two times diverge (cutpaste from
win32/time.c, so please forgive whitespace/style):
#include windows.h
#include winbase.h
#include time.h
#include winsock2.h
int getfilesystemtime(struct timeval *time_Info)
{
FILETIME ft;
__int64 ff;
LARGE_INTEGER li;
GetSystemTimeAsFileTime(ft); /* 100 ns blocks since 01-Jan-1641 */
/* resolution seems to be 0.01 sec */
li.u.LowPart = ft.dwLowDateTime;
li.u.HighPart = ft.dwHighDateTime;
ff = li.QuadPart;
time_Info-tv_sec =
(int)(ff/(__int64)1000-(__int64)11644473600ULL);
time_Info-tv_usec = (int)(ff % 1000)/10;
return 0;
}
#define PW32G(x)(x)
int
main()
{
LARGE_INTEGER li;
__int64 freq, timer;
double dt;
struct timeval tv, *time_Info = tv, starttime, tv2;
QueryPerformanceFrequency(li);
freq = li.QuadPart;
getfilesystemtime(starttime);
QueryPerformanceCounter(li);
timer = li.QuadPart;
dt = (double)timer/PW32G(freq);
PW32G(starttime).tv_usec -=
(int)((dt-(int)dt)*100);
if (PW32G(starttime).tv_usec 0) {
PW32G(starttime).tv_usec += 100;
--PW32G(starttime).tv_sec;
}
PW32G(starttime).tv_sec -= (int)dt;
while(1) {
sleep(10);
QueryPerformanceCounter(li);
getfilesystemtime(tv2);
timer = li.QuadPart;
dt = (double)timer/PW32G(freq);
time_Info-tv_sec = PW32G(starttime).tv_sec +
(int)dt;
time_Info-tv_usec = PW32G(starttime).tv_usec +
(int)((dt-(int)dt)*100);
if (time_Info-tv_usec 100) {
time_Info-tv_usec -= 100;
++time_Info-tv_sec;
}
printf(%ld.%06ld\n,
tv2.tv_sec - time_Info-tv_sec,
tv2.tv_usec - time_Info-tv_usec);
}
}
Expected result:
the time on 'msec' line should be same as for 'sec' line. Since the second
date() call fetches time after the microtime() call, the 'sec' line may
print time 1 second after the 'msec' line occassionally, but the times
should match most of the time.
The C program should print ~constant time difference.
Actual result:
--
The longer the script runs, the bigger difference between the 'msec' and
'sec' time.
Example output (after about 12 hours):
msec: [2007-09-13 12:22:25.7074]
sec : [2007-09-13 12:22:26]
msec: [2007-09-13 12:27:25.6848]
sec : [2007-09-13 12:27:26]
msec: [2007-09-13 12:32:25.6624]
sec : [2007-09-13 12:32:26]
It _appears_ microtime() loses about 0.02 seconds on each 5 minute
measurement on this machine, but this may be just local value and the exact
value could differ on different hardware.
C program output (from start):
0.002466
0.002998
0.003723
It appears performance counter based time loses about 0.0006 sec on each
10 second measurement compared to GetSystemTimeAsFileTime(). This matches
the difference observed in PHP script.
--
Edit bug report at http://bugs.php.net/?id=42659edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42659r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42659r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42659r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42659r
#42627 [NEW]: bz2 extension fails to build with -fno-common
From: jdolecek at netbsd dot org Operating system: Mac OS X PHP version: 5.2.4 PHP Bug Type: Compile Failure Bug description: bz2 extension fails to build with -fno-common Description: bz2 extension header causes php_bz2_filter_factory symbol to be a common symbol, rather then extern variable, due to lacking 'extern' modifier. When compiling on Mac OS X, which uses -fno-common by default, this causes build failure. The header should define it just as extern, since the symbol is properly declared in bz2_filter.c. Fix: --- ext/bz2/php_bz2.h.orig 2007-09-02 20:11:08.0 +0200 +++ ext/bz2/php_bz2.h @@ -51,7 +51,7 @@ PHP_BZ2_API php_stream *_php_stream_bz2o #define php_stream_bz2open_from_BZFILE(bz, mode, innerstream) _php_stream_bz2open_from_BZFILE((bz), (mode), (innerstream) STREAMS_CC TSRMLS_CC) #define php_stream_bz2open(wrapper, path, mode, options, opened_path) _php_stream_bz2open((wrapper), (path), (mode), (options), (opened_path), NULL STREAMS_CC TSRMLS_CC) -php_stream_filter_factory php_bz2_filter_factory; +extern php_stream_filter_factory php_bz2_filter_factory; extern php_stream_ops php_stream_bz2io_ops; #define PHP_STREAM_IS_BZIP2php_stream_bz2io_ops -- Edit bug report at http://bugs.php.net/?id=42627edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42627r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42627r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42627r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42627r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42627r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42627r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42627r=needscript Try newer version:http://bugs.php.net/fix.php?id=42627r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42627r=support Expected behavior:http://bugs.php.net/fix.php?id=42627r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42627r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42627r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42627r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42627r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42627r=dst IIS Stability:http://bugs.php.net/fix.php?id=42627r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42627r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42627r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42627r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42627r=mysqlcfg
#42629 [NEW]: Dynamically loaded PHP extensions need symbols exported
From: jdolecek at NetBSD dot org Operating system: Mac OS X 10.4.10 PHP version: 5.2.4 PHP Bug Type: Dynamic loading Bug description: Dynamically loaded PHP extensions need symbols exported Description: Some PHP extensions expect to have symbols from other PHP extensions available. This is the case for PDO drivers (which use symbols from PDO extension) and XSL (which uses symbols from DOM extension). Extensions are loaded with dlopen(..., RTLD_GLOBAL) on platforms with dlopen() (i.e. most unices). On Mac OS X, NSLinkModule() is used instead of dlopen(), but with 'private' option, which hides symbols of dynamically loaded extensions from other dynamically loaded code. Due to this symbol hiding, PDO and DOM needed to be compiled into base PHP binary, otherwise the dependant extension couldn't be dynamically loaded since expected symbols are not found. PDO configure script even intentionally silently disables compilation of dynamically loaded PDO module on MacOSX/Darwin because of this. Following patch makes it possible to load also PDO and DOM dynamically on Mac OS X and thus PHP extensions work all the same way as on other UNIX systems: --- Zend/zend_extensions.c.orig 2007-09-11 22:00:50.0 +0200 +++ Zend/zend_extensions.c @@ -243,7 +243,7 @@ void *zend_mh_bundle_load(char* bundle_p return NULL; } - bundle_handle = NSLinkModule(bundle_image, bundle_path, NSLINKMODULE_OPTION_PRIVATE); + bundle_handle = NSLinkModule(bundle_image, bundle_path, NSLINKMODULE_OPTION_NONE); NSDestroyObjectFileImage(bundle_image); /* call the init function of the bundle */ Reproduce code: --- Compile PDO (after fix to configure script) as dynamic extensions, as well as pdo_mysq, and add into php.ini lines: extension=pdo.so extension=pdo_mysql.so then run: php -m | grep -i pdo Expected result: PDO pdo_mysql Actual result: -- dyld: lazy symbol binding failed: Symbol not found: _php_pdo_declare_long_constant Referenced from: /Users/Shared/pkg/lib/php/20040412/pdo_mysql.so Expected in: flat namespace dyld: Symbol not found: _php_pdo_declare_long_constant Referenced from: /Users/Shared/pkg/lib/php/20040412/pdo_mysql.so Expected in: flat namespace Trace/BPT trap -- Edit bug report at http://bugs.php.net/?id=42629edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42629r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42629r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42629r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42629r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42629r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42629r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42629r=needscript Try newer version:http://bugs.php.net/fix.php?id=42629r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42629r=support Expected behavior:http://bugs.php.net/fix.php?id=42629r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42629r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42629r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42629r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42629r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42629r=dst IIS Stability:http://bugs.php.net/fix.php?id=42629r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42629r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42629r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42629r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42629r=mysqlcfg
#42630 [NEW]: dlopen() should be preferred to NSLinkModule()
From: jdolecek at NetBSD dot org
Operating system: Mac OS X 10.4
PHP version: 5.2.4
PHP Bug Type: Dynamic loading
Bug description: dlopen() should be preferred to NSLinkModule()
Description:
PHP uses NSLinkModule()-based interface for loading dynamic extensions.
Since Mac OS X 10.4, dlopen() is now available as native function and
should be used in preference to older NSLinkModule()-based method, for
consistency with other UNIX platforms.
Fix - if dlopen() is available, use dlopen(), otherwise fallback to
NSLinkModule():
--- Zend/zend.h.orig2007-09-05 00:16:02.0 +0200
+++ Zend/zend.h
@@ -80,18 +80,7 @@
# include dlfcn.h
#endif
-#if HAVE_MACH_O_DYLD_H
-#include mach-o/dyld.h
-
-/* MH_BUNDLE loading functions for Mac OS X / Darwin */
-void *zend_mh_bundle_load (char* bundle_path);
-int zend_mh_bundle_unload (void *bundle_handle);
-void *zend_mh_bundle_symbol(void *bundle_handle, const char
*symbol_name);
-const char *zend_mh_bundle_error(void);
-
-#endif /* HAVE_MACH_O_DYLD_H */
-
-#if defined(HAVE_LIBDL) !defined(HAVE_MACH_O_DYLD_H)
!defined(ZEND_WIN32)
+#if defined(HAVE_LIBDL) !defined(ZEND_WIN32)
# ifndef RTLD_LAZY
# define RTLD_LAZY 1/* Solaris 1, FreeBSD's (2.1.7.1 and older) */
@@ -118,6 +107,14 @@ const char *zend_mh_bundle_error(void);
# define DL_HANDLE void *
# define ZEND_EXTENSIONS_SUPPORT 1
#elif defined(HAVE_MACH_O_DYLD_H)
+
+#include mach-o/dyld.h
+
+/* MH_BUNDLE loading functions for Mac OS X / Darwin */
+void *zend_mh_bundle_load (char* bundle_path);
+int zend_mh_bundle_unload (void *bundle_handle);
+void *zend_mh_bundle_symbol(void *bundle_handle, const char
*symbol_name);
+const char *zend_mh_bundle_error(void);
# define DL_LOAD(libname)
zend_mh_bundle_load(libname)
# define DL_UNLOAD zend_mh_bundle_unload
# define DL_FETCH_SYMBOL(h,s)
zend_mh_bundle_symbol(h,s)
--- Zend/zend_extensions.c.orig 2007-09-05 00:24:04.0 +0200
+++ Zend/zend_extensions.c
@@ -230,7 +230,7 @@ ZEND_API zend_extension *zend_get_extens
*
*/
-#if HAVE_MACH_O_DYLD_H
+#if defined(HAVE_MACH_O_DYLD_H) !defined(HAVE_LIBDL)
void *zend_mh_bundle_load(char* bundle_path)
{
@@ -284,7 +284,7 @@ const char *zend_mh_bundle_error(void)
return NULL;
}
-#endif /* HAVE_MACH_O_DYLD_H */
+#endif /* HAVE_MACH_O_DYLD_H !HAVE_LIBDL */
/*
* Local variables:
Reproduce code:
---
I've originally developed this patch as a fix to bug #42629 to make
extensions load with RTLD_GLOBAL. However, I found simplier fix to that
problem, so I'm filling this dlopen() change as a separate bug report.
--
Edit bug report at http://bugs.php.net/?id=42630edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42630r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42630r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42630r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42630r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42630r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42630r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42630r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42630r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42630r=support
Expected behavior:http://bugs.php.net/fix.php?id=42630r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42630r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42630r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42630r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42630r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42630r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42630r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42630r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42630r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42630r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42630r=mysqlcfg
#34832 [NoF-Opn]: sprintf not reentrant
ID: 34832 User updated by: jdolecek at NetBSD dot org -Reported By: dolecek at stringdata dot cz +Reported By: jdolecek at NetBSD dot org -Status: No Feedback +Status: Open Bug Type: Strings related Operating System: Windows 2000 PHP Version: 5CVS-2005-10-17 (snap) New Comment: (non content related, just editing submissing e-mail) Previous Comments: [2005-11-10 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-11-02 13:26:07] [EMAIL PROTECTED] Yes, and now please read the comment. I asked for short but complete script..and not some huge package. [2005-11-01 17:15:24] dolecek at stringdata dot cz Reproducing script already provided in previous feedback. [2005-11-01 11:43:44] [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 to avoid embedding huge scripts into the report. [2005-10-17 09:56:24] dolecek at stringdata dot cz Tested with php5.1-win32-200510170630 and php5.0-win32-200510170030. PHP 5.1 crashes Apache after several seconds of running the test. PHP 5.0.6-dev doesn't crash, but still exhibits the problem. Thus, the problem is not fixed in snapshot. 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/34832 -- Edit this bug report at http://bugs.php.net/?id=34832edit=1
#37726 [Com]: proc_open let fd opened in the child process
ID: 37726
Comment by: jdolecek at NetBSD dot org
Reported By: n dot escuder at intra-links dot com
Status: Open
Bug Type: Program Execution
Operating System: Linux
PHP Version: 5.1.4
New Comment:
This may be the same problem as Bug #34794, which includes the fix.
Previous Comments:
[2006-06-07 17:08:45] n dot escuder at intra-links dot com
Yes when we do a pcntl_fork or a fork in C the FD must stay open but
here it's a complety new program that is started.
Proc_open use fork for starting the new process but don't cleanup open
descriptor after the fork.
[2006-06-07 15:16:24] [EMAIL PROTECTED]
IMHO, I think this is expected. When you fork under unix the open file
descriptors will be copied to the child process. proc_open just
enforces what the specified fd should look like.
[2006-06-07 10:56:45] n dot escuder at intra-links dot com
Description:
When executing a program with proc_open the child process that is
started by proc_open have all fd's that was opened in the master script
ex: file, database connection
The child process must don't have any fd open expect the fd specified
by $descriptorspec.
Reproduce code:
---
?
$fd = fopen(/tmp/test.log, w);
$descriptorspec = array(
0 = array(pipe, r),
1 = array(pipe, w),
2 = array(pipe, w)
);
$pipes = null;
$process = proc_open(ls /proc/self/fd -l, $descriptorspec, $pipes);
while ( ( $line = fgets($pipes[1]) ) ) {
echo $line;
}
proc_close( $process );
fclose($fd );
?
Expected result:
total 5
lr-x-- 1 root root 64 2006-06-07 12:44 0 - pipe:[22573]
l-wx-- 1 root root 64 2006-06-07 12:44 1 - pipe:[22574]
l-wx-- 1 root root 64 2006-06-07 12:44 2 - pipe:[22575]
lr-x-- 1 root root 64 2006-06-07 12:44 3 - /proc/19964/fd
Actual result:
--
total 5
lr-x-- 1 root root 64 2006-06-07 12:44 0 - pipe:[22573]
l-wx-- 1 root root 64 2006-06-07 12:44 1 - pipe:[22574]
l-wx-- 1 root root 64 2006-06-07 12:44 2 - pipe:[22575]
l-wx-- 1 root root 64 2006-06-07 12:44 3 - /tmp/test.log
lr-x-- 1 root root 64 2006-06-07 12:44 4 - /proc/19964/fd
--
Edit this bug report at http://bugs.php.net/?id=37726edit=1
#37611 [Fbk-Opn]: WDDX serializer encodes all non-ascii characters with char/
ID: 37611
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
-Status: Feedback
+Status: Open
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.5CVS
New Comment:
127 serializes/deserialized just fine on my system even without your
change, test script:
$str = wddx_deserialize(wddx_serialize_value(chr(127)));
echo ord($str[0]).\n;
wddx_deserialize() expects UTF-8 input and gives iso-8859-1 output.
There are ways around this, but this is the default way.
wddx_serialize_value() doesn't particularily care, it takes both UTF-8
and iso-8869-1.
So the right way to use the API is to UTF-8-encode text before
serializing, so that we'd get proper output after deserializing.
I'd also point out that both 1) and 2) points still hold, and both are
very painfull for non-english speakers. _Please_ back the change off.
Previous Comments:
[2006-05-31 22:22:04] [EMAIL PROTECTED]
Without the 127 bit on chr(128) for example becomes translated
to 0 causing irreversible data loss.
As far as chr(200) you don't need to utf8 encode it.
[2006-05-30 15:59:24] jdolecek at NetBSD dot org
Yes it is a bug.
1) it breaks current code using UTF-8 and expecting to get iso-8859-1
result from wddx_deserialize(), i.e.
$str = chr(200);
$str_u8 = utf8_encode($str);
$result = wddx_deserialize(wddx_Serialize_value($str_u8));
When run with PHP 5.1.4 or when the data has been serialized with
the older version, $result == $str.
New version has $result == $str_u8.
So, _all_ old serialized UTF-8 data (i.e. stored
in database) serializes to different encoding
then newly serialized data. This is major
backward incompatibility, and is problem for any
current applications using serializing of
UTF-8 input.
(Arguably serializing UTF-8 strings wasn't really
very usable before due to Bug #37571, but you get
the idea)
2) it explodes the size of packet, and it's not clear
what was the reason for the change. This is serious
problem when storing the result serialized data,
and totally unnecessary. XML is designed 8-bit
clean, so encoding high-bit characters this
way doesn't make sense.
Please explain why encoding characters = 127 is right. Please revert
this part of the patch.
If you want to fix wddx so that the encoding on input is same as
encoding on output it's fine, but it must be done in
backward-compatible way, such as adding some extra parameters to either
wddx_serialize_value() or wddx_deserialize().
[2006-05-28 15:13:29] [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
This is definitely not left over debug code, it is needed on
some system to ensure proper encoding of non-ascii characters.
[2006-05-27 09:58:51] jdolecek at NetBSD dot org
Seems the bug submit system turns non-ascii character to some entities,
the #268; should be character with ordinal value 200 (i.e. result of
chr(200)).
[2006-05-27 09:57:18] jdolecek at NetBSD dot org
Description:
The condition which determines if a character in string should be
encoded using the char code=XX/ construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p =
127) {
...encode using char code=XX/...
}
This means that _all_ non-ascii characters are encoded with the
construct, which explodes the result packet size if non-ascii
characters are used.
The || (int)*(unsigned char *)p = 127 parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
wddxPacket
version='1.0'header/datastring#268;/string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code=C8//string/data/wddxPacket
--
Edit this bug report at http://bugs.php.net/?id=37611edit=1
#36427 [Com]: proc_open() / proc_close() leak handles on Windows XP
ID: 36427
Comment by: jdolecek at NetBSD dot org
Reported By: pgj at ds-fr dot com
Status: Assigned
Bug Type: Program Execution
Operating System: windows XP SP2 Windows 2000 SP4
PHP Version: 5.1.2, 4.4.2
Assigned To: wez
New Comment:
Alternative (simplier) patch:
--- ext/standard/proc_open.c.orig 2006-06-01 18:09:51.0
+0200
+++ ext/standard/proc_open.c
@@ -670,7 +670,10 @@ PHP_FUNCTION(proc_open)
}
#ifdef PHP_WIN32
- descriptors[ndesc].childend =
(HANDLE)_get_osfhandle(fd);
+ /* dup the handle, and close the
original descriptor to
+* avoid leak */
+ descriptors[ndesc].childend =
dup_fd_as_handle(fd);
+ _close(fd);
#else
descriptors[ndesc].childend = fd;
#endif
Previous Comments:
[2006-05-29 12:05:44] pgj at ds-fr dot com
Your correction works on 4.4.2 on windows, no more bugs after 1
proc_open.
Thanks a lot
[2006-05-28 20:57:35] jdolecek at NetBSD dot org
It appears the problem is actually due to way Windows internally
emulate POSIX file descriptors, i.e. the process runs out of the
allowed count of the 'POSIX' file descriptors tracked in the C library,
not handles per se.
This is supported by Windows process viewer, which shows ~constant
number of handles for PHP process during the script run, particularily
same number of handles when it runs OK and when it starts giving the
error.
Note the problem only appears when using 'file' in descriptorspec,
using 'pipe' instead does workaround the problem.
I believe the problem can be fixed by consistently closing the file
descriptors rather then just the handles, i.e something along:
--- ext/standard/proc_open.c.orig 2006-05-28 21:51:09.0
+0200
+++ ext/standard/proc_open.c
@@ -462,6 +462,9 @@ static inline HANDLE dup_fd_as_handle(in
struct php_proc_open_descriptor_item {
int index;
/* desired fd number in child process */
php_file_descriptor_t parentend, childend; /* fds for
pipes in parent/child */
+#ifdef PHP_WIN32
+int childend_desc;
+#endif
int mode;
/* mode for proc_open code */
int mode_flags; /* mode
flags for opening fds */
};
@@ -671,6 +674,7 @@ PHP_FUNCTION(proc_open)
#ifdef PHP_WIN32
descriptors[ndesc].childend =
(HANDLE)_get_osfhandle(fd);
+ descriptors[ndesc].childend_desc = fd;
#else
descriptors[ndesc].childend = fd;
#endif
@@ -901,6 +905,11 @@ PHP_FUNCTION(proc_open)
char *mode_string=NULL;
php_stream *stream = NULL;
+#ifdef PHP_WIN32
+ if (descriptors[i].childend_desc)
+ _close(descriptors[i].childend_desc); /* closes
also the handle */
+#endif
+
close_descriptor(descriptors[i].childend);
switch (descriptors[i].mode ~DESC_PARENT_MODE_WRITE)
{
I cannot check this, since I haven't succeeded in setting up a build
environment on MS Windows for PHP sources.
[2006-02-21 18:11:58] pgj at ds-fr dot com
Same problem with php 5.1.2
[2006-02-19 01:38:59] [EMAIL PROTECTED]
While I can reproduce the problem, I couldn't spot the error at first
sight, because the code is very complex (and without valgrind even
worst..)
[2006-02-17 15:35:06] pgj at ds-fr dot com
Description:
I launch processes in a script and put stout in file
after more than 2000 processes and can't open a new one and have this
message.
It's similar with 30743 bit it uses 2 pipes for $fileDescriptors and in
this case it's a pipe and a file
Reproduce code:
---
?
set_time_limit(6000);
$i=0;
mkdir(test);
while(1)
{
$i++;
echo(-$i--\n);
invoke($i);
}
function invoke($i)
{
$commandLine = echo hello;
$fileDescriptors = array(
1 = array(pipe, r),
2 = array(file, test/$i.txt,w)
);
$pipes = array();
$processHandle = proc_open($commandLine,$fileDescriptors, $pipes);
if (is_resource($processHandle))
{
fclose($pipes[1]);
proc_close($processHandle);
}
}
Expected result:
Open a new one
Actual result:
--
bWarning/b: proc_open(test/2587.txt
#37619 [Fbk-Opn]: proc_open() closes stdin on fork() failure
ID: 37619
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Any UNIX-like, Netware
PHP Version: 5.1.4
New Comment:
I think bash uses ulimit -u rathern then ulimit -p for max user
processes (I've used ksh).
Previous Comments:
[2006-05-31 18:26:11] [EMAIL PROTECTED]
Could you please provide a more portable reproduce case?
[EMAIL PROTECTED]:~/build/php-5.2-debug$ bash /tmp/run.sh
/tmp/run.sh: line 1: ulimit: pipe size: cannot modify limit: Invalid
argument
sh: line 0: echo: write error: Bad file descriptor
test
[2006-05-28 20:30:32] jdolecek at NetBSD dot org
Description:
The block spawning the child process for both Netware and UNIX-like OS
contains this block in failure case:
if (child 0) {
/* failed to fork() */
/* clean up all the descriptors */
for (i = 0; i ndesc; i++) {
close(descriptors[i].childend);
close(descriptors[i].parentend);
}
...
}
parentend is filled only for pipes, for 'file'
handles it's not filled, and left '0' as initialized
by memset() in proc_open.c line 537.
So, if proc_open() was called with descriptorspec
using 'file' and the fork() call fails, this results
in closing descriptor 0.
Quick fix is to only close parentend if it's non-zero, such as:
--- ext/standard/proc_open.c.orig 2006-05-28 21:51:09.0
+0200
+++ ext/standard/proc_open.c
@@ -796,7 +796,8 @@ PHP_FUNCTION(proc_open)
/* clean up all the descriptors */
for (i = 0; i ndesc; i++) {
close(descriptors[i].childend);
- close(descriptors[i].parentend);
+ if (descriptors[i].parentend)
+ close(descriptors[i].parentend);
}
php_error_docref(NULL TSRMLS_CC, E_WARNING, procve
failed - %s, strerror(errno));
goto exit_fail;
@@ -863,7 +864,8 @@ PHP_FUNCTION(proc_open)
/* clean up all the descriptors */
for (i = 0; i ndesc; i++) {
close(descriptors[i].childend);
- close(descriptors[i].parentend);
+ if (descriptors[i].parentend)
+ close(descriptors[i].parentend);
}
php_error_docref(NULL TSRMLS_CC, E_WARNING, fork
failed - %s, strerror(errno));
Reproduce code:
---
It's necessary to setup process limit via ulimit so that running the
php script gets last allowed slot:
echo test tst
ulimit -p `pgrep -u \`id -u\` | wc -l`
php script.php tst
script.php:
?php
$p = proc_open(echo hello, array(0 = array('file', '/dev/null',
'r'), 1 =
array('pipe', 'r')), $pipes1);
echo file_get_contents(php://stdin).\n;
Expected result:
PHP Warning: proc_open(): fork failed - Resource temporarily
unavailable in /usr/home/dolecek/tmp/proc3.php on line 4
test
Actual result:
--
PHP Warning: proc_open(): fork failed - Resource temporarily
unavailable in /usr/home/dolecek/tmp/proc3.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=37619edit=1
#37611 [Bgs-Opn]: WDDX serializer encodes all non-ascii characters with char/
ID: 37611
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
-Status: Bogus
+Status: Open
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.5CVS
New Comment:
Yes it is a bug.
1) it breaks current code using UTF-8 and expecting to get iso-8859-1
result from wddx_deserialize(), i.e.
$str = chr(200);
$str_u8 = utf8_encode($str);
$result = wddx_deserialize(wddx_Serialize_value($str_u8));
When run with PHP 5.1.4 or when the data has been serialized with
the older version, $result == $str.
New version has $result == $str_u8.
So, _all_ old serialized UTF-8 data (i.e. stored
in database) serializes to different encoding
then newly serialized data. This is major
backward incompatibility, and is problem for any
current applications using serializing of
UTF-8 input.
(Arguably serializing UTF-8 strings wasn't really
very usable before due to Bug #37571, but you get
the idea)
2) it explodes the size of packet, and it's not clear
what was the reason for the change. This is serious
problem when storing the result serialized data,
and totally unnecessary. XML is designed 8-bit
clean, so encoding high-bit characters this
way doesn't make sense.
Please explain why encoding characters = 127 is right. Please revert
this part of the patch.
If you want to fix wddx so that the encoding on input is same as
encoding on output it's fine, but it must be done in
backward-compatible way, such as adding some extra parameters to either
wddx_serialize_value() or wddx_deserialize().
Previous Comments:
[2006-05-28 15:13:29] [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
This is definitely not left over debug code, it is needed on
some system to ensure proper encoding of non-ascii characters.
[2006-05-27 09:58:51] jdolecek at NetBSD dot org
Seems the bug submit system turns non-ascii character to some entities,
the #268; should be character with ordinal value 200 (i.e. result of
chr(200)).
[2006-05-27 09:57:18] jdolecek at NetBSD dot org
Description:
The condition which determines if a character in string should be
encoded using the char code=XX/ construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p =
127) {
...encode using char code=XX/...
}
This means that _all_ non-ascii characters are encoded with the
construct, which explodes the result packet size if non-ascii
characters are used.
The || (int)*(unsigned char *)p = 127 parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
wddxPacket
version='1.0'header/datastring#268;/string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code=C8//string/data/wddxPacket
--
Edit this bug report at http://bugs.php.net/?id=37611edit=1
#34794 [Com]: proc_close() hangs when used with two processes
ID: 34794
Comment by: jdolecek at NetBSD dot org
Reported By: e-t172 at e-t172 dot net
Status: Assigned
Bug Type: Program Execution
Operating System: Linux
PHP Version: 5CVS-2005-10-09 (snap)
Assigned To: wez
New Comment:
This is actually not a bug, or just documentation bug.
proc_close() blocks if the child has not terminated yet.
You must use proc_terminate() instead of proc_close() if you can't
guarantee the child has already exited, or use proc_get_status() to
check if the child has already exited if you want to avoid blocking.
Previous Comments:
[2006-04-29 02:42:16] Dallas at ekkySoftware dot com
I have a similar problem, it seems at I can't concurrently call the
same page with proc_open until the first proc_open returns. It looks
like proc_open is running through a critical section even though it is
opening separate processes.
From experience it is like php is using the same pipes for each
proc_open and can't continue to the next proc_open until the original
as ended. I would normally use temporary files instead of pipes – but
this makes life difficult.
Dallas
http://www.ekkySoftware.com/
[2006-04-26 14:50:23] radu dot rendec at ines dot ro
Same problem with 5.1.3RC4-dev (latest CVS snapshot at the moment) on
Linux/i386.
I independently reproduced the bug with the following piece of code:
error_reporting(E_ALL);
$spec = array(
0 = array(pipe, r),
1 = array(pipe, w),
2 = array(pipe, w)
);
$p1 = proc_open(/bin/cat, $spec, $fd1);
$p2 = proc_open(/bin/cat, $spec, $fd2);
fclose($fd1[0]);
fclose($fd1[1]);
fclose($fd1[2]);
echo closing p1... ; flush();
proc_close($p1);
echo success\n; flush();
This code hangs in proc_close(). This doesn't happen if the second
proc_open() is commented.
Although the parent process seems to correctly close all pipes, the
child process still remains blocked in read(0,...).
[2005-11-01 11:54:27] [EMAIL PROTECTED]
Assigned to the author of this stuff.
[2005-10-09 20:12:09] e-t172 at e-t172 dot net
Same problem with the last CVS Snapshot.
[2005-10-09 18:23:40] e-t172 at e-t172 dot net
Description:
(i am french, sorry for my bad english)
1. Open two processes with proc_open()
2. Try to close them : it works only if you close the second one first,
otherwise it hangs
Reproduce code:
---
?php
echo('Opening process 1'.\n);
$process1 = proc_open('cat', array(0 = array('pipe', 'r'), 1 =
array('pipe', 'r')), $pipes1);
echo('Opening process 2'.\n);
$process2 = proc_open('cat', array(0 = array('pipe', 'r'), 1 =
array('pipe', 'r')), $pipes2);
// WORKS :
//echo('Closing process 2'.\n);
//fclose($pipes2[0]); fclose($pipes2[1]); proc_close($process2);
//echo('Closing process 1'.\n);
//fclose($pipes1[0]); fclose($pipes1[1]); proc_close($process1);
// DOESN'T WORK :
echo('Closing process 1'.\n);
fclose($pipes1[0]); fclose($pipes1[1]); proc_close($process1);
echo('Closing process 2'.\n);
fclose($pipes2[0]); fclose($pipes2[1]); proc_close($process2);
?
Expected result:
$ php -f test.php
Opening process 1
Opening process 2
Closing process 1
Closing process 2
$
Actual result:
--
$ php -f test.php
Opening process 1
Opening process 2
Closing process 1
(HANGS)
--
Edit this bug report at http://bugs.php.net/?id=34794edit=1
#34794 [Com]: proc_close() hangs when used with two processes
ID: 34794
Comment by: jdolecek at NetBSD dot org
Reported By: e-t172 at e-t172 dot net
Status: Assigned
Bug Type: Program Execution
Operating System: Linux
PHP Version: 5CVS-2005-10-09 (snap)
Assigned To: wez
New Comment:
Actually yes, there is a severe pipe setup problem.
The problem is that the second spawned process inherits the descriptor
of parent end of pipe to the first spawned process, created when
setting up the process1 pipes. Since PHP doesn't set the close-on-exec
flag, the descriptor stays open in process2.
So, when the parent-end of pipes1[0] is closed in master script, the
descriptor is still open by process2, thus the pipe write end is not
closed yet and thus cat in process1 doesn't end.
Note this is also potential security problem, since the second process
is able to send data to the first.
Fix:
--- ext/standard/proc_open.c.orig 2006-05-28 19:10:35.0
+0200
+++ ext/standard/proc_open.c
@@ -929,6 +929,16 @@ PHP_FUNCTION(proc_open)
descriptors[i].mode_flags), mode_string,
NULL);
#else
stream =
php_stream_fopen_from_fd(descriptors[i].parentend, mode_string, NULL);
+
+#if defined(F_SETFD) defined(FD_CLOEXEC)
+ /*
+* Mark the descriptor close-on-exec, so that it
+* it won't be inherited by potential other children.
+* This avoids first child deadlock on proc_close().
+*/
+ fcntl(descriptors[i].parentend, F_SETFD, FD_CLOEXEC);
+#endif
+
#endif
if (stream) {
zval *retfp;
Previous Comments:
[2006-05-28 17:32:37] jdolecek at NetBSD dot org
This is actually not a bug, or just documentation bug.
proc_close() blocks if the child has not terminated yet.
You must use proc_terminate() instead of proc_close() if you can't
guarantee the child has already exited, or use proc_get_status() to
check if the child has already exited if you want to avoid blocking.
[2006-04-29 02:42:16] Dallas at ekkySoftware dot com
I have a similar problem, it seems at I can't concurrently call the
same page with proc_open until the first proc_open returns. It looks
like proc_open is running through a critical section even though it is
opening separate processes.
From experience it is like php is using the same pipes for each
proc_open and can't continue to the next proc_open until the original
as ended. I would normally use temporary files instead of pipes – but
this makes life difficult.
Dallas
http://www.ekkySoftware.com/
[2006-04-26 14:50:23] radu dot rendec at ines dot ro
Same problem with 5.1.3RC4-dev (latest CVS snapshot at the moment) on
Linux/i386.
I independently reproduced the bug with the following piece of code:
error_reporting(E_ALL);
$spec = array(
0 = array(pipe, r),
1 = array(pipe, w),
2 = array(pipe, w)
);
$p1 = proc_open(/bin/cat, $spec, $fd1);
$p2 = proc_open(/bin/cat, $spec, $fd2);
fclose($fd1[0]);
fclose($fd1[1]);
fclose($fd1[2]);
echo closing p1... ; flush();
proc_close($p1);
echo success\n; flush();
This code hangs in proc_close(). This doesn't happen if the second
proc_open() is commented.
Although the parent process seems to correctly close all pipes, the
child process still remains blocked in read(0,...).
[2005-11-01 11:54:27] [EMAIL PROTECTED]
Assigned to the author of this stuff.
[2005-10-09 20:12:09] e-t172 at e-t172 dot net
Same problem with the last CVS Snapshot.
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/34794
--
Edit this bug report at http://bugs.php.net/?id=34794edit=1
#37619 [NEW]: proc_open() closes stdin on fork() failure
From: jdolecek at NetBSD dot org
Operating system: Any UNIX-like, Netware
PHP version: 5.1.4
PHP Bug Type: Unknown/Other Function
Bug description: proc_open() closes stdin on fork() failure
Description:
The block spawning the child process for both Netware and UNIX-like OS
contains this block in failure case:
if (child 0) {
/* failed to fork() */
/* clean up all the descriptors */
for (i = 0; i ndesc; i++) {
close(descriptors[i].childend);
close(descriptors[i].parentend);
}
...
}
parentend is filled only for pipes, for 'file'
handles it's not filled, and left '0' as initialized
by memset() in proc_open.c line 537.
So, if proc_open() was called with descriptorspec
using 'file' and the fork() call fails, this results
in closing descriptor 0.
Quick fix is to only close parentend if it's non-zero, such as:
--- ext/standard/proc_open.c.orig 2006-05-28 21:51:09.0
+0200
+++ ext/standard/proc_open.c
@@ -796,7 +796,8 @@ PHP_FUNCTION(proc_open)
/* clean up all the descriptors */
for (i = 0; i ndesc; i++) {
close(descriptors[i].childend);
- close(descriptors[i].parentend);
+ if (descriptors[i].parentend)
+ close(descriptors[i].parentend);
}
php_error_docref(NULL TSRMLS_CC, E_WARNING, procve failed
- %s, strerror(errno));
goto exit_fail;
@@ -863,7 +864,8 @@ PHP_FUNCTION(proc_open)
/* clean up all the descriptors */
for (i = 0; i ndesc; i++) {
close(descriptors[i].childend);
- close(descriptors[i].parentend);
+ if (descriptors[i].parentend)
+ close(descriptors[i].parentend);
}
php_error_docref(NULL TSRMLS_CC, E_WARNING, fork failed -
%s, strerror(errno));
Reproduce code:
---
It's necessary to setup process limit via ulimit so that running the php
script gets last allowed slot:
echo test tst
ulimit -p `pgrep -u \`id -u\` | wc -l`
php script.php tst
script.php:
?php
$p = proc_open(echo hello, array(0 = array('file', '/dev/null', 'r'), 1
=
array('pipe', 'r')), $pipes1);
echo file_get_contents(php://stdin).\n;
Expected result:
PHP Warning: proc_open(): fork failed - Resource temporarily unavailable
in /usr/home/dolecek/tmp/proc3.php on line 4
test
Actual result:
--
PHP Warning: proc_open(): fork failed - Resource temporarily unavailable
in /usr/home/dolecek/tmp/proc3.php on line 4
--
Edit bug report at http://bugs.php.net/?id=37619edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37619r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37619r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37619r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37619r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37619r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37619r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37619r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37619r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37619r=support
Expected behavior:http://bugs.php.net/fix.php?id=37619r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37619r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37619r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37619r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37619r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37619r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37619r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37619r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37619r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37619r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37619r=mysqlcfg
#36427 [Com]: proc_open() / proc_close() leak handles on Windows XP
ID: 36427
Comment by: jdolecek at NetBSD dot org
Reported By: pgj at ds-fr dot com
Status: Verified
Bug Type: Program Execution
Operating System: windows XP SP2 Windows 2000 SP4
PHP Version: 5.1.2, 4.4.2
New Comment:
It appears the problem is actually due to way Windows internally
emulate POSIX file descriptors, i.e. the process runs out of the
allowed count of the 'POSIX' file descriptors tracked in the C library,
not handles per se.
This is supported by Windows process viewer, which shows ~constant
number of handles for PHP process during the script run, particularily
same number of handles when it runs OK and when it starts giving the
error.
Note the problem only appears when using 'file' in descriptorspec,
using 'pipe' instead does workaround the problem.
I believe the problem can be fixed by consistently closing the file
descriptors rather then just the handles, i.e something along:
--- ext/standard/proc_open.c.orig 2006-05-28 21:51:09.0
+0200
+++ ext/standard/proc_open.c
@@ -462,6 +462,9 @@ static inline HANDLE dup_fd_as_handle(in
struct php_proc_open_descriptor_item {
int index;
/* desired fd number in child process */
php_file_descriptor_t parentend, childend; /* fds for
pipes in parent/child */
+#ifdef PHP_WIN32
+int childend_desc;
+#endif
int mode;
/* mode for proc_open code */
int mode_flags; /* mode
flags for opening fds */
};
@@ -671,6 +674,7 @@ PHP_FUNCTION(proc_open)
#ifdef PHP_WIN32
descriptors[ndesc].childend =
(HANDLE)_get_osfhandle(fd);
+ descriptors[ndesc].childend_desc = fd;
#else
descriptors[ndesc].childend = fd;
#endif
@@ -901,6 +905,11 @@ PHP_FUNCTION(proc_open)
char *mode_string=NULL;
php_stream *stream = NULL;
+#ifdef PHP_WIN32
+ if (descriptors[i].childend_desc)
+ _close(descriptors[i].childend_desc); /* closes
also the handle */
+#endif
+
close_descriptor(descriptors[i].childend);
switch (descriptors[i].mode ~DESC_PARENT_MODE_WRITE)
{
I cannot check this, since I haven't succeeded in setting up a build
environment on MS Windows for PHP sources.
Previous Comments:
[2006-02-21 18:11:58] pgj at ds-fr dot com
Same problem with php 5.1.2
[2006-02-19 01:38:59] [EMAIL PROTECTED]
While I can reproduce the problem, I couldn't spot the error at first
sight, because the code is very complex (and without valgrind even
worst..)
[2006-02-17 15:35:06] pgj at ds-fr dot com
Description:
I launch processes in a script and put stout in file
after more than 2000 processes and can't open a new one and have this
message.
It's similar with 30743 bit it uses 2 pipes for $fileDescriptors and in
this case it's a pipe and a file
Reproduce code:
---
?
set_time_limit(6000);
$i=0;
mkdir(test);
while(1)
{
$i++;
echo(-$i--\n);
invoke($i);
}
function invoke($i)
{
$commandLine = echo hello;
$fileDescriptors = array(
1 = array(pipe, r),
2 = array(file, test/$i.txt,w)
);
$pipes = array();
$processHandle = proc_open($commandLine,$fileDescriptors, $pipes);
if (is_resource($processHandle))
{
fclose($pipes[1]);
proc_close($processHandle);
}
}
Expected result:
Open a new one
Actual result:
--
bWarning/b: proc_open(test/2587.txt): failed to open stream: Too
many open files in bE:\cotcot\leak.php/b on line b24/bbr /
--
Edit this bug report at http://bugs.php.net/?id=36427edit=1
#37610 [NEW]: win32build has incorrect expat, PHP non-buildable
From: jdolecek at NetBSD dot org Operating system: Windows PHP version: 5.1.4 PHP Bug Type: Compile Failure Bug description: win32build has incorrect expat, PHP non-buildable Description: http://www.php.net/extra/win32build.zip has incorrect version of expat bundled - with version bundled there, extensions xml and wddx don't build, missing some symbols and e.g. structure XML_Memory_Handling_Suite. Reproduce code: --- Try to follow README.WIN32-BUILD-SYSTEM and setup build environment on MS Windows. Expected result: Compiles fine. Actual result: -- Build ends with compile failure. -- Edit bug report at http://bugs.php.net/?id=37610edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37610r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37610r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37610r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37610r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37610r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37610r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37610r=needscript Try newer version:http://bugs.php.net/fix.php?id=37610r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37610r=support Expected behavior:http://bugs.php.net/fix.php?id=37610r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37610r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37610r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37610r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37610r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37610r=dst IIS Stability:http://bugs.php.net/fix.php?id=37610r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37610r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37610r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37610r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37610r=mysqlcfg
#37611 [NEW]: WDDX serializer encodes all non-ascii characters with char/
From: jdolecek at NetBSD dot org
Operating system: Any
PHP version: 5.1.5CVS
PHP Bug Type: WDDX related
Bug description: WDDX serializer encodes all non-ascii characters with char/
Description:
The condition which determines if a character in string should be encoded
using the char code=XX/ construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p = 127)
{
...encode using char code=XX/...
}
This means that _all_ non-ascii characters are encoded with the construct,
which explodes the result packet size if non-ascii characters are used.
The || (int)*(unsigned char *)p = 127 parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
wddxPacket
version='1.0'header/datastring#268;/string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code=C8//string/data/wddxPacket
--
Edit bug report at http://bugs.php.net/?id=37611edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37611r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37611r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37611r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37611r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37611r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37611r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37611r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37611r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37611r=support
Expected behavior:http://bugs.php.net/fix.php?id=37611r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37611r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37611r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37611r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37611r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37611r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37611r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37611r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37611r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37611r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37611r=mysqlcfg
#37611 [Opn]: WDDX serializer encodes all non-ascii characters with char/
ID: 37611
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
Status: Open
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.5CVS
New Comment:
Seems the bug submit system turns non-ascii character to some entities,
the #268; should be character with ordinal value 200 (i.e. result of
chr(200)).
Previous Comments:
[2006-05-27 09:57:18] jdolecek at NetBSD dot org
Description:
The condition which determines if a character in string should be
encoded using the char code=XX/ construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p =
127) {
...encode using char code=XX/...
}
This means that _all_ non-ascii characters are encoded with the
construct, which explodes the result packet size if non-ascii
characters are used.
The || (int)*(unsigned char *)p = 127 parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
wddxPacket
version='1.0'header/datastring#268;/string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code=C8//string/data/wddxPacket
--
Edit this bug report at http://bugs.php.net/?id=37611edit=1
#37571 [Bgs-Opn]: WDDX cannot deserialize serialized UTF-8 encoded non-ASCII text
ID: 37571
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
-Status: Bogus
+Status: Open
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.4
New Comment:
You probably don't understand the problem. I'm not talking about
problem encoding iso-8859-1 text, but problem encoding text in
_UTF-8_.
UTF-8 stream legally contains characters in 128-160
range. Hopefully we agree here.
WDDX uses iscntrl() to determine if it should record the character to
char code=XX/ form. So it takes each character of multicharacter
UTF-8 sequence and if _the single character of the sequence_ is
determined to be control character according to current locale, it
turns the component of multibyte sequence into char code=XX/
construct.
So, it turns perfectly valid UTF-8 stream into invalid text stream,
where some UTF-8 sequences are valid and some not.
The problem is that it uses iscntrl(), while it arguably should enforce
valid UTF-8 input and use something along iswcntrl(). But this would
change the interface and likely break existing code using WDDX which
depend on using iso-8859-1 text as input to serializer.
Using iscntrl() + isascii() definitely solves the problem in the least
obtrusive way AFAICS.
Previous Comments:
[2006-05-24 06:46:22] [EMAIL PROTECTED]
Latin 1 doesn't define those characters in the 128-160 range... so it's
perfectly correct not to encode them to UTF-8. You simply need to make
sure you have valid text in the first place.
[2006-05-23 22:50:20] jdolecek at NetBSD dot org
Description:
WDDX cannot be used to encode certain UTF8-encoded iso-8859-1 text.
Particularily those iso-8859-1 characters, which after conversion to
UTF-8 generate sequence of characters with value in 128-160 range,
which are recognized as control characters. Control characters are
turned into char code=XX/ sequence by WDDX.
wddx_deserialize() expects UTF-8 encoded string, and implicitly
converts the text back to iso-8859-1 before deserializing the
structure. This is done _before_
the char code=XX/ is replaced by the character. The is thus
recognized as part of the UTF-8 sequence, two-byte sequence is recoded
to single-byte character and the result contains invalid XML (fragment
'char code=XX/'). Deserialization thus fails silently.
I.e.:
1. iso-8859-1 is Z (ord(Z) 128)
2. UTF-8 string is XY
3. WDDX serializes that as Xchar code=ord(Y)/
4. deserializer converts UTF-8 input to iso-8859-1 before
starting deserialization, result is Bchar code=ord(Y)/
5. deserializer detects invalid XML and aborts the decode,
returns empty string
Fix:
Only recode ASCII control characters to char code=XX / sequence:
--- wddx.c.orig 2006-05-24 00:39:34.0 +0200
+++ wddx.c
@@ -399,7 +399,8 @@ static void php_wddx_serialize_string(wd
break;
default:
- if (iscntrl((int)*(unsigned
char *)p)) {
+ if (iscntrl((int)*(unsigned
char *)p)
+isascii((int)*(unsigned
char *)p)) {
FLUSH_BUF();
sprintf(control_buf,
WDDX_CHAR, *p);
php_wddx_add_chunk(packet, control_buf);
Note - this patch also makes problem of Bug #37569 go away, but that
patch is still useful to apply for code clarity.
This bug is probably same problem as Bug #35241.
Reproduce code:
---
On UNIX with iso-8859-1 locale or Windows with Windows-1250 locale:
var_dump(
wddx_deserialize(wddx_serialize_value(utf8_encode(chr(200
);
Expected result:
string(1) #268;
Actual result:
--
string(0)
--
Edit this bug report at http://bugs.php.net/?id=37571edit=1
#37569 [NEW]: WDDX bad character encoding
From: jdolecek at NetBSD dot org
Operating system: Any
PHP version: 5.1.4
PHP Bug Type: WDDX related
Bug description: WDDX bad character encoding
Description:
WDDX serializes control charactes using a char code=XX/ construct,
However, the code contains sign extension bug, and on platforms with
signed char the result XX contains incorrect (sign-extended) code.
This affects e.g. UTF8-encoded non-ASCII text, which can contain
characters in 128-160 range.
Fix:
--- wddx.c.orig 2006-05-23 23:58:54.0 +0200
+++ wddx.c
@@ -401,7 +401,7 @@ static void php_wddx_serialize_string(wd
default:
if (iscntrl((int)*(unsigned char
*)p)) {
FLUSH_BUF();
- sprintf(control_buf,
WDDX_CHAR, *p);
+ sprintf(control_buf,
WDDX_CHAR, (int)*(unsigned char *)p);
php_wddx_add_chunk(packet,
control_buf);
} else
buf[l++] = *p;
Reproduce code:
---
On UNIX with iso-8859-1 locale:
echo wddx_serialize_value(chr(1)).\n;
echo wddx_serialize_value(chr(128)).\n;
Expected result:
wddxPacket version='1.0'header/datastringchar
code='01'//string/data/wddxPacket
wddxPacket version='1.0'header/datastringchar
code='80'//string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code='01'//string/data/wddxPacket
wddxPacket version='1.0'header/datastringchar
code='FF80'//string/data/wddxPacket
--
Edit bug report at http://bugs.php.net/?id=37569edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37569r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37569r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37569r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37569r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37569r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37569r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37569r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37569r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37569r=support
Expected behavior:http://bugs.php.net/fix.php?id=37569r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37569r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37569r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37569r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37569r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37569r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37569r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37569r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37569r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37569r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37569r=mysqlcfg
#37571 [NEW]: WDDX cannot deserialize serialized UTF-8 encoded non-ASCII text
From: jdolecek at NetBSD dot org
Operating system: Any
PHP version: 5.1.4
PHP Bug Type: WDDX related
Bug description: WDDX cannot deserialize serialized UTF-8 encoded non-ASCII
text
Description:
WDDX cannot be used to encode certain UTF8-encoded iso-8859-1 text.
Particularily those iso-8859-1 characters, which after conversion to UTF-8
generate sequence of characters with value in 128-160 range, which are
recognized as control characters. Control characters are turned into char
code=XX/ sequence by WDDX.
wddx_deserialize() expects UTF-8 encoded string, and implicitly converts
the text back to iso-8859-1 before deserializing the structure. This is
done _before_
the char code=XX/ is replaced by the character. The is thus
recognized as part of the UTF-8 sequence, two-byte sequence is recoded to
single-byte character and the result contains invalid XML (fragment 'char
code=XX/'). Deserialization thus fails silently.
I.e.:
1. iso-8859-1 is Z (ord(Z) 128)
2. UTF-8 string is XY
3. WDDX serializes that as Xchar code=ord(Y)/
4. deserializer converts UTF-8 input to iso-8859-1 before
starting deserialization, result is Bchar code=ord(Y)/
5. deserializer detects invalid XML and aborts the decode,
returns empty string
Fix:
Only recode ASCII control characters to char code=XX / sequence:
--- wddx.c.orig 2006-05-24 00:39:34.0 +0200
+++ wddx.c
@@ -399,7 +399,8 @@ static void php_wddx_serialize_string(wd
break;
default:
- if (iscntrl((int)*(unsigned char
*)p)) {
+ if (iscntrl((int)*(unsigned char
*)p)
+isascii((int)*(unsigned
char *)p)) {
FLUSH_BUF();
sprintf(control_buf,
WDDX_CHAR, *p);
php_wddx_add_chunk(packet,
control_buf);
Note - this patch also makes problem of Bug #37569 go away, but that patch
is still useful to apply for code clarity.
This bug is probably same problem as Bug #35241.
Reproduce code:
---
On UNIX with iso-8859-1 locale or Windows with Windows-1250 locale:
var_dump(
wddx_deserialize(wddx_serialize_value(utf8_encode(chr(200
);
Expected result:
string(1) #268;
Actual result:
--
string(0)
--
Edit bug report at http://bugs.php.net/?id=37571edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37571r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37571r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37571r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37571r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37571r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37571r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37571r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37571r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37571r=support
Expected behavior:http://bugs.php.net/fix.php?id=37571r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37571r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37571r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37571r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37571r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37571r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37571r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37571r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37571r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37571r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37571r=mysqlcfg
#37348 [NEW]: pear installation might fail with open_basedir
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 5.1.4 PHP Bug Type: Safe Mode/open_basedir Bug description: pear installation might fail with open_basedir Description: pear/Makefile.frag from the PHP 5.1.4 source tree disables safe_mode, but doesn't disable open_basedir. If user has php.ini with open_basedir set, they would probably get an error when installing pear PHAR. Reproduce code: --- Code inspection only (not tested) -- Edit bug report at http://bugs.php.net/?id=37348edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37348r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37348r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37348r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37348r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37348r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37348r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37348r=needscript Try newer version:http://bugs.php.net/fix.php?id=37348r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37348r=support Expected behavior:http://bugs.php.net/fix.php?id=37348r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37348r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37348r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37348r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37348r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37348r=dst IIS Stability:http://bugs.php.net/fix.php?id=37348r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37348r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37348r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37348r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37348r=mysqlcfg
#37313 [NEW]: sigemptyset() used without including signal.h
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 5.1.3 PHP Bug Type: Compile Warning Bug description: sigemptyset() used without including signal.h Description: Compiling FastCGI PHP emits a warning about sigemptyset() used without correct header #include in sapi/cgi/fastcgi.c. Patch: --- sapi/cgi/fastcgi.c.orig +++ sapi/cgi/fastcgi.c @@ -69,7 +69,7 @@ # include netinet/in.h # include arpa/inet.h # include netdb.h -# include sys/signal.h +# include signal.h #ifndef INADDR_NONE #define INADDR_NONE ((unsigned long) -1) Reproduce code: --- ./configure --enable-fastcgi, make and wait Expected result: No warning Actual result: -- sapi/cgi/fastcgi.o(.text+0x9c): In function `fcgi_init': : warning: warning: reference to compatibility sigemptyset(); include signal.h for correct reference -- Edit bug report at http://bugs.php.net/?id=37313edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37313r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37313r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37313r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37313r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37313r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37313r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37313r=needscript Try newer version:http://bugs.php.net/fix.php?id=37313r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37313r=support Expected behavior:http://bugs.php.net/fix.php?id=37313r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37313r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37313r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37313r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37313r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37313r=dst IIS Stability:http://bugs.php.net/fix.php?id=37313r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37313r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37313r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37313r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37313r=mysqlcfg
#37162 [NEW]: WDDX module doesn't build non-bundled
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 5.1.2 PHP Bug Type: WDDX related Bug description: WDDX module doesn't build non-bundled Description: When WDDX module is compiled separately from main PHP build, the module contents are not actually compiled due to #ifdef HAVE_WDDX. Since config.h is not included,HAVE_WDDX is not defined in this case and empty .o file is produced. This problem also affects PHP 4.4.2. Fix is to include config.h on top: --- ext/wddx/wddx.c.orig2006-04-22 12:18:32.0 +0200 +++ ext/wddx/wddx.c @@ -20,2 +20,6 @@ +#ifdef HAVE_CONFIG_H +#include config.h +#endif + #include php.h Reproduce code: --- Build as separate module (i.e. not compiled into php) and load via extension=wddx.so Expected result: Module loads Actual result: -- php prints warning when loading the extension: PHP Warning: Unknown(): Invalid library (maybe not a PHP library) 'wddx.so' in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=37162edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37162r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37162r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37162r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37162r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37162r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37162r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37162r=needscript Try newer version:http://bugs.php.net/fix.php?id=37162r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37162r=support Expected behavior:http://bugs.php.net/fix.php?id=37162r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37162r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37162r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37162r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37162r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37162r=dst IIS Stability:http://bugs.php.net/fix.php?id=37162r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37162r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37162r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37162r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37162r=mysqlcfg
#37163 [NEW]: timelib_structs.h requires explicit compiler include path setting
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 5.1.2 PHP Bug Type: Compile Failure Bug description: timelib_structs.h requires explicit compiler include path setting Description: When php_date.h is used in a module, the build requires the include path of C compiler to be set to include ext/date/lib explicitely. This is due to php_date.h pulling lib/timelib.h (this is fine), then timelib.h including timelib_structs.h (this is fine too), but timelib_structs.h including timelib_config.h (this fails). If this is used in a separately built module (encountered with WDDX when build as an extension), this means the include path for the extension build must be setup to include php/include/ext/date/lib. Reproduce code: --- Build WDDX as separate extension (i.e. not part of PHP build itself). Expected result: Compiles fine Actual result: -- Compile fails with error couldn't find timelib_config.h. -- Edit bug report at http://bugs.php.net/?id=37163edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37163r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37163r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37163r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37163r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37163r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37163r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37163r=needscript Try newer version:http://bugs.php.net/fix.php?id=37163r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37163r=support Expected behavior:http://bugs.php.net/fix.php?id=37163r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37163r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37163r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37163r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37163r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37163r=dst IIS Stability:http://bugs.php.net/fix.php?id=37163r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37163r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37163r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37163r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37163r=mysqlcfg
#37163 [Opn]: timelib_structs.h requires explicit compiler include path setting
ID: 37163 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org Status: Open Bug Type: Compile Failure Operating System: NetBSD PHP Version: 5.1.2 New Comment: Fix: --- ext/date/lib/timelib_structs.h.orig 2006-04-22 12:51:57.0 +0200 +++ ext/date/lib/timelib_structs.h 2006-04-22 12:52:01.0 +0200 @@ -21,7 +21,7 @@ #ifndef __TIMELIB_STRUCTS_H__ #define __TIMELIB_STRUCTS_H__ -#include timelib_config.h +#include timelib_config.h #ifdef HAVE_SYS_TYPES_H #include sys/types.h Previous Comments: [2006-04-22 10:51:06] jdolecek at NetBSD dot org Description: When php_date.h is used in a module, the build requires the include path of C compiler to be set to include ext/date/lib explicitely. This is due to php_date.h pulling lib/timelib.h (this is fine), then timelib.h including timelib_structs.h (this is fine too), but timelib_structs.h including timelib_config.h (this fails). If this is used in a separately built module (encountered with WDDX when build as an extension), this means the include path for the extension build must be setup to include php/include/ext/date/lib. Reproduce code: --- Build WDDX as separate extension (i.e. not part of PHP build itself). Expected result: Compiles fine Actual result: -- Compile fails with error couldn't find timelib_config.h. -- Edit this bug report at http://bugs.php.net/?id=37163edit=1
#35544 [NEW]: pear should ignore safemode/open_basedir
From: jdolecek at netbsd dot org Operating system: NetBSD PHP version: 5.1.1 PHP Bug Type: Feature/Change Request Bug description: pear should ignore safemode/open_basedir Description: If user sets safemode or open_basedir restriction in their php.ini, they will no longer be able to use pear upgrade etc - the pear call will end with error. NetBSD pkgsrc patches pear.sh to use -n to ignore system php.ini, i.e to exec: exec $PHP -C -q $INCARG -d output_buffering=1 \ -n $INCDIR/pearcmd.php This works as long as pear doesn't need any non-builtin extensions or include path different to the one compiled into the executable. FWIW, we had no problem reports about this causing any problem since the change was introduced (2004/12/12), so this appears to work fine for all NetBSD pkgsrc users. Rather then using -n and ignoring system php.ini completely, it would be great if CLI PHP either ignored the open_basedir/safemode setting implicitely or had a commandline flag to do so (which then would be used in pear.sh/pear.bat). Reproduce code: --- Edit php.ini, set open_basedir to /nonexistent. Then run any pear upgrade from commandline: pear upgrade HTML_Common Expected result: downloading HTML_Common-1.2.2.tar ... Starting to download HTML_Common-1.2.2.tar (-1 bytes) done: 20,992 bytes upgrade ok: channel://pear.php.net/HTML_Common-1.2.2 Actual result: -- Warning: require_once(PEAR.php): failed to open stream: Operation not permitted in pearcmd.php on line 63 PHP Fatal error: require_once(): Failed opening required 'PEAR.php' (include_path='/usr/pkg/lib/php') in /usr/pkg/lib/php/pearcmd.php on line 63 -- Edit bug report at http://bugs.php.net/?id=35544edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35544r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35544r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35544r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35544r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35544r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35544r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35544r=needscript Try newer version:http://bugs.php.net/fix.php?id=35544r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35544r=support Expected behavior:http://bugs.php.net/fix.php?id=35544r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35544r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35544r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35544r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35544r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35544r=dst IIS Stability:http://bugs.php.net/fix.php?id=35544r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35544r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35544r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35544r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35544r=mysqlcfg
#30919 [NEW]: Bundled Net_Socket and Net_SMTP should be updated
From: jdolecek at NetBSD dot org Operating system: NetBSD 2.99.10 PHP version: 4.3.10RC1 PHP Bug Type: Sockets related Bug description: Bundled Net_Socket and Net_SMTP should be updated Description: Net_Socket 1.0.2 and Net_SMTP 1.2.6 contain some important bug fixes. Some pear packages (HTTP_Request, maybe others) even require Net_Socket 1.0.2. It would be nice if the bundled versions would be updated, AFAICS 4.3.10R1 still contains versions 1.0.1 and 1.2.3 respectively. Of course this doesn't affect PHP5, where the classes are not bundled. -- Edit bug report at http://bugs.php.net/?id=30919edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30919r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30919r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30919r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30919r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30919r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30919r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30919r=needscript Try newer version: http://bugs.php.net/fix.php?id=30919r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30919r=support Expected behavior: http://bugs.php.net/fix.php?id=30919r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30919r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30919r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30919r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30919r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30919r=dst IIS Stability: http://bugs.php.net/fix.php?id=30919r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30919r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30919r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30919r=mysqlcfg
#29133 [NEW]: MySQL extension config.m4 uses incorrect full path
From: jdolecek at NetBSD dot org Operating system: NetBSD PHP version: 4.3.8 PHP Bug Type: Compile Failure Bug description: MySQL extension config.m4 uses incorrect full path Description: ext/mysql/config.m4 includes: sinclude(ext/mysql/libmysql/acinclude.m4) sinclude(ext/mysql/libmysql/mysql.m4) sinclude(libmysql/acinclude.m4) sinclude(libmysql/mysql.m4) When building this extension separately and phpize is called in the directory ext/mysql/, the former two files don't exist and autoconf 1.8 aborts build. The NetBSD pkgsrc fix to this is: --- config.m4.orig Mon Jul 14 12:43:51 2003 +++ config.m4 Wed Mar 31 12:02:43 2004 @@ -3,7 +3,5 @@ dnl -sinclude(ext/mysql/libmysql/acinclude.m4) -sinclude(ext/mysql/libmysql/mysql.m4) sinclude(libmysql/acinclude.m4) sinclude(libmysql/mysql.m4) Reproduce code: --- Build mysql extension separately from main package using autoconf 1.8. Expected result: The phpize phase eventually fails with: aclocal-1.8: cannot open ext/mysql/libmysql/acinclude.m4: No such file or directory *** Error code 1 -- Edit bug report at http://bugs.php.net/?id=29133edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29133r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29133r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29133r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29133r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29133r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29133r=needscript Try newer version: http://bugs.php.net/fix.php?id=29133r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29133r=support Expected behavior: http://bugs.php.net/fix.php?id=29133r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29133r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29133r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29133r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29133r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29133r=dst IIS Stability: http://bugs.php.net/fix.php?id=29133r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29133r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29133r=float
#29133 [Bgs-Opn]: MySQL extension config.m4 uses incorrect full path
ID: 29133 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org -Status: Bogus +Status: Open Bug Type: Compile Failure Operating System: NetBSD PHP Version: 4.3.8 New Comment: Sorry - I made a mistake with the specified version. Autoconf 2.59 is used. Automake is version 1.8. Older automake (1.4) ignores the sinclude() if the specified file doesn't exist. Newer automake (1.8) exits with error in this case, however. So, this should be adressed sooner or later. Previous Comments: [2004-07-14 14:00:24] [EMAIL PROTECTED] autoconf 1.8 is not supported. Use the snapshots from http://snaps.php.net if you don't have the right tools to generate build stuff. [2004-07-14 08:29:51] jdolecek at NetBSD dot org Description: ext/mysql/config.m4 includes: sinclude(ext/mysql/libmysql/acinclude.m4) sinclude(ext/mysql/libmysql/mysql.m4) sinclude(libmysql/acinclude.m4) sinclude(libmysql/mysql.m4) When building this extension separately and phpize is called in the directory ext/mysql/, the former two files don't exist and autoconf 1.8 aborts build. The NetBSD pkgsrc fix to this is: --- config.m4.orig Mon Jul 14 12:43:51 2003 +++ config.m4 Wed Mar 31 12:02:43 2004 @@ -3,7 +3,5 @@ dnl -sinclude(ext/mysql/libmysql/acinclude.m4) -sinclude(ext/mysql/libmysql/mysql.m4) sinclude(libmysql/acinclude.m4) sinclude(libmysql/mysql.m4) Reproduce code: --- Build mysql extension separately from main package using autoconf 1.8. Expected result: The phpize phase eventually fails with: aclocal-1.8: cannot open ext/mysql/libmysql/acinclude.m4: No such file or directory *** Error code 1 -- Edit this bug report at http://bugs.php.net/?id=29133edit=1
#29116 [NEW]: Zend constant warning uses memory after free
From: jdolecek at NetBSD dot org
Operating system: NetBSD 2.0G
PHP version: 4.3.7
PHP Bug Type: Scripting Engine problem
Bug description: Zend constant warning uses memory after free
Description:
If a constant in a define() call is already defined, Zend engine issues a
warning with E_NOTICE set. This warning code might use memory after it's
freed. This can cause interpreter crash, especially under threaded Apache
2.x.
Following fixes the problem (this patch is in NetBSD pkgsrc ATM):
--- Zend/zend_constants.c.orig 2004-07-13 14:01:27.0 +0200
+++ Zend/zend_constants.c 2004-07-13 14:01:54.0 +0200
@@ -265,11 +265,11 @@
}
if (zend_hash_add(EG(zend_constants), name, c-name_len, (void *)
c, sizeof(zend_constant), NULL)==FAILURE) {
+ zend_error(E_NOTICE,Constant %s already defined, name);
free(c-name);
if (!(c-flags CONST_PERSISTENT)) {
zval_dtor(c-value);
}
- zend_error(E_NOTICE,Constant %s already defined, name);
ret = FAILURE;
}
if (lowercase_name) {
Reproduce code:
---
Under NetBSD, switch on extended malloc() debugging, by telling malloc to
fill free()d values with junk:
ln -s J /etc/malloc.conf
then, run:
php -r 'error_reporting(E_ALL); define(foo, j); define(foo, j);'
see something along:
PHP Notice: Constant
#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;#208;
in Command line code on line 1
--
Edit bug report at http://bugs.php.net/?id=29116edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29116r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29116r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29116r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29116r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29116r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29116r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29116r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29116r=support
Expected behavior: http://bugs.php.net/fix.php?id=29116r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29116r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29116r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29116r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29116r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29116r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29116r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29116r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29116r=float
#26972 [Bgs]: Please add option to use umap-uw linkage.c
ID: 26972 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org Status: Bogus Bug Type: Feature/Change Request Operating System: NetBSD 1.6ZH PHP Version: 4.3.4 New Comment: BTW, I was not able to find bug #26936 using advanced search by specifying Author address '[EMAIL PROTECTED]' and Status All. FWIW, now I cannot find even this bug (#26972) using the advanced search, either using Status=All or Status=Bogus. The search now returns (when using Status=Closed and the author setting) only two closed PRs, #26462 and #26896. Previous Comments: [2004-01-20 19:10:33] [EMAIL PROTECTED] And you already sent one report about this, bug #26936 ONE is enough.. [2004-01-20 19:09:06] [EMAIL PROTECTED] Reclassified. This is NOT a bug but feature/change request.. [2004-01-20 04:43:06] jdolecek at NetBSD dot org Description: In NetBSD pkgsrc, we patch the imap module to use directly umap-iw linkage.c, so that all available authenticators and methods would be compiled in for PHP. Since some other people might find this useful, it would be nice to have a configure option to enable this. This is the patch we currently use. It adds option --with-imap-linkage, which changes the code to use the linkage.c supplied by imap-uw package, instead of hardcoded list. It also disables the Kerberos check, since it's not necessary to explicitly link against Kerberos libs if the imap libraries contain Kerberos support. Note this adresses same problem as to Bug #4136. I don't know why the change to use linkage.c unconditionally was removed. Patch #1 --- config.m4.orig 2003-10-03 07:25:35.0 +0200 +++ config.m4 @@ -54,6 +54,14 @@ AC_DEFUN(PHP_IMAP_TEST_BUILD, [ ]) ]) +dsl Must be before --with-kerberos, affects the check +PHP_ARG_WITH(imap-linkage,use IMAP c-client linkage, +[ --with-imap-linkage Use IMAP c-client linkage to determine supported ite ms.]) + +if test $PHP_IMAP_LINKAGE != no; then + AC_DEFINE(HAVE_IMAP_LINKAGE, 1, [ ]) +fi + AC_DEFUN(PHP_IMAP_KRB_CHK, [ AC_ARG_WITH(kerberos, [ --with-kerberos[=DIR] IMAP: Include Kerberos support. DIR is the Kerbe ros install dir.],[ @@ -90,7 +98,7 @@ AC_DEFUN(PHP_IMAP_KRB_CHK, [ PHP_ADD_LIBRARY(k5crypto, 1, IMAP_SHARED_LIBADD) PHP_ADD_LIBRARY(com_err, 1, IMAP_SHARED_LIBADD) PHP_ADD_INCLUDE($PHP_KERBEROS_DIR/include) - else + elif test $PHP_IMAP_LINKAGE != yes; then AC_EGREP_HEADER(auth_gss, $IMAP_INC_DIR/linkage.h, [ AC_MSG_ERROR([This c-client library is built with Kerberos support. --- cut here -- Patch #2 --- php_imap.c.orig 2003-09-04 09:48:30.0 +0200 +++ php_imap.c @@ -408,6 +408,11 @@ PHP_MINIT_FUNCTION(imap) ZEND_INIT_MODULE_GLOBALS(imap, php_imap_init_globals, NULL) +/* + * Optionally use the installed c-client linkage.c to determine which drivers + * are authenticators are linked in. Otherwise use this fixed list. + */ +#ifndef HAVE_IMAP_LINKAGE #ifndef PHP_WIN32 mail_link(unixdriver); /* link in the unix driver */ mail_link(mhdriver); /* link in the mh driver */ @@ -423,6 +428,10 @@ PHP_MINIT_FUNCTION(imap) mail_link(tenexdriver);/* link in the tenex driver */ mail_link(mtxdriver); /* link in the mtx driver */ mail_link(dummydriver);/* link in the dummy driver */ +#else /* HAVE_IMAP_LINKAGE */ +/* link in the c-client mail and auth drivers */ +#include linkage.c +#endif /* HAVE_IMAP_LINKAGE */ #ifndef PHP_WIN32 auth_link(auth_log); /* link in the log authenticator */ Reproduce code: --- Code inspection. -- Edit this bug report at http://bugs.php.net/?id=26972edit=1
#26972 [Bgs]: Please add option to use umap-uw linkage.c
ID: 26972 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org Status: Bogus Bug Type: Feature/Change Request Operating System: NetBSD 1.6ZH PHP Version: 4.3.4 New Comment: Surely enough, the 'Status=Closed' in previous message should have been 'Status=All'. Previous Comments: [2004-01-21 08:37:38] jdolecek at NetBSD dot org BTW, I was not able to find bug #26936 using advanced search by specifying Author address '[EMAIL PROTECTED]' and Status All. FWIW, now I cannot find even this bug (#26972) using the advanced search, either using Status=All or Status=Bogus. The search now returns (when using Status=Closed and the author setting) only two closed PRs, #26462 and #26896. [2004-01-20 19:10:33] [EMAIL PROTECTED] And you already sent one report about this, bug #26936 ONE is enough.. [2004-01-20 19:09:06] [EMAIL PROTECTED] Reclassified. This is NOT a bug but feature/change request.. [2004-01-20 04:43:06] jdolecek at NetBSD dot org Description: In NetBSD pkgsrc, we patch the imap module to use directly umap-iw linkage.c, so that all available authenticators and methods would be compiled in for PHP. Since some other people might find this useful, it would be nice to have a configure option to enable this. This is the patch we currently use. It adds option --with-imap-linkage, which changes the code to use the linkage.c supplied by imap-uw package, instead of hardcoded list. It also disables the Kerberos check, since it's not necessary to explicitly link against Kerberos libs if the imap libraries contain Kerberos support. Note this adresses same problem as to Bug #4136. I don't know why the change to use linkage.c unconditionally was removed. Patch #1 --- config.m4.orig 2003-10-03 07:25:35.0 +0200 +++ config.m4 @@ -54,6 +54,14 @@ AC_DEFUN(PHP_IMAP_TEST_BUILD, [ ]) ]) +dsl Must be before --with-kerberos, affects the check +PHP_ARG_WITH(imap-linkage,use IMAP c-client linkage, +[ --with-imap-linkage Use IMAP c-client linkage to determine supported ite ms.]) + +if test $PHP_IMAP_LINKAGE != no; then + AC_DEFINE(HAVE_IMAP_LINKAGE, 1, [ ]) +fi + AC_DEFUN(PHP_IMAP_KRB_CHK, [ AC_ARG_WITH(kerberos, [ --with-kerberos[=DIR] IMAP: Include Kerberos support. DIR is the Kerbe ros install dir.],[ @@ -90,7 +98,7 @@ AC_DEFUN(PHP_IMAP_KRB_CHK, [ PHP_ADD_LIBRARY(k5crypto, 1, IMAP_SHARED_LIBADD) PHP_ADD_LIBRARY(com_err, 1, IMAP_SHARED_LIBADD) PHP_ADD_INCLUDE($PHP_KERBEROS_DIR/include) - else + elif test $PHP_IMAP_LINKAGE != yes; then AC_EGREP_HEADER(auth_gss, $IMAP_INC_DIR/linkage.h, [ AC_MSG_ERROR([This c-client library is built with Kerberos support. --- cut here -- Patch #2 --- php_imap.c.orig 2003-09-04 09:48:30.0 +0200 +++ php_imap.c @@ -408,6 +408,11 @@ PHP_MINIT_FUNCTION(imap) ZEND_INIT_MODULE_GLOBALS(imap, php_imap_init_globals, NULL) +/* + * Optionally use the installed c-client linkage.c to determine which drivers + * are authenticators are linked in. Otherwise use this fixed list. + */ +#ifndef HAVE_IMAP_LINKAGE #ifndef PHP_WIN32 mail_link(unixdriver); /* link in the unix driver */ mail_link(mhdriver); /* link in the mh driver */ @@ -423,6 +428,10 @@ PHP_MINIT_FUNCTION(imap) mail_link(tenexdriver);/* link in the tenex driver */ mail_link(mtxdriver); /* link in the mtx driver */ mail_link(dummydriver);/* link in the dummy driver */ +#else /* HAVE_IMAP_LINKAGE */ +/* link in the c-client mail and auth drivers */ +#include linkage.c +#endif /* HAVE_IMAP_LINKAGE */ #ifndef PHP_WIN32 auth_link(auth_log); /* link in the log authenticator */ Reproduce code: --- Code inspection. -- Edit this bug report at http://bugs.php.net/?id=26972edit=1
#26972 [NEW]: Please add option to use umap-uw linkage.c
From: jdolecek at NetBSD dot org Operating system: NetBSD 1.6ZH PHP version: 4.3.4 PHP Bug Type: IMAP related Bug description: Please add option to use umap-uw linkage.c Description: In NetBSD pkgsrc, we patch the imap module to use directly umap-iw linkage.c, so that all available authenticators and methods would be compiled in for PHP. Since some other people might find this useful, it would be nice to have a configure option to enable this. This is the patch we currently use. It adds option --with-imap-linkage, which changes the code to use the linkage.c supplied by imap-uw package, instead of hardcoded list. It also disables the Kerberos check, since it's not necessary to explicitly link against Kerberos libs if the imap libraries contain Kerberos support. Note this adresses same problem as to Bug #4136. I don't know why the change to use linkage.c unconditionally was removed. Patch #1 --- config.m4.orig 2003-10-03 07:25:35.0 +0200 +++ config.m4 @@ -54,6 +54,14 @@ AC_DEFUN(PHP_IMAP_TEST_BUILD, [ ]) ]) +dsl Must be before --with-kerberos, affects the check +PHP_ARG_WITH(imap-linkage,use IMAP c-client linkage, +[ --with-imap-linkage Use IMAP c-client linkage to determine supported ite ms.]) + +if test $PHP_IMAP_LINKAGE != no; then + AC_DEFINE(HAVE_IMAP_LINKAGE, 1, [ ]) +fi + AC_DEFUN(PHP_IMAP_KRB_CHK, [ AC_ARG_WITH(kerberos, [ --with-kerberos[=DIR] IMAP: Include Kerberos support. DIR is the Kerbe ros install dir.],[ @@ -90,7 +98,7 @@ AC_DEFUN(PHP_IMAP_KRB_CHK, [ PHP_ADD_LIBRARY(k5crypto, 1, IMAP_SHARED_LIBADD) PHP_ADD_LIBRARY(com_err, 1, IMAP_SHARED_LIBADD) PHP_ADD_INCLUDE($PHP_KERBEROS_DIR/include) - else + elif test $PHP_IMAP_LINKAGE != yes; then AC_EGREP_HEADER(auth_gss, $IMAP_INC_DIR/linkage.h, [ AC_MSG_ERROR([This c-client library is built with Kerberos support. --- cut here -- Patch #2 --- php_imap.c.orig 2003-09-04 09:48:30.0 +0200 +++ php_imap.c @@ -408,6 +408,11 @@ PHP_MINIT_FUNCTION(imap) ZEND_INIT_MODULE_GLOBALS(imap, php_imap_init_globals, NULL) +/* + * Optionally use the installed c-client linkage.c to determine which drivers + * are authenticators are linked in. Otherwise use this fixed list. + */ +#ifndef HAVE_IMAP_LINKAGE #ifndef PHP_WIN32 mail_link(unixdriver); /* link in the unix driver */ mail_link(mhdriver); /* link in the mh driver */ @@ -423,6 +428,10 @@ PHP_MINIT_FUNCTION(imap) mail_link(tenexdriver);/* link in the tenex driver */ mail_link(mtxdriver); /* link in the mtx driver */ mail_link(dummydriver);/* link in the dummy driver */ +#else /* HAVE_IMAP_LINKAGE */ +/* link in the c-client mail and auth drivers */ +#include linkage.c +#endif /* HAVE_IMAP_LINKAGE */ #ifndef PHP_WIN32 auth_link(auth_log); /* link in the log authenticator */ Reproduce code: --- Code inspection. -- Edit bug report at http://bugs.php.net/?id=26972edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26972r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26972r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26972r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26972r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26972r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26972r=needscript Try newer version: http://bugs.php.net/fix.php?id=26972r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26972r=support Expected behavior: http://bugs.php.net/fix.php?id=26972r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26972r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26972r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26972r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26972r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26972r=dst IIS Stability: http://bugs.php.net/fix.php?id=26972r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26972r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26972r=float
#26936 [NEW]: Add an option to compile imap with imap-uw c-client linkage
From: jdolecek at NetBSD dot org Operating system: NetBSD 1.6 ZG PHP version: 4.3.4 PHP Bug Type: IMAP related Bug description: Add an option to compile imap with imap-uw c-client linkage Description: It would be nice if it would be possible to compile imap module directly with imap-uw linkage file, so that all supported authentication modules and protocols would be available. Actually, patches implementing this are in NetBSD pkgsrc system for some time, and I hope such option would be useful for other systems too. Having this option integrated in main PHP tree would ease our package maintenance, too :) Note there is similar (now closed) PR #4136 with same issue. The bug DB entry claims it was fixed in CVS, I don't know why it was backed off. Anyway, following patch adds configure option --with-imap-linkage. This option makes php_imap.c #include directly c-client linkage.c, instead of using list of hardcoded stuff. Default is same as now, i.e. to NOT use linkage.c. The --with-imap-linkage also disables the --with-kerberos check, since that is not needed in this case. Patch #1 -- cut here -- --- config.m4.orig 2003-10-03 07:25:35.0 +0200 +++ config.m4 @@ -54,6 +54,14 @@ AC_DEFUN(PHP_IMAP_TEST_BUILD, [ ]) ]) +dsl Must be before --with-kerberos, affects the check +PHP_ARG_WITH(imap-linkage,use IMAP c-client linkage, +[ --with-imap-linkage Use IMAP c-client linkage to determine supported ite ms.]) + +if test $PHP_IMAP_LINKAGE != no; then + AC_DEFINE(HAVE_IMAP_LINKAGE, 1, [ ]) +fi + AC_DEFUN(PHP_IMAP_KRB_CHK, [ AC_ARG_WITH(kerberos, [ --with-kerberos[=DIR] IMAP: Include Kerberos support. DIR is the Kerbe ros install dir.],[ @@ -90,7 +98,7 @@ AC_DEFUN(PHP_IMAP_KRB_CHK, [ PHP_ADD_LIBRARY(k5crypto, 1, IMAP_SHARED_LIBADD) PHP_ADD_LIBRARY(com_err, 1, IMAP_SHARED_LIBADD) PHP_ADD_INCLUDE($PHP_KERBEROS_DIR/include) - else + elif test $PHP_IMAP_LINKAGE != yes; then AC_EGREP_HEADER(auth_gss, $IMAP_INC_DIR/linkage.h, [ AC_MSG_ERROR([This c-client library is built with Kerberos support. -- cut here -- Patch #2 -- cut here -- --- php_imap.c.orig 2003-09-04 09:48:30.0 +0200 +++ php_imap.c @@ -408,6 +408,11 @@ PHP_MINIT_FUNCTION(imap) ZEND_INIT_MODULE_GLOBALS(imap, php_imap_init_globals, NULL) +/* + * Optionally use the installed c-client linkage.c to determine which drivers + * are authenticators are linked in. Otherwise use this fixed list. + */ +#ifndef HAVE_IMAP_LINKAGE #ifndef PHP_WIN32 mail_link(unixdriver); /* link in the unix driver */ mail_link(mhdriver); /* link in the mh driver */ @@ -423,6 +428,10 @@ PHP_MINIT_FUNCTION(imap) mail_link(tenexdriver);/* link in the tenex driver */ mail_link(mtxdriver); /* link in the mtx driver */ mail_link(dummydriver);/* link in the dummy driver */ +#else /* HAVE_IMAP_LINKAGE */ +/* link in the c-client mail and auth drivers */ +#include linkage.c +#endif /* HAVE_IMAP_LINKAGE */ #ifndef PHP_WIN32 auth_link(auth_log); /* link in the log authenticator */ -- cut here -- Reproduce code: --- Code inspection - php_imap.c uses fixed list instead of using imap-uw supplied linkage.c. -- Edit bug report at http://bugs.php.net/?id=26936edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26936r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26936r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26936r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26936r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26936r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26936r=needscript Try newer version: http://bugs.php.net/fix.php?id=26936r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26936r=support Expected behavior: http://bugs.php.net/fix.php?id=26936r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26936r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26936r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26936r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26936r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26936r=dst IIS Stability: http://bugs.php.net/fix.php?id=26936r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26936r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26936r=float
#26896 [NEW]: ftp module doesn't work when compiled as extension module
From: jdolecek at NetBSD dot org Operating system: NetBSD 1.6ZG PHP version: 4.3.4 PHP Bug Type: FTP related Bug description: ftp module doesn't work when compiled as extension module Description: When the ftp extension is compiled as module and loaded as such, some symbols (such as ftp_connect()) are not defined and thus PHP won't start. This happens due to HAVE_FTP not being defined when ftp.c is being compiled. This is because ftp.c doesn't include config.h as it should. This is patch which fixes the problem (now in NetBSD pkgsrc): --- ftp.c.orig 2004-01-13 19:31:39.0 +0100 +++ ftp.c 2004-01-13 19:31:48.0 +0100 @@ -19,6 +19,10 @@ /* $Id: ftp.c,v 1.68.2.10 2003/09/09 21:15:20 pollita Exp $ */ +#ifdef HAVE_CONFIG_H +#include config.h +#endif + #include php.h #if HAVE_FTP Reproduce code: --- tar xzf php-4.3.4.tar.bz ext/ftp cd php-4.3.4/ext/ftp phpize ./configure --with-ftp make make install after that: php -r 'ftp_connect(ftp.funet.fi)' -- Edit bug report at http://bugs.php.net/?id=26896edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26896r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26896r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26896r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26896r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26896r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26896r=needscript Try newer version: http://bugs.php.net/fix.php?id=26896r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26896r=support Expected behavior: http://bugs.php.net/fix.php?id=26896r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26896r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26896r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26896r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26896r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26896r=dst IIS Stability: http://bugs.php.net/fix.php?id=26896r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26896r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26896r=float
#26896 [Opn]: ftp module doesn't work when compiled as extension module
ID: 26896 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org Status: Open Bug Type: FTP related Operating System: NetBSD 1.6ZG PHP Version: 4.3.4 New Comment: Forgot to add you need to add the extension=ftp.so line to your php.ini Sorry about that. Previous Comments: [2004-01-13 13:45:33] jdolecek at NetBSD dot org Description: When the ftp extension is compiled as module and loaded as such, some symbols (such as ftp_connect()) are not defined and thus PHP won't start. This happens due to HAVE_FTP not being defined when ftp.c is being compiled. This is because ftp.c doesn't include config.h as it should. This is patch which fixes the problem (now in NetBSD pkgsrc): --- ftp.c.orig 2004-01-13 19:31:39.0 +0100 +++ ftp.c 2004-01-13 19:31:48.0 +0100 @@ -19,6 +19,10 @@ /* $Id: ftp.c,v 1.68.2.10 2003/09/09 21:15:20 pollita Exp $ */ +#ifdef HAVE_CONFIG_H +#include config.h +#endif + #include php.h #if HAVE_FTP Reproduce code: --- tar xzf php-4.3.4.tar.bz ext/ftp cd php-4.3.4/ext/ftp phpize ./configure --with-ftp make make install after that: php -r 'ftp_connect(ftp.funet.fi)' -- Edit this bug report at http://bugs.php.net/?id=26896edit=1
#26462 [Fbk-Opn]: bcmath doesn't compile as module
ID: 26462 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org -Status: Feedback +Status: Open Bug Type: BC math related Operating System: NetBSD 1.6ZF PHP Version: 4.3.4 Assigned To: sniper New Comment: Sorry about not providing the steps at first. Here it is: 1. tar xzf php-4.3.4.tar.bz2 php-4.3.4/ext/bcmath 2. cd php-4.3.4/ext/bcmath 3. patch patch1; patch patch2 4. phpize 5. ./configure --enable-bcmath 6. gmake patch1 and patch2 are your two patches. These steps get me reliably to the same compilation failure, as pasted in previous feedback. Previous Comments: [2003-11-30 03:36:26] [EMAIL PROTECTED] Exactly HOW is the configure run? Give the full process, not just some part of it.. [2003-11-29 08:59:44] jdolecek at NetBSD dot org No, compile still fails with: cc -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src -I. -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath -DPHP_ATOM_INC -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/include -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/main -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/main -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/Zend -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/TSRM -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include -DHAVE_CONFIG_H -O2 -pipe -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include -c /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c -fPIC -DPIC -o libbcmath/src/.libs/init.o /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c: In function `bc_init_numbers': /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: `_zero_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: (Each undeclared identifier is reported only once /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: for each function it appears in.) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:106: error: `_one_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:106: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:107: error: invalid type argument of `-' /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:108: error: `_two_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:108: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:109: error: invalid type argument of `-' /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c: In function `bc_init_num': /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:128: error: `_zero_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:128: warning: passing arg 1 of `bc_copy_num' makes pointer from integer without a cast *** Error code 1 Stop. make: stopped in /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath *** Error code 1 Stop. make: stopped in /usr/pkgsrc/math/php4-bcmath *** Error code 1 Stop. make: stopped in /usr/pkgsrc/math/php4-bcmath I believe this is caused by libbcmath/init.c picking up 'wrong' config.h. [2003-11-29 08:36:58] [EMAIL PROTECTED] Fixed in CVS, here's the patch: http://www.php.net/~jani/patches/bug26462.patch [2003-11-29 08:15:52] [EMAIL PROTECTED] I'm working on this. (btw. The patch here is not ok..) [2003-11-29 07:34:08] jdolecek at NetBSD dot org Description: NetBSD pkgsrc compiles modules individually, using phpize et.al. bcmath config.m4 doesn't have correct paths, so some includes are not properly found and compile fails. Furthermore, it still insists on number.c being present, which is apparently not needed (it used to be needed in past, I guess). Note some care needs to be taken for the include paths, since some files include config.h, which need to pick up
#26462 [Fbk-Opn]: bcmath doesn't compile as module
ID: 26462 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org -Status: Feedback +Status: Open Bug Type: BC math related Operating System: NetBSD 1.6ZF PHP Version: 4.3.4 Assigned To: sniper New Comment: I split your patch into two files, so that there would we one patch per patched file. Yes, phpize is from PHP 4.3.4. libtool 1.4 autoconf 2.57 automake 1.7.6 Note: all other php4 modules build fine, so it's only problem with bcmath. Perhaps 'your' libfool magically strips some -I directives? Can you paste your compile line for libcmath/src/init.c? The problem happens due to init.c not picking .../ext/bcmath/config.h before including php_bcmath.h. Due to this, the #ifdef WITH_BCMATH block won't be included. Thus, BCG() macro is not defined and obviously the compile fails due to 'missing' _zero_ et.al. I'm not sure why it works for you - this is obviously wrong and shouldn't work anywhere. Anyway, adding #include ../../config.h just before #include ../../php_bcmath.h in bcmath.h fixed the compile problem, thus this updated patch to bcmath.h works fine: --- bcmath.h.orig 2002-11-22 10:27:08.0 +0100 +++ bcmath.h2003-12-01 13:10:05.0 +0100 @@ -52,8 +52,9 @@ in the case of leading zeros generated. */ } bc_struct; -#include php.h -#include ext/bcmath/php_bcmath.h +#include php.h +#include ../../config.h +#include ../../php_bcmath.h Note the file should really use #include php.h, because php.h comes from installed PHP headers, not local bcmath module stuff. So I propose this patch as 'final': --- libbcmath/src/bcmath.h.orig 2002-11-22 10:27:08.0 +0100 +++ libbcmath/src/bcmath.h 2003-12-01 13:16:46.0 +0100 @@ -53,7 +53,8 @@ } bc_struct; #include php.h -#include ext/bcmath/php_bcmath.h +#include ../../config.h +#include ../../php_bcmath.h /* The base used in storing the numbers in n_value above. With this patch (and the config.m4 fix to not include number.c), the module compiles fine for me. Previous Comments: [2003-12-01 03:49:13] [EMAIL PROTECTED] What two patches? There's exactly 1 (one) file I gave. Anyway, this works just fine for me.. What libtool, autoconf and automake versions you're using? Is the phpize you're using from PHP 4.3.4 ? [2003-12-01 03:26:16] jdolecek at NetBSD dot org Sorry about not providing the steps at first. Here it is: 1. tar xzf php-4.3.4.tar.bz2 php-4.3.4/ext/bcmath 2. cd php-4.3.4/ext/bcmath 3. patch patch1; patch patch2 4. phpize 5. ./configure --enable-bcmath 6. gmake patch1 and patch2 are your two patches. These steps get me reliably to the same compilation failure, as pasted in previous feedback. [2003-11-30 03:36:26] [EMAIL PROTECTED] Exactly HOW is the configure run? Give the full process, not just some part of it.. [2003-11-29 08:59:44] jdolecek at NetBSD dot org No, compile still fails with: cc -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src -I. -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath -DPHP_ATOM_INC -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/include -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/main -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/main -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/Zend -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/TSRM -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include -DHAVE_CONFIG_H -O2 -pipe -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include -c /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c -fPIC -DPIC -o libbcmath/src/.libs/init.o /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c: In function `bc_init_numbers': /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: `_zero_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: (Each undeclared identifier is reported only once /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: for each function it appears in.) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:106: error: `_one_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php
#26462 [Csd]: bcmath doesn't compile as module
ID: 26462 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org Status: Closed Bug Type: BC math related Operating System: NetBSD 1.6ZF PHP Version: 4.3.4 Assigned To: sniper New Comment: Yes, this works. Arguably it's not right to #ifdef HAVE_CONFIG_H just ../../config.h, since it's always necessary to bring that in before you #include php_bcmath.h and it's not related to libbcmath build per-se (it's libbcmath configure which defines HAVE_CONFIG_H). It would be also aesthetically more pleasing to use #include php.h instead of #include php.h. But I don't really care about the details. It's cool it now compiles out of box. Thank you. Previous Comments: [2003-12-01 09:01:23] [EMAIL PROTECTED] This patch should work better: http://www.php.net/~jani/patches/bug26462.patch (fixed in CVS too) [2003-12-01 07:17:59] jdolecek at NetBSD dot org I split your patch into two files, so that there would we one patch per patched file. Yes, phpize is from PHP 4.3.4. libtool 1.4 autoconf 2.57 automake 1.7.6 Note: all other php4 modules build fine, so it's only problem with bcmath. Perhaps 'your' libfool magically strips some -I directives? Can you paste your compile line for libcmath/src/init.c? The problem happens due to init.c not picking .../ext/bcmath/config.h before including php_bcmath.h. Due to this, the #ifdef WITH_BCMATH block won't be included. Thus, BCG() macro is not defined and obviously the compile fails due to 'missing' _zero_ et.al. I'm not sure why it works for you - this is obviously wrong and shouldn't work anywhere. Anyway, adding #include ../../config.h just before #include ../../php_bcmath.h in bcmath.h fixed the compile problem, thus this updated patch to bcmath.h works fine: --- bcmath.h.orig 2002-11-22 10:27:08.0 +0100 +++ bcmath.h2003-12-01 13:10:05.0 +0100 @@ -52,8 +52,9 @@ in the case of leading zeros generated. */ } bc_struct; -#include php.h -#include ext/bcmath/php_bcmath.h +#include php.h +#include ../../config.h +#include ../../php_bcmath.h Note the file should really use #include php.h, because php.h comes from installed PHP headers, not local bcmath module stuff. So I propose this patch as 'final': --- libbcmath/src/bcmath.h.orig 2002-11-22 10:27:08.0 +0100 +++ libbcmath/src/bcmath.h 2003-12-01 13:16:46.0 +0100 @@ -53,7 +53,8 @@ } bc_struct; #include php.h -#include ext/bcmath/php_bcmath.h +#include ../../config.h +#include ../../php_bcmath.h /* The base used in storing the numbers in n_value above. With this patch (and the config.m4 fix to not include number.c), the module compiles fine for me. [2003-12-01 03:49:13] [EMAIL PROTECTED] What two patches? There's exactly 1 (one) file I gave. Anyway, this works just fine for me.. What libtool, autoconf and automake versions you're using? Is the phpize you're using from PHP 4.3.4 ? [2003-12-01 03:26:16] jdolecek at NetBSD dot org Sorry about not providing the steps at first. Here it is: 1. tar xzf php-4.3.4.tar.bz2 php-4.3.4/ext/bcmath 2. cd php-4.3.4/ext/bcmath 3. patch patch1; patch patch2 4. phpize 5. ./configure --enable-bcmath 6. gmake patch1 and patch2 are your two patches. These steps get me reliably to the same compilation failure, as pasted in previous feedback. [2003-11-30 03:36:26] [EMAIL PROTECTED] Exactly HOW is the configure run? Give the full process, not just some part of it.. 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/26462 -- Edit this bug report at http://bugs.php.net/?id=26462edit=1
#26462 [NEW]: bcmath doesn't compile as module
From: jdolecek at NetBSD dot org Operating system: NetBSD 1.6ZF PHP version: 4.3.4 PHP Bug Type: BC math related Bug description: bcmath doesn't compile as module Description: NetBSD pkgsrc compiles modules individually, using phpize et.al. bcmath config.m4 doesn't have correct paths, so some includes are not properly found and compile fails. Furthermore, it still insists on number.c being present, which is apparently not needed (it used to be needed in past, I guess). Note some care needs to be taken for the include paths, since some files include config.h, which need to pick up the proper one - bcmath configure or libbcmath one - appropriately. Compile ends up with something along: In file included from /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/php_bcmath.h:26, from /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/bcmath.c:30: /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/bcmath.h:56:35: ext/bcmath/php_bcmath.h: No such file or directory Following patch fixes the problem: --- config.m4.orig 2002-03-07 15:18:01.0 +0100 +++ config.m4 2003-08-31 18:24:27.0 +0200 @@ -7,11 +7,11 @@ if test $PHP_BCMATH != no; then AC_DEFINE(WITH_BCMATH, 1, [Whether you have bcmath]) - PHP_NEW_EXTENSION(bcmath, bcmath.c number.c \ + PHP_NEW_EXTENSION(bcmath, bcmath.c \ libbcmath/src/add.c libbcmath/src/div.c libbcmath/src/init.c libbcmath/src/neg.c libbcmath/src/outofmem.c libbcmath/src/raisemod.c libbcmath/src/rt.c libbcmath/src/sub.c \ libbcmath/src/compare.c libbcmath/src/divmod.c libbcmath/src/int2num.c libbcmath/src/num2long.c libbcmath/src/output.c libbcmath/src/recmul.c \ libbcmath/src/sqrt.c libbcmath/src/zero.c libbcmath/src/debug.c libbcmath/src/doaddsub.c libbcmath/src/nearzero.c libbcmath/src/num2str.c libbcmath/src/raise.c \ libbcmath/src/rmzero.c libbcmath/src/str2num.c, - $ext_shared,,[EMAIL PROTECTED]@/libbcmath/src) + $ext_shared,,[EMAIL PROTECTED]@ [EMAIL PROTECTED]@/../.. [EMAIL PROTECTED]@/libbcmath/src) PHP_ADD_BUILD_DIR($ext_builddir/libbcmath/src) fi The patch is also available on NetBSD CVSweb server: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/math/php4-bcmath/patches/patch-aa?rev=1.2content-type=text/plain -- Edit bug report at http://bugs.php.net/?id=26462edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26462r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26462r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26462r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26462r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26462r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26462r=needscript Try newer version: http://bugs.php.net/fix.php?id=26462r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26462r=support Expected behavior: http://bugs.php.net/fix.php?id=26462r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26462r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26462r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26462r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26462r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26462r=dst IIS Stability: http://bugs.php.net/fix.php?id=26462r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26462r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26462r=float
#26462 [Csd-Opn]: bcmath doesn't compile as module
ID: 26462 User updated by: jdolecek at NetBSD dot org Reported By: jdolecek at NetBSD dot org -Status: Closed +Status: Open Bug Type: BC math related Operating System: NetBSD 1.6ZF PHP Version: 4.3.4 Assigned To: sniper New Comment: No, compile still fails with: cc -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src -I. -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath -DPHP_ATOM_INC -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/include -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/main -I/usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/main -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/Zend -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include/php/TSRM -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include -DHAVE_CONFIG_H -O2 -pipe -I/usr/obj/pkgsrc/math/php4-bcmath/work/.buildlink/include -c /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c -fPIC -DPIC -o libbcmath/src/.libs/init.o /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c: In function `bc_init_numbers': /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: `_zero_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: (Each undeclared identifier is reported only once /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: for each function it appears in.) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:105: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:106: error: `_one_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:106: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:107: error: invalid type argument of `-' /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:108: error: `_two_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:108: error: invalid lvalue in assignment /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:109: error: invalid type argument of `-' /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c: In function `bc_init_num': /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:128: error: `_zero_' undeclared (first use in this function) /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/init.c:128: warning: passing arg 1 of `bc_copy_num' makes pointer from integer without a cast *** Error code 1 Stop. make: stopped in /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath *** Error code 1 Stop. make: stopped in /usr/pkgsrc/math/php4-bcmath *** Error code 1 Stop. make: stopped in /usr/pkgsrc/math/php4-bcmath I believe this is caused by libbcmath/init.c picking up 'wrong' config.h. Previous Comments: [2003-11-29 08:36:58] [EMAIL PROTECTED] Fixed in CVS, here's the patch: http://www.php.net/~jani/patches/bug26462.patch [2003-11-29 08:15:52] [EMAIL PROTECTED] I'm working on this. (btw. The patch here is not ok..) [2003-11-29 07:34:08] jdolecek at NetBSD dot org Description: NetBSD pkgsrc compiles modules individually, using phpize et.al. bcmath config.m4 doesn't have correct paths, so some includes are not properly found and compile fails. Furthermore, it still insists on number.c being present, which is apparently not needed (it used to be needed in past, I guess). Note some care needs to be taken for the include paths, since some files include config.h, which need to pick up the proper one - bcmath configure or libbcmath one - appropriately. Compile ends up with something along: In file included from /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/php_bcmath.h:26, from /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/bcmath.c:30: /usr/obj/pkgsrc/math/php4-bcmath/work/php-4.3.4/ext/bcmath/libbcmath/src/bcmath.h:56:35: ext/bcmath/php_bcmath.h: No such file or directory Following patch fixes the problem: --- config.m4.orig 2002-03-07 15:18:01.0 +0100 +++ config.m4 2003-08-31 18:24:27.0 +0200 @@ -7,11 +7,11 @@ if test $PHP_BCMATH != no; then AC_DEFINE(WITH_BCMATH, 1, [Whether you
