This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Don't run forever in gdb.base/structs.c
- From: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 03 Oct 2014 09:57:50 +0100
- Subject: Re: [PATCH] Don't run forever in gdb.base/structs.c
- Authentication-results: sourceware.org; auth=none
- References: <yjt2d2abqz9x dot fsf at ruffy dot mtv dot corp dot google dot com> <542C936A dot 60507 at redhat dot com> <CADPb22RA+nn55F=BCof+deCh5LRQZ3z58RUESGD2UptAwfLYqQ at mail dot gmail dot com>
On 10/02/2014 09:10 PM, Doug Evans wrote:
> On Wed, Oct 1, 2014 at 4:51 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 10/01/2014 10:02 PM, Doug Evans wrote:
>>
>>> If gdb crashes during testing tests may be left to free-run, eating cpu.
>>>
>>> This patch fixes one of the more egregious cases since several versions
>>> of the program are built.
>>>
>>> I've got patches to fix others.
>>> Just seeing if folks want to comment on this first.
>>>
>>> IWBN to have the harness itself cleanup, and I think there's something
>>> we can do there, but that's not always robust either, and I think
>>> multiple levels of robustness would be useful.
>>
>> Agreed.
>>
>>> Since this testcase is an egregious one, and since this patch simple,
>>> I'm starting with this.
>>
>> Looks fine with me.
>
> Committed, thanks.
Thank you. Guess this could be material for:
https://sourceware.org/gdb/wiki/GDBTestcaseCookbook
?
>> In a few other tests, we use "alarm()", though IMO it's best to avoid
>> that if possible, to expose the test on as much targets as possible.
>> E.g., alarm() IIRC isn't available on mingw unless you
>> specify __USE_MINGW_ALARM. Bare metal targets may have trouble
>> with it too, etc.
>
> Agreed.
Expanding on that a bit: TBC, I see no problem with alarm() if the
test is already using other posix-ish things, like pthread_create,
or signal. I'd avoid iff the test otherwise could be mostly
plain C/C++ and OS independent, like structs.c.
Thanks,
Pedro Alves