#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830 User updated by: adconrad at 0c3 dot net Reported By: adconrad at 0c3 dot net -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Debian 3.0/SPARC PHP Version: 4.3.7 New Comment: I don't have a Sparc machine in front of me right now to test, but looking at CVS, I don't see HOW this can be fixed, as the relevant portions of config.m4 haven't been touched since I reopened the bug. Previous Comments: [2004-12-13 00:14:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-06-07 05:14:52] adconrad at 0c3 dot net This bug has returned in PHP 4.3.7 with the changes made in ext/standard/config.m4, rev 1.47.2.14. [2004-04-04 06:14:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2004-04-03 08:34:24] adconrad at 0c3 dot net As an added note, I didn't bother trying to add a glibc or linux test in there, as most arch-specific compiler bugs seem to span OSs, and this bug would probably affect Solaris as well. We don't have a Solaris machine in-house anymore for me to test this theory on, however. [2004-04-03 08:31:25] adconrad at 0c3 dot net Please try the new config.m4 No go. The glibc tests appear to be incorrect. I took them out anyway, and changed the others, as rationalised below. Could you try and tweak the #ifdefs if they still don't work, and report back here. New and improved line: - #if (__GNUC__ == 2)(__GNUC_MINOR = 96)defined(__sparc__) - 1. I bumped the __GNUC_MINOR version to 96, as I will give you 99-to-1 odds the bug lasted until later pre-releases, and there are a couple of dists out there (*cough*RedHat*cough*) that actually released a stable dist based on that buggy pre-release. I can't verify this in the GCC bug tracker right now, but given how few people would be running gcc-2.96 on SPARC, I'd say it's a better safe than dealing with a duplicate bug that no one can hunt down later thing. 2. I pulled out the glibc check after confirming that building with gcc-2.95 on a system with glibc 2.3 produces the same segfaulting binary. It's all GCC's fault, glibc is an innocent bystander. 3. I changed __sparc64 (a define that doesn't always (or ever, in some systems) exist to __sparc__, since while I reported this happening on a sparc64 system, one must realise that sparc64 systems are sparc32 in user-space (well, most of them are). Compiling for sparc32 or sparc64 targets produces the same bug, so a generic __sparc__ test seems to make more sense. With this new and improved line, the Ugly Hack(tm) to work around this compiler issue seems to work just fine. Thanks for the help hunting it down and giving it some TLC. Clearly, this is a compiler/glibc bug. Sounds like something you guys at Debian might wanna fix as well. Certainly looks like a GCC bug, yes. However, it's a GCC bug in our stable release (which doesn't get compiler updates, or PHP updates for that matter, with the exception of security fixes), so it's not going to get fixed (this problem doesn't show up in sarge (our upcoming stable release) or sid (unstable)). Doesn't stop me from trying to run the latest PHP on production machines running Debian/stable, however. :) I'm not sure how many other Debian/SPARC users try to use the latest PHP on stable systems, but I'm sure they'd thank you for your efforts. Most probably use the php4 packages provided by Debian (and packaged by me, ironically) that work just fine, but there's always a few build-from-source types out there. 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/27830 -- Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
helly: Which unstable system is that? As I mentioned, it's Debian
stable, with what was at the time considered to be the most stable and
sane compiler.
abies: I'll give it a whirl right now. I assume by the rerun
buildconf comment that it's just a change to detect this particular
compiler bug? I'll check and see how it works.
Previous Comments:
[2004-04-03 04:38:12] [EMAIL PROTECTED]
... and be sure to re-run buildconf
[2004-04-03 04:37:57] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
In this case the error obviously comes from the unstable system you\'re
using. It would be a very good idea to tell the developers of all
unstable things you were using about the problem: returning a double
shouldn\'t fail at all.
[2004-04-03 04:37:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-04-02 19:44:34] adconrad at 0c3 dot net
Okay, there isn't much point in testing with gcc-3.3 on an unstable
system. I just install gcc-3.0.4 on the same stable system I was
testing this bug on, and it seems to work just fine.
config.{out,log}-gcc-3.0 and build.log-gcc-3.0 at the same URL as
previous logs.
So, to repeat: This bug appears to vanish building with gcc-3.0.4 (and
presumably any gcc 3.x), but manifests with gcc-2.95.
[2004-04-02 18:52:11] adconrad at 0c3 dot net
I'll build a Debian unstable chroot with gcc-3.3 and give it a whirl.
Of course, that'll also be using a new glibc, among other things, so
it's not terribly scientific.
I could also try gcc-3.0 on a stable system and see if that makes it
happy. Either way, gcc-2.95 and glibc 2.2 is a combination that should
probably be on the supported list for a while yet, I'd say.
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/27830
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
Please try the new config.m4
No go. The glibc tests appear to be incorrect. I took them out
anyway, and changed the others, as rationalised below.
Could you try and tweak the #ifdefs if they still don't
work, and report back here.
New and improved line:
-
#if (__GNUC__ == 2)(__GNUC_MINOR = 96)defined(__sparc__)
-
1. I bumped the __GNUC_MINOR version to 96, as I will give you 99-to-1
odds the bug lasted until later pre-releases, and there are a couple of
dists out there (*cough*RedHat*cough*) that actually released a stable
dist based on that buggy pre-release. I can't verify this in the GCC
bug tracker right now, but given how few people would be running
gcc-2.96 on SPARC, I'd say it's a better safe than dealing with a
duplicate bug that no one can hunt down later thing.
2. I pulled out the glibc check after confirming that building with
gcc-2.95 on a system with glibc 2.3 produces the same segfaulting
binary. It's all GCC's fault, glibc is an innocent bystander.
3. I changed __sparc64 (a define that doesn't always (or ever, in some
systems) exist to __sparc__, since while I reported this happening on a
sparc64 system, one must realise that sparc64 systems are sparc32 in
user-space (well, most of them are). Compiling for sparc32 or sparc64
targets produces the same bug, so a generic __sparc__ test seems to
make more sense.
With this new and improved line, the Ugly Hack(tm) to work around this
compiler issue seems to work just fine. Thanks for the help hunting it
down and giving it some TLC.
Clearly, this is a compiler/glibc bug. Sounds like
something you guys at Debian might wanna fix as well.
Certainly looks like a GCC bug, yes. However, it's a GCC bug in our
stable release (which doesn't get compiler updates, or PHP updates for
that matter, with the exception of security fixes), so it's not going
to get fixed (this problem doesn't show up in sarge (our upcoming
stable release) or sid (unstable)). Doesn't stop me from trying to run
the latest PHP on production machines running Debian/stable, however.
:)
I'm not sure how many other Debian/SPARC users try to use the latest
PHP on stable systems, but I'm sure they'd thank you for your efforts.
Most probably use the php4 packages provided by Debian (and packaged by
me, ironically) that work just fine, but there's always a few
build-from-source types out there.
Previous Comments:
[2004-04-03 07:29:55] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Please try the new config.m4
Could you try and tweak the #ifdefs if they still don't
work, and report back here.
Clearly, this is a compiler/glibc bug. Sounds like
something you guys at Debian might wanna fix as well.
[2004-04-03 06:42:23] adconrad at 0c3 dot net
The latest snapshot didn't actually have any changes other than
derick's valgrind-induced fixes, and still failed. Of course, this is
what I get for responding too quickly to the bug. :)
I snagged your config.m4 changes from CVS, applied them, regenerated
configure, and the resulting binary still segfaults with the same
backtrace as before.
config.{out,log} and build.log available at the same URL as always,
with a gcc-2.95-snapshot suffix.
[2004-04-03 05:43:14] adconrad at 0c3 dot net
helly: Which unstable system is that? As I mentioned, it's Debian
stable, with what was at the time considered to be the most stable and
sane compiler.
abies: I'll give it a whirl right now. I assume by the rerun
buildconf comment that it's just a change to detect this particular
compiler bug? I'll check and see how it works.
[2004-04-03 04:38:12] [EMAIL PROTECTED]
... and be sure to re-run buildconf
[2004-04-03 04:37:57] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
In this case the error obviously comes from the unstable system you\'re
using. It would be a very good
#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
Previous Comments:
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
#27830 [Fbk-Opn]: PHP segfaults immediately on startup
ID: 27830
User updated by: adconrad at 0c3 dot net
Reported By: adconrad at 0c3 dot net
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Debian 3.0/SPARC
PHP Version: 4.3.6RC1
New Comment:
I'll build a Debian unstable chroot with gcc-3.3 and give it a whirl.
Of course, that'll also be using a new glibc, among other things, so
it's not terribly scientific.
I could also try gcc-3.0 on a stable system and see if that makes it
happy. Either way, gcc-2.95 and glibc 2.2 is a combination that should
probably be on the supported list for a while yet, I'd say.
Previous Comments:
[2004-04-02 17:19:22] [EMAIL PROTECTED]
Could you try and compile with gcc-3.3 ? (I'm not
suggesting this as a fix, I'm just curious if it will work
around the problem)
I would do it myself if I had access to a Sparc64/linux
machine.
[2004-04-02 08:57:24] adconrad at 0c3 dot net
[EMAIL PROTECTED]:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/sparc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
./configure output (and log) is at
http://people.debian.org/~adconrad/php/config.{out,log}
[2004-04-02 04:41:05] [EMAIL PROTECTED]
Could you post your compiler version and the output of
'configure' ?
[2004-04-01 23:00:36] adconrad at 0c3 dot net
Description:
PHP segfaults immediately on execution, with or without input on SPARC.
If the patch[1] applied in CVS (ostensibly to improve portability)
is removed, the segfault goes away.
1. A short script that reproduces the problem.
[EMAIL PROTECTED]:~/build/php4/php-4.3.6RC1$ sapi/cli/php
Segmentation fault
2. The list of modules you compiled PHP with (your configure line).
'./configure' '--disable-all' '--prefix=/usr/local/php-4.3.6RC1'
'--with-apxs2=/usr/bin/apxs2' '--enable-sockets' '--with-pcre-regex'
'--enable-ctype' '--enable-overload' '--enable-posix'
'--enable-session' '--enable-tokenizer' '--enable-xml'
'--with-expat-dir=/usr' '--with-xmlrpc' '--with-pear' '--with-openssl'
'--with-mysql=shared,/usr' '--with-pgsql=shared,/usr'
'--with-sybase-ct=shared,/usr/local/freetds'
3. Any other information unique or specific to your setup.
Debian GNU/Linux 3.0 (woody), SPARC port on an UltraSPARC (sparc64)
CPU. glibc version 2.2.5-11.5.
4. Any changes made in your php.ini compared to php.ini-dist (not your
whole php.ini!)
This occurs with or without a php.ini.
5. A gdb backtrace.
Program received signal SIGSEGV, Segmentation fault.
0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
1021return HUGE_VAL;
(gdb) bt
#0 0x0005e170 in php_get_inf ()
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1021
#1 0x0005e4d4 in zm_startup_basic (type=1, module_number=4)
at
/home/adconrad/build/php4/php-4.3.6RC1/ext/standard/basic_functions.c:1065
#2 0x000ef068 in zend_startup_module (module=0x14647c)
at /home/adconrad/build/php4/php-4.3.6RC1/Zend/zend_API.c:1005
#3 0x000bead0 in php_startup_extensions (ptr=0x14eabc, count=1370840)
at /home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1044
#4 0x00108334 in php_startup_internal_extensions () at
main/internal_functions_cli.c:65
#5 0x000bf0b8 in php_module_startup (sf=0x149570,
additional_modules=0x0,
num_additional_modules=0) at
/home/adconrad/build/php4/php-4.3.6RC1/main/main.c:1216
#6 0x001074c8 in main (argc=1, argv=0xeb34)
at /home/adconrad/build/php4/php-4.3.6RC1/sapi/cli/php_cli.c:576
[1]
http://cvs.php.net/diff.php/php-src/ext/standard/basic_functions.c?login=2r1=1.543.2.34r2=1.543.2.35ty=u
--
Edit this bug report at http://bugs.php.net/?id=27830edit=1
