[PATCH 1/1] RSB: Mitigate too short error reports
frank.kuehndel at embedded-brains.de
Thu Jan 19 12:47:51 UTC 2023
On 1/16/23 18:27, Joel Sherrill wrote:
> Re: [PATCH 1/1] RSB: Mitigate too short error reports
> Joel Sherrill <joel at rtems.org>
> 1/16/23, 18:27
> Frank Kühndel <frank.kuehndel at embedded-brains.de>
> 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:
>>> Re: [PATCH 1/1] RSB: Mitigate too short error reports
>>> Chris Johns<chrisj at rtems.org>
>>> 1/16/23, 01:02
>>> 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
>>>>>> 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 =
>>>>>> with open(name, 'w') as l:
>>>>>> 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
>>>> As the text indicates, this is specific to GNU make. For those using
>>>> 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
>>>> 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
>>>> 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
>>> 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
>>> 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
> 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
>>> 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 ... and a happy new year to you
>> embedded brains GmbH
>> Herr Frank KÜHNDEL
>> Dornierstr. 4
>> 82178 Puchheim
>> 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:
>> devel mailing list
>> devel at rtems.org
More information about the devel