Re: [PATCH] testsuite quick fixes

On Sat, Aug 03, 2002 at 04:01:58PM -0400, Garth Sainio wrote:
> On Sat, 3 Aug 2002, Richard Clamp wrote:
> 
> > More progress.  perl -e is still segfaulting, but that's just
> > happening within the call to mktemp that the -e causes so I think
> > that's an easy thing to fix.
> 
> If you pass the -fwritable-strings to gcc that seems to solve the

Excellent news.  I think I was kicking an inverse solution by using
strdup to make a locally writable copy.  I didn't realise I could have
the compiler do it for me, but now I do I much refer your solution
since it's a much smaller change.

This does raise a side issue, backporting some of the perl5 hints
system would help with this in a "it's linux, so it must be gcc and
-fwritable-strings" way.  I'll take a look at this tomorrow if people
think this is worthwhile (or don't object too loudly).

Also, is the plan to make perl1 properly ANSI C and -Wall clean, or
just to get it building on as many contemporary platforms as is
possible?  The latter is possibly a much smaller patch.

> > 7 test scripts still fail, but they seem like real bugs rather than
> > just dodgyness in the test harness.
> 
> With the above flag to gcc I am down to 2 errors in the test harness.
> 
> One in t/comp.decl, the last two format do not write and one in t/op.each
> which causes a core dump, it seems to be a memory allocation issue.

On osx this takes me down to 5 from the previous 8 (there's one extra
on osx compared to linux/ppc as osx has a /usr/bin/sed rather than the
/bin/sed which is expected in perly.c).  These are comp.cpp/40 (the
/bin/sed thing), comp.decl/6, op.each/2 (according to osx this is
double or bogus frees[0]), op.flip/8, and op.time/2.

op.time/2 looks like a "computers sure have gotten quicker in the last
14 years" glitch to me, but I'm not sure I'm reading the test correctly.


[0] It spits this out (with slight reformatting), maybe valgrind on
linux/x86 will explain more, but I can't get at a suitable machine
until the morning at least.

*** malloc[4398]: Deallocation of a pointer not malloced: 0x93160;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug

*** malloc[4398]: Deallocation of a pointer not malloced: 0x9a020;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug

*** malloc[4398]: Deallocation of a pointer not malloced: 0x99340;
This could be a double free(), or free() called with the middle of an
allocated block; Try se tting environment variable MallocHelp to see
tools to help debug 
op.each...FAILED on test 2

-- 
Richard Clamp <[email protected]>