#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: soletan at toxa dot de Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: Ran into the same problem and read most of the posts in this report. Well, I don't expect PHP developers to ever find this bug. Don't you get annoyed by template-driven posts asking for information they can't use? HERE COMES MY ADVICE: Reading hints on expecting a race condition lead me to installing suhosin, which is an extension to PHP increasing its integrity and security. Guess what, it helped me out of this trouble. This is no ad, so I won't provide a link here. Just google the name ... Maybe PHP developers shouldn't use templates requesting tons of backtracks providing obviously useless information, but invest some time in revising observers for the internal memory management of PHP as this is obviously causing the trouble. Previous Comments: [2009-03-03 11:22:34] hakan dot koseoglu at gmail dot com The same problem appears from a allegedly successful compilation op PHP 5.2.9 on RHEL5 64 bit using -m32 CFLAG so that the binaries are 32 bit. The compilation appears to complete successfully: Apache 2.0.59 compiled w/o any problems with the following configure and it works fine. ./configure --prefix=/apps/apache2 --with-expat=builtin PHP is configured with the following options: ./configure --with-apxs2=/apps/apache2/bin/apxs --build=i386-redhat-linux --with-pic --with-gd --with-zlib --with-config-file-path=/apps/apache2/conf --with-libdir=/lib/ --enable-debug And after the successful run, make test was run with the following errors: [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c71270 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:144, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdd80 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdb78 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cd9ac status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' /apps/source/php-5.2.9/main/streams/plain_wrapper.c(160) : Freeing 0x097CD9AC (108 bytes), script=/apps/source/php-5.2.9/run-test-info .php /apps/source/php-5.2.9/ext/standard/php_fopen_wrapper.c(312) : Actual location (location was relayed) Last leak repeated 2 times === Total 3 memory leaks detected === [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c734c4 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:292, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '-' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x086d7038 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x4C780131) At least 4 bytes overflown --- [Tue Mar 3
#38938 [NEW]: more useful initialization for strptime
From: soletan at toxa dot de
Operating system: Linux
PHP version: 5CVS-2006-09-23 (snap)
PHP Bug Type: Date/time related
Bug description: more useful initialization for strptime
Description:
Hi,
in addition to bug #38524 I'd prefer initializing call to strptime in a
more useful way. While it is easiest way to memset all with 0's, some
fields like tm_mon can't be interpreted properly.
My proposal uses 0xFF for initialization to get all values set -1.
Then in addition, I add array element value NULL on every field that
wasn't touched by strptime. I consider this to be quite common behaviour
in PHP ...
Below is my proposal for a patch on latest CVS snapshot.
Best Regards,
Thomas Urban
*** datetime.c.orig 2006-08-24 14:30:57.0 +0200
--- datetime.c 2006-09-24 02:16:09.0 +0200
***
*** 101,107
return;
}
! memset(parsed_time, 0, sizeof(parsed_time));
unparsed_part = strptime(ts, format, parsed_time);
if (unparsed_part == NULL) {
--- 101,107
return;
}
! memset(parsed_time, 0xFF, sizeof(parsed_time));
unparsed_part = strptime(ts, format, parsed_time);
if (unparsed_part == NULL) {
***
*** 109,122
}
array_init(return_value);
! add_assoc_long(return_value, tm_sec, parsed_time.tm_sec);
! add_assoc_long(return_value, tm_min, parsed_time.tm_min);
! add_assoc_long(return_value, tm_hour, parsed_time.tm_hour);
! add_assoc_long(return_value, tm_mday, parsed_time.tm_mday);
! add_assoc_long(return_value, tm_mon, parsed_time.tm_mon);
! add_assoc_long(return_value, tm_year, parsed_time.tm_year);
! add_assoc_long(return_value, tm_wday, parsed_time.tm_wday);
! add_assoc_long(return_value, tm_yday, parsed_time.tm_yday);
add_assoc_string(return_value, unparsed, unparsed_part, 1);
}
/* }}} */
--- 109,146
}
array_init(return_value);
! if ( parsed_time.tm_sec 0 )
! add_assoc_null(return_value, tm_sec);
! else
! add_assoc_long(return_value, tm_sec, parsed_time.tm_sec);
! if ( parsed_time.tm_min 0 )
! add_assoc_null(return_value, tm_min);
! else
! add_assoc_long(return_value, tm_min, parsed_time.tm_min);
! if ( parsed_time.tm_hour 0 )
! add_assoc_null(return_value, tm_hour);
! else
! add_assoc_long(return_value, tm_hour, parsed_time.tm_hour);
! if ( parsed_time.tm_mday 0 )
! add_assoc_null(return_value, tm_mday);
! else
! add_assoc_long(return_value, tm_mday, parsed_time.tm_mday);
! if ( parsed_time.tm_mon 0 )
! add_assoc_null(return_value, tm_mon);
! else
! add_assoc_long(return_value, tm_mon, parsed_time.tm_mon);
! if ( parsed_time.tm_year 0 )
! add_assoc_null(return_value, tm_year);
! else
! add_assoc_long(return_value, tm_year, parsed_time.tm_year);
! if ( parsed_time.tm_wday 0 )
! add_assoc_null(return_value, tm_wday);
! else
! add_assoc_long(return_value, tm_wday, parsed_time.tm_wday);
! if ( parsed_time.tm_yday 0 )
! add_assoc_null(return_value, tm_yday);
! else
! add_assoc_long(return_value, tm_yday, parsed_time.tm_yday);
add_assoc_string(return_value, unparsed, unparsed_part, 1);
}
/* }}} */
--
Edit bug report at http://bugs.php.net/?id=38938edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38938r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38938r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38938r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38938r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38938r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38938r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38938r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38938r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38938r=support
Expected behavior:http://bugs.php.net/fix.php?id=38938r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38938r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38938r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38938r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38938r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38938r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38938r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38938r=gnused
#34526 [NEW]: array-related operation to reduce contained items
From: soletan at toxa dot de Operating system: Linux PHP version: 5.0.5 PHP Bug Type: Feature/Change Request Bug description: array-related operation to reduce contained items Description: Is it possible to have an array_-method to perform the transformation on arrays as given below. Since I am working with DBs and wrapping records of tables using classes I often get the case to receive an array as given below and require to pass the list of IDs, only. For sure I can do the transformation all by myself in PHP using foreach. But since my software is getting more and more complex I appreciate any chance to increase my scripts' performance by having such trivial tasks being done in one step. Reproduce code: --- before: array( array( 'id' = 1, 'foo' = 'bar' ), array( 'id' = 2, 'foo' = 'bar' ), array( 'id' = 3, 'foo' = 'bar' ), array( 'id' = 4, 'foo' = 'bar' ), array( 'id' = 5, 'foo' = 'bar' ) ); action: $out = array_x( $in, 'id' ); result: array( 1, 2, 3, 4, 5 ); -- Edit bug report at http://bugs.php.net/?id=34526edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34526r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34526r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34526r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34526r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34526r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34526r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34526r=needscript Try newer version: http://bugs.php.net/fix.php?id=34526r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34526r=support Expected behavior: http://bugs.php.net/fix.php?id=34526r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34526r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34526r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34526r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34526r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34526r=dst IIS Stability: http://bugs.php.net/fix.php?id=34526r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34526r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34526r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34526r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34526r=mysqlcfg
#32506 [NEW]: bug or feature? no virtual resolution of self::-reference
From: soletan at toxa dot de
Operating system: Linux
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: bug or feature? no virtual resolution of self::-reference
Description:
First of all I expect this to be an item for your wish list but hope it
is a bug (lack) to be fixed. :-) Maybe you will advise me to re-design
my code ... but: ...
I consider OOP in PHP5 to be a very powerful advantage over PHP4 so I
started to re-implement my web application library from scratch using PHP5
... having classes wrapping data entities encouraged me to have some kind
of base class with commonly used methods like getProperty(),
setProperty(), createItem(), deleteItem(), listItems() etc.
There are static methods like createItem() or loadItem() which take a link
to DB and a ID (in case of load) and return an instance of their own class
on successful return etc.
Then I'd like to have a class derived from this common class with only
parametrizing the base class. So, for example, there is a method returning
a list of properties (columns in wrapped DB-table), which are considered
to be read-only. This list is requested by method getProperty() in base
class and will cause some requests for adjustment to be revoked by base
class method getProperty() without the need to overload it in a derived
class.
Other methods like create and load simply need to know what table to work
with and so call a method which is telling the table's name.
Okay, this might be possible using object properties declared static. But
then there is another part of specification that causes conflicts:
Using OOP should lead to clean wrapping of data. This is why I want to
have entities like user being wrapped. So there is a base class as drawn
before, and a derivation called user. This implements commonly used API
to user accounts.
Now there are opportunities to have customers plugging in their own code.
One of my bad customers implement a class bad_user derived from user
and make property password writable while it is read-only using class
user. They can do that by simply adjusting that property giving list of
read-only properties.
Using a method instead and then declare that method final in class user
it is possible to make my class user resistant and reliable, right!? And
that's why I would prefer using that way of parameterizing my base class.
But: PHP 5.0.3 is working as given below and self::... is always resolving
into base class instead of virtually using overloaded method in derived
class instead, even when method test was invoked in scope of derived
class.
Is this a bug or a feature? And if it's a feature, is there a short-time
opportunity to have it changed anyhow? ;-)
I know there are opportunities using __get() and __set() to work with some
undeclared properties. But before I start to re-uglify my code I would like
to ensure that is really working. And finally I don't like to re-uglify
as this is a hack and reduces the power of OOP in PHP5, doesn't it!?
Okay, I hope this post is no riddle for you and I thank you in advance for
any advise or solution.
Best Regards,
Thomas Urban
Reproduce code:
---
?php
class base {
static function test() {
echo self::read();
}
protected static function read() {
return base;
}
}
class spec extends base {
protected static function read() {
return spec;
}
}
spec::test();
?
Expected result:
spec
Actual result:
--
base
--
Edit bug report at http://bugs.php.net/?id=32506edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32506r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32506r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32506r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32506r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32506r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32506r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32506r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32506r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32506r=support
Expected behavior: http://bugs.php.net/fix.php?id=32506r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32506r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32506r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32506r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32506r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32506r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32506r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32506r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32506r=float
No Zend Extensions: http
#32507 [NEW]: continued: abstract static functions cause error on invocation
From: soletan at toxa dot de
Operating system: Linux
PHP version: 5.0.3
PHP Bug Type: Class/Object related
Bug description: continued: abstract static functions cause error on invocation
Description:
This report is a sequel to BUG #31943 and is in relation to BUG #32506
(posted by myself) most probably.
BUG #31943 was solved by reporter without a more detailed note, but
nevertheless I think there's a misinterpretation of how and why abstract
and static might be combined in an OOP-like system.
Or it is caused by non-virtual resolution of scope-reference self::... -
then it is identical to BUG #32506.
Is it bad OOP to have constellations like this code below? Or is it just
because of PHP5 not supporting virtual references? Well, in that case I
prefer to have it on the wish list.
Best Regards,
Thomas Urban
Reproduce code:
---
abstract class a {
static function test() {
echo self::read();
}
abstract protected static function read();
}
class b extends a {
protected static function read() {
return hello world!;
}
}
b::test();
Expected result:
hello world!
Actual result:
--
Fatal error: Cannot call abstract method base::read() in ...
--
Edit bug report at http://bugs.php.net/?id=32507edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32507r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=32507r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=32507r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=32507r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=32507r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=32507r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=32507r=needscript
Try newer version: http://bugs.php.net/fix.php?id=32507r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=32507r=support
Expected behavior: http://bugs.php.net/fix.php?id=32507r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=32507r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=32507r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=32507r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32507r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=32507r=dst
IIS Stability: http://bugs.php.net/fix.php?id=32507r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=32507r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=32507r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=32507r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=32507r=mysqlcfg
#32012 [NEW]: Request for revisiting your online manual
From: soletan at toxa dot de Operating system: WinXP PHP version: 5.0.3 PHP Bug Type: Feature/Change Request Bug description: Request for revisiting your online manual Description: Hi, I'm using your online manual as reference while coding each and every day. I prefer to use that over any book or similar since I consider it to be always most uptodate over those. Furthermore user notes are quite helpful very often. BUT: Again and again I don't see any sense in having such huge front page on each extension. Did you ever try to find the list of supported methods on Multibyte String Extension's front page? While looking for that I'm neither interested in information how to install that extension, how to configure transparent IO-encoding or on what each charset is about to be. Even moving to bottom of page doesn't satisfy as there might be lots of user notes with further suggestions on how to install here, configure there etc. Of course, ALL these information are worth to be available, but why couldn't you have some subpages since they become more and more complex with each new release of PHP. And normally users stop installing some day and even configuration is done, right before the developer starts to use your manual as a reference for daily work. Sometimes I simply can't remember what was the name of a single function or what options I have to do this or that using single selection. So using shorthand access using URL is no good tool just like searching whole PHP's function list. Well, simplest adjustment would be to have a page menu on top to click for the function list (as well as installation notes, list of defined constants, user notes, etc.). This would avoid getting more files in PHP manual folder. -- Edit bug report at http://bugs.php.net/?id=32012edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32012r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32012r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32012r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32012r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32012r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32012r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32012r=needscript Try newer version: http://bugs.php.net/fix.php?id=32012r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32012r=support Expected behavior: http://bugs.php.net/fix.php?id=32012r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32012r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32012r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32012r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32012r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32012r=dst IIS Stability: http://bugs.php.net/fix.php?id=32012r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32012r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32012r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32012r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32012r=mysqlcfg
#28062 [Bgs]: gettext produces ? instead of german special chars
ID: 28062 User updated by: soletan at toxa dot de Reported By: soletan at toxa dot de Status: Bogus Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: Okay, this problem appeared to be some kind of abnormal. It wasn't in relation to PHP's upgrade. It took me hours to get into depths but now there's a stable solution to avoid this problem: After booting a server conversion failed as described, since gconv/iconv at libgettext produced question-marks on any German special character. Restarting the Apache2 once solved this problem until the system's next reboot. So I moved on and checked PHP's result of calling setlocale and that way found that category LC_MESSAGES isn't documented in PHP manual pages (anymore?). Well, in this it's optionally available, but editing all calls of setlocale to use LC_ALL instead permanently solved the problem. Software is okay, documentation/category support is nearly okay, too. Best Regards Thomas Urban Previous Comments: [2004-04-19 22:36:06] [EMAIL PROTECTED] Okay. Reopen this if that happens. [2004-04-19 22:04:24] soletan at toxa dot de For the moment forget about that. I tested around with it a bit and everything's working fine right now. I come back, if it re-appears. [2004-04-19 20:30:13] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-04-19 17:08:26] soletan at toxa dot de BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#28062 [NEW]: gettext produces ? instead of german special chars
From: soletan at toxa dot de Operating system: SuSE Linux 7.2 PHP version: 4.3.6 PHP Bug Type: Gettext related Bug description: gettext produces ? instead of german special chars Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit bug report at http://bugs.php.net/?id=28062edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28062r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28062r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28062r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28062r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28062r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28062r=needscript Try newer version: http://bugs.php.net/fix.php?id=28062r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28062r=support Expected behavior: http://bugs.php.net/fix.php?id=28062r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28062r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28062r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28062r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28062r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28062r=dst IIS Stability: http://bugs.php.net/fix.php?id=28062r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28062r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28062r=float
#28062 [Opn]: gettext produces ? instead of german special chars
ID: 28062 User updated by: soletan at toxa dot de Reported By: soletan at toxa dot de Status: Open Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ Previous Comments: [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#28062 [Fbk-Opn]: gettext produces ? instead of german special chars
ID: 28062 User updated by: soletan at toxa dot de Reported By: soletan at toxa dot de -Status: Feedback +Status: Open Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: For the moment forget about that. I tested around with it a bit and everything's working fine right now. I come back, if it re-appears. Previous Comments: [2004-04-19 20:30:13] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-04-19 17:08:26] soletan at toxa dot de BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#22736 [NEW]: change of operator precedence
From: soletan at toxa dot de Operating system: Linux PHP version: 4.3.1 PHP Bug Type: Feature/Change Request Bug description: change of operator precedence Hi, maybe this can't be done because of scripts relying on current operator precedence, but for the statement $a ~$b != 0 your current precedence rules would do $a ~( $b != 0 ) which is quite unusual. Traditional logics (used by Frege and others) would first compute the negation, it is the most strongly bound operator. For instance, having ~p ^ q as a structured expression the negation would precede any other operator p is argument of, or: p is not argument of the conjunction, but the negation's result is. Maybe I'm still false, but that's what I have expected to write logical calculations like for years. Best Regards, Thomas Urban -- Edit bug report at http://bugs.php.net/?id=22736edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22736r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22736r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22736r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22736r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22736r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22736r=support Expected behavior: http://bugs.php.net/fix.php?id=22736r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22736r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22736r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22736r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22736r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22736r=dst IIS Stability: http://bugs.php.net/fix.php?id=22736r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22736r=gnused
#21306 [Com]: warnning about cannot change the session settings
ID: 21306 Comment by: soletan at toxa dot de Reported By: Xuefer at 21cn dot com Status: Open Bug Type: Session related Operating System: linux PHP Version: 4.3.0 New Comment: I tried to compile some information on that bug, that probably helps to understand my problems. Because this report system lacks of a support for attachments (which is quite reasonable to me, of course). But I guess you won't read 3MB text files unzipped or 86 KB archived, but binary here ... I send the compilation to anyone who likes to get. Several php-scripts, some modifications to php-source I made, two quite large but still simple syslog-excerpts, a copy of output are included with that compilation. The scripts are excerpts only, because a full backup of my scripts source tree would take 190 KB gzipped. If you need more information (sources) to reproduce the malfunction, send me a mail, but I hope this is enough and maybe you dont need that much additional information. Some first idea of whats wrong: In my case this bug doesnt immediately belong to sessions. Its probably some scripting failure or a malfunction of how several parts of PHP-core and exts zend scripting engine and altered session handler work together. It looks like some overflow, like somethings trashing PHPs heap. As a consequence, or in conjunction with that, PHP doesnt end and gets dropped by maximum-execution-time observer, which then ignores any session save procedures and cleans up everything. During this the session still gets informed about restoring the ini-environment and produces the posted error message. Here is what I did: The bug appeared again and I couldn't find any place in my scripts missed to include some session_write_close() + exit() this in consequence to my last comment! One of my scripts is a layouter (lib/layout.php), implemented as a class. I feed it with information about the body content, menu structure and else. It stores all these in a structured array. Finally I call a method named draw(), that searches for available plugins depending on the client's browser-caps and uses one of these to produce a string, which draw() returns itself to its caller afterwards. That caller finally echo's the string right before the closing tag and the end of major script file I used src/start.php for testing. Each trial to break the execution before calling that draw method was successful, tested with included snippet echo 'test'; exit( 0 ); ... Now comes some interesting point: Placing the same at the first line inside the draw-method, I get test twice without delay. One exit gets ignored, then scripting gets into draw() a second time and this time the exit seems to be computed, too. This double call might become visible by the second logfile-excerpt, message-foo ... Removing any additional echos and exits, the script runs for maximum execution time and then produces the output, Xuefer posted at modification notifier in ext/session/session.c:OnUpdateSaveHandler. I included some debugging support by calling syslog in zend/zend_ini.c and in session/session.c of PHP's source tree at several points of code. Watching my syslog-file I detected, that my installed session-class didnt get called for writing and closing, but zend engine shuts down script execution. Well, after detecting one of my variables having values at second run, I've never assigned myself anywhere, I used this to detect the second call and return immediately from method draw() after flushing session with a pair of session_write_close(); @session_start();. Now there's no execution delay, no strange error message, nothing but a f**king workaround hack. Best Regards Thomas Urban Previous Comments: [2003-03-06 11:35:25] soletan at toxa dot de Damn, I got rid of that message Xuefer initially posted. All I had done was calling exit() before session could write back its data. Then I included session_write_close() before some exit. It's not that exit inside some session_set_save_handler-calling function. It's any exit at any place, I expect. Isn't it possible, to include this needed call to session_write_close() automatically in sources of exit() to avoid all that trouble I have been handling with for the last 24 hours??? It would be more convenient, doesn't it? BTW: I have PHP 4.3.1 as DSO to Apache 2.0.43 under SuSE Linux 7.1. The first two are both self-compiled from source. Best Regards, Thomas Urban [2003-02-07 17:15:20] rob at nospamplease dot com This appears (in our case anyway) to be triggered by the use of an exit statement in the session_set_save_handler session_write function. We had a benign error in our custom session_write function (caused by the session data not changing when it was writing out).. this caused an error message
#21445 [NEW]: imagettfbbox and imagettftext fail with warning
From: [EMAIL PROTECTED] Operating system: SuSE Linux 7.2 PHP version: 4.3.0 PHP Bug Type: GD related Bug description: imagettfbbox and imagettftext fail with warning Hi, I've update my 4.2.3 to freshly published 4.3.0. It works with Apache 2.0.40 here ... Nearly everything's fine. I used some script that dynamically generates images with text in them. Under 4.2.3 everything was okay and created PNG for instance, now under 4.3.0 the image files get malformed because of two warnings which are preceding the non-working data: Warning: imagettfbbox() [...]: arialbd.ttf in /home/... on line xx Warning: imagettftext() [...]: ..# in /home/... on line yy Both are shortened inside the brackets and by the omitted scriptname. The rest is as short as produced ... What I'm calling is: $font = arialbd.ttf; $text = whatever; $size = imagettfbbox( 10, 0, $font, $text ); [..] imagettftext( $imgobj, 10, 0, 0, $height, $col, $font, $text); arialbd.ttf lies in same directory as script does. Preceding both calls with @ lead to Apache/PHP not answering anymore ... (faking some request with telnet results in an unstoppable telnet client). I compiled from source without any source patch or similar with following configuration: './configure' '--with-apxs2' '--enable-discard-path' '--with-debug' '--enable-safe-mode' '--with-exec-dir' '--with-openssl' '--enable-sigchild' '--enable-maqic-quotes' '--enable-libgcc' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-db3' '--enable-dio' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--enable-dl' '--with-ming=/tmp/ming-0.2a/' '--with-ttf' '--with-t1lib' '--with-jpeg-dir' '--with-png-dir' '--with-gettext' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt' '--with-mysql=/usr' '--with-pdflib' '--with-tiff-dir' '--enable-sockets' '--with-regex=system' '--enable-tokenizer' '--with-xmlrpc' --- check my php-config under http://www.toxa.de/test.php On closing this report I repeat not to change any of the circumstances which made the script working before under 4.2.3, even configure as shown above staid the same ... Thank you for your help! Thomas Urban -- Edit bug report at http://bugs.php.net/?id=21445edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21445r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21445r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21445r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21445r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21445r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21445r=support Expected behavior: http://bugs.php.net/fix.php?id=21445r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21445r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21445r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21445r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21445r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21445r=dst IIS Stability: http://bugs.php.net/fix.php?id=21445r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21445r=gnused
#19806 [NEW]: more detailed messages PLEASE!!!!
From: [EMAIL PROTECTED] Operating system: Linux 2.4.9 PHP version: 4.2.3 PHP Bug Type: Feature/Change Request Bug description: more detailed messages PLEASE This is what I tried to do today ... after getting rid of safe-mode-get-uid-stress yesterday and apache-2.0+php-4.2.x-trouble that day before, which tooks me several hours each ... Well, I used to call dba_open and got some well known error saying driver initialization failed. It's quite okay for that. Browsing your bug report system indicates, that this failure isn't fresh, but was told to be done in CVS for 4.0.1 or something around that version. Now, it took me several hours again to first browse your site, the rest of internet, the sources of PHP and DB3 and test around with several things before I came to the point in code, where I had to install some error reporting into your sources to find out why dba_open finally failed ... Well, I've reported several non-significant bugs to your system before and always tried to bring up the patience to make it as easy as understandable for you what went wrong here at my systems. Some reports can't be supplied with detailed information without spending another lot of hours - which I can't effort, too, because of economic needs - in testing, searching and solution-offering. All I get is some automatic message saying, you can't do anything without further details, linking me with some explanation of what you would like a bug report consisting of and finally making my report a bogus one ... I really understand all your stress and that PHP isn't fulltime for you and I pay full respect to this all, but sometimes I don't feel like being handled in a similar way by you ... what about some better documentation, more specific and even more professional. And if not being better documented, what about more detailed error reporting mechanisms In the example given up there your code responds with driver initialization failed on any problem the handler's open-method encounters and reports by some boolean result. The other end point of the underlying calling chain - db3's open-method supplies detailed error messages - which I would like to get instead of that nonsense warning. To me it's like reporting you: Hey, my PHP isn't working. While expecting your time to be wasted with that request or its realisation, I hope it could influence a bit the way of coding several extensions (which rely on external libraries - like dba does) in the future ... Thanks for your attention! -- Edit bug report at http://bugs.php.net/?id=19806edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19806r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19806r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19806r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19806r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19806r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19806r=support Expected behavior: http://bugs.php.net/fix.php?id=19806r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19806r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19806r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19806r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19806r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19806r=dst IIS Stability: http://bugs.php.net/fix.php?id=19806r=isapi
#13818 [Com]: safe mode wrong uid -1
ID: 13818 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *General Issues Operating System: solaris PHP Version: 4.0.6 New Comment: Same problem with PHP-CVS-snapshot STABLE-200210061500 and Apache 2.0.43 ... well but it looks like trouble with Apache's server_context things. I browsed through PHP sources a bit and found that it uses values provided by apache and apache is taking it from system using fstat. But I couldn't find out why no one gets real uid of script file or even where to configure this feature ... Previous Comments: [2002-06-26 04:19:51] [EMAIL PROTECTED] I get this error with php4-200206240900 / apache-2.0.39 on Solaris 8. And yes, apache defaults to run as -1, but this has been succesfully configured to another uid here. [2002-04-28 10:55:36] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. I believe this has been fixed on solaris since 4.0.6. [2002-04-05 05:44:19] [EMAIL PROTECTED] I might be mistaken, but doesn't Apache try to run as -1 by default? On some systems that refers to nobody. Might that be that case? [2001-10-24 13:41:52] [EMAIL PROTECTED] I could not find any reference on the newsgroups to the following error we are getting when safe mode is on: Warning: SAFE MODE Restriction in effect. The script whose uid is -1 is not allowed to access ../orders.txt owned by uid 66400 in /class/em680a/www/cgi-bin/vieworders.php on line 10 The -1 can't be a uid, but I can't figure out what the error is. There was a bug post on 12/8/2000 by someone who was getting the same error but the uid was 1 not -1 and the suggestion was to upgrade php and reopen the issue if it was not fixed. -- Edit this bug report at http://bugs.php.net/?id=13818edit=1
#19790 [NEW]: can't fetch file update.php4
From: [EMAIL PROTECTED] Operating system: Linux 2.4.9 PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: can't fetch file update.php4 Hi, first of all I can't determine, if this bugs concerns to you, to Apache or to some fault in my configuration of either. Using Apache 2.0.43 + PHP 4.2.3 I have some site set up, where I link a file named update.php4 within some menu (using HTML-A-tag of course). I do the same with other scripts, but the other referers work. Now, when I use this link to fetch update.php4, which contains nothing but a nice PHP-script from the very first to the very last line, I get the source instead of the script's output after running. If I turn the reference as well as the script's name into updat.php4 or updater.php4 everything works fine and I get the script running and putting out ... Then I tried STABLE-200210061500 from snaps.php.net and encountered the same problem. Again, I don't know, if this is of your concern or if it belongs to either apache or my configuration. I first searched apache's bug report database for update and found nothing appropriate and so grepped my configuration files (the whole /etc/httpd-directory) for that token and didn't found it somewhere not within a comment ... -- Edit bug report at http://bugs.php.net/?id=19790edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19790r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=19790r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=19790r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19790r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19790r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=19790r=support Expected behavior: http://bugs.php.net/fix.php?id=19790r=notwrong Not enough info:http://bugs.php.net/fix.php?id=19790r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=19790r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=19790r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19790r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=19790r=dst IIS Stability: http://bugs.php.net/fix.php?id=19790r=isapi
#19632 [NEW]: trouble using cmdline with options
From: [EMAIL PROTECTED] Operating system: Linux 2.4.19 PHP version: 4CVS-2002-09-27 PHP Bug Type: *General Issues Bug description: trouble using cmdline with options Hi, I'm using PHP cmdline-version called by shell shortcut comment #!/usr/local/bin/php ... with options -d log_errors=On -q which made the -q get ignored under 4.2.3. So I tried to use latest CVS-snapshot as defined above. Well, this problem has gone, but then I tried to include some definitions with option -d. #!/usr/local/bin/php -d display_errors=Off ?php include notthere.php; ? produces Warning: main(notthere.php) [http://www.php.net/function.main]: failed to create stream: No such file or directory in ./test on line 1 Warning: Failed opening 'notthere.php' for inclusion (include_path='.:/usr/lib/php') in ./test on line 1 Can't I overload system-wide configuration file by using this option -d??? BTW: Some other failure I realised with the first test under 4.2.3 appears in that CVS-version, too. Writing -q as first option before -d produces some error output Error in argument 1, char 3: option not found Error in argument 1, char 4: option not found - Error in argument 1, char 3: option not found Usage: [...] which is then completed by the list of available options. I tried to turn it into using -c with some optional configuration file #!/usr/local/bin/php -q -c /etc/test.ini and set display_errors to false in that file. With -q it still produces the error output, so this could be a false of -q handling. Removing it produces still the file-not-found-warnings ... After finding several bugs I'm forced to use your beta-cvs-snapshots within production tools and urgently need some release (called stable officially) which fixes this and the recent bugs ... thanks. Thomas Urban -- Edit bug report at http://bugs.php.net/?id=19632edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=19632r=trysnapshot Fixed in CVS:http://bugs.php.net/fix.php?id=19632r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=19632r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=19632r=needtrace Try newer version: http://bugs.php.net/fix.php?id=19632r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=19632r=support Expected behavior: http://bugs.php.net/fix.php?id=19632r=notwrong Not enough info: http://bugs.php.net/fix.php?id=19632r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=19632r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=19632r=globals
