Jay Blanchard wrote: > [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. It would be nice, yes. In my previous professional life, I would probably have asked the customer to set a SLIP trap to provide that extra info. That trap would be triggered/detriggered given the right set of circumstances and could give me either a systems trace, maybe a stand-alone dump or something else to assist me in locating the problem. Right now I'm trying to debug what I think is a race condition in spamd (spamassassin) when it reloads the config. Reproducing is out of the question except by chance. To help me debug, I now run an strace every time the daemon is sighup'ed. It might be another couple of months before it happens again. > [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? Oh, definitely. The complete code should always be available to you, but that's not the same as being able to reproduce the problem. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
