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 ---------------------------------------------------------------------------- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
