On Wed, 2009-12-02 at 00:56 +0100, Andreas Fritiofson wrote: > On Tue, Dec 1, 2009 at 11:50 PM, Zach Welch <z...@superlucidity.net> wrote: > > On Tue, 2009-12-01 at 23:09 +0100, Andreas Fritiofson wrote: [snip] > > I like it, except I think it needs to be disabled in the default case. > > We will get complaints if OpenOCD produces core dumps without asking, so > > this precludes the possibility of turning it on by default. Our program > > needs to respect the fact that the user could have configured their > > environment to let the program dump its core, so it seems like bad > > policy to override that default without the user's explicit authority. > > I don't follow. If a user has no clue what a core file is but wants to > report a crash, he'll be pleased to find that the file we request is > already there, ready to submit in a bug report. If a user knows about > core files and _wants_ them, he surely has them enabled anyway (ulimit > -c unlimited). If that user _doesn't_ want any core files from > openocd, he'll have set the hard limit to 0 (ulimit -c 0), in which > case openocd cannot change that. Tough luck. The default policy, which > the user may override, is "don't dump core unless the process wants > to".
But all of these things are extra steps, grok? If the stack trace is Just There, we get it in the first report; we don't have to add a round-trip to the communication to tell them to look at the core file. And you must have missed my point in another line of this thread that none of these things are suitable for _users_. These are things that developers will do. While some developers may make these efforts, I think the majority of users will just want a tool that works, and they are not going to be bothered to debug our problems. Heck, I claim that class of user will uninstall us if it segfaults for them off-the-shelf, but this shows that we care enough about them to encourage bug reports. They just might stick around and see how we respond, and maybe they will be convinced to continue with it -- if it gets fixed without us asking them to do a lot of grunt work like generating a core file or using GDB. Say, that reminds me to update the segfault output to tell users to report them to us. :) Your core files can't do that! > > We could allow it to be turned on with OPENOCD_DUMPS_CORES set in the > > environment or via a script command (e.g. 'core dumps (on|off)'). This > > modified suggestion sounds like a reasonable feature to add, once more > > work has been done to manage portability. Right now, it's a rat's nest. > > Finally, I am not sure your suggestion would improve the assert() macro, > > as the last patch that I posted demonstrates. Does that macro produce > > core files with the stack trace at the point of assertion? > > Yes. Unless, of course, your mentioned patch is applied... :) > It also dumps on some other signals (SIGILL, SIGFPE and SIGQUIT). > > The fact is that the most recent crash I had with OpenOCD > (log_print_lf adding a newline beyond the end of the cheaply allocated > string) wouldn't have been caught with your stack trace, since it did > not SIGSEGV, it was aborted by a later free(). It would have dumped > core though. Of course, your solution could have been trivially > improved to catch SIGABRT as well. More patches are welcome, but base patches off my repo.or.cz branch and not those posted to the list. :) > > I still want my stack tracing, because I cannot tell the future. It's > > also the least invasive to the user experience, when compared to GDB or > > core dumps. I am not kidding when I say that I do not want to do _any_ > > extra post-processing steps. I fail to see how core files meet this > > added requirement any better than GDB, when my code nearly does.... To > > be fair, I added a small perl script to my series that runs addr2line to > > translate the existing traces that the code produces, but this still has > > the clear advantage of not needing to predict your crashes. > > What kind of post-processing steps do you mean and why don't you want > them? Given an executable and its core dump its as simple as > $ gdb executable > (gdb) target core core > and wham you have a debug session up where you can backtrace, examine > variables and such. Developers should know tricks like this to get detailed information, but I never want to ask a user to do this. I think it is reprehensible as a maintainer to do so, when it could have been prevented by dumping the stack trace for them right into the log for them. > I'm not saying your patches have no use here in any context, they > could very well be the fanciest solution to some particular problems, > but they feel a bit like .. reinventing ... something round. At least we have the glibc APIs to do this somewhat cleanly. I mean, it's not like I am asking to walk down the stack by hand. ;) Thank goodness I don't need to handle C++ name demangling too, though libgcc has APIs to make that easy too (IIRC). --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
