ID: 20268
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Solaris 9
PHP Version: 4CVS-2002-11-05
New Comment:
Furthermore, there are some show-stoppers with OnUpdateInt and
zend_parse_parameters.
The LDAP module specifies longs rather than ints for its globals that
are being set via the INI mechanism. Same for some of the database
exts. To cope with this, I now have both OnUpdateInt and OnUpdateLong
into zend_ini.[ch].
Some potential affected files are:
php_ldap.h php_fbsql.h php_informix.h php_ii.h php_interbase.h
php_mssql.h php_mysql.h php_sybase_ct.h
However, in the case of the LDAP problem, there was some comparison
logic at 'fault', too. In ldap.c there was logic that said 'if x == -1,
then y is unlimited, otherwise actual y must be less than x'. This
fails (does not work and does not produce a warning) if x is < -1.
Other parts of ldap.c do use 'if x > -1' rather than 'if x == -1'. One
actualy advantage of the 'error' is that it did at least cause the
module to output a message along the lines of 'already have the maximum
of 0 connections open', which is an obvious sign that there's problem.
Also, for some reason configure doesn't add -lldap to LIBS for me, no
matter what combination of libtool/autoconf/automake I have used with
PHP 4.3*.
And now...it gets worse. There are heaps of instances where
zend_parse_parameters has been used to assign to ints instead of longs
(the documentation seems to say 'l' is for long, so people should be
assigning to longs, right?). BUT, for example, in php4/ext/dio/dio.c
the assignment is to type mode_t (rather than obviously int or long).
So it's a bit messy, but I basically changed int occurrences to longs
for make PHP work for me. There are some files like mcrypt.c where I
didn't even attempt it (even though I do use mcrypt so I'll have to
have it fixed sometime, if it needs fixing). Looks like all use of
zend_parse_parameters needs to be reviewed for type safety.
Also, there seems to be a bug in php4/ext/fdf/fdf.c's fdf_remove_item
(see what is passes to zend_parse_parameters, below).
Patches that made PHP stop crashing for the time being:
Index: ext/ldap/ldap.c
===================================================================
RCS file: /repository/php4/ext/ldap/ldap.c,v
retrieving revision 1.130
diff -u -r1.130 ldap.c
--- ext/ldap/ldap.c 5 Nov 2002 14:18:20 -0000 1.130
+++ ext/ldap/ldap.c 10 Nov 2002 03:46:14 -0000
@@ -200,7 +200,7 @@
/* {{{ PHP_INI_BEGIN
*/
PHP_INI_BEGIN()
- STD_PHP_INI_ENTRY_EX("ldap.max_links", "-1", PHP_INI_SYSTEM,
OnUpdateInt, max_links, zend_ldap_globals,
ldap_globals, display_link_numbers)
+ STD_PHP_INI_ENTRY_EX("ldap.max_links", "-1", PHP_INI_SYSTEM,
+ OnUpdateLong, max_links, zend_ldap_globals,
+ ldap_globals, display_link_numbers)
PHP_INI_END()
/* }}} */
@@ -288,7 +288,7 @@
php_info_print_table_row(2, "LDAP Support", "enabled" );
php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.130
2002/11/05 14:18:20 edink Exp $" );
- if (LDAPG(max_links) == -1) {
+ if (LDAPG(max_links) < 0) {
snprintf(tmp, 31, "%ld/unlimited", LDAPG(num_links));
} else {
snprintf(tmp, 31, "%ld/%ld", LDAPG(num_links), LDAPG(max_links));
@@ -345,11 +345,11 @@
{
char *host = NULL;
int hostlen;
- int port = 389; /* Default port */
+ long port = 389; /* Default port */
#ifdef HAVE_ORALDAP
char *wallet, *walletpasswd;
int walletlen, walletpasswdlen;
- int authmode;
+ long authmode;
int ssl=0;
#endif
ldap_linkdata *ld;
@@ -373,7 +373,7 @@
}
#endif
- if (LDAPG(max_links) != -1 && LDAPG(num_links) >= LDAPG(max_links))
{
+ if (LDAPG(max_links) > -1 && LDAPG(num_links) >= LDAPG(max_links)) {
php_error(E_WARNING, "%s(): Too many open links (%d)",
get_active_function_name(TSRMLS_C), LDAPG(num_links));
RETURN_FALSE;
}
Previous Comments:
------------------------------------------------------------------------
[2002-11-07 03:20:33] [EMAIL PROTECTED]
Hi,
I found this same problem under Solaris 8 using PHP 4.3.0pre2. For me,
this is due to 64-bit uncleanliness.
Since the CLI is required during PEAR installation, I did get an
obvious interruption to `make install`. Therefore, `make install` is
the "litmus test" I used to find the following three problems.
(1) One problem seems to be an inconsistency between Zend and PHP.
There are many 'globals' structs in PHP that specify int storage for
configuration values, along with the OnUpdateInt callback. However,
Zend defines OnUpdateInt to operate on longs. OnUpdateINT sounds like a
misnomer for something that works with longs. Also, OnUpdateInt uses
zend_atoi, which returns an int type, not long. So perhaps it really is
a Zend problem. This matters (e.g. on LP64 platforms) where
sizeof(int)!=sizeof(long).
I changed OnUpdateInt in zend_ini.c by modifying p from long* to int*
and loading of config now works fine for me.
--- Zend/zend_ini.c 2002-09-23 20:00:39.000000000 +0800
+++ Zend/zend_ini.c 2002-11-07 15:16:29.521055000 +0800
@@ -429,18 +429,18 @@
ZEND_API ZEND_INI_MH(OnUpdateInt)
{
- long *p;
+ int *p;
#ifndef ZTS
char *base = (char *) mh_arg2;
#else
char *base;
base = (char *) ts_resource(*((int *) mh_arg2));
#endif
- p = (long *) (base+(size_t) mh_arg1);
+ p = (int *) (base+(size_t) mh_arg1);
*p = zend_atoi(new_value, new_value_length);
return SUCCESS;
}
(2) Another problem shown in this pstack during PEAR installation:
100114084 php_stdiop_cast (ffffffff, 3, 7fff6734, 100114040, 100113fa0,
1005e2388) + 44
100114790 _php_stream_cast (1005e2388, 1, 7fff6734, 1, 2, 2) + 1b0
10009a95c zif_flock (2, 1005de668, 0, 1, 7fff75b0, 10009a8e0) + 7c
100146af8 execute (100343728, 7fff7dd0, 100338c50, 7fff7eb8, 1002cf700,
100343728) + 2278
100146870 execute (10057e6c8, 7fff8430, a8, 7fff84e0, 1002cf700,
10057e6c8) + 1ff0
100146870 execute (1003434a8, 7fff9a80, 7e0, 7fffa268, 1002cf700,
1003434a8) + 1ff0
100146870 execute (100536a58, 7fffa540, 100338c18, 7fffb5e8, 1002cf700,
100536a58) + 1ff0
100146870 execute (10033fae8, 100144880, 10011dd80, 1, 0, 0) + 1ff0
100137700 zend_execute_scripts (8, 0, 3, 7ffff7c0, 1002cf700, 7fffd818)
+ e0
100109114 php_execute_script (0, 1002cf700, 10033f528, 0, 2f, 2d) +
1d4
10014bcf0 main (0, 7ffff8b8, 7ffff8e8, 1002c9990, 100000000, 0) + 910
100021abc _start (0, 0, 0, 0, 0, 0) + 7c
(Note that I have actually trimmed the address widths down for
readability, though the stack itself is unmodified.)
`truss` indicated that the value of third argument ("ret") to
main/stream.c's php_stdiop_cast was an unusable address. That is also
the third argument to _php_stream_cast. So, we're zif_flock, expanded
from PHP_FUNCTION(flock) in ext/standard/file.[ch]. Now, fd is an int
and its address is passed as a void**. So php_stdiop_cast dereferences
it to a void* and then to store the int value, it is cast as (void*) to
be compatible at compile time. Since sizeof(int)!=sizeof(void*), we
have a problem. So I cast the point as an int* instead.
--- streams.c 2002-10-24 21:14:47.000000000 +0800
+++ streams.c 2002-11-07 17:10:27.015969000 +0800
@@ -1401,7 +1401,7 @@
}
if (ret) {
fflush(data->file);
- *ret = (void*)fd;
+ *(int*)ret = fd;
}
return SUCCESS;
default:
(3) Guess what. Argh. Now in php_strspn part of
./ext/standard/string.c. The last two arguments are bogus (we do have
less than 6 TB of RAM in this machine). Hmmm. zend_parse_parameters
returns junk into len1 and len2. Chapter 33 of the manual seems to
indicate that string length is returned as an int (and in zend_API.c
that does seem to be the case) so this was a bug in string.c. But this
is a bit odd, since zend_parse_parameters has 'l' for electing a long
argument but not an int argument. So there is this mixture of integer
lengths around. I knew nothing about Zend until today so I don't know
what supposed to happen here, simply that this is a way that made it
work for me:
--- string.c 2002-10-26 04:09:53.000000000 +0800
+++ string.c 2002-11-07 17:11:18.988027000 +0800
@@ -202,7 +202,8 @@
static void php_spn_common_handler(INTERNAL_FUNCTION_PARAMETERS, int
behavior)
{
char *s11, *s22;
- long len1, len2, start, len;
+ int len1, len2;
+ long start, len;
start = 0;
len = 0;
Although I have applied (1), (2), and (3) and found that PHP now
functions (in the five minutes since the compile finished and when I
wrote this message, at least), there could be similar timebombs lurking
inside if the motifs such as (2) are present in other locations.
--end--
------------------------------------------------------------------------
[2002-11-05 16:29:21] [EMAIL PROTECTED]
The CVS version (and the 4.3.0pre2 version, same error and backtrace)
core dumps on startup with this error:
Bus Error (core dumped)
My configure:
CFLAGS="-g -m64" ./configure --with-apache=../apache_1.3.27 --with-xml
--with-oci8=/usr/local/oracle/OraHome --with-zlib
--enable-inline-optimization --enable-bcmath --enable-debug
--with-curl
Here is the backtrace:
bash-2.05# gdb /usr/local/bin/php ,/core
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.9"...
/export/home/bdabney/php4/,/core: No such file or directory.
(gdb) quit
bash-2.05# gdb /usr/local/bin/php ./core
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.9"...
Core was generated by `/export/home/bdabney/php4/sapi/cli/php -d
safe_mode=0 -d open_basedir= /export/'.
Program terminated with signal 10, Bus error.
Reading symbols from /usr/lib/64/libz.so.1...done.
Loaded symbols for /usr/lib/64/libz.so.1
Reading symbols from /usr/lib/64/libdl.so.1...done.
Loaded symbols for /usr/lib/64/libdl.so.1
Reading symbols from /usr/lib/64/libsocket.so.1...done.
Loaded symbols for /usr/lib/64/libsocket.so.1
Reading symbols from /usr/lib/64/libnsl.so.1...done.
Loaded symbols for /usr/lib/64/libnsl.so.1
Reading symbols from /usr/lib/64/libcrypt_i.so.1...done.
Loaded symbols for /usr/lib/64/libcrypt_i.so.1
Reading symbols from /usr/lib/64/libresolv.so.2...done.
Loaded symbols for /usr/lib/64/libresolv.so.2
Reading symbols from /usr/lib/64/libm.so.1...done.
Loaded symbols for /usr/lib/64/libm.so.1
Reading symbols from /usr/local/lib/libcurl.so.2...done.
Loaded symbols for /usr/local/lib/libcurl.so.2
Reading symbols from /usr/lib/64/libgen.so.1...done.
Loaded symbols for /usr/lib/64/libgen.so.1
Reading symbols from
/usr/local/oracle/OraHome/lib/libclntsh.so.9.0...done.
Loaded symbols for /usr/local/oracle/OraHome/lib/libclntsh.so.9.0
Reading symbols from /usr/lib/64/libc.so.1...done.
Loaded symbols for /usr/lib/64/libc.so.1
Reading symbols from /usr/lib/64/libmp.so.2...done.
Loaded symbols for /usr/lib/64/libmp.so.2
Reading symbols from /usr/local/oracle/OraHome/lib/libwtc9.so...done.
Loaded symbols for /usr/local/oracle/OraHome/lib/libwtc9.so
---Type <return> to continue, or q <return> to quit---
Reading symbols from /usr/lib/64/libaio.so.1...done.
Loaded symbols for /usr/lib/64/libaio.so.1
Reading symbols from /usr/lib/64/librt.so.1...done.
Loaded symbols for /usr/lib/64/librt.so.1
Reading symbols from /usr/lib/64/libmd5.so.1...done.
Loaded symbols for /usr/lib/64/libmd5.so.1
Reading symbols from
/usr/platform/SUNW,Sun-Blade-100/lib/sparcv9/libc_psr.so.1...done.
Loaded symbols for
/usr/platform/SUNW,Sun-Blade-100/lib/sparcv9/libc_psr.so.1
#0 0x100265bd0 in OnUpdateInt (entry=0x100407fb0,
new_value=0x1002ad390 "1024", new_value_length=4, mh_arg1=0x4c,
mh_arg2=0x1003f2e50, mh_arg3=0x0, stage=1)
at /export/home/bdabney/php4/Zend/zend_ini.c:444
444 *p = zend_atoi(new_value, new_value_length);
(gdb) bt
#0 0x100265bd0 in OnUpdateInt (entry=0x100407fb0,
new_value=0x1002ad390 "1024", new_value_length=4, mh_arg1=0x4c,
mh_arg2=0x1003f2e50, mh_arg3=0x0, stage=1)
at /export/home/bdabney/php4/Zend/zend_ini.c:444
#1 0x100264cbc in zend_register_ini_entries (ini_entry=0x1003ec008,
module_number=0) at /export/home/bdabney/php4/Zend/zend_ini.c:157
#2 0x1001ea968 in php_module_startup (sf=0x1003f1e00,
additional_modules=0x0,
num_additional_modules=0) at
/export/home/bdabney/php4/main/main.c:1068
#3 0x10027644c in main (argc=9, argv=0xffffffff7ffffad8)
at /export/home/bdabney/php4/sapi/cli/php_cli.c:443
(gdb)
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20268&edit=1
