php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #20268 64-bit PHP 4.3 (extensive long vs int problems)
Submitted: 2002-11-05 16:29 UTC Modified: 2003-03-18 11:57 UTC
Votes:6
Avg. Score:4.7 ± 0.7
Reproduced:6 of 6 (100.0%)
Same Version:2 (33.3%)
Same OS:0 (0.0%)
From: bdabney at dallasnews dot com Assigned:
Status: Closed Package: Scripting Engine problem
PHP Version: 4CVS-2002-11-05 OS: any 64bit
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: bdabney at dallasnews dot com
New email:
PHP Version: OS:

 

 [2002-11-05 16:29 UTC] bdabney at dallasnews dot com 
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)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-21 10:15 UTC] ddhill at zk3 dot dec dot com 
I am glad to see someone is looking at the OnUpDateInt issue, and I think adding an OnUpdateLong is a good way to go. On Tru64 the int* vs. long* can cause some really hard to track errors because if the storage area is an int and is treated as a long, 32 bits of data following the int gets scrubbed with apparently no reason. I dug through a bunch of the 4.3.1 code and there is quite a mix of int an long being passed to OnUpdateInt, either directly or indirectly as in the case of zlib (which is where I encountered it). Blindly changeing OnUpdateInt to use int* will not work as there are quite a few longs being passed into the routine.

The right answer seems to be adding OnUpdateLong and then doing a code sweep of the core and extensions to make sure the right one is called, which seems to be the thrust of the previous response. I hope these changes will show up in the mainstream soon.

thanks!
 [2003-02-21 10:16 UTC] ddhill at zk3 dot dec dot com 
Forgot to mention - bug 21822 has the same root cause as this one.
 [2003-02-23 03:17 UTC] sniper@php.net 
[To: j-devenish at users dot sourceforge dot net]

PLEASE do NOT add such long diffs to bug reports!
Instead put them on some site and add an URL to them here.

(I deleted those comments from here now since they're pretty useless as the bug system mangles them anyway)
 [2003-02-23 03:44 UTC] j-devenish at users dot sourceforge dot net 
Sigh.

Since my entire post of 10/11 Nov has been deleted, and I did not receive an e-mail copy of my post via the bug submission system, I have no record of what I said. Presumably I stated that I, too, had encountered the problem, that I couldn't even install PHP 4.3, that it was due to int/long size mismatches on LP64 platforms, and then indicated the strategy I had used to work around it (via patches).

I posted patches and test result information (for HEAD of the day and also for 4.3.0pre2) to php-dev on 11 November 2002. Thread subject was "64-bit PHP 4.3 (extensive long vs int problems)". Those patches are now out of date because (on the downside) further int/long problems have crept in and (on the upside) some test cases have been improved.
 [2003-02-23 04:36 UTC] sniper@php.net 
http://news.php.net/article.php?group=php.bugs&article=24417
http://news.php.net/article.php?group=php.bugs&article=24418
 [2003-03-04 19:51 UTC] sniper@php.net 
Need to be addressed before 4.3.2 goes out the door.
 [2003-03-10 08:56 UTC] sniper@php.net 
Most, if not all issues should now be fixed.
Please give the latest stable snapshot a go.
(http://snaps.php.net/)
 [2003-03-12 02:08 UTC] j-devenish at users dot sourceforge dot net 
FWIW, I installed a "Stable (4.3.x-dev)" snapshot! After ./configure modifications (relating to hard-coded library paths -- that affects 64-bit RedHat, too, so maybe it will get fixed) it compiled and installed without crashing. Importantly, this out-of-the-box PHP actually serves files without crashing (though I get compile warnings regarding ostensibly non 64 bit-clean code).

One odd thing though: Apache reports that it is running 4.3.0-pre2. In contrast, Apache reports 4.3.2-dev when I have my php4 (PHP_4_3) checkout installed.

After modifying the Makefile to run the 'test' target, that does something, too. It results in a few core dumps, and a few tests still assume that values are limited to 32-bit precision, but 4.3.2 is still a step up for anyone who hasn't been able to use PHP 4.3 yet.
 [2003-03-14 03:13 UTC] j-devenish at users dot sourceforge dot net 
Although the original title of this bug was something to do with the
CLI crashing during the installation process, the title is now 64-bit
PHP 4.3.

Regarding the status of 4.3.2RC1, some known problems (not new ones)
are:

 - ./configure wants to compare hard-coded paths when finding some
   module libraries, rather than testing the compiler and linker
   themselves. This affects RedHat and SUSE Linux as well as
   Solaris, at least.
 - test cases have flaws that cause them to fail on LP64 systems
   although the failures aren't necessarily caused by any 64-bit
   problems in the code. This affects Solaris, at least.
 - various int/void* confusion (crash-causing). This affects
   Solaris, at least.

These have been reported in the bug system and discussed on php-dev
(and php-internals and php-qa). Although it was along time coming,
some partial fixes were applied between 4.3.0 and 4.3.1RC1.
 [2003-03-18 11:57 UTC] sniper@php.net 
[To: j-devenish at users dot sourceforge dot net]

Most of the critical issues are now fixed in CVS.
If there are any left, please open new bug report for them.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Nov 05 06:00:01 2025 UTC