develooper Front page | perl.perl5.porters | Postings from October 2013

Re: [perl #120314] t/re/fold_grind.t spews tons of "Attempt to freetemp prematurely" warnings on DEBUGGING but ultimately passes

Thread Previous | Thread Next
Karl Williamson
October 30, 2013 05:18
Re: [perl #120314] t/re/fold_grind.t spews tons of "Attempt to freetemp prematurely" warnings on DEBUGGING but ultimately passes
Message ID:
On 10/24/2013 11:03 PM, Karl Williamson wrote:
> # Test process timed out - terminating
> On 10/23/2013 08:08 AM, bulk88 via RT wrote:
>> On Wed Oct 23 03:35:04 2013, davem wrote:
>>>> The answer is plain as day in
>>> build.reports/2013/10/msg152778.html
>>>> I won't provide a patch to protest discrimination against C89 :p
>>> It may be plain to you, but not to me. Care to elaborate?
>> A lack of knowledge of C89, since AFAIK, most P5Pers use GCC in C++ mode
>> here, and if my C++ knowledge is correct, they will never see the bug.
>> Commit
>> is responsible. I'll leave it to khw to realize his mistake in that
>> commit and fix all the warnings in regcomp.c in
>> .
>> I am upset because the only reason I saw this is because I looked at my
>> screen because my TV show went to commercials. The smoke report still
>> "passes" even though its outputting severe warnings. The timing of
>> commercials on the TV is not a reliable way to check for bugs in a make
>> test.
>> IMO if it wasn't for a TV commercial this would have silently gone into
>> 5.20. Anyone agree or disagree?
>> Maybe those SV leak warnings should be fatal on DEBUGGING builds, not
>> warnings?

It should follow then that you wouldn't have been upset if you hadn't 
jumped to unwarranted conclusions.

First of all, this is arguably not a bug at all since the correct answer 
is always computed and nothing bad happens.  The warnings are saying 
that if Perl were less clever, then freeing the same memory twice could 
happen (I didn't see any leak messages.)  But Perl is clever enough not 
to do that.  That's why it's OK for the warnings to only be in debugging 

Second, I had already noticed that I had made a commit which was causing 
Win32 compiler warnings, and so I had fixed them (and similar ones that 
I hadn't caused) locally.  But I had not pushed this yet because I 
didn't realize that it was actually causing run-time warnings, and I 
have had only a very minimum of time that I can devote to Perl due to 
rebuilding after a natural disaster in my area.  Thus, it turns out that 
your TV commercial did not affect the ultimate outcome in this case. 
When I found out that they were causing warnings, I stayed up late one 
night and split the original patch into two, one for just the warnings 
specified in this ticket; and the other for the similar warnings from 
elsewhere.  After smoking on Win32, it turns out that fixing these 
compiler warnings also fixed the run-time warnings.  (Until then it 
really wasn't known if they were actually related.)

That's not to say that blind luck doesn't play a role in finding and 
averting problems.  It just wasn't a factor in this case.  I'm grateful 
whenever luck happens; sometimes it doesn't, and code is shipped whose 
defectiveness only becomes apparent from field reports.   Naturally, a 
project should be managed to try to avoid (as much as possible) relying 
on luck.  In this particular case, I think the lesson is that we 
definitely want to minimize compiler warnings as much as possible before 
shipping a release.  My mistake was to not notice those warnings before 
I made the original commit.

I don't submit a patch unless it passes all tests on my (Linux) machine 
under both C++, and C with C89 strict enabled.  However, I don't usually 
do a debugging build for the latter.  That catches many goofs I might 
otherwise make, but it doesn't catch everything.  I've been burned 
enough that for almost all non-trivial changes to C code, I also wait 
for the output of the Win32 smoker.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About