[snip] I beg to differ. In the past 20 years, I've spent plenty of time working with core dumps, stand-alone dumps, slip traps and system traces debugging my own software (running at customer sites) without the remotest possibility of reproducing a problem on-demand. If you think a problem must be reproducable for "any development team" to solve it, you need to try working in a real one. No offence, just my opinion. [/snip] I agree, sometimes you cannot get the actions that caused the issue from a customer, but in this case we are developers...we are (or should be) smarter than the average user and should be able to take code that we are running when the segfault occurs and provide that to the PHP development team. It is much easier for any development team when the problem is reproducible. I have worked and led "real ones" for nearly 30 years (and several languages) and one of the troubleshooting techniques is to attempt to reproduce the error. [snip] A core dump or an strace or some debug output at the right time will have 99% of the information you need - provided you understand how to read it. I submit there is generally no need to reproduce a problem in order to diagnose it. To fix it, yes, it will undoubtedly help if you can reproduce it, but once you've diagnosed it, reproducing it is a lot easier. [/snip] Wouldn't it be nice to have 100% of the information? That last 1% may be the code that caused the problem. [snip] > You see that time and again on this list as well....without the > offending action all we can do is attempt to guess at what was going > on at the time of the failure. Diligent trouble-shooting on your part > would have gotten a much better response. You could have likely > isolated the code that caused the core dump (just as we isolate > problem code on this list... Jay, this is the same kind of c... that PHP developers have responded with in the past. I'm sorry, but IMO that is entirely unprofessional. OK, so maybe one isn't being paid to write open source software, but that's no excuse for not being professional about it. IMHO. [/snip] So given just a clue you can surmise what code the developer wrote, how s/he used it and how it failed from a general description? As developers we have a responsibility as well; we must do our part and if that includes troubleshooting and isolating code that causes a segfault then so be it. I understand that we sometimes do not do this, and we should expect that solutions will be more difficult to come by. [snip] What's the purpose of a core dump if it does not provide the key information for solving a problem? If I still have to isolate and reproduce the issue in user code, there seems to be very little need for the core dump, right? [/snip] Not so. A core dump, as you stated before, gives you most of the information. Having the code that appeared to have caused the problem is definitely welcomed. It helps to see what was occurring when the segfault happened. Would you not agree? I want to make a note here; only if I run the same code over and over and it causes a segfault every time do I have code that may cause the issue. If the developer is not the only one testing on the same box then there could be multiple reasons for the core dump. I would never send a one-time core dump to the dev team. I would isolate and test my code again and again to see if the segfault occurred each time. At that point I would submit the info if there was nothing in the core dump that gave me a clue as to what was going on. If you have multiple developers testing on the same platform and experience a segfault you may never be able to reproduce the problem because it could be a combination of things that caused the problem to occur. Giving the core dump data to the development team provides them valuable information but it may not be a problem easily solved because there are too many variables to account for. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
