Front page | perl.perl5.porters |
Postings from October 2013
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 >>>> >>>> http://www.nntp.perl.org/group/perl.daily- >>> 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 >> http://perl5.git.perl.org/perl.git/commit/db17973a7879fcb6ada1024d1c72e99a944746d1 >> >> is responsible. I'll leave it to khw to realize his mistake in that >> commit and fix all the warnings in regcomp.c in >> http://www.nntp.perl.org/group/perl.daily-build.reports/2013/10/msg152778.html >> >> . >> >> 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 builds. 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