Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 5.0.3 losing $this »

PHP 5.0.3 losing $this

php.internals

Yermo Lamers

21 years ago
PHP 5.0.3 is losing $this. PHP 4.3.10 and 5.0.0 seem to work fine. The bug originally appeared in 5.0.2. I have submitted a bug report at: http://bugs.php.net/31525 I've not had alot of luck with reporting bugs through the bug tracker; For instance see http://bugs.php.net/31508 where the guy claims PHP can't do recursion without crashing ... Ummm? So I thought I'd try to ask here. Unfortunately I've been unable to reproduce the 5.0.3 bug in just a few lines. I do have a script that's in my mind pretty short and the meat of it is only 8 lines long but it includes three classes needed to set up the experiment. More information is available at: http://www.formvista.com/index.html?article_id=4 Direct link to the code: http://www.formvista.com/uploaded_files/php5_drops_object.php.txt Scroll to the bottom. The code has three classes: fv_basecomponent is a child of fv_basewidget is a child of fv_tree. fv_baseComponent overrides a method in fv_basewidget called &getParentControl(). fv_baseComponent::getParentControl() returns a reference to $this. In PHP 5.0.3 the reference returned is not an object and a nasty error is generated. I've tested this using today's snapshot (php5-STABLE-200503051730). It continues to work like a champ in PHP 4.3.10 and every previous version and like I said it used to work in 5.0.0. Any help in tracking this down or devising a workaround would be greatly appreciated. And if anyone has any thoughts on bug http://bugs.php.net/31508 that would be greatly appreciated as well; it's not quite the showstopper than the 5.0.3 bug is, but is causing me serious headaches as well. Thanks -- Yermo --------------------------------------------------------------------- DTLink Software http://www.dtlink.com Internet Business Systems and Software ---------------------------------------------------------------------

Matthew Charles Kavanagh

21 years ago
Yermo Lamers wrote:
> I've not had alot of luck with reporting bugs through the bug tracker; > For instance see > > http://bugs.php.net/31508 > > where the guy claims PHP can't do recursion without crashing ... Ummm?
To be fair, he is correct in what he says; PHP cannot do recursion beyond a certain level, because of limitations on stack size. He does not claim that PHP cannot do recursion; you are misrepresenting him..

Yermo Lamers

21 years ago
> Yermo Lamers wrote: >> I've not had alot of luck with reporting bugs through the bug tracker; >> For instance see >> >> http://bugs.php.net/31508 >> >> where the guy claims PHP can't do recursion without crashing ... Ummm? > > To be fair, he is correct in what he says; PHP cannot do recursion > beyond a certain level, because of limitations on stack size. He does > not claim that PHP cannot do recursion; you are misrepresenting him..
Not to start a new thread but at this point in the conversation because the PHP 5.0.3 bug is much more serious but in my own defense I was told: "What you are experiencing is a stack smash caused by recurssion. This is unlikely to ever be fixed and is a good example of why not to use recursive functions." Good example of why not to use recursive functions ... Ummm? I don't see how I can misrepresent that. You are correct that later in the conversation he corrected himself after I replied. But to be fair I put alot of work into tracking this down this far and it's a very serious bug that has nothing to do with recursion. It just got dismissed out of hand; which is pretty much what has happened with every bug report, every patch, etc that I've ever submitted going back to PHP 4.0. I certainly understand that there are countless bugs and thousands of people with issues and very few of them are doing projects of the size and scope that I am. In many ways, PHP is not an appropriate choice for my project, but that's a separate subject. At the very least it would be nice to not be dismissed out of hand; especially when I've taken the time to clearly demonstrate an internal PHP buffer overrun error. I can't be the only person experiencing these problems. As far as I've been able to determine the PHP 4.3.10 bug is due to a buffer overrun error having something to do with methods returning array members and the caller incorrectly taking a reference to the returned value ... 9 times out of 10 it makes the sit and spin/coredump problem go away. If taking a a reference to a by-value is incorrect PHP it should generate a warning. It seems to be correct since it'll work for the first few hundred iterations .. and then randomnly crash depending on context, which is why I haven't been able to produce a nice small script to demonstrate it. At least with --enable-debug turned on the coredump problems goes away and it generates very nice buffer overrun errors. Like I said, I haven't had much luck reporting bugs. No problem. I understand they are very busy; and I'm willing to help if I can. But showing no interest and dismissing serious bugs out of hand is a real problem. Right now the 4.3.10 bug isn't as critical as the 5.0.3 bug. That one's a showstopper as the project I've been working on for the last 4 years (tens of thousands of lines of code) can't run under 5.0 while this bug persists. Symbol table trashing bugs due to buffer management errors have plagued PHP since the 4.0 days. I had held out hope they would be resolved in Zend 2; and I think the situation is improved but this "$this" getting lost problem prevents me from upgrading. What can I do to help to track these down and fix it/get them fixed? -- Yermo ---------------------------------------------------------------------------- DTLink Software http://www.dtlink.com Desktop Software and Web Applications ----------------------------------------------------------------------------

Wez Furlong

21 years ago
On Sat, 5 Mar 2005 16:05:45 -0500 (EST), Yermo Lamers <yml@dtlink.com> wrote:
> At least with --enable-debug turned on the coredump problems goes away and > it generates very nice buffer overrun errors.
> Like I said, I haven't had much luck reporting bugs. No problem. I > understand they are very busy; and I'm willing to help if I can. But > showing no interest and dismissing serious bugs out of hand is a real > problem.
The problem you're having is not giving the right information. For instance, the buffer overrun errors would be an ideal thing to attach to your bug report.
> Symbol table trashing bugs due to buffer management errors have plagued > PHP since the 4.0 days. I had held out hope they would be resolved in Zend > 2; and I think the situation is improved but this "$this" getting lost > problem prevents me from upgrading. > > What can I do to help to track these down and fix it/get them fixed?
Write good bug reports. There is something of an art to it, especially for the harder to pin-down problems. I just glanced through your script, and the mere fact that you have to search for the bug shows that the test script is too large. The bottom line is that PHP is a free open source project, powered by volunteers; show some respect for our free time by taking the time to refine the report to the smallest possible test case. --Wez.

Yermo Lamers

21 years ago
> The problem you're having is not giving the right information. For > instance, the buffer overrun errors would be an ideal thing to attach > to your bug report.
The buffer overruns are the separate bug in PHP 4 as in http://bugs.php.net/31508. The PHP 5 is not encountering a buffer overrun; it just loses $this.
> Write good bug reports. There is something of an art to it, > especially for the harder to pin-down problems. I just glanced > through your script, and the mere fact that you have to search for the > bug shows that the test script is too large.
So what do you do when you can't reduce it down any further? I spent two days putting that script together in a trial and error fashion until I finally got something that seemed reasonably small in size. It's 8 lines, not including the supporting classes; and those classes are very simple. There error it generates is completely obvious. "$this is not an object". Hmm. how could that be? It is entirely unreasonable to think that all bugs are going to be reduced down to a few lines of code. Maybe if you're doing trivial things .. but when dealing writing complicated systems it's often not so straight forward.
> The bottom line is that PHP is a free open source project, powered by > volunteers; show some respect for our free time by taking the time to > refine the report to the smallest possible test case.
I spent 16 hours producing that test case. It took countless runs. The body of code that it comes from includes over 61,000 lines of code. You see my problem. If someone doesn't have enough time to at least look at it they could at least point me in a direction so I can start delving into it. I understand it's an open source project and I am trying to contribute where I can. I'm not saying fix this for me. I'm saying "Where do I go next if I can't produce the small script". The answer seems to be "you're out of luck". Maybe the answer is "You need to pay someone to fix it", or "check out this section of the parser yourself" or "try this patch" or "give us a login and get on the phone with us and help us do this". Some next step because I have to get this fixed. The answer I keep getting is "oh well, we're too busy, you have no options if you can't reproduce it in 20 lines". -- Yermo ---------------------------------------------------------------------------- DTLink Software http://www.dtlink.com Desktop Software and Web Applications ----------------------------------------------------------------------------

Andi Gutmans

21 years ago
Yermo, You have to understand that with the amount of work we're doing on PHP, it's very hard to start logging into someone's server (many offer) and debug 61K of code we don't know. It also means that instead of you spending the time to try and reproduce it, one of the PHP Development team would have to do it because in most cases it's the only way to really understand what's going wrong. I don't see why your time is more precious than ours. So yes, we want to help, but it means you have to help too and give us something which we can easily reproduce and investigate. In most cases a backtrace will not do. I don't think you have to contribute a patch nor do I think you have to pay anyone, I only think you have to spend some time and present us with a solvable problem. Hope it's a bit clearer now. Thanks, Andi At 07:51 PM 3/5/2005 -0500, Yermo Lamers wrote:

Yermo Lamers

21 years ago
Andi, Thanks for the return() pointer .. I figure that's probably what's causing alot of my trouble.
> You have to understand that with the amount of work we're doing on PHP, > it's very hard to start logging into someone's server (many offer) and > debug 61K of code we don't know.
That's not what I was asking for; give me some direction of how I can be helpful. I figure if I can get the BufferOverflown errors when --enable-debug is turned on that there's a real bug in the code that has to be fixed. At that point it's not my bug, it's a parser bug.
> It also means that instead of you > spending the time to try and reproduce it, one of the PHP Development > team would have to do it because in most cases it's the only way to > really understand what's going wrong.
Not what I was asking for. I was asking for some direction. What do you guys do when you've got a buffer overrun by 10 error that happens randomnly? How do you guys track it down? Maybe there should be a "What to do when you can't reproduce it in a few lines of code" page to help guys like me out. Do you use efence(), are there any internals documents that cover typical errors, are there any other resources, are there any other debug options to turn on, etc. etc.
> I don't see why your time is more precious than ours.
It's clearly not. Don't misunderstand em. I am entirely aware that I am at your service, not the other way around. And that's what I don't get; I have said from the beginning I am entirely willing to step up to the plate and help out in any way I can to solve this. It would just be very helpful to get some /direction/ for some of these more serious problems. For instance, in PHP 4.3.10, in some cases changing the length of a variable name in a given method changes a core dump into perfectly running code. I've had to go in to my framework and build out reference verification code because PHP is endlessly dropping arrays, dropping objects, corrupting the symbol table and just randomly going seriously weird. Sometimes it'll cause Apache to sit and spin inside a malloc() call until it grows without bounds. (and no, that's not executing PHP code at the time .. ). Obviously something I'm doing is exercising some bug ... maybe it's the () on the returns. I'll implement that change and will report back .. I bet that's probably it. Strange that's been working all this time ...
> So yes, we want to help, but it means you have to help too and give us > something which we can easily reproduce and investigate.
Therein lies the problem. There are /countless/ serious issues in PHP that will randomnly trash the symbol table .. and they are virtually impossible to reproduce in a small snippet of code. And I'm not using anything exotic. No extra extensions. PHP + Mysql inside Apache on Linux. Pretty plain.
> In most cases a backtrace will not do. I don't think you have to > contribute a patch nor do I think you have to pay anyone, I only > think you have to spend some time and present us with a solvable problem.
But what am I to do when I am faced with the case where I have the 61k lines of code and PHP is dumping core on me randomly and I spend weeks trying to reproduce it down to small script and am unable to? The reason I ask (and the source of frustration is) I run into these problems all the time.
> Hope it's a bit clearer now.
Bottom line is, if I can't reproduce it in a few lines of code what should I do then? Keep quiet and/or go away? Or do you believe the entire problem space will always reduce down to a few lines of code? I'm just looking for some direction; I'm sure there are alot of guys like me out there that would love to help out more and make your lives easier; all we need is some direction. "make a short script" just isn't enough, I don't think. -- Yermo
> Thanks, > Andi > > > At 07:51 PM 3/5/2005 -0500, Yermo Lamers wrote: > >> > The problem you're having is not giving the right information. For >> > instance, the buffer overrun errors would be an ideal thing to attach >> > to your bug report. >> >>The buffer overruns are the separate bug in PHP 4 as in >>http://bugs.php.net/31508. >> >>The PHP 5 is not encountering a buffer overrun; it just loses $this. >> >> > Write good bug reports. There is something of an art to it, >> > especially for the harder to pin-down problems. I just glanced >> > through your script, and the mere fact that you have to search for the >> > bug shows that the test script is too large. >> >>So what do you do when you can't reduce it down any further? I spent two >>days putting that script together in a trial and error fashion until I >>finally got something that seemed reasonably small in size. >> >>It's 8 lines, not including the supporting classes; and those classes are >>very simple. >> >>There error it generates is completely obvious. "$this is not an object". >>Hmm. how could that be? >> >>It is entirely unreasonable to think that all bugs are going to be >> reduced >>down to a few lines of code. Maybe if you're doing trivial things .. but >>when dealing writing complicated systems it's often not so straight >>forward. >> >> > The bottom line is that PHP is a free open source project, powered by >> > volunteers; show some respect for our free time by taking the time to >> > refine the report to the smallest possible test case. >> >>I spent 16 hours producing that test case. It took countless runs. The >>body of code that it comes from includes over 61,000 lines of code. You >>see my problem. >> >>If someone doesn't have enough time to at least look at it they could at >>least point me in a direction so I can start delving into it. I >> understand >>it's an open source project and I am trying to contribute where I can. >> >>I'm not saying fix this for me. I'm saying "Where do I go next if I can't >>produce the small script". The answer seems to be "you're out of luck". >> >>Maybe the answer is "You need to pay someone to fix it", or "check out >>this section of the parser yourself" or "try this patch" or "give us a >>login and get on the phone with us and help us do this". >> >>Some next step because I have to get this fixed. >> >>The answer I keep getting is "oh well, we're too busy, you have no >> options >>if you can't reproduce it in 20 lines". >> >>-- Yermo >> >>---------------------------------------------------------------------------- >>DTLink Software http://www.dtlink.com >> Desktop Software and Web Applications >>---------------------------------------------------------------------------- >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php > >
---------------------------------------------------------------------------- DTLink Software http://www.dtlink.com Desktop Software and Web Applications ----------------------------------------------------------------------------

Zeev Suraski

21 years ago
Yermo, Essentially, what Andi was saying is that we need your help in order for us to help you. To put it more clearly - even if there is a bug in the language engine or some other component of PHP - it's impossible for us to figure out what it is, unless we're provided with a reproducible test case that's small enough to analyze. At 05:08 06/03/2005, Yermo Lamers wrote:
> > It also means that instead of you > > spending the time to try and reproduce it, one of the PHP Development > > team would have to do it because in most cases it's the only way to > > really understand what's going wrong. > >Not what I was asking for. I was asking for some direction. What do you >guys do when you've got a buffer overrun by 10 error that happens >randomnly? > >How do you guys track it down?
There's usually no magic there, just a lot of work narrowing things down (as opposed to trying and guess where the problem is and create a new test case). To narrow it down, create a copy of the app that's causing the problem, and start cutting out parts gradually, while checking in every step of the way that the problem is still occurring. This is the time consuming part, that you're probably more qualified to do than any of us, since you know your code best. Make sure you keep the editor window open, so that you can undo a change that causes the problem to disappear. An important thing is actually not to stop when you find the line or block that appears to trigger the error - but continue and try to remove other parts of the code. Essentially, what would help us best is a piece of code that: (a) reproduces the problem (b) is a derivative of the original code that went through the above mentioned process, rather than a bottom-up written script that reproduces a similar problem (c) anything removed from that piece of code will cause the problem to disappear Disabling the Zend memory manager (change USE_ZEND_ALLOC to 0 in zend_alloc.h) and using valgrind can also sometimes shed light on the source of the problem, although it's usually only practical once you already have a stripped down version of the script.
>Maybe there should be a "What to do when you can't reproduce it in a few >lines of code" page to help guys like me out.
That's not a bad idea! Hope this helps, Zeev

Yermo Lamers

21 years ago
> Yermo, > > Essentially, what Andi was saying is that we need your help in order for > us to help you. To put it more clearly - even if there is a bug in the > language engine or some other component of PHP - it's impossible for us to > figure out what it is, unless we're provided with a reproducible test case > that's small enough to analyze.
yea, like I was saying there are so often cases with PHP that you have a very specific situation where it's dumping core and you make the /slightest/ change and it no longer exhibits the problem .. only to crop up again months later in another very annoying/very specific instance. In the most extreme case I've seen removing a single character from a string in an array be the difference between symbol table corruption/coredump and running fine. What I'm hearing is that unless I can reproduce it in a small script I should not bother reporting it. Correct?
>>Maybe there should be a "What to do when you can't reproduce it in a few >>lines of code" page to help guys like me out. > > That's not a bad idea!
It turns out that, at least in this instance, the source of my problem was incorrectly using parentheses on return()'s when returning references. If I understand correctly ()'s indicate an expression in this context and expressions cannot evaluate to references ... what's weird is that I've been doing it that way for the last 4 years with little ill effect. It does look like the situation is not being caught correctly, however, as returning a reference in a parenthetical expression will, under some circumstances, cause a coredump. I believe because PHP doesn't handle the "trying to dereference a NULL pointer as an object reference" case sometimes. (again, random core dump. I don't have a demo script.) Just an FYI. Thanks for your time and attention, -- Yermo ---------------------------------------------------------------------------- DTLink Software http://www.dtlink.com Desktop Software and Web Applications ----------------------------------------------------------------------------