#38138 [Opn]: russian encoding detection support
ID: 38138 Updated by: techto...@php.net Reported By: techto...@php.net Status: Open Bug Type:Feature/Change Request PHP Version: 4.4.2 New Comment: It is not freeware - it's open source. That basically means that you have all the tools to do it yourself and contribute back for others. Or learn some other language. Previous Comments: [2009-08-28 23:54:53] jehy at valar dot ru Already three years. Still no changes. That's why I hate freeware. [2009-03-20 11:14:20] wips at mail dot ru Another version of encoding detector http://popoff.donetsk.ua/file/text/libs/a.charset.php which works with utf8 too. [2009-01-21 08:46:35] Roman dot Kyrylych at gmail dot com here's a russian encoding autodetector that can be used after mb_detect_encoding returned false: http://www.opennet.ru/base/dev/charset_autodetect.txt.html [2008-10-11 04:40:21] maybeoutput at gmail dot com Two years old bug and still can't detect encoding? [2008-10-04 23:07:03] dennis at nikolaenko dot ru I also bumped into this, just voting. 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/38138 -- Edit this bug report at http://bugs.php.net/?id=38138edit=1
#33016 [NoF]: Access Violation when trying to create any COM object
ID: 33016 Updated by: [EMAIL PROTECTED] Reported By: bas dot timmer at gmail dot com Status: No Feedback Bug Type: COM related Operating System: Windows NT 4.0 Service Pack 6A -PHP Version: 4CVS-2005-05-12 (stable) +PHP Version: 4.4.1 New Comment: Crash reproduced on W2K SP4 + PHP 4.4.1 (cli) (built: Oct 30 2005 12:45:47). ?php $my = new COM(MY.UNEXISTENT) or die (create fail); ? Previous Comments: [2005-05-20 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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. [2005-05-12 22:06:13] [EMAIL PROTECTED] Please upgrade to PHP 5. Support for COM in PHP 4 is not available for free, since it was rewritten from scratch for PHP 5. [2005-05-12 15:00:56] bas dot timmer at gmail dot com Description: I get an Access Violation in php.exe, or the ISAPI dll when trying to use new COM. Reproduce code: --- ?php $acctDomain = localhost; echo Making COM connection using ADSI\n\r; $acctStr = WinNT://.$acctDomain; echo $acctStr\n\r; $comUsers = new COM($acctStr); echo new COM Sucessful; ? Expected result: Don't crash, just make the COM object available to me. Actual result: -- I get this error: PHP has encountered an Access Violation at 01568A68Make User Warning: mkdir(D:\inetpub\wwwroot\hosttest): File exists in D:\Inetpub\wwwroot\ntfunc.php on line 13 Warning: (null)(): Invalid ProgID, GUID string, or Moniker: Invalid syntax in D:\Inetpub\wwwroot\ntfunc.php on line 15 Or an DrWatson32 when trying to execute from command line. -- Edit this bug report at http://bugs.php.net/?id=33016edit=1
#34266 [Fbk-Bgs]: Apache 2.0.50 crashes from time to time
ID: 34266 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Reproducible crash Operating System: W2K SP4 PHP Version: 4.4.0 New Comment: Forget about it. Sorry, there's no another day to spend for studying some obscure patterns of another application framework. It seems to be a memory problem anyway and I don't think that I be able to come up with a simple script for that. I'll better switch to another platform. Previous Comments: [2005-08-28 00:57:05] [EMAIL PROTECTED] Then you need to come up with a reproducing script. [2005-08-26 17:46:59] [EMAIL PROTECTED] The problem is that this framework (binarycloud) is not for PHP 5 yet. [2005-08-26 17:09:44] [EMAIL PROTECTED] a) Try and see if you can reproduce these crashes with PHP 5.1 snapshot first b) If you get the crashes, grab the debug pack from same place http://snaps.php.net/ [2005-08-26 17:05:51] [EMAIL PROTECTED] Following instructions from http://bugs.php.net/bugs-generating-backtrace.php I've got the following output. Seems that I need debug version of php4ts.dll - I don't know where to get any and failed to compile one myself from recent sources snapshot. C:\httpd\bingdb.exe Apache.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-mingw32...(no debugging symbols found)... (gdb) run -X Starting program: C:\WINDEX\httpd\bin/Apache.exe -X ---Type return to continue, or q return to quit--- ---Type return to continue, or q return to quit--- Program received signal SIGSEGV, Segmentation fault. [Switching to thread 664.0x668] 0x77d5d670 in ?? () (gdb) bt #0 0x77d5d670 in ?? () #1 0x77d5d6ab in ?? () #2 0x7c2e4225 in ?? () (gdb) [2005-08-26 13:32:16] [EMAIL PROTECTED] We really need a short script to reproduce it, or a useful backtrace. 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/34266 -- Edit this bug report at http://bugs.php.net/?id=34266edit=1
#11074 [Bgs]: array_splice used to insert associative array forgets first key
ID: 11074 Updated by: [EMAIL PROTECTED] Reported By: symetrie at online dot fr Status: Bogus Bug Type: Arrays related Operating System: Linux SuSE 6.4 -PHP Version: 4.0.4pl1 +PHP Version: 4.3.10 New Comment: array_splice doesn't preserve keys from replacement arrays. I wonder if it is possible to add optional preserve_keys parameter in PHP5? Previous Comments: [2002-02-26 21:37:46] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. [2001-05-23 22:04:42] symetrie at online dot fr It seems to be impossible to replace a key in associative array with another array : array_splice always add a '0' key... Feature or bug ? ?php $a = array(a = AA, b = BB, c = CC); $a2 = $a; $z = array(z = array(z1=ZZ1,z2=ZZ2), x =XX); // 1 try to replace b=BB by contents of $z array_splice($a, 1, 1, $z); print_r($a); // produces : Array ( [a] = AA [0] = Array ( [z1] = ZZ1 [z2] = ZZ2 ) [1] = XX [c] = CC ) echo hr; // 2 try to replace b=BB by contents of $z as in manual array_splice($a, 1, 1, array($z)); print_r($a); // produces : Array ( [a] = AA [0] = Array ( [z] = Array ( [z1] = ZZ1 [z2] = ZZ2 ) [x] = XX ) [1] = XX [c] = CC ) // I'd like : // Array ( [a] = AA [z] = Array ( [z1] = ZZ1 [z2] = ZZ2 ) [1] = XX [c] = CC ) ? -- Edit this bug report at http://bugs.php.net/?id=11074edit=1
#22108 [Asn]: php doesn't ignore the utf-8 BOM
ID: 22108 Updated by: [EMAIL PROTECTED] Reported By: bugzilla at jellycan dot com Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: * Assigned To: moriyoshi New Comment: How about making this --enable-zend-multibyte default option? Is it possible to port this support for windows too? And for 4.3.x branch? Should it be marked open again? Previous Comments: [2004-05-25 12:33:30] lapo at lapo dot it Adding '--enable-zend-multibyte' to latest PHP5 port for FreeBSD for sure solves the problem: All files contain: ? header(Content-Language: it); echo àèéìòù\n; ? cyberx [~] $ php /usr/tmp/utf8-bom.php à èéìòù cyberx [~] $ php /usr/tmp/utf8Y-bom.php àèéìòù cyberx [~] $ php /usr/tmp/utf16-bom.php àèéìòù cyberx [~] $ php /usr/tmp/utf16BE-bom.php àèéìòù cyberx [~] $ php /usr/tmp/utf16LE-bom.php àèéìòù Except for UTF8 without BOM that is, of course, not distinguishable from ISO8859-15 (default here), all theother formats are correctly interpreted and outputted. (notice that the 'header' instruction prior of the 'echo' one would stutter with a non-BOM-aware PHP compile). I wonder if and when this great multibyte support would be available by default in Win32 compiles, I would really use it for work and am not willing to but VisualC just to compile that ;-) (though I'm trying compiling it with cygwin's gcc using '-mno-cygwin' option, we'll see...) [2003-11-09 16:12:50] a9c83cd8bb41db324db5b449352f183 at arcor dot de Thought about it... Now I think it's better when the BOM isn't part of the output because that would cause trouble if you want to output images or PDF or something like that... [2003-11-08 06:45:22] a9c83cd8bb41db324db5b449352f183 at arcor dot de I think the best would be that PHP recognizes the BOM and outputs it before it outputs the document (but after the HTTP headers, of course) so that the document can still be recognized as UTF-8 when it's saved to disk (where no Content-Type headers with a charset specification are available). [2003-10-31 11:12:06] [EMAIL PROTECTED] I added i18n support to Zend Engine 2 (though it's still partial one...), and one of its features contain awareness of BOM. So now you can gracefully parse scripts with BOM if you use PHP 5.0.0b2 and configure it with the option '--enable-zend-multibyte'. These features are still experimental and under testing, so that I have not been documented these but I'll add the entry to the manual, ZEND_CHANGES and so on if I feel certain of the stability and robustness of my patch, though I do not know when it is:) Anyway, I'll close this bug if '--enable-zend-multibyte' option in PHP 5.0.0b2 is assured to work well for this problem. Comments are welcome. [2003-02-07 23:13:07] bugzilla at jellycan dot com The BOM (byte order mark) is a few bytes at the very front of a file that act as a signature denoting what type of encoding has been used, and in UTF16/32 it also makes the byte order (LE or BE). Although utf-8 is byte order independent, it has become popular on windows (perhaps not so on unix) to make use of the BOM encoded in UTF-8 to flag the file as being in UTF-8 format. This allows editors to determine the type of the file from the first few characters instead of trying to guess what type the file is. Ref: Textpad 4.6 (http://textpad.com) See the Unicode FAQ for details of the utf-8 BOM... http://www.unicode.org/unicode/faq/utf_bom.html#25 The use of this should be obvious, you have to leave the my-language-only mindset that afflicts too many programmers (myself included before this job) and think about the growing multiplicity of languages on the web. I am writing web applications in Japan, with European language and CJK (Chinese/Japanese/Korean) language processing and interfaces. Thus I have php files where variable values are strings of all sorts of languages - hence utf-8 encoding. I feel that this is definitely a bug in php. Considering that: * php is slowly growing into a language-neutral (i18n/l10n possible) language * php is designed such that php commands can be liberally sprinkled through html, and html is increasing encoded in utf-8 these days * the utf-8 bom is becoming increasingly popular for reasons of indentifying the file character format * if the utf-8 bom exists php actually outputs it incorrectly and in doing so prevents header output I request that you don't see this as a feature request, but as a bug in the handling of utf-8 files. Whether the output generator is the correct characterization of this bug or not I leave up to you.
#25876 [Csd-Opn]: session_start(): Failed to initialize storage module
ID: 25876
Updated by: [EMAIL PROTECTED]
Reported By: golden at riscom dot com
-Status: Closed
+Status: Open
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
Confirmed on SF.net 4.3.10 Linux
Try several times until error.
http://farplugins.sourceforge.net/test/php.php
?
session_start();
echo $PHPSESSID;
?
http://farplugins.sourceforge.net/test/in.php
?php phpinfo(); ?
/home/groups/f/fa/farplugins/htdocs/test/.htaccess
IfModule mod_php4.c
php_value session.save_path
/home/groups/f/fa/farplugins/htdocs/test/tmp
/IfModule
Previous Comments:
[2004-09-28 23:12:14] coadmin at hostings dot pl
We have the same problem.
FreeBSD 4.10-STABLE, PHP 4.3.8, Apache 1.3.31
how to repeat:
?
session_start();
echo $PHPSESSID;
?
then refresh the website a many times.
you will receive an error:
Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp) in /home/xxx/public_html/index.php on line 2
the problem still exists also when using custom dir for saving session
files.
[2004-08-16 17:32:30] ron at dse dot nl
Clearing the x-bit did not solve the problem. Probably this bug is not
really related to the X-bit-hack but merely very similar in it's
effects.
The way to work around this bug is by avoiding php ini settings in all
.htaccess files on your Apache server and instead put them in the
application. For Drupal for instance, I moved these settings to
conf.php by using ini_set() there. Squirrelmail even has a special
config_local.php that you can use for this.
More info on my particular setup:
Apache 1.3.29 with o.a. mod_suexec and mod_rewrite
PHP 4.3.8 (but same issue with 4.3.4)
applications installed within same vhost
Hope this will help developers find this annoying bug.
[2004-08-08 20:48:47] ron at dse dot nl
Spent over a day troubleshooting as well. I think the real problem is
described here: http://bugs.php.net/bug.php?id=25753
Although the suggested bug fix over there seems to have been
incorporated in up to version 4.3.8, the behaviour still exists. The
bug is easily triggered by running Squirrelmail and Drupal off the same
Apache server as in my case. Drupal sets the session.save_handler to
'user' by a directive in the .htaccess file that comes with the
installation. If, by accident, the next request by the same Apache
child process is for a squirrelmail user, then the squirrelmail
session_start() fails with 'Failed to initialize storage module'. This
happens because the session.save_handler is still set to user instead
of file, it is not reset to the master value for the child process. It
is a matter of random luck which child process will serve the
squirrelmail request so that explains the intermittent occurance.
As mentioned by rasmus this only happens on text/html files with the
executable bit set. Clearing the bit for all of the squirrelmail PHP
files seems to be useful a workaround. Just perform a
find . -name '*.php' -type f -exec chmod -x {} ';'
in your squirrelmail (or other PHP application) directory and restart
your Apache server (for some reason this was necessary).
[2004-05-05 07:27:32] tkaeser at gmx dot net
Hi,
had the same error, added the following line before starting the
session:
ini_set('session.save_handler', 'files');
this fixed it in my case...
I don't have any idea why this works, got it from
http://lists.mushaake.org/pipermail/php/Week-of-Mon-20031117/004091.html
[2004-04-05 08:17:56] venkat at ehostpros dot com
#
Problem :
Fatal error: session_start(): Failed to initialize storage module
#
The solution (fingers crossed) was to clear the session.save_path
directory - it got thousands of session files there.
Hope it helps someone out there.
#
The above solution works fine :)
Thanks,
Venkatesh.G
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876edit=1
#18373 [Bgs]: unread_bytes always 0
ID: 18373 Updated by: [EMAIL PROTECTED] Reported By: webmaster at darkenemy dot com Status: Bogus Bug Type: Sockets related Operating System: Windows Server Platform PHP Version: 4.2.1 New Comment: feof() doesn't work with blocked sockets like flag for available data. When it is time to see if more data is available and feof() returns true that means that socket is actually closed. Perhaps I can say where is a bug actually. When you write to a blocked socket with fwrite() it resets internal socket buffer and the next thing you'd like to know is when the data will be available. Now there's no way to get that info. You can try to execute a read operation and enter an endless loop waiting for the data to appear from the other end until either script timeout happened or somebody will send the data. Previous Comments: [2002-10-05 09:12:29] [EMAIL PROTECTED] unread_bytes is the number of bytes remaining in PHPs buffering layer after the last read. If you have consumed all data from the buffer on a prior read, unread_bytes will remain at zero until you next read a chunk of data from the network. So, unread_bytes should not be used to determine if more data is pending; you should use either: a. feof() to detect end of file. Don't forget that you can use non-blocking mode here. b. PHP 4.3 has a new function called stream_select() which behaves like socket_select() from the sockets extension, but works on all files returned by fopen() and fsockopen(). You can use it to test which files are ready for reading/writing and also specify a timeout. PHP 4.3 is about to enter the release process, but you can try a non-stable snapshot from http://snaps.php.net/win32. (It's probably best to wait a couple of hours, as some important bug fixes have been made this morning). --Wez. [2002-09-25 09:25:10] webmaster at darkenemy dot com I want to check the socket, whether there is data that must be read. Otherwise the script should do other things. At moment the situation is, that the script only can do other things, after read some data from the socket. The most popular thing, that requires this mechanism, is to write an IRC client with PHP, that can be used like cgi irc. Don't know whether is possible with any current php build for Linux, under Windows it wasn't possible with the builds from July 2002. I tried blocking and non blocking mode, but the stream reseted. So I prefered blocking mode, because the control about the socket is better. The script only must know, whether there is data to read from the socket, so that a request to the socket doesn't stop the script, until there is some data. [2002-09-25 09:19:07] [EMAIL PROTECTED] Well, that depends on how you use the information. If the goal is to detect a possible block(which looks like what your code is doing), then when that value is 0, there is no data left on the socket. The same is true if blocked is set, and if eof is set. What would your reason be to look at the sytems buffer? -Jason [2002-09-11 11:47:26] webmaster at darkenemy dot com Sorry, I had posted some more feedback. Don't know where it is now. So I'll do again: I tested that CVS build and the result was, that unread_bytes told me the number of bytes, containing the PHP internal socket buffer and not the number of bytes, available on that socket. And I think, that unread_bytes should exactly mean that. Otherwise it would be some less useful. [2002-09-11 11:37:46] [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. 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/18373 -- Edit this bug report at http://bugs.php.net/?id=18373edit=1
#30056 [NEW]: Merge CLI and CGI functionality
From: techtonik at tut dot by Operating system: PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: Merge CLI and CGI functionality Description: I know that it is strange request and for developers it is more difficult to support two different functionalities in one binary, but.. For a long run PHP had this two .exe messing around and often it was quite easy to mention CLI instead of CGI and vice versa. With PHP5 CLI version becomes default and CGI migrated into directory. In PHP4 in directory was CLI version. Although it is quite easy to remember, it is rather hard to explain users what is CGI or CLI, why their php.exe is incorrect and where to find another php.exe. Often they just replace CGI with CLI (with correct version, ehh) and after upgrade to the story begins anew. I know that this is not so easy, but if there were a voting systems for proposals I bet this one would be in the first 20. I propose to leave default behavior as CGI and use -f key to execute script in CLI mode. Of course, it is more convenient to leave default mode to CLI, but it can probably lead to incompatibilities with CGI specification. Reproduce code: --- CGI behavior php.exe file.php CLI php.exe -f file.php -- Edit bug report at http://bugs.php.net/?id=30056edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30056r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30056r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30056r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30056r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30056r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30056r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30056r=needscript Try newer version: http://bugs.php.net/fix.php?id=30056r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30056r=support Expected behavior: http://bugs.php.net/fix.php?id=30056r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30056r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30056r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30056r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30056r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30056r=dst IIS Stability: http://bugs.php.net/fix.php?id=30056r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30056r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30056r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30056r=mysqlcfg
#30056 [WFx]: Merge CLI and CGI functionality
ID: 30056 User updated by: techtonik at tut dot by Reported By: techtonik at tut dot by Status: Wont fix Bug Type:Feature/Change Request PHP Version: Irrelevant New Comment: Sure it will introduce some problems, but only with PHP and support scripts installation and only with one of the CGI and CLI stepbrothers. This is major change and it, of course, should be indicated at the top of install.txt. Those, who are running CGI version won't feel any changes in PHP's behavior. Only CLI users will need to change their PHP detection routines by adding -f or --cli key to execute the scipt. There also can be some environment checks to detect CGI or CLI mode of PHP executable along with explicit keys. At least you can make it phpi.exe or phpex.exe. If they are so different, you can glue the binaries and include stub, which will parse cmdline or cgi environment variables and pass control to appropriate part. This is a bad solution, since CLI version is very limited under windows (it doesn't understand ordinary quotes, for example), but it will be possible to release such thing at least in next year. Previous Comments: [2004-09-10 23:21:08] [EMAIL PROTECTED] You are at least one year to late. Now such a change would introduce a major BC problem for both versions. Also it is not so easily to merge them because they are in fact very different. Just read the docs and be done. If some users don't read it and get a problem, well than it is their problem. [2004-09-10 21:26:07] techtonik at tut dot by Description: I know that it is strange request and for developers it is more difficult to support two different functionalities in one binary, but.. For a long run PHP had this two .exe messing around and often it was quite easy to mention CLI instead of CGI and vice versa. With PHP5 CLI version becomes default and CGI migrated into directory. In PHP4 in directory was CLI version. Although it is quite easy to remember, it is rather hard to explain users what is CGI or CLI, why their php.exe is incorrect and where to find another php.exe. Often they just replace CGI with CLI (with correct version, ehh) and after upgrade to the story begins anew. I know that this is not so easy, but if there were a voting systems for proposals I bet this one would be in the first 20. I propose to leave default behavior as CGI and use -f key to execute script in CLI mode. Of course, it is more convenient to leave default mode to CLI, but it can probably lead to incompatibilities with CGI specification. Reproduce code: --- CGI behavior php.exe file.php CLI php.exe -f file.php -- Edit this bug report at http://bugs.php.net/?id=30056edit=1
#28508 [NEW]: hypot is broken
From: techtonik at tut dot by Operating system: Windows 2000 PHP version: 4.3.6 PHP Bug Type: Math related Bug description: hypot is broken Description: hypot() support seems to be broken on windows. Can anybody confirm? Reproduce code: --- ?php $x = hypot(3, 4); var_dump($x); ? Expected result: 5 Actual result: -- NULL -- Edit bug report at http://bugs.php.net/?id=28508edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28508r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28508r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28508r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28508r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28508r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28508r=needscript Try newer version: http://bugs.php.net/fix.php?id=28508r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28508r=support Expected behavior: http://bugs.php.net/fix.php?id=28508r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28508r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28508r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28508r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28508r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28508r=dst IIS Stability: http://bugs.php.net/fix.php?id=28508r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28508r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28508r=float
#27526 [Bgs-Opn]: Loading TiFF file crashes Apache 2.0.48
ID: 27526 User updated by: techtonik at tut dot by Reported By: techtonik at tut dot by -Status: Bogus +Status: Open Bug Type: *PDF functions Operating System: Windows 2000 -PHP Version: 4.3.5RC3 +PHP Version: 4.3.6RC2 New Comment: So, will you upgrade PDFlib in PHP distributive to latest available? Previous Comments: [2004-03-13 14:10:44] techtonik at tut dot by Why don't you include latest 4.0.3 Pdflib in distributive? http://www.pdflib.com/support/faq.html#PHP43xforPDFlib403 The BUG is fixed with it. Current version in latest distributive is 4.0.2 [2004-03-08 12:16:33] [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. This is a bug in the old libpdf libraries, upgrade your library to the latest stable libpdf library avaliable and the bug will go away. [2004-03-08 09:10:42] techtonik at tut dot by Description: pdf_open_image_file() crashes Apache while attempting to load TiFF file. Reproduce code: --- ?php $pdf = pdf_new(); pdf_open_file($pdf); pdf_begin_page($pdf, 200, 200); //this function crashes $pdfimage = pdf_open_image_file($pdf, tiff, test.tif); //pdf_place_image($pdf, $pdfimage, 10, 10, 0.6); //pdf_close_image($pdf, $pdfimage); //close it up pdf_end_page($pdf); pdf_close($pdf); $data = pdf_get_buffer($pdf); ? Actual result: -- Start of function trace 0.0021 0 - pdf_new() C:\MyFiles.XFiles\Numerald\test18.php:5 0.0025 0 - pdf_open_file(resource(2) of type (pdf object)) C:\wwwroot\test18.php:6 0.0029 0 - pdf_begin_page(resource(2) of type (pdf object), 200, 200) C:\wwwroot\Numerald\test18.php:11 0.0040 0 - pdf_open_image_file(resource(2) of type (pdf object), 'tiff', 'test.tif') C:\wwwroot\Numerald\test18.php:14 -- Edit this bug report at http://bugs.php.net/?id=27526edit=1
#27526 [Bgs]: Loading TiFF file crashes Apache 2.0.48
ID: 27526 User updated by: techtonik at tut dot by Reported By: techtonik at tut dot by Status: Bogus Bug Type: *PDF functions Operating System: Windows 2000 PHP Version: 4.3.5RC3 New Comment: Why don't you include latest 4.0.3 Pdflib in distributive? http://www.pdflib.com/support/faq.html#PHP43xforPDFlib403 The BUG is fixed with it. Current version in latest distributive is 4.0.2 Previous Comments: [2004-03-08 12:16:33] [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. This is a bug in the old libpdf libraries, upgrade your library to the latest stable libpdf library avaliable and the bug will go away. [2004-03-08 09:10:42] techtonik at tut dot by Description: pdf_open_image_file() crashes Apache while attempting to load TiFF file. Reproduce code: --- ?php $pdf = pdf_new(); pdf_open_file($pdf); pdf_begin_page($pdf, 200, 200); //this function crashes $pdfimage = pdf_open_image_file($pdf, tiff, test.tif); //pdf_place_image($pdf, $pdfimage, 10, 10, 0.6); //pdf_close_image($pdf, $pdfimage); //close it up pdf_end_page($pdf); pdf_close($pdf); $data = pdf_get_buffer($pdf); ? Actual result: -- Start of function trace 0.0021 0 - pdf_new() C:\MyFiles.XFiles\Numerald\test18.php:5 0.0025 0 - pdf_open_file(resource(2) of type (pdf object)) C:\wwwroot\test18.php:6 0.0029 0 - pdf_begin_page(resource(2) of type (pdf object), 200, 200) C:\wwwroot\Numerald\test18.php:11 0.0040 0 - pdf_open_image_file(resource(2) of type (pdf object), 'tiff', 'test.tif') C:\wwwroot\Numerald\test18.php:14 -- Edit this bug report at http://bugs.php.net/?id=27526edit=1
#27526 [NEW]: Loading TiFF file crashes Apache 2.0.48
From: techtonik at tut dot by Operating system: Windows 2000 PHP version: 4.3.5RC3 PHP Bug Type: *PDF functions Bug description: Loading TiFF file crashes Apache 2.0.48 Description: pdf_open_image_file() crashes Apache while attempting to load TiFF file. Reproduce code: --- ?php $pdf = pdf_new(); pdf_open_file($pdf); pdf_begin_page($pdf, 200, 200); //this function crashes $pdfimage = pdf_open_image_file($pdf, tiff, test.tif); //pdf_place_image($pdf, $pdfimage, 10, 10, 0.6); //pdf_close_image($pdf, $pdfimage); //close it up pdf_end_page($pdf); pdf_close($pdf); $data = pdf_get_buffer($pdf); ? Actual result: -- Start of function trace 0.0021 0 - pdf_new() C:\MyFiles.XFiles\Numerald\test18.php:5 0.0025 0 - pdf_open_file(resource(2) of type (pdf object)) C:\wwwroot\test18.php:6 0.0029 0 - pdf_begin_page(resource(2) of type (pdf object), 200, 200) C:\wwwroot\Numerald\test18.php:11 0.0040 0 - pdf_open_image_file(resource(2) of type (pdf object), 'tiff', 'test.tif') C:\wwwroot\Numerald\test18.php:14 -- Edit bug report at http://bugs.php.net/?id=27526edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27526r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27526r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27526r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27526r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27526r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27526r=needscript Try newer version: http://bugs.php.net/fix.php?id=27526r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27526r=support Expected behavior: http://bugs.php.net/fix.php?id=27526r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27526r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27526r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27526r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27526r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27526r=dst IIS Stability: http://bugs.php.net/fix.php?id=27526r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27526r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27526r=float
#26894 [Bgs]: Apache2 hangs when working with mail
ID: 26894 User updated by: techtonik at tut dot by Reported By: techtonik at tut dot by Status: Bogus Bug Type: IMAP related Operating System: NT 4.0 SP6a PHP Version: 4.3.5RC2 New Comment: Can you implement some custom timeout for connection with this c-client (i don't know that it is)? Is it ok, that this c-client makes temporary files into my root directory? Do you know any free IMAP servers for windows? Can you at least document this behavior? Previous Comments: [2004-02-09 21:55:43] [EMAIL PROTECTED] It's c-client that hangs, not anything in PHP. (Instead of using POP3, use IMAP as it works fine..there are some restrictions with deleting/expunging when you use POP3..) [2004-02-09 13:42:19] techtonik at tut dot by See Bug #23257 There is a sample script, which hangs just fine for me.. File msg2 created in the root C:\ Additionally I added xdebug trace: Start of function trace 1.1202 0 - imap_open() C:\Lotus\virlist_db\ema.php:9 6.7052 0 - imap_num_msg() C:\Lotus\virlist_db\ema.php:11 6.7719 0 - imap_fetchstructure() C:\Lotus\virlist_db\ema.php:15 6.9647 0 - imap_delete() C:\Lotus\virlist_db\ema.php:17 6.9737 0 - imap_expunge() C:\Lotus\virlist_db\ema.php:19 6.9804 0 - imap_fetchstructure() C:\Lotus\virlist_db\ema.php:21 [2004-01-16 10:25:27] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-01-16 09:36:16] techtonik at tut dot by I've tried this build. Problem persists - Apache hangs. Virtual memory allocation stops at approximately 6Mb. [2004-01-13 13:30:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Try the snapshot first. 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/26894 -- Edit this bug report at http://bugs.php.net/?id=26894edit=1
#26894 [NoF-Opn]: Apache2 hangs when working with mail
ID: 26894 User updated by: techtonik at tut dot by -Summary: Apache2 hangs when working with mail. Reported By: techtonik at tut dot by -Status: No Feedback +Status: Open Bug Type: IMAP related Operating System: NT 4.0 SP6a -PHP Version: 4CVS-2004-01-16 +PHP Version: 4.3.5RC2 New Comment: See Bug #23257 There is a sample script, which hangs just fine for me.. File msg2 created in the root C:\ Additionally I added xdebug trace: Start of function trace 1.1202 0 - imap_open() C:\Lotus\virlist_db\ema.php:9 6.7052 0 - imap_num_msg() C:\Lotus\virlist_db\ema.php:11 6.7719 0 - imap_fetchstructure() C:\Lotus\virlist_db\ema.php:15 6.9647 0 - imap_delete() C:\Lotus\virlist_db\ema.php:17 6.9737 0 - imap_expunge() C:\Lotus\virlist_db\ema.php:19 6.9804 0 - imap_fetchstructure() C:\Lotus\virlist_db\ema.php:21 Previous Comments: [2004-01-21 06:08:56] [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. [2004-01-16 10:25:27] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-01-16 09:36:16] techtonik at tut dot by I've tried this build. Problem persists - Apache hangs. Virtual memory allocation stops at approximately 6Mb. [2004-01-13 13:30:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Try the snapshot first. [2004-01-13 09:45:59] techtonik at tut dot by Description: I'm trying to parse a lot of msges in pop3 mailbox using IMAP functions. Unfortunately I can't find debug biuld for PHP 4.3.4 and I can't compile it myself, so I'll try to descript what is wrong in general. First of all Apache in hung state is endlessly munching file with name like msg77 or msg6 and so on, which it creates in the root! directory on my drive. Figured by Filemon. This file contains full email message, which I'm trying to send via mail() function. Message is random size. Now munching one with size about 1687 bytes. Apache works about hour and couldn't output anything even though I have timeout set to 180 seconds. So I can't even figure the line, where it hangs. My script reads all msgs from 1st till last by one. When msg fetched, an attach in tar.gz format is taked out of it, decompressed by gzinflate() and parsed by preg_match_all(). After that parsed letters remailed to another email. It all began with gzinflate() reporting buffer error and then data error after parsing some amount of msgs. These errors in turn appeared after I have added imap_delete() and imap_expunge() to erase successfully parsed messages. Now it just hangs and that is all. If I can fugure out which function makes Apache 2.0.48 hang I can do a more detailed report. -- Edit this bug report at http://bugs.php.net/?id=26894edit=1
#26894 [Fbk-Opn]: Apache2 hangs when working with mail.
ID: 26894 User updated by: techtonik at tut dot by Reported By: techtonik at tut dot by -Status: Feedback +Status: Open Bug Type: IMAP related Operating System: NT 4.0 SP6a PHP Version: 4.3.4 New Comment: I've tried this build. Problem persists - Apache hangs. Virtual memory allocation stops at approximately 6Mb. Previous Comments: [2004-01-13 13:30:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Try the snapshot first. [2004-01-13 09:45:59] techtonik at tut dot by Description: I'm trying to parse a lot of msges in pop3 mailbox using IMAP functions. Unfortunately I can't find debug biuld for PHP 4.3.4 and I can't compile it myself, so I'll try to descript what is wrong in general. First of all Apache in hung state is endlessly munching file with name like msg77 or msg6 and so on, which it creates in the root! directory on my drive. Figured by Filemon. This file contains full email message, which I'm trying to send via mail() function. Message is random size. Now munching one with size about 1687 bytes. Apache works about hour and couldn't output anything even though I have timeout set to 180 seconds. So I can't even figure the line, where it hangs. My script reads all msgs from 1st till last by one. When msg fetched, an attach in tar.gz format is taked out of it, decompressed by gzinflate() and parsed by preg_match_all(). After that parsed letters remailed to another email. It all began with gzinflate() reporting buffer error and then data error after parsing some amount of msgs. These errors in turn appeared after I have added imap_delete() and imap_expunge() to erase successfully parsed messages. Now it just hangs and that is all. If I can fugure out which function makes Apache 2.0.48 hang I can do a more detailed report. -- Edit this bug report at http://bugs.php.net/?id=26894edit=1
#26894 [NEW]: Apache2 hangs when working with mail.
From: techtonik at tut dot by Operating system: NT 4.0 SP6a PHP version: 4.3.4 PHP Bug Type: *Mail Related Bug description: Apache2 hangs when working with mail. Description: I'm trying to parse a lot of msges in pop3 mailbox using IMAP functions. Unfortunately I can't find debug biuld for PHP 4.3.4 and I can't compile it myself, so I'll try to descript what is wrong in general. First of all Apache in hung state is endlessly munching file with name like msg77 or msg6 and so on, which it creates in the root! directory on my drive. Figured by Filemon. This file contains full email message, which I'm trying to send via mail() function. Message is random size. Now munching one with size about 1687 bytes. Apache works about hour and couldn't output anything even though I have timeout set to 180 seconds. So I can't even figure the line, where it hangs. My script reads all msgs from 1st till last by one. When msg fetched, an attach in tar.gz format is taked out of it, decompressed by gzinflate() and parsed by preg_match_all(). After that parsed letters remailed to another email. It all began with gzinflate() reporting buffer error and then data error after parsing some amount of msgs. These errors in turn appeared after I have added imap_delete() and imap_expunge() to erase successfully parsed messages. Now it just hangs and that is all. If I can fugure out which function makes Apache 2.0.48 hang I can do a more detailed report. -- Edit bug report at http://bugs.php.net/?id=26894edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26894r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26894r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26894r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26894r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26894r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26894r=needscript Try newer version: http://bugs.php.net/fix.php?id=26894r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26894r=support Expected behavior: http://bugs.php.net/fix.php?id=26894r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26894r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26894r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26894r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26894r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26894r=dst IIS Stability: http://bugs.php.net/fix.php?id=26894r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26894r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26894r=float
