[sheepdog] [PATCH] util: dump ucontext in crash handlers

[MORITA Kazutaka]

At Mon, 06 May 2013 22:38:21 +0900,
Hitoshi Mitake wrote:
> 
> At Wed, 01 May 2013 22:21:16 +0900,
> MORITA Kazutaka wrote:
> > 
> > At Wed,  1 May 2013 18:30:56 +0900,
> > Hitoshi Mitake wrote:
> > > 
> > > Current crash handlers (of sheep, collie, and logger) don't dump
> > > register status when the signal rises. This patch let them dump the
> > > information. I believe especially RIP is useful for debugging.
> > 
> > I don't thinks so.  If you are debugging Sheepdog on your environment,
> > you can get the register values from the core file.  If you are
> > debugging with a reported sheep.log from other environment, how does
> > the register status help us?
> > 
> > I cannot image the use case of RIP, too.  We can know where the
> > process crashed from the backtrace.  Why do we need it?
> 
> Sorry for my slack description. Sometimes I debug programs with
> objdump -d, so contents of registers are informative for me. But this
> is not a productive way and I should switch to gdb.
> 
> But dumping registers is helpful for users. Because core files might
> contain sensitive information (potentially) so in some cases sending
> core files to public mailing lists would not be allowed. Contents of
> registers would be helpful for such a case. e.g. redis employes this
> way: http://antirez.com/news/43
> (Of course redis is a on memory storage software and it stores almost
> every data on main memory. So core files produced by redis must be
> more sensitive than ones produced by sheep. But the core files
> produced by sheep would also contain sensitive information.)

NACK, the register status in the bug report doesn't help us unless we share the
same executable binary file.  In addition, debugging with the register status is
a pain.  I'd suggest adding more sd_printf() if you are trying to fix a problem
which needs register information.

Thanks,

Kazutaka