#21948 [Fbk-Opn]: Reproducible segfaults when running IMP over SSL
ID: 21948
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: RedHat Linux 7.3
PHP Version: 4.3.0
New Comment:
Ok here's a more specific dump. First the configuration:
--enable-debug=yes
--disable-rpath
--with-openssl
--with-regex=system
--with-layout=GNU
--with-kerberos=/usr/kerberos
--enable-debugger
--enable-sockets
--with-imap
--with-imap-ssl
--with-mysql=/usr
--enable-wddx
--with-gettext
This seems to be as small as I could get it and still compile PHP and
run IMP (my c-client is built with kerberos so I had to enable that,
for example.)
Here is the resulting crash dump:
#0 0x4207b524 in chunk_realloc () from /lib/i686/libc.so.6
#1 0x4207b2f8 in realloc () from /lib/i686/libc.so.6
#2 0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#3 0x4202b33f in putenv () from /lib/i686/libc.so.6
#4 0x404ab54c in zif_putenv (ht=1, return_value=0x88b4bb4,
this_ptr=0x0, return_value_used=0)
at
/home/jmt/rpm/BUILD/php-4.3.0/ext/standard/basic_functions.c:1353
#5 0x405645d3 in execute (op_array=0x8b5c55c) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1596
#6 0x405647af in execute (op_array=0x8ae43e4) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1640
#7 0x405647af in execute (op_array=0x8bf06c4) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1640
#8 0x405647af in execute (op_array=0x8c7bc34) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:1640
#9 0x40569dee in execute (op_array=0x8836b34) at
/home/jmt/rpm/BUILD/php-4.3.0/Zend/zend_execute.c:2162
#10 0x4054f48c in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/jmt/rpm/BUILD/php-4.3.0/Zend/zend.c:864
#11 0x40522d36 in php_execute_script (primary_file=0xb140) at
/home/jmt/rpm/BUILD/php-4.3.0/main/main.c:1573
#12 0x4056c75a in apache_php_module_main (r=0x87d0a00,
display_source_mode=0)
at /home/jmt/rpm/BUILD/php-4.3.0/sapi/apache/sapi_apache.c:55
#13 0x4056d36b in send_php (r=0x87d0a00, display_source_mode=0,
filename=0x0)
at /home/jmt/rpm/BUILD/php-4.3.0/sapi/apache/mod_php4.c:556
#14 0x4056d3c3 in send_parsed_php (r=0x87d0a00) at
/home/jmt/rpm/BUILD/php-4.3.0/sapi/apache/mod_php4.c:571
#15 0x080547cd in ap_invoke_handler ()
#16 0x0806769c in process_request_internal ()
#17 0x40271d33 in handle_dir () from /etc/httpd/modules/mod_dir.so
#18 0x080547cd in ap_invoke_handler ()
#19 0x0806769c in process_request_internal ()
#20 0x08067713 in ap_process_request ()
#21 0x0805f867 in child_main ()
#22 0x0805fa0a in make_child ()
#23 0x0805fb4d in startup_children ()
#24 0x080601a0 in standalone_main ()
#25 0x08060aa3 in main ()
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
Hope this helps.
Previous Comments:
[2003-01-30 13:43:31] [EMAIL PROTECTED]
And cut down the amount of the configure options, to bare minimum to
get IMP work. And ditch the 'shared' options too.
[2003-01-29 15:06:24] [EMAIL PROTECTED]
I spoke too soon, the crash is still there. Am attempting to get a core
file now to generate another backtrace to see if its the same problem
or not.
bug 21804 seems like it may be related to this issue as well.
[2003-01-29 14:05:43] [EMAIL PROTECTED]
It is compiled with --enable-debug (see config list above), which is
why I made the note that the backtrace was somewhat baffling. I ran gdb
across libphp4.so just to confirm that it does indeed load debugging
symbols so they ARE there.
FYI I removed the SetEnvIf directive and the crashes have gone away it
seems.
[2003-01-29 13:56:17] [EMAIL PROTECTED]
Please compile PHP with --enable-debug, that will result in more
detailed backtraces.
[2003-01-29 12:32:18] [EMAIL PROTECTED]
I am getting a reproducible crash (segfaults) on my system using Apache
1.3.27 (RH 7.3 RPM) and PHP 4.3.0 (my custom RPM). PHP was built with
the following options:
--enable-force-cgi-redirect
--enable-debug
--enable-pic
--disable-rpath
--enable-inline-optimization
--with-bz2
--with-db3
--with-curl
--with-dom=%{_prefix}
--with-exec-dir=%{_bindir}
--with-freetype-dir=%{_prefix}
--with-png-dir=%{_prefix}
--with-gd
--enable-gd-native-ttf
--with-ttf
--with-gdbm
--with-gettext
--with-ncurses
--with-gmp
#21948 [NEW]: Reproducible segfaults when running IMP over SSL
From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.3
PHP version: 4.3.0
PHP Bug Type: Reproducible crash
Bug description: Reproducible segfaults when running IMP over SSL
I am getting a reproducible crash (segfaults) on my system using Apache
1.3.27 (RH 7.3 RPM) and PHP 4.3.0 (my custom RPM). PHP was built with the
following options:
--enable-force-cgi-redirect
--enable-debug
--enable-pic
--disable-rpath
--enable-inline-optimization
--with-bz2
--with-db3
--with-curl
--with-dom=%{_prefix}
--with-exec-dir=%{_bindir}
--with-freetype-dir=%{_prefix}
--with-png-dir=%{_prefix}
--with-gd
--enable-gd-native-ttf
--with-ttf
--with-gdbm
--with-gettext
--with-ncurses
--with-gmp
--with-iconv
--with-jpeg-dir=%{_prefix}
--with-mm
--with-openssl
--with-png
--with-pspell
--with-regex=system
--with-xml
--with-expat-dir=%{_prefix}
--with-zlib
--with-layout=GNU
--enable-bcmath
--enable-debugger
--enable-exif
--enable-ftp
--enable-magic-quotes
--enable-safe-mode
--enable-sockets
--enable-sysvsem
--enable-sysvshm
--enable-discard-path
--enable-track-vars
--enable-trans-sid
--enable-yp
--enable-wddx
--without-oci8
--with-imap=shared
--with-imap-ssl
--with-kerberos=/usr/kerberos
--with-ldap=shared
--with-mysql=shared,%{_prefix}
--with-pgsql=shared
--with-snmp=shared,%{_prefix}
--with-snmp=shared
--enable-ucd-snmp-hack
--with-unixODBC=shared
--enable-memory-limit
--enable-bcmath
--enable-shmop
--enable-versioning
--enable-calendar
--enable-dbx
--enable-dio
--enable-mbstring
--enable-mbstr-enc-trans
(please excuse the spec file variables; they are just pathnames so I left
them in)
Running apache in the debugger yields the following trace:
0 0x4207b524 in chunk_realloc () from /lib/i686/libc.so.6
#1 0x4207b2f8 in realloc () from /lib/i686/libc.so.6
#2 0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#3 0x4202b33f in putenv () from /lib/i686/libc.so.6
#4 0x4050cb5c in object.2 () from /etc/httpd/modules/libphp4.so
#5 0x405b3493 in object.2 () from /etc/httpd/modules/libphp4.so
#6 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#7 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#8 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#9 0x405b8cae in object.2 () from /etc/httpd/modules/libphp4.so
#10 0x4059e34c in object.2 () from /etc/httpd/modules/libphp4.so
#11 0x405718a6 in object.2 () from /etc/httpd/modules/libphp4.so
#12 0x405bb61a in object.2 () from /etc/httpd/modules/libphp4.so
#13 0x405bc22b in object.2 () from /etc/httpd/modules/libphp4.so
#14 0x405bc291 in object.2 () from /etc/httpd/modules/libphp4.so
#15 0x080547cd in ap_invoke_handler ()
#16 0x0806769c in process_request_internal ()
#17 0x40271d33 in handle_dir () from /etc/httpd/modules/mod_dir.so
#18 0x080547cd in ap_invoke_handler ()
#19 0x0806769c in process_request_internal ()
#20 0x08067713 in ap_process_request ()
#21 0x0805f867 in child_main ()
#22 0x0805fa0a in make_child ()
#23 0x0805fb4d in startup_children ()
#24 0x080601a0 in standalone_main ()
#25 0x08060aa3 in main ()
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(I don't understand the large sequence of object.2 function
referencesdebugging *is* compiled into the PHP library)
What is odd is that I have another server, almost identically configured
(same RPMs, etc) that does *not* have these crashes. And then it dawned on
me. The server that crashes runs IMP through an SSL connection whereas the
other does not. I suspect the putenv() call is related to following in my
SSL virtual host:
SetEnvIf User-Agent .*MSIE.* nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
(this might also explain why I have trouble causing the crash with
Mozilla...). I'd like to think this is an Apache bug but I don't have
crashes accesing for any other part of the site with SSL, so PHP seems to
at the very least make the bug surface.
--
Edit bug report at http://bugs.php.net/?id=21948edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21948r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21948r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21948r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21948r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21948r=oldversion
Not developer issue:
#21948 [Com]: Reproducible segfaults when running IMP over SSL
ID: 21948
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproducible crash
Operating System: RedHat Linux 7.3
PHP Version: 4.3.0
New Comment:
It is compiled with --enable-debug (see config list above), which is
why I made the note that the backtrace was somewhat baffling. I ran gdb
across libphp4.so just to confirm that it does indeed load debugging
symbols so they ARE there.
FYI I removed the SetEnvIf directive and the crashes have gone away it
seems.
Previous Comments:
[2003-01-29 13:56:17] [EMAIL PROTECTED]
Please compile PHP with --enable-debug, that will result in more
detailed backtraces.
[2003-01-29 12:32:18] [EMAIL PROTECTED]
I am getting a reproducible crash (segfaults) on my system using Apache
1.3.27 (RH 7.3 RPM) and PHP 4.3.0 (my custom RPM). PHP was built with
the following options:
--enable-force-cgi-redirect
--enable-debug
--enable-pic
--disable-rpath
--enable-inline-optimization
--with-bz2
--with-db3
--with-curl
--with-dom=%{_prefix}
--with-exec-dir=%{_bindir}
--with-freetype-dir=%{_prefix}
--with-png-dir=%{_prefix}
--with-gd
--enable-gd-native-ttf
--with-ttf
--with-gdbm
--with-gettext
--with-ncurses
--with-gmp
--with-iconv
--with-jpeg-dir=%{_prefix}
--with-mm
--with-openssl
--with-png
--with-pspell
--with-regex=system
--with-xml
--with-expat-dir=%{_prefix}
--with-zlib
--with-layout=GNU
--enable-bcmath
--enable-debugger
--enable-exif
--enable-ftp
--enable-magic-quotes
--enable-safe-mode
--enable-sockets
--enable-sysvsem
--enable-sysvshm
--enable-discard-path
--enable-track-vars
--enable-trans-sid
--enable-yp
--enable-wddx
--without-oci8
--with-imap=shared
--with-imap-ssl
--with-kerberos=/usr/kerberos
--with-ldap=shared
--with-mysql=shared,%{_prefix}
--with-pgsql=shared
--with-snmp=shared,%{_prefix}
--with-snmp=shared
--enable-ucd-snmp-hack
--with-unixODBC=shared
--enable-memory-limit
--enable-bcmath
--enable-shmop
--enable-versioning
--enable-calendar
--enable-dbx
--enable-dio
--enable-mbstring
--enable-mbstr-enc-trans
(please excuse the spec file variables; they are just pathnames so I
left them in)
Running apache in the debugger yields the following trace:
0 0x4207b524 in chunk_realloc () from /lib/i686/libc.so.6
#1 0x4207b2f8 in realloc () from /lib/i686/libc.so.6
#2 0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#3 0x4202b33f in putenv () from /lib/i686/libc.so.6
#4 0x4050cb5c in object.2 () from /etc/httpd/modules/libphp4.so
#5 0x405b3493 in object.2 () from /etc/httpd/modules/libphp4.so
#6 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#7 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#8 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#9 0x405b8cae in object.2 () from /etc/httpd/modules/libphp4.so
#10 0x4059e34c in object.2 () from /etc/httpd/modules/libphp4.so
#11 0x405718a6 in object.2 () from /etc/httpd/modules/libphp4.so
#12 0x405bb61a in object.2 () from /etc/httpd/modules/libphp4.so
#13 0x405bc22b in object.2 () from /etc/httpd/modules/libphp4.so
#14 0x405bc291 in object.2 () from /etc/httpd/modules/libphp4.so
#15 0x080547cd in ap_invoke_handler ()
#16 0x0806769c in process_request_internal ()
#17 0x40271d33 in handle_dir () from /etc/httpd/modules/mod_dir.so
#18 0x080547cd in ap_invoke_handler ()
#19 0x0806769c in process_request_internal ()
#20 0x08067713 in ap_process_request ()
#21 0x0805f867 in child_main ()
#22 0x0805fa0a in make_child ()
#23 0x0805fb4d in startup_children ()
#24 0x080601a0 in standalone_main ()
#25 0x08060aa3 in main ()
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(I don't understand the large sequence of object.2 function
referencesdebugging *is* compiled into the PHP library)
What is odd is that I have another server, almost identically
configured (same RPMs, etc) that does *not* have these crashes. And
then it dawned on me. The server that crashes runs IMP through an SSL
connection whereas the other does not. I suspect the putenv() call is
related to following in my SSL virtual host:
SetEnvIf User-Agent .*MSIE.* nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
(this might also explain
#21948 [Com]: Reproducible segfaults when running IMP over SSL
ID: 21948
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Reproducible crash
Operating System: RedHat Linux 7.3
PHP Version: 4.3.0
New Comment:
I spoke too soon, the crash is still there. Am attempting to get a core
file now to generate another backtrace to see if its the same problem
or not.
bug 21804 seems like it may be related to this issue as well.
Previous Comments:
[2003-01-29 14:05:43] [EMAIL PROTECTED]
It is compiled with --enable-debug (see config list above), which is
why I made the note that the backtrace was somewhat baffling. I ran gdb
across libphp4.so just to confirm that it does indeed load debugging
symbols so they ARE there.
FYI I removed the SetEnvIf directive and the crashes have gone away it
seems.
[2003-01-29 13:56:17] [EMAIL PROTECTED]
Please compile PHP with --enable-debug, that will result in more
detailed backtraces.
[2003-01-29 12:32:18] [EMAIL PROTECTED]
I am getting a reproducible crash (segfaults) on my system using Apache
1.3.27 (RH 7.3 RPM) and PHP 4.3.0 (my custom RPM). PHP was built with
the following options:
--enable-force-cgi-redirect
--enable-debug
--enable-pic
--disable-rpath
--enable-inline-optimization
--with-bz2
--with-db3
--with-curl
--with-dom=%{_prefix}
--with-exec-dir=%{_bindir}
--with-freetype-dir=%{_prefix}
--with-png-dir=%{_prefix}
--with-gd
--enable-gd-native-ttf
--with-ttf
--with-gdbm
--with-gettext
--with-ncurses
--with-gmp
--with-iconv
--with-jpeg-dir=%{_prefix}
--with-mm
--with-openssl
--with-png
--with-pspell
--with-regex=system
--with-xml
--with-expat-dir=%{_prefix}
--with-zlib
--with-layout=GNU
--enable-bcmath
--enable-debugger
--enable-exif
--enable-ftp
--enable-magic-quotes
--enable-safe-mode
--enable-sockets
--enable-sysvsem
--enable-sysvshm
--enable-discard-path
--enable-track-vars
--enable-trans-sid
--enable-yp
--enable-wddx
--without-oci8
--with-imap=shared
--with-imap-ssl
--with-kerberos=/usr/kerberos
--with-ldap=shared
--with-mysql=shared,%{_prefix}
--with-pgsql=shared
--with-snmp=shared,%{_prefix}
--with-snmp=shared
--enable-ucd-snmp-hack
--with-unixODBC=shared
--enable-memory-limit
--enable-bcmath
--enable-shmop
--enable-versioning
--enable-calendar
--enable-dbx
--enable-dio
--enable-mbstring
--enable-mbstr-enc-trans
(please excuse the spec file variables; they are just pathnames so I
left them in)
Running apache in the debugger yields the following trace:
0 0x4207b524 in chunk_realloc () from /lib/i686/libc.so.6
#1 0x4207b2f8 in realloc () from /lib/i686/libc.so.6
#2 0x4202b65c in __add_to_environ () from /lib/i686/libc.so.6
#3 0x4202b33f in putenv () from /lib/i686/libc.so.6
#4 0x4050cb5c in object.2 () from /etc/httpd/modules/libphp4.so
#5 0x405b3493 in object.2 () from /etc/httpd/modules/libphp4.so
#6 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#7 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#8 0x405b366f in object.2 () from /etc/httpd/modules/libphp4.so
#9 0x405b8cae in object.2 () from /etc/httpd/modules/libphp4.so
#10 0x4059e34c in object.2 () from /etc/httpd/modules/libphp4.so
#11 0x405718a6 in object.2 () from /etc/httpd/modules/libphp4.so
#12 0x405bb61a in object.2 () from /etc/httpd/modules/libphp4.so
#13 0x405bc22b in object.2 () from /etc/httpd/modules/libphp4.so
#14 0x405bc291 in object.2 () from /etc/httpd/modules/libphp4.so
#15 0x080547cd in ap_invoke_handler ()
#16 0x0806769c in process_request_internal ()
#17 0x40271d33 in handle_dir () from /etc/httpd/modules/mod_dir.so
#18 0x080547cd in ap_invoke_handler ()
#19 0x0806769c in process_request_internal ()
#20 0x08067713 in ap_process_request ()
#21 0x0805f867 in child_main ()
#22 0x0805fa0a in make_child ()
#23 0x0805fb4d in startup_children ()
#24 0x080601a0 in standalone_main ()
#25 0x08060aa3 in main ()
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
(I don't understand the large sequence of object.2 function
referencesdebugging *is* compiled into the PHP library)
What is odd is that I have another server, almost identically
configured (same RPMs, etc) that does *not* have
#21804 [Com]: php crashes iPlanet - php4_execute
ID: 21804 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Solaris 8 PHP Version: 4.3.1-dev New Comment: Bug #21948 may be a related issue. Previous Comments: [2003-01-23 13:08:56] [EMAIL PROTECTED] It crashes with other scripts as well. Our developers experienced this problem, and I found that these two scripts reliably reproduce it. We set the Oracle variables in the script because multiple applications run in one web server instance - they may not use the same version of Oracle, and they certainly use different sids. However, when I commented out the putenv/getenv statements, the test ran cleanly. The byte count wrong messages went away too. So we do have a kludge of a work-around. It would be nice to have this fixed. I'm not clear why setting environment variables in the php script is a bad idea. I would expect each thread to have it's own environment... Thanks, David [2003-01-22 21:58:58] [EMAIL PROTECTED] Does the crash happen only with the provided script? And btw. you should set those envinronment variables in the system, NOT in the script.. [2003-01-21 13:29:00] [EMAIL PROTECTED] Had the wrong email addr... [2003-01-21 13:25:04] [EMAIL PROTECTED] I can reliably crash iPlanet by running http_load -parallel 5 by concurrently using both of the two scripts below. This is like 20613, but that was fixed in Nov and I have this problem now with a current version of php. I have found no resolution except to run php single-threaded - stable, but hardly an option for a 100-user app that makes Oracle queries... I have reproduced this with iPlanet 6.0sp2 and 6.0sp5, php4.2.3, php 4.3.0, and php4-STABLE-200301140030, running on a 280R and an Ultra 2. I built php using gcc 2.95.3 with these options: --prefix=/shared/gnu \ --with-config-file-path=$prefix/../lib \ --enable-discard-path --enable-tracking \ --enable-libgcc --with-ndbm \ --with-ldap=openldap 2.0.27 path \ --with-oracle=oracle 8.1.7.2 path \ --without-mysql --with-nsapi=iplanet path The error I see is: catastrophe (1625): Server crash detected (signal SIGSEGV) info (1625): Crash occurred in NSAPI SAF php4_execute info (1625): Crash occurred in function strlen from module /usr/lib/libc.so.1 Here is the back trace: (gdb) bt #0 0xfea33344 in strlen () from /usr/lib/libc.so.1 #1 0xfd6b3e90 in _estrdup (s=0xb8 Address 0xb8 out of bounds) at /shared/gnu/src/php-4.2.3/Zend/zend_alloc.c:322 #2 0xfd738948 in php_print_info (flag=32, tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/ext/standard/info.c:273 #3 0xfd73935c in zif_phpinfo (ht=0, return_value=0x8d6c18, this_ptr=0x0, return_value_used=0, tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/ext/standard/info.c:471 #4 0xfd6c2740 in execute () from /opt/local/php/lib/nsapi/libphp4.so #5 0xfd6d50d0 in zend_execute_scripts (type=8, tsrm_ls=0x8600e8, retval=0x0, file_count=3) at /shared/gnu/src/php-4.2.3/Zend/zend.c:812 #6 0xfd6e4368 in php_execute_script (primary_file=0xfaef1b48, tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/main/main.c:1383 #7 0xfd6e0b90 in nsapi_module_main (request_context=0x0, tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:462 #8 0xfd6e0d1c in php4_execute (pb=0x3d47f8, sn=0x6e3a90, rq=0x6e3ad8) at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:513 #9 0xff239b14 in __0Fcfunc_native_pool_thread_mainP6NNSTPWorkArg_s () from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libns-httpd40.so #10 0xfe8e16cc in NSTP_ThreadMain () from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnstp.so #11 0xfed676a0 in _pt_root () from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnspr4.so (gdb) Finally, here are the two scripts: --- html body h2PHP Operational Qualification Test/h2 p This test displays a Hello, world. announcment, then a series of tables describing the PHP environment. /p p The classic announcement: ?php echo(Hello, world.); ? /p p PHP Info for this installation: /p ?php phpinfo(); ? /body /html html body h2PHP Operational Qualification Test: Oracle Connectivity/h2 p This test connects to an Oracle database and displays some stuff. /p p ?php $userid = dwells; putenv(ORACLE_SID=clindev); putenv(ORACLE_HOME=/opt/local/newshare/oracle/product/7.3.3.6); putenv(TNS_ADMIN=/opt/local/newshare/oracle/product/7.3.3.6/network/admin); $query = sprintf(select * from Employee); $ncols = $nrows = 7; printf(pResult size is
Bug #16629 Updated: php_flag not working and php_value strange behavior
ID: 16629 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Windows XP PHP Version: 4.2.0 New Comment: I also have this problem under FreeBSD with Apache 2.0.35 and PHP/4.3.0-dev, and I have a working patch. I don't know where to sedn it or how to attach it. If someone could email me where to send it, I'll send it. Previous Comments: [2002-04-26 17:47:09] [EMAIL PROTECTED] Same problem on Linux machine running apache 2.0.35 with FINAL release of php 4.2.0 [2002-04-24 17:11:42] [EMAIL PROTECTED] I have the same problem under Windows 98 SE (Apache 2.0.35) and the FINAL RELEASE of PHP 4.2.0. [2002-04-16 05:50:15] [EMAIL PROTECTED] same here on win2k, php 4.2.0 rc4 [2002-04-16 04:44:44] [EMAIL PROTECTED] I was attempting to modify register_globals value in my vhost config file like i used to do with PHP 4.1.X + Apache 1.3: php_value register_globals On / Off It didn't work with PHP 4.2.0 RC/3 even if i didn't get any error message (the value just didn't get changed) i tried using php_flag register_globals On / Off, but i got an error message when attempting to restart apache: Invalid command 'php_flag', perhaps mis-spelled or defined by a module not included in the server configuration Same thing with php_admin_flag I had to use php_value register_globals 1 / 0 to get it to work. I'm running Apache 2.0.35 on Windows XP professional, with PHP 4.2.0 RC/3. -- Edit this bug report at http://bugs.php.net/?id=16629edit=1
