Good build

All tests successful on one of my Mandrake 7.2 machines after applying the
Configure and test suite patches, -fwritable-strings, and perl's malloc

Glenn

----- Original Message -----
From: "Richard Clamp" <[email protected]>
To: "Garth Sainio" <[email protected]>
Cc: <[email protected]>
Sent: Saturday, August 03, 2002 10:08 PM
Subject: 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]>
>