how to discover description of error which terminated run

[johnlumby]

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
>
>
>