[PATCH 1/1] RSB: Mitigate too short error reports

Thu Jan 19 12:47:51 UTC 2023

Hello Chris,
Hello Joel,

On 1/16/23 18:27, Joel Sherrill wrote:
> Subject:
> Re: [PATCH 1/1] RSB: Mitigate too short error reports
> From:
> Joel Sherrill <joel at rtems.org>
> Date:
> 1/16/23, 18:27
> 
> To:
> Frank Kühndel <frank.kuehndel at embedded-brains.de>
> CC:
> Chris Johns <chrisj at rtems.org>, devel at rtems.org
> 
> 
> On Mon, Jan 16, 2023 at 8:46 AM Frank Kühndel <
> frank.kuehndel at embedded-brains.de> wrote:
> 
>> Hi Chris,
>>
>> On 1/16/23 01:02, Chris Johns wrote:
>>> Subject:
>>> Re: [PATCH 1/1] RSB: Mitigate too short error reports
>>> From:
>>> Chris Johns<chrisj at rtems.org>
>>> Date:
>>> 1/16/23, 01:02
>>>
>>> To:
>>> Frank Kühndel<frank.kuehndel at embedded-brains.de>,devel at rtems.org
>>>
>>>
>>> On 22/12/2022 9:09 pm, Frank Kühndel wrote:
>>>> On 12/21/22 00:06, Chris Johns wrote:
>>>>> On 21/12/2022 3:44 am, Frank Kuehndel wrote:
>>>>>> From: Frank Kühndel<frank.kuehndel at embedded-brains.de>
>>>>>>
>>>>>> Close #4642
>>>>>> ---
>>>>>>     source-builder/sb/ereport.py | 4 ++++
>>>>>>     1 file changed, 4 insertions(+)
>>>>>>
>>>>>> diff --git a/source-builder/sb/ereport.py
>> b/source-builder/sb/ereport.py
>>>>>> index d8fb5f6..d391917 100755
>>>>>> --- a/source-builder/sb/ereport.py
>>>>>> +++ b/source-builder/sb/ereport.py
>>>>>> @@ -55,6 +55,10 @@ def generate(name, opts, header = None, footer =
>> None):
>>>>>>                 with open(name, 'w') as l:
>>>>>>                     l.write(os.linesep.join(r))
>>>>>>                 log.notice('  See error report: %s' % (name))
>>>>>> +            log.notice('  (Hint: The first error may be in front of
>> a '
>>>>>> +                'line containing\n'
>>>>>> +                '  "Error 1" [GNU make] and may be only in the whole
>> log '
>>>>> Is this too specific to GNU make? What ifs a package uses cmake or
>> something
>>>>> else?
>>>> As the text indicates, this is specific to GNU make. For those using
>> something
>>>> else reading this text will still hint that the first error may not be
>> in the
>>>> end of the report "and may be only in the whole log".
>>>>
>>>> Another weak point in this text is that by far not all errors
>> originating from
>>>> "make". Yet, the true trouble is the original "See error report: %s"
>> where it
>>>> can sometimes happen that the error is not in this "error report" at
>> all.
>>>> I found it difficult to find a wording which is short, clear and
>> helpful to the
>>>> reader and at the same time not confusing. I am not perfectly happy
>> with the
>>>> notice above. I just found it a reasonable compromise.
>>>>
>>>> If you prefer more generic texts - such as the examples below - I will
>> send a
>>>> new patch with the suggested test.
>>>>
>>>>       "Hint: The first error may be far way from the end of the
>>>>       report and in cases can only be found in the whole build log."
>>>>
>>>>       "Hint: The error is most likely in the error report otherwise
>>>>       see the whole build log [--log option]."
>>>>
>>>> If you find any such change might cause more confusion than it might be
>> helpful,
>>>> I think it better to close this bug than to try to fix it.
>>>>
>>> I think all you have written is valid and I have found the wording
>> difficult.
>>> There will never be a robust error message scanner or a simple full
>> proof way to
>>> find errors. The parallel builds makes tracking the errors difficult and
>> the
>>> point of error and end of the build a long distance apart.
> I usually search the logs for "rror:" and that's the first time something
> is reported
> whether by make or gcc or whatever. It may not be the root cause but it gets
> me to the first report.
> 
> Cutting any of these long reports down is always going to be possible to
> cut out the real issue. It's ok because it it's more than just an odd setup
> issue on the host, someone will have to build locally to reproduce the
> issue.
> And then they will get the full output.
> 
> 
>>> As a result I question the value of the report and wonder if it should be
>>> removed. The report adds overhead to the build as the logging process
>> needs to
>>> maintain a buffer of lines that is always updating. Your attention and
>> interest
>>> around this feature highlights how problematic it is so maybe it is
>> simpler and
>>> better to remove it and we leave users to find the error in the log file.
>>>
>>> I am happy to accept the report has not worked as a feature, remove it
>> and in
>>> the process we recover some overheads in the logging area of the RSB?
>>>
>> I am not against the error report and I do not say it is a useless
>> feature. It is just that I found the message '  See error report: %s'
>> confusing in those cases where the report does not contain the error
>> at all because it is too short (the error report consists simply of the
>> last 400 lines of the build log).
>>
>> To answer your question, I believe there is always a build log - no
>> matter whether the `--log` option is used or not. In this case, removing
>> the error report and pointing to the build log in case of error (for
>> example like '  See build log: %s') would certainly solve all my concerns.
>>
> But on the build@ reports, it is nice to have something. Many times it
> is possible to diagnose the issue. Just in the past fifteen minutes, there
> was one which having the log made it clear that CentOS 7 and other older
> distributions need to use a newer GCC. Having the info in the build@
> message was more than enough to diagnose that.
> 
>> On the other hand, implementing the error report took time and was
>> certainly done with good reason. I do not feel like I should be the one
>> deciding to remove it. Changing the message or simply closing
>> https://devel.rtems.org/ticket/4642  would also be perfectly valid for me.
>>
> Changing the message to encourage --log or whatever guidance for
> debug. I don't even mind it pointing to a URL with guidance on debugging
> RSB build issues.

When I understand Joel right, he would keep the error report and prefers 
to change the message. This brings the discussion back to decide on an 
appropriate text. To make progress, I suggests

   '  See error report: %s\n'
   '  Note: In some cases the error appears only in\n'
   '  the complete build log (see --log option)'

If your are OK with this text, I am happy to prepare a patch. I also 
welcome any other suggestion. If we cannot find any solution, I prefer 
to close my ticket #4642 without any action taken.

Greetings
fk

> 
> --joel
> 
> 
>> Greetings ... and a happy new year to you
>> Frank
>>
>> --
>> embedded brains GmbH
>> Herr Frank KÜHNDEL
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email:frank.kuehndel at embedded-brains.de
>> phone:  +49-89-18 94 741 - 23
>> mobile: +49-176-15 22 06 - 11
>> fax:    +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> 