Re: how to discover description of error which terminated run

[johnlumby <johnlumby at hotmail dot com>]

On 12/07/12 05:06, Mark Wielaard wrote:
> On Thu, 2012-12-06 at 18:29 -0500, Frank Ch. Eigler wrote:
> > johnlumby wrote:
> >
> > > [...]  What surprises me is that the run continued for a full 0.1
> > > seconds (over 4000 lines of output) after this message was logged
> > > before it shut itself down.  [...]
> > The intent is not to lose information unnecessarily; the transport of
> > that queued information is lightweight enough not to cause overload.
> That and we prioritize reporting warning/error messages. When there are
> messages from the kernel to user space then warning/errors get reported
> first, even when some other messages might still be pending to make sure
> errors are always presented to the user. Which in this case made it
> harder for the user to spot the error, because we were also able deliver
> all the normal messages after reporting the error... :{
>
> > > [...] Makes me wonder  -  is there some way of directing error
> > > messages such as this to some other channel rather than interspersing
> > > them into the run output.   Or else at least making them more distinctive.

I checked how  I was running stap and now I see I was re-directing 
stderr to stdout !
So it was my fault I missed it.      I will switch to using tee for 
stderr in future
and that should solve it.

> > I believe errors/warnings already go to stderr as opposed to stdout.
> > I opened PR14927 to make them even more visible.  (Want to give coding
> > that up a try?  We'll help!)

I read the Bug Report.    Looks interesting.    I can certainly try.
Just point me to where the error messages are written.

> O, color coded error/warnings! Nice idea.
>
> Thanks,
>
> Mark