[PHP-DEV] how to find a memory corruption in php ?
Hi all, I get an error with my program: Fatal error: Allowed memory size of 134217728 bytes exhausted at /home/courtois/php-5.3.6/Zend/zend_execute.h:163 (tried to allocate 261900 bytes) in /var/www/dev4.sociatomdev.com/chroot/htdocs/templeet/fetch.php on line 580 - The same error occurs with any of php 5.3 versions tested. With 5.2 it's ok. - I know the error message is wrong. The program does not consume much memory. - If i change some lines in my php code like adding trace messages it sometimes work sometimes no (but constant result for same php code) I will not submit the bug since it's hard to reproduce unless being in the exact same configuration as me. I used to be an experienced C programmer (>30 lines written) but almost nothing for the last 15 years. My questions: - is there any document somewhere to read before hunting a bug in php ? - are there any build/compile options other than --enable-debug ? - how should I proceed to debug when php is called via fastcgi ? My configuration: debian squeeze i386 32bits Thanks, Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to find a memory corruption in php ?
Le 01/04/2011 15:20, Pierre Joye a écrit : > hi, > > In php 5.3+ the memory limit default is 256MB, not 128MB. 5.3 does not > necessary use more memory but actually uses and reports its usage more > efficiently. I would suggest to use this default value and try again. the exact same bug occurs whatever the limit set. Anyway, when it works it's ok with 6MB so it's not a matter of quantity obviously. > About detecting leaks and memory corruptions, valgrind is a good tool > to begin with. It take a look at it. Thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to find a memory corruption in php ?
Le 01/04/2011 18:46, Pascal COURTOIS a écrit : > Le 01/04/2011 15:20, Pierre Joye a écrit : >> hi, >> >> In php 5.3+ the memory limit default is 256MB, not 128MB. 5.3 does not >> necessary use more memory but actually uses and reports its usage more >> efficiently. I would suggest to use this default value and try again. > > the exact same bug occurs whatever the limit set. Anyway, when it works > it's ok with 6MB so it's not a matter of quantity obviously. further investigations show that my program uses around 3Mbytes of memory BUT real_usage memory increases constantly which could suggest either a bug in the zend memory manager or a very special condition in my php program making the memory manager unable to use holes in its system allocated memory. the use of gc_collect_cycles() as suggested privately does not make any difference. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to find a memory corruption in php ?
Le 03/04/2011 12:46, Pierre Joye a écrit : > Try to run it by disabling the zend memory manager: with zend memory manager disabled the program works fine. I'll try with valgrind as you suggest -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to find a memory corruption in php ?
Le 03/04/2011 12:46, Pierre Joye a écrit : > USE_ZEND_ALLOC=0 valgrind php --leak-check=full sapi/cli/php ... (or > httpd if you use apache or only reproducible there) > > That will tell you if there are actual leaks. it IS leaking: ==9772== Memcheck, a memory error detector ==9772== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==9772== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==9772== Command: /home/courtois/php-5.3.6/sapi/cgi/php-cgi ==9772== /var/www/dev4.sociatomdev.com/chroot/htdocs/templeet/fetch.php(215) : Warning - Cannot modify header information - headers already sent by (output started at /var/www/dev4.sociatomdev.com/chroot/htdocs/templeet/fetch.php:580) ==9772== ==9772== HEAP SUMMARY: ==9772== in use at exit: 60,706 bytes in 1,591 blocks ==9772== total heap usage: 1,822,108 allocs, 1,820,517 frees, 303,318,634 bytes allocated ==9772== ==9772== 21 (20 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 136 ==9772==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==9772==by 0x840F2D1: _emalloc (zend_alloc.c:2370) ==9772==by 0x845A07A: zend_assign_to_variable_reference (zend_execute.c:413) ==9772==by 0x84E558E: ZEND_ASSIGN_REF_SPEC_CV_VAR_HANDLER (zend_vm_execute.h:27383) ==9772==by 0x845CE46: execute (zend_vm_execute.h:107) ==9772==by 0x8430173: zend_execute_scripts (zend.c:1194) ==9772==by 0x83C70C8: php_execute_script (main.c:2268) ==9772==by 0x84F4A3A: main (cgi_main.c:2109) ==9772== ==9772== 21 (20 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 28 of 136 ==9772==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==9772==by 0x840F2D1: _emalloc (zend_alloc.c:2370) ==9772==by 0x845B3E4: zend_assign_to_variable (zend_execute.c:714) ==9772==by 0x84D40A3: ZEND_ASSIGN_SPEC_CV_CONST_HANDLER (zend_vm_execute.h:24059) ==9772==by 0x845CE46: execute (zend_vm_execute.h:107) ==9772==by 0x8430173: zend_execute_scripts (zend.c:1194) ==9772==by 0x83C70C8: php_execute_script (main.c:2268) ==9772==by 0x84F4A3A: main (cgi_main.c:2109) ==9772== ==9772== 39 bytes in 3 blocks are possibly lost in loss record 46 of 136 ==9772==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==9772==by 0x840F2D1: _emalloc (zend_alloc.c:2370) ==9772==by 0x840F685: _estrndup (zend_alloc.c:2525) ==9772==by 0x83F588F: zend_scan_escape_string (zend_language_scanner.l:740) ==9772==by 0x83F74AC: lex_scan (zend_language_scanner.l:2037) ==9772==by 0x841CEEE: zendlex (zend_compile.c:4954) ==9772==by 0x83EF882: zendparse (zend_language_parser.c:3280) ==9772==by 0x83F517F: compile_file (zend_language_scanner.l:364) ==9772==by 0x8265A34: phar_compile_file (phar.c:3393) ==9772==by 0x83AEE26: xc_check_initial_compile_file (xcache.c:929) ==9772==by 0x84300D3: zend_execute_scripts (zend.c:1186) ==9772==by 0x83C70C8: php_execute_script (main.c:2268) ==9772== ==9772== 40 bytes in 2 blocks are definitely lost in loss record 54 of 136 ==9772==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==9772==by 0x840F2D1: _emalloc (zend_alloc.c:2370) ==9772==by 0x84CCA39: zend_send_by_var_helper_SPEC_CV (zend_vm_execute.h:22135) ==9772==by 0x84CD161: ZEND_SEND_VAR_SPEC_CV_HANDLER (zend_vm_execute.h:22242) ==9772==by 0x845CE46: execute (zend_vm_execute.h:107) ==9772==by 0x8430173: zend_execute_scripts (zend.c:1194) ==9772==by 0x83C70C8: php_execute_script (main.c:2268) ==9772==by 0x84F4A3A: main (cgi_main.c:2109) ==9772== ==9772== 54 (20 direct, 34 indirect) bytes in 1 blocks are definitely lost in loss record 65 of 136 ==9772==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==9772==by 0x840F2D1: _emalloc (zend_alloc.c:2370) ==9772==by 0x845AAC6: zend_assign_to_object (zend_execute.c:558) ==9772==by 0x84D38B9: ZEND_ASSIGN_OBJ_SPEC_CV_CONST_HANDLER (zend_vm_execute.h:23966) ==9772==by 0x845CE46: execute (zend_vm_execute.h:107) ==9772==by 0x8430173: zend_execute_scripts (zend.c:1194) ==9772==by 0x83C70C8: php_execute_script (main.c:2268) ==9772==by 0x84F4A3A: main (cgi_main.c:2109) ==9772== ==9772== 75 bytes in 12 blocks are possibly lost in loss record 73 of 136 ==9772==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==9772==by 0x840F2D1: _emalloc (zend_alloc.c:2370) ==9772==by 0x840F685: _estrndup (zend_alloc.c:2525) ==9772==by 0x83F588F: zend_scan_escape_string (zend_language_scanner.l:740) ==9772==by 0x83F9834: lex_scan (zend_language_scanner.l:1870) ==9772==by 0x841CEEE: zendlex (zend_compile.c:4954) ==9772==by 0x83EF882: zendparse (zend_language_parser.c:3280) ==9772==by 0x83F517F: compile_file (zend_language_scanner.l:364) ==9772==by 0x8265A34: phar_compile_file (phar.c:3393) ==9772==by 0x83AEE26: xc_check_initial_compile_file (xcache.c:929) ==9772==by 0x84300D3: zend_execute_scripts (zend.c:1186) ==9772==by 0x83C
Re: [PHP-DEV] patch review
Le 03/04/2011 13:30, Peter Beverloo a écrit : > The parsing change you are proposing is invalid per RFC 1738. RFC 1738 has been obsoleted by RFC 3986 http://tools.ietf.org/html/rfc3986 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to find a memory corruption in php ?
Le 03/04/2011 15:46, Patrick ALLAERT a écrit : > Sounds like "now" is a good time to fill in a bug report at > http://bugs.php.net/ :) The trouble is I don't know how to fill in such bug report. It happens with my template engine which is thousands of lines of PHP. The template engine has been used since 2003 and the bug appears with one single template which has nothing particular. I guess if I make a bug report with all instructions to reproduce the bug no one will ever look at it because it means installing the framework. Ok, the installer does the job in 5 seconds but knowing the number of open tickets in PHP, if I was a zend developper I'm not sure I would look in priority in a bug which is hard to reproduce. :-( What do you think ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to find a memory corruption in php ?
Le 03/04/2011 20:37, Pierre Joye a écrit : > post it with the necessary steps to reproduce it. We may try to reduce > the code to the minimal we need to get the leak (I remember someone > having a tool for that) ok, thanks: http://bugs.php.net/bug.php?id=54460 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proposed access modifier "silent" ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Le 11/04/2011 19:17, Michael Morris a écrit : > But don't ask the engine to be rewritten to encourage bad coding practices > which failing to properly initialize variables is a prime example of. It's > this sort of thinking that got register_globals and magic_quotes put into > the language no doubt. In the long run it's an extremely bad idea and needs > to be avoided. +1 Use APL if PHP is too verbose for you (good luck :-) ) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] annotations again
Le 10/05/2011 07:46, Lester Caine a écrit : > The existing tools had been working well, but nowadays things are simply > becoming a mess ... > I agree. Why not fixing the several hundreds of bugs in PHP before just even thinking about adding new features ??? I much respect people using my programs thus for my projects I just forbid myself to release any new version which is not bug free as far as I know. It's getting harder and harder to make my php programs work because of memory leaks/corruptions :-( YMMV -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
Le 29/05/2011 07:05, Gwynne Raskind a écrit : > On May 28, 2011, at 10:55 PM, Martin Scotta wrote: >> I really dont like to move away from PHP, but compared to others... it's >> just a template language with steroids. >> >> and please dont get me wrong, I love PHP, it's is still my favourite but... > > > This has been exactly my experience when trying to use PHP in any meaningful > way. For example, trying to use PHP as a network server: > why not using a language designed for your needs ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fwd: What's up with Quercus?
Le 29/05/2011 09:41, Gwynne Raskind a écrit : > The balance between rapid development, learning curve, and usability. > One line in Python or PHP or even C# can equate to thousands in C. no doubt > Python or Java might be a better match for what I'm doing, sure > but then > there's the question of putting in the time to become fluent with > them and their libraries, and there is a time constraint. unfortunately, time is (almost) always a constraint for everyone :-( > PHP has all > of these issues, but 1) I know the language and how to cope with the > issues it does have, why not taking some of your time to be at ease with python or whatever instead of requesting valuable core team time to program the things you need ? > and 2) once those issues are coped with, it > works better than anything else I know well enough to use now. There are very few specific pitfalls with PHP language itself since it's very intuitive for any experienced programmer. The only real issues are implementation bugs has some exists, more or less, in any language/program. being at ease with python is *much* simpler than dealing with threads for example. It looks you have enough programming experience to handle threads then it's likely that you can become very good with most high level interpreted language in a matter of days (if "interpreted languages" still means something nowadays, but that's another story). my 2 cents -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 04:36, dukeofgaming a écrit : > Hi, > > I think that —in any context— the "if it aint broke don't fix it" is a very > depressing attitude to have, and a very wrong one in any open source > community. What I feel depressing is the urge of the PHP core team to fix working features instead of focusing on the 1800 open bug tickets. On every PHP project I work on I had to find workarounds because PHP crashes. Behaviour bugs (feature not working as intented) are annoying but memory leaks and memory corruptions are just a no no no in production environnement. The only way to call PHP when its memory leaks and get corrupted is to call it via CGI which is much too slow for a production server. What I need is a very stable language on which I can rely and I'm very sad to to say PHP is getting worse and worse on that point of view versions after versions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 07:23, Stas Malyshev a écrit : > Hi! > >> On every PHP project I work on I had to find workarounds because >> PHP crashes. Behaviour bugs (feature not working as intended) are >> annoying but memory leaks and memory corruptions are just a no no >> no in production environment. The only way > > A key to fixing memory corruption is providing good bug reports - > with backtraces, valgrind reports, etc. If you have such reports and > nothing happens to them - you may want to try to raise the profile of > bug reports that are bothering you by mentioning them on the list and > calling for volonteers to fix them. Usually if bug is in frequently > used module and reproduceable, there would be somebody who can fix > it. what I did every single time. Among all my bug reports I had one answer from decoder-...@own-hero.net (thanks to him) who reduced the test case for a memory leak (bug 54460). I'm not talking about bugs in modules but bugs in *core* which can be reproduced with few lines of *core* PHP. >> What I need is a very stable language on which I can rely and I'm >> very sad to to say PHP is getting worse and worse on that point of >> view versions after versions. > > I can not contradict your experience, it is what it is, but my > experience for years working with PHP was exactly the opposite. To tell you the truth, I've been asked to rewrite the framework I did in Ruby because of these problems. I'm of course very reluctant to go that way but in the end I may have no choice :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:01, dukeofgaming a écrit : > Sorry if the question is dumb, but, how many core developers does PHP have?, > how many in total (including non-core contributors)?. That's not the point. Whatever the project is, every developer should fix existing bugs before even thinking about improving. That's the way I do and that's why there is no bug I'm aware in my programs. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:10, Stas Malyshev a écrit : > Hi! > >> what I did every single time. Among all my bug reports I had one >> answer from decoder-...@own-hero.net (thanks to him) who reduced >> the test case for a memory leak (bug 54460). I'm not talking about >> bugs in modules but bugs in *core* which can be reproduced with few >> lines of *core* PHP. > > I am reading the list pretty closely and I don't remember any emails > from you raising the question of reproducible corruption bugs > recently, except indeed for 54460 which seems to be a memory leak, > though presence of xcache in the trace suggests it may not even be a > PHP bug. It talks about bug in a template engine containing thousands > of lines. This is pretty hard work to debug something starting with > huge unknown code, so no wonder nobody got to it yet. PHP is a > volunteer project, and it's not easy to find volunteers to dig into > thousand lines of unknown code to find a bug that may not even be > there. It's quite a hard work. as I said earlier, test case was reduced to: as you can see there's nothing but PHP core instructions in that code. > I must have missed other ones. But if they are still reproducible in > 5.4 and you have reproducing code, you're welcome to share on the > list. Unfortunately, bugs.php.net seems to be down, but once it gets > up we could look into it and see if we can fix any. for memory leaks if the bug is fixed it will not happen again but for memory corruption it's something totaly different. The fact that a bug disapears doesn't mean in any way it has been fixed. > As I said, good > reproduction makes it better. I've been debugging in lots of languages including assembly codes for over 30 years so I know precisely what you mean. So when it's possible to reproduce a bug in some known conditions, the wait-and-see attitude is not a good option because it's very likely that the bug will disapear. Memory coruptions are much like terrorist attacks: you never know where and when it will happen. In bug 614904 I submitted a TWO lines program which crashed PHP on a absolutely standard i386 debian install. I got no answer. Of course the bug disapeared in following versions of PHP but what is fixed ? Not as far as I know. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:52, Lester Caine a écrit : > Pascal I am sure that many people here would be more than happy to > hear about particular problems you are hitting. Ok, then why when I signal a bug noone cares ? > Like Stas I have > never had problems with the stability of PHP5 in 10 years of running > it. PHP5 did not exist 10 years ago ;-) Anyway, around 2001 it took me one year (not full time) to find out there was a memory corruption in PHP. At that time I was using mod_php. It crashed Apache. > YES I can get it to crash, but it has always told me why and > fixing the problem clears that up. I do have sites that become > unstable, but I have yet to find a situation where PHP was the > problem ... when you have a bug in PHP it should not ever ever crash PHP and unfortunately I encountered that case dozens of times. > My grumble is with having to rewrite code simply because someone has > decided that what I was doing is no longer acceptable ... if I can > run my code with display_errors ON then I know I've got clean code > :) I 1000% agree -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:19, Lester Caine a écrit : >>when you have a bug in PHP it should not ever ever crash PHP and >> unfortunately I encountered that case dozens of times. > At least on Linux is just recovers and carries on If PHP crashes, yes, it recovers but it's VERY resource and time consumming. If PHP corrupts some memory, it does not crash fastcgi processes but the next request(s) behave erratically. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:29, Stas Malyshev a écrit : > On 6/15/11 11:38 PM, Pascal COURTOIS wrote: >>In bug 614904 I submitted a TWO lines program which crashed PHP on >> a absolutely standard i386 debian install. I got no answer. >> Of course the bug disapeared in following versions of PHP but what is fixed ? >> Not as far as I know. > > 614904 doesn't look like real bug number. Must be a typo. ooops, sorry. You're right. It's a bug I submitted to debian because of the way they work with releases having a version with no feature update but including security updates, which means the versions in debian distribution are not exactly the ones released. Since debian requires that bug submitted should not be submitted also to program developpers, I complied. May be it was a mistake... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 09:56, Stas Malyshev a écrit : > On 6/15/11 11:38 PM, Pascal COURTOIS wrote: >> as I said earlier, test case was reduced to: > > The leaks you'll be seeing in this code is probably caused by the > fact that main function (i.e. global context) is not destroyed when > exit() is called, since . It can be argued as a bug, but very minor > one and totally unlikely to cause any problems both because the leak > is minuscule and the fact that memory manager will clean it up anyway > on shutdown. If you call "minuscule" a leak that requires more than 128Mb as it normally requires about 4Mb, then it's minuscule but whatever you name it it just does not run. > I would have very hard time believing this very > short-time leak can cause any problems in any production code. It does -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 10:12, Stas Malyshev a écrit : > Hi! > > On 6/16/11 1:05 AM, Pascal COURTOIS wrote: >> If you call "minuscule" a leak that requires more than 128Mb as it >> normally requires about 4Mb, then it's minuscule but whatever you >> name it it just does not run. > > Sorry, if your example generates memory footprint of 128Mb, something > is seriously wrong with your build. There's no way this code can > produce 128Mb footprint. If it's another code, they we'd need to > investigate what causes that leak, that's a deal. I have no time right now but I will summerize on tuesday the whole thing that leaded to this code. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 11:36, Johannes Schlüter a écrit : > On Thu, 2011-06-16 at 08:12 +0200, Pascal COURTOIS wrote: >> Le 16/06/2011 08:01, dukeofgaming a écrit : >> >>> Sorry if the question is dumb, but, how many core developers does PHP have?, >>> how many in total (including non-core contributors)?. >> >> That's not the point. Whatever the project is, every developer should fix >> existing bugs before even thinking about improving. That's the way I do and >> that's why there is no bug I'm aware in my programs. > > Feel free to contribute. PHP is driven by volunteers spending their free > time on it. I know. I also have a GPL project. Nonetheless some societies use it, and some people rely on it to get paid. I have absolutely no legal contract with anyone but I have a moral contract and when I'm signaled a bug, it is mostly fixed within few hours. I just can't imagine replying to a bug submission "Hey guy, its a free project. Why don't you fix it yourself ?" My conscience tells me to not release a program if people using it can shoot themself in the foot. > For many it is more fun to implement new stuff they probably > "need" than fixing bugs in some code which has some side effects which > are not always easy to predict and which they actually don't use. If you followed the thread you have seen the reduced test case is VERY short and the ONLY constructions involved are user functions and exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. I can't imagine nobody uses user functions and exceptions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 12:12, Pierre Joye a écrit : > It is not what Johannes said and we do fix bugs every single day. What > Johannes said is that we can't force a volunteer to do something > specific instead of what he wants to do. > > It is also totally off topic btw. It is really on topic since letting someone insert his wonderful clever feature in a project, whatever it is, and not maintain it is a project management problem. PHP makes me think of a ship with tens of stirring wheels. Of course no one can be forced to do what he doesn't want but a free project doesn't mean unmanaged project and a managed project means people with responsibilities. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 12:31, Rasmus a écrit : > On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: >> If you followed the thread you have seen the reduced test case is >> VERY short and the ONLY constructions involved are user functions and >> exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. >> I can't imagine nobody uses user functions and exceptions. > > You might also consider that your particular case is rather unique. I since decoder-...@own-hero.net could reduce the case from my original program in the conditions I stated, he could obvously detect the leaks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 13:42, Rasmus a écrit : > On 06/16/2011 11:40 AM, Pascal COURTOIS wrote: >> Le 16/06/2011 12:31, Rasmus a écrit : >>> On 06/16/2011 11:03 AM, Pascal COURTOIS wrote: >>>> If you followed the thread you have seen the reduced test case is >>>> VERY short and the ONLY constructions involved are user functions and >>>> exceptions. FULL STOP. Not even a single addition nor a loop nor nothing. >>>> I can't imagine nobody uses user functions and exceptions. >>> >>> You might also consider that your particular case is rather unique. I >> >> since decoder-...@own-hero.net could reduce the case from my original >> program in the conditions I stated, he could obvously detect the leaks. > > I'm not saying there aren't any. There are known leaks in compile_file() > when you throw an exception like that, so if you call a huge amount of > these within a single request, which is not the case. At most I will have 3 or 4 exceptions per request. > you are going to have problems. But that > is not something the average person hits, and again, they are all > free'ed on request shutdown, so it isn't like it is a persistent leak. Ok, as said before I will summerize the facts on tuesday. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 18:11, Andi Gutmans a écrit : > I have some news for you. Ruby has crashes, Python has crashes, Probably. any references about that ? > even Java has security issues and crashes (check out the Java bug database. > It's bigger than ours). IMHO java is a big s**t but that's really out of topic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 16/06/2011 08:10, Stas Malyshev a écrit : > Hi! > >> what I did every single time. Among all my bug reports I had one >> answer from decoder-...@own-hero.net (thanks to him) who reduced >> the test case for a memory leak (bug 54460). I'm not talking about >> bugs in modules but bugs in *core* which can be reproduced with few >> lines of *core* PHP. > > I am reading the list pretty closely and I don't remember any emails > from you raising the question of reproducible corruption bugs > recently, except indeed for 54460 which seems to be a memory leak, bug 54460 has disapeared from bugs.php.net . Is due to the crash ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] unexpected modification of a variable
Hi,
Is there any way that a variable can be changed within a function without
passing it by reference ?
I have a code like that:
function myfunction($var)
{
print_r($var); => prints $var which is an object
anotherfunction($var); // call by value
print_r($var); => $var has changed
}
I thought that since there's no reference in any way to the variable it cannot
be changed in the function. Am I wrong ?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Give the Language a Rest motion (fwd)
Le 29/06/2011 16:57, Hannes Magnusson a écrit : > We have the data now and work is now ongoing migrating the two now. > museum is also up, and snaps will probably be running before the weekend. great, thanks :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unexpected modification of a variable
Le 29/06/2011 17:00, Richard Quadling a écrit : > For objects, $var is always an alias to an object identifier which > points to the same object... > > http://docs.php.net/manual/en/language.oop5.references.php thanks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
