Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe:PHP 5)
At 05:28 02/01/2002, Manuel Lemos wrote: (b) If we do it, it'll go on leaking as it does today False, if you do it you will give one less reason for users to drop PHP. That sentence MEANS that though. Maybe you weren't sure of what you were saying, but saying We have to do X in order to prevent even more users from leaking means that even if we do X, users will go on leaking as they do now, and if we don't do X, they'll leak more. Again, I wasn't expecting you to answer me point by point on this and tell me if you think it's right or not. As I said - if it's the truth - we don't want to hear it - especially when people here don't think it's the truth. Think positive. You are still not getting it, I don't have a problem when people do not accept my ideais. My problem only happens when arises when people invent forced excuses for not accepting my ideas or at least to not put them in practice. What excuses did I make up? What excuses did I even mention? I said that the preachy way in which you presented your idea is not going to get you anywhere, let alone PHP. You may have encouraged someone to write a CORBA extension, and you definitely pissed off lots of other developers. Is that good? Did it get you or PHP anywhere better? I can assure you, by the way, that Andi didn't ask for out-of-the-blue ideas from people who don't have any idea on how to do them, and have no intention of doing anything about them themselves. How about a wiseguy that will suggest to improve the speed of PHP 10 times around? Great, we're all for it, but have a plan on how to do it, or be willing to work on a plan if it's accepted. It is like Richard Heyes said very well, while Andi asked for suggestions you promptly jumped in just to say it is pointless as if it was urgent to refuse my suggestion, or at least present an excuse for not implementing it. I did not refuse your suggestion or present any excuses. That's only in your preset mind. I said it's good, but I also said that you presented it in a very, VERY poor way, as you tend to often do. There's no conspiracy against you, I can assure you that, and if you cause many different people to object to the way that you present your ideas, you can assume that the problems lie in your hands, and not everybody else's. I hope you see this time is not just Manuel. Things could have worked much better if you have to refused the countless times that I bothered to lend a hand, even if it was just presenting ideas and no code. Too bad that you usually only wanted to get me wrong as if what I was suggesting was not going to work in your favour. Anyway, it is not soon, but may be is not too late... I never refused a single time you bothered to lend a hand - I don't recall a single time (other than this vague virtual marketing idea which I didn't consider too good). As far as I recall, you said that Rasmus refused your help in the past, and I think I was the one that actually pushed for you to get a CVS account. Not sure though, it was a long time ago. At any rate, with all the differences I have with Rasmus, and God know we have lots - if he refused to accept your help, you must have done something TERRIBLY wrong. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794 Updated: misleading warning with regard to 'allow_call_time_pass_reference'
ID: 14794 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: xml_set_object() should take object by-reference Status: Open Old Bug Type: XML related Bug Type: Feature/Change Request Operating System: Linux 2.4 / Apache 1.3 PHP Version: 4.1.1 New Comment: Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! Previous Comments: [2002-01-02 02:19:32] [EMAIL PROTECTED] I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. Edit this bug report at http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794 Updated: misleading warning with regard to 'allow_call_time_pass_reference'
ID: 14794 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: xml_set_object() should take object by-reference Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4 / Apache 1.3 PHP Version: 4.1.1 New Comment: Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! Previous Comments: [2002-01-02 03:28:52] [EMAIL PROTECTED] Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! [2002-01-02 02:19:32] [EMAIL PROTECTED] I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. Edit this bug report at http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14794 Updated: misleading warning with regard to 'allow_call_time_pass_reference'
ID: 14794 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Summary: xml_set_object() should take object by-reference Status: Open Bug Type: Feature/Change Request Operating System: Linux 2.4 / Apache 1.3 PHP Version: 4.1.1 New Comment: Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! Previous Comments: [2002-01-02 03:28:55] [EMAIL PROTECTED] Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! [2002-01-02 03:28:52] [EMAIL PROTECTED] Ok, I am really embarassed now, because xml_set_object() does take object by reference. The warning message is misleading though. It convinced me that the parameter was passed by value. But rather, it should say '.. - argument passed according to the function spec', which, in this case, is by-reference. Thanks! [2002-01-02 02:19:32] [EMAIL PROTECTED] I am getting the following warning after I switched to 'php.ini-recommended': Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of xml_set_object()... Apparently, xml_set_object() takes an object by value, which renders this functionality useless: The only way it's any good is when the object is passed by reference, so that the event-receiving object is the same instance that was passed as a parameter to xml_set_object() call. Otherwise, there is no way for a copied object to pass parsed data out to the caller of xml_set_object() (without global variables, of course). Please fix xml_set_object() to take an object by reference. Thanks. Edit this bug report at http://bugs.php.net/?id=14794edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] SOAP and CORBA
Hi, well yes I would like to see better CORBA support. We are in the process of getting a CORBA based software that we would write an interface for. Since we do not want to write it in anything but PHP we are sort of in a difficult situation. We went through the entire list of current implementations. Universe seems to be the most recent hope to make PHP+COPRBA a reality but David Erickson said he will be working on his degree next spring. Gavin Sherry also seemed interested in doing this. But I think he was also waiting for Zend2 and iirc thread safety. The problem is that the deal currently is in jeopardy so I decided to focus my companies efforts elsewhere (since otherwise I will have to face the risk of PHP not working as well as needed with CORBA AND getting the deal through in the first place .. the risks stack). All in all I sort of really like the idea of CORBA and PHP. But I am by no means a CORBA expert and we do not have this project on the top of our priority lists anymore. If the deal does com through I might be able to offer some funding (this is what I talked to Gavin about) but there are way too many If's and When's in my email to count on me for anything in terms of CORBA aside from cheering, the person that does step in to do it, forward. :( On the SOAP front: I think the best way for PHP to implement new stuff like that is to offer some low level stuff and let the users do the rest in PHP. I think this is the most convenient way to deal with rapidly evolving standards until they are settled in and people actually are interested in following the spec to the letter as in the early stages people often need to adapt standard to their established software. Later on people really start off projects with SOPA or whatever else as the core concept their software. This is more a general comment than anything really SOPA specific. Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -Original Message- From: Manuel Lemos [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 02, 2002 7:40 AM To: [EMAIL PROTECTED]; Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] SOAP and CORBA Hello, Andi Gutmans wrote: At 12:44 AM 1/2/2002 +, Nick Loman wrote: Hello PHP developers, Interesting to think about what might make a nice foundation technology for all the exciting potential of PHP5. SOAP is obviously an important technology for websites in the future. But given that (I guess) most of us are not really that keen to follow in the nervous footsteps of Microsoft, and given that XML brings me out in a horrible rash, why don't we think about CORBA as a fundamental PHP technology? CORBA is now finally in a state where people can actually use it without running away screaming. There are now enough free implementations on enough platforms to enable mainstream PHP support. David Eriksson has done some nice stuff with Universe/Satellite, but I don't think PHP's CORBA support is currentl plug n' go enough to really be capitalised on (it currently relies on a fair amount of knowledge of CORBA). What would be fantastic is a situation where newbie PHP coders feel confident enough to use CORBA services exposed to the Internet (not many exist at the moment, the classic example is Random.org but this could change). If it was easy enough to start interacting with ORBs exposed to the 'Net, and it was easy enough for PHP developers to write their own net-facing ORBs, we could potentially be facing an interesting paradigm shift whereby PHP users are exposing their interesting objects (which may, e.g. provide access to databases, content) to the 'net. Much sexier than say RDF, no? If anyone would like to help me in my quest to make CORBA more mainstream (CORBA isn't really scary, at its most basic its just cross-platform remote procedure calls) I would love to work with you. All the best for 2002 everyone, We are going to try to improve the object overloading in ZE2 so I suggest not working on this before we see what we can come up with. Basically we are just trying to make it easier for people to overload objects from C and make it a bit more powerful. In the meanwhile you can still play around with different Corba implementations and choose how you're going to do it but I suggest waiting because it'll hopefully save you lots of headaches. Yes, adding and maintaining static CORBA interfaces is an hell to deal with IDL compilers and stuff, but I think dynamic invocation fits well with the nature of PHP. You may want to talk with Lukas Smith and Gavin Sherry as I heard them talking about adding some kind of CORBA support to PHP. Regards, Manuel Lemos -- PHP
[PHP-DEV] Re: MSSQL DB Connect
Thanks Jeremy, I finally found the solution:
?php
$query=SELECT * FROM DB1 JOIN DB2 ON DB1.dataid=DB2.dataid;
$queryupd=UPDATE DB1 SET dateval='20010101' where dateval='2101';
$hostname = serverdb;
$username = user;
$password = pwd;
$dbName = DB;
mssql_connect($hostname,$username,$password) or die(DATABASE FAILED TO
RESPOND.);
mssql_select_db($dbName) or DIE(Table unavailable);
$result2 = MSSQL_QUERY($queryupd); // Execute Update Statment
$result = MSSQL_QUERY($query); // Execute Select Statment
$number = MSSQL_NUM_ROWS($result);
$i=0;
if($number == 0) print No data?;
elseif($number 0){
print Number of rows: $numberBR;
while($i $number){
$dateval= mssql_result($result,$i,dateval);
echo TRTDFONT color=#112266$dateval/FONT/TD;
$i++;}
}?
And it works fine !
Now I'm looking for the same function for IBM DB2 database connection...
Jerry
Jeremy Reed [EMAIL PROTECTED] wrote:
What was the error message you received? Also, when passing the variables
to the mssql_connect() function, you need not use quotes since you've
already initialized them to the strings. Pass them as follows:
$connection
= mssql_connect($a,$b,$c). Also, you aren't passing the actual sql string
to the mssql_query() function. You have $sql = blah but you pass
$sql_temp.
Jerry wrote:
Hi
I have PHP on windows 2000 web server
I would like to remote to a MS SQL database on another web server.
I tried something like:
?php
$h = server adr;
$u = user;
$p = passw;
$b = db;
$connexion = mssql_connect($h, $u, $p);
mssql_select_db($b);
$sql_temp= select * from test;
$result = mssql_query($sql_temp);
mssql_close($connexion);
?
But it didn't work. Please help me.
Jerry
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
Hi, having everything bundled is a strength for people who install from source, but it really doesn't do much to help people who haved installed from a distribution or are in a shared-hosting situation. those are the well, i dont agree with that. think about people that are not hosting themself.. its great to have all that stuff included in PHP, its easiert to tell your provider hey could you enable this feature instead of hey.. would you intall... just my 2 cents -- Peter [DiSAStA] Petermann -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14772 Updated: some links are missing (cosmetic error)
ID: 14772 Updated by: georg Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Documentation problem Operating System: n/a PHP Version: 4.1.1 New Comment: fixed in cvs Previous Comments: [2002-01-02 02:25:58] [EMAIL PROTECTED] REOPENED bug still exists in online manual (build date 2002-01-01) and ditto in my local cvs build. Georg [2001-12-30 10:46:53] [EMAIL PROTECTED] Fixed in cvs. Thnaks for the report. [2001-12-30 09:17:19] [EMAIL PROTECTED] This is a docu prob. [2001-12-30 08:50:32] [EMAIL PROTECTED] This is only a little thing. On the function page for socket_get_status, the references to related functions at the button are not hyperlinked. It's the line See also accept_connect(), bind(), connect(), listen(), and strerror(). Fix when you can. Thanks. - Dan Edit this bug report at http://bugs.php.net/?id=14772edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14781 Updated: ftp_login failure after mysql_connect
ID: 14781 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: FTP related Operating System: Linux Redhat 6.2/7.2 PHP Version: 4.1.1 New Comment: Well...ahm. Should have thought of that myself I guess...thanks a lot. And sorry to bother you with things I should solve on my own :-) Previous Comments: [2002-01-01 07:56:33] [EMAIL PROTECTED] Your code doesn't watch out for operator precedence: $foo = function1() || die(i'm dead now); will evalute to $foo = ( function1() || die(i'm dead now) ); which means $foo will be true (if function1 succeeded). For your code this means: $hFtp = ( ftp_connect (localhost) || die (Could not connect.\n) ). and therefore $hFtp will be boolean true and not your resource/connection id. Proper parenthesizing will solve this: ( $hFtp = ftp_connect (localhost) ) || die (Could not connect.\n); [2001-12-31 11:30:49] [EMAIL PROTECTED] I wanted to connect to a ftp server, get some files and insert them into a database. I started connecting to the ftp server, then logging in and that worked fine. Then I added a mysql_connect and now I get an error on ftp_login that says that it can not find ftpbuf. (tried on two systems: Linux Redhat 6.2, Linux Redhat 7.2). I'm not sure if this is a failure of ftp functions, mysql, a documentation problem or me being too stupid. After dropping all unneccessary code, the file looks like that: ?php $hHandle=mysql_connect(localhost, nobody, ) or die (no connection.\n); mysql_close ($hHandle); #this can be dropped $hFtp = ftp_connect (localhost) #this works || die (Could not connect.\n); # next line results in an error: $iLoginResult=ftp_login($hFtp, nobody, ) || die (Error: Unable to login\n); ? I got the following error message: Warning: Unable to find ftpbuf 1 in scipt on line XX, (which is the ftp_login line (ftp_connect works!)). If you drop mysql_connect, its working fine... I'm using build in mysql support (for version 3.23.39), ftp is of course enabled too. Hopefully this is a stupid question and there is an easy answer... Thanks in advance and a happy new year, flim Edit this bug report at http://bugs.php.net/?id=14781edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
On Tue, Jan 01, 2002 at 05:56:53PM -, Jim Winstead wrote: Andi Gutmans [EMAIL PROTECTED] wrote: The Zend Engine 2 has made lots of progress. is there an up-to-date summary of the changes beyond the original ze2 proposal? example scripts that show the new features? Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys implemented for PECL. I know that if it's not a really cool easy to use mechanism I would prefer to wait until we write one. One of the main strengths of PHP is that everything is bundled together and is easy to setup. We shouldn't make it much harder on people. Although we're planning on only move the unimportant extensions out of PHP I still think it should be extremely easy to get a list of available extensions (maybe even a part of the ./configure process) and to easily download/configure/install them. having everything bundled is a strength for people who install from source, but it really doesn't do much to help people who haved installed from a distribution or are in a shared-hosting situation. those are the places where something like perl's cpan really shines (and where the pear/pecl stuff presumably will too). I think a lot of people are installing from source, so it's very important that's easy to do so. Distributios are outdated and as long as you wan't just one new feature of the extensions you're bound to install from source anyway. i'd really love to see the existing pear/pecl stuff brought out into the open more, even if it is not fully baked. i think the fact that it is relatively hidden makes it extremely difficult for people to know where things are headed, how close (or far) they are, and how to help. The main benefit of the PECL is the independent release-cycle. It'll force less people to install PHP from source when they need stuff from a newly updated extension. (and 'unimportant' is a dangerous word. obviously that depends on the situation.) IMHO, all extensions should be PECL. If it's easier to have some extensions part of core PHP 'cause they're important, then it's a sign of bad PECL design. PHP should be the glue for SAPI, extensions (PECL, I hope) and Zend. No more. -- Adam jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Adam Dickmeiss mailto:[EMAIL PROTECTED] http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
On Wed, 2 Jan 2002, Adam Dickmeiss wrote: IMHO, all extensions should be PECL. If it's easier to have some extensions part of core PHP 'cause they're important, then it's a sign of bad PECL design. PHP should be the glue for SAPI, extensions (PECL, I hope) and Zend. No more. I do not agree with this. Important extensions should be part of the core, and remain that way. It's much easier to distribute (one download), and easier to install. (No more fetching of PECL extensions). Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14795: array_sum() modifies the specified array
From: [EMAIL PROTECTED] Operating system: Debian unstable PHP version: 4.1.0 PHP Bug Type: Arrays related Bug description: array_sum() modifies the specified array the documentation claims this behavior was changed after 4.0.6, but it appears to behave the same in 4.1.0. (and i don't see a commit to ext/standard/array.c that indicates any such change to array_sum.) $a = array(1, 2, foo); print_r($a); echo array_sum($a); print_r($a); results in: Array ( [0] = 1 [1] = 2 [2] = foo ) 3Array ( [0] = 1 [1] = 2 [2] = 0 ) -- Edit bug report at: http://bugs.php.net/?id=14795edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving extensions to PECL
On Tue, Jan 01, 2002 at 07:55:33PM +0100, Egon Schmid wrote: From: Martin Jansen [EMAIL PROTECTED] On Tue, 1 Jan 2002 18:36:57 +0100, Egon Schmid wrote: Well, I know librians will love the YAZ extension. I suggest to move the documentation in a new part in the PHP Manual. I think of a split of the original Function Reference in something like Basic Function Reference and Extended Function Reference. If yaz is going to become part of PECL (= part of PEAR), documentation should be placed in the PEAR manual. Everything else is less intuitive and will irritate people IMO. Are you sure that librians find the PEAR documentation? As I can see PEAR and PHP documentation differs in many things. I think Adam would be glad if he can maintain the YAZ functions as before. They probably won't find the PEAR documentation currently. I guess it wouldn't take that much to change the structure of the PHP web site a little, to make it more visible. -- Adam -Egon -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Adam Dickmeiss mailto:[EMAIL PROTECTED] http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
* [EMAIL PROTECTED] wrote: and remain that way. It's much easier to distribute (one download), and easier to install. (No more fetching of PECL extensions). Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with core extensions) and a release of php_4_3_4_complete.tgz packaged with all extensions together? -- Sichere PHP Applikationen / Notfall-Consulting mit der PHP Feuerwehr / Code inspection / Code rehearsal / API Checkup. mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
At 13:41 02/01/2002, Björn Schotte wrote: * [EMAIL PROTECTED] wrote: and remain that way. It's much easier to distribute (one download), and easier to install. (No more fetching of PECL extensions). Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with core extensions) and a release of php_4_3_4_complete.tgz packaged with all extensions together? That can happen, but what does that buy you? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14770 Updated: phps truncates long sources
ID: 14770 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Scripting Engine problem Operating System: Linux Mandrake 8.1 kernel 2.4.8 PHP Version: 4.1.0 New Comment: PHP 4.1.0 with Apache 1.3.22 truncates sources I have also PHP 4.0.6 with Apache Advanced Extranet Server 1.3.20 that does not have the bug ./congfigure --with-mysql --with-apache=../apache-1.3.22 --enable-track-vars long sources only are truncated short display correctly well for example 7141 bytes gets truncated while 3159 bytes does not do you have any standard way of replying a bug I couldn't find one Previous Comments: [2001-12-31 05:05:04] [EMAIL PROTECTED] I'm afraid to ask for an example of a 'long source', but could you provide some details about the size of the code, and what sort of results you're seeing? [2001-12-30 07:19:45] [EMAIL PROTECTED] PHP 4.1.0 with Apache 1.3.22 truncates sources I have also PHP 4.0.6 with Apache 1.3.20 that does not have the bug ./congfigure --with-mysql --with-apache=../apache-1.3.22 --enable-track-vars long sources only are truncated short display correctly Edit this bug report at http://bugs.php.net/?id=14770edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
* Zeev Suraski wrote: Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with core extensions) and a release of php_4_3_4_complete.tgz packaged with all extensions together? That can happen, but what does that buy you? I can err myself, but it's some sort of BC for me in the configuration/installation process. -- Sichere PHP Applikationen / Notfall-Consulting mit der PHP Feuerwehr / Code inspection / Code rehearsal / API Checkup. mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13154 Updated: ODBC query to Openingres 2.0 fail with scs_p_GetTblAttribs: DRV_DDTables failed
Hello Lobbin,
I didn't give any feedback just because I have no password to enter the system and
issue my opinions.
The problem is still there, I have a case opened in OpenLink SW for a long time for
this matter and have sent to them every log
they asked to try to help in solving the problem.
This problem seems to be with Openlink driver, or else with the form that PHP 4.x uses
it.
I'm sure its a compatibility problem between the two.
Happy new year,
André Felipe
Bug Database wrote:
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=13154edit=2
ID: 13154
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: ODBC related
Operating System: Solaris 8
PHP Version: 4.0.6
Assigned To: ahill
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-07 13:11:40] [EMAIL PROTECTED]
We've not had any problems with your configuration - are you getting an error
message?
Best regards,
Andrew Hill
[2001-12-07 12:25:32] [EMAIL PROTECTED]
Assigning this to Ahill as he knows the OpenLink software best.
[2001-09-05 14:57:19] [EMAIL PROTECTED]
No queries can be made with PHP 4 and Openlink ODBC to access OpenIngres.
Test program:
? echo Teste de ODBCP ;
$odbc = odbc_connect(Desenv , notes, notes, SQL_CUR_USE_IF_NEEDED );
echo ODBC_CONNECT return code: $odbc ;
$query = select matrica from srhtb002;
$queryprep = odbc_prepare ($odbc, $query); // This produces the error.
$result = odbc_execute($queryprep );
print ok. result = $result;
$nextrow = odbc_fetch_row($result, 1);
if (! $nextrow ) {
print Nco achou nada...br;
}
else {
print odbc_result($result , 1 );
print br;
print odbc_result($result , 2 );
}
?
The configure line is:
./configure --enable-track-vars --with-yp --with-apxs --with-oci8
--with-iodbc=/software/openlink/odbcsdk
--
André Felipe M. Carvalho
Analista de Sistemas - Embrapa / DTI
[EMAIL PROTECTED]
http://www.embrapa.br
---
Os internautas escolheram a Embrapa como Top Cadê.
Veja o resultado!
http://www.topcade.com.br/ciencia/votacienciaMar2001.shtm
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14796: error in calculating with minus
From: [EMAIL PROTECTED] Operating system: suse linux 7.1 PHP version: 4.1.0 PHP Bug Type: *General Issues Bug description: error in calculating with minus php allways returns after echo 166.3 - 166.6; -0.28 but the right result is -0.3 is there a fix for this problem? thanx -OLIMAC -- Edit bug report at: http://bugs.php.net/?id=14796edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13154 Updated: ODBC query to Openingres 2.0 fail with scs_p_GetTblAttribs: DRV_DDTables failed
ID: 13154
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ODBC related
Operating System: Solaris 8
PHP Version: 4.0.6
Old Assigned To: ahill
Assigned To:
New Comment:
Hello Lobbin,
I didn't give any feedback just because I have no password to enter the system and
issue my opinions.
The problem is still there, I have a case opened in OpenLink SW for a long time for
this matter and
have sent to them every log
they asked to try to help in solving the problem.
This problem seems to be with Openlink driver, or else with the form that PHP 4.x uses
it.
I'm sure its a compatibility problem between the two.
Happy new year,
André Felipe
Previous Comments:
[2001-12-28 06:10:42] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-07 13:11:40] [EMAIL PROTECTED]
We've not had any problems with your configuration - are you getting an error message?
Best regards,
Andrew Hill
[2001-12-07 12:25:32] [EMAIL PROTECTED]
Assigning this to Ahill as he knows the OpenLink software best.
[2001-09-05 14:57:19] [EMAIL PROTECTED]
No queries can be made with PHP 4 and Openlink ODBC to access OpenIngres.
Test program:
? echo Teste de ODBCP ;
$odbc = odbc_connect(Desenv , notes, notes, SQL_CUR_USE_IF_NEEDED );
echo ODBC_CONNECT return code: $odbc ;
$query = select matrica from srhtb002;
$queryprep = odbc_prepare ($odbc, $query); // This produces the error.
$result = odbc_execute($queryprep );
print ok. result = $result;
$nextrow = odbc_fetch_row($result, 1);
if (! $nextrow ) {
print Nco achou nada...br;
}
else {
print odbc_result($result , 1 );
print br;
print odbc_result($result , 2 );
}
?
The configure line is:
./configure --enable-track-vars --with-yp --with-apxs --with-oci8
--with-iodbc=/software/openlink/odbcsdk
Edit this bug report at http://bugs.php.net/?id=13154edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13154 Updated: ODBC query to Openingres 2.0 fail with scs_p_GetTblAttribs: DRV_DDTables failed
ID: 13154
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: ODBC related
Operating System: Solaris 8
PHP Version: 4.0.6
Old Assigned To: ahill
Assigned To:
Previous Comments:
[2001-12-28 06:10:42] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-07 13:11:40] [EMAIL PROTECTED]
We've not had any problems with your configuration - are you getting an error message?
Best regards,
Andrew Hill
[2001-12-07 12:25:32] [EMAIL PROTECTED]
Assigning this to Ahill as he knows the OpenLink software best.
[2001-09-05 14:57:19] [EMAIL PROTECTED]
No queries can be made with PHP 4 and Openlink ODBC to access OpenIngres.
Test program:
? echo Teste de ODBCP ;
$odbc = odbc_connect(Desenv , notes, notes, SQL_CUR_USE_IF_NEEDED );
echo ODBC_CONNECT return code: $odbc ;
$query = select matrica from srhtb002;
$queryprep = odbc_prepare ($odbc, $query); // This produces the error.
$result = odbc_execute($queryprep );
print ok. result = $result;
$nextrow = odbc_fetch_row($result, 1);
if (! $nextrow ) {
print Nco achou nada...br;
}
else {
print odbc_result($result , 1 );
print br;
print odbc_result($result , 2 );
}
?
The configure line is:
./configure --enable-track-vars --with-yp --with-apxs --with-oci8
--with-iodbc=/software/openlink/odbcsdk
Edit this bug report at http://bugs.php.net/?id=13154edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14796 Updated: error in calculating with minus
ID: 14796 Updated by: bate Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *General Issues Operating System: suse linux 7.1 PHP Version: 4.1.0 New Comment: Its tested with 4.1.1 I tested with 128.1 - 128.0 I think this error just occours if the result 1.0 and the numbers =128.0. Previous Comments: [2002-01-02 07:20:10] [EMAIL PROTECTED] php allways returns after echo 166.3 - 166.6; -0.28 but the right result is -0.3 is there a fix for this problem? thanx -OLIMAC Edit this bug report at http://bugs.php.net/?id=14796edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14796 Updated: error in calculating with minus
ID: 14796 Updated by: jimw Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: suse linux 7.1 PHP Version: 4.1.0 New Comment: floating point numbers are not exact. see http://www.php.net/manual/en/language.types.float.php Previous Comments: [2002-01-02 07:30:29] [EMAIL PROTECTED] Its tested with 4.1.1 I tested with 128.1 - 128.0 I think this error just occours if the result 1.0 and the numbers =128.0. [2002-01-02 07:20:10] [EMAIL PROTECTED] php allways returns after echo 166.3 - 166.6; -0.28 but the right result is -0.3 is there a fix for this problem? thanx -OLIMAC Edit this bug report at http://bugs.php.net/?id=14796edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe: PHP 5)
ext/xmlrpc in PHP 4.2.0dev already supports SOAP 1.1. It is still in experimental status, but, this is good start point to add native SOAP support for PHP. I think the light weight and fast SOAP implementation is prefereable because SOAP is really basic layer/infrastrucure for Web Services. -- - Rui Hirokawa [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14797: include (_path) in Apache SAPI and CGI on Win98SE does not work
From: [EMAIL PROTECTED] Operating system: Windows 98 SE PHP version: 4.1.0 PHP Bug Type: Reproducible crash Bug description: include (_path) in Apache SAPI and CGI on Win98SE does not work Hello, I can't run PHP Version 4.1.0 under Windows 95/98 4.10, there are massive problems when I try to include a file: Server API CGI -- - It's possible to set the include-path in php.ini. - Scripts without any include statement work well. - include statements with a relative path work. - include statements with an absolute path do not work, there is the following error: Failed opening '/foo/test.php' for inclusion Server API Apache - - It is not possible to set the include-path in php.ini to an other value than . If I do, there will be everytime the same error: Failed opening 'foo/index.php' for inclusion (include_path='.;/foo') in Unknown on line 0 - If I set the include-path in php.ini to and in a script with ini_set(include_path, $new_inc_path) to the desired path, then php shows the same behaviour like Server API CGI - only relative paths work. I think this could be the bug #11612 or #14563, bit I don't use Win2k, I'm using Win 98 SE. Martin -- Edit bug report at: http://bugs.php.net/?id=14797edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14798: session.gc_maxlifetime does not work (Reopen Bug ID #3793)
From: [EMAIL PROTECTED] Operating system: Win 2k PHP version: 4.1.0 PHP Bug Type: Session related Bug description: session.gc_maxlifetime does not work (Reopen Bug ID #3793) Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440 1440s = 24min. hmm 24min ?? Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time AND 24 relates more to 24h! So is it realy *seconds* ?! --- The Bug: As reported in Bug ID #3793 (from [EMAIL PROTECTED]) following still happens (taken from [EMAIL PROTECTED], 2000-12-07 and veryfied by [EMAIL PROTECTED], 2001-11-25): 1) session.gc_maxlifetime does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script) 2) When I set session.gc_probability = 100 in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). . My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set session.gc_probability = 50 but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. [EMAIL PROTECTED] wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': Some Unix filesystems can be mounted with atime updates disabled to increase the performance. [Session] session.gc_probability = 100 session.gc_maxlifetime = 60 session.save_handler = files session.save_path = c:\tmp\ session.use_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.referer_check = session.entropy_length = 0 session.entropy_file = ;session.entropy_length = 16 ;session.entropy_file = /dev/urandom session.cache_limiter = nocache session.cache_expire = 180 session.use_trans_sid = 1 -- Edit bug report at: http://bugs.php.net/?id=14798edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
I know that PHP is mainly used for developing web-based applications, but I think that it has a great potential as a general purpose scripting language. Even when developing web applications I often find necessary to make command line scripts for maintenance and batch operations. One of our goals should be the presence of /usr/bin/php on as many systems as possible. We already have decent support for command line scripts in form of ext/ncurses, ext/pcntl and similar, but there are still some pieces that could be improved. The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. There were some suggestions on this list to create a new sapi (CLI), which would be a simplified version of cgi sapi, but which would print no headers by default, etc. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14797 Updated: include (_path) in Apache SAPI and CGI on Win98SE does not work
ID: 14797 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Windows 98 SE PHP Version: 4.1.0 New Comment: With PHP Version 4.0.5RC1 an inlude-path set to ;.;./; it works with SAPI, but with 4.0.6 and newer it's the same like 4.1.0 Martin Previous Comments: [2002-01-02 08:30:47] [EMAIL PROTECTED] Hello, I can't run PHP Version 4.1.0 under Windows 95/98 4.10, there are massive problems when I try to include a file: Server API CGI -- - It's possible to set the include-path in php.ini. - Scripts without any include statement work well. - include statements with a relative path work. - include statements with an absolute path do not work, there is the following error: Failed opening '/foo/test.php' for inclusion Server API Apache - - It is not possible to set the include-path in php.ini to an other value than . If I do, there will be everytime the same error: Failed opening 'foo/index.php' for inclusion (include_path='.;/foo') in Unknown on line 0 - If I set the include-path in php.ini to and in a script with ini_set(include_path, $new_inc_path) to the desired path, then php shows the same behaviour like Server API CGI - only relative paths work. I think this could be the bug #11612 or #14563, bit I don't use Win2k, I'm using Win 98 SE. Martin Edit this bug report at http://bugs.php.net/?id=14797edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
At 14:01 02/01/2002, Björn Schotte wrote: * Zeev Suraski wrote: Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with core extensions) and a release of php_4_3_4_complete.tgz packaged with all extensions together? That can happen, but what does that buy you? I can err myself, but it's some sort of BC for me in the configuration/installation process. Well, I think that the main motivation for separating the modules away was the release schedule. I.e., separating the release schedule of each extension from the release schedule of the PHP core itself. If we still have a full version and a bare-bones version side by side, I'm not sure how much that buys you, in comparison with what we have today... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
* Zeev Suraski wrote: Well, I think that the main motivation for separating the modules away was the release schedule. I.e., separating the release schedule of each extension from the release schedule of the PHP core itself. Jep. Just to note: I'm +1 for it. If we still have a full version and a bare-bones version side by side, I'm not sure how much that buys you, in comparison with what we have today... It buys me nothing because I would prefer the PECL way. I just wanted to say that it could be useful for Sysadmins who don't want to download each PECL extension with the PEAR/PECL-installer. (like ApacheToolbox) -- Sichere PHP Applikationen / Notfall-Consulting mit der PHP Feuerwehr / Code inspection / Code rehearsal / API Checkup. mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
At 16:06 02/01/2002, Björn Schotte wrote: * Zeev Suraski wrote: Well, I think that the main motivation for separating the modules away was the release schedule. I.e., separating the release schedule of each extension from the release schedule of the PHP core itself. Jep. Just to note: I'm +1 for it. I'm +1 for separating the less popular ones, but I'm -1 for separating everything (look up the archives as to why...) If we still have a full version and a bare-bones version side by side, I'm not sure how much that buys you, in comparison with what we have today... It buys me nothing because I would prefer the PECL way. I wasn't talking about you personally, but the PHP project in general :) If we still have to tie up releases to a stable snapshot of all of the extensions, then it won't help the release schedule too much. It may make it easier I just wanted to say that it could be useful for Sysadmins who don't want to download each PECL extension with the PEAR/PECL-installer. (like ApacheToolbox) It'll probably be easier for most people who don't really care too much about the version of each individual extension (which, from my experience anyway, accounts for most of the users). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14799: Remove the To:/Subject: headers if not entered
From: [EMAIL PROTECTED] Operating system: RH 7.x PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: Remove the To:/Subject: headers if not entered mail command accept: mail ($recipient, $subject, $message [, string additional_headers]); all good. But when I construct all the mail from headers I don't need to supply: $recipient, $subject, $message as they all exist in the headers. So I do: mail (, , , $headers); The problem is that even when I write the To: header in the headers another empty To: appear next to it. So for maximal flexibility I think that $headers suppose to override all other fields. -- Edit bug report at: http://bugs.php.net/?id=14799edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14799 Updated: Remove the To:/Subject: headers if not entered
ID: 14799 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Old Bug Type: Unknown/Other Function Bug Type: Mail related Operating System: RH 7.x PHP Version: 4.0.6 New Comment: oops, forgot to mention the bug type. sorry Previous Comments: [2002-01-02 09:20:09] [EMAIL PROTECTED] mail command accept: mail ($recipient, $subject, $message [, string additional_headers]); all good. But when I construct all the mail from headers I don't need to supply: $recipient, $subject, $message as they all exist in the headers. So I do: mail (, , , $headers); The problem is that even when I write the To: header in the headers another empty To: appear next to it. So for maximal flexibility I think that $headers suppose to override all other fields. Edit this bug report at http://bugs.php.net/?id=14799edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14095 Updated: fopen/fwrite does not create file via ftp://
ID: 14095 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: FTP related Operating System: Windows NT4 SP6a PHP Version: 4.0.6 New Comment: No Feedback, closing. Previous Comments: [2001-11-17 17:52:49] [EMAIL PROTECTED] Unfortunately I do not have authority over that server. But I will try to either set up a test box (don't have NT4 available right now) or convince the admin to upgrade - so is there a known issue? [2001-11-17 17:32:32] [EMAIL PROTECTED] Can you please test with a more recent version (e.g. from php4win.de) ? [2001-11-17 17:16:35] [EMAIL PROTECTED] PHP as CGI on NT4SP6a/IIS4. To update a file on the server, I read the old contents into an array, populate a string with modified content, delete the old file, and use fopen/fwrite to write a new one. This worked great on FreeBSD/Apache, now on NT4/IIS4 the new file is not written. There are *no* error messages, but the file is not there. Really messed up is the fact that the file is written successfully when I specify the previous FreeBSD/Apache host in $FTPSite... The following variables are defined before the code below runs: $newcontents $FTPUser $FTPPass (contains special characters, e.g. urb@n) $FTPSite (host.domain.tl) $FTPDoc (/path/filename) [Curiously, I cannot use localhost or an IP address as $FTPSite...(unable to find ftpbuf 0 on ftp_login and ftp_delete as well as php_hostconnect: connect failed on fopen)] // delete previous file via ftp $ftp = ftp_connect($FTPSite); ftp_login($ftp, $FTPUser, $FTPPass); ftp_delete($ftp, $FTPDoc); ftp_quit($ftp); // get file handler $FTPOpen=ftp://; . rawurlencode($FTPUser) . : . rawurlencode($FTPPass) . @ . $FTPSite . $FTPDoc; //echo $FTPOpen . BR; $NewTopTen = fopen($FTPOpen,w); echo $NewTopTen; // write new content to file fwrite($NewTopTen, $newcontents); //close file handle fclose($NewTopTen); Edit this bug report at http://bugs.php.net/?id=14095edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14052 Updated: ftp_rawlist: Hangs up
ID: 14052 Updated by: mfischer Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: FTP related Operating System: Win2K PHP Version: 4.0.6 New Comment: Is this bug still present to you, also with 4.1.0? If so, can you verify that the 'hang' time is about 90 seconds (its a fixed coded timeout value in ext/ftp)? Previous Comments: [2001-11-14 09:48:04] [EMAIL PROTECTED] I think there is really a problem with repeated ftp_rawlist (Reported in #7897). I write a script which make several ftp_rawlists to indexing all the content. In most case, the task hangs up for 1 or 2 minutes. Then the program will continue, but it can be that it hangs up again. When I start the script directly (cmd-line), it will run well. But when I start it trough the task scheduler or the web server, it hangs up always. I can't explain the problem more, because this is all - Repeated ftp_rawlist, script is running under user system. Edit this bug report at http://bugs.php.net/?id=14052edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14800: Oracle connection probleme.
From: [EMAIL PROTECTED] Operating system: windows2000 advance server PHP version: 4.0.6 PHP Bug Type: OCI8 related Bug description: Oracle connection probleme. When i would like to connect with Oracle 8i data base i receive this message. Warning: OCISessionBegin: ORA-03113: end-of-file on communication channel in e:\easyphp\www\exemplephp\oci_affiche.php on line 17 regards. -- Edit bug report at: http://bugs.php.net/?id=14800edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14801: my_getwd.c fails to compile with error No way to get current directory
From: [EMAIL PROTECTED] Operating system: Solaris 8 Intel PHP version: 4.1.1 PHP Bug Type: MySQL related Bug description: my_getwd.c fails to compile with error No way to get current directory ./configure --with-mysql --with-apxs --with-db3=/usr/local/BerkeleyDB.3.3 --with-imap=../imap-2001a --with-mm --with-ldap --with-zlib --with-openssl --with-imap-ssl getwd() and getcwd() are both available in Solaris, but it looks like configure is not correctly defining HAVE_GETWD and HAVE_GETCWD, so my_getwd.c fails to compile. I manually added the following line to ext/mysql/libmysql/mysys_priv.h to get it to compile and work: #define HAVE_GETWD -- Edit bug report at: http://bugs.php.net/?id=14801edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14303 Updated: httpd threads hang with large data structures
ID: 14303
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Reproducible crash
Operating System: Redhat 7.2
PHP Version: 4.0.6
New Comment:
Good day,
Sorry for the lack of reply.
The function you had requested that I try, apache_child_terminate, is not enabled.
Looking at the source, it appears that this was toggled at compile time.
Regardless of the usefulness of this function, I don't feel that the ticket should be
closed until the problem itself is actually dealt with, instead of using this very
patch-y workaround.
Previous Comments:
[2001-12-23 04:52:30] [EMAIL PROTECTED]
No feedback. Closing.
[2001-12-02 00:03:06] [EMAIL PROTECTED]
There is a not-yet-documented function called
apache_child_terminate that should help you.
Call the function at the end of your script so that Apache
knows to terminate the process running the script (and
clean up its memory)
There was a recent thread on the PHP Dev mailing list
related to this issue. If you are curious, check the list
archives (or news group) for more information. The first
message in the thread was started by Edin Kadribasic on
Fri, 23 Nov 2001. You can also search for
ap_child_terminate and apache_child_terminate.
Visit http://www.php.net/support.php for information on
where to find the archive and news group.
Also, please do write back to let us know if the function
helped your problem.
[2001-11-30 13:39:07] [EMAIL PROTECTED]
I've had a lot of problems recently with PHP cleaning up properly after using large
data structures.
A sample script is included:
$huge_array = array();
for ( $i=0 ; $i= 8000 ; $i++ ) {
foreach (array(cn , uid , sn , givenName , attr1 , attr2 , attr3) as
$j ) {
for ( $k=0 ; $k= 50 ; $k++ ) {
$huge_array[$i][$j][$k] = rand(0,1).value;
}
}
}
The script executes normally, but the httpd thread remains afterwards, consuming
memory and CPU. It appears to need a kill -9 to make it finally die. If enough of
these are run, all of the child processes of apache get tied up, preventing it from
serving any more requests. At this point the threads have to be killed and the server
restarted.
I've also encountered similar problems with storing the results of a large
ldap_get_entries(), although the behavior of the above script suggests that the
problem is not actually with the LDAP function. Reducing the size of the query
incrementally reveals that there seems to be a breaking point where this behavior
begins.
httpd also logs that it has problems terminating its child processes:
[warn] child process 9541 still did not exit, sending a SIGTERM
I'm running php-4.0.6-7 under apache-1.3.20-16, all Redhat 7.2 RPMs, with the default
configuration.
Edit this bug report at http://bugs.php.net/?id=14303edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14802: --with-oci8 doesnt grok 64-bit Oracle 9i
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.1 PHP Bug Type: Compile Failure Bug description: --with-oci8 doesnt grok 64-bit Oracle 9i less debug.log CONFIGURE: './configure' '--with-fastcgi' '--without-mysql' '--with-oci8=/home/oracle/OraHome1' '- -enable-mbstr-enc-trans' CC: cc CFLAGS: -g CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS CXX: CXXFLAGS: INCLUDES: -I/usr/local/include -I$(top_builddir)/Zend -I/home/oracle/OraHome1/rdbms/public -I/h ome/oracle/OraHome1/rdbms/demo -I/home/oracle/OraHome1/plsql/public LDFLAGS: -R/usr/ucblib -L/usr/ucblib -R/home/oracle/OraHome1/lib -L/home/oracle/OraHome1/lib LIBS: -ldl -lgen -lsocket -lnsl -lcrypt -lresolv -lresolv -lresolv -lm -ldl -lnsl -lsocket -l socket -lcrypt -lclntsh DLIBS: SAPI: fastcgi PHP_RPATHS: /usr/ucblib /home/oracle/OraHome1/lib uname -a: SunOS double-eric 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-2 cc -o conftest -g -D_POSIX_PTHREAD_SEMANTICS -R/usr/ucblib -L/usr/ucblib -R/home/oracle/OraHome1/l ib -L/home/oracle/OraHome1/lib conftest.c -ldl -lgen -lsocket -lnsl -lcrypt -lresolv -lresolv -lreso lv -lm -ldl -lnsl -lsocket -lsocket -lcrypt -lclntsh 15 ld: fatal: file /home/oracle/OraHome1/lib/libclntsh.so: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to conftest --- the 32bit libraries are in $ORACLE_HOME/lib32 however, looking at the configure file, I am unable to figure out what in the oci8 detection system needs to be changed as all the paths are coded as ???/lib -- Edit bug report at: http://bugs.php.net/?id=14802edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14799 Updated: Remove the To:/Subject: headers if not entered
ID: 14799 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Mail related Operating System: RH 7.x PHP Version: 4.0.6 New Comment: I also noticed and maybe im wrong that the mail function replace the Return-path: header that i inserted with Return-path:[EMAIL PROTECTED] if so this should be fixed too Previous Comments: [2002-01-02 09:21:44] [EMAIL PROTECTED] oops, forgot to mention the bug type. sorry [2002-01-02 09:20:09] [EMAIL PROTECTED] mail command accept: mail ($recipient, $subject, $message [, string additional_headers]); all good. But when I construct all the mail from headers I don't need to supply: $recipient, $subject, $message as they all exist in the headers. So I do: mail (, , , $headers); The problem is that even when I write the To: header in the headers another empty To: appear next to it. So for maximal flexibility I think that $headers suppose to override all other fields. Edit this bug report at http://bugs.php.net/?id=14799edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP 5
On Wed, 2 Jan 2002, Zeev Suraski wrote: At 16:06 02/01/2002, Björn Schotte wrote: * Zeev Suraski wrote: Well, I think that the main motivation for separating the modules away was the release schedule. I.e., separating the release schedule of each extension from the release schedule of the PHP core itself. Jep. Just to note: I'm +1 for it. I'm +1 for separating the less popular ones, but I'm -1 for separating everything (look up the archives as to why...) Why not separate everything and then bundle the more popular ones to the normal PHP distribution on the time of a release ? I would love to be able to upgrade just the 'GD' extension if there was a bug on the extension on release PHP4.1.12 and it was fixed on PECL version of the extension 2.1.23. I would also love to be able to tell the users of my application to just use the PEAR installer to download and install the bugfix release of the GD extension instead of telling them to not use a particular buggy / not compatible version of PHP. I can understand that it will mean more work to you guys to handle several release independent extensions, but if you can just use the PEAR installer to download the stuff from the repository, you will be able to download the stable releases from PEAR and then build the general PHP distribution. Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14782 Updated: key_exists renamed to array_key_exists
ID: 14782 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.1.1 Old Assigned To: zak Assigned To: New Comment: I understand the issue or having functions disappear and then reappear.. We are a application service provider. We provide a content management system and application framework written in PHP to our customer's who host their sites on our colocated server at Rackspace. Just about every customer is running different version of our application. To migrate from one version to another is not just a file copy. It involves data base migration and changes and also application config changes. All our sites on our server are using PHP 4.0.6. To load PHP 4.1.1 means I have to bring all my sites down, load php 4.1.1, migrate the data, update each customer's config for the new app and then test each site. This is a huge undertaking. The way we normally handle application upgrades is to upgrade the customer's site the next time that their site comes in for maintenance work. I can understand that changing a function in a single site's scripts is not much of an issue, but please consider what this means to an ISP/ASP that is running many, possibly hundreds of sites. How an ISP will break many sites by loading PHP 4.1.1. Our latest version of our app uses the key_exists() function. The funciton is what was needed for the problem at hand. I had no idea that a PHP function could suddenly become an invalid function in the next release of the language. I can understand how an API can be retired. It out lived it's purpose or was buggy, but not function name. I understand the naming consistancy problem that key_exists had, but architecturly how does it hurt the PHP to keep an alias for it? You could keep the alias and then put a warning on the www.php.net/key_exists page saying that the array_key_exists function should be used instead and that the key_exists function. Does an alias affect performance or the memory foot print of PHP? Is it just a pointer to the correct function? Please understand that I am arguing this point to protect PHP and my company's investment. My company has based it's current and future success on the reliability, consistancy, performance, and power of PHP. Please make these kind of decisions more cautiously with larger more complex PHP applications and ISP/ASPs in mind. Thank you for your response and concern on these issues. Mike Boulet Newfangled Web Factory www.newfangled.com Previous Comments: [2001-12-31 16:59:41] [EMAIL PROTECTED] As Someone Who Shall Not Be Named Because They Are Also On Vacation has pointed out to me off list, it would be a bad thing to have functions disappearing and reappearing between versions. The function shall stay as is - please adjust your scripts accordingly. Thank you. [2001-12-31 16:37:26] [EMAIL PROTECTED] Assigning to myself [2001-12-31 16:21:14] [EMAIL PROTECTED] Hi Mike, Unless one of the developers objects, I will add the alias - however, if the change is made, it would not show up 'til the next release. I would recommend that you modify your files anyway. It is a small amount of work using gawk or vim. :) Alternately, you can modify your local copy of PHP until next release. Add the following line to ext/standard/basic_functions.c: PHP_FALIAS(key_exists, array_key_exists, NULL) The line should go after the line that looks like: PHP_FE(array_key_exists,NULL) Once you have made the change and saved, recompile PHP. [2001-12-31 15:33:39] [EMAIL PROTECTED] I have a very large PHP application running on my Linux web server that uses the 4.0.6 function key_exists. The problem is that I have 30 copies of this application running on the server. If I upgrade my server to php 4.1.1, I will be forced to upgrade all 30 sites with a new version of my application where array_key_exists is used instead. This is a HUGE undertaking. Is there any way to put the key_exists alias back in so that PHP compatiblity is not broken? Thank you Edit this bug report at http://bugs.php.net/?id=14782edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14755 Updated: 105.05$ becomes 105.5$ !!! - I found the fix.
ID: 14755
Updated by: sander
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: InterBase related
Operating System: ALL
PHP Version: 4.1.1
New Comment:
This is a fix for 12383. Can somebody look into it and apply the fix?
Previous Comments:
[2001-12-29 13:22:59] [EMAIL PROTECTED]
Hello. I found a nasty bug in interbase extension, and I
have the solution here. You have only to put it in the
source code; I would but I don't know how to do this. I
already posted the authors, but with no result.
104.05$ become 104.5$ !!!
When traslating scaled numeric fields (i.e. with
decimals), the routine _php_ibase_var_pval is faulty;
here is the original code:
#ifdef SQL_INT64
case SQL_INT64:
val-type = IS_STRING;
val-value.str.len = sprintf(string_data, %Ld.%Ld,
(ISC_INT64) (*((ISC_INT64 *)data) /
(int) pow(10.0, (double) -scale)),
(ISC_INT64) abs((int) (*((ISC_INT64 *)data) %
(int) pow(10.0, (double) -scale;
val-value.str.val = estrdup(string_data);
break;
#endif
You can clearly see that this code is fine if the decimal
part has no 0s before the first non 0 cipher. Here is
my correction:
#ifdef SQL_INT64
case SQL_INT64:
val-type = IS_STRING;
/* Experimental section by Giancarlo Niccolai */
if (scale) {
int i, len;
char dt[20];
double number = (double) ((ISC_INT64)
(*((ISC_INT64 *)data)));
for (i = 0; i -scale; i++)
number /= 10;
sprintf(dt, %%0.%df, -scale);
val-value.str.len = sprintf (string_data, dt ,
number);
}
else {
val-value.str.len = sprintf (string_data, %Ld,
(ISC_INT64) (*((ISC_INT64 *)data)));
}
/* End of experimental section */
val-value.str.val = estrdup(string_data);
break;
#endif
Please, since Interbase is used for e-commerce, all the
php-interbase applications can be at risk, if the site
deals with cents...
Edit this bug report at http://bugs.php.net/?id=14755edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14452 Updated: libphp4.so is not linking with *.la files
ID: 14452 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Linux Old PHP Version: 4.1.0 PHP Version: 4.1.0, 4.1.1 New Comment: I have sucessfully linked PHP4.1.1 to static libtool libraries with the following method: 1. ./configure in the 4.0.6 source directory 2. ./configure in the 4.1.1 source directory 3. copy the libtool from 4.0.6 to the 4.1.1 direcory 4. make 5. make install Obviously this is a little messy, but it does seem to work sucessfully. Regards, Glen Previous Comments: [2001-12-14 04:14:09] [EMAIL PROTECTED] MySQL was installed from RPM's a while ago: MySQL-3.22.21-2C1 MySQL-client-3.22.21-2C1 MySQL-devel-3.22.21-2C1 The system is a Cobalt Qube 2: Linux qube.dessol 2.0.34C51_SK #1 Mon Nov 29 07:59:59 CET 1999 mips unknown By the way, I also tried linking with libmcal.a which is installed in /usr/local/mcal/lib/. I used the configuration option --with-mcal=/usr/local/mcal and configuration/compiling/installing went fine. However, when restarting Apache, I get: Cannot load /usr/lib/apache/libphp4.so into server: /usr/ lib/apache/libphp4.so: undefined symbol: mcal_close I don't know what's going on here, but it seems the *.a files are not being linked to correctly? There was no such problems with the 4.0.6 release which I compilied with MySQL and MCAL support with no problems. Thanks. [2001-12-13 23:55:23] [EMAIL PROTECTED] How exactly did you configure/compile/install Mysql ? And what linux distribution is this ? --Jani [2001-12-13 06:18:31] [EMAIL PROTECTED] I deleted the libmysqlclient.la file from /usr/lib/mysql and tried re-compiling, but still got the same error. [2001-12-12 12:45:29] [EMAIL PROTECTED] I guess you're getting the libtool bug I noticed myself too. Try deleting the .la file. --Jani [2001-12-12 07:47:06] [EMAIL PROTECTED] I have configured PHP with the following options: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr /usr/lib/mysql contains libmyclient.a and libmyclient.sa. Configuration and make goes fine, though I get the following warning: *** Warning: This library needs some functionality provided by /usr/lib/mysql/libmysqlclient.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. Install goes fine, but when I restart Apache ( 1.3.3 ), I get the following error: Cannot load /usr/lib/apache/libphp4.so into server: /usr/ lib/apache/libphp4.so: undefined symbol: mysql_free_result PHP 4.0.6 compiled from source and ran with no such problems. Edit this bug report at http://bugs.php.net/?id=14452edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14767 Updated: Bug unsetting vars using $_SESSION
ID: 14767
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Session related
Operating System: Linux 2.4
PHP Version: 4.1.1
New Comment:
session_unregister('test') should work. Alternatively, you can use
unset($_SESSION['test']);
Previous Comments:
[2001-12-30 06:58:28] [EMAIL PROTECTED]
In a project I work on I ran into something I would say
is a bug..
When I call the page with ?debug=3 the session var 'test'
gets the value howdy and gets stored (no need to call
session_register('test'); (odd?)). After this there seem
to be no way of unsetting/removing this session var..
At least non of the methods below works. Bug?
unset in #2 (see below) removes the var, so it doesn't
show up in the var_dump (#6), but upon calling the page again with ?debug=2 (only show
sess-vars), it shows up
again.
At the same: $_GETand $_SERVER is displayed in phpinfo, but not $_SESSION. Another
bug?
In php.ini:
register_globals = On
Script:
// #1
if ($debug==3)
$_SESSION['test'] = howdy;
// #2
if ($debug==4)
unset($_SESSION['test']);
// #3
if ($debug==5)
unset($test);
// #4
if ($debug==6)
session_unregister($test);
// #5
if ($debug==7)
session_unregister($_SESSION['test']);
// #6
if ($debug1)
var_dump($_SESSION);
Edit this bug report at http://bugs.php.net/?id=14767edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14793 Updated: Setlocale not working for Japanese
ID: 14793
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Strings related
Operating System: Redhat Linux 7.1 J edition
PHP Version: 4.0.6
New Comment:
Did you compile with multibyte character support? I don't know if that's necessary but
it can't hurt. Also, try the latest version (4.1.0).
Previous Comments:
[2002-01-01 23:51:36] [EMAIL PROTECTED]
When I set setlocale (LC_ALL, ja_JP) and then call the function print (strftime
(%A.\n)), japanese format dates do not appear. I do get the Y character with monies
though.
When I run the code below, I do not get compete info for the Japanese locale.
setlocale(LC_ALL, en_US);
$locale_info = localeconv();
echo PRE\n;
echo \n;
echo Monetary information for current locale: \n;
echo \n\n;
echo int_curr_symbol: {$locale_info[int_curr_symbol]}\n;
echo currency_symbol: {$locale_info[currency_symbol]}\n;
echo mon_decimal_point: {$locale_info[mon_decimal_point]}\n;
echo mon_thousands_sep: {$locale_info[mon_thousands_sep]}\n;
echo positive_sign: {$locale_info[positive_sign]}\n;
echo negative_sign: {$locale_info[negative_sign]}\n;
echo int_frac_digits: {$locale_info[int_frac_digits]}\n;
echo frac_digits: {$locale_info[frac_digits]}\n;
echo p_cs_precedes: {$locale_info[p_cs_precedes]}\n;
echo p_sep_by_space:{$locale_info[p_sep_by_space]}\n;
echo n_cs_precedes: {$locale_info[n_cs_precedes]}\n;
echo n_sep_by_space:{$locale_info[n_sep_by_space]}\n;
echo p_sign_posn: {$locale_info[p_sign_posn]}\n;
echo n_sign_posn: {$locale_info[n_sign_posn]}\n;
echo /PRE\n;
Edit this bug report at http://bugs.php.net/?id=14793edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
+1 Edin Kadribasic wrote: I know that PHP is mainly used for developing web-based applications, but I think that it has a great potential as a general purpose scripting language. Even when developing web applications I often find necessary to make command line scripts for maintenance and batch operations. One of our goals should be the presence of /usr/bin/php on as many systems as possible. We already have decent support for command line scripts in form of ext/ncurses, ext/pcntl and similar, but there are still some pieces that could be improved. The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. There were some suggestions on this list to create a new sapi (CLI), which would be a simplified version of cgi sapi, but which would print no headers by default, etc. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14803: Call to SQLGetInfo in odbc_cursor gives empty cursor name
From: [EMAIL PROTECTED] Operating system: Sybase ODBC (QNX and Win2k) PHP version: 4.1.1 PHP Bug Type: ODBC related Bug description: Call to SQLGetInfo in odbc_cursor gives empty cursor name This bug appears to have been in the code for several versions - definitely 4.0.5 through 4.1.1. In the odbc_cursor function (defined in ext/odbc/php_odbc.c), the call to SQLGetInfo (lines 1057-1058 in version 4.1.1 source code) uses a zero as the fourth parameter. This causes odbc_cursor to incorrectly return an empty cursor name, '' (when using different versions of Sybase SQL Anywhere under both QNX and Windows 2000). The bug looks like it is more in the Sybase implementation of the ODBC SQLGetInfo documentation. According to the ODBC documentation, the fourth parameter is supposed to be ignored when the second parameter is set to an int type such as SQL_MAX_CURSOR_NAME_LEN. The fix/workaround is to change the fourth parameter to: sizeof(max_len) Can this fix be implemented in the base PHP code so that it works with the widest selection of ODBC drivers? Correct implementations should ignore this value. Thanks. -- Edit bug report at: http://bugs.php.net/?id=14803edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Built-in SOAP based Web Services support (wasRe:PHP 5)
I think this sub-thread is a wonderful candidate for being taken offline. Zeev Suraski wrote: At 05:28 02/01/2002, Manuel Lemos wrote: (b) If we do it, it'll go on leaking as it does today False, if you do it you will give one less reason for users to drop PHP. That sentence MEANS that though. Maybe you weren't sure of what you were saying, but saying We have to do X in order to prevent even more users from leaking means that even if we do X, users will go on leaking as they do now, and if we don't do X, they'll leak more. Again, I wasn't expecting you to answer me point by point on this and tell me if you think it's right or not. As I said - if it's the truth - we don't want to hear it - especially when people here don't think it's the truth. Think positive. You are still not getting it, I don't have a problem when people do not accept my ideais. My problem only happens when arises when people invent forced excuses for not accepting my ideas or at least to not put them in practice. What excuses did I make up? What excuses did I even mention? I said that the preachy way in which you presented your idea is not going to get you anywhere, let alone PHP. You may have encouraged someone to write a CORBA extension, and you definitely pissed off lots of other developers. Is that good? Did it get you or PHP anywhere better? I can assure you, by the way, that Andi didn't ask for out-of-the-blue ideas from people who don't have any idea on how to do them, and have no intention of doing anything about them themselves. How about a wiseguy that will suggest to improve the speed of PHP 10 times around? Great, we're all for it, but have a plan on how to do it, or be willing to work on a plan if it's accepted. It is like Richard Heyes said very well, while Andi asked for suggestions you promptly jumped in just to say it is pointless as if it was urgent to refuse my suggestion, or at least present an excuse for not implementing it. I did not refuse your suggestion or present any excuses. That's only in your preset mind. I said it's good, but I also said that you presented it in a very, VERY poor way, as you tend to often do. There's no conspiracy against you, I can assure you that, and if you cause many different people to object to the way that you present your ideas, you can assume that the problems lie in your hands, and not everybody else's. I hope you see this time is not just Manuel. Things could have worked much better if you have to refused the countless times that I bothered to lend a hand, even if it was just presenting ideas and no code. Too bad that you usually only wanted to get me wrong as if what I was suggesting was not going to work in your favour. Anyway, it is not soon, but may be is not too late... I never refused a single time you bothered to lend a hand - I don't recall a single time (other than this vague virtual marketing idea which I didn't consider too good). As far as I recall, you said that Rasmus refused your help in the past, and I think I was the one that actually pushed for you to get a CVS account. Not sure though, it was a long time ago. At any rate, with all the differences I have with Rasmus, and God know we have lots - if he refused to accept your help, you must have done something TERRIBLY wrong. Zeev -- Darrell Brogdon http://darrell.brogdon.net 1024D/D7FB6981 3CB8 A14D 1662 8351 11F6 40C1 D205 2D97 D7FB 6981 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14716 Updated: PHP 4.1.1 DSO: apache startup fail
ID: 14716 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: Linux, RH 6.1 base, Kernel2.2.19 PHP Version: 4.1.0 New Comment: OK, it turns out to be the --with-dmalloc option. I can use [almost] any other options that pertain to libraries available on my system, but with that one... php builds fine, but then has the mentioned problem at runtime. So would this be some problem with my dmalloc?? Is this a single report of this issue, or what? Previous Comments: [2002-01-01 02:13:12] [EMAIL PROTECTED] This seems to have been remedied by supplying --with-regex=php. Supplying --with-regex=apache caused a build failure. [2001-12-27 06:41:23] [EMAIL PROTECTED] /usr/local/apacheS/bin/apachectl start gives me: Syntax error on line 968 of /usr/local/apacheS/conf/httpd.conf: BrowserMatch regex could not be compiled. ../bin/apachectl start: httpd could not be started Before installing the libphp4.so module, the server was fine. This problem seems to occur regardless of whether or not I comment the modssl and modperl module lines. Something about the options below that don't work together? Please let me know. :( I have compiled PHP4.1.1 with this configure line: ./configure --with-mysql=/usr/local --with-ldap --enable-mailparse --with-db3 --with-gdbm --with-ndbm --with-ttf --with-freetype-dir=/usr/local/include/freetype/ --with-imap --with-openssl=/usr/local/ssl/ --with-imap-ssl=/usr/local/ssl --with-gd --enable-dmalloc --with-bz2 --enable-ftp --with-apxs=/usr/local/apacheS/bin/apxs --sysconfdir=/etc --with-jpeg-dir=/usr/ --with-zlib-dir=/usr/local --with-png-dir=/usr/local --with-xpm-dir=/usr/X11R6 --with-mcrypt=/usr/local --with-mhash=/usr/local/ --enable-gd-native-ttf --with-java=/usr/jdk1.3/ --enable-track-vars Everything is OK, no debug.log generated. Edit this bug report at http://bugs.php.net/?id=14716edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
On Wed, 2 Jan 2002 14:43:39 +0100, Edin Kadribasic wrote: The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. I'm +1 on this, even though I think that PHP isn't very well suited for shell jobs in comparison to Bash or Perl. Always building the CGI version would also help the PEAR command line installer a lot since it currently needs a PHP binary to be executed. - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. I'm +1 on this, even though I think that PHP isn't very well suited for shell jobs in comparison to Bash or Perl. I don't know Perl, but I cannot see what's the advantage of using bash (except for the infamous exit() function) over PHP. If there are any maybe we can do something about it. The same goes for Perl. Always building the CGI version would also help the PEAR command line installer a lot since it currently needs a PHP binary to be executed. Yes, I had that in mind. We should get /usr/bin/php on as many machines as possible. This message from Stig S. Bakken summarises nicely what I'm trying to say: http://marc.theaimsgroup.com/?l=php-devm=100313140811956w=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. I'm +1 on this, even though I think that PHP isn't very well suited for shell jobs in comparison to Bash or Perl. I don't know Perl, but I cannot see what's the advantage of using bash (except for the infamous exit() function) over PHP. If there are any maybe we can do something about it. The same goes for Perl. Always building the CGI version would also help the PEAR command line installer a lot since it currently needs a PHP binary to be executed. Yes, I had that in mind. We should get /usr/bin/php on as many machines as possible. This message from Stig S. Bakken summarises nicely what I'm trying to say: http://marc.theaimsgroup.com/?l=php-devm=100313140811956w=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14806: server RECV strange if using PHP clients
From: [EMAIL PROTECTED]
Operating system: W2K
PHP version: 4.1.0
PHP Bug Type: Sockets related
Bug description: server RECV strange if using PHP clients
we've got a serious problem that we couldn't fix within a week even after
trying several options. So we very much appreciate ANY help.
We use PHP 4.1.0 on Windows 2000 server under IIS.
Situation: we are running socket-based servers that follow the
implementation recommendations found at http://tangentsoft.net/wskfaq/. The
problems encountered can be reproduced by using the BasisServer provided
at http://tangentsoft.net/wskfaq/examples/basics/basic-client.html.
Test1.
We use the fokkowing PHP-Script. Thereby we use the native socket-functions
introduced in PHP 4.1.0.
?
$port = ;
$string = P RegioTicket/Haltestellensuche@R 0@N Frankfurt@A 15@;
$socket = socket_create (AF_INET, SOCK_STREAM, 0);
if ($socket 0)
{
echo socket_create() failed: reason: ;
}
else
{
socket_create() successful: ;
}
$ip = gethostbyname ('172.24.79.232');
echo nbsp;Attempting to connect to '$ip' on port '$port'...;
$result = socket_connect ($socket, $ip, $port);
if ($result 0)
{
echo socket_connect() failed.\nReason: ($result) .
socket_strerror($result) . \n;
}
else
{
echoOK.\n;
}
$length = strlen($string);
echo brVariable $ . $string . $BR;
$retcodew = socket_write ($socket, $string, $length);
$retcoder = socket_read ($socket, $var, 10);
echo brVariable $ . $var . $BR;
echo return Code Write : . $retcodew . br;
echo Return Code Read : . $retcoder ;
?
To follow the example debug the BasicServer.exe (basic-server.cpp) or just
believe me g.
The server waits within ACCEPT. When the client sends data it RECEIVES this
data and SENDS it back as an echo. It cycles throught the rest of the loop,
ending in another RECEIVE. This RECEIVE returns -1, which is recognized
as an socket error, finally leading into closing down the server. Unwanted
result.
Test2.
We use the following PHP-script. Thereby we use the classic style with
fsockopen, fputs, fgets, fsockclose.
?php
$anfrage = P RegioTicket/Haltestellensuche@;
$anfrage .= R 0@;
$anfrage .= N Frankfurt@;
$anfrage .= A 15@;
echo $anfrage br;
$fp = fsockopen(172.24.79.232, , $errno, $errstr, 10);
if(!$fp)
{
$err = error: $errstr ($errno)br;
return $err;
}
else
{
$n = strlen($anfrage); // size of buffer for request
//$str = sprintf(%08d%s, $n, $anfrage);
fputs($fp, $anfrage);
echo test nach puts();
$result = fgets($fp, 128);
//get_selection($fp, $select);
//socket_shutdown($fp, 1);
fclose($fp);
return $result;
}
?
The server waits within ACCEPT. When the client sends data it RECEIVES this
data and SENDS it back as an echo. It cycles throught the rest of the loop,
ending in another RECEIVE. This RECEIVE waits indefinitely until some
timeout occurs. Unwanted result, the server is blocked.
Test3.
We use one of our good old REXX scripts and rxsock.dll.
The server waits within ACCEPT. When the client sends data it RECEIVES this
data and SENDS it back as an echo. It cycles throught the rest of the loop,
ending in another RECEIVE. This RECEIVE returns 0 which indicates that no
more data is available, the server closes the connection, recycles itself
into the ACCEPT statement again and waits for the next connection request.
We consider this to be the expected result, being comaptible to our own
C++-clients and the examples we found in the Internet.
So our question is, why the results are different when using PHP. Maybe we
just need to know how to inplement that in a better way using PHP. But as
we already spent some considerable time with it, we think, that the
inplementation within PHP (both) might need some improvement. But maybe PHP
just needs server that follow some rules of a protocol. If so, where can we
find specifications for this?
--
Edit bug report at: http://bugs.php.net/?id=14806edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14625 Updated: socket servers expect more data from PHPCGI
ID: 14625 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Duplicate Bug Type: Sockets related Operating System: Windows 2000 PHP Version: 4.1.0 New Comment: Has been replaced by a more specific bug report showing other problems. Previous Comments: [2001-12-20 11:23:34] [EMAIL PROTECTED] Standard sequence of single fsockopen, fputs, fgets, fclose hangs servers. Our own C++-servers and several samples of socket-servers we found in the Internet work with other clients, but when being used by PHP scripts in the standard way described all around try to recv(eive) more data from the PHP script, that itself waits at the fgets statement. Finally this locking situation is resolved by some timer running up at client or server side. Data sent by PHP script is received by the servers in the correct length and echo servers or others do send data back before going back to the recv the actually hangs the (non-blocking server or thread). So from PHP side some information like end of transmission seems to be missing at the server side. Same behavior using PHP 4.0.6 Edit this bug report at http://bugs.php.net/?id=14625edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: PHP 5
From: Joao Prado Maia [mailto:[EMAIL PROTECTED]] Why not separate everything and then bundle the more popular ones to the normal PHP distribution on the time of a release ? I would love to be able to upgrade just the 'GD' extension if there was a bug on the extension on release PHP4.1.12 and it was fixed on PECL version of the extension 2.1.23. this sounds like the best idea to me release everything separately and make a current snapshot for a new php release of the most popular extensions Best regards, Lukas Smith [EMAIL PROTECTED] ___ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Germany Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de [EMAIL PROTECTED] ___ -Original Message- Sent: Wednesday, January 02, 2002 5:09 PM To: Zeev Suraski Cc: Björn Schotte; [EMAIL PROTECTED]; Adam Dickmeiss; Jim Winstead; php- [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: PHP 5 On Wed, 2 Jan 2002, Zeev Suraski wrote: At 16:06 02/01/2002, Björn Schotte wrote: * Zeev Suraski wrote: Well, I think that the main motivation for separating the modules away was the release schedule. I.e., separating the release schedule of each extension from the release schedule of the PHP core itself. Jep. Just to note: I'm +1 for it. Why not separate everything and then bundle the more popular ones to the normal PHP distribution on the time of a release ? I would love to be able to upgrade just the 'GD' extension if there was a bug on the extension on release PHP4.1.12 and it was fixed on PECL version of the extension 2.1.23. I would also love to be able to tell the users of my application to just use the PEAR installer to download and install the bugfix release of the GD extension instead of telling them to not use a particular buggy / not compatible version of PHP. I can understand that it will mean more work to you guys to handle several release independent extensions, but if you can just use the PEAR installer to download the stuff from the repository, you will be able to download the stable releases from PEAR and then build the general PHP distribution. Joao -- João Prado Maia [EMAIL PROTECTED] http://phpbrasil.com - php com um jeitinho brasileiro -- Precisando de consultoria em desenvolvimento para a Internet ? Impleo.net - http://impleo.net/?lang=br -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14805: array_unique works opposed to the manual
From: [EMAIL PROTECTED]
Operating system: MS Windows 98
PHP version: 4.0.6
PHP Bug Type: Arrays related
Bug description: array_unique works opposed to the manual
The manual (recent version from cvs) states that :
array_unique() will keep the first key encountered for every value, and
ignore all following keys.
I've tested the two examples in this page and I've found
this statement is not true.
?php
$input = array (4,4,3,4,3,3);
$result = array_unique ($input);
var_dump($result);
?
output: /* PHP 4.0.6 Win'98 PWS */
array(2) {
[3]=
int(4)
[4]=
int(3)
}
but the manual says it should print:
array(2) {
[0]=
int(4)
[1]=
string(1) 3
}
As you can recognize the latest keys are preserved
for both value 4 and 3.
--
Edit bug report at: http://bugs.php.net/?id=14805edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PECL (was PHP 5)
I think that if PECL ends up being very good and actually works very nicely and transparently, we would PECLize all extensions. At release time of a new version of PHP we'd create a huge .tar.gz with the latest STABLE versions of the extensions we decide should be in the release tar.gz (I hope saying the extensions we decide on is politically correct enough :). However, if PECL doesn't become everything we hoped for within the next few months (possible) I don't think it should stop PHP 5. We could always have 5.1. Anyway, that's not too important right now. We still haven't heard from anyone what work has been done on PECL. I think without a lot of work done by many of us here on php-dev it'll probably not gain enough momentum. I suggest we move PECL either to its own mailing list or to php-dev. I don't think it's a good idea to mix between it and the PEAR mailing list which is mostly about PEAR PHP code.. Concerning PHP 5, some time ago we talked about how we're going to handle the standardization of function names with the next major version. Do you guys want to revisit this issue or keep the status quo? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14807: core dump
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.1.0
PHP Bug Type: Unknown/Other Function
Bug description: core dump
Running the following always causes a core dump:
?php
$arr = array (
1 = array (0,0,0,0,0),
2 = array (0,0,0,0,0),
3 = array (0,0,0,0,0),
4 = array (0,0,0,0,0),
5 = array (0,0,0,0,0)
);
print_r($arr);
echo br\n\nbr\n\n;
$str = serialize($arr);
echo serializedbr\n, $str, brbr\n\n;
function hex2bin($data) {
$len = strlen($data);
return pack(H . $len, $data);
}
$enc = urlencode($str);
echo urlencodedbr, $enc, brbr\n\n;
$gzd = gzcompress($enc);
//echo gzcompressed (urlencoded)br, $gzd, brbr\n\n;
$b64 = base64_encode($gzd);
echo base64_encodedbr, $b64, brbr\n\n;
$b2h = bin2hex($enc);
echo bin2hex (urlencoded)br, $b2h, brbr\n\n;
$binary = base_convert($b2h, 16, 2);
echo $binary, brbr\n\n;
$conv = base_convert($binary, 2, 16);
echo $conv, brbr\n\n;
$h2b = hex2bin($conv);
echo $h2b, brbr\n\n;
$md = md5($str);
echo md5br, $md, brbr\n;
?
--
Edit bug report at: http://bugs.php.net/?id=14807edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14807 Updated: core dump
ID: 14807
Updated by: jan
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System:
PHP Version: 4.1.0
New Comment:
at least for me it doesn't (FreeBSD 4.4 PHP 4.1.0)
can you provide more Information about you environmation (OS, configure options e.g.)
?
Previous Comments:
[2002-01-02 13:39:24] [EMAIL PROTECTED]
Running the following always causes a core dump:
?php
$arr = array (
1 = array (0,0,0,0,0),
2 = array (0,0,0,0,0),
3 = array (0,0,0,0,0),
4 = array (0,0,0,0,0),
5 = array (0,0,0,0,0)
);
print_r($arr);
echo br\n\nbr\n\n;
$str = serialize($arr);
echo serializedbr\n, $str, brbr\n\n;
function hex2bin($data) {
$len = strlen($data);
return pack(H . $len, $data);
}
$enc = urlencode($str);
echo urlencodedbr, $enc, brbr\n\n;
$gzd = gzcompress($enc);
//echo gzcompressed (urlencoded)br, $gzd, brbr\n\n;
$b64 = base64_encode($gzd);
echo base64_encodedbr, $b64, brbr\n\n;
$b2h = bin2hex($enc);
echo bin2hex (urlencoded)br, $b2h, brbr\n\n;
$binary = base_convert($b2h, 16, 2);
echo $binary, brbr\n\n;
$conv = base_convert($binary, 2, 16);
echo $conv, brbr\n\n;
$h2b = hex2bin($conv);
echo $h2b, brbr\n\n;
$md = md5($str);
echo md5br, $md, brbr\n;
?
Edit this bug report at http://bugs.php.net/?id=14807edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14443 Updated: Double-free causes segfault in domxml
ID: 14443
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: DOM XML related
Operating System: Linux Redhat 7.1
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 02:19:24] [EMAIL PROTECTED]
'The code has changed quite a lot ...' ...
[2001-12-12 02:18:52] [EMAIL PROTECTED]
Ok, just don't forget to give feedback. The quite has changed but doesn't necessarily
mean the bug has been fixed ;-)
Feedback.
[2001-12-12 02:04:49] [EMAIL PROTECTED]
I just looked at the php4 code in the CVS tree and it
appears that this bug is already fixed, in a better way
than I did it. We'll have to look into upgrading to 4.1 I
guess. Thank you.
Adam
[2001-12-11 21:48:45] [EMAIL PROTECTED]
The code has changed quite a lot since 4.0.6. I can't reproduce the crash with the
current CVS version. Please give it yourself a try.
Feedback.
PS: Patches not against CVS are most of the time useless because code tends to change
a lot.
[2001-12-11 21:02:16] [EMAIL PROTECTED]
The domxml extension frees memory twice when an XPath
query is used which results in an empty nodelist. I'm
providing a PHP script which reproduces the bug, and a
patch to fix it.
How to reproduce:
$xml = 'xml fragment';
$doc = xmldoc($xml);
$xh = $doc-xpath_new_context();
$nodes = xpath_eval($xh,
xpath expression which doesn't match anything);
When the xpath expression doesn't match any nodes, then
the xmlXPathObjectPtr which gets created by the query gets
freed twice. Usually a segfault won't occur unless you do
8 or more non-matching XPath queries, since a single
double-free won't always cause a segfault. But if you run
php with ElectricFence, a malloc debugging library, then a
single non-matching XPath query will generate the
double-free error.
The bug is caused in the php_xpathptr_eval() function in
php_domxml.c. It calls xmlXPathEval() and saves the
result in xpathobjp. It then inserts xpathobjp into a
zend list, le_xpathobjectp. Later in the function, it
checks whether xpathobjp contains an empty nodeset, and if
it does, it calls xmlXPathFreeObject(xpathobjp) and
returns FALSE. But it didn't remove the xpathobjp pointer
from the zend list before deleting it, so when PHP exits
and cleans up the objects, the pointer sitting on the
le_xpathobjp list gets freed again. I fixed the bug by
checking whether the nodeset is empty before it gets put
on the zend list, and if it is empty, I free it and just
return FALSE from the function.
I'm appending my patch to php_domxml.c, a PHP program that
triggers the bug in php 4.0.6, and also a stack trace
showing where the crash occurs.
-- patch to php_domxml.c --
*** php-4.0.6-orig/ext/domxml/php_domxml.c Thu May 24
08:41:46 2001
--- php-4.0.6/ext/domxml/php_domxml.c Tue Dec 11
01:06:08 2001
***
*** 1681,1686
--- 1681,1690
if (!xpathobjp) {
RETURN_FALSE;
}
+ if (xpathobjp-type == XPATH_NODESET
!xpathobjp-nodesetval) {
+ xmlXPathFreeObject(xpathobjp);
+ RETURN_FALSE;
+ }
ret = zend_list_insert(xpathobjp, le_xpathobjectp);
zend_list_addref(ret);
-- end patch --
-- STACK TRACE --
Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x402fea00, p=0x8185180) at
malloc.c:3180
3180in malloc.c
(gdb) bt
#0 chunk_free (ar_ptr=0x402fea00, p=0x8185180) at
malloc.c:3180
#1 0x4024acd4 in __libc_free (mem=0x8185188) at
malloc.c:3154
#2 0x4039b747 in xmlXPathFreeObject () from
/usr/lib/libxml2.so.2
#3 0x40019f9d in php_free_xpath_object (rsrc=0x818514c)
at php_domxml.c:188
#4 0x080c84b3 in list_entry_destructor (ptr=0x818514c) at
zend_list.c:179
#5 0x080c70fa in zend_hash_apply_deleter (ht=0x8133fd0,
p=0x8171b5c)
at zend_hash.c:615
#6 0x080c722a in zend_hash_graceful_destroy
(ht=0x8133fd0) at zend_hash.c:666
#7 0x080c85e0 in zend_destroy_rsrc_list () at
zend_list.c:234
#8 0x080bb42d in shutdown_executor () at
zend_execute_API.c:179
#9 0x080c3265 in zend_deactivate () at zend.c:540
#10 0x0805de9d in php_request_shutdown (dummy=0x0) at
main.c:660
#11 0x0805cfdd in main (argc=4, argv=0xb7f4) at
cgi_main.c:751
#12 0x401e6627 in __libc_start_main (main=0x805c740
main, argc=4,
ubp_av=0xb7f4, init=0x805ad5c _init,
fini=0x80f4920 _fini,
rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb7ec)
at ../sysdeps/generic/libc-start.c:129
-- END STACK
[PHP-DEV] Bug #14427 Updated: Starting a script takes almost 1 minute
ID: 14427 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Performance problem Operating System: RedHat 7.1 Linux 2.4.2-2 kernel PHP Version: 4.1.0 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 11:01:43] [EMAIL PROTECTED] re-classified and changed the short summary. [2001-12-11 12:51:51] [EMAIL PROTECTED] Can you provide some more information like a (simple) sample script, and your configure-line? [2001-12-11 11:44:34] [EMAIL PROTECTED] I builted php irc bot. It works whine with 4.0.6 php version. If i start bot with version 4.1.0, it takes about 1min before it even start totally. Computer loads get to over 5.00. Normally loads are 0.01-0.10. I have no problems with 4.0.6 but 4.1.0 doesn't work totally. Edit this bug report at http://bugs.php.net/?id=14427edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7973 Updated: Safe Mode absolute path behaviour changed
ID: 7973 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: Red Hat Linux 5.2 PHP Version: 4.0.3pl1 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:41:48] [EMAIL PROTECTED] Status = Feedback [2001-12-12 06:29:40] [EMAIL PROTECTED] Nobody has touched this bug report for a long time. Is this still a issue? To reporter: Could you try 4.1.0 see if there is problem? [2000-11-25 17:06:45] [EMAIL PROTECTED] Under PHP 4.0.1pl2 running in Safe Mode with the php_doc_root admin flag set to the user's home directory, a require()'d or include()'d (or auto_prepended) file could be specified as '/html/path/to/file', which would be evaluated as php_doc_root/html/path/to/file. After upgrading to PHP 4.0.3pl1 this is no longer working, and all files appear to require their absolute paths to be used, ie $DOCUMENT_ROOT . /path/to/file. Edit this bug report at http://bugs.php.net/?id=7973edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #8931 Updated: Memory leaks attributable to OO PHP
ID: 8931 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Performance problem Operating System: Windows 2000 PHP Version: 4.0.4pl1 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 18:46:19] [EMAIL PROTECTED] Could you try 4.1.0 see if it help? [2001-01-26 06:56:42] [EMAIL PROTECTED] I've identified the problem as PHP leaking memory when it sees code that it doesn't like, eg. it leaks code when the script crashes with an error. I think that it leaks code even when it reads through functions and there is code in them which it does not recognise (that it will give an error, but ... because the function is not run, the script does not report an error, but memory is leaked anyway). [2001-01-26 06:38:40] [EMAIL PROTECTED] The short version scored 7680 hits over 2 min, whereas the Object Oriented version scored around 1700 hits over 2 min running 4 threads. Both scripts do the same thing, query to database, with same result, but the OO version seems to be 5 times slower, so I am classifying this bug as a performance problem. [2001-01-26 06:32:37] [EMAIL PROTECTED] I wrote two scripts to compare the difference in performance between simple script and one written in OO with classes and required libraries. Both scripts accessed the SQL database using ADODB connection. I used Microsoft Web Application Stress Tool, which seems to be very useful. The simple version yielded better performance in less CPU usage (and no memory leaking), whereas the OO version maxed out the CPU usage 100%, as well as slowly but surely leaking memory. I tried using the unset() function in several places in the code, but this did not help much, as the script was still leaking memory during the tests. Using unset() to unset the COM object helped a lot, as PHP did not seem able to free the memory by itself. Edit this bug report at http://bugs.php.net/?id=8931edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9763 Updated: Segmentation Fault upon running big cl script
ID: 9763 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: RedHat 6.2 PHP Version: 4.0.4pl1 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 06:31:34] [EMAIL PROTECTED] Do you have this problem with 4.1.0? [2001-04-28 16:08:33] [EMAIL PROTECTED] User Feedback: -- Hi, I dont serialize any data. What happens is that I get lots of data from an Oracle database, then for each row i make x objects (objects being product (if!isset), item, unit, contry and so on), after having made all the objects i throw them into an objectsaver that saves the object data (not the object, just the data) in another oracle database. We might be dealing with 10K objects taking upwards 20mb mem. It is only when its saving the objects in the oracle database it segfaults -- which means that ALL objects HAVE been created, and are being saved. If theres anything I can do, please tell me, and I will happily subject myself and/or my little php fellow to all sorts of sadist attempts at squashing bugs :) TIA. Kind regards, David. [2001-04-28 14:40:53] [EMAIL PROTECTED] do you serialise this data etc? can you give us some more info on the script and perhaps somthing that will reproduce it if its not too big. Thanks - James [2001-03-15 04:47:08] [EMAIL PROTECTED] After the script has run for 10 minutes or so, it just seg faults. The script itself takes big amounts of data, and throws them into objects in an array, then when done it passes them on to a saver object that aves the object in another database. This happens at the end (it seems) of running through the array and plopping the objects into the database. Here's the backtrace: Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /usr/lib/libjpeg.so.62...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libtiff.so.3...done. Reading symbols from /usr/local/lib/libpdf.so.1...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /usr/local/lib/libmcrypt-2.2.so.2...done. Reading symbols from /usr/lib/libttf.so.2...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /db/ora8i/lib/libclntsh.so.8.0...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /db/ora8i/lib/libwtc8.so...done. Reading symbols from /lib/libpthread.so.0...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. #0 zend_hash_destroy (ht=0xbf155b4) at zend_hash.c:562 562 p = p-pListNext; (gdb) bt #0 zend_hash_destroy (ht=0xbf155b4) at zend_hash.c:562 #1 0x80fb879 in _zval_dtor (zvalue=0x8212464) at zend_variables.c:69 #2 0x80f5d22 in _zval_ptr_dtor (zval_ptr=0xc2e72c0) at zend_execute_API.c:261 #3 0x80ff139 in zend_hash_destroy (ht=0xc2e45bc) at zend_hash.c:564 #4 0x80fb898 in _zval_dtor (zvalue=0xc2e671c) at zend_variables.c:75 #5 0x80f5d22 in _zval_ptr_dtor (zval_ptr=0xc2e6a58) at zend_execute_API.c:261 #6 0x80ff139 in zend_hash_destroy (ht=0xc2c8cfc) at zend_hash.c:564 #7 0x80fb879 in _zval_dtor (zvalue=0xc2d5a8c) at zend_variables.c:69 #8 0x80f5d22 in _zval_ptr_dtor (zval_ptr=0xc2d6a38) at zend_execute_API.c:261 #9 0x80ff139 in zend_hash_destroy (ht=0xc2d6584) at zend_hash.c:564 #10 0x80fb898 in _zval_dtor (zvalue=0xc2d6094) at zend_variables.c:75 #11 0x80f5d22 in _zval_ptr_dtor (zval_ptr=0xc2eb338) at zend_execute_API.c:261 #12 0x80ff139 in zend_hash_destroy (ht=0x821154c) at zend_hash.c:564 #13 0x80f5bb2 in shutdown_executor () at zend_execute_API.c:165 #14 0x80fc267 in zend_deactivate () at zend.c:525 #15 0x806d442 in php_request_shutdown (dummy=0x0) at main.c:688 #16 0x806c7fa in main (argc=3, argv=0xba44) at cgi_main.c:771 HTH. David. Edit this bug report at http://bugs.php.net/?id=9763edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10113 Updated: allow_persistent directive doesn't work
ID: 10113 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: PHP options/info functions Operating System: Linux PHP Version: 4.0.4pl1 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 03:19:14] [EMAIL PROTECTED] Could you check if this problem exists in 4.1.0? [2001-04-02 09:12:53] [EMAIL PROTECTED] To prevent the use of persistent connections I've put the following lines in my php.ini: mysql.allow_persistent = Off ; pgsql.allow_persistent = Off ; When I look at the output of phpinfo() I can see that PHP reads my settings, because it reports persistent links to be off. Nevertheless, PHP still allows persistent connections, so every now and then I run out of available database backends because too many of them are idling. I solved this problem by patching the source code (modified ext/pgsql/pgsql.c line 462 and ext/mysql/php_mysql.c line 597, changed 1 into 0), but I do not consider this as a 'clean' solution, since I have to patch the source every time I update PHP. You can view phpinfo()'s output at: http://www.schapendonk.org/config Thanks for your time to look into this problem. Regards, Martin Schapendonk Edit this bug report at http://bugs.php.net/?id=10113edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10197 Updated: magic_quotes_runtime and other magic quotes sometimes are switching on or off.
ID: 10197 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.4pl1 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 04:23:39] [EMAIL PROTECTED] Type = Scripting Engine Problem Does this happen with 4.1.0? [2001-04-06 05:33:38] [EMAIL PROTECTED] magic_quotes_runtime and other magic quotes sometimes are switching on or off without any reason. First noticed in 4.0.3pl. After moving to 4.0.4pl1 seemed to be working ok for 2 weeks. Now found several situations where magic quotes are unstable in MySQL Output. eg $row-string is \test\ can be output'ed with printf as test or \test\ with magic_quotes_runtime set to on. PHP's PHPINFO() is available at http://slackl.emd.ru/~slackl/test.php Edit this bug report at http://bugs.php.net/?id=10197edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10485 Updated: no input file specified when running as a CGI
ID: 10485 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: HP-UX 11 PHP Version: 4.0.4pl1 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:28:07] [EMAIL PROTECTED] Could you try 4.1.0? to see if it helps? [2001-04-25 02:19:06] [EMAIL PROTECTED] I am running PHP4 4.0.4pl1 on HP-UX11 (64 bit) and Apache 1.3.11. I compiled PHP4 with gcc and did not specify any options except --with-mysql. When I try to execute simple scripts like: #!/opt/php4/php -q echo foobar; I always get No input file specified. If I leave out the option -q my scripts work, but I always get as a first line #!/opt/php4/php which prevents me from using cookies :-( It is hardly possible to compile PHP on HP-UX, so I cannot (and do not want to) use PHP as an Apache module. I would be extremely happy to use PHP via CGI, but I am still running into this annoying bug which should be fixed long ago. At least the usenet is full of descriptions No input file specified when using PHP via CGI and I never encountered a solution. I have got it running on Apache and Windows 2000 without problems (since there was no need to compile anything :-), but this is not a suitable webserver. Cheers, Mark Edit this bug report at http://bugs.php.net/?id=10485edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10840 Updated: asp_tags = On is ignored, if apache is started with the php4_module
ID: 10840 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: win 98 PHP Version: 4.0.5 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:05:51] [EMAIL PROTECTED] Could you try PHP4.1.0 to see if you still have this problem? [2001-05-13 14:13:54] [EMAIL PROTECTED] asp_tags = on in php.ini is ignored when apache is started with LoadModule php4_module c:/php/sapi/php4apache.dll in httpd.conf. It works when apache is limited to work with the cgi binary Edit this bug report at http://bugs.php.net/?id=10840edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10857 Updated: Syntax highlighting does not work with output buffering/compression
ID: 10857 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Output Control Operating System: RH Linux 6.x PHP Version: 4.0.5 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 04:34:31] [EMAIL PROTECTED] Does this happen with 4.1.0? [2001-05-14 14:05:20] [EMAIL PROTECTED] Syntax highlighting (i.e. phps script) appears to be broken if you have output buffering and compression turned on. in my .htaccess file I had overrode the values for output_buffering and output_handler. The values were confirmed to be turned on via a phpinfo page. With the .htaccess file in place, the source was displayed, but there was no color syntaxing. Once I removed the .htaccess file it worked as expected. Edit this bug report at http://bugs.php.net/?id=10857edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10903 Updated: Output buffering crashs PHP when mail function is invoked
ID: 10903 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Output Control Operating System: Win98 PHP Version: 4.0.5 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 04:20:31] [EMAIL PROTECTED] Does this happen with 4.1.0? [2001-05-16 10:24:27] [EMAIL PROTECTED] This will crash PHP: ob_start(ob_gzhandler); echo something; mail (.); but this will not: ob_start(ob_gzhandler); echo something; ob_end_flush(); mail (.); Note: I don't have any mail server installed. The mail function should report an error, but PHP crashes instead. Edit this bug report at http://bugs.php.net/?id=10903edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10905 Updated: ImageGif (ImagePNG) output uncompressed
ID: 10905 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Output Control Operating System: Linux PHP Version: 4.0.5 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 05:02:21] [EMAIL PROTECTED] Ok Derick. It would be useful for other purposes also. Status = Feedback. To reporter, Could you try it on snapshot http://snaps.php.net/ Please provide *short* script. Thank you. [2001-12-12 04:39:21] [EMAIL PROTECTED] Let's not make this bogus. However, please post a short reproducing example script. Derick [2001-12-12 04:27:44] [EMAIL PROTECTED] If you want to compress images, use zlib extension. [2001-05-16 12:17:43] [EMAIL PROTECTED] Using the compression ob_gzhandler all HTML Pages get compressed well. But dynamic generated Images don't get compressed. Header of the output says, it is compressed, but the data following the header isn't. So those images can't be displayed (by at least netscape) Thanks for the patch, ;-) mike PS: Don't tell me that it isn't useful to gzip images, but if you have switched compression to 'enabled' in your php.ini file and you are creating images on the fly, you'll need it to handle this case correctly. Edit this bug report at http://bugs.php.net/?id=10905edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11103 Updated: different cookie behavior with module vs. cgi
ID: 11103 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: win98 PHP Version: 4.0.5 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:18:01] [EMAIL PROTECTED] Do you still have this problem with 4.1.0? [2001-05-25 00:10:55] [EMAIL PROTECTED] ok... i added the code before and you told me to ask for help in the support forum! argh. anyway, here is some psuedo code. script1.php: set_cookie(blah); header(Loaction: absolute to script2); script2.php: /* cookie is not available here in cgi version, but is in module version */ [2001-05-24 21:38:36] [EMAIL PROTECTED] Add an example script into this bug report. [2001-05-24 21:00:05] [EMAIL PROTECTED] when running php as cgi with this sequence set_cookie(), header(Location: new script): new script will not see the cookie. however, with the module it works fine. Edit this bug report at http://bugs.php.net/?id=11103edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11676 Updated: A few apache children consume all memory and CPU.
ID: 11676 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: linux 2.4.5 i386 PHP Version: 4.0 Latest CVS (2001-06-25) New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:20:11] [EMAIL PROTECTED] Status = feedback [2001-12-12 08:19:47] [EMAIL PROTECTED] Could you try 4.1.0? see if it helps? [2001-08-19 05:31:51] [EMAIL PROTECTED] There's only one issue... how can I determine which script was running on the processes that i find stuck? In the meanwhile i installed the Zend Optimizer on the server, and the problem seems to happen VERY less frequently... i know this is nearly no help at all, but I'm doing all I can. Anyway, i see some other guy had my same problem... [2001-08-19 04:56:56] [EMAIL PROTECTED] A short script that causes this would help a lot.. [2001-07-13 04:43:02] [EMAIL PROTECTED] anyone alive??? 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/?id=11676 Edit this bug report at http://bugs.php.net/?id=11676edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11700 Updated: db2 driver initialization failed
ID: 11700
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: DBM/DBA related
Operating System: RedHat 6.2
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 04:13:06] [EMAIL PROTECTED]
Status = Feedback
[2001-12-12 04:12:23] [EMAIL PROTECTED]
Do you still have problem with 4.1.0?
[2001-06-26 11:00:20] [EMAIL PROTECTED]
I read the other bug reports. Apache user has write permission to the directory
containing the db2 file. I have db2 support compiled in:
dba
DBA support: enabled
Supported handlers:gdbm db2
db:This is GDBM version 1.8.0, as of May 19, 1999
config parameters:
./configure --prefix=/usr/local \
--with-apxs=/usr/sbin/apxs \
--enable-track-vars \
--enable-trans-sid \
--enable-versioning \
--enable-apc \
--with-calendar=shared \
--enable-safe-mode \
--with-gdbm=/usr/include \
--with-db=/usr \
--enable-mbstring \
--enable-mbstr-enc-trans \
--with-db2=/usr/local/BerkeleyDB
Using SleepyCat BerkeleyDB 2.7.7.
This script:
$dbmfile= /tmp/testdb;
$username= user;
$passwd= password;
$encpasswd = crypt ($passwd);
$dbh = dba_open($dbmfile, c, db2) or die (Cannot open DB $dbmfile!);
if (!dba_replace($dbh, $username, $encpasswd)) {
print Success;
} else {
print Failure;
}
dba_close($dbh);
..causes this error:
Warning: driver initialization failed in /home/richpav/php/passwd.php on line 8
Cannot open DB /tmp/testdb!
If tempdb isn't already created (using perl script), PHP creates a 0 byte file
previous to barfing.
Changing the mode from c to w, r or n has no effect.
I CAN use gdbm with PHP, no problem.
If you need more info, please let me know.
Edit this bug report at http://bugs.php.net/?id=11700edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11723 Updated: A few apache children remain in memory after apachectl stop
ID: 11723 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: linux 2.2.14 and 2.2.16 PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:16:26] [EMAIL PROTECTED] Do you still have this problem with 4.1.0? [2001-06-28 03:04:01] [EMAIL PROTECTED] This is the line I used to configure the PHP: ./configure --enable-imap --enable-mysql --with-mysql --with-apache=../$APACHE --with-imap --without-xml --enable-track-vars --enable-memory-limit=yes --with-zlib=/usr --with-gd=/usr/local --with-jpeg-dir=/usr --with-png-dir=/usr --enable-magic-quotes The problem has presented only with PHP 4.0.5 (and 4.0.6) with apache 1.3.20. Before we had PHP 4.0.3pl1 with Apache 1.3.16 and we had no problems. Soon as possible I'll try to give you a gdb track... this is difficult because often the machine is completely down and the only way to restart the apache is to reboot (power down) it... Denis [2001-06-27 11:56:50] [EMAIL PROTECTED] what was the configure line used to configure PHP? [2001-06-27 03:56:32] [EMAIL PROTECTED] I have the same problem as Valerio (bug #11676), but in my case the apache children remain in memory and it is not possible to kill them (i've tried also kill -9 but nothing do to, sick!). The only way to solve the problem is to reboot the machine or, in the worst case, to power down hardly the system. The kernels are 2.2.14 (RedHat 6.2) and 2.2.16 (RedHat 7.0) , the apache is 1.3.20 and php 4.0.6 (but the problems were present also in php 4.0.5 with apache 1.3.19). I was not able to track down the bug, it seems to happen randomly. The php is compiled with gd,mysql and imap (4.7c2). Denis Edit this bug report at http://bugs.php.net/?id=11723edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11739 Updated: Memory limit is used for all scripts instead of one script?
ID: 11739
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Suse Linux 7.0
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 08:45:46] [EMAIL PROTECTED]
This is similar to set_time_limit() problem...
Anyone know if this is fixed or not?
To reporter: Could you try 4.1.0 and report the result?
[2001-06-27 10:43:12] [EMAIL PROTECTED]
Hi there!
As far as I understand, the option memory_limit sets the mem-limit for ONE script.
I installed PHP as a Apache module and I set the memory_limit to 16M (via php.ini).
When I allocate 8M of memory, all works fine. But when two different scripts each
allocate 8M, I will get sometimes the following message:
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate
4194304 bytes) in /usr/local/httpd/htdocs/testxx.php on line 6
Both scripts (testx.php and testxx.php) contain the following code:
?php
$str = x;
for($i=0; $i23; $i++)
{
$str .= $str;
echo strlen($str) . br;
}
?
First, 1 byte will be allocated, then 2, then 4 and so on. The last allocated string
has a size of 8M.
It's a little difficult to reproduce the problem because I have to call both scripts
exactly at the same time from my browser. But, as I said, sometimes I get the
described error-message.
My question is: Is this normal and memory_limit sets the limit for ALL scripts that
are currently running or is this a bug?
Thanks in advance!
... tobias wiersch from germany
Edit this bug report at http://bugs.php.net/?id=11739edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12227 Updated: Output puffering causes Apache to SIGSEGV
ID: 12227
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Output Control
Operating System: Linux 2.2.16-SMP
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 04:31:14] [EMAIL PROTECTED]
I guess you have ob_end_clean() or ob_end_flush() in your auto prepend file. Do you?
Anyway, does this happen with 4.1.0?
[2001-07-18 06:13:58] [EMAIL PROTECTED]
One more comment which I forgot before:
This does NOT happen when I do not use auto_prepend_file and call my function inside
the main script instead.
[2001-07-18 06:07:05] [EMAIL PROTECTED]
When using ob_start() with a script included via auto_prepend_file and then doing
something like this:
ob_start(my_flush);
function my_flush($buffer)
{
$buffer = preg_replace(/(!--REPLACE\\s.*?--)/e, parse(\\\1\),
$buffer);
return $buffer;
}
PHP 4.0.6 SIGSEGV's with this message in the error_log:
[Wed Jul 18 11:55:08 2001] Script: '/home/htdocs/test.php'
---
output.c(235) : Block 0x0824C940 status:
Beginning: Overrun (magic=0x08294990, expected=0x7312F8DC)
End: Unknown
---
./zend_execute.c(334) : Freeing 0x082A8CB4 (28131 bytes),
script=/home/htdocs/test.php
zend_variables.c(117) : Actual location (location was relayed)
[Wed Jul 18 11:55:08 2001] [notice] child pid 30192 exit signal Segmentation fault
(11)
If I replace the line
$buffer = preg_replace(/(!--REPLACE\\s.*?--)/e, parse(\\\1\),
$buffer);
with
$newbuffer = preg_replace(/(!--REPLACE\\s.*?--)/e, parse(\\\1\),
$buffer);
it works fine.
Any ideas for a fix?
Harry
Edit this bug report at http://bugs.php.net/?id=12227edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12251 Updated: Error with zend_hash.c after writing a file
ID: 12251
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System:
PHP Version: 4.0CVS-2001-07-19
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 07:05:08] [EMAIL PROTECTED]
Could you try with 4.1.0? If there is problem, try it on snapshot.
Please provide short complete script next time.
[2001-07-19 08:46:40] [EMAIL PROTECTED]
Fatal error: ht=001262d4 is already destroyed in zend_hash.c:852 in Unknown on line 0
Fatal error: ht=00123ebc is already destroyed in zend_hash.c:519 in Unknown on line 0
Fatal error: ht=00123ebc is already destroyed in zend_hash.c:519 in Unknown on line 0
Fatal error: ht=00123ebc is already destroyed in zend_hash.c:519 in Unknown on line 0
This error appears after writing in a TXT file. But I don't think that the script I've
written can be the source of this bug.
function finsert($Nom_script,$tableau,$texte,$i){
static $fp, $k;
$tableau[$i] .= $texte.\n;
$fp = @fopen ($Nom_script, w);
if (!$fp) return FALSE;
for ($k=0;$kcount($tableau);$k ++ ) fwrite ($fp,$tableau[$k]);
fclose ($fp);
return TRUE;
}
A french developper Xavier
Edit this bug report at http://bugs.php.net/?id=12251edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12289 Updated: Not fully reproducable include-errors
ID: 12289
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4.0.5
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 08:38:51] [EMAIL PROTECTED]
Could you try 4.1.0?
[2001-07-27 06:44:12] [EMAIL PROTECTED]
This didn't solve the problem. As I mentioned before, all include-files are
encapsulated in if(!defined(C)){define(C)..} statements.
I replaced all includes with include_once, and upgradet to 4.0.6, but this didn't
help.
The problems seems someway related to the process getting the request. Its very often
the case that alternating requests result in an error. So every other requets works.
This is even reproducable.
On our live-system, the problem had been solved by setting display_errors = Off
This seems to make things not only invisible, but actually work.
[2001-07-20 15:47:08] [EMAIL PROTECTED]
This is what the include_once function is for. Use that instead and see if that fixes
things for you.
[2001-07-20 14:45:31] [EMAIL PROTECTED]
We encouter include() -problems on a large project. It
makes extensive use of classes and due to the fact that
session-vars need to have the class-definitions before
they can be used, some includes are circular. Of course
all include-files are encapsulated into if(defined(C)
{.. } blocks.
The included files before each weppage have a linecount at
a maximum of 6214.
The errors result in classes not known and thus
declaration of classes extended by them fail. Also
function-declarations sometimes are missing. When using a
while(!function_exists(f))
{ include(f.php); }
this results in timeouts because of endless loops. Of
course _should_ happen, because the constants mentioned
above are all correctly set.
The errors occur not fully predictabel, and normally
disappear when reloading the webpage.
In the apache-error-log appaer the following lines,
although I'm not sure if they are related to the problem:
[Fri Jul 20 16:01:34 2001] [alert] (14)Bad address:
FastCGI: openf() of fcgi_dynamic_mbox (null) failed
[Fri Jul 20 16:01:52 2001] [notice] child pid 13112 exit
signal Segmentation fault (11)
Any suggestions? Or is this project just too large for
PHP4?
./configure --with-apxs=/usr/sbin/apxs --with-gd
--with-curl=/tmp/curl-7.8 --with-oci8=/opt/oracle/OraHome1
--with-gettext=/usr/share --enable-sigchild
--with-dom=/usr/local/lib/
Edit this bug report at http://bugs.php.net/?id=12289edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12315 Updated: Buffering crashes PHP when there is an error with mail function
ID: 12315
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Output Control
Operating System: Win ME
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 04:33:20] [EMAIL PROTECTED]
This report seems to be duplicate.
Does this happen with 4.1.0?
[2001-07-23 07:42:17] [EMAIL PROTECTED]
I don't have an email server in my development computer, so when I turn output
buffering on with ob_start('ob_gzhandler') and try to send an email with mail
(string to, string subject, string message) or die('Error message'), PHP crashes.
This doesn't happen in every script ans doesn't happen at all, when I remove the or
die('Error message') condition.
Edit this bug report at http://bugs.php.net/?id=12315edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12532 Updated: Memory Leak
ID: 12532 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Performance problem Operating System: MacOSX Server PHP Version: 4.0.4 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 19:10:27] [EMAIL PROTECTED] Could you try 4.1.0 see if it help? [2001-08-02 08:52:47] [EMAIL PROTECTED] I'm completely new to this, so I'll try my best. I'm using the installed PHP on OSX Server. I'm doing nothing fancy, a couple include statements. But just recently the web log is filled with these errors. I usually check the logs after the pages hang up or refuse to load. I don't get a parse error, just nothing happens. I must go restart apache to make the page work again. /Users/admin/Projects/ApacheComponents/apache_mod_php-4.3/p hp/Zend/zend_stac k.c(27) : Freeing 0x004B0914 (256 bytes), script=/JLDwebsites/jldinc2/clients.php Last leak repeated 5 times Last leak repeated 2 times /Users/admin/Projects/ApacheComponents/apache_mod_php-4.3/p hp/Zend/zend_stac k.c(27) : Freeing 0x004AF0A4 (256 bytes), script=/JLDwebsites/jldinc2/index.php Last leak repeated 5 times Edit this bug report at http://bugs.php.net/?id=12532edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12634 Updated: Segfaults due to possible memory leak??
ID: 12634 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Reproducible crash Operating System: Linux 2.4 PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 04:13:50] [EMAIL PROTECTED] Status = Feedback [2001-12-12 04:08:45] [EMAIL PROTECTED] Do you still have problems with 4.1.0? Is it ok to be closed? [2001-10-03 14:21:36] [EMAIL PROTECTED] As a follow-up on this bug report .. Just today I installed a recent cvs version (called 4.0.7RC2 in the Debian unstable distribution)... So far the system has been running almost an entire day without a problem .. I noticed in the change log that there were some LDAP memory leak fixes ... that may have been the problem as our site also relies heavily upon ldap .. So far .. So good. [2001-08-19 21:40:28] [EMAIL PROTECTED] Also .. keep in mind my stuff uses OCI-8 (with oracle 8.1.6), so that may be linked (since no one else has reported this problem) ?? [2001-08-19 21:36:48] [EMAIL PROTECTED] No, it appears to be almost random The script names (and line numbers) that appear in the logs are always different. I was able to force the problem for any script by using the apache benchmark utility (ab) and blasting a script with generated hits .. when doing this the seg faults start almost immediately (and again for any php script i point it at).. if this helps 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/?id=12634 Edit this bug report at http://bugs.php.net/?id=12634edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12995 Updated: Failed opening ... in Unknown on line 0
ID: 12995 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: SuSE Linux 7.2 PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:32:07] [EMAIL PROTECTED] Do you still have this problem with 4.1.0? [2001-08-30 07:10:15] [EMAIL PROTECTED] We found out, that this errors only happen when the server runs on a load above 1.0 . [2001-08-28 07:04:30] [EMAIL PROTECTED] I get this warning: Warning: Failed opening 'path_to_a_script' for inclusion (include_path='.:/path/to/a/include/directory') in Unknown on line 0 Sometimes everything works fine, sometimes don't - without changing anything in the php.ini or httpd.conf . A few days ago I updated from php4.0.4 to php4.0.6 and after that the problems begann. All parameters in 4.0.6 are the same than in 4.0.4. Do you need more informations? Bye, Sascha Emondts Edit this bug report at http://bugs.php.net/?id=12995edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13235 Updated: include() fails unpredictable
ID: 13235 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 08:40:15] [EMAIL PROTECTED] Please update this bug report if you could use 4.1.0. [2001-09-10 12:46:59] [EMAIL PROTECTED] Since my Provider upgraded to 4.0.6 some of my scripts don't work as exspected anymore... I use include() with URL's where the URL's are from the same domain. They fail unpredictable: example: www.alstereck.de/aecke32001/ingebericht.phtml With every reload the appearance of the page changes, because the included files change, the rest fails with: Warning: Failed opening 'http://www.alstereck.de/aeckehead1.html' for inclusion (include_path='') in /raid/domains/de/a/alstereck/htdocs/www/aecke32001/ingebericht.phtml on line 3 When I include() via URL a file from a non-local server it works always fine. If I use this script on a different server with a perhaps different configuration (even 4.0.6.) it works fine! working exampl: http://www.ksweb.f2s.com/nochntest.php Conf of trouble server www.alstereck.de/test.php Conf of fine working server http://www.ksweb.f2s.com/test.php rgds Tiemo Edit this bug report at http://bugs.php.net/?id=13235edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13291 Updated: System Load very high
ID: 13291 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Performance problem Operating System: SCO Openserver 5.0.x PHP Version: 4.0CVS-2001-09-13 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 19:12:26] [EMAIL PROTECTED] Could you try PHP 4.1.0 see if it help? [2001-09-13 14:49:06] [EMAIL PROTECTED] current load average: 2.00, 2.03, 2.00 cpuhog indicates load due to system, not user or system version 4.0.7 and later up to 4.0.8 typical load average load average: 0.02 0.02 0.05 apache 1.20 has not been changed etc... have not been changed Edit this bug report at http://bugs.php.net/?id=13291edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13672 Updated: Memory leak
ID: 13672 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Scripting Engine problem Operating System: RH Linux (2.2.16-22) PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 07:16:06] [EMAIL PROTECTED] Do you still have this problem with 4.1.0? [2001-10-15 08:53:52] [EMAIL PROTECTED] Doing mtrace on libphp4.so returns: - 00 Realloc 6161 was never alloc'd - 00 Realloc 6163 was never alloc'd - 00 Realloc 6168 was never alloc'd - 00 Realloc 7007 was never alloc'd - 00 Realloc 7015 was never alloc'd - 00 Realloc 7023 was never alloc'd Memory not freed: - Address Size Caller 000 at I have tried the latest CVS build, but it won't compile with zlib: zlib.c:115: `STANDARD_MODULE_HEADER' undeclared here (not in a function) zlib.c:115: initializer element is not constant zlib.c:115: (near initialization for `php_zlib_module_entry.name') zlib.c:116: warning: initialization from incompatible pointer type zlib.c:117: warning: initialization from incompatible pointer type zlib.c:122: warning: initialization from incompatible pointer type zlib.c:123: `NO_VERSION_YET' undeclared here (not in a function) zlib.c:123: initializer element is not constant zlib.c:123: (near initialization for `php_zlib_module_entry.global_shutdown_func') zlib.c:124: warning: initialization makes integer from pointer without a cast zlib.c:124: warning: initialization makes integer from pointer without a cast zlib.c:124: warning: initialization makes integer from pointer without a cast zlib.c:124: warning: excess elements in struct initializer zlib.c:124: warning: (near initialization for `php_zlib_module_entry') zlib.c:125: warning: excess elements in struct initializer zlib.c:125: warning: (near initialization for `php_zlib_module_entry') make[3]: *** [zlib.lo] Error 1 make[3]: Leaving directory `/usr/local/bang_setup/php4-200110141200/ext/zlib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/bang_setup/php4-200110141200/ext/zlib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/bang_setup/php4-200110141200/ext' make: *** [all-recursive] Error 1 My config line for PHP is: --with-apxs=/usr/local/apache/bin/apxs' '--enable-force-cgi-redirect' '-with-png-dir=/usr/local/bang_setup/libpng-1.0.11/' '--with-zlib-dir=/usr/local/bang_setup/zlib-1.1.3/' '--enable-ftp' '--with-gd=/usr/local/bang_setup/gd-1.8.4' '--with-jpeg-dir=/usr/local/' '--with-mysql=/usr/local' '--enable-gd-imgstrttf' '--with-imap' '--with-ldap=/usr/local' '--enable-gd-native-ttf' '--enable-trans-sid' '--with-mcrypt' Some of our websites have become erratic, to the point where some scripts would sometimes return: Cannot use assign-op operators with overloaded object s nor string offsets on something as simple as $table[$i] .= something; This last problem has been circumvented by $var .= something; $table[$i] = $var; but now rather than the above-mentioned error, the script outputs the letter F. I wish I could be more accurate, but I have no idea why this started happening, but I suspect the memory leak. I haven't been able to come up with a test case, and my script is a little unwieldy. Edit this bug report at http://bugs.php.net/?id=13672edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #13968 Updated: $this reference is bad during __wakeup
ID: 13968
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 14:27:42] [EMAIL PROTECTED]
Thies has made changes to how serialize handles
references. The changes are incorporated in PHP 4.1.0
Upgrading may fix your problem.
[2001-12-12 07:45:46] [EMAIL PROTECTED]
Any update for this bug?
[2001-11-06 22:56:04] [EMAIL PROTECTED]
References to $this are randomly wrong during __wakeup.
I am keeping track of all objects in a global $objs.
global $objs;
$objs[] = $this;
during __wakeup causes $objs[] to gain an element that matches some random OTHER
variable in my script (an integer I was using somewhere, or an array I had somewhere
else)
Unforunately I cannot reproduce this on a simple script, but here is the essence of
what I am doing:
?
$objs = array();
class O {
function __wakeup() {
global $objs;
$objs[] = $this;
}
}
class X extends O {
var $a = 213;
var $b = 'hello';
}
$x = new X();
$y = serialize($x);
$z = unserialize($y);
var_dump($objs);
?
^^ the above script works perfectly, but in a more complex script doing the same
thing, it ends up putting a reference to a totally different variable into $objs.
Edit this bug report at http://bugs.php.net/?id=13968edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14304 Updated: Potential problem with regex...
ID: 14304
Updated by: lobbin
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Regexps related
Operating System: Linux php3-2 2.4.7 #1 Thu Aug 9
PHP Version: 4.0.6
New Comment:
No feedback. Closing.
Previous Comments:
[2001-12-12 01:41:11] [EMAIL PROTECTED]
I cannot reproduce the problem under PHP 4.1.0. Can you
upgrade to this version?
[2001-12-12 01:31:01] [EMAIL PROTECTED]
The problem is there...
I got the first result :
array(10) {
[0]=
string(24) phpdig:ignore_message/
[1]=
string(14) ignore_message
[2]=
...
But on the second, i got nothing but a 'maximum execution time exceeded'.
I traced my code with some echoes and flush(), and it seems that the php engine stays
on the eregi() function.
It not core dump, but Apache goes 100% CPU until the timeout occurs.
[2001-12-11 17:39:59] [EMAIL PROTECTED]
Thanks for the additional information.
I tested the code snippets provided on PHP 4.1.0 - they
all seem to operate as expected. The input of both
snippets (when fed to your original function) returns
'bri/i/td'
The regular expressions provided later seem to work as
well.
The top snippet captures:
array(10) {
[0]=
string(24) phpdig:ignore_message/
[1]=
string(14) ignore_message
[2]=
bool(false)
[3]=
bool(false)
[4]=
bool(false)
[5]=
bool(false)
[6]=
bool(false)
[7]=
bool(false)
[8]=
bool(false)
[9]=
bool(false)
}
...and the bottom snippet captures:
array(10) {
[0]=
string(31) phpdig:ignore_common_message/
[1]=
string(21) ignore_common_message
[2]=
bool(false)
[3]=
bool(false)
[4]=
bool(false)
[5]=
bool(false)
[6]=
bool(false)
[7]=
bool(false)
[8]=
bool(false)
[9]=
bool(false)
}
Is this the output that you get with PHP 4.0.6? Please let
me know!
[2001-12-09 08:08:18] [EMAIL PROTECTED]
Changed bug type to Regexps
[2001-12-09 08:00:37] [EMAIL PROTECTED]
I isolate the bug :
this works :
eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/','briphpdig:ignore_message//i/td',$regs);
this doesn't (php loops) :
eregi('phpdig:([a-z0-9_]*)[[:blank:]]*(src=)*[\']*([a-z0-9./_-]+)*[\']*[[:blank:]]*/','briphpdig:ignore_common_message//i/td',$regs);
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/?id=14304
Edit this bug report at http://bugs.php.net/?id=14304edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14333 Updated: Apache processes consume all CPU
ID: 14333 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Apache related Operating System: RH 6.2 SMP PHP Version: 4.0.6 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 19:40:21] [EMAIL PROTECTED] I also suggest to check RedHat resources to see if there is any known problems with their SMP kernel. There are issues like this for SMP kernel occasionally. [2001-12-12 09:12:31] [EMAIL PROTECTED] Like I asked before, configure/compile PHP without ANY configure options. (only --with-apxs) And updating kernel (and compiling it by yourself) is not bad idea either. [2001-12-08 19:34:26] [EMAIL PROTECTED] This time I compiled PHP with this configuration: CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --prefix=/usr/local \ --with-apache=/root/atb/Apachetoolbox-1.5.45/apache_1.3.22 \ --enable-exif \ --enable-track-vars \ --with-calendar=shared \ --enable-safe-mode \ --enable-magic-quotes \ --enable-trans-sid \ --enable-wddx \ --enable-ftp \ --without-mysql \ --without-ldap \ Apache was just the same as before. However, I am still getting the same runaway process problem. Any other ideas or suggestions for me to try? [2001-12-08 19:19:42] [EMAIL PROTECTED] Thanks for the help. I've installed the MySQL-shared RPM and now have /usr/lib/libmysqlclient.so. Also, I've recompiled with a minimal PHP configuration: CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --prefix=/usr/local \ --with-apache=/root/atb/Apachetoolbox-1.5.45/apache_1.3.22 \ --enable-exif \ --enable-track-vars \ --with-calendar=shared \ --enable-safe-mode \ --enable-magic-quotes \ --enable-trans-sid \ --enable-wddx \ --enable-ftp \ --with-mysql=/usr \ --with-ldap \ My Apache configuration is also very minimal. The only things I have included are the basics plus mod_ssl and mod_php: export CFLAGS= export LIBS= export INCLUDES= ./configure --prefix=/usr/local/apache \ --enable-suexec \ --suexec-caller=nobody \ --suexec-docroot=/home \ --suexec-logfile=/var/log/httpd/cgi.log \ --suexec-uidmin=500 \ --suexec-gidmin=500 \ --suexec-safepath=/usr/local/bin:/usr/bin:/bin \ --enable-module=so \ --enable-module=access \ --disable-module=auth_db \ --disable-module=digest \ --enable-module=imap \ --enable-module=mime \ --enable-module=setenvif \ --disable-module=usertrack \ --enable-module=auth \ --disable-module=cern_meta \ --disable-module=expires \ --enable-module=log_config \ --disable-module=proxy \ --disable-module=vhost_alias \ --disable-module=auth_anon \ --enable-module=cgi \ --disable-module=headers \ --disable-module=log_referer \ --disable-module=rewrite \ --enable-module=userdir \ --enable-module=asis \ --enable-module=autoindex \ --disable-module=example \ --disable-module=log_agent \ --enable-module=negotiation \ --enable-module=status \ --enable-module=actions \ --disable-module=auth_dbm \ --enable-module=dir \ --enable-module=include \ --disable-module=mime_magic \ --disable-module=unique_id \ --enable-module=alias \ --disable-module=auth_digest \ --enable-module=env \ --disable-module=info \ --disable-module=mmap_static \ --disable-module=speling \ --enable-module=ssl \ --activate-module=src/modules/php4/libphp4.a \ However, as within a minute of installing and running this Apache, I start getting runaway httpd processes (94% CPU usage). It doesn't look like the libmysqlclient.so is the issue. I'm going to try installing with the --without-mysql option to see if that makes a difference. [2001-12-08 10:14:24] [EMAIL PROTECTED] The RPm is called MySQL-shared BTW. 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/?id=14333 Edit this bug report at http://bugs.php.net/?id=14333edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14402 Updated: round() outputs too many digits
ID: 14402 Updated by: lobbin Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Closed Bug Type: Math related Operating System: Linux-2.4.14 (Slackware 8.0) PHP Version: 4.1.0RC5 New Comment: No feedback. Closing. Previous Comments: [2001-12-12 11:30:26] [EMAIL PROTECTED] can't reproduce either with PHP 4.2.0-dev. Try the latest CVS snapshot: http://snaps.php.net/ --Jani [2001-12-11 16:16:45] [EMAIL PROTECTED] weird, this works fine for me (PHP cgi). Derick [2001-12-10 09:51:40] [EMAIL PROTECTED] Changed distro/php version for clarity. [2001-12-10 09:47:24] [EMAIL PROTECTED] ? $int = 0.293847289472983; echo $int .\n; echo round($int,2) . \n; echo round((int)$int,2) . \n; echo round((float)$int,2) . \n; echo round((double)$int,2) . \n; ? outputs on php 4.0.6: 0.29384728947298 0.29 0 0.29 0.29 however, using php 4.1.0, it outputs: 0.29384728947298299761570206101168878376483917236328125 0.289980015985556747182272374629974365234375 0 0.289980015985556747182272374629974365234375 0.289980015985556747182272374629974365234375 is this a bug, or a new 'feature' ? Closest report I found was http://marc.theaimsgroup.com/?l=php-devm=100750316722784w=2 on the php-dev mailinglist. Edit this bug report at http://bugs.php.net/?id=14402edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] PECL (was PHP 5)
On Wed, 02 Jan 2002 20:39:44 +0200, Andi Gutmans wrote: However, if PECL doesn't become everything we hoped for within the next few months (possible) I don't think it should stop PHP 5. We could always have 5.1. At least we could have PHP 6 right after 5 :-). Anyway, that's not too important right now. We still haven't heard from anyone what work has been done on PECL. Currently there has not been much work on the PECL installer. Our current aim is to provide a solid installation procedure for PEAR components. Installing PECL extensions is a bit trickier IMO: You have to consider ./configure files, build processes, plugging configuration directives in php.ini etc. I think without a lot of work done by many of us here on php-dev it'll probably not gain enough momentum. +1. I suggest we move PECL either to its own mailing list or to php-dev. +1 for it's own mailing list. Additionally we could perhaps set up an own CVS module for PECL. (Currently it resides in /pear/PECL.) Guys? - Martin -- Martin Jansen, [EMAIL PROTECTED] http://www.martin-jansen.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14807 Updated: core dump
ID: 14807
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System:
PHP Version: 4.1.0
New Comment:
I am using it in CGI mode, and this is some info that might be useful to you:
bash$ cat /proc/version
Linux version 2.2.20 (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1
SMP Fri Nov 9 09:25:22 EST 2001
phpinfo()
PHP Version 4.1.0
System Linux host name removed 2.2.20 #1 SMP Fri Nov 9 09:25:22 EST 2001 i686
unknown
Build DateDec 24 2001
Configure Command './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-xml'
'--with-curl' '--with-swf=/usr/local/flash' '--enable-ftp' '--with-gd=../gd-1.8.4'
'--with-jpeg-dir=/usr/local' '--with-xpm-dir=/usr/X11R6' '--with-png-dir=/usr'
'--with-imap=../imap-2001.BETA.SNAP-0105220031' '--with-ming=../ming-0.1.1'
'--enable-magic-quotes' '--with-mysql' '--enable-safe-mode' '--enable-track-vars'
'--with-ttf' '--enable-versioning' '--with-zlib'
Server API CGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /usr/local/Zend/etc/php.ini
ZEND_DEBUG disabled
Thread Safety disabled
If you need anything else, just let me know.
Previous Comments:
[2002-01-02 13:46:02] [EMAIL PROTECTED]
at least for me it doesn't (FreeBSD 4.4 PHP 4.1.0)
can you provide more Information about you environmation (OS, configure options e.g.)
?
[2002-01-02 13:39:24] [EMAIL PROTECTED]
Running the following always causes a core dump:
?php
$arr = array (
1 = array (0,0,0,0,0),
2 = array (0,0,0,0,0),
3 = array (0,0,0,0,0),
4 = array (0,0,0,0,0),
5 = array (0,0,0,0,0)
);
print_r($arr);
echo br\n\nbr\n\n;
$str = serialize($arr);
echo serializedbr\n, $str, brbr\n\n;
function hex2bin($data) {
$len = strlen($data);
return pack(H . $len, $data);
}
$enc = urlencode($str);
echo urlencodedbr, $enc, brbr\n\n;
$gzd = gzcompress($enc);
//echo gzcompressed (urlencoded)br, $gzd, brbr\n\n;
$b64 = base64_encode($gzd);
echo base64_encodedbr, $b64, brbr\n\n;
$b2h = bin2hex($enc);
echo bin2hex (urlencoded)br, $b2h, brbr\n\n;
$binary = base_convert($b2h, 16, 2);
echo $binary, brbr\n\n;
$conv = base_convert($binary, 2, 16);
echo $conv, brbr\n\n;
$h2b = hex2bin($conv);
echo $h2b, brbr\n\n;
$md = md5($str);
echo md5br, $md, brbr\n;
?
Edit this bug report at http://bugs.php.net/?id=14807edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
Hello, Martin Jansen wrote: On Wed, 2 Jan 2002 14:43:39 +0100, Edin Kadribasic wrote: The build process should be altered so that the standalone interpreter (cgi sapi) is always built so the traditional make make install installs /usr/bin/php no matter what sapi module was chosen. I'm +1 on this, even though I think that PHP isn't very well suited for shell jobs in comparison to Bash or Perl. That is a major misconception. Who told you that is probably a batter bash or Perl programmer that PHP. The suitability of PHP for Web or shell jobs depends on your skills at programming with PHP. Just an example of the complexity of tasks that I use PHP from shell for instance in the PHP Classes repository: - Installation and maintenance of the site database schema. This is done with Metabase. It only uses PHP code. No separate SQL scripts. All queries are executed using PHP commands. You can't do this with Perl, because there is no Metabase for Perl. - Notification message processing. A cron script starts a deamon that keeps polling the notification message queue. It executes a query to extract the recipients list of the notification message and dispatches a message that is used for an outside message delivery system. - The message delivery system is also done in PHP although run from separate server. It fetches the notification message and puts in a qmail queue for delivery to many thousands of users. - Bounced message handling. A daemon PHP script started from cron pools the queue of bounced messages. It analyzes each message to extract the exact address of the bouncing subscriber. Than it goes through the site database and flags the accounts with the specified address so next notification message is not sent to that subscriber to avoid further bounces. - Log archiving. This is simple, just copy and compress the log file of the site for offline processing later with Webalizer. - Updating the search engine database. This is done with some wrapper classes that call htdig programs to traverse the site pages daily and update the search engine database. There are plans for doing more things like this all in PHP, like processing unsubscribe requests sent via e-mail. Anyway, the point is that if you are good at PHP to develop Web applications, you can also make good of it using it for running scripts from the shell. The real advantage of using PHP both ways is that you get to reuse much code. In the case of this site, I used exactly the same classes for processing stuff that is the database that is needed either for showing Web content and for doing background processing. I could certainly not make it better using Perl or bash because like most PHP users, I am more skilled and productive using PHP than with Perl or bash. Always building the CGI version would also help the PEAR command line installer a lot since it currently needs a PHP binary to be executed. One of these days, you will realize how wonderful and appropriate is to use PHP to run things like Metabase for database installation and maintenance. Regards, Manuel Lemos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] SHMOP Module Patch
Attached to this message is a patch to php's shmop extension, it fixes the following: - shmop_open has a new flag for read/write access, 'w' (bug #10530, 10656) - shmop_open has a new flag for create only 'n' (bug #10530, 10656) - eliminated a segfault when trying to write to a SHM_RDONLY segment (bug #14784) - eliminated a segfault when an invalid flag which starts with 'a' or 'c' is passed (bug #14784) - updated creators' email addresses - changed error messages to say shmop_* instead of shm* to correspond with new shmop_* function names Could someone with a CVS access please implement the diff and close the 3 bug reports I've outlined. I will submit a patch to the shmop's php documentation shortly. I've tested this diff on PHP 4.0.6,4.1.0 4.1.1 it seems to work fine on all of them. On 4.0.6 patch complains a little but it works fine non the less. cd php4; patch -p0 shmop.diff diff -urN ext/shmop/ChangeLog ext/shmop/ChangeLog --- ext/shmop/ChangeLog Wed Dec 31 19:00:00 1969 +++ ext/shmop/ChangeLog Wed Jan 2 13:15:34 2002 @@ -0,0 +1,7 @@ +Jan, 2, 2002 + +- shmop_open has a new flag for read/write access, 'w' (bug #10530, 10656) +- shmop_open has a new flag for create only 'n' (bug #10530, 10656) +- eliminated a segfault when trying to write to a SHM_RDONLY segment (bug #14784) +- eliminated a segfault when an invalid flag which starts with 'a' or 'c' is passed (bug #14784) +- updated creators' email addresses +- changed error messages to say shmop_* instead of shm* to correspond with new shmop_* function names diff -urN ext/shmop/README ext/shmop/README --- ext/shmop/README Tue Oct 3 17:56:21 2000 +++ ext/shmop/README Wed Jan 2 13:57:23 2002 @@ -1,31 +1,35 @@ -last update sept 3, 2000 ([EMAIL PROTECTED][EMAIL PROTECTED]) +last update Jan 2, 2002 ([EMAIL PROTECTED][EMAIL PROTECTED]) Shared Memory Operations Extension to PHP4 - While developing a search deamon we needed the php based front end - to communicate the deamon via SHM. Now, PHP already had a shared memory + While developing a search deamon we needed a php based front end + to communicate the deamon via SHM. PHP already had a shared memory extention (sysvshm) written by Christian Cartus [EMAIL PROTECTED], - unfortunatly this extention was designed with PHP only in mind, and + unfortunatly this extention was designed with PHP only in mind and offers high level features which are extremly bothersome for basic SHM - we had in mind. After spending a day trying to reverse engeener figure + we had in mind. After spending a day trying to reverse engineer and figure out the format of sysvshm we decided that it would be much easier to add our own extention to php for simple SHM operations, we were right :)). the functions are: -int shm_open(int key, string flags, int mode, int size) +int shmop_open(int key, string flags, int mode, int size) key - the key of/for the shared memory block - flags - 2 flags are avalible -a for access (sets IPC_EXCL) -c for create (sets IPC_CREATE) + flags - 3 flags are avalible +a for read only access (sets SHM_RDONLY) +w for read write access +c create or open an existing segment (sets IPC_CREATE) +n create a new segment and fail if one already exists under same name (sets IPC_CREATE|IPC_EXCL) +(the n flag is mostly useful for security perpouses, so that you don't end up opening a faked segment +if someone guesses your key) mode - acsess mode same as for a file (0644) for example size - size of the block in bytes returns an indentifier -char shm_read(int shmid, int start, int count) +char shmop_read(int shmid, int start, int count) shmid - shmid from which to read start - offset from which to start reading @@ -33,7 +37,7 @@ returns the data read -int shm_write(int shmid, string data, int offset) +int shmop_write(int shmid, string data, int offset) shmid - shmid from which to read data - string to put into shared memory @@ -41,14 +45,14 @@ returns bytes written -int shm_size(int shmid) +int shmop_size(int shmid) shmid - shmid for which to return the size returns the size in bytes of the shm segment -int shm_delete(int shmid) +int shmop_delete(int shmid) marks the segment for deletion, the segment will be deleted when all processes mapping it will detach @@ -56,7 +60,7 @@ returns 1 if all ok, zero on failure -int shm_close(int shmid) +int shmop_close(int shmid) shmid - shmid which to close diff -urN ext/shmop/php_shmop.h ext/shmop/php_shmop.h --- ext/shmop/php_shmop.h Mon Sep 17 09:43:11 2001 +++ ext/shmop/php_shmop.h Wed Jan 2 13:06:18 2002 @@ -12,8 +12,8 @@ | obtain it through the world-wide-web, please send a note to | | [EMAIL PROTECTED] so we can mail you a copy immediately. | +--+ - | Authors: Slava Poliakov ([EMAIL PROTECTED])
Re: [PHP-DEV] Re: [PEAR-DEV] PECL (was PHP 5)
On Wed, Jan 02, 2002 at 08:09:10PM +0100, Martin Jansen wrote: I suggest we move PECL either to its own mailing list or to php-dev. +1 for it's own mailing list. Additionally we could perhaps set up an own CVS module for PECL. (Currently it resides in /pear/PECL.) Guys? I think I agree on both points ([EMAIL PROTECTED] and /PECL). -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14807 Updated: core dump
Hello jan,
I have 'segmentation' to with this code on Linix 2.4.16 php 4.1.1
CC=gcc2.95.3 \
CXX=gcc2.95.3 \
./configure \
--prefix=/usr/local/php \
--with-config-file-path=/usr/local/php/etc \
--enable-track-vars \
--enable-magic-quotes \
--enable-safe-mode \
--enable-memory-limit \
--enable-sysvshm \
--enable-sysvsem \
--enable-shmop \
--enable-sockets \
--enable-wddx \
--enable-xslt \
--enable-ctype \
--enable-bcmath \
--enable-mailparse \
--enable-ftp \
--with-gd \
--with-jpeg-dir \
--with-png-dir \
--with-ttf \
--with-t1lib \
--with-mysql=/usr/local/mysql \
--with-openssl=/usr/local/ssl \
--with-epipe \
--with-mcrypt \
--with-mhash \
--with-zlib \
--with-mm \
--with-xmlrpc \
--with-iconv \
--with-curl \
--with-bz2 \
--with-gmp \
--with-ldap \
--with-xml \
--with-zip \
--with-gettext \
--with-dom \
--with-xslt-sablot \
$@
(gdb) bt
0x0806 in _php_math_zvaltobase (arg=0xbfffdfc0, base=2) at math.c:841
841 *ptr = digits[digit];
(gdb) bt
#0 0x0806 in _php_math_zvaltobase (arg=0xbfffdfc0, base=2) at math.c:841
#1 0x080ab5b4 in zif_base_convert (ht=3, return_value=0x831b35c, this_ptr=0x0,
return_value_used=1) at math.c:1005
#2 0x081a468a in execute (op_array=0x8318d24) at ./zend_execute.c:1590
#3 0x080deab9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814
#4 0x08079a41 in php_execute_script (primary_file=0xb930) at main.c:1307
#5 0x0807414c in main (argc=3, argv=0xb9a4) at cgi_main.c:738
#6 0x405349cb in __libc_start_main (main=0x80737b4 main, argc=3, argv=0xb9a4,
init=0x80705f8 _init,
fini=0x81fcf00 _fini, rtld_fini=0x4000aea0 _dl_fini, stack_end=0xb99c) at
../sysdeps/generic/libc-start.c:92
jpn ID: 14807
jpn Updated by: jan
jpn Reported By: [EMAIL PROTECTED]
jpn Status: Open
jpn Bug Type: Unknown/Other Function
jpn Operating System:
jpn PHP Version: 4.1.0
jpn New Comment:
jpn at least for me it doesn't (FreeBSD 4.4 PHP 4.1.0)
jpn can you provide more Information about you environmation (OS, configure options
e.g.) ?
jpn Previous Comments:
jpn
jpn [2002-01-02 13:39:24] [EMAIL PROTECTED]
jpn Running the following always causes a core dump:
jpn ?php
jpn $arr = array (
jpn 1 = array (0,0,0,0,0),
jpn 2 = array (0,0,0,0,0),
jpn 3 = array (0,0,0,0,0),
jpn 4 = array (0,0,0,0,0),
jpn 5 = array (0,0,0,0,0)
jpn );
jpn print_r($arr);
jpn echo br\n\nbr\n\n;
jpn $str = serialize($arr);
jpn echo serializedbr\n, $str, brbr\n\n;
jpn function hex2bin($data) {
jpn $len = strlen($data);
jpn return pack(H . $len, $data);
jpn }
jpn $enc = urlencode($str);
jpn echo urlencodedbr, $enc, brbr\n\n;
jpn $gzd = gzcompress($enc);
jpn //echo gzcompressed (urlencoded)br, $gzd, brbr\n\n;
jpn $b64 = base64_encode($gzd);
jpn echo base64_encodedbr, $b64, brbr\n\n;
jpn $b2h = bin2hex($enc);
jpn echo bin2hex (urlencoded)br, $b2h, brbr\n\n;
jpn $binary = base_convert($b2h, 16, 2);
jpn echo $binary, brbr\n\n;
jpn $conv = base_convert($binary, 2, 16);
jpn echo $conv, brbr\n\n;
jpn $h2b = hex2bin($conv);
jpn echo $h2b, brbr\n\n;
jpn $md = md5($str);
jpn echo md5br, $md, brbr\n;
?
jpn
jpn Edit this bug report at http://bugs.php.net/?id=14807edit=1
Best regards,
Andrew Sitnikov
e-mail : [EMAIL PROTECTED]
GSM: (+372) 56491109
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14805 Updated: array_unique works opposed to the manual
ID: 14805
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Operating System: MS Windows 98
PHP Version: 4.0.6
New Comment:
I forgot to mention that there may be something wrong with
array_unique itself. There are three values of 3 considered equal in the example
above:
2 = 3(string), 4 = 3(int), 5 = 3 (string)
[manual]
Two elements are considered equal if and only if (string)
$elem1 === (string) $elem2. In words: when the string
representation is the same.
Why does array_unique use the index 4 in this case?
(It's neither the first nor the latest key of value 3)
Previous Comments:
[2002-01-02 12:48:29] [EMAIL PROTECTED]
The manual (recent version from cvs) states that :
array_unique() will keep the first key encountered for every value, and ignore all
following keys.
I've tested the two examples in this page and I've found
this statement is not true.
?php
$input = array (4,4,3,4,3,3);
$result = array_unique ($input);
var_dump($result);
?
output: /* PHP 4.0.6 Win'98 PWS */
array(2) {
[3]=
int(4)
[4]=
int(3)
}
but the manual says it should print:
array(2) {
[0]=
int(4)
[1]=
string(1) 3
}
As you can recognize the latest keys are preserved
for both value 4 and 3.
Edit this bug report at http://bugs.php.net/?id=14805edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 5
Creating a CLI sapi module w/o all of the CGI crap is extremely easy. What might be more challenging is fixing the build so that it always builds the cli. Then again I don't really know because I don't know the whole build system too well. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PEAR-DEV] PECL (was PHP 5)
I suggest keeping it on php-dev. All of the build stuff has been done by php-dev in the past as build/PECL related discussions really are php-dev. It also means that php-dev won't be allowed to cut themselves out of what's happening with PECL and it won't lead to some php-dev ppl who don't subscribe to PECL to be surprised in a few months time :) Andi At 02:16 PM 1/2/2002 -0500, Jon Parise wrote: On Wed, Jan 02, 2002 at 08:09:10PM +0100, Martin Jansen wrote: I suggest we move PECL either to its own mailing list or to php-dev. +1 for it's own mailing list. Additionally we could perhaps set up an own CVS module for PECL. (Currently it resides in /pear/PECL.) Guys? I think I agree on both points ([EMAIL PROTECTED] and /PECL). -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
