Re: core files in testsuite directory

Re: core files in testsuite directory

[Michael Elizabeth Chastain]

drow> If the other tests _are_ supposed to generate core files (I don't
drow> know), then they should probably run in similar subdirectories.

Sounds good to me (but I admit I haven't looked at the code).

Also I regret that I approved gdb.c++/annota3.exp with the same
name as gdb.base/annota3.exp.  Dunno if we can move it now.
Certainly gdb.cp/annota3.exp has very little history to lose.

Michael C

core files in testsuite directory

[David Carlton]

My testsuite directory is littered with core files.  They're from
annota1, annota3 (the one in gdb.base, not the one in gdb.cp), and
signals.  The first two tests attempt to remove a file named 'core',
but the core files are actually named 'core.PID', so they stay around.

Some questions:

* I assume that all these tests are generating core files for
  legitimate reasons?  It's not entirely clear to me why they're being
  generated, but I don't really understand what signals lead to core
  files in the first place.

Assuming that's the case, we should presumably change the core file
cleanup function (and move it to lib/gdb.exp, for ease of sharing, and
have signals.exp call it as well).  So:

* What should the new cleanup function do?  Should it just try to
  remove core.*?  Or should it be passed the PID of the process in
  question, and only try to remove core.PID and core?

David Carlton
carlton@kealia.com

Re: core files in testsuite directory

[Daniel Jacobowitz]

On Fri, Sep 26, 2003 at 09:44:06AM -0700, David Carlton wrote:
> My testsuite directory is littered with core files.  They're from
> annota1, annota3 (the one in gdb.base, not the one in gdb.cp), and
> signals.  The first two tests attempt to remove a file named 'core',
> but the core files are actually named 'core.PID', so they stay around.
> 
> Some questions:
> 
> * I assume that all these tests are generating core files for
>   legitimate reasons?  It's not entirely clear to me why they're being
>   generated, but I don't really understand what signals lead to core
>   files in the first place.
> 
> Assuming that's the case, we should presumably change the core file
> cleanup function (and move it to lib/gdb.exp, for ease of sharing, and
> have signals.exp call it as well).  So:
> 
> * What should the new cleanup function do?  Should it just try to
>   remove core.*?  Or should it be passed the PID of the process in
>   question, and only try to remove core.PID and core?

Check um... corefile.exp?  Which does the former, I believe.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: core files in testsuite directory

[David Carlton]

On Fri, 26 Sep 2003 13:45:59 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Fri, Sep 26, 2003 at 09:44:06AM -0700, David Carlton wrote:

>> * What should the new cleanup function do?  Should it just try to
>> remove core.*?  Or should it be passed the PID of the process in
>> question, and only try to remove core.PID and core?

> Check um... corefile.exp?  Which does the former, I believe.

Yeah, but it's a special case: it runs in a subdirectory to make
cleanups easier.  It looks for core.* but only uses it if there's
exactly one match for the regexp; that makes using that regexp safe,
but I don't think the single match restriction would work well in
general.

David Carlton
carlton@kealia.com

Re: core files in testsuite directory

[Daniel Jacobowitz]

On Fri, Sep 26, 2003 at 10:50:47AM -0700, David Carlton wrote:
> On Fri, 26 Sep 2003 13:45:59 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> > On Fri, Sep 26, 2003 at 09:44:06AM -0700, David Carlton wrote:
> 
> >> * What should the new cleanup function do?  Should it just try to
> >> remove core.*?  Or should it be passed the PID of the process in
> >> question, and only try to remove core.PID and core?
> 
> > Check um... corefile.exp?  Which does the former, I believe.
> 
> Yeah, but it's a special case: it runs in a subdirectory to make
> cleanups easier.  It looks for core.* but only uses it if there's
> exactly one match for the regexp; that makes using that regexp safe,
> but I don't think the single match restriction would work well in
> general.

If the other tests _are_ supposed to generate core files (I don't
know), then they should probably run in similar subdirectories.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer