I dont think this is necessarily an either-or. These are disjoint use cases IMV.
I concur it would be desirable to have support for something along these lines for end users. It would be a bit more than configuring that tool though ; we probably need to setup a site where this stuff gets uploaded to, and then identify poor souls to actually look at it. EMC Volunteer Force folks, please stand in line, not more than 10 core dumps per person ;-) Actually the more I think about it enabling such a tool by default would be not necessarily improve 'user experience' if you dont have an appropriate organisational structure to back it up, and I doubt we have that. But then this wasnt the question. And I really should look at Apport. What *I* (developer hat) need is a) notification that something happened without me perusing dmesg output periodically and b) have a short, concise report when I screwed up. These 40-something lines of code serve that purpose well without further dependencies. What I do not need during development is a whale of an end-user tool which shares the important information with me that I'm running 10.04 LTS before uploading the results of my feeble coding attempts to hall-of-shame.linuxcnc.org ;-) What I will do is to add a feature mask ini variable, where optional features can be turned on and off with a mask similar like [EMC]DEBUG, and add backtrace as such a feature bit. Then, in case the signal handler gets in the way with other tools it can be turned off by default for distribution. -m ps: semi-on-topic: currently reading 'Andreas Zeller, Why Programs Fail' (http://www.whyprogramsfail.com/). Heavily recommended. It adresses these issues too. Am 16.09.2011 um 16:32 schrieb s...@highlab.com: > I'd love to have backtraces of users' crashes, but i'm not sure explicit > support in each of our executables is the way to do it. Do you know about > Apport? It's a system-wide crash reporting tool that might be useful for us. > > https://wiki.ubuntu.com/Apport > > ----- Reply message ----- > From: "Michael Haberler" <mai...@mah.priv.at> > Date: Fri, Sep 16, 2011 00:48 > Subject: [Emc-developers] patch: generating a backtrace in task (was: EMC's > 'silent segfaulting' behaviour) > To: "EMC developers" <emc-developers@lists.sourceforge.net> > > Here's a proposed patch to generate a backtrace in task on SIGSEGV, SIGFPE > and SIGUSR1 > > the SEGV and FPE signals will abort task, sending SIGUSR1 will create a > backtrace and continue. Appropriate Operator message are displayed. > > http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/backtrace-task > > unsure where this should go, I guess master > > The backtrace goes to /tmp/backtrace.<milltask-pid> and looks like so: > > stack trace for /home/mah/emc2-test/bin/milltask pid=16970 signal=11 > 0x009bc416 in __kernel_vsyscall () > [Current thread is 1 (process 16970)] > #0 0x009bc416 in __kernel_vsyscall () > #1 0x001a77d3 in waitpid () from /lib/tls/i686/cmov/libc.so.6 > #2 0x0806809e in backtrace (signo=11) at emc/task/backtrace.cc:26 > #3 <signal handler called> > #4 0x00c5c3aa in Interp::read_o (this=0x807db00, line=0xc82ef8 > "o<rm400>call", counter=0xbfc4c95c, block=0xc82b6c, parameters=0xc841c4) at > emc/rs274ngc/interp_read.cc:1451 > #5 0x00c5925f in Interp::read_items (this=0x807db00, block=0xc82b6c, > line=0xc82ef8 "o<rm400>call", parameters=0xc841c4) at > emc/rs274ngc/interp_read.cc:774 > #6 0x00c55a5a in Interp::parse_line (this=0x807db00, line=0xc82ef8 > "o<rm400>call", block=0xc82b6c, settings=0xc82a40) at > emc/rs274ngc/interp_internal.cc:327 > #7 0x00c7035f in Interp::read (this=0x807db00, command=0x8fe9e64 > "o<rm400>call") at emc/rs274ngc/rs274ngc_pre.cc:937 > #8 0x00c6c72e in Interp::execute (this=0x807db00, command=0x8fe9e64 > "o<rm400>call") at emc/rs274ngc/rs274ngc_pre.cc:218 > #9 0x00c6d11d in Interp::execute (this=0x807db00, command=0x8fe9e64 > "o<rm400>call", line_number=-2147483647) at emc/rs274ngc/rs274ngc_pre.cc:317 > #10 0x0804facd in emcTaskPlanExecute (command=0x8fe9e64 "o<rm400>call", > line_number=-2147483647) at emc/task/emctask.cc:527 > #11 0x0805f90a in emcTaskIssueCommand (cmd=0x8fe9e58) at > emc/task/emctaskmain.cc:2042 > #12 0x0805e09d in emcTaskPlan () at emc/task/emctaskmain.cc:1307 > #13 0x08061a97 in main (argc=3, argv=0xbfc4cd14) at > emc/task/emctaskmain.cc:3074 > /home/mah/emc2-test/bin/milltask exiting > > comments? > > -Michael > > > ------------------------------------------------------------------------------ > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA > http://p.sf.net/sfu/rim-devcon-copy2 > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
