This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Don't run forever in gdb.base/structs.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]