#21480 [NEW]: COM related
From: [EMAIL PROTECTED] Operating system: Windows 2000 Pro PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: COM related A working script written using COM now crashes Apache 1.3.26 after upgrading to PHP 4.3.0. It also hangs Apache 1.3.27. Excel zombies wander. I was using a snap dated sometime later than 10/17/2002. And according to CVS no changes have been made to the COM extension since then other than bumping of the copyright year. -- Edit bug report at http://bugs.php.net/?id=21480&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21480&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21480&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21480&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21480&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21480&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21480&r=support Expected behavior: http://bugs.php.net/fix.php?id=21480&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21480&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21480&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21480&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21480&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21480&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21480&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21480&r=gnused
#20986 [Fbk->NoF]: PHP causes Apache to leak semaphores
ID: 20986 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: RedHat Linux 7.1 & 8.0 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-12-22 01:10:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-13 04:13:22] [EMAIL PROTECTED] This bug has been discussed over at RedHat's Bugzilla. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=70846 A quick synopsis of how I get it to misbehave: Create the following simple PHP script and access it through a web browser: 2, 'test' => 2, 1 => 'hello', 'say' => 'hello', 2 => 42, 'life' => 42, 3 => 'this should help \'crash\' the machine', 'hoho' => 'this should help \'crash\' the machine'); print_r($crash); for( $i=0; $i It should die with an error similar to this: Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /home//crash.php on line 14 Reload this page a good 5-10 times. If you run 'ipcs -s' and then restart apache and run 'ipcs -s' again you will find that the number of semaphore arrays has increased and the first few semid's are unchanged (not having been freed when apache shutdown?). If you rinse and repeat the above with a crude shell script like: while [ true ]; do wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php wget -O - http://localhost/crash.php ipcs -s|grep apache|wc /etc/rc.d/init.d/httpd restart sleep 1 ipcs -s|grep apache|wc done then you'll find the semaphore array numbers increasing slowly and apache taking longer and longer to do each restart until eventually (once all 128 semaphore arrays are used) it refuses to start at all with the message reported earlier in this bug (70846): Starting httpd: Ouch! ap_mm_create(1048576, "/var/run/httpd.mm.5619") failed Error: MM: mm:core: failed to acquire semaphore (No space left on device): OS: Invalid argument [FAILED] Just restarting apache in a loop without loading crash.php on a freshly booted system does not cause the number of semaphores to spiral - it stays constant at 5. This is verifyable on multiple RH7.1 and a RH8.0 machine, all fully updated through RHN (except for kernels). RedHat have literally just released an updated mm package which stops the use of kernel semaphores so that the leaks should not cause Apache problems so quickly (ie more than 128 are now allowed), but none-the-less there RedHat agree there is still a PHP problem. Louis -- Edit this bug report at http://bugs.php.net/?id=20986&edit=1
#21261 [Opn]: $_SERVER['PHP_SELF'] gives wrong info
ID: 21261 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: linux 2.4.18 - slack 8.1 PHP Version: 4.3.0 Assigned To: shane New Comment: [EMAIL PROTECTED]: email me your httpd.conf, php.ini and the test script you use. You can remove anything from the files that are private. Also, as per spec PATH_TRANSLATED will be empty unless you have PATH_INFO, which is path data *after* the script in a url: http://host/script.php/path/info?query-string The only thing I'm concerned about is the garbled PHP_SELF. PHP_SELF is the same as SCRIPT_NAME, is SCRIPT_NAME also garbled? Previous Comments: [2003-01-06 11:06:47] [EMAIL PROTECTED] Negative. Patch not only did not work (I applied it to current 4.3.0) but I now no longer have a $_SERVER['PATH_TRANSLATED'] variable . So $_SERVER['PHP_SELF'] remains corrupted and $_SERVER['PATH_TRANSLATED'] gives some kind of udefined error. Joshua [2003-01-05 21:58:19] [EMAIL PROTECTED] The patch at http://www.caraveo.com/php/cgi.patch Should fix this problem. Please try this and let me know. It's against cvs HEAD from today. [2003-01-02 10:54:32] [EMAIL PROTECTED] I'm using php with cgiwrap. http://cgiwrap.unixtools.org/ I added two small patches as described in Bug #21301 but i don't know if they work with current cvs version. In httpd.conf: AddHandler php-cgiwrap .php Action php-cgiwrap /cgiwrapper/php-cgiwrap/ ScriptAlias /cgiwrapper/ /usr/local/cgiwrap/ [2003-01-01 11:21:36] [EMAIL PROTECTED] Are you talking about this? ScriptAlias /cgi/ /var/www/htdcos/cgi/ Action application/x-httpd-php /cgi/php AddType application/x-httpd-php .php I can also post my ini and my configure script though you can probably get that info from the env.html I posted earlier. [2002-12-31 01:21:50] [EMAIL PROTECTED] Send me the pertinent lines out of httpd.conf that you have used to configure php so I can test with the same settings. 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/21261 -- Edit this bug report at http://bugs.php.net/?id=21261&edit=1
#21478 [Opn]: Zend/zend_alloc.c :: shutdown_memory_manager produces segfault
ID: 21478
Updated by: [EMAIL PROTECTED]
-Summary: stream_get_filters(true) can cause segfault on script
exit
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Reproducible crash
+Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4CVS-2003-01-06 (dev)
Assigned To: pollita
New Comment:
It seems this error does not occour as a direct result of
stream_get_filters but is instead coincidental.
I was testing code in the streams/filters implementation in PHP-CVS
using the following script:
= 'A' AND $tempstr[$i] <= 'M') OR
($tempstr[$i] >= 'a' AND $tempstr[$i] <= 'm')) $tempstr[$i] =
chr(ord($tempstr[$i]) + 13);
else if (($tempstr[$i] >= 'N' AND $tempstr[$i] <= 'Z') OR
($tempstr[$i] >= 'n' AND $tempstr[$i] <= 'z'))
$tempstr[$i] = chr(ord($tempstr[$i]) - 13);
return $tempstr;
}
function write($data) {
for($i = 0; $i < strlen($data); $i++)
if (($data[$i] >= 'A' AND $data[$i] <= 'M') OR
($data[$i] >= 'a' AND $data[$i] <= 'm')) $data[$i] =
chr(ord($data[$i]) + 13);
else if (($data[$i] >= 'N' AND $data[$i] <= 'Z') OR
($data[$i] >= 'n' AND $data[$i] <= 'z')) $data[$i] =
chr(ord($data[$i]) - 13);
return parent::write($data);
}
}
var_dump(stream_get_filters(true));
/* Register our filter with PHP */
stream_register_filter("rot13", "rot13_filter")
or die("Failed to register filter");
var_dump(stream_get_filters(true));
$fp = fopen("foo-bar.txt","w");
stream_filter_append($fp, "string.rot13");
stream_filter_append($fp, "string.toupper");
stream_filter_append($fp, "rot13");
var_dump(stream_get_filters(true));
fwrite($fp,"This is a test.\n");
fclose($fp);
readfile("foo-bar.txt");
print "\n\n";
?>
And discovered a consistently reproducable crash upon script exit.
Oddly, compiling with --enable-debug causes the segfault to stop
occouring. (Making a backtrace difficult)
After exploration I discovered that commenting out one of the
occourances of stream_get_filters() would prevent the segfault so I
believed the fault to be in that function.
But here's the wierd twist:
Turns out that if you do something as innocuous as add:
$myvar = "";
to the end of that script, the segfault goes away.
After putting in a series of watches I tracked the segfault down to the
call to: ZEND_DO_FREE(ptr) on line 462 of Zend/zend_alloc.c in
shutdown_memory_manager.
The value of ptr looks reasonable and is in the same neighborhood as
other calls in the i/j loops.
I wish I could give you something better to work with but this is a
seriously elusive heisenbug.
I'll continue to explore the code locally, but I don't pretend to know
the Zend engine as well as many of you others.
- [EMAIL PROTECTED]
CVS: 2003-01-06
./configure --without-mysql --disable-cgi
Previous Comments:
[2003-01-06 19:00:02] [EMAIL PROTECTED]
This is a note to myself to fix this.
When stream_get_filters(true) is called between
stream_register_filter() and stream_fitler_(ap|pre)pend(), engine will
segfault on script exit.
--
Edit this bug report at http://bugs.php.net/?id=21478&edit=1
#21451 [Opn->Csd]: mssql extension crash apache server when used with freetds
ID: 21451 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: MSSQL related Operating System: Linux RedHat8.0 PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Building the mssql extension as shared did not set the right linker options. This is now fixed in cvs and will be available in php 4.3.1 Previous Comments: [2003-01-05 22:49:38] [EMAIL PROTECTED] Hi all, and first as all thank's, I'm testing the new funcionality of mssql trought freetds, I succesflly built rpms for RedHat8.0.92 httpd-2.0.40-14 of php-4.3.0, I'm using mssql throught freetds-0.60 from yesterday snapshot, but apache server crash when starts, this is the apache error log... /usr/sbin/httpd: relocation error: /usr/lib/php4/mssql.so: undefined symbol: dbinit here is my configure line './configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-pdflib=shared' '--with-tiff-dir=/usr' '--with-ncurses' '--with-gmp' '--with-iconv' '--enable-xslt=shared' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mcal=shared,/usr' '--with-mcrypt=shared,/usr' '--with-mhash=shared,/usr' '--with-mssql=shared,/usr' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--with-xslt-sablot=shared,/usr' '--with-sablot-js=shared,/usr' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I hope it helps Aliet -- Edit this bug report at http://bugs.php.net/?id=21451&edit=1
#17622 [Com]: session_register-session_is_registered does'nt work with register_globals=on
ID: 17622 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Session related Operating System: Debian GNU/Linux 3.0,kern2.2.17 PHP Version: 4.1.2 New Comment: Here is my test code, I get the same problem "; $_SESSION['blah'] = "foo"; var_dump($_SESSION); ?> blah The result is always the first var_dump is NULL, SID is blank and the second var_dump looks like what it should. Testing the same script on 4.2.1 alpha arch it works as is expected. Debian GNU/Linux system kernel 2.4.18 on sparc64 arch php4 4.1.2-4 Previous Comments: [2002-10-18 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-10-02 06:18:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-02 02:43:54] [EMAIL PROTECTED] Nope, it's an old Sparc Station 5 (sun4m). It's now upgraded with a 2.4.18 kernel ... same result. [2002-10-02 01:18:53] [EMAIL PROTECTED] Does your sparc installation use a 64bit data model? [2002-06-06 05:39:39] [EMAIL PROTECTED] session_register - session_is_registered doesn't work for global variables with "register_globals = on" on the sparc arch. The set.php - get.php scripts at the end of this report works just fine om my Debian GNU/Linux 3.0, kernel 2.4.18 on i386, but doesnt work on my Debian GNU/Linux 3.0, kernel 2.2.17 on sparc. Both machines runs Apache 1.3.24 and PHP 4.1.2 and got identical php.ini files. The scripts: --- set.php - get.php'; ?> --- get.php - - On the i386 I get ok and on the sparc failed. -- Edit this bug report at http://bugs.php.net/?id=17622&edit=1
#21279 [Fbk->Opn]: odbc_fetch_into returns empty strings for columns with NULL values
ID: 21279
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 4.3.0
New Comment:
I just tried Win32 build of PHP 4.4.0-dev taken from snaps.php.net
(php4-win32-200301062330.zip) and it is working the same. It looked
like the fix would solve the problem but it works as if the fix was not
applied. Isn't that build supposed to include the fix?
Previous Comments:
[2003-01-06 12:11:01] [EMAIL PROTECTED]
Try a snapshot dated sometime after this. I believe it does what you
want/desire. If not many complaints happen I'll leave it in...
[2003-01-03 17:09:16] [EMAIL PROTECTED]
What I meant is that every SQL based PHP database API has a function to
fetch rows into an array. When it is not not *_fetch_into is
*_fetch_row.
I do not see any ambiguity in figuring if a result column has a NULL.
As a matter of fact in the current odbc_function of php_odbc.c you
have:
http://cvs.php.net/co.php/php4/ext/odbc/php_odbc.c?r=1.143.2.1
if (result->values[i].vallen == SQL_NULL_DATA) {
Z_STRVAL_P(tmp) = empty_string;
break;
}
Since NULL is always NULL regardless of the data type of a column, all
that needs to be done is to leave undefined (NULL) the respective
column position of the PHP array value returned by the odbc_fetch_into.
[2003-01-03 12:10:44] [EMAIL PROTECTED]
Which other API's are you talking about? Oracle? It's the only other
extension that uses fetch into really.
As for the statement, there is no way for ODBC to really tell either.
The API itself defines this to be rather ambiguous so it becomes
difficult to deal with. At this time the result leaves it to the PHP
user to decide if one is really an emtpy string or NULL rather than the
PHP engine. I tend to think this is a better solution.
[2002-12-29 19:47:04] [EMAIL PROTECTED]
odbc_fetch_into returns empty strings for columns with NULL values.
This makes it impossible to distinguish whether a result column value
is a real empty string or a NULL, unlike with API functions for the
same purpose but for other databases.
--
Edit this bug report at http://bugs.php.net/?id=21279&edit=1
#21465 [Opn->Bgs]: multipart/form-data forms post problems
ID: 21465 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Linux RedHat 7.3 (kernel 2420) PHP Version: 4.3.0 New Comment: 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 Use $_FILES & $_POST superglobals to access the data. Previous Comments: [2003-01-06 10:49:37] [EMAIL PROTECTED] Hi, when I use form varibles, named, as associative array (see an example) and form have attribute multipart/form-data, after posting, first element of posted array are lost, in some cases. Example: - -- After posting printr($img) give: Array ( [koeff] => 1.45 [min_width] => 220 ) Thank you for support. Ivaschenko Yuriy. -- Edit this bug report at http://bugs.php.net/?id=21465&edit=1
#21462 [Opn->Bgs]: set_error_handler not properly executed?
ID: 21462
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux Slackware
PHP Version: 4.3.0
New Comment:
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
You cannot 'capture' fatal errors, your approach to checking function
avaliablity is flawed. Instead of trying to execute the function, why
not use function_exists(), which will accurately tell you if a function
is avaliable or not.
Previous Comments:
[2003-01-06 15:03:02] [EMAIL PROTECTED]
I am also experimenting this. My function used as error handling now
gives me array in all the parameters.
Ex. :
function my_error_handler($errno,$errstr,$errfile,$errline,$variables)
$errno = array
$errstr = array
etc...
[2003-01-06 09:01:50] [EMAIL PROTECTED]
Today we upgraded from php 4.2.3 (apache 1.3.26) to php 4.3.0.
We use freetype functionality in a set of functions and to keep this
very flexible the following code (except for the debugging prints) is
used to determine what freetype version was installed in order to use
the right functions (imagefttext or imagettftext).
This function (the set_error_handler) stopped working properly after
upgrading to 4.3.0
print freetype_version();
function freetype_version() {
// change error handler
set_error_handler("freetype_version_handler");
// remove freetype version from session
unset($_SESSION['freetype_version']);
// determine check array
$checkers = array(
"imagefttext" => 2, // freetype version
specific function -> freetype version
"imagettftext" => 1
);
// run checkers
while (list($key,$val)=each($checkers)) {
printf("%s:%s\n",$key,$val);
eval(sprintf("%s();",$key));
}
// restore old error handler
restore_error_handler();
// return version (null = no freetype support)
return $_SESSION['freetype_version'];
}
function
freetype_version_handler($errno,$errstr,$errfile,$errline,$variables)
{
print "errorrr!\n";
if (eregi(sprintf("wrong parameter count for
%s",$variables['key']),$errstr)) {
$_SESSION['freetype_version'] = $variables['val'];
}
}
The code outputs the following error:
Fatal error: Call to undefined function: imagefttext() in
/sda6/domains/betterbeyourself.com_staging/includes/fnc_lang.inc(651) :
eval()'d code on line 1
We allready use a custom error handler so the above handler is
nested... this however worked very well in 4.2.3 I also noticed the
same problems in some 4.3.0 developmental cvs snapshots (don't know
which snapshots they were though) and thought it was a bug to be solved
before the stable release but appearantly it's still there
Grtz,
Jeroen
--
Edit this bug report at http://bugs.php.net/?id=21462&edit=1
#21479 [Com]: function crashes when used with a URL
ID: 21479
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: GetImageSize related
Operating System: Windows 2000
PHP Version: 4.3.0
New Comment:
this happens with every image.
Previous Comments:
[2003-01-06 20:54:40] [EMAIL PROTECTED]
Does this happen with every image you try or a specific image or two?
In the event of the latter could you please provide a URL to the
offending image.
[2003-01-06 20:17:33] [EMAIL PROTECTED]
function ImgExists($f) {
$r=@getimagesize("http://localhost/$f";);
return $r[2]!=0;
}
if(ImgExists('icon.jpg')) echo('exists!');
when calling this function, php.exe (4.3.0 as CGI in IIS4) is crashing.
remark out the 'getimagesize' line, and it won't crash.
i can email my php.ini on request.
--
Edit this bug report at http://bugs.php.net/?id=21479&edit=1
#21477 [Opn->Fbk]: $node->dump_node($node) crashes when node has any attribute
ID: 21477 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: DOM XML related Operating System: linux; kernel 2.4.18 PHP Version: 4.3.0 New Comment: Cannot dublicate the crash using latest PHP snapshot. If you still experience the problem could you please provide a backtrace. Previous Comments: [2003-01-06 18:33:33] [EMAIL PROTECTED] hi eot; // this text avoids crash: $without_attr=<root(); // the following dump_node() call causes crash: $nodeContent =$root->dump_node($root); // the following dump_mem() call succeeds, using $with_attr: //$nodeContent =$doc->dump_mem(); echo htmlentities($nodeContent); // php appears to have crashed; the following text is not printed: echo "hi"; ?> I am using PHP 4.3.0 configured as: ./configure --with-dom --with-zlib-dir=/usr/include --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-xml --enable-track-vars -- Edit this bug report at http://bugs.php.net/?id=21477&edit=1
#21479 [Opn->Fbk]: function crashes when used with a URL
ID: 21479
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: GetImageSize related
Operating System: Windows 2000
PHP Version: 4.3.0
New Comment:
Does this happen with every image you try or a specific image or two?
In the event of the latter could you please provide a URL to the
offending image.
Previous Comments:
[2003-01-06 20:17:33] [EMAIL PROTECTED]
function ImgExists($f) {
$r=@getimagesize("http://localhost/$f";);
return $r[2]!=0;
}
if(ImgExists('icon.jpg')) echo('exists!');
when calling this function, php.exe (4.3.0 as CGI in IIS4) is crashing.
remark out the 'getimagesize' line, and it won't crash.
i can email my php.ini on request.
--
Edit this bug report at http://bugs.php.net/?id=21479&edit=1
#21309 [Asn->Csd]: ftp_connect error reporting of trivial errors trough perror()
ID: 21309 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: FTP related Operating System: linux PHP Version: 4.3.0 Assigned To: sesser New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-02 19:30:41] [EMAIL PROTECTED] Note: I just sent a patch for it to php-dev. Thank you for reviewing it. [2002-12-31 04:53:32] [EMAIL PROTECTED] Verified, the whole FTP code uses perror() and not php_error_docref(). It also makes use of free() and malloc() and doesn't use the zend memory manager for it. Derick [2002-12-31 04:50:07] [EMAIL PROTECTED] ftp_connect() returns stream or false on error this is not the case for error messages like "connect: Connection timed out" which go trough perror() calls inside the extension theese should be actively removed or replaced with E_WARNING or E_NOTICE errors which can be actively ignored/handled by script. -- Edit this bug report at http://bugs.php.net/?id=21309&edit=1
#21283 [Com]: Apache2 & PHP4.3 leak memory when respond to requests
ID: 21283 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: Windows2000(japanese version) PHP Version: 4.3.0 New Comment: Is there any test I can do to help fixing this problem? I'm completely new to debugging open source softwares, but I'm willing to do if I could have directions from Wizards. Previous Comments: [2002-12-30 03:16:16] [EMAIL PROTECTED] php enabled:foo.php -> leaks php enabled:foo.html -> does not leak php disabled:foo.html -> does not leak the contents of foo.php & foo.html is same, just ''. hope this helps. tamagawa [2002-12-30 01:53:06] [EMAIL PROTECTED] Does it also leak when you disable PHP (ie. when you dont load the module)? Derick [2002-12-30 01:30:46] [EMAIL PROTECTED] I set up PHP4.3.0(DLL) & Apache2.0.43. Each time client browsers access to foo.php file, PHP&Apache leak certain amout of memory. I put a file named foo.php which contains just '' in htdocs directory, and I access that file from mozilla1.2. When i repeatedly reload foo.php, amout memory that Apache2 uses grows(seems about 100 bytes/req). I confirmed the growth with Window's task manager. Apache's http.conf is 'as is' distributed and PHP4.3's ini is same as ini-recommended. -- Edit this bug report at http://bugs.php.net/?id=21283&edit=1
#21479 [NEW]: function crashes when used with a URL
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.3.0
PHP Bug Type: GetImageSize related
Bug description: function crashes when used with a URL
function ImgExists($f) {
$r=@getimagesize("http://localhost/$f";);
return $r[2]!=0;
}
if(ImgExists('icon.jpg')) echo('exists!');
when calling this function, php.exe (4.3.0 as CGI in IIS4) is crashing.
remark out the 'getimagesize' line, and it won't crash.
i can email my php.ini on request.
--
Edit bug report at http://bugs.php.net/?id=21479&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21479&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21479&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21479&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21479&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21479&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21479&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21479&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21479&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21479&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21479&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21479&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21479&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21479&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21479&r=gnused
#21435 [Csd->Opn]: termination when calling mysql_info()
ID: 21435 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 4.3.0 Assigned To: georg Previous Comments: [2003-01-06 18:13:37] [EMAIL PROTECTED] I think this is not the solution ... i just downloaded the 22:30 Snapshot of Jan 01st (stabel 4.3.0) and I get a SegVault calling mysql_info($vk). calling mysql_info() (without parameter) seems to work! [2003-01-05 15:11:57] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-05 14:25:37] [EMAIL PROTECTED] verified... assigned to myself [2003-01-05 13:11:03] [EMAIL PROTECTED] As you have MSVC, would you be able to provide a stack trace (which you should have on the screen when you see those assembler code lines)? Derick [2003-01-05 13:09:21] [EMAIL PROTECTED] when calling mysql_info() apache 1.3.24 terminates with an error: "The instruction at "0x100c1588" referenced memory at "0x000a". the memory could not be "read" [ok/debug]. M$ debug gives "100C1588 cmp byte ptr [eax+8],7" script when calling: regards, -Wolfgang -- Edit this bug report at http://bugs.php.net/?id=21435&edit=1
#21476 [Opn->Bgs]: Refering to Bug #21435
ID: 21476 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Linux PHP Version: 4CVS-2003-01-06 (stable) New Comment: Opening back #21435 Previous Comments: [2003-01-06 18:19:41] [EMAIL PROTECTED] Bug #21435 seems not to be solved yet ... as I posted as an additional comment to this Bug I downloaded the 22:30 Snapshot on Jan 7th (invalid in my comment). the error seems to appear only if calling with parameter ( mysql_info($vk) ) ! Calling without parameter ( mysql_info() ) works fine! -- Edit this bug report at http://bugs.php.net/?id=21476&edit=1
#21478 [NEW]: stream_get_filters(true) can cause segfault on script exit
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4CVS-2003-01-06 (dev) PHP Bug Type: Reproducible crash Bug description: stream_get_filters(true) can cause segfault on script exit This is a note to myself to fix this. When stream_get_filters(true) is called between stream_register_filter() and stream_fitler_(ap|pre)pend(), engine will segfault on script exit. -- Edit bug report at http://bugs.php.net/?id=21478&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21478&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21478&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21478&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21478&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21478&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21478&r=support Expected behavior: http://bugs.php.net/fix.php?id=21478&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21478&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21478&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21478&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21478&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21478&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21478&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21478&r=gnused
#21477 [NEW]: $node->dump_node($node) crashes when node has any attribute
From: [EMAIL PROTECTED] Operating system: linux; kernel 2.4.18 PHP version: 4.3.0 PHP Bug Type: DOM XML related Bug description: $node->dump_node($node) crashes when node has any attribute hi eot; // this text avoids crash: $without_attr=<root(); // the following dump_node() call causes crash: $nodeContent =$root->dump_node($root); // the following dump_mem() call succeeds, using $with_attr: //$nodeContent =$doc->dump_mem(); echo htmlentities($nodeContent); // php appears to have crashed; the following text is not printed: echo "hi"; ?> I am using PHP 4.3.0 configured as: ./configure --with-dom --with-zlib-dir=/usr/include --with-mysql=/usr/local/mysql --with-apxs=/usr/local/apache/bin/apxs --with-xml --enable-track-vars -- Edit bug report at http://bugs.php.net/?id=21477&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21477&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21477&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21477&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21477&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21477&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21477&r=support Expected behavior: http://bugs.php.net/fix.php?id=21477&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21477&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21477&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21477&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21477&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21477&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21477&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21477&r=gnused
#21476 [NEW]: Refering to Bug #21435
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4CVS-2003-01-06 (stable) PHP Bug Type: MySQL related Bug description: Refering to Bug #21435 Bug #21435 seems not to be solved yet ... as I posted as an additional comment to this Bug I downloaded the 22:30 Snapshot on Jan 7th (invalid in my comment). the error seems to appear only if calling with parameter ( mysql_info($vk) ) ! Calling without parameter ( mysql_info() ) works fine! -- Edit bug report at http://bugs.php.net/?id=21476&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21476&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21476&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21476&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21476&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21476&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21476&r=support Expected behavior: http://bugs.php.net/fix.php?id=21476&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21476&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21476&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21476&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21476&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21476&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21476&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21476&r=gnused
#21435 [Com]: termination when calling mysql_info()
ID: 21435 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 4.3.0 Assigned To: georg New Comment: I think this is not the solution ... i just downloaded the 22:30 Snapshot of Jan 01st (stabel 4.3.0) and I get a SegVault calling mysql_info($vk). calling mysql_info() (without parameter) seems to work! Previous Comments: [2003-01-05 15:11:57] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-01-05 14:25:37] [EMAIL PROTECTED] verified... assigned to myself [2003-01-05 13:11:03] [EMAIL PROTECTED] As you have MSVC, would you be able to provide a stack trace (which you should have on the screen when you see those assembler code lines)? Derick [2003-01-05 13:09:21] [EMAIL PROTECTED] when calling mysql_info() apache 1.3.24 terminates with an error: "The instruction at "0x100c1588" referenced memory at "0x000a". the memory could not be "read" [ok/debug]. M$ debug gives "100C1588 cmp byte ptr [eax+8],7" script when calling: regards, -Wolfgang -- Edit this bug report at http://bugs.php.net/?id=21435&edit=1
#20358 [Com]: Apache is "Segmentation fault" by session_start() with libmm
ID: 20358
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Session related
Operating System: RedHat7.3
PHP Version: 4.3.0-dev
New Comment:
Same problem here
Tried the latest snapshot no difference
Willing to produce a backtrace if neccesary
Redhat 7.3
Apache 2.0.43
PHP 4.3.0 and latest snapshot
I have a Typo3 CMS and can make the segmentation fault happen on
command with the install tool.
Previous Comments:
[2002-12-16 14:37:58] [EMAIL PROTECTED]
Same problem here...
Sparc Solaris 8, php-4.2.3, apache-1.3.27
[2002-12-16 02:41:49] [EMAIL PROTECTED]
Hi,
I have experienced the same bug on my linux box with several versions
of httpd/php
Redhat7.3 PHP 4.3.2 4.3.0-pre1 4.3.0-rc1 4.3.0-rc2
Apache 1.3.27.
It can happen at any time (like 24h after launching httpd) and it then
crashes every apache child.
Obviously, the structure data->hash[slot] is not properly initialized
before entering in ps_sd_lookup, but that is quite strange !
It think it should be fixed before 4.3.0 release.
[2002-12-13 08:46:30] [EMAIL PROTECTED]
FreeBSD, Apache 1.3.27, PHP 4.2.3
#0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at
mod_mm.c:168
168 for (prev = data->hash[slot]; prev->next != sd;
prev = prev->next);
(gdb) bt
#0 0x48287655 in ps_sd_destroy (data=0x811b0a0, sd=0x4c6c2354) at
mod_mm.c:168
#1 0x4828784f in ps_mm_destroy (data=0x811b0a0) at mod_mm.c:242
#2 0x48287a25 in zm_shutdown_ps_mm (type=1, module_number=11) at
mod_mm.c:293
#3 0x48231e93 in module_destructor (module=0x811c500) at
zend_API.c:1127
#4 0x482338d3 in zend_hash_destroy (ht=0x48333b80) at zend_hash.c:541
#5 0x4822ef3f in zend_shutdown () at zend.c:492
#6 0x4823c107 in php_module_shutdown () at main.c:1052
#7 0x4823c0d4 in php_module_shutdown_wrapper
(sapi_globals=0x48311880)
at main.c:1029
#8 0x48239abc in apache_php_module_shutdown_wrapper () at
mod_php4.c:800
#9 0x805003a in run_cleanups ()
#10 0x804f09f in ap_clear_pool ()
#11 0x804f100 in ap_destroy_pool ()
#12 0x804f08b in ap_clear_pool ()
#13 0x804f100 in ap_destroy_pool ()
#14 0x8059460 in clean_parent_exit ()
#15 0x805b925 in standalone_main ()
#16 0x805bd6b in main ()
#17 0x804eb0d in _start ()
(gdb) print *data
$3 = {mm = 0x4c69b414, hash = 0x4c69b434, hash_max = 511, hash_cnt =
0,
owner = 81324}
(gdb) print *sd
$4 = {next = 0x3e0, hv = 979, ctime = 1282159212, data = 0x74656c73,
datalen = 2087871860, alloclen = 976304755, key = "\""}
(gdb) print slot
$5 = 1282155348
(gdb) print data->hash
$6 = (ps_sd **) 0x4c69b434
(gdb) print *(data->hash)
$7 = (ps_sd *) 0x4c6c2354
(gdb) print *prev
Cannot access memory at address 0x10.
[2002-11-12 06:01:38] [EMAIL PROTECTED]
more info...
(gdb) list
182
183 hv = ps_sd_hash(key, strlen(key));
184 slot = hv & data->hash_max;
185
186 for (prev = NULL, ret = data->hash[slot]; ret; prev =
ret, ret =
ret->next)
187 if (ret->hv == hv && !strcmp(ret->key, key))
188 break;
189
190 if (ret && rw && ret != data->hash[slot]) {
191 /* Move the entry to the top of the linked list
*/
(gdb) print key
$1 = 0x8136f2c "136"
(gdb) print hv
$2 = 1943406893
(gdb) print slot
$3 = 301
(gdb) print data->hash_max
$4 = 511
(gdb) print prev
$5 = (ps_sd *) 0x4413df00
(gdb) print ret
$6 = (ps_sd *) 0x1f
(gdb) print ret->next
Cannot access memory at address 0x1f
(gdb) print data->hash[slot]->next
$7 = (struct ps_sd *) 0x1f
[2002-11-12 05:51:51] [EMAIL PROTECTED]
Apache was re-compiled with -DBIG_SECURITY_HOLE option.
edit /usr/local/apache/conf/httpd.conf
User root
Group root
CoreDumpDirectory /tmp
# /usr/local/apache/bin/apachectl start
# sh loop.sh
# tail -f /usr/local/apache/logs/error_log
[Tue Nov 12 20:41:49 2002] [notice] child pid 23351 exit signal
Segmentation fault (11), possible coredump in /tmp
child proccess of apache was core dumped.
back trace
(gdb) bt
#0 0x40148a33 in ps_sd_lookup (data=0x80d4418, key=0x8136f2c "136",
rw=0)
at /home/work/httpd/php-4.3.0pre2/ext/session/mod_mm.c:187
#1 0x40148ec8 in ps_read_mm (mod_data=0x4029ea70, key=0x8136f2c
"136",
val=0xbfffd1e0, vallen=0xbfffd1dc)
at /home/work/httpd/php-4.3.0pre2/ext/session/mod_mm.c:326
#2 0x401446b9 in php_session_initialize ()
at /home/work/httpd/php-4.3.0pre2/ext/session/session.c:608
#3 0x40145864 in php_session_start ()
at /home/work/httpd/php-
#21406 [Opn->Csd]: Appending same filter twice causes segfault
ID: 21406
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Filesystem function related
Operating System: linux
PHP Version: 4CVS-2003-01-03 (dev)
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-01-04 13:54:36] [EMAIL PROTECTED]
The backtrace tottalled up to over 11MB so I've put it on a webserver
for you to grab. I also made a gzip -9 version to save downloading
time.
http://169.229.139.97/backtrace (~11.8MB)
http://169.229.139.97/backtrace.gz (~530KB)
I can save you even that much downloading though by telling you that it
seems the execution just goes into an infinite loop calling:
#1122 0x080b403a in userfilter_flush (stream=0x817ace4,
thisfilter=0x817adb4, closing=1) at
/home/sarag/cvs/php4/ext/standard/user_filters.c:255
#1123 0x080b3cce in zif_user_filter_flush (ht=1,
return_value=0x82aeaf4, this_ptr=0x817ae34, return_value_used=1) at
/home/sarag/cvs/php4/ext/standard/user_filters.c:107
#1124 0x080ed80c in call_user_function_ex (function_table=0x817a850,
object_pp=0xbf826890, function_name=0xbf8268a0,
retval_ptr_ptr=0xbf826894, param_count=1,
params=0xbf826898, no_separation=0, symbol_table=0x0) at
/home/sarag/cvs/php4/Zend/zend_execute_API.c:584
The pointers change, but the commands and the their sequence remain the
same...over...and over...and over...and over...
An early morning guess would say that the filterhead chain isn't being
setup properly.
Though as a slight aside, why does the fops structure show eof/dtor
methods when user_filter.c calls them oncreate/onclose ? When are
oncreate/onclose called?
[2003-01-04 04:41:10] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Always include a backtrace in reports of segfaults or bus errors (it
saves a good 15 minutes or more of my time!)
Thanks!
[2003-01-03 22:37:45] [EMAIL PROTECTED]
Correction... Any two filters:
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "rot13");
or
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "default");
or
stream_filter_append($fp, "default");
stream_filter_append($fp, "default");
all produce the same segfault when fclose()ing (presumably during the
calls to write() or flush() in the filters).
Note: "default" was previously registered using:
stream_register_filter("default", "php_user_filter");
[2003-01-03 22:30:11] [EMAIL PROTECTED]
The following code works fine when "stream_filter_append()" is called
only once. Adding the second call causes a segfault when fclose() is
called.
= 'A' AND $tempstr[$i] <= 'M') OR
($tempstr[$i] >= 'a' AND $tempstr[$i] <= 'm')) $tempstr[$i] =
chr(ord($tempstr[$i]) + 13);
else if (($tempstr[$i] >= 'N' AND $tempstr[$i] <= 'Z') OR
($tempstr[$i] >= 'n' AND $tempstr[$i] <= 'z'))
$tempstr[$i] = chr(ord($tempstr[$i]) - 13);
return $tempstr;
}
function write($data) {
for($i = 0; $i < strlen($data); $i++)
if (($data[$i] >= 'A' AND $data[$i] <= 'M') OR
($data[$i] >= 'a' AND $data[$i] <= 'm')) $data[$i] =
chr(ord($data[$i]) + 13);
else if (($data[$i] >= 'N' AND $data[$i] <= 'Z') OR
($data[$i] >= 'n' AND $data[$i] <= 'z')) $data[$i] =
chr(ord($data[$i]) - 13);
return parent::write($data);
}
}
stream_register_filter("rot13", "rot13_filter")
or die("Failed to register filter");
$fp = fopen("foo-bar.txt", "r");
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "rot13");
fwrite($fp, "Line1\n");
fwrite($fp, "Word - 2\n");
fwrite($fp, "Easy As 123\n");
fclose($fp);
?>
--
Edit this bug report at http://bugs.php.net/?id=21406&edit=1
#20827 [Opn->Csd]: stat macro
ID: 20827 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Tru64 PHP Version: 4.3.0RC2 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-06 16:18:35] [EMAIL PROTECTED] Same thing happens with 4.3.0 release, in the same file main/streams.c but on line 677 [2002-12-05 08:52:35] [EMAIL PROTECTED] When compile PHP-4.3.0RC2 on Tru64 arch, I got : [.] /usr/local/tmp/php-4.3.0RC2/main/streams.c: In function `_php_stream_stat': /usr/local/tmp/php-4.3.0RC2/main/streams.c:655: structure has no member named `_F64_stat' [.] The bogus line is : return stream->ops->stat(stream, ssb TSRMLS_CC); Indeed, on this arch, 'stat' is a macro to '_F64_stat' whereas it use here as a member of struct '_php_stream_ops'. So I've added parenthesis to prevent macro expansion : return (stream->ops->stat)(stream, ssb TSRMLS_CC); PS: I saw the same pb on CVS version. Sincerly, Julien -- Edit this bug report at http://bugs.php.net/?id=20827&edit=1
#21475 [NEW]: Conflict in versions of gds32.dll
From: [EMAIL PROTECTED] Operating system: WIN32 PHP version: 4.3.0 PHP Bug Type: InterBase related Bug description: Conflict in versions of gds32.dll Using Interbase 5.6 and precompiled Win32 version of PHP (not only 4.3.0, also in 4.1.0) I've found, that there is conflict in gds32.dll. PHP can't work with file from Interbase installation, and Interbase cant work with same file from PHP. -- Edit bug report at http://bugs.php.net/?id=21475&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21475&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21475&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21475&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21475&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21475&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21475&r=support Expected behavior: http://bugs.php.net/fix.php?id=21475&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21475&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21475&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21475&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21475&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21475&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21475&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21475&r=gnused
#21466 [Opn->Fbk]: configure bug in XSLT/Sablotron and Zip options
ID: 21466 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: RedHat Linux PHP Version: 4.3.0 New Comment: When you get 'configure: error: zziplib module requires zzlib >= 0.10.6' Open the file called config.log and look at the text at the very bottom of the file. There should be a reason indicating why test for zzlib had failed, please include that text in your reply. Previous Comments: [2003-01-06 11:25:22] [EMAIL PROTECTED] Hi guys, I perhaps found a "mystery" bug in ./configure process... check out when I try: CFLAGS='-O2 -I/usr/local/ssl/include/openssl/' \ ./configure \ --with-apache=../apache_1.3.27 \ --with-mysql \ --enable-track-vars \ --enable-ftp \ --with-gettext \ --with-imap=/usr/lib \ --with-pdflib=/usr/local \ --enable-static-pdflib \ --with-gd \ --with-tiff-dir=/usr/lib \ --with-jpeg-dir=/usr/lib \ --with-png-dir=/usr/lib \ --with-zlib-dir=/usr/include \ --enable-xslt \ --with-xslt-sablot \ --with-zip I got an error message: configure: error: zziplib module requires zzlib >= 0.10.6. zzlib version 0.10.66 I has installed on my system in path: /usr/local/lib when I kick out options: --enable-xslt AND --with-xslt-sablot then the configure process done OK. When kick out --with-zip AND leave there both --enable-xslt AND --with-xslt-sablot then the configure done OK again. The problem is when together: --enable-xslt \ --with-xslt-sablot \ --with-zip On my home server RedHat 8.0 everything OK, on the production server RedHat 7.1 + upgrades I found this "bug". Feedback please. Regards Lubo Kopacek, Slovakia -- Edit this bug report at http://bugs.php.net/?id=21466&edit=1
#21467 [Opn->Bgs]: crash without any error
ID: 21467 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: linux debian PHP Version: 4.3.0 New Comment: 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 I am not sure why you are not seeing an error, it could be due to error_reporting being set to 0 or php.ini directive indicate errors should not be shown. The code you have does generate a fatal error, for your benefit I am including it here: PHP Fatal error: Cannot redeclare test() in c.php on line 6 php4/c.php(6) : Fatal error - Cannot redeclare test() Fatal error: Cannot redeclare test() in c.php on line 6 Previous Comments: [2003-01-06 11:37:17] [EMAIL PROTECTED] forgot to mention that the version it worked correctly is 4.1.2 (if can be defined correctly at all, i mean the script was working) [2003-01-06 11:34:26] [EMAIL PROTECTED] when I try this done I minimized the problem, which I found with an old code using FastTemplate nothing happens - no errors, no warning, no output - just sending headers and thats all I am not sure if it is leagal code, but I'm sure it should get some error or warning message at least, or work of course I installed it on apache web server, but the cli version is working the same way ( not working ) compiled the PHP with --enable-debug, and still no difference - no messages of any kind -- Edit this bug report at http://bugs.php.net/?id=21467&edit=1
#20827 [Com]: stat macro
ID: 20827 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Tru64 PHP Version: 4.3.0RC2 New Comment: Same thing happens with 4.3.0 release, in the same file main/streams.c but on line 677 Previous Comments: [2002-12-05 08:52:35] [EMAIL PROTECTED] When compile PHP-4.3.0RC2 on Tru64 arch, I got : [.] /usr/local/tmp/php-4.3.0RC2/main/streams.c: In function `_php_stream_stat': /usr/local/tmp/php-4.3.0RC2/main/streams.c:655: structure has no member named `_F64_stat' [.] The bogus line is : return stream->ops->stat(stream, ssb TSRMLS_CC); Indeed, on this arch, 'stat' is a macro to '_F64_stat' whereas it use here as a member of struct '_php_stream_ops'. So I've added parenthesis to prevent macro expansion : return (stream->ops->stat)(stream, ssb TSRMLS_CC); PS: I saw the same pb on CVS version. Sincerly, Julien -- Edit this bug report at http://bugs.php.net/?id=20827&edit=1
#21453 [Opn->Csd]: strip_tags behaviour change
ID: 21453
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Strings related
Operating System: Windows XP
PHP Version: 4.3.0
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-01-06 01:14:11] [EMAIL PROTECTED]
A "<" as plaintext is something strip_tags can't make much sense of,
sure. My previous report ( http://bugs.php.net/bug.php?id=21253 ) was
indeed bogus, but what about this.
");
$test = "\nfirst cell before < first cell
after\nsecond cell before < second cell
after\n\n";
$testarray = explode("\n",strip_tags($test));
print_r($testarray);
print("");
/*
4.2.3
=
Array
(
[0] =>
[1] => first cell before
[2] => second cell before
[3] =>
[4] =>
)
4.3.0
=
Array
(
[0] =>
[1] => first cell before
)
*/
?>
Is this also per design? Parsing third-party webpages created by
someone/some program that disregards that < should be used instead
of "<" became a bit more difficult with 4.3.0. Not hard to code around,
but certainly an annoyance compared to 4.2.3.
--
Edit this bug report at http://bugs.php.net/?id=21453&edit=1
#21473 [NEW]: Content-Type header ignored when default character encoding set in php.ini
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.3
PHP Bug Type: Output Control
Bug description: Content-Type header ignored when default character encoding set in
php.ini
In php 4.2.3, if a value is specifed for the default_charset variable in
/etc/php.ini, attempts to modify the content type using:
header("Content-Type: text/vnd.wap.wml");
will be ignored by PHP:
> telnet www.buberel.org 80
Trying 10.0.0.1...
Connected to taylor.buberel.org (10.0.0.1).
Escape character is '^]'.
get /wapmail/test.php HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 06 Jan 2003 21:32:01 GMT
Server: Apache-AdvancedExtranetServer/1.3.26 (Mandrake Linux/6.1mdk)
mod_ssl/2.8.10 OpenSSL/0.9.6g PHP/4.2.3
X-Powered-By: PHP/4.2.3
Connection: close
Content-Type: text/html; charset=iso-8859-15
However, when the value of default_charset is set to the empty string ("")
in /etc/php.ini, the content-type header is handled properly:
> telnet www.buberel.org 80
Trying 10.0.0.1...
Connected to taylor.buberel.org (10.0.0.1).
Escape character is '^]'.
get /wapmail/test.php HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 06 Jan 2003 22:02:04 GMT
Server: Apache-AdvancedExtranetServer/1.3.26 (Mandrake Linux/6.1mdk)
mod_ssl/2.8.10 OpenSSL/0.9.6g PHP/4.2.3
X-Powered-By: PHP/4.2.3
Random-Header: x/y
Connection: close
Content-Type: text/vnd.wap.wml
-jason
--
Edit bug report at http://bugs.php.net/?id=21473&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21473&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21473&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21473&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21473&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21473&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21473&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21473&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21473&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21473&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21473&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21473&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21473&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21473&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21473&r=gnused
#21448 [Opn->Bgs]: apache_lookup_uri returns "valid URI" even when passed non-existent filenames
ID: 21448 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Linux (redhat) PHP Version: 4.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. apache_lookup_uri() is a very simple wrapper around Apache 2's own ap_sub_req_lookup_uri() function. Any bugs that you encounter while using that function are in Apache 2 and not PHP. Previous Comments: [2003-01-05 22:11:59] [EMAIL PROTECTED] I've played with this some more. I'm beginning to feel that this is a documentation problem. Neither the Apache or PHP docs say so, but is this just a parsing function that never actually does a stat(2) on the underlying file? I got the impression from the code for virtual() in php-4.3.0/sapi/apache2filter that it did more, but perhaps it is a misunderstanding on my part. This is probably a closable entry in your bug database...sorry. [2003-01-05 19:44:13] [EMAIL PROTECTED] I compiled Apache 2.0.43 and PHP 4.3.0 from source as a DSO. When using the internal PHP apache_lookup_uri(), it always returns status 200. status; echo $f->the_request; ?> I always get 200, and the URI of the PHP file in which it is enclosed. Does anyone know the apache API??? I dug through the source, but I don't know much about the Apache filter chains and the linkage of the request structures. I'll try to look further when I get a chance, but if anyone has any ideas, I'd love to hear them. - Tony -- Edit this bug report at http://bugs.php.net/?id=21448&edit=1
#21472 [Opn->Fbk]: Problems with short tags and
ID: 21472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: Please be specific with the questions below: 1) EXACTLY what does (a) say from below? 2) Did you restart the web server after editing? 3) What does phpinfo() say for this directive? 4) What value are you assigning to this directive in php.ini? Previous Comments: [2003-01-06 15:26:05] [EMAIL PROTECTED] It is in c:\WINNT, the one I have been modifying all the time. Same situation. [2003-01-06 15:23:51] [EMAIL PROTECTED] Please look at phpinfo() for the true location of the used php.ini and the true setting for the short_open_tag directive. So: a) Tell us exactly what "Configuration File (php.ini) Path" is in phpinfo(). b) Make sure you edit this file. c) Make sure you restart the web server after making changes to php.ini d) See what phpinfo() says about this directive. [2003-01-06 14:47:48] [EMAIL PROTECTED] I have noticed that using short tags in PHP files does not work on any of my servers, all WIN2K. When using short tags for includes the file will not be included and the page will not load correctly, using a long tag will work. Short tags are turned on in the php.ini. Also
#21443 [Opn->Csd]: get_browser still has problems with browsecap.ini from www.garykeith.com
ID: 21443 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-05 22:38:43] [EMAIL PROTECTED] Thanks, Serge. Ilia, I think this is fairly solid proof that my suspicions are correct about get_browser() having a problem dealing with multiple question marks in the user agent. The old definition in my browscap.ini file: Mozilla/4.8 (Windows NT 5.0; U) fails while the updated definition: Mozilla/4.8*(Windows NT 5.0; U) works fine. Both definitions work fine with browscap.dll therefore I suspect a problem with get_browser(). [2003-01-05 22:25:51] [EMAIL PROTECTED] I updated the browscap.ini and the detection works fine now with Netscape for windows: ua: Mozilla/4.8 [en] (Windows NT 5.0; U) pattern match: browser_name_pattern Mozilla/4\.8.*(Windows NT 5\.0; U) [2003-01-05 21:49:27] [EMAIL PROTECTED] Ilia, I am the developer of the browscap.ini file that PHP recommends to its users. Respectfully, this issue does appear to be a bug in PHP. The user agent in question, Mozilla/4.8 [en] (Windows NT 5.0; U), is in my browscap.ini file and it is recognized when Serge visits my website which uses IIS. To me that suggests a bug in get_browser(). I am suspicious that in certain situations get_browser() has a problem dealing with multiple question marks in a user agent. In an attempt to prove my theory I changed the definition for the user agent in question and asked Serge to see if it works. I'll report back here on his results. [2003-01-05 15:41:02] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Contact the developer mantaining the browsecap.ini, this is not a PHP bug. [2003-01-05 15:29:07] [EMAIL PROTECTED] PHP does not detect Netscape for Windows ua: Mozilla/4.8 [en] (Windows NT 5.0; U) It did detect Mozilla 1.2 and IE 6 for Windows and Mozilla 1.1 and Netscape 4.7 in Linux. The latest verion (downloaded January 5 2003) of browsecap.ini was used. -- Edit this bug report at http://bugs.php.net/?id=21443&edit=1
#21468 [Opn->Csd]: get_browser() still has bugs
ID: 21468 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Various PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-06 12:50:01] [EMAIL PROTECTED] I am the developer who maintains the browscap.ini file that is recommended by PHP. Despite some recent bug fixes there still seems to be at least one bug in the get_browser() function. Simply put, multiple question marks surrounded by white space in a user agent definition in browscap.ini creates some sort of error that results in a valid user agent not being recognized by get_browser(). Here's a more detailed example of what I mean. user agent: Mozilla/4.8 [en] (Windows NT 5.0; U) original browscap.ini definition: Mozilla/4.8 (Windows NT 5.0; U) updated browscap.ini definition: Mozilla/4.8*(Windows NT 5.0; U) The original definition resulted in the user agent not being found and the Default browser being returned. The updated definition works fine. This forms the basis of my theory about multiple question marks surrounded by white space. By the way, both definitions are valid and both work just fine on other platforms such as ASP. With the help of a fellow developer we did some further testing to confirm my theory. The following user agent definitions did not result in a match when presented with a user agent that should have created a match: Mozilla/4.76C-CCK-MCD (X11; ?; SunOS 5.? sun4u) Mozilla/4.76C-CCK-MCD vg_472 (X11; ?; SunOS 5.8 sun4u) Mozilla/4.76C-SGI (X11; ?; IRIX64 6.5 IP30) Mozilla/4.79C-CCK-MCD (X11; ?; SunOS 5.6 sun4u) But these did result in matches: Mozilla/4.79 *(Win95; ?) Mozilla/4.78 (Windows 2000; U) Opera 6.05 Mozilla/5.0 (BeOS; ?; BeOS BePC; ?; rv:1.0.?) Gecko/ This seems to suggest a problem only when multiple question marks are surrounded on both sides by white space. I hope this is enough information for someone to attempt a fix. -- Edit this bug report at http://bugs.php.net/?id=21468&edit=1
#21472 [Fbk->Opn]: Problems with short tags and
ID: 21472 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: It is in c:\WINNT, the one I have been modifying all the time. Same situation. Previous Comments: [2003-01-06 15:23:51] [EMAIL PROTECTED] Please look at phpinfo() for the true location of the used php.ini and the true setting for the short_open_tag directive. So: a) Tell us exactly what "Configuration File (php.ini) Path" is in phpinfo(). b) Make sure you edit this file. c) Make sure you restart the web server after making changes to php.ini d) See what phpinfo() says about this directive. [2003-01-06 14:47:48] [EMAIL PROTECTED] I have noticed that using short tags in PHP files does not work on any of my servers, all WIN2K. When using short tags for includes the file will not be included and the page will not load correctly, using a long tag will work. Short tags are turned on in the php.ini. Also
#21472 [Opn->Fbk]: Problems with short tags and
ID: 21472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: Please look at phpinfo() for the true location of the used php.ini and the true setting for the short_open_tag directive. So: a) Tell us exactly what "Configuration File (php.ini) Path" is in phpinfo(). b) Make sure you edit this file. c) Make sure you restart the web server after making changes to php.ini d) See what phpinfo() says about this directive. Previous Comments: [2003-01-06 14:47:48] [EMAIL PROTECTED] I have noticed that using short tags in PHP files does not work on any of my servers, all WIN2K. When using short tags for includes the file will not be included and the page will not load correctly, using a long tag will work. Short tags are turned on in the php.ini. Also
#21462 [Com]: set_error_handler not properly executed?
ID: 21462
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux Slackware
PHP Version: 4.3.0
New Comment:
I am also experimenting this. My function used as error handling now
gives me array in all the parameters.
Ex. :
function my_error_handler($errno,$errstr,$errfile,$errline,$variables)
$errno = array
$errstr = array
etc...
Previous Comments:
[2003-01-06 09:01:50] [EMAIL PROTECTED]
Today we upgraded from php 4.2.3 (apache 1.3.26) to php 4.3.0.
We use freetype functionality in a set of functions and to keep this
very flexible the following code (except for the debugging prints) is
used to determine what freetype version was installed in order to use
the right functions (imagefttext or imagettftext).
This function (the set_error_handler) stopped working properly after
upgrading to 4.3.0
print freetype_version();
function freetype_version() {
// change error handler
set_error_handler("freetype_version_handler");
// remove freetype version from session
unset($_SESSION['freetype_version']);
// determine check array
$checkers = array(
"imagefttext" => 2, // freetype version
specific function -> freetype version
"imagettftext" => 1
);
// run checkers
while (list($key,$val)=each($checkers)) {
printf("%s:%s\n",$key,$val);
eval(sprintf("%s();",$key));
}
// restore old error handler
restore_error_handler();
// return version (null = no freetype support)
return $_SESSION['freetype_version'];
}
function
freetype_version_handler($errno,$errstr,$errfile,$errline,$variables)
{
print "errorrr!\n";
if (eregi(sprintf("wrong parameter count for
%s",$variables['key']),$errstr)) {
$_SESSION['freetype_version'] = $variables['val'];
}
}
The code outputs the following error:
Fatal error: Call to undefined function: imagefttext() in
/sda6/domains/betterbeyourself.com_staging/includes/fnc_lang.inc(651) :
eval()'d code on line 1
We allready use a custom error handler so the above handler is
nested... this however worked very well in 4.2.3 I also noticed the
same problems in some 4.3.0 developmental cvs snapshots (don't know
which snapshots they were though) and thought it was a bug to be solved
before the stable release but appearantly it's still there
Grtz,
Jeroen
--
Edit this bug report at http://bugs.php.net/?id=21462&edit=1
#21472 [NEW]: Problems with short tags and
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: Problems with short tags and
#21471 [Opn->Fbk]: empty variables with apache 2
ID: 21471 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows 2000 Pro PHP Version: 4.2.3 New Comment: Three things: a) What is your register_globals setting? b) Use PHP 4.3.0 c) Read http://www.php.net/variables.predefined Previous Comments: [2003-01-06 14:41:56] [EMAIL PROTECTED] If just installed PHP version 4.2.3 on apache webserver 2.0.43. But some variables ($PHP_SELF, $DOCUMENT_ROOT, $PATH_INFO) are empty. I made a script where the variables $PHP_SELF, $DOCUMENT_ROOT, $PATH_INFO where used. I tested it with the same version of PHP on a apache 1.3.23 and there worked it fine. But on the apache 2.0.43 server it gave a lot of errors. -- Edit this bug report at http://bugs.php.net/?id=21471&edit=1
#21336 [Com]: Session sometime can't function
ID: 21336 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Win 2000 Server PHP Version: 4.3.0 New Comment: I have difinately seen this as well. I was able to go back to 4.2.3 and made sure to replace the php.ini file with my old version and all is well again, but 4.3.0 will not handle sessions for me. Previous Comments: [2003-01-02 19:22:39] [EMAIL PROTECTED] i'm confuse about it now. Not just on 4.3.0, 4.2.3 seem got this problem too. After changed 4.2.3: i have open two browser, one seem everything alright. but one got the same problem. everytime open new session. if the code error. two browser must got the same problem. Mike [2003-01-02 07:29:02] [EMAIL PROTECTED] I'm using session between two pages. But sometime the 4.3.0 can't read the pervious session and then second page was created the new session. And i was confirmed this bug only on 4.3.0 Because i was changed back to 4.2.3. The session error didn't appeared anymore. -- Edit this bug report at http://bugs.php.net/?id=21336&edit=1
#21471 [NEW]: empty variables with apache 2
From: [EMAIL PROTECTED] Operating system: Windows 2000 Pro PHP version: 4.2.3 PHP Bug Type: Apache2 related Bug description: empty variables with apache 2 If just installed PHP version 4.2.3 on apache webserver 2.0.43. But some variables ($PHP_SELF, $DOCUMENT_ROOT, $PATH_INFO) are empty. I made a script where the variables $PHP_SELF, $DOCUMENT_ROOT, $PATH_INFO where used. I tested it with the same version of PHP on a apache 1.3.23 and there worked it fine. But on the apache 2.0.43 server it gave a lot of errors. -- Edit bug report at http://bugs.php.net/?id=21471&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21471&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21471&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21471&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21471&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21471&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21471&r=support Expected behavior: http://bugs.php.net/fix.php?id=21471&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21471&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21471&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21471&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21471&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21471&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21471&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21471&r=gnused
#21470 [NEW]: add imagecopyrotated from latest gd
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: add imagecopyrotated from latest gd http://www.boutell.com/gd/ has a patch against php 4.2.3 that adds the imagecopyrotated() function from the gdImageCopyRotated() function that was added in gd 2.0.8. I would be nice if this were a part of the php tree. -- Edit bug report at http://bugs.php.net/?id=21470&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21470&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21470&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21470&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21470&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21470&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21470&r=support Expected behavior: http://bugs.php.net/fix.php?id=21470&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21470&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21470&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21470&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21470&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21470&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21470&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21470&r=gnused
#21469 [Bgs]: mysql module compile problem
ID: 21469 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Compile Failure Operating System: Linux - Redhat 8 PHP Version: 4.3.0 New Comment: BTW, it's a very common warning and the compile ran fine. It's not fatal even though it may appear to be as it's the last line of output during compile. I'm making a faq entry for this question as it sure comes up a lot :) Previous Comments: [2003-01-06 13:25:15] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. [2003-01-06 13:21:55] [EMAIL PROTECTED] This has been going on for the last few version updates. I am having to compile with the inhouse mysql client stuff on one server but I am unable to do that because of the following error in the make process. ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /home/blahblah/temp/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' My configure string is: ./configure --enable-force-cgi-redirect --enable-pic --with-bz2 --with-curl --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext --with-png --with-pspell --with-jpeg-dir=/usr --with-kerberos=/usr/kerberos --with-xml --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --with-imap=shared --with-pgsql=shared --enable-bcmath --with-mysql --with-ftp --with-apxs=/apache/bin/apxs The last version I was able to compile without this error which I am still running because of this was: PHP Version 4.2.3 Any help on this would be appreciated. -- Edit this bug report at http://bugs.php.net/?id=21469&edit=1
#21375 [Opn]: Changes in configure.in do not allow the creation of a sane configure
ID: 21375
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Compile Issues
Operating System: Solaris 8
PHP Version: 4CVS-2003-01-02 (dev)
New Comment:
More information: (using CVS from today 2003-01-06)
I had installed the following versions
automake 1.4
libtool 1.4
autoconf 2.13
Gnu m4 1.4
which according to buil/buildcheck.sh should be OK (and which indeed
used to build from CVS w/o trouble)
To try and see if it will work w/ a new version, I installed:
autoconf 2.57
automake 1.7.2
and then I rerun:
% ./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.57 (ok)
buildconf: Your version of autoconf likely contains buggy cache code.
Running cvsclean for you.
To avoid this, install autoconf-2.13 and automake-1.5.
buildconf: automake version 1.7.2 (ok)
buildconf: libtool version 1.4 (ok)
rebuilding configure
configure.in:831: warning: AC_PROG_LIBTOOL is m4_require'd but is not
m4_defun'd
configure.in:146: error: possibly undefined macro: AC_MSG_RESULT
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.in:295: error: possibly undefined macro: AC_DEFINE
configure.in:1064: error: possibly undefined macro: AC_PROG_LIBTOOL
configure:100054: error: possibly undefined macro:
_LT_AC_TRY_DLOPEN_SELF
rebuilding acconfig.h
rebuilding main/php_config.h.in
configure.in:831: m4: Undefined macro `AC_PROG_LIBTOOL'
Seems like it is unhappy somehow.
At last I risked it an tried using the same './configure' call as
before and I get the same error (on a different line now), namely:
"...
checking whether dlsym() requires a leading underscore in symbol
names... ./configure: line 100042: syntax error near unexpected token
`_LT_AC_TRY_DLOPEN_SELF('
./configure: line 100042: `_LT_AC_TRY_DLOPEN_SELF('
..."
Previous Comments:
[2003-01-02 20:53:14] [EMAIL PROTECTED]
There have been at least 2 changes since I last built from CVS on
Solaris 8 (October 13, 2002)
The first one is the addition to grep of Gnu grep only parameters w/o
checking for the existence of said option in the target OS (changed to
gnu grep manually in configure.in)
The second one is that it seems like the file is using macros from a
newer autoconf (only msg I saw in the logs for configure.in is from rev
1.394: "Don't use autoconf 2.52 macros.")
If a newer autoconf is required, it should be documented, or a warning
should be generated. Instead of a broken configure that later on
fails.
% autoconf --version
Autoconf version 2.13
Tried doing a "buildconf" on today's CVS (2003/01/02) and got:
% ./buildconf
using default Zend directory
rebuilding configure
configure.in:831: /opt/sfw/bin/gm4: Undefined macro `AC_PROG_LIBTOOL'
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
configure.in:1064:AC_PROG_LIBTOOL
configure.in:1142:AC_DEFINE([HAVE_BUILD_DEFS_H], 1, [ ])
configure.in:146:AC_MSG_RESULT(${1}.${2} (ok))
configure.in:166:AC_MSG_RESULT(${1}.${2}.${3} (ok))
configure.in:238:AC_MSG_RESULT([$PHP_SAPI])
configure.in:295: AC_DEFINE(HAVE_LIBDL, 1, [ ])
configure.in:422: AC_DEFINE(HAVE_SOCKADDR_STORAGE,1,[Whether you have
struct sockaddr_storage])
configure.in:431:[AC_DEFINE(HAVE_SOCKADDR_LEN,1,[Whether sockaddr
struct has sa_len])],
configure.in:518: AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the
getaddrinfo function])
configure.in:545:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t])
configure.in:547: AC_DEFINE(in_addr_t, u_int, [ ])
configure.in:635: AC_DEFINE(PHP_SAFE_MODE,1,[ ])
configure.in:637: AC_DEFINE(PHP_SAFE_MODE,0,[ ])
configure.in:647:
AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
configure.in:648: AC_MSG_RESULT([/usr/local/php/bin])
configure.in:650:
AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,"$withval", [ ])
configure.in:651: AC_MSG_RESULT([$withval])
configure.in:654:
AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
configure.in:655:AC_MSG_RESULT([/usr/local/php/bin])
configure.in:658:
AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
configure.in:659: AC_MSG_RESULT([/usr/local/php/bin])
configure.in:666: AC_DEFINE(PHP_SIGCHILD, 1, [ ])
configure.in:668: AC_DEFINE(PHP_SIGCHILD, 0, [ ])
configure.in:675: AC_DEFINE(MAGIC_QUOTES, 1, [ ])
configure.in:677: AC_DEFINE(MAGIC_QUOTES, 0, [ ])
configure.in:700: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,"1",[ ])
configure.in:702: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,"0",[ ])
configure.in:712:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have
dmalloc])
configure.in:723: AC_DEFINE(HAVE_IPV6,1,[Whether to enable IPv6
support])
configure.in:742: AC_DEFINE(HAVE_CRYPT,1,[ ])
configure.in:795:AC_MSG_RESUL
#21469 [Opn->Bgs]: mysql module compile problem
ID: 21469 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Linux - Redhat 8 PHP Version: 4.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Previous Comments: [2003-01-06 13:21:55] [EMAIL PROTECTED] This has been going on for the last few version updates. I am having to compile with the inhouse mysql client stuff on one server but I am unable to do that because of the following error in the make process. ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /home/blahblah/temp/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' My configure string is: ./configure --enable-force-cgi-redirect --enable-pic --with-bz2 --with-curl --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext --with-png --with-pspell --with-jpeg-dir=/usr --with-kerberos=/usr/kerberos --with-xml --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --with-imap=shared --with-pgsql=shared --enable-bcmath --with-mysql --with-ftp --with-apxs=/apache/bin/apxs The last version I was able to compile without this error which I am still running because of this was: PHP Version 4.2.3 Any help on this would be appreciated. -- Edit this bug report at http://bugs.php.net/?id=21469&edit=1
#21469 [NEW]: mysql module compile problem
From: [EMAIL PROTECTED] Operating system: Linux - Redhat 8 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: mysql module compile problem This has been going on for the last few version updates. I am having to compile with the inhouse mysql client stuff on one server but I am unable to do that because of the following error in the make process. ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /home/blahblah/temp/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' My configure string is: ./configure --enable-force-cgi-redirect --enable-pic --with-bz2 --with-curl --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext --with-png --with-pspell --with-jpeg-dir=/usr --with-kerberos=/usr/kerberos --with-xml --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --with-imap=shared --with-pgsql=shared --enable-bcmath --with-mysql --with-ftp --with-apxs=/apache/bin/apxs The last version I was able to compile without this error which I am still running because of this was: PHP Version 4.2.3 Any help on this would be appreciated. -- Edit bug report at http://bugs.php.net/?id=21469&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21469&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21469&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21469&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21469&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21469&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21469&r=support Expected behavior: http://bugs.php.net/fix.php?id=21469&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21469&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21469&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21469&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21469&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21469&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21469&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21469&r=gnused
#21443 [Bgs->Opn]: get_browser still has problems with browsecap.ini from www.garykeith.com
ID: 21443 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 Previous Comments: [2003-01-05 22:38:43] [EMAIL PROTECTED] Thanks, Serge. Ilia, I think this is fairly solid proof that my suspicions are correct about get_browser() having a problem dealing with multiple question marks in the user agent. The old definition in my browscap.ini file: Mozilla/4.8 (Windows NT 5.0; U) fails while the updated definition: Mozilla/4.8*(Windows NT 5.0; U) works fine. Both definitions work fine with browscap.dll therefore I suspect a problem with get_browser(). [2003-01-05 22:25:51] [EMAIL PROTECTED] I updated the browscap.ini and the detection works fine now with Netscape for windows: ua: Mozilla/4.8 [en] (Windows NT 5.0; U) pattern match: browser_name_pattern Mozilla/4\.8.*(Windows NT 5\.0; U) [2003-01-05 21:49:27] [EMAIL PROTECTED] Ilia, I am the developer of the browscap.ini file that PHP recommends to its users. Respectfully, this issue does appear to be a bug in PHP. The user agent in question, Mozilla/4.8 [en] (Windows NT 5.0; U), is in my browscap.ini file and it is recognized when Serge visits my website which uses IIS. To me that suggests a bug in get_browser(). I am suspicious that in certain situations get_browser() has a problem dealing with multiple question marks in a user agent. In an attempt to prove my theory I changed the definition for the user agent in question and asked Serge to see if it works. I'll report back here on his results. [2003-01-05 15:41:02] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Contact the developer mantaining the browsecap.ini, this is not a PHP bug. [2003-01-05 15:29:07] [EMAIL PROTECTED] PHP does not detect Netscape for Windows ua: Mozilla/4.8 [en] (Windows NT 5.0; U) It did detect Mozilla 1.2 and IE 6 for Windows and Mozilla 1.1 and Netscape 4.7 in Linux. The latest verion (downloaded January 5 2003) of browsecap.ini was used. -- Edit this bug report at http://bugs.php.net/?id=21443&edit=1
#21468 [NEW]: get_browser() still has bugs
From: [EMAIL PROTECTED] Operating system: Various PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: get_browser() still has bugs I am the developer who maintains the browscap.ini file that is recommended by PHP. Despite some recent bug fixes there still seems to be at least one bug in the get_browser() function. Simply put, multiple question marks surrounded by white space in a user agent definition in browscap.ini creates some sort of error that results in a valid user agent not being recognized by get_browser(). Here's a more detailed example of what I mean. user agent: Mozilla/4.8 [en] (Windows NT 5.0; U) original browscap.ini definition: Mozilla/4.8 (Windows NT 5.0; U) updated browscap.ini definition: Mozilla/4.8*(Windows NT 5.0; U) The original definition resulted in the user agent not being found and the Default browser being returned. The updated definition works fine. This forms the basis of my theory about multiple question marks surrounded by white space. By the way, both definitions are valid and both work just fine on other platforms such as ASP. With the help of a fellow developer we did some further testing to confirm my theory. The following user agent definitions did not result in a match when presented with a user agent that should have created a match: Mozilla/4.76C-CCK-MCD (X11; ?; SunOS 5.? sun4u) Mozilla/4.76C-CCK-MCD vg_472 (X11; ?; SunOS 5.8 sun4u) Mozilla/4.76C-SGI (X11; ?; IRIX64 6.5 IP30) Mozilla/4.79C-CCK-MCD (X11; ?; SunOS 5.6 sun4u) But these did result in matches: Mozilla/4.79 *(Win95; ?) Mozilla/4.78 (Windows 2000; U) Opera 6.05 Mozilla/5.0 (BeOS; ?; BeOS BePC; ?; rv:1.0.?) Gecko/ This seems to suggest a problem only when multiple question marks are surrounded on both sides by white space. I hope this is enough information for someone to attempt a fix. -- Edit bug report at http://bugs.php.net/?id=21468&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21468&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21468&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21468&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21468&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21468&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21468&r=support Expected behavior: http://bugs.php.net/fix.php?id=21468&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21468&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21468&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21468&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21468&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21468&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21468&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21468&r=gnused
#19349 [Opn->Fbk]: odbc_longreadlen() does not work
ID: 19349
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: SuSE 8.0
PHP Version: 4.2.1
New Comment:
The bug has been fixed in CVS. Please try it when you will be able to
compile PHP. Do not change the status of this bug just because an
another one is not (yet) fixed already. (Even if it looks it is
now).
Thank you for your report.
Previous Comments:
[2003-01-06 12:35:48] [EMAIL PROTECTED]
Don't put this in a different state yet as I can't get the snapshot to
compile until bug #20928 is fixed.
[2003-01-06 12:24:10] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
As soon as the CVS commit happens I think I fixed this. Give it a try
and let me know.
[2002-11-16 12:06:34] [EMAIL PROTECTED]
Script is pretty simple. It's hard to just cut and paste because I have
everything spread out in a bunch of classes.
$linkid = odbc_pconnect("database", "username", "password");
$result = odbc_exec($linkid, "SELECT SUBSTR(document, 1, 200) FROM
documents WHERE doc_id = 1);
odbc_longreadlen($result, 200);
odbc_binmode($result, ODBC_BINMODE_PASSTHRU);
$column = odbc_result($result, 1);
// A short example of what I'm trying to do.
// $column should be filled with up to 200 bytes of data.
// By default, it's up to 4096 bytes of data, or whatever is
// set in the php.ini file.
[2002-11-16 01:13:36] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-02 14:51:11] [EMAIL PROTECTED]
can you please provide the full script sample for this? I think I do
see what is wrong, but want to make sure.
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/19349
--
Edit this bug report at http://bugs.php.net/?id=19349&edit=1
#19349 [Fbk->Opn]: odbc_longreadlen() does not work
ID: 19349
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: SuSE 8.0
PHP Version: 4.2.1
New Comment:
Don't put this in a different state yet as I can't get the snapshot to
compile until bug #20928 is fixed.
Previous Comments:
[2003-01-06 12:24:10] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
As soon as the CVS commit happens I think I fixed this. Give it a try
and let me know.
[2002-11-16 12:06:34] [EMAIL PROTECTED]
Script is pretty simple. It's hard to just cut and paste because I have
everything spread out in a bunch of classes.
$linkid = odbc_pconnect("database", "username", "password");
$result = odbc_exec($linkid, "SELECT SUBSTR(document, 1, 200) FROM
documents WHERE doc_id = 1);
odbc_longreadlen($result, 200);
odbc_binmode($result, ODBC_BINMODE_PASSTHRU);
$column = odbc_result($result, 1);
// A short example of what I'm trying to do.
// $column should be filled with up to 200 bytes of data.
// By default, it's up to 4096 bytes of data, or whatever is
// set in the php.ini file.
[2002-11-16 01:13:36] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-02 14:51:11] [EMAIL PROTECTED]
can you please provide the full script sample for this? I think I do
see what is wrong, but want to make sure.
[2002-09-11 10:27:31] [EMAIL PROTECTED]
I have a script that runs a select statement from a 10MB CLOB field
(among others). I run the following :
odbc_longreadlen($resultid, 300);
Then I run:
$document = odbc_result($resultid, 2);
The problem is, $document ends up with 4096 bytes of data (the default,
NOT 300). If I edit php.ini and set up odbc_lrl to 200 in
there, then $document ends up with 2MBin it. It acts like the function
odbc_longreadlen does not work at all.
I don't know how much more information I can give other than
odbc_longreadlen does not seem to do anything at all.
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/19349
--
Edit this bug report at http://bugs.php.net/?id=19349&edit=1
#19045 [Opn->Fbk]: SELECT DISTINCT with just ONE table doesn't work
ID: 19045 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: IIS4 on NT4 PHP Version: 4.2.2 New Comment: Can you send me a sample schema/dataset to immitate your behavior exactly? Previous Comments: [2002-12-09 11:06:38] [EMAIL PROTECTED] I made the test again with PHP Version 4.3.0RC2, and I have the same results ; with two tables it works, but not with one. [2002-11-26 19:59:40] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-11-15 18:11:26] [EMAIL PROTECTED] Any chance you can check to see if this is still happening for you with the 4.3RC? [2002-10-04 07:03:49] [EMAIL PROTECTED] I didn't find any tab with 'logging on' checkbox in ODBC Administrator program ; so, I changed the value of the 'Driver Logging' parameter to 17 in the oraodbc.ini file. I hope it can help you... Merci. // logging results when the request works fine (with two joined tables) Oracle ODBC 32 Bit Driver Version 08.00.6000 Oracle ODBC 32 Bit Driver File Version08.00.6000 0X0013BA50: php 0X 0X0013F078: php 0X 0X0013F8D0: php 0X 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES, GROUPE_MACHINE where poste=machine 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES, GROUPE_MACHINE where poste=machine 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES, GROUPE_MACHINE where poste=machine 0X0013FC70: Rows Fetched = 0X006E // logging results when the request doesn't work fine (with one table) Oracle ODBC 32 Bit Driver Version 08.00.6000 Oracle ODBC 32 Bit Driver File Version08.00.6000 0X0013BA50: php 0X 0X0013F078: php 0X 0X0013F8D0: php 0X 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES 0X0013FC70: SELECT ROWID from TEMPSCUMULES 0X0013FC70: SELECT ROWID,distinct SOCIETE, POSTE from TEMPSCUMULES WHERE ROWID='' 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES [2002-10-03 07:48:10] [EMAIL PROTECTED] Open your ODBC Administrator and there should be tab that has a little check box that says "Turn Logging On" I believe it's on the same tab as the Pooling 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/19045 -- Edit this bug report at http://bugs.php.net/?id=19045&edit=1
#21192 [Bgs]: Problems with variables
ID: 21192
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Performance problem
Operating System: Windows XP Home Ed
PHP Version: 4.2.3
New Comment:
Thank you very much for your help. I have changed the
'register_globals' setting and everything has fallen into place.
Anyway, I also had to use the POST method to make it work.
Best regards.
Pasquale Esposito
Previous Comments:
[2003-01-06 09:19:43] [EMAIL PROTECTED]
Dear sirs,
I have the same problem of Pasquale. I have already changed the
parameter "register_globals on" but my script doesn't recognize the
variables passed from the form with GET method.
PHP v.4.2.3 and APACHE 1.3.27 on Windows XP
Can you help me? Thank you!
LUCA ALVISI
[2002-12-26 06:57:01] [EMAIL PROTECTED]
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
[2002-12-26 06:54:13] [EMAIL PROTECTED]
Dear Sirs,
I have recently installed PHP v.4.2.3 on a Windows XP Home Edition
system equipped with an Apache HTTP Server v.1.3.24 and MySQL v.4.0.3.
I believe the installation was completed successfully since I have
already managed to create simple databases with PHP and MySQL and
insert, update and delete tables and records.
In spite of this, I have encountered a problem dealing with variable
settings that is literally driving me crazy. I'll try to explain it in
very few words.
If I populate a table using the following code, everything works
perfectly:
//***START OF CODE***
@mysql_connect("localhost", "root", "") or die ("Sorry. Could not
connect to the DB!");
@mysql_select_db("mydb") or die ("Sorry. Coluld not open the DB!");
@mysql_query("insert into mytable (field1,field2) values ('First field
value','Second field value')") or die("Sorry. Could not insert
data!");
//***END OF CODE***
Nevertheless, if I try to specify the field values by means of
variables corresponding to the values of text boxes, the variables are
not recognized by PHP and I get an error message. So the problem is, I
can't import variables from text boxes!
In order to simplify what I mean, the following basic code, saved in a
file called "test.php", originates an error on my system:
//***START OF CODE***
//***END OF CODE***
When I execute the code above, all I get is the following error
message:
Notice: Undefined variable: mytext in c:\program files\apache
group\apache\htdocs\test.php on line 5
I would very much like to understand the reason why such elementary
lines of code don't work on my system. Please if you have the answer to
my question, help me. If possible, notify me at the following e-mail
address:
[EMAIL PROTECTED]
Thanks in advance for your help.
Yours faithfully,
Pasquale Esposito
Perugia (Italy)
--
Edit this bug report at http://bugs.php.net/?id=21192&edit=1
#19349 [Opn->Fbk]: odbc_longreadlen() does not work
ID: 19349
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: SuSE 8.0
PHP Version: 4.2.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
As soon as the CVS commit happens I think I fixed this. Give it a try
and let me know.
Previous Comments:
[2002-11-16 12:06:34] [EMAIL PROTECTED]
Script is pretty simple. It's hard to just cut and paste because I have
everything spread out in a bunch of classes.
$linkid = odbc_pconnect("database", "username", "password");
$result = odbc_exec($linkid, "SELECT SUBSTR(document, 1, 200) FROM
documents WHERE doc_id = 1);
odbc_longreadlen($result, 200);
odbc_binmode($result, ODBC_BINMODE_PASSTHRU);
$column = odbc_result($result, 1);
// A short example of what I'm trying to do.
// $column should be filled with up to 200 bytes of data.
// By default, it's up to 4096 bytes of data, or whatever is
// set in the php.ini file.
[2002-11-16 01:13:36] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2002-11-02 14:51:11] [EMAIL PROTECTED]
can you please provide the full script sample for this? I think I do
see what is wrong, but want to make sure.
[2002-09-11 10:27:31] [EMAIL PROTECTED]
I have a script that runs a select statement from a 10MB CLOB field
(among others). I run the following :
odbc_longreadlen($resultid, 300);
Then I run:
$document = odbc_result($resultid, 2);
The problem is, $document ends up with 4096 bytes of data (the default,
NOT 300). If I edit php.ini and set up odbc_lrl to 200 in
there, then $document ends up with 2MBin it. It acts like the function
odbc_longreadlen does not work at all.
I don't know how much more information I can give other than
odbc_longreadlen does not seem to do anything at all.
[2002-09-11 09:49:21] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
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/19349
--
Edit this bug report at http://bugs.php.net/?id=19349&edit=1
#13838 [Opn->Ana]: Default ODBC statement concurrency option does not allow some queries on MSSQL
ID: 13838
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: ODBC related
Operating System: WinNT4 SP5
-PHP Version: 4.0.6
+PHP Version: 4.3.0
New Comment:
This is true for all versions of PHP really. The ODBC env needs to be
delt with differently for this to work. I've been working on a fix for
this for awhile.
Previous Comments:
[2003-01-06 11:57:04] [EMAIL PROTECTED]
Nicos this hasn't been changed, thus the non-status change in it.
[2003-01-02 19:40:34] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2001-10-26 10:55:48] [EMAIL PROTECTED]
I am using PHP 4.0.6 on WinNT4 SP5. The database is
MSSQL 7.0.
With the default ODBC statement concurrency option set
by PHP/ODBC some queries are not executed by SQL Server.
$conn = odbc_connect("MyDSN", "user", "pass");
odbc_exec($conn, "SELECT * FROM test1 WITH(UPDLOCK HOLDLOCK) WHERE
ID=1");
results in this error:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot specify UPDLOCK
or TABLOCKX with READ ONLY or INSENSITIVE cursors.
Workaround:
Manually set a default ODBC statement option that
results in a cursor that is not read only:
$conn = odbc_connect("MyDSN", "user", "pass");
odbc_setoption($conn, 1, SQL_CONCURRENCY, SQL_CONCUR_VALUES);
odbc_exec($conn, "SELECT * FROM test1 WITH(UPDLOCK HOLDLOCK) WHERE
ID=1");
The drawback of the workaround is that it does not work
for persistent connections.
But it would be nice to have persistent connections also.
So, I propose some extensions on the arguments of
odbc_connect/odbc_pconnect:
int odbc_connect (string dsn, string user, string password [, int
cursor_type[, array default_statement_options]])
So it could be used like this:
$dso = array(SQL_CURSOR_TYPE=>SQL_CURSOR_DYNAMIC,
SQL_CONCURRENCY=>SQL_CONCUR_VALUES);
$conn = odbc_connect("DSN", "user", "pass", SQL_CUR_USE_DRIVER,
$dso);
You could either set the defaults with SQLSetConnectOption
after SQLConnect or do a SQLSetStmtOption after allocating
an ODBC statement handle for all the items of the array.
Maybe it would be possible to change the signature of
odbc_connect/odbc_pconnect to:
int odbc_connect (string dsn, string user, string password [, mixed
odbc_options])
where mixed means the (current) int or the proposed array.
Advantages:
- Persistent connections could be made to accept some
statement options because odbc_pconnect has all the
information for discriminating and selecting an
appropriate connection.
There seems to be a similar problem reported
with bug id #9738 (http://bugs.php.net/bug.php?id=9738).
But instead of providing some sort of "odbc_prepare_clean"
I would prefer to extend the capability of setting ODBC
statement options in a much more flexible way that can be
used for persistent connections also.
--
Edit this bug report at http://bugs.php.net/?id=13838&edit=1
#21279 [Opn->Fbk]: odbc_fetch_into returns empty strings for columns with NULL values
ID: 21279
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: Windows
PHP Version: 4.3.0
New Comment:
Try a snapshot dated sometime after this. I believe it does what you
want/desire. If not many complaints happen I'll leave it in...
Previous Comments:
[2003-01-03 17:09:16] [EMAIL PROTECTED]
What I meant is that every SQL based PHP database API has a function to
fetch rows into an array. When it is not not *_fetch_into is
*_fetch_row.
I do not see any ambiguity in figuring if a result column has a NULL.
As a matter of fact in the current odbc_function of php_odbc.c you
have:
http://cvs.php.net/co.php/php4/ext/odbc/php_odbc.c?r=1.143.2.1
if (result->values[i].vallen == SQL_NULL_DATA) {
Z_STRVAL_P(tmp) = empty_string;
break;
}
Since NULL is always NULL regardless of the data type of a column, all
that needs to be done is to leave undefined (NULL) the respective
column position of the PHP array value returned by the odbc_fetch_into.
[2003-01-03 12:10:44] [EMAIL PROTECTED]
Which other API's are you talking about? Oracle? It's the only other
extension that uses fetch into really.
As for the statement, there is no way for ODBC to really tell either.
The API itself defines this to be rather ambiguous so it becomes
difficult to deal with. At this time the result leaves it to the PHP
user to decide if one is really an emtpy string or NULL rather than the
PHP engine. I tend to think this is a better solution.
[2002-12-29 19:47:04] [EMAIL PROTECTED]
odbc_fetch_into returns empty strings for columns with NULL values.
This makes it impossible to distinguish whether a result column value
is a real empty string or a NULL, unlike with API functions for the
same purpose but for other databases.
--
Edit this bug report at http://bugs.php.net/?id=21279&edit=1
#21441 [Com]: POST-ed array repeats itself
ID: 21441
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Apache2 related
Operating System: RH 8.0 Apache 2.0
PHP Version: 4.2.2
New Comment:
Hi,
i use the current releas version -> 4.3.0 on redhat-8.0 with apache
2.0.43 and get the same error.
here is another example
\$_POST ";
print_r($_POST);
echo "\n\$_GET ";
print_r($_GET);
echo "";
?>
chbox 1
chbox 2
chbox 3
chbox 4
chbox 5
output (all checkboxes selected):
$_POST Array
(
[chkTest] => Array
(
[0] => chbox 1
[1] => chbox 2
[2] => chbox 3
[3] => chbox 4
[4] => chbox 5
[5] => chbox 2
[6] => chbox 3
[7] => chbox 4
[8] => chbox 5
)
[submit] => submit
)
$_GET Array
(
)
When I replace the POST wit GET it works fine.
cya later
/Stephan
Previous Comments:
[2003-01-05 16:44:45] [EMAIL PROTECTED]
Reclassified
[2003-01-05 14:51:42] [EMAIL PROTECTED]
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at
http://www.php.net/downloads.php
[2003-01-05 14:49:13] [EMAIL PROTECTED]
Here some_arr[] has two values, but after POST-ing the resulting array
seems like it is repeating itself.
Example:
var_dump($some_arr):
array(3) {
[0]=>
string(2) "aa"
[1]=>
string(15) "bbsome_arr[]=aa"
[2]=>
string(2) "bb"
}
When I replace the POST wit GET it works fine.
--
Edit this bug report at http://bugs.php.net/?id=21441&edit=1
#16411 [Fbk]: CGI application misbehaved by not returning a complete set of
ID: 16411 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: MSSQL related Operating System: Windows 2000 -PHP Version: 4.1.2 +PHP Version: 4.3.0 New Comment: Updating version Previous Comments: [2003-01-06 12:02:13] [EMAIL PROTECTED] What version of the MDAC are all of you using? I've heard that the latest MDAC causes a lot of problems and that many users are downgrading to the last version. Just wondering if this might be true or not for any of you. [2003-01-02 09:27:17] [EMAIL PROTECTED] I have experienced the same bug when running Win2000 Server and MS Sql 2000. MS SQL 7 would not produce this error. The error has been reproduced in all PHP versions I've tried up to 4.3.0. I've tried to use delays and change preformance parameters in MSSQL, but no luck there. A temporary solution would be to rewrite the code to use ODBC for database calls. This cannot be considered a acceptable solution, but it does work for us until this bug is corrected. [2002-12-25 01:53:11] [EMAIL PROTECTED] Looks like feedback exists -> open [2002-12-24 01:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-18 06:43:19] [EMAIL PROTECTED] I have the same problem. Platform: PHP different versions, SQL Server 2000 and Windows 2000. I see it a lot when the server is busy, or when two requests are made really fast after another. Really need a solution for this. 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#21310 [Com]: no such file (paths)
ID: 21310 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Directory/Filesystem functions Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: yes, same thing for me. if HTTP server has permission to read all directories in path to the file, all users can read directories of other user and it's really not secure ... Previous Comments: [2003-01-05 16:59:45] [EMAIL PROTECTED] In my humble opinion it is a bug, because: 1. Previous version of PHP (4.0) could read file without full path, even if PHP couldnt read "." or higher directory. 2. PHP reads several directories (why?) when includes each file without full path. 2. There is no technical reason to give PHP access to read all directories from "/" to directories with PHP scripts. [2003-01-05 16:41:43] [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 [2003-01-05 16:37:36] [EMAIL PROTECTED] Module PHP can't find files (eg. includes them) if HTTP server hasn't permission to read all directories in path to the file. [2002-12-31 05:10:31] [EMAIL PROTECTED] After upgrading to 4.3.0 version some PHP scripts stop working. I have checked, that the reason is problem with opening and including files. FIRST EXAMPLE: I had to change variable: $blocked_list["kom.pl"] = "blockkom.txt"; ---> $blocked_list["kom.pl"] = "blockkom.txt"; SECOND EXAMPLE: --- Warning: main(main/linie.php) [function.main]: failed to create stream: No such file or directory in /www/klient34/start/dolacz.php on line 5 Warning: main() [function.main]: Failed opening 'main/linie.php' for inclusion (include_path=''.:..:/usr/local/lib/php'') in /www/klient34/start/dolacz.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=21310&edit=1
#16411 [Opn->Fbk]: CGI application misbehaved by not returning a complete set of
ID: 16411 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.2 New Comment: What version of the MDAC are all of you using? I've heard that the latest MDAC causes a lot of problems and that many users are downgrading to the last version. Just wondering if this might be true or not for any of you. Previous Comments: [2003-01-02 09:27:17] [EMAIL PROTECTED] I have experienced the same bug when running Win2000 Server and MS Sql 2000. MS SQL 7 would not produce this error. The error has been reproduced in all PHP versions I've tried up to 4.3.0. I've tried to use delays and change preformance parameters in MSSQL, but no luck there. A temporary solution would be to rewrite the code to use ODBC for database calls. This cannot be considered a acceptable solution, but it does work for us until this bug is corrected. [2002-12-25 01:53:11] [EMAIL PROTECTED] Looks like feedback exists -> open [2002-12-24 01:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-18 06:43:19] [EMAIL PROTECTED] I have the same problem. Platform: PHP different versions, SQL Server 2000 and Windows 2000. I see it a lot when the server is busy, or when two requests are made really fast after another. Really need a solution for this. [2002-12-13 11:25:11] [EMAIL PROTECTED] i'm also experiencing this error with win xp, mssql 2000, and php 4.3.0 rc3. is it a problem with php, or with the mssql libraries? 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/16411 -- Edit this bug report at http://bugs.php.net/?id=16411&edit=1
#13838 [Fbk->Opn]: Default ODBC statement concurrency option does not allow some queries on MSSQL
ID: 13838
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: ODBC related
Operating System: WinNT4 SP5
PHP Version: 4.0.6
New Comment:
Nicos this hasn't been changed, thus the non-status change in it.
Previous Comments:
[2003-01-02 19:40:34] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2001-10-26 10:55:48] [EMAIL PROTECTED]
I am using PHP 4.0.6 on WinNT4 SP5. The database is
MSSQL 7.0.
With the default ODBC statement concurrency option set
by PHP/ODBC some queries are not executed by SQL Server.
$conn = odbc_connect("MyDSN", "user", "pass");
odbc_exec($conn, "SELECT * FROM test1 WITH(UPDLOCK HOLDLOCK) WHERE
ID=1");
results in this error:
[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot specify UPDLOCK
or TABLOCKX with READ ONLY or INSENSITIVE cursors.
Workaround:
Manually set a default ODBC statement option that
results in a cursor that is not read only:
$conn = odbc_connect("MyDSN", "user", "pass");
odbc_setoption($conn, 1, SQL_CONCURRENCY, SQL_CONCUR_VALUES);
odbc_exec($conn, "SELECT * FROM test1 WITH(UPDLOCK HOLDLOCK) WHERE
ID=1");
The drawback of the workaround is that it does not work
for persistent connections.
But it would be nice to have persistent connections also.
So, I propose some extensions on the arguments of
odbc_connect/odbc_pconnect:
int odbc_connect (string dsn, string user, string password [, int
cursor_type[, array default_statement_options]])
So it could be used like this:
$dso = array(SQL_CURSOR_TYPE=>SQL_CURSOR_DYNAMIC,
SQL_CONCURRENCY=>SQL_CONCUR_VALUES);
$conn = odbc_connect("DSN", "user", "pass", SQL_CUR_USE_DRIVER,
$dso);
You could either set the defaults with SQLSetConnectOption
after SQLConnect or do a SQLSetStmtOption after allocating
an ODBC statement handle for all the items of the array.
Maybe it would be possible to change the signature of
odbc_connect/odbc_pconnect to:
int odbc_connect (string dsn, string user, string password [, mixed
odbc_options])
where mixed means the (current) int or the proposed array.
Advantages:
- Persistent connections could be made to accept some
statement options because odbc_pconnect has all the
information for discriminating and selecting an
appropriate connection.
There seems to be a similar problem reported
with bug id #9738 (http://bugs.php.net/bug.php?id=9738).
But instead of providing some sort of "odbc_prepare_clean"
I would prefer to extend the capability of setting ODBC
statement options in a much more flexible way that can be
used for persistent connections also.
--
Edit this bug report at http://bugs.php.net/?id=13838&edit=1
#21073 [Opn->Csd]: linking "configure --with-sapdb" failed
ID: 21073 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux PHP Version: 4.2.3 New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Should not exist in the latest release of PHP (4.3.0). Previous Comments: [2002-12-18 04:49:39] [EMAIL PROTECTED] After "./configure --with-sapdb=" the make run ends in : /bin/sh /home/remuser/ttk/php-4.2.3/libtool --silent --mode=link gcc -I. -I/home/remuser/ttk/php-4.2.3/ -I/home/remuser/ttk/php-4.2.3/main -I/home/remuser/ttk/php-4.2.3 -I/home/remuser/ttk/php-4.2.3/Zend -I/home/remuser/ttk/php-4.2.3/ext/mysql/libmysql -I/home/remuser/ttk/odbc_7.3.0.28//incl -I/home/remuser/ttk/php-4.2.3/ext/xml/expat -I/home/remuser/ttk/php-4.2.3/TSRM -g -O2 -o php -export-dynamic stub.lo libphp4.la /usr/i486-suse-linux/bin/ld: cannot find -lsqlrte collect2: ld returned 1 exit status make[1]: *** [php] Error 1 The problem is that entries regarding sqlrte in ./configure and ./ext/odbc/config.m4 for SAP DB are wrong. Following patches fix the problem: patch for ./configure: *** configure.orig Wed Dec 18 10:08:58 2002 --- configure Wed Dec 18 10:08:52 2002 *** *** 42171,42186 esac - case sqlrte in - c|c_r|pthread*) ;; - *) - - - LIBS="-lsqlrte $LIBS" - - - ;; - esac ODBC_TYPE=sapdb cat >> confdefs.h <<\EOF --- 42171,42176 patch for ./ext/odbc/config.m4: *** config.m4.orig Mon Mar 4 10:10:31 2002 --- config.m4 Wed Dec 18 11:48:43 2002 *** *** 135,141 PHP_ADD_INCLUDE($withval/incl) PHP_ADD_LIBPATH($withval/lib) PHP_ADD_LIBRARY(sqlod) - PHP_ADD_LIBRARY(sqlrte) ODBC_TYPE=sapdb AC_DEFINE(HAVE_SAPDB,1,[ ]) AC_MSG_RESULT(yes) --- 135,140 Regards Thomas -- Edit this bug report at http://bugs.php.net/?id=21073&edit=1
#21467 [Opn]: crash without any error
ID: 21467 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Class/Object related Operating System: linux debian PHP Version: 4.3.0 New Comment: forgot to mention that the version it worked correctly is 4.1.2 (if can be defined correctly at all, i mean the script was working) Previous Comments: [2003-01-06 11:34:26] [EMAIL PROTECTED] when I try this done I minimized the problem, which I found with an old code using FastTemplate nothing happens - no errors, no warning, no output - just sending headers and thats all I am not sure if it is leagal code, but I'm sure it should get some error or warning message at least, or work of course I installed it on apache web server, but the cli version is working the same way ( not working ) compiled the PHP with --enable-debug, and still no difference - no messages of any kind -- Edit this bug report at http://bugs.php.net/?id=21467&edit=1
#21467 [NEW]: crash without any error
From: [EMAIL PROTECTED] Operating system: linux debian PHP version: 4.3.0 PHP Bug Type: Class/Object related Bug description: crash without any error when I try this done I minimized the problem, which I found with an old code using FastTemplate nothing happens - no errors, no warning, no output - just sending headers and thats all I am not sure if it is leagal code, but I'm sure it should get some error or warning message at least, or work of course I installed it on apache web server, but the cli version is working the same way ( not working ) compiled the PHP with --enable-debug, and still no difference - no messages of any kind -- Edit bug report at http://bugs.php.net/?id=21467&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21467&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21467&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21467&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21467&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21467&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21467&r=support Expected behavior: http://bugs.php.net/fix.php?id=21467&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21467&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21467&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21467&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21467&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21467&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21467&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21467&r=gnused
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.3.0-dev,4.2.3 New Comment: Getting totally wrong dir in the output of the error mess open_basedir restriction in effect. File(index.php) is not within the allowed path(s): (/home/userB) Getting this error when surfing to userA which has open_basedir set to /home/userA in apache virthost, one gets that access to userB home isn't granted. This might not be a fault in the open_basedir code, but for some reason it get's the wrong open_basedir dir from the calling function. If someone could take a deeper look at this it would be nice, hard to explain to all customers that this problem is out of our hands to fix. Previous Comments: [2003-01-06 10:33:12] [EMAIL PROTECTED] Bug confirmed on FreeBSD 4.6 with php 4.3.0. Totally random it seems. [2003-01-01 10:11:49] [EMAIL PROTECTED] i have the same problem after i upgrade from 4.2.2 to 4.3.0(release version) pls update bug version No. it's _NOT_ fixed in php-4.3.0 it seems php may not re-initize correctly cause there's an un-relative bug: http://bugs.php.net/?id=21306 but i'm just guessing [2002-11-12 16:06:18] [EMAIL PROTECTED] Same problem here on FreeBSD 4.7-STABLE + Apache and it's really a showstoppper. PHP is today's 4.3.0-dev snapshot, but a 4.2.3 release had the same behavior. Sometimes the error message reports the open_basedir of another unrelated virtualhost. The problem _never_ showed up on OpenBSD 3.1/3.2 + Zeus + PHP 4.2.3 with FastCGI on a very similar setup. There's definitely an off-by-one or some kind of memory corruption somewhere. [2002-11-11 08:43:36] [EMAIL PROTECTED] We randomly gets this error even if virtual server has this option switched off. (but other virtual servers has this option on) [2002-11-10 05:01:42] [EMAIL PROTECTED] I get this problem alot on my site http://perthtunes.wicked.dj/ which is not hosted by me.. Apache Version 1.3.27 (Unix) Kernel Version 2.4.18-0.12 Perl Version 5.006001 PHP Version 4.2.3 the site has alot of nested include files and I seem to get a high rate of recreation of the error. seems to happen 1 in every 5 or so page views for most users. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#21378 [Com]: COM code crashes after update 4.2.1 to 4.3.0
ID: 21378
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: Windows 2000 pro sp2
PHP Version: 4.3.0
New Comment:
(sorry for my bad english)
I have this same error!
My COM code works OK with PHP 4.2.3, but after upgrade to 4.3.0, Apache
(1.3.27) crash (DrWatson32 appears) and restart. This simple code crash
Apache:
$com = new COM("ADODB.Connection");
DrWatson32 leaves this information on log:
función: php_COM_release
1003070f 397e04 cmp [esi+0x4],edi
ds:04f43582=
10030712 740f jz
php_VARIANT_get_le_variant+0x1983 (10039223)
10030714 8b4614 mov eax,[esi+0x14]
ds:04f43582=
10030717 50 pusheax
10030718 8b10 mov edx,[eax]
ds:045c10a0=
1003071a ff5208 calldword ptr [edx+0x8]
ds:00afd5d3=
1003071d 897e14 mov [esi+0x14],edi
ds:04f43582=
10030720 897e04 mov [esi+0x4],edi
ds:04f43582=
10030723 8b460c mov eax,[esi+0xc]
ds:04f43582=
10030726 50 pusheax
ERROR -> 10030727 8b08 mov ecx,[eax]
ds:045c10a0=
10030729 ff5108 calldword ptr [ecx+0x8]
ds:00c76672=
1003072c 8b4608 mov eax,[esi+0x8]
ds:04f43582=
1003072f 897e0c mov [esi+0xc],edi
ds:04f43582=
10030732 48 dec eax
10030733 5f pop edi
10030734 894608 mov [esi+0x8],eax
ds:04f43582=
10030737 5e pop esi
10030738 c3 ret
10030739 90 nop
1003073a 90 nop
1003073b 90 nop
I'm using Windows 2000 Server SP3 with PHP as a module in Apache.
Any idea ?
Thanks!
Previous Comments:
[2003-01-02 21:47:14] [EMAIL PROTECTED]
-
[2003-01-02 21:26:17] [EMAIL PROTECTED]
COM code that works perfectly ok with 4.2.1 gets Apache 1.3.22 down
with program error notice in PHP 4.3.0. Any documentation update
possibly, maybe?
--
Edit this bug report at http://bugs.php.net/?id=21378&edit=1
#21466 [NEW]: configure bug in XSLT/Sablotron and Zip options
From: [EMAIL PROTECTED] Operating system: RedHat Linux PHP version: 4.3.0 PHP Bug Type: *Compile Issues Bug description: configure bug in XSLT/Sablotron and Zip options Hi guys, I perhaps found a "mystery" bug in ./configure process... check out when I try: CFLAGS='-O2 -I/usr/local/ssl/include/openssl/' \ ./configure \ --with-apache=../apache_1.3.27 \ --with-mysql \ --enable-track-vars \ --enable-ftp \ --with-gettext \ --with-imap=/usr/lib \ --with-pdflib=/usr/local \ --enable-static-pdflib \ --with-gd \ --with-tiff-dir=/usr/lib \ --with-jpeg-dir=/usr/lib \ --with-png-dir=/usr/lib \ --with-zlib-dir=/usr/include \ --enable-xslt \ --with-xslt-sablot \ --with-zip I got an error message: configure: error: zziplib module requires zzlib >= 0.10.6. zzlib version 0.10.66 I has installed on my system in path: /usr/local/lib when I kick out options: --enable-xslt AND --with-xslt-sablot then the configure process done OK. When kick out --with-zip AND leave there both --enable-xslt AND --with-xslt-sablot then the configure done OK again. The problem is when together: --enable-xslt \ --with-xslt-sablot \ --with-zip On my home server RedHat 8.0 everything OK, on the production server RedHat 7.1 + upgrades I found this "bug". Feedback please. Regards Lubo Kopacek, Slovakia -- Edit bug report at http://bugs.php.net/?id=21466&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21466&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21466&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21466&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21466&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21466&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21466&r=support Expected behavior: http://bugs.php.net/fix.php?id=21466&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21466&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21466&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21466&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21466&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21466&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21466&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21466&r=gnused
#21261 [Opn]: $_SERVER['PHP_SELF'] gives wrong info
ID: 21261 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: linux 2.4.18 - slack 8.1 PHP Version: 4.3.0 Assigned To: shane New Comment: Negative. Patch not only did not work (I applied it to current 4.3.0) but I now no longer have a $_SERVER['PATH_TRANSLATED'] variable . So $_SERVER['PHP_SELF'] remains corrupted and $_SERVER['PATH_TRANSLATED'] gives some kind of udefined error. Joshua Previous Comments: [2003-01-05 21:58:19] [EMAIL PROTECTED] The patch at http://www.caraveo.com/php/cgi.patch Should fix this problem. Please try this and let me know. It's against cvs HEAD from today. [2003-01-02 10:54:32] [EMAIL PROTECTED] I'm using php with cgiwrap. http://cgiwrap.unixtools.org/ I added two small patches as described in Bug #21301 but i don't know if they work with current cvs version. In httpd.conf: AddHandler php-cgiwrap .php Action php-cgiwrap /cgiwrapper/php-cgiwrap/ ScriptAlias /cgiwrapper/ /usr/local/cgiwrap/ [2003-01-01 11:21:36] [EMAIL PROTECTED] Are you talking about this? ScriptAlias /cgi/ /var/www/htdcos/cgi/ Action application/x-httpd-php /cgi/php AddType application/x-httpd-php .php I can also post my ini and my configure script though you can probably get that info from the env.html I posted earlier. [2002-12-31 01:21:50] [EMAIL PROTECTED] Send me the pertinent lines out of httpd.conf that you have used to configure php so I can test with the same settings. [2002-12-30 20:21:48] [EMAIL PROTECTED] Probable cause found Checking with submitter of prior patch. 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/21261 -- Edit this bug report at http://bugs.php.net/?id=21261&edit=1
#21465 [NEW]: multipart/form-data forms post problems
From: [EMAIL PROTECTED] Operating system: Linux RedHat 7.3 (kernel 2420) PHP version: 4.3.0 PHP Bug Type: *General Issues Bug description: multipart/form-data forms post problems Hi, when I use form varibles, named, as associative array (see an example) and form have attribute multipart/form-data, after posting, first element of posted array are lost, in some cases. Example: - -- After posting printr($img) give: Array ( [koeff] => 1.45 [min_width] => 220 ) Thank you for support. Ivaschenko Yuriy. -- Edit bug report at http://bugs.php.net/?id=21465&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21465&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21465&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21465&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21465&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21465&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21465&r=support Expected behavior: http://bugs.php.net/fix.php?id=21465&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21465&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21465&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21465&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21465&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21465&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21465&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21465&r=gnused
#21464 [Opn->Fbk]: imap_get_quota broken in php4.3.0?
ID: 21464
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: IMAP related
Operating System: UnitedLinux 1.0
PHP Version: 4.3.0
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Marking as bogus, because the functionality of imap_get_quota was
changed a bit to correct for a bug (which basically returned the wrong
values). You might want to try a newer IMP, or give a bit more
information as to what is broken in the function.
Previous Comments:
[2003-01-06 10:10:10] [EMAIL PROTECTED]
just tried to get IMP3.1 running on UnitedLinux1.0
the IMP- configfile contains the "imap_get_quota" - command
however, when I disable the Line ("// ...") IMP works fine just without
Quotadisplay
if i leave the Line active there comes no Output produced from any
command after that Line
i use php 4.3.0/imap-2000a (without ssl)
--
Edit this bug report at http://bugs.php.net/?id=21464&edit=1
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.3.0-dev,4.2.3 New Comment: Bug confirmed on FreeBSD 4.6 with php 4.3.0. Totally random it seems. Previous Comments: [2003-01-01 10:11:49] [EMAIL PROTECTED] i have the same problem after i upgrade from 4.2.2 to 4.3.0(release version) pls update bug version No. it's _NOT_ fixed in php-4.3.0 it seems php may not re-initize correctly cause there's an un-relative bug: http://bugs.php.net/?id=21306 but i'm just guessing [2002-11-12 16:06:18] [EMAIL PROTECTED] Same problem here on FreeBSD 4.7-STABLE + Apache and it's really a showstoppper. PHP is today's 4.3.0-dev snapshot, but a 4.2.3 release had the same behavior. Sometimes the error message reports the open_basedir of another unrelated virtualhost. The problem _never_ showed up on OpenBSD 3.1/3.2 + Zeus + PHP 4.2.3 with FastCGI on a very similar setup. There's definitely an off-by-one or some kind of memory corruption somewhere. [2002-11-11 08:43:36] [EMAIL PROTECTED] We randomly gets this error even if virtual server has this option switched off. (but other virtual servers has this option on) [2002-11-10 05:01:42] [EMAIL PROTECTED] I get this problem alot on my site http://perthtunes.wicked.dj/ which is not hosted by me.. Apache Version 1.3.27 (Unix) Kernel Version 2.4.18-0.12 Perl Version 5.006001 PHP Version 4.2.3 the site has alot of nested include files and I seem to get a high rate of recreation of the error. seems to happen 1 in every 5 or so page views for most users. [2002-10-31 04:17:18] [EMAIL PROTECTED] Can you mark this critical ? 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#21446 [Opn->Bgs]: php4apache.dll uses plain Apache 1.3 API
ID: 21446 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Windows XP PHP Version: 4.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Previous Comments: [2003-01-05 18:36:47] [EMAIL PROTECTED] I downloaded PHP 4.3.0 and followed the instructions step-by-step. I use Apache 1.3.27 and Apache can't start because: [Warn] Loaded DSO c:/php/sapi/php4apache.dll uses plain Apache 1.3 API, this module might crash under EAPI! (Please recompile it with -DEAPI) -- Edit this bug report at http://bugs.php.net/?id=21446&edit=1
#21464 [NEW]: imap_get_quota broken in php4.3.0?
From: [EMAIL PROTECTED]
Operating system: UnitedLinux 1.0
PHP version: 4.3.0
PHP Bug Type: Scripting Engine problem
Bug description: imap_get_quota broken in php4.3.0?
just tried to get IMP3.1 running on UnitedLinux1.0
the IMP- configfile contains the "imap_get_quota" - command
however, when I disable the Line ("// ...") IMP works fine just without
Quotadisplay
if i leave the Line active there comes no Output produced from any command
after that Line
i use php 4.3.0/imap-2000a (without ssl)
--
Edit bug report at http://bugs.php.net/?id=21464&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21464&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21464&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21464&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21464&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21464&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21464&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21464&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21464&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21464&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21464&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21464&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21464&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21464&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21464&r=gnused
#21463 [Opn->Bgs]: Overload __call method argument lowercase
ID: 21463
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Windows NT 4
PHP Version: 4.3.0
New Comment:
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
In PHP function/method names are case-insensitive, so they
all get auto-converted to lowercase.
Previous Comments:
[2003-01-06 09:48:43] [EMAIL PROTECTED]
Seems the magic __call() function used with the overload extension is
converting the name of the function called (the first argument of
__call()) to lowercase.
Best summarized with a script;
');
}
function __call($method,$args) {
echo ( 'Method called: '.$method.'' );
switch ( $method ) {
case 'testa':
echo ('testa('.$args[0].') success');
break;
case 'TestB':
echo ('TestB('.$args[0].') success');
break;
case 'TESTC':
echo ('TESTC('.$args[0].') success');
break;
default:
echo ('Method unknown');
break;
}
}
}
overload('Test');
$o=new Test();
$o->testa(1);
$o->TestA(2);
$o->TESTA(3);
$o->testb(1);
$o->TestB(2);
$o->TESTB(3);
$o->testc(1);
$o->TestC(2);
$o->TESTC(3);
?>
Output of above script;
Test constructed
Method called: testa
testa(1) success
Method called: testa
testa(2) success
Method called: testa
testa(3) success
Method called: testb
Method unknown
Method called: testb
Method unknown
Method called: testb
Method unknown
Method called: testc
Method unknown
Method called: testc
Method unknown
Method called: testc
Method unknown
--
Edit this bug report at http://bugs.php.net/?id=21463&edit=1
#21463 [NEW]: Overload __call method argument lowercase
From: [EMAIL PROTECTED]
Operating system: Windows NT 4
PHP version: 4.3.0
PHP Bug Type: Class/Object related
Bug description: Overload __call method argument lowercase
Seems the magic __call() function used with the overload extension is
converting the name of the function called (the first argument of
__call()) to lowercase.
Best summarized with a script;
');
}
function __call($method,$args) {
echo ( 'Method called: '.$method.'' );
switch ( $method ) {
case 'testa':
echo ('testa('.$args[0].') success');
break;
case 'TestB':
echo ('TestB('.$args[0].') success');
break;
case 'TESTC':
echo ('TESTC('.$args[0].') success');
break;
default:
echo ('Method unknown');
break;
}
}
}
overload('Test');
$o=new Test();
$o->testa(1);
$o->TestA(2);
$o->TESTA(3);
$o->testb(1);
$o->TestB(2);
$o->TESTB(3);
$o->testc(1);
$o->TestC(2);
$o->TESTC(3);
?>
Output of above script;
Test constructed
Method called: testa
testa(1) success
Method called: testa
testa(2) success
Method called: testa
testa(3) success
Method called: testb
Method unknown
Method called: testb
Method unknown
Method called: testb
Method unknown
Method called: testc
Method unknown
Method called: testc
Method unknown
Method called: testc
Method unknown
--
Edit bug report at http://bugs.php.net/?id=21463&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21463&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21463&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21463&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21463&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21463&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21463&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21463&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21463&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21463&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21463&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21463&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21463&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21463&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21463&r=gnused
#21192 [Com]: Problems with variables
ID: 21192
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Performance problem
Operating System: Windows XP Home Ed
PHP Version: 4.2.3
New Comment:
Dear sirs,
I have the same problem of Pasquale. I have already changed the
parameter "register_globals on" but my script doesn't recognize the
variables passed from the form with GET method.
PHP v.4.2.3 and APACHE 1.3.27 on Windows XP
Can you help me? Thank you!
LUCA ALVISI
Previous Comments:
[2002-12-26 06:57:01] [EMAIL PROTECTED]
In PHP 4.2.0, the 'register_globals' setting default changed to
'off'. See http://www.php.net/release_4_2_0.php for more info.
We are sorry about the inconvenience, but this change was a necessary
part of our efforts to make PHP scripting more secure and portable.
[2002-12-26 06:54:13] [EMAIL PROTECTED]
Dear Sirs,
I have recently installed PHP v.4.2.3 on a Windows XP Home Edition
system equipped with an Apache HTTP Server v.1.3.24 and MySQL v.4.0.3.
I believe the installation was completed successfully since I have
already managed to create simple databases with PHP and MySQL and
insert, update and delete tables and records.
In spite of this, I have encountered a problem dealing with variable
settings that is literally driving me crazy. I'll try to explain it in
very few words.
If I populate a table using the following code, everything works
perfectly:
//***START OF CODE***
@mysql_connect("localhost", "root", "") or die ("Sorry. Could not
connect to the DB!");
@mysql_select_db("mydb") or die ("Sorry. Coluld not open the DB!");
@mysql_query("insert into mytable (field1,field2) values ('First field
value','Second field value')") or die("Sorry. Could not insert
data!");
//***END OF CODE***
Nevertheless, if I try to specify the field values by means of
variables corresponding to the values of text boxes, the variables are
not recognized by PHP and I get an error message. So the problem is, I
can't import variables from text boxes!
In order to simplify what I mean, the following basic code, saved in a
file called "test.php", originates an error on my system:
//***START OF CODE***
//***END OF CODE***
When I execute the code above, all I get is the following error
message:
Notice: Undefined variable: mytext in c:\program files\apache
group\apache\htdocs\test.php on line 5
I would very much like to understand the reason why such elementary
lines of code don't work on my system. Please if you have the answer to
my question, help me. If possible, notify me at the following e-mail
address:
[EMAIL PROTECTED]
Thanks in advance for your help.
Yours faithfully,
Pasquale Esposito
Perugia (Italy)
--
Edit this bug report at http://bugs.php.net/?id=21192&edit=1
#21462 [NEW]: set_error_handler not properly executed?
From: [EMAIL PROTECTED]
Operating system: Linux Slackware
PHP version: 4.3.0
PHP Bug Type: Unknown/Other Function
Bug description: set_error_handler not properly executed?
Today we upgraded from php 4.2.3 (apache 1.3.26) to php 4.3.0.
We use freetype functionality in a set of functions and to keep this very
flexible the following code (except for the debugging prints) is used to
determine what freetype version was installed in order to use the right
functions (imagefttext or imagettftext).
This function (the set_error_handler) stopped working properly after
upgrading to 4.3.0
print freetype_version();
function freetype_version() {
// change error handler
set_error_handler("freetype_version_handler");
// remove freetype version from session
unset($_SESSION['freetype_version']);
// determine check array
$checkers = array(
"imagefttext" => 2, // freetype version
specific function -> freetype version
"imagettftext" => 1
);
// run checkers
while (list($key,$val)=each($checkers)) {
printf("%s:%s\n",$key,$val);
eval(sprintf("%s();",$key));
}
// restore old error handler
restore_error_handler();
// return version (null = no freetype support)
return $_SESSION['freetype_version'];
}
function
freetype_version_handler($errno,$errstr,$errfile,$errline,$variables) {
print "errorrr!\n";
if (eregi(sprintf("wrong parameter count for
%s",$variables['key']),$errstr)) {
$_SESSION['freetype_version'] = $variables['val'];
}
}
The code outputs the following error:
Fatal error: Call to undefined function: imagefttext() in
/sda6/domains/betterbeyourself.com_staging/includes/fnc_lang.inc(651) :
eval()'d code on line 1
We allready use a custom error handler so the above handler is nested...
this however worked very well in 4.2.3 I also noticed the same problems in
some 4.3.0 developmental cvs snapshots (don't know which snapshots they
were though) and thought it was a bug to be solved before the stable
release but appearantly it's still there
Grtz,
Jeroen
--
Edit bug report at http://bugs.php.net/?id=21462&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21462&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21462&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21462&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21462&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21462&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21462&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21462&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21462&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21462&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21462&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21462&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21462&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21462&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21462&r=gnused
#21461 [NEW]: Returning Turkish characters
From: [EMAIL PROTECTED] Operating system: win2k PHP version: 4.3.0 PHP Bug Type: *Languages/Translation Bug description: Returning Turkish characters I have Php4.3.0 on Apache/1.3.27 (Win32) mod_gzip/1.3.26.1a with Win2kServer. I connect to MSSQL and execute a query whose return has Turkish characters. it connects regularly but displays result wrongly. in addition when i use a query whose parameters has Turkish characters didnt return a result set. same code run regularly on Php4.3.0 Apache/1.3.23 (Win32) mod_gzip/1.3.26.1a with winXPCorp king regards Umut Barýþ RÜZGAR -- Edit bug report at http://bugs.php.net/?id=21461&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21461&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21461&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21461&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21461&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21461&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21461&r=support Expected behavior: http://bugs.php.net/fix.php?id=21461&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21461&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21461&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21461&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21461&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21461&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21461&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21461&r=gnused
#21458 [Opn->Bgs]: simple calcul have strange result
ID: 21458 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: linux and windows PHP Version: 4.3.0 New Comment: Actually this is documented: http://www.php.net/manual/en/language.types.float.php Previous Comments: [2003-01-06 05:16:30] [EMAIL PROTECTED] i should have: 0.01 0.02 0.03 0.04 0.05 0.19 but i get : 0.009998 0.02 0.02999 0.03999 0.05001 0.06 0.07 0.08 0.09 ... 0.19 A test on linux RedHat 6.2 and Windows 2000 SP3 -- Edit this bug report at http://bugs.php.net/?id=21458&edit=1
#21459 [Opn->Bgs]: converting float to int failed sometime
ID: 21459 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: linux and windows PHP Version: 4.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Previous Comments: [2003-01-06 05:17:00] [EMAIL PROTECTED] The output should be 20 and 20, but it's 20 and 19 this strange behavior does not appear for all value. I test on Redhat 6.2 and windows 2000 SP3 I think there was a link to another bug n°21458 -- Edit this bug report at http://bugs.php.net/?id=21459&edit=1
#14365 [Com]: require_once() causes segfault
ID: 14365 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: iPlanet related Operating System: RedHat Linux 7.3 PHP Version: 4.3.0-dev New Comment: We are using evals but the worst I could find was 65 evals on one page (the template system uses evals for nested blocks). The index page has a complex template and needs 55 evals, normal pages only need 4 or 5 evals. Previous Comments: [2003-01-06 01:58:31] [EMAIL PROTECTED] I've read the backtrace page but the bt there doesn't show php filenames and linenumber.. But Sean mailed me that I should try 'bt full', I'll try that the next time. Anyway, as I said I'm using Apache and not iPlanet... The canonicalize problem only seems to occur on 4.3.0, PHP 4.2.3 seems to segfault on memcopy() [2003-01-05 09:33:15] [EMAIL PROTECTED] See http://bugs.php.net/bugs-generating-backtrace.php for details on making backtraces. The stack size appears to be a setting in the iPlanet configuration:Try modifying your ns/threads section to include a larger stacksize...the default one is 128*1024I ran into a stacksize problem on the recent redhat update (related to glibc) that was segfaulting on a dns lookup. I didn't associate it with the segfault I was getting for PHP (Including squirrelmail), but the segfault for SM is gone now for me after this fix and SM works perfectly. Try this sample: ns_section "ns/threads" ns_param stacksize [expr 256*1024] " (quoted from this bug report). I don't have and have never used iPlanet, so it's up to you to find out how to configure it. " [2003-01-05 09:07:05] [EMAIL PROTECTED] I would love to but I don't have a clue how I should do that :D I'm using Apache 1.3.26 and PHP 4.3.0 (but that one segfaults too often) and PHP 4.2.3 (segfaults too but less often, especially when we use a debug build and limit the MaxRequestsPerChild to 10. Nested evals()? Hmm, we shouldn't, I'll go and see if that can be the case. BTW how did Sean create that backtrace? It even shows in what PHP file and on what line Apache/PHP went down... [2003-01-02 11:54:51] [EMAIL PROTECTED] Can you try increasing your stack size as was suggested in one of the earlier responses? The latest backtrace looks *very* deep - are you using a lot of nested eval() calls ? [2003-01-01 14:55:40] [EMAIL PROTECTED] Oh, sorry. Forgot to mention what the site is running on. We're using Apache 1.3.26 with PHP as a module. Info page is over here: http://www.bokt.nl/klad/info.php It's a Redhat 7.3 box with: gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-112) It's an Athlon 1800 XP with 1GB ram and phpBB is using MySQL (MyISAM tables) extensively. Some stats can be seen on: http://www.bokt.nl/stats/ 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/14365 -- Edit this bug report at http://bugs.php.net/?id=14365&edit=1
#21459 [NEW]: converting float to int failed sometime
From: [EMAIL PROTECTED] Operating system: linux and windows PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: converting float to int failed sometime The output should be 20 and 20, but it's 20 and 19 this strange behavior does not appear for all value. I test on Redhat 6.2 and windows 2000 SP3 I think there was a link to another bug n°21458 -- Edit bug report at http://bugs.php.net/?id=21459&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21459&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21459&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21459&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21459&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21459&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21459&r=support Expected behavior: http://bugs.php.net/fix.php?id=21459&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21459&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21459&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21459&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21459&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21459&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21459&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21459&r=gnused
#21458 [NEW]: simple calcul have strange result
From: [EMAIL PROTECTED] Operating system: linux and windows PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: simple calcul have strange result i should have: 0.01 0.02 0.03 0.04 0.05 0.19 but i get : 0.009998 0.02 0.02999 0.03999 0.05001 0.06 0.07 0.08 0.09 ... 0.19 A test on linux RedHat 6.2 and Windows 2000 SP3 -- Edit bug report at http://bugs.php.net/?id=21458&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21458&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21458&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21458&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21458&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21458&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21458&r=support Expected behavior: http://bugs.php.net/fix.php?id=21458&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21458&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21458&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21458&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21458&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21458&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21458&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21458&r=gnused
#21224 [Com]: apache configure fails at php module
ID: 21224 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Problem solved (for me) when removing --enable-versioning from the configure Previous Comments: [2002-12-30 09:32:31] [EMAIL PROTECTED] I'm having the same problem building 4.3.0 with Apache on my server, previous builds were ok: RedHat Linux 7.1 kernel 2.4.18-18.7.xsmp gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.1) ld -v GNU ld version 2.10.91 (with BFD 2.10.91.0.2) libtool --version ltmain.sh (GNU libtool) 1.3.5 (1.385.2.206 2000/05/27 11:12:27) ./configure --prefix=/usr/local/php \ --with-config-file-path=/usr/local/php --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql --with-oci8=/usr/local/oracle \ --with-oracle=/usr/local/oracle --with-sybase-ct=/opt/sybase-12.5/OCS-12_5 \ --with-pdflib=/usr/local/pdflib --with-jpeg --with-tiff --with-zlib \ --with-gd --with-ttf --with-freetype --with-xml --with-gettext \ --enable-ftp --enable-versioning --enable-sockets --enable-calendar \ --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-debugger \ --enable-magic-quotes --enable-rpath --enable-short-tags --enable-posix \ --enable-session --enable-xml --enable-bcmath --enable-ctype --enable-mailparse \ --with-apache=../apache_1.3.27 ./configure --with-layout=Apache --prefix=/usr/local/apache \ --activate-module=src/modules/php4/libphp4.a --enable-module=so \ --enable-module=rewrite --add-module=mod_gzip.c Configuring for Apache, Version 1.3.27 + using installation path layout: Apache (config.layout) + activated php4 module (modules/php4/libphp4.a) + on-the-fly added and activated gzip module (modules/extra/mod_gzip.o) Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o rewrite_module uses ConfigStart/End + using -lndbm for DBM support enabling DBM support for mod_rewrite o php4_module uses ConfigStart/End + using system Expat + using -ldl for vendor DSO support + checking sizeof various data types + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; gcc -DLINUX=22 -I/usr/include/db1 `./apaci` -o helpers/dummy helpers/dummy.c -Wl,-rpath,/usr/local/mysql/lib/mysql -Wl,-rpath,/usr/local/oracle/lib -Wl,-rpath,/lib -Wl,-rpath,/usr/local/pdflib/lib -Wl,-rpath,/usr/local/pgsql/lib -Wl,-rpath,/opt/sybase-12.5/OCS-12_5/lib -rdynamic -L/usr/local/mysql/lib/mysql -L/usr/local/oracle/lib -L/lib -L/usr/local/pdflib/lib -L/usr/local/pgsql/lib -L/opt/sybase-12.5/OCS-12_5/lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -export-symbols /usr/local/src/php-4.3.0/sapi/apache/php.sym -rdynamic -L/usr/local/mysql/lib/mysql -L/usr/local/oracle/lib -L/lib -L/usr/local/pdflib/lib -L/usr/local/pgsql/lib -L/opt/sybase-12.5/OCS-12_5/lib -lsybtcl -lintl -lcomn -lct -lcs -lpq -lpdf -lz -lpng -lmysqlclient -lttf -lpng -lz -lz -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -ldl -lm -lnsl -lclntsh -ldl -lm -lnsl -lclntsh -lm -lcrypt -lndbm -lexpat -ldl /usr/bin/ld:/usr/local/src/php-4.3.0/sapi/apache/php.sym: file format not recognized; treating as linker script /usr/bin/ld:/usr/local/src/php-4.3.0/sapi/apache/php.sym:2: parse error collect2: ld returned 1 exit status make: *** [dummy] Error 1 = End of Error Report = Aborting! [2002-12-30 05:59:59] [EMAIL PROTECTED] Same problem at Linux RedHat 6.2 machines, some with: GNU ld 2.9.5 ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) and others with: GNU ld 2.13.2 ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [2002-12-28 04:33:22] [EMAIL PROTECTED] the libtool on the php distribution tree is: ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) I have to say that previous versions of php up to 4.3.0rc2 compiled fine on the same system. [2002-12-28 01:01:44] [EMAIL PROTECTED] What version of libtool are you using? [2002-12-27 16:58:54] [EMAIL PRO
#21457 [Opn->Bgs]: Error in pack() function
ID: 21457 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 98 SE PHP Version: 4.3.0 New Comment: :) Previous Comments: [2003-01-06 04:32:36] [EMAIL PROTECTED] Error in pack() function, see code below. file "test": : 01 0D 0A -- Edit this bug report at http://bugs.php.net/?id=21457&edit=1
#20503 [Asn->Csd]: [chm] bug on function.imagesetbrush.html
ID: 20503 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: GD related Operating System: windows PHP Version: 4.2.3,4.3.0-dev,4.4.0-dev Assigned To: edink New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-11-19 17:53:45] [EMAIL PROTECTED] The windows build files just don't define HAVE_GD_IMAGESETBRUSH which would make this function available on win32 too.. [2002-11-19 17:40:31] [EMAIL PROTECTED] [2002-11-19 14:14:24] [EMAIL PROTECTED] I have found a bug on page function.imagesetbrush.html [chm date: 2002-08-28]... windows php v 4.2.3 report 'Warning: imagesetbrush(): requires a more recent version of GD ' php.ini extension=php_gd2.dll ;extension=php_gd.dll in Linux php all ok. Why? -- Edit this bug report at http://bugs.php.net/?id=20503&edit=1
#21454 [Opn->Bgs]: Output line too long. ; gcc: TSR: No such file or directory
ID: 21454 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: solaris PHP Version: 4.3.0 New Comment: Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. Previous Comments: [2003-01-06 02:30:42] [EMAIL PROTECTED] solaris 8 5.8 Generic_108528-13 Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.1 configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-versioning make make fails with: [..] ck.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -lresolv -lm -ldl -lnsl -lsocket -lgcc -lcrypt -o sapi/cli/php Output line too long. Output line too long. Output line too long. gcc: TSR: No such file or directory make: *** [sapi/cli/php] Error 1 -- Edit this bug report at http://bugs.php.net/?id=21454&edit=1
#21457 [NEW]: Error in pack() function
From: [EMAIL PROTECTED] Operating system: Windows 98 SE PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: Error in pack() function Error in pack() function, see code below. file "test": : 01 0D 0A -- Edit bug report at http://bugs.php.net/?id=21457&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21457&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21457&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21457&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21457&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21457&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21457&r=support Expected behavior: http://bugs.php.net/fix.php?id=21457&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21457&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21457&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21457&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21457&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21457&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21457&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21457&r=gnused
#19927 [Com]: Printer error after several pages print
ID: 19927
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows 98
PHP Version: 4.2.3
New Comment:
Hi all,
I've exactly the same problem as you in Win98/ME Operating System.
In Win2K it runs without any problem.
Previous Comments:
[2002-11-12 17:41:03] [EMAIL PROTECTED]
same bug on win2000 server and apache2 (php 4.2.3).
restarting the apache2 helps for the next
30-50 pages.
This bug only appears by printing a higher amount of pages;
for single page printjobs everything works fine.
[2002-10-16 00:28:47] [EMAIL PROTECTED]
I print various letters and various forms every day using PHP.
However, when I want to print a mass mailing of 200 letters to
different people, php will error out after printing approximately 20
pages. It seems that the amount of pages that print is directly
proportionate to the amount of fill (verbage) placed on a page.
Warning: couldn't start a new page in
C:\apache\htdocs\print\print_td.php on line 20
Warning: couldn't end the page in C:\apache\htdocs\print\print_td.php
on line 87
Warning: couldn't start a new page in
C:\apache\htdocs\print\print_td.php on line 20
Warning: couldn't end the page in C:\apache\htdocs\print\print_td.php
on line 87
Warning: couldn't allocate new print job in
C:\apache\htdocs\print\print_td.php on line 19
Warning: couldn't end the page in C:\apache\htdocs\print\print_td.php
on line 87
Fatal error: couldn't terminate print job in
C:\apache\htdocs\print\print_td.php on line 88
Below is a snip-it of just printing out a heading over and over again
which seems to error the same way as my letters do
I tried printing to a Novell que, and directly to an LPT1 and get the
same results.
#3
$p='printer name';
$copies = 100;
while($copies > 0) {
$handle = printer_open("$p");
printer_start_doc($handle);
printer_start_page($handle);
# FONT
$font = printer_create_font("Times New Roman", 200, 85,
PRINTER_FW_BOLD, false, false, false, 0);
printer_select_font($handle, $font);
printer_draw_text($handle, " College", 400, 130);
printer_delete_font($font);
$font = printer_create_font("Arial", 72, 35, PRINTER_FW_LIGHT, false,
false, false, 0);
printer_select_font($handle, $font);
printer_draw_text($handle, " W. Wilson Ave. Chicago, Illinois
60640", 400, 300);
printer_delete_font($font);
$font = printer_create_font("Arial", 72, 30, PRINTER_FW_NORMAL, false,
false, false, 0);
printer_select_font($handle, $font);
printer_draw_text($handle, "www.XXXcollege.net", 3800, 300);
printer_delete_font($font);
# LINE DRAW
$pen = printer_create_pen(PRINTER_PEN_SOLID, 3, "00");
printer_select_pen($handle, $pen);
printer_draw_line($handle, 30, 380, 5000, 380);
printer_delete_pen($pen);
$font = printer_create_font("Arial", 72, 36, PRINTER_FW_MEDIUM, false,
false, false, 0);
printer_select_font($handle, $font);
printer_draw_text($handle, "Office of Financial Aid", 400, 400);
printer_draw_text($handle, "773 907- ", 1590, 400);
printer_draw_text($handle, "[EMAIL PROTECTED]", 3800, 400);
printer_delete_font($font);
#
# #NAME AND
ADDRESS AND BODY OF LETTER WOULD PRINT HERE
### STUDENT ID
printer_end_page($handle);
printer_end_doc($handle);
printer_close($handle);
$copies = $copies - 1;
} // END WHILE COUNT
### END ROUTINE
Any consideration to my problem will be greatly appreciated.
--
Edit this bug report at http://bugs.php.net/?id=19927&edit=1
#21455 [Opn->Bgs]: Displaying records from mysql in a tabular form
ID: 21455 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: windows 97 PHP Version: 4.2.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Previous Comments: [2003-01-06 02:30:48] [EMAIL PROTECTED] hi! i'm a beginner in php and i've learned the below method of displaying records from mysql.i have discoverd that this method wastes space. could you please offer me any kind of help that will enable me to display the records in a table depending on the items i enter on my form.i want the names of the headings to be at the top,and then the records must follow in the rows on a table. your help will appreciated. ".$fieldname." ".": ".$fieldvalue."";?> -- Edit this bug report at http://bugs.php.net/?id=21455&edit=1
#21455 [NEW]: Displaying records from mysql in a tabular form
From: [EMAIL PROTECTED] Operating system: windows 97 PHP version: 4.2.0 PHP Bug Type: MySQL related Bug description: Displaying records from mysql in a tabular form hi! i'm a beginner in php and i've learned the below method of displaying records from mysql.i have discoverd that this method wastes space. could you please offer me any kind of help that will enable me to display the records in a table depending on the items i enter on my form.i want the names of the headings to be at the top,and then the records must follow in the rows on a table. your help will appreciated. ".$fieldname." ".": ".$fieldvalue."";?> -- Edit bug report at http://bugs.php.net/?id=21455&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21455&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21455&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21455&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21455&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21455&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21455&r=support Expected behavior: http://bugs.php.net/fix.php?id=21455&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21455&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21455&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21455&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21455&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21455&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21455&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21455&r=gnused
#21454 [NEW]: Output line too long. ; gcc: TSR: No such file or directory
From: [EMAIL PROTECTED] Operating system: solaris PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: Output line too long. ; gcc: TSR: No such file or directory solaris 8 5.8 Generic_108528-13 Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.1 configure --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-versioning make make fails with: [..] ck.lo Zend/zend_variables.lo Zend/zend.lo Zend/zend_API.lo Zend/zend_extensions.lo Zend/zend_hash.lo Zend/zend_list.lo Zend/zend_indent.lo Zend/zend_builtin_functions.lo Zend/zend_sprintf.lo Zend/zend_ini.lo Zend/zend_qsort.lo Zend/zend_multibyte.lo Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo main/internal_functions_cli.lo -lcrypt -lresolv -lm -ldl -lnsl -lsocket -lgcc -lcrypt -o sapi/cli/php Output line too long. Output line too long. Output line too long. gcc: TSR: No such file or directory make: *** [sapi/cli/php] Error 1 -- Edit bug report at http://bugs.php.net/?id=21454&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21454&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21454&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21454&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21454&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21454&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21454&r=support Expected behavior: http://bugs.php.net/fix.php?id=21454&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21454&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21454&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21454&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21454&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21454&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21454&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21454&r=gnused
#21450 [Opn]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Unknown/Other Function
+Bug Type: Feature/Change Request
Operating System: Windows 2000 Pro
PHP Version: 4CVS-2003-01-05 (dev)
-Assigned To:
+Assigned To: sesser
New Comment:
Content-disposition: form-data; filename="etc\root.hint"
This line of the rfc1867 fileupload lacks a name="whatever"
attribute. PHP cannot handle anonymous fileuploads for now... (I will
implement that)
Previous Comments:
[2003-01-05 22:29:03] [EMAIL PROTECTED]
Here is a capture of a complete request made by WPW:
POST /temp/fb.php HTTP/1.1
Accept: */*
Content-Type: Multipart/Form-Data,boundary=19359@23195#13275
User-Agent: Microsoft HTTP Post (RFC1867)
Host: 10.0.0.7
Connection: Keep-Alive
Cache-Control: no-cache
Content-Length: 3002
--19359@23195#13275
Content-disposition: form-data; filename="etc\root.hint"
Content-type: application/octet-stream
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . "
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file/domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher atRS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; filenamed.root
;
; last update:Aug 22, 1997
; related version of root zone: 1997082200
;
;
; formerly NS.INTERNIC.NET
;
.360 IN NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 360 A 198.41.0.4
;
; formerly NS1.ISI.EDU
;
.360 NSB.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 360 A 128.9.0.107
;
; formerly C.PSI.NET
;
.360 NSC.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 360 A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
.360 NSD.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 360 A 128.8.10.90
;
; formerly NS.NASA.GOV
;
.360 NSE.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 360 A 192.203.230.10
;
; formerly NS.ISC.ORG
;
.360 NSF.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 360 A 192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.360 NSG.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 360 A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.360 NSH.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 360 A 128.63.2.53
;
; formerly NIC.NORDU.NET
;
.360 NSI.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 360 A 192.36.148.17
;
; temporarily housed at NSI (InterNIC)
;
.360 NSJ.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 360 A 198.41.0.10
;
; housed in LINX, operated by RIPE NCC
;
.360 NSK.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 360 A 193.0.14.129
;
; temporarily housed at ISI (IANA)
;
.360 NSL.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 360 A 198.32.64.12
;
; housed in Japan, operated by WIDE
;
.360 NSM.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 360 A 202.12.27.33
; End of File
--19359@23195#13275--
[2003-01-05 21:47:40] [EMAIL PROTECTED]
When using microsoft web publishing wizard to post files to a php
script $_FILES is always empty. Logged in my php error log is:
[06-Jan-2003 16:46:49] PHP Warning: File Upload Mime headers garbled
in Unknown on line 0
It is able to reteive some of the post values but not the files. Is
this really a Microsoft RFC compliance problem or a PHP problem?
Using the following script:
$value) {
fwrite($fp, "$header: $value\n");
}
fclose($fp);
echo $content;
I set WPW to HTTP Post files to the URL of this script and the files
are never available. A common entry in fb.log looks like this:
New Hit
**
$_SERVER:
array (
'COMSPEC' => 'C:WINNTsystem32cmd.exe',
'CONTENT_LENGTH' => '189',
'CONTENT_TYPE' => 'Multipart/Form-Data,boundary=23264@18686#20663',
'DOCUMENT_ROOT' => 'i:/httpd/www.graftonhall.co.nz/htdocs',
'HTTP_ACCEPT' => '*/*',
