#22684 [Opn]: Unhappy with strtoll declaration in bundled libmysql
ID: 22684 User updated by: michael dot mauch at gmx dot de Reported By: michael dot mauch at gmx dot de Status: Open Bug Type: MySQL related Operating System: Tru64 4.0g PHP Version: 5.0.0-dev 4.3.2RC1 New Comment: I already reported it to the MySQL people back in March (I thought I had noted it here, but obviously not). I got a private answer saying that the fix is not so easy as I thought, because it would break the build on other machines. I'll check and see if there are any news. Previous Comments: [2003-05-30 14:42:32] [EMAIL PROTECTED] Could you please report this bug (with latest stable 3.23.x client library) to bugs.mysql.com ? [2003-03-14 11:19:34] [EMAIL PROTECTED] You should report this to the mysql. (if you already haven't :) Even as it clearly is Mysql problem, it's better leave this open for now as a reminder to upgrade the bundled library as soon as it's fixed. [2003-03-14 10:31:06] michael dot mauch at gmx dot de No, MySQL 3.23.55 shows the same error = bogus (but the Status box only has Open or Close, so I have to leave it open). [2003-03-13 17:20:11] [EMAIL PROTECTED] Do you get the same error when you compile mysql? [2003-03-13 15:24:21] michael dot mauch at gmx dot de cc: Error: /house/elmicha/local/src/php-4.3.2RC1/ext/mysql/libmysql/strto.c, line 68: In this declaration, the type of strtoll is not compatible with the type of a previous declaration of strtoll at line number 44 in file /usr/include.dtk/stdlib.h. (notcompat) function (const char *nptr,char **endptr,int base) ^ The declaration of strtoll() in stdlib.h is: extern long long int strtoll( const char * /*restrict*/ __nptr, char ** /*restrict*/ __endptr, int __base); The declaration in strto.c is expanded to: longlong strtoll (const char *nptr,char **endptr,int base) % cc -V: Compaq C V6.5-207 (dtk) on Digital UNIX V4.0G (Rev. 1530) Compiler Driver V6.5-207 (dtk) (dtk) cc Driver http://bugs.php.net/bug.php?id=18815 looks similar, but it's closed (and on Linux). -- Edit this bug report at http://bugs.php.net/?id=22684edit=1
#22927 [Com]: OCI_SHARED init flag cause SIGABRT
ID: 22927 Comment by: michael dot mauch at gmx dot de Reported By: soula at lifl dot fr Status: Open Bug Type: OCI8 related Operating System: Tru64 PHP Version: 4.3.2RC1 New Comment: I reported the same problem on Linux in http://bugs.php.net/bug.php?id=22521. Previous Comments: [2003-03-27 09:08:09] soula at lifl dot fr I use php4-STABLE-200303241630 version, Oracle-8.1.7 and Tru64/5.1 . In standalone or within Apache, the initialization of OCI8 module (function OCIInitialise) with OCI_SHARED flag cause an immediate SIGABRT. Without the flag, the OCI8 initialize works well. Here the compilation config : Configure Command = './configure' '--prefix=/usr/local/php-200303241630-ap1' '--enable-memory-limit' '--enable-shared' '--enable-sockets' '--enable-trans-sid' '--enable-debug' '--with-config-file-path=/usr/local/lib' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-debugger=yes' '--enable-safe-mode' '--with-exec-dir=/usr/bin' '--with-mod_charset' '--with-openssl' '--with-bz2' '--with-zlib-dir' '--with-gettext' '--with-kerberos' '--with-regex=system' '--with-zlib' '--with-gd=shared' '--with-jpeg-dir=/usr/local/jpeg/lib' '--with-png-dir=/usr/local/lib' '--with-xpm-dir=/usr/local/lib' '--with-oci8=shared,/usr/oracle/product/8.1.6' '--with-ldap=shared' '--with-mysql=shared,/usr/local/mysql' '--with-pgsql=shared,/usr/local/pgsql' Here the gdb backtrace for ./php -i : Core was generated by `php'. Program terminated with signal 6, IOT/Abort trap. Reading symbols from /usr/local/lib/libz.so.1.1.3...done. Reading symbols from /usr/local/lib/libssl.so...done. Reading symbols from /usr/local/lib/libcrypto.so...done. Reading symbols from /usr/shlib/libm.so...done. Reading symbols from /usr/shlib/libc.so...done. Reading symbols from /usr/local/php-200303241630-ap1/lib/php/extensions/debug-non-zts-20020429/libldap.so...done. Reading symbols from /usr/local/lib/libldap.so...done. Reading symbols from /usr/local/lib/liblber.so...done. Reading symbols from /usr/local/lib/libgcc_s.so.1...done. Reading symbols from /usr/local/php-200303241630-ap1/lib/php/extensions/debug-non-zts-20020429/libmysql.so...done. Reading symbols from /usr/local/php-200303241630-ap1/lib/php/extensions/debug-non-zts-20020429/liboci8.so...done. Reading symbols from /usr/oracle/product/8.1.6/lib/libclntsh.so.8.0...done. Reading symbols from /usr/shlib/libjava.so...done. Reading symbols from /usr/oracle/product/8.1.6/lib/libwtc8.so...done. Reading symbols from /usr/shlib/libexc.so...done. Reading symbols from /usr/shlib/librt.so...done. Reading symbols from /usr/shlib/libaio_raw.so...done. Reading symbols from /usr/shlib/libpthread.so...done. Reading symbols from /usr/shlib/libmach.so...done. #0 0x3ff805bab48 in __nxm_thread_kill () from /usr/shlib/libpthread.so (gdb) bt #0 0x3ff805bab48 in __nxm_thread_kill () from /usr/shlib/libpthread.so #1 0x3ff805b4148 in pthread_kill () from /usr/shlib/libpthread.so #2 0x3ff805c99ec in __tsInit () from /usr/shlib/libpthread.so #3 0x3ff80118f58 in tis_raise () from /usr/shlib/libc.so #4 0x3ff80170764 in raise () from /usr/shlib/libc.so #5 0x3ff8018f6e0 in __ieee_get_fp_control () from /usr/shlib/libc.so #6 0x3ff80191bec in __exc_raise_status_exception () from /usr/shlib/libc.so #7 0x3ff807f2280 in exc_raise_status_exception () from /usr/shlib/libexc.so #8 0x30003cfc078 in kgepop () at /vobs/rdbms/src/generic/vos/kge.c:401 #9 0x30003cfd124 in kgesev () at /vobs/rdbms/src/generic/vos/kge.c:965 #10 0x30003cfcc68 in kgesec0 () at /vobs/rdbms/src/generic/vos/kge.c:748 #11 0x300039f206c in kgupmcreate_sga () at /vobs/rdbms/src/client/vos/kgupm.c:313 #12 0x300039d6774 in kgup_startup () at /vobs/rdbms/src/client/vos/kgup.c:528 #13 0x3000396d810 in kpushInit () at /vobs/rdbms/src/client/progint/kpu/kpuini.c:2774 #14 0x30003d06764 in kpummpin () at /vobs/rdbms/src/generic/progint/progint/kpumm.c:448 #15 0x300039687d8 in kpupin () at /vobs/rdbms/src/client/progint/kpu/kpuini.c:574 #16 0x30003951010 in OCIInitialize () at /vobs/rdbms/src/client/progint/oci/oci8.c:261 #17 0x3000300496c in zm_startup_oci (type=-1071955256, module_number=16) at /usr/local/tmp/php4-STABLE-200303241630/ext/oci8/oci8.c:518 #18 0x1200737f4 in php_dl (file=0x140062710, type=1, return_value=0x11fffbad0) at /usr/local/tmp/php4-STABLE-200303241630/ext/standard/dl.c:238 #19 0x1200feea0 in php_load_function_extension_cb (arg=0x3ffc01b42c8) at /usr/local/tmp/php4-STABLE-200303241630/main/php_ini.c:216 #20 0x12012b9fc in zend_llist_apply (l=0x3ffc01b42c8, func=0x1200fee80 php_load_function_extension_cb) at /usr/local/tmp/php4-STABLE-200303241630/Zend/zend_llist.c:189 #21 0x1200ff630 in php_ini_delayed_modules_startup () at /usr/local/tmp/php4-STABLE-200303241630/main/php_ini.c:469 #22 0x1200f941c in php_module_startup (sf=0x140028826, additional_modules=0x0
#22929 [Com]: pb of exit handler in OCI8 module
ID: 22929 Comment by: michael dot mauch at gmx dot de Reported By: soula at lifl dot fr Status: Open Bug Type: OCI8 related Operating System: tru64 PHP Version: 4.3.2RC1 New Comment: Yes, I see this too on Linux (latest CVS with #undef HAVE_OCI8_SHARED_MODE in oci8.c). # php -r 'if(!extension_loaded(oci8)) dl(oci8.so); print_r(ocilogon(user,pw));' Resource id #6zsh: segmentation fault (core dumped) php -r Previous Comments: [2003-03-27 09:45:46] soula at lifl dot fr I use php4-STABLE-200303241630 version, Oracle-8.1.7 and Tru64/5.1 . Note: For technical reason, we have clear the OCI_SHARED in the OCI8 initialize call (cf. #22927) The Oracle client (libclntsh.so) set a exit handler via atexit() when we connect DB. But PHP unload the module and le library before exiting and so the handler doesn't exist any more and cause a SIGSEGV. The solution we found is either commenting the dlclose() in zend_API.c or compiling OCI8 module in static. Here the compilation config : Configure Command = './configure' '--prefix=/usr/local/php-200303241630-ap1' '--enable-memory-limit' '--enable-shared' '--enable-sockets' '--enable-trans-sid' '--enable-debug' '--with-config-file-path=/usr/local/lib' '--with-apxs=/usr/local/apache/bin/apxs' '--enable-debugger=yes' '--enable-safe-mode' '--with-exec-dir=/usr/bin' '--with-mod_charset' '--with-openssl' '--with-bz2' '--with-zlib-dir' '--with-gettext' '--with-kerberos' '--with-regex=system' '--with-zlib' '--with-gd=shared' '--with-jpeg-dir=/usr/local/jpeg/lib' '--with-png-dir=/usr/local/lib' '--with-xpm-dir=/usr/local/lib' '--with-oci8=shared,/usr/oracle/product/8.1.6' '--with-ldap=shared' '--with-mysql=shared,/usr/local/mysql' '--with-pgsql=shared,/usr/local/pgsql' Sincerly, -- Julien -- Edit this bug report at http://bugs.php.net/?id=22929edit=1
#22884 [Com]: something strange with strchr
ID: 22884 Comment by: michael dot mauch at gmx dot de Reported By: sebastien at mouzaia dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: linux PHP Version: 4.3.1 New Comment: Does your copy of the manual also have the sentence: If needle contains more than one character, the first is used. Previous Comments: [2003-03-26 02:52:11] sebastien at mouzaia dot com Hello Moriyoshisan I know the manual by hart :-) I read in it: This function returns the portion of haystack which starts at the last occurrence of needle and goes until the end of haystack. In my sample, it prints wings if I use the word drawings and what is expected, /wip/drazings if I use the word drazings. This is not a bug ? Thanks for your consideration. [2003-03-25 18:06:08] [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 See http://www.php.net/manual/en/function.strrchr.php. As described in the documentation, strrchr() doesn't work in the opposite way of strchr(). [2003-03-25 17:49:59] sebastien at mouzaia dot com ? print(phpversion().'br'); $string = public_html/concepts/2L_vuda_dupont/wip/drawings; $return = strrchr($string,'wip/'); print($return.'br'); // print wings WHY ??? print(hr); $string = public_html/concepts/2L_vuda_dupont/wip/drazings; $return = strrchr($string,'wip/'); // print /wip/drazings(OK) print($return.'br') // tested on a 4.3.1 linux and on a 4.3.0 windows ? -- Edit this bug report at http://bugs.php.net/?id=22884edit=1
#22796 [Com]: -r option: no error messages unless display_startup_errors = On
ID: 22796
Comment by: michael dot mauch at gmx dot de
Reported By: gk at proliberty dot com
Status: Feedback
Bug Type: CGI related
Operating System: linux RH 7.2
PHP Version: 4CVS-2003-03-19 (stable)
New Comment:
With php4-STABLE-200303241430 (and with 4.3.1), I can get even three
error messages for the same error.
# sapi/cli/php -c php.ini-dist -r 'f();'
Command line code(1) : Fatal error - Call to undefined function: f()
# sapi/cli/php -c php.ini-recommended -r 'f();'
PHP Fatal error: Call to undefined function: f() in Command line code
on line 1
Command line code(1) : Fatal error - Call to undefined function: f()
# sed 's/\(display_.*errors = \)Off/\1On/' php.ini-recommended
php.ini-display-errors
# sapi/cli/php -c php.ini-display-errors -r 'f();'
PHP Fatal error: Call to undefined function: f() in Command line code
on line 1
Command line code(1) : Fatal error - Call to undefined function: f()
Fatal error: Call to undefined function: f() in Command line code on
line 1
This last php.ini is with display_errors and display_startup_errors =
On.
The message starting with Fatal error: goes to stdout, the other two
to stderr.
Previous Comments:
[2003-03-24 04:12:26] [EMAIL PROTECTED]
And get first the latest stable snapshot again.
[2003-03-24 04:11:54] [EMAIL PROTECTED]
# php -r f();
Command line code(1) : Fatal error - Call to undefined function: f()
This is what I get when using the php.ini-dist from the latest stable
CVS snapshot.
As you can see, we get totally different style of error
messages too.
Please try with the plain, unmodified php.ini-dist instead of your
current php.ini.
[2003-03-24 02:11:34] gk at proliberty dot com
I split this bug into two; changed the title to better reflect what I
have learned:
it is possible to work around this bug by changing the default value of
display_startup_errors in php.ini:
---
#default value
#display_startup_errors = Off
display_startup_errors = On
---
Now I get the proper error message:
[EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -r f();
Fatal error: Call to undefined function: f() in Command line code on
line
Following sniper's advice of using -n to prevent reading php.ini has
the same effect for me as display_startup_errors = Off; apparently it
doesn't have the same result for sniper. Odd.
[2003-03-21 20:09:38] gk at proliberty dot com
I built it again, per your instructions and get the same result:
[EMAIL PROTECTED] php4-STABLE-200303210630]# sapi/cli/php -n -r
require('/htdocs/common/test/junk/junk.php');
begin
[EMAIL PROTECTED] php4-STABLE-200303210630]#
Do I need a more recent snapshot than that?
I'm using the same test file:
/htdocs/common/test/junk/junk.php:
?php
echo begin\n;
f(); // undefined function; fatal error
echo end\n;
?
[2003-03-21 17:13:42] [EMAIL PROTECTED]
Try this with latest stable snapshot:
# rm config.cache
# ./configure --disable-all --disable-cgi make clean make
# sapi/cli/php -n -r require('test.php');
I think you're just doing something wrong / have something
setup very differently in your server..
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/22796
--
Edit this bug report at http://bugs.php.net/?id=22796edit=1
#22795 [Com]: C compiler failed:cannot create executable
ID: 22795 Comment by: michael dot mauch at gmx dot de Reported By: pnocq at yahoo dot com Status: Open Bug Type: Compile Failure Operating System: Solaris 7(sparc) PHP Version: 4.3.0 New Comment: values-Xa.o should come with your Solaris, see e.g. http://www.netsys.com/sunmgr/1996-07/msg00034.html and http://www.science.uva.nl/pub/solaris/solaris2/Q6.2.html. Also see http://www.php.net/manual/en/install.solaris.php for further install prerequisites. Previous Comments: [2003-03-19 18:36:02] pnocq at yahoo dot com I try also the last release from CVS and this is the same error and the same config.log [2003-03-19 18:27:54] pnocq at yahoo dot com trying to install PHP4.3.0 get the error below # ./configure --with-mysql=/usr/slocal/mysql --with-nsapi=/web/netscape/suitespot/ --enable-track-vars --enable-libgcc creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.7 Updated php_version.h checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. When I do : # gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/3.2.2/specs Configured with: ../configure --disable-nls --with-ld=/usr/ccs/bin/ld --with-as=/usr/ccs/bin/as Thread model: posix gcc version 3.2.2 So I think that gcc could work...I looked at config.log and see : configure:1944: gcc -o conftestconftest.c 15 ld: fatal: file values-Xa.o: cannot open file: No such file or directory ld: fatal: File processing errors. No output written to conftest I don't find conftest.c or values-Xa.o I dont understand..if someone could help me -- Edit this bug report at http://bugs.php.net/?id=22795edit=1
#22770 [Com]: Make fail after config with oracle
ID: 22770 Comment by: michael dot mauch at gmx dot de Reported By: oyo37503 at hotmail dot com Status: Open Bug Type: Oracle related Operating System: Redhat Linux 8 PHP Version: 4.3.1 New Comment: Set your --with-oracle=... to $ORACLE_HOME, which is probably /opt/oracle/product/8.1.7 . Probably you want to use --with-oci8 instead of --with-oracle. See http://www.php.net/manual/en/ref.oci8.php for details. Previous Comments: [2003-03-18 12:06:05] oyo37503 at hotmail dot com I was install oracle 8.1.7 client on /opt/oracle and try to config php to support oracle, by use option --with-oracle=/opt/oracle # ./configure --with-oracle=/opt/oracle --with-apache=../apache.version --enable-track-vars # make after make it show error /usr/local/src/php-4.3.1/ext/oracle/php_oracle.h:23:20: ocidfn.h: No such file or directory /usr/local/src/php-4.3.1/ext/oracle/php_oracle.h:24:20: ociapr.h: No such file or directory In file included from /usr/local/src/php-4.3.1/ext/oracle/oracle.c:40: /usr/local/src/php-4.3.1/ext/oracle/php_oracle.h:69: parse error before Lda_Def and more .. how can I fix this problem? Thank you.. Anan Ananthasri Thailand. -- Edit this bug report at http://bugs.php.net/?id=22770edit=1
#22521 [Opn]: Immediate coredump --with-oci8=shared
ID: 22521 User updated by: michael dot mauch at gmx dot de Reported By: michael dot mauch at gmx dot de Status: Open Bug Type: OCI8 related Operating System: Linux -PHP Version: 4CVS-2003-03-03 (stable) +PHP Version: 4.3.2RC1 New Comment: Updating version number. Previous Comments: [2003-03-03 13:53:18] michael dot mauch at gmx dot de With current stable CVS, I get an immediate coredump on Apache's or PHP's startup (e.g. php -i). configure --with-apxs --with-oci8=shared --enable-debug If I comment out the line AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) in ext/oci/config.m4, it works (but that's of course not a real fix). (gdb) bt #0 0x40690b06 in sskgmstat () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #1 0x4068ec9f in skgmidrealm () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #2 0x4068eaaf in skgmlocate () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #3 0x4068e523 in skgmcrone () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #4 0x4068fae6 in skgmcrmany () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #5 0x4068c955 in skgmcreate () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #6 0x40435f04 in kgupmcreate_sga () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #7 0x40433a98 in kgup_startup () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #8 0x403ec883 in kpushInit () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #9 0x40694719 in kpummpin () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #10 0x403ec924 in kpupin () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #11 0x404142aa in OCIInitialize () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #12 0x4027e4d7 in zm_startup_oci (type=1, module_number=10) at /usr/local/src/php-cvs/php4/ext/oci8/oci8.c:489 #13 0x080b0875 in php_dl (file=0x81d29c0, type=1, return_value=0xbfffe6ac) at /usr/local/src/php-cvs/php4/ext/standard/dl.c:238 #14 0x08138a2a in php_load_function_extension_cb (arg=0x81d29c0) at /usr/local/src/php-cvs/php4/main/php_ini.c:216 #15 0x08166d8f in zend_llist_apply (l=0x81c9a5c, func=0x8138a00 php_load_function_extension_cb) at /usr/local/src/php-cvs/php4/Zend/zend_llist.c:189 #16 0x08139495 in php_ini_delayed_modules_startup () at /usr/local/src/php-cvs/php4/main/php_ini.c:469 #17 0x08133edf in php_module_startup (sf=0x81c86c0, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-cvs/php4/main/main.c:1218 #18 0x08189db8 in main (argc=2, argv=0xbfffe934) at /usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481 #19 0x4013f8c1 in __libc_start_main (main=0x8189c84 main, argc=2, argv=0xbfffe934, init=0x806132c _init, fini=0x818b184 _fini, rtld_fini=0x4000a914 _dl_fini, stack_end=0xbfffe92c) at ../sysdeps/generic/libc-start.c:92 -- Edit this bug report at http://bugs.php.net/?id=22521edit=1
#22684 [Fbk-Opn]: Unhappy with strtoll declaration in bundled libmysql
ID: 22684 User updated by: michael dot mauch at gmx dot de Reported By: michael dot mauch at gmx dot de -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Tru64 4.0g PHP Version: 4.3.2RC1 New Comment: No, MySQL 3.23.55 shows the same error = bogus (but the Status box only has Open or Close, so I have to leave it open). Previous Comments: [2003-03-13 17:20:11] [EMAIL PROTECTED] Do you get the same error when you compile mysql? [2003-03-13 15:24:21] michael dot mauch at gmx dot de cc: Error: /house/elmicha/local/src/php-4.3.2RC1/ext/mysql/libmysql/strto.c, line 68: In this declaration, the type of strtoll is not compatible with the type of a previous declaration of strtoll at line number 44 in file /usr/include.dtk/stdlib.h. (notcompat) function (const char *nptr,char **endptr,int base) ^ The declaration of strtoll() in stdlib.h is: extern long long int strtoll( const char * /*restrict*/ __nptr, char ** /*restrict*/ __endptr, int __base); The declaration in strto.c is expanded to: longlong strtoll (const char *nptr,char **endptr,int base) % cc -V: Compaq C V6.5-207 (dtk) on Digital UNIX V4.0G (Rev. 1530) Compiler Driver V6.5-207 (dtk) (dtk) cc Driver http://bugs.php.net/bug.php?id=18815 looks similar, but it's closed (and on Linux). -- Edit this bug report at http://bugs.php.net/?id=22684edit=1
#22684 [NEW]: Unhappy with strtoll declaration in bundled libmysql
From: michael dot mauch at gmx dot de Operating system: Tru64 4.0g PHP version: 4.3.2RC1 PHP Bug Type: Compile Failure Bug description: Unhappy with strtoll declaration in bundled libmysql cc: Error: /house/elmicha/local/src/php-4.3.2RC1/ext/mysql/libmysql/strto.c, line 68: In this declaration, the type of strtoll is not compatible with the type of a previous declaration of strtoll at line number 44 in file /usr/include.dtk/stdlib.h. (notcompat) function (const char *nptr,char **endptr,int base) ^ The declaration of strtoll() in stdlib.h is: extern long long int strtoll( const char * /*restrict*/ __nptr, char ** /*restrict*/ __endptr, int __base); The declaration in strto.c is expanded to: longlong strtoll (const char *nptr,char **endptr,int base) % cc -V: Compaq C V6.5-207 (dtk) on Digital UNIX V4.0G (Rev. 1530) Compiler Driver V6.5-207 (dtk) (dtk) cc Driver http://bugs.php.net/bug.php?id=18815 looks similar, but it's closed (and on Linux). -- Edit bug report at http://bugs.php.net/?id=22684edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22684r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22684r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22684r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22684r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22684r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22684r=support Expected behavior: http://bugs.php.net/fix.php?id=22684r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22684r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22684r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22684r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22684r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22684r=dst IIS Stability: http://bugs.php.net/fix.php?id=22684r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22684r=gnused
#22635 [Com]: 1.1.1970 24 hours in [gm]mktime
ID: 22635
Comment by: michael dot mauch at gmx dot de
Reported By: jsteen at timecom dot com
Status: Open
Bug Type: Date/time related
Operating System: win32
PHP Version: 4.3.1
New Comment:
Please read the fine manual. From
http://www.php.net/manual/en/function.mktime.php:
on systems where time_t is a 32bit signed integer, as most common
today, the valid range for year is somewhere between 1902 and 2037.
If you are using values outside this range, you get undefined
behaviour.
Previous Comments:
[2003-03-12 03:34:12] jsteen at timecom dot com
WE F...ING KNOW mktime, gmmktime etc. WORK FINE ON *NIX!
THIS IS A WIN REPORT!
[flame: on]
is it a new policy on bugs.php.net to NOT read post
headers/declarations, write works fine with linux as answer, and put
the bug on 'BOGUS'?
i'm among the many users that are pissed that all the
timestamp-functions are buggy on win. ok. fine. deal. but then please
take our reports seriously and put a proper comment in the man! i
really begin to wonder whether you're not just too lazy to seriously
deal with it if i get this sorts of answers.
[flame: off]
so why does 1.1.1970 not have 24h?
please omit any of the usual answers, like:
- works fine for linux
- blame MS
[2003-03-11 11:15:13] [EMAIL PROTECTED]
Works fine with Linux.
[2003-03-11 07:53:26] jsteen at timecom dot com
1.1.1970 does not have 24 hours!
-
for ($i = 1 ; $i 365; $i++){
$date = mktime(0,0,0,1,$i,1970);
$date1 = mktime(0,0,0,1,$i+1,1970);
echo br $i: .gmdate(Y m d, $date) . ;
echo ($date1 - $date ) /3600 . h;
}
-
1: 23.000278 h
2: 1970 01 01 24 h
3: 1970 01 02 24 h
4: 1970 01 03 24 h
...
-
for ($i = 1 ; $i 365; $i++){
$date = gmmktime(0,0,0,1,$i,1970);
$date1 = gmmktime(0,0,0,1,$i+1,1970);
echo br $i: .gmdate(Y m d, $date) . ;
echo ($date1 - $date ) /3600 . h;
}
-
1: 24.000278 h
2: 1970 01 02 24 h
3: 1970 01 03 24 h
4: 1970 01 04 24 h
...
-
--
Edit this bug report at http://bugs.php.net/?id=22635edit=1
#22521 [NEW]: Immediate coredump --with-oci8=shared
From: michael dot mauch at gmx dot de Operating system: Linux PHP version: 4CVS-2003-03-03 (stable) PHP Bug Type: OCI8 related Bug description: Immediate coredump --with-oci8=shared With current stable CVS, I get an immediate coredump on Apache's or PHP's startup (e.g. php -i). configure --with-apxs --with-oci8=shared --enable-debug If I comment out the line AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ]) in ext/oci/config.m4, it works (but that's of course not a real fix). (gdb) bt #0 0x40690b06 in sskgmstat () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #1 0x4068ec9f in skgmidrealm () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #2 0x4068eaaf in skgmlocate () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #3 0x4068e523 in skgmcrone () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #4 0x4068fae6 in skgmcrmany () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #5 0x4068c955 in skgmcreate () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #6 0x40435f04 in kgupmcreate_sga () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #7 0x40433a98 in kgup_startup () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #8 0x403ec883 in kpushInit () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #9 0x40694719 in kpummpin () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #10 0x403ec924 in kpupin () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #11 0x404142aa in OCIInitialize () from /mnt/app/oracle/product/8.1.6/lib/libclntsh.so.8.0 #12 0x4027e4d7 in zm_startup_oci (type=1, module_number=10) at /usr/local/src/php-cvs/php4/ext/oci8/oci8.c:489 #13 0x080b0875 in php_dl (file=0x81d29c0, type=1, return_value=0xbfffe6ac) at /usr/local/src/php-cvs/php4/ext/standard/dl.c:238 #14 0x08138a2a in php_load_function_extension_cb (arg=0x81d29c0) at /usr/local/src/php-cvs/php4/main/php_ini.c:216 #15 0x08166d8f in zend_llist_apply (l=0x81c9a5c, func=0x8138a00 php_load_function_extension_cb) at /usr/local/src/php-cvs/php4/Zend/zend_llist.c:189 #16 0x08139495 in php_ini_delayed_modules_startup () at /usr/local/src/php-cvs/php4/main/php_ini.c:469 #17 0x08133edf in php_module_startup (sf=0x81c86c0, additional_modules=0x0, num_additional_modules=0) at /usr/local/src/php-cvs/php4/main/main.c:1218 #18 0x08189db8 in main (argc=2, argv=0xbfffe934) at /usr/local/src/php-cvs/php4/sapi/cli/php_cli.c:481 #19 0x4013f8c1 in __libc_start_main (main=0x8189c84 main, argc=2, argv=0xbfffe934, init=0x806132c _init, fini=0x818b184 _fini, rtld_fini=0x4000a914 _dl_fini, stack_end=0xbfffe92c) at ../sysdeps/generic/libc-start.c:92 -- Edit bug report at http://bugs.php.net/?id=22521edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22521r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22521r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22521r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22521r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22521r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22521r=support Expected behavior: http://bugs.php.net/fix.php?id=22521r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22521r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22521r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22521r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22521r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22521r=dst IIS Stability: http://bugs.php.net/fix.php?id=22521r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22521r=gnused
#22415 [Com]: strtolower()
ID: 22415 Comment by: michael dot mauch at gmx dot de Reported By: admin at naxe dot net Status: Open Bug Type: Strings related Operating System: Linux Red Hat v7.3 PHP Version: 4.3.0 New Comment: Your LANG [EMAIL PROTECTED] uses the ISO-8859-15 character set - that's the one with the Euro sign. At character position 180 it has a Z with a little v (caron) above, and at character position it has the z with the little v (caron) above - so strtolower() is correct. See man iso-8859-15, if your system has that man page. Previous Comments: [2003-02-25 08:58:51] admin at naxe dot net Hi, thanks for your replies. As you can see on my phpinfo() I have this environment setting: LANG [EMAIL PROTECTED] I think it was from the Red Hat v7.3 installation. I tested the script, as you suggested, with LANG=C (the same language settings that I have on the other server) and it works. But I think that this behaviour is still very strange, why my setting of it_IT will produce this problem: strtolower(chr(180)) results in chr(184)? I think this is an important issue for code portability. Thanks. [2003-02-25 08:24:28] [EMAIL PROTECTED] And also try inserting setlocale(LC_CTYPE, C); on top of your script. [2003-02-25 08:20:41] [EMAIL PROTECTED] strtolower's behaviour depends on the locale settings (LC_CTYPE), and the settings are different on each server, so the reported behaviour seems to be quite expectable for me. Setting LANG=C would solve your problem? [2003-02-25 08:18:31] [EMAIL PROTECTED] from the manual page on strtolower: Note that 'alphabetic' is determined by the current locale. are you sure that this is not just a locale settings problem? [2003-02-25 08:05:45] admin at naxe dot net Hi, I make massive use of PHP so I tested many times before report this that I think is a bug: This is the example script: $ch=chr(180); echo $ch; echo strtolower($ch); echo strtoupper($ch); The result will be this: ´¸´ instead of this: ´´´ This bug seems that occur only with PHP v4.3.0, I tested it also with PHP v4.2.2 ad it was ok. I uploaded the script on two different server of mine: http://www.dez.it/test/strtolower.php here with PHP v4.2.2 (http://www.dez.it/test/phpinfo.php for phpinfo) http://www.postare.it/test/strtolower.php here with PHP v4.3.0 (http://www.postare.it/test/phpinfo.php for phpinfo) As said the first link works ok, the seconds has this strange behaviour, it modify chr(180) to chr(184). I haven't tested with all the ascii set. I hope this report was useful. Good debug. -- Edit this bug report at http://bugs.php.net/?id=22415edit=1
#22393 [Com]: __FILE__, __LINE__ as default parameter value
ID: 22393
Comment by: michael dot mauch at gmx dot de
Reported By: tom dot polak at post dot cz
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows, but all
PHP Version: 4.2.3
New Comment:
Have a look at
http://www.php.net/manual/en/function.set-error-handler.php, then
use an error handler like in the example:
// error handler function
function myErrorHandler ($errno, $errstr, $errfile, $errline) {
print(Error {$msg} in file {$errfile} on line {$errline}\n);
}
where you get $errfile and $errline without problems. For your extra
errors, you can use the trigger_error function.
Previous Comments:
[2003-02-24 08:11:18] tom dot polak at post dot cz
Hello,
First, I have found similar request as #13944,
but there is NO SOLUTION EXPLAINED, only closed.
If this request is solved, then my request is solved too,
but how was #13944 solved?
I am trying to write error handler function as follows:
function ErrorHandler($msg,$file=__FILE__,$line=__LINE__){
print(Error {$msg} in file {$file} on line {$line}\n);
}
which can be called from any php script when error occurs:
...
if($somethingwrong){
ErrorHandler(something wrong);
}
I can to see the $file and $line pointing to the place,
from which is ErrorHanlder function called.
But currently I see allwys the same file and line
of the ErrorHandler function itself.
This request is based on big amount of php script files,
where is not so simple to found, where the error condition
occurs. Because the $msg itself is often not enough to
explain the point in source code.
Secondary, I need to have own errorhandler, because
using some features when the error appears in SQL command,
there is more additional information displayed (not
showed in example above, because is not relevant to this request). I am
logging errors by its type to several
locations, conditionally email it to response admin
and other things.
Because of hunderts calls of ErrorHandler, using __FILE__
and __LINE__ is very time and place consuming.
With hope, that this description is understandable,
even my poor english knowledge.
Best regards,
Tomas Polak
[EMAIL PROTECTED]
--
Edit this bug report at http://bugs.php.net/?id=22393edit=1
#22406 [Com]: syntax errors in php_imap.c
ID: 22406 Comment by: michael dot mauch at gmx dot de Reported By: rbyrns at wenaasusa dot com Status: Open Bug Type: IMAP related Operating System: Free BSD PHP Version: 4.3.1 New Comment: Please give some more info! You don't say which of the source files you used (a release? a snapshot? which?), you don't say which imap version you're using. Previous Comments: [2003-02-24 16:48:24] rbyrns at wenaasusa dot com Using source posted at php.net on Feb 17 Configure seems to go well but make returns: /usr/home/rex/php-4.3.1/ext/imap/php_imap.c:339: syntax error before `QUOTALIST' /usr/home/rex/php-4.3.1/ext/imap/php_imap.c: In function `mail_getquota': /usr/home/rex/php-4.3.1/ext/imap/php_imap.c:344: `qlist' undeclared (first use in this function) /usr/home/rex/php-4.3.1/ext/imap/php_imap.c:344: (Each undeclared identifier is reported only once /usr/home/rex/php-4.3.1/ext/imap/php_imap.c:344: for each function it appears in.) /usr/home/rex/php-4.3.1/ext/imap/php_imap.c: In function `zif_imap_get_quota': /usr/home/rex/php-4.3.1/ext/imap/php_imap.c:869: `SET_QUOTA' undeclared (first use in this function) /usr/home/rex/php-4.3.1/ext/imap/php_imap.c: In function `zif_imap_get_quotaroot': /usr/home/rex/php-4.3.1/ext/imap/php_imap.c:903: `SET_QUOTA' undeclared (first use in this function) -- Edit this bug report at http://bugs.php.net/?id=22406edit=1
#19714 [Com]: Using default user in OCI8 functions
ID: 19714 Comment by: michael dot mauch at gmx dot de Reported By: jomar at hafro dot is Status: Assigned Bug Type: OCI8 related Operating System: SunOS PHP Version: 4.2.2 Assigned To: maxim New Comment: The bug database is not a user support forum. Have a look at http://www.php.net/support.php to find the newsgroups and mailing lists where you can ask questions. Also see the user notes on the manual page http://www.php.net/manual/en/function.ocilogon.php, there are many examples. Previous Comments: [2003-02-23 05:57:54] leopoldo dot antonetti at globalvalue dot it Good morning, we are starting to use PHP 4.1.1 on an HP ALPHA system with OPENVMS, ORALCE8i and APACHE. I see that the OCILogon /connect-string doesn't works. What is the correct syntax? is it a bug? is there any workaround? must I upgrade the version of PHP to a new one that works? Many thanks Leopoldo Antonetti Global Value Services S.p.A Midrange Technologies VMS System Technologies Tel. +39 01100.53258 MailTo:[EMAIL PROTECTED] [2003-02-23 05:55:57] leopoldo dot antonetti at globalvue dot it Good morning, we are starting to use PHP 4.1.1 on an HP ALPHA system with OPENVMS, ORALCE8i and APACHE. I see that the OCILogon /connect-string doesn't works. What is the correct syntax? is it a bug? is there any workaround? must I upgrade the version of PHP to a new one that works? Many thanks Leopoldo Antonetti Global Value Services S.p.A Midrange Technologies VMS System Technologies Tel. +39 01100.53258 MailTo:[EMAIL PROTECTED] [2002-11-11 13:08:10] [EMAIL PROTECTED] Oracle does not seem to read user/pass if it is passed to it as the username via OCILogon. When second parameter is an empty strng OCISessionBegin() complains about the NULL password Given while if username contains '/' it is 1) unparsed by API, 2) will still leave OCISessionBegin() without a password. I will take a look at it. [2002-10-02 08:15:44] [EMAIL PROTECTED] nevermind..should have read your report 2 times instead of one time. [2002-10-02 08:14:41] [EMAIL PROTECTED] You should be setting those environment variables in the SHELL not in apache httpd.. See http://www.php.net/manual/en/ref.oci8.php for more information. 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/19714 -- Edit this bug report at http://bugs.php.net/?id=19714edit=1
#22265 [Com]: PHP fails to pass variables randomly
ID: 22265 Comment by: michael dot mauch at gmx dot de Reported By: andy at thegartsidegroup dot com Status: Feedback Bug Type: IIS related Operating System: Windows 2000 PHP Version: 4.3.1 New Comment: php4-STABLE-200302232030 doesn't work here (Linux) as a CGI: % echo '?php echo hi\n;?' | sapi/cgi/php Status: 404 Content-type: text/html X-Powered-By: PHP/4.3.2-dev No input file specified. No safe_mode or open_base_dir in effect (just php.ini-dist or php.ini-recommended). php-4.3.1 works fine here. Previous Comments: [2003-02-23 05:17: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 [2003-02-19 15:53:27] andy at thegartsidegroup dot com I have since learned that I actually had two separate problems happening. One was entirely my own fault for not being up-to-date with PHP. The default setting for register_globals has changed since I learned php coding. I might point out that there is no mention of this in the install.txt that ships with the download. Anyway, I have learned something new and better coding and security practice. The original problem remains. I altered the permissions for a few directories (so that other users couldn't mess about with a few programs) and a working version of PHP4 stopped working. Mainly giving the error message No input file specified but also occasionally a 404 error. Changing the file permissions back didn't fix it. This is why I think there may be a bug. I note that I haven't found anyone who has this problem on the Internet who has managed to resolve it. Sorry for the confusion in the first post. The re-install actually worked afterall. Andy [2003-02-18 23:33:05] [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 Some problems are fixed in the CVS which were not in 4.3.1.. So please give it a go. Also, you said simple ?php phpinfo(); ? script works always? If the snapshot doesn't help, can you try reducing the problematic scripts to bare minimum which still causes this? Try to see what is common to all of them. [2003-02-18 02:02:34] andy at thegartsidegroup dot com PHP 4.3.0 was working fine on W2kSP3 and IIS5 with latest security rollup and with MySQL 3.23.50. It is a CGI installation. Then I added a new user and changed some file permissions. These changes were very careful and I made sure that IUSR_mymachine had read and execute permissions to all required directories, as per the install.txt readme. My IIS 5 web-development environment went crazy. Sometimes it worked, sometimes it didn't. ? phpinfo(); ? works fine as a test file. Sometimes I get a 404 message for files I know are there, other times I get a complete failure to retrieve variables from the database (but not the error message that I wrote if the DB connect failed) These files worked perfectly just a few days ago. It no longer seems to support sessions either. I spent days and days scouring the php sites, looking for a solution - nothing. I am quite an expert at php and IIS 5 configuration settings by now, so I have checked them repeatedly. Eventually, I gave up. I repartitioned my hard-drive and re-installed Windows 2000 SP3. This time, I added all the users I needed and set the permissions before installing anything. I re-installed IIS and the rollup package. I re-installed MySQL and tested it extensively. I went and got the latest (4.3.1) php installer.exe and re-installed windows. SAME PROBLEM!!! I reset all the permissions on all directories, sub-directories and files on my entire machine to full-control everyone NO SUCCESS! Random failures, mostly to do with variables disappearing in forms or in queries to the databases. I am desperate now. I NEED to do work, not chase this anymore. I'll see how this goes today USA time, then I'll have to try rebuilding AGAIN with no extra users and default file permissions. This is obviously not a very good solution. Thanks, Andrew Gartside (Canberra Australia) -- Edit this bug report at http://bugs.php.net/?id=22265edit=1
#21912 [Com]: getimagesize() on remote images fails sometimes..
ID: 21912 Comment by: michael dot mauch at gmx dot de Reported By: tozz at kijkt dot tv Status: Assigned Bug Type: GetImageSize related Operating System: Linux PHP Version: 4.3.1-dev Assigned To: wez New Comment: Wez apparently fixed this one, too - php4-STABLE-200302220630 works for both pictures. Previous Comments: [2003-02-17 18:23:04] [EMAIL PROTECTED] To tozz at kijkt dot tv: The difference is that we have a new streams abstraction layer which allows GetImageSize() to work which whatever can be treated as a file. To michael dot mauch at gmx dot de: That was what i expected. And it means there is a problem with the streams stuff. [2003-02-17 17:37:35] michael dot mauch at gmx dot de Yes, it's the same here - on the local servers it works with both images, but it doesn't work with the 00645.jpg when I put it on another remote server. When I change line 387 of ext/standard/image.c: if ((marker = php_stream_getc(stream)) == EOF) into marker = php_stream_getc(stream); fprintf(stderr,%0x ,marker); if (marker == EOF) I see e0 ff ed ff ee ff db ff c0 when the image is served from localhost and only e0 ff ed 68 or e0 ff ed 64 when fetching from the remote servers. That looks strange, but I'm afraid I don't understand what's going on here. [2003-02-08 05:41:17] [EMAIL PROTECTED] I suppose ther is another problem :-) When i download the image and put it on one of my local servers it works: [EMAIL PROTECTED] php4-HEAD]$ php -r 'print_r(getimagesize($argv[1]));' -- http://zaphod.boerger.de/php/ext/exif/test/bug21912.jpg Array ( [0] = 389 [1] = 500 [2] = 2 [3] = width=389 height=500 [bits] = 8 [channels] = 3 [mime] = image/jpeg ) [EMAIL PROTECTED] php4-HEAD]$ php -r 'var_dump(getimagesize($argv[1]));' -- http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg bool(false) [2003-01-28 13:52:36] tozz at kijkt dot tv Yes, it has indeed something to do with the image. If I take another image it works fine! But there must be some difference in the PHP versions since the 2nd pictures only works with PHP 4.1.2, and not with the latest PHP version. [2003-01-28 13:26:00] michael dot mauch at gmx dot de php -r '$size = getimagesize(http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg;); print_r($size); echo \n;' works without problems here (PHP 4.3.0), while php -r '$size = getimagesize(http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg;); print_r($size); echo \n;' prints nothing. ImageMagick's identify sees some strange ipct data in the second image; probably these make getimagesize() misbehave. 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/21912 -- Edit this bug report at http://bugs.php.net/?id=21912edit=1
#22135 [Com]: PHP confused by America/Los Angeles timezone
ID: 22135
Comment by: michael dot mauch at gmx dot de
Reported By: vaughan at ucla dot edu
Status: Open
Bug Type: Date/time related
Operating System: Linux (debian)
PHP Version: 4.2.3
New Comment:
I don't see a /usr/share/zoneinfo/US/Los_Angeles on Debian, only
America/Los_Angeles (and US/Pacific). So I suggest you try again with
America/Los_Angeles.
Previous Comments:
[2003-02-22 11:37:58] vaughan at ucla dot edu
no, TZ is not being set in httpd.conf nor in apachectl.
Experiment #1
What happens if we use putenv(TZ=US/Los_Angeles)?
the script:
?
print(server timezone is: . getenv('TZ') . br\n);
print(server time is: . date(F j, Y, g:i a) . br\n);
print(changing server time zone to US/Los_Angelesbr\n);
putenv(TZ=US/Los_Angeles);
print(new server time is: . date(F j, Y, g:i a) . br\n);
print(new server timezone for this script is: . getenv('TZ'));
?
here's the output, with the incorrect times:
server timezone is: America/Los Angeles
server time is: February 22, 2003, 5:01 pm
changing server time zone to US/Los_Angeles
new server time is: February 22, 2003, 5:01 pm
new server timezone for this script is: US/Los_Angeles
output of date(T):US/Los_Angeles
Experiment # 2:
I also tried putting
SetEnv US/Pacific
into httpd.conf.
this script:
print(server timezone is: . getenv('TZ') . br\n);
print(server time is: . date(F j, Y, g:i a) . br\n);
print(changing server time zone to US/Pacificbr\n);
putenv(TZ=US/Pacific);
print(new server time is: . date(F j, Y, g:i a) . br\n);
print(new server timezone for this script is: . getenv('TZ'));
produces this output:
server timezone is: US/Pacific
server time is: February 22, 2003, 5:29 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:29 am
new server timezone for this script is: US/Pacific
output of date(T):PST
In this case, PHP picks up the US/Pacific timezone from the
environment, but gets the time wrong!
Experiment # 3
try with SetEnv = US/Los_Angeles in httpd.conf
same script as #2, produces bad output:
server timezone is: US/Los_Angeles
server time is: February 22, 2003, 5:34 pm
changing server time zone to US/Pacific
new server time is: February 22, 2003, 9:34 am
new server timezone for this script is: US/Los_Angeles
output of date(T):PST
So it seems to be the case that the ONLY way to get PHP to have the
correct time is to use putenv(TZ=US/Pacific) in a script.
Any other ideas? Thanks for your help
[2003-02-09 16:49:25] michael dot mauch at gmx dot de
You don't have a
SetEnv TZ America/Los Angeles
in your httpd.conf, do you? Or maybe TZ is fixed in your apachectl
script?
[2003-02-09 13:54:50] vaughan at ucla dot edu
here's what I do, as root:
# export TZ='America/Los_Angeles'
# set | grep TZ
# TZ=America/Los_Angeles
# apachectl stop
/usr/sbin/apachectl stop: httpd stopped
# apachectl start
/usr/sbin/apachectl start: httpd started
output of the php script:
server timezone is: America/Los Angeles
server time is: February 9, 2003, 7:51 pm
changing server time zone to US/Pacific
new server time is: February 9, 2003, 11:51 am
new server timezone for this script is: US/Pacific
I notice that PHP does not pick up the underscore in Los_Angeles.
What I wondered was whether there's a way to do the equivalent of
putenv(TZ=US/Pacific) in php.ini?
However, I have just noticed that the time is wrong in OTRS running on
the same server -- and it is a set of perl scripts. So maybe this is
not a PHP bug at all?
[2003-02-09 12:39:25] michael dot mauch at gmx dot de
apachectl restart does not pick up the new TZ environment variable.
Did you try apachectl stop / apachectl start? I get the same results as
you with TZ=America/Los Angeles, but America/Los_Angeles or
US/Pacific work. As far as I know there's no php.ini setting that
fiddles with timezones.
[2003-02-09 10:54:54] vaughan at ucla dot edu
Yes, tzselect suggests that TZ be set as 'America/Los_Angeles'.
I did this, using export TZ='America/Los_Angeles' and restarted apache.
It made no difference to the php script output.
In other words, if php believes that the server timezone is
'America/Los_Angeles' it gives the incorrect time. But if it believes
that timezone is 'US/Pacific' it gives the correct time. However,
setting TZ to 'US/Pacific' also makes no difference to the script
output. So I'm wondering where PHP is picking up the timezone
information from and how I can get it to believe that the timezone is
'US/Pacific' from startup. Can I set that in php.ini?
(Also, there are two timezone
#18640 [Com]: Compilation with Oracle fails...
ID: 18640 Comment by: michael dot mauch at gmx dot de Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Compaq Tru64 PHP Version: 4CVS-2002-07-30 New Comment: I doubt that we had (independently) a bad ORACLE_HOME or --with-oci8, because all of the other functions were found without problems. Only the OCILob* functions were not found, because they are in libocijdbc8 (on some systems / some Oracle versions). I can't read php.dev at the moment, but will do so in a couple of hours (after work). Previous Comments: [2003-02-21 04:20:08] [EMAIL PROTECTED] Reopening since I'm about to revert the 'fix' for this. You might have used wrong path for --with-oci8 or had ORACLE_HOME pointing to wrong place..? [2002-09-09 14:18:49] [EMAIL PROTECTED] Fixed in CVS by Michael Mauch [2002-09-03 13:43:28] [EMAIL PROTECTED] Verified with PHP4.2.3RC2 [2002-08-21 05:19:01] michael dot mauch at gmx dot de These functions are in libocijdbc8. If I manually append -locijdbc8 to the failing linker command, it works. [2002-07-30 08:28:46] [EMAIL PROTECTED] I get these unresolves symbols when trying to compile PHP 4-CVS agains Oracle 8.1.6. OCILobCreateTemporary OCILobClose OCILobFreeTemporary OCILobIsTemporary OCILobOpen *** Exit 1 Stop. I don't know if this is an PHP or an Oracle-Issue, but with 4.2.0 it worked fine on that same machine and that same Oracle-Version. -- Edit this bug report at http://bugs.php.net/?id=18640edit=1
#22356 [NEW]: Cannot find file stdio.h
From: michael dot mauch at gmx dot de Operating system: Tru64 5.1 PHP version: 4CVS-2003-02-21 (stable) PHP Bug Type: Compile Failure Bug description: Cannot find file stdio.h Compilation fails both for PHP-4.3.1 and for php4-STABLE-200302211430 with the Compaq compiler. % cc -V Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732) Compiler Driver V6.3-026 (sys) cc Driver % configure --with-oci8 --prefix=/house/elmicha/spe155/build % make [...] cc -IZend/ -I/house/elmicha/local/src/php4-STABLE-200302211430/Zend/ -DPHP_ATOM_INC -I/house/elmicha/local/src/php4-STABLE-200302211430/include -I/house/elmicha/local/src/php4-STABLE-200302211430/main -I/house/elmicha/local/src/php4-STABLE-200302211430 -I/house/elmicha/local/src/php4-STABLE-200302211430/Zend -I/usr/app/oracle/product/8.1.7/rdbms/public -I/usr/app/oracle/product/8.1.7/rdbms/demo -I/house/elmicha/local/src/php4-STABLE-200302211430/ext/xml/expat -I/house/elmicha/local/src/php4-STABLE-200302211430/TSRM -g -c /house/elmicha/local/src/php4-STABLE-200302211430/Zend/zend_execute.c -o Zend/zend_execute.o echo Zend/zend_execute.lo cc -I -Isapi/cgi/ -I/house/elmicha/local/src/php4-STABLE-200302211430/sapi/cgi/ -DPHP_ATOM_INC -I/house/elmicha/local/src/php4-STABLE-200302211430/include -I/house/elmicha/local/src/php4-STABLE-200302211430/main -I/house/elmicha/local/src/php4-STABLE-200302211430 -I/house/elmicha/local/src/php4-STABLE-200302211430/Zend -I/usr/app/oracle/product/8.1.7/rdbms/public -I/usr/app/oracle/product/8.1.7/rdbms/demo -I/house/elmicha/local/src/php4-STABLE-200302211430/ext/xml/expat -I/house/elmicha/local/src/php4-STABLE-200302211430/TSRM -g -c /house/elmicha/local/src/php4-STABLE-200302211430/sapi/cgi/cgi_main.c -o sapi/cgi/cgi_main.o echo sapi/cgi/cgi_main.lo cc: Severe: /house/elmicha/local/src/php4-STABLE-200302211430/Zend/zend.h, line 35: Cannot find file stdio.h specified in #include directive. (noinclfilef) #include stdio.h -^ *** Error code 1 Stop. /usr/include/stdio.h does of course exist. Apparently this compiler doesn't like -I without arguments, just like it doesn't like empty defines (see http://bugs.php.net/bug.php?id=20752). cc -IZend/ -Isapi/cgi/ ... works fine. -- Edit bug report at http://bugs.php.net/?id=22356edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22356r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22356r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22356r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22356r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22356r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22356r=support Expected behavior: http://bugs.php.net/fix.php?id=22356r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22356r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22356r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22356r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22356r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22356r=dst IIS Stability: http://bugs.php.net/fix.php?id=22356r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22356r=gnused
#22272 [Com]: Segmentation Fault (11)
ID: 22272 Comment by: michael dot mauch at gmx dot de Reported By: webmaster at cryptpad dot com Status: Open Bug Type: Apache related Operating System: RedHat 7.2 PHP Version: 4.3.1 New Comment: /install/php-4.3.1/ is where I installed PHP from. Should it really be running the mod_php4.c file from there? mod_php4.c is a C source file, it's not executed and only shown there for reference. P.S. I also have a separate copy of apache running which is my ssl server. I tried to install PHP into that copy in the same way, and it worked fine!! Can you please make sure that the php.ini of your bad Apache references the correct extension_dir, i.e. the one that belongs to the same libphp4.so (LoadModule in httpd.conf)? Previous Comments: [2003-02-19 04:16:52] webmaster at cryptpad dot com Tried: ./configure --with-apxs=/usr/local/apache/bin/apxs with and without --with-mysql [2003-02-19 04:13:32] [EMAIL PROTECTED] What was the configure line used to configure PHP? [2003-02-19 04:02:25] webmaster at cryptpad dot com No, None. [2003-02-18 18:05:24] [EMAIL PROTECTED] Do you set any PHP settings via virtual host or .htaccess, if so, what are they? [2003-02-18 08:38:11] webmaster at cryptpad dot com Installed PHP as a DSO Module in Apache. Install went fine. Modified httpd.conf file to include LoadModule AddType declarations, then stopped and started Apache. Whenever I go to access a PHP page, it returns no data and puts the following into the apache error log: [Tue Feb 18 14:13:34 2003] [notice] child pid 9320 exit signal Segmentation fault (11) Doing a backtrace reveals the following: (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x4040c5e6 in send_php (r=0x83fa594, display_source_mode=0, filename=0x0) at /install/php-4.3.1/sapi/apache/mod_php4.c:498 498 per_dir_conf = (HashTable *) get_module_config(r-per_dir_config, php4_module); (gdb) bt #0 0x4040c5e6 in send_php (r=0x83fa594, display_source_mode=0, filename=0x0) at /install/php-4.3.1/sapi/apache/mod_php4.c:498 #1 0x4040c80e in send_parsed_php (r=0x83fa594) at /install/php-4.3.1/sapi/apache/mod_php4.c:571 #2 0x080afea3 in ap_invoke_handler () #3 0x080c4f03 in ap_some_auth_required () #4 0x080c4f64 in ap_process_request () #5 0x080bbda1 in ap_child_terminate () #6 0x080bbf4c in ap_child_terminate () #7 0x080bc0c0 in ap_child_terminate () #8 0x080bc738 in ap_child_terminate () #9 0x080bcf9b in main () #10 0x40087657 in __libc_start_main (main=0x80bcbf4 main, argc=2, ubp_av=0xb9b4, init=0x8065630 _init, fini=0x8172b40 _fini, rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb9ac) at ../sysdeps/generic/libc-start.c:129 /install/php-4.3.1/ is where I installed PHP from. Should it really be running the mod_php4.c file from there? Can anyone help? P.S. I also have a separate copy of apache running which is my ssl server. I tried to install PHP into that copy in the same way, and it worked fine!! Both Apache versions are 1.3.27 -- Edit this bug report at http://bugs.php.net/?id=22272edit=1
#21912 [Com]: getimagesize() on remote images fails sometimes..
ID: 21912 Comment by: michael dot mauch at gmx dot de Reported By: tozz at kijkt dot tv Status: Verified Bug Type: GetImageSize related Operating System: Linux PHP Version: 4.3.1-dev New Comment: Yes, it's the same here - on the local servers it works with both images, but it doesn't work with the 00645.jpg when I put it on another remote server. When I change line 387 of ext/standard/image.c: if ((marker = php_stream_getc(stream)) == EOF) into marker = php_stream_getc(stream); fprintf(stderr,%0x ,marker); if (marker == EOF) I see e0 ff ed ff ee ff db ff c0 when the image is served from localhost and only e0 ff ed 68 or e0 ff ed 64 when fetching from the remote servers. That looks strange, but I'm afraid I don't understand what's going on here. Previous Comments: [2003-02-08 05:41:17] [EMAIL PROTECTED] I suppose ther is another problem :-) When i download the image and put it on one of my local servers it works: [marcus@zaphod php4-HEAD]$ php -r 'print_r(getimagesize($argv[1]));' -- http://zaphod.boerger.de/php/ext/exif/test/bug21912.jpg Array ( [0] = 389 [1] = 500 [2] = 2 [3] = width=389 height=500 [bits] = 8 [channels] = 3 [mime] = image/jpeg ) [marcus@zaphod php4-HEAD]$ php -r 'var_dump(getimagesize($argv[1]));' -- http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg bool(false) [2003-01-28 13:52:36] tozz at kijkt dot tv Yes, it has indeed something to do with the image. If I take another image it works fine! But there must be some difference in the PHP versions since the 2nd pictures only works with PHP 4.1.2, and not with the latest PHP version. [2003-01-28 13:26:00] michael dot mauch at gmx dot de php -r '$size = getimagesize(http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg;); print_r($size); echo \n;' works without problems here (PHP 4.3.0), while php -r '$size = getimagesize(http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg;); print_r($size); echo \n;' prints nothing. ImageMagick's identify sees some strange ipct data in the second image; probably these make getimagesize() misbehave. [2003-01-27 17:25:35] [EMAIL PROTECTED] I can reproduce this with latest stable CVS (4.3.1-dev) It does work if the image is local..but not if it's remote. [2003-01-27 16:12:37] tozz at kijkt dot tv Hallo, I have a weird problem, which I think is a bug. The following script works with PHP 4.1.2 (I know, very outdated), but DOES NOT work with PHP 4.3.0: ? error_reporting (E_ALL); $foto=http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg;; $image_size=getimagesize($foto); $width=$image_size[0]; $height=$image_size[1]; $type=$image_size[2]; print (img src='$foto'\n); print (p\n); print (width: $width; height: $height; type: $typebr\n); print (p\n); $foto=http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg;; $image_size=getimagesize($foto); $width=$image_size[0]; $height=$image_size[1]; $type=$image_size[2]; print (img src='$foto'\n); print (p\n); print (width: $width; height: $height; type: $typebr\n); ? The problem is : The first image works fine, it shows the height, width and type. However, the information about the second image is only beeing displayed if using PHP 4.1.2. With PHP 4.3.0 no information is beeing displayed. -- Edit this bug report at http://bugs.php.net/?id=21912edit=1
