On Sun, Jun 29, 2008 at 02:21:20PM -0700, chromatic wrote: > On Sunday 29 June 2008 06:52:12 [EMAIL PROTECTED] wrote: > > --- trunk/languages/perl6/tools/test_summary.pl (original) > > +++ trunk/languages/perl6/tools/test_summary.pl Sun Jun 29 06:52:09 2008 > > @@ -58,7 +58,7 @@ > > - my $cmd = "../../parrot perl6.pbc $tfile"; > > + my $cmd = "../../parrot -G perl6.pbc $tfile"; > > This change bugs me; are there other tickets for segfaults and crashes in > Parrot affecting Rakduo besides RT #56448, or am I misunderstanding the > purpose of the change? > > If the default behavior is to work around problems, I fear > that we won't get the problems fixed.
I think this question requires a longish reply -- apologies in advance for the length. First, r28816 is not related to RT#56448; the segfault in RT#56448 occurs regardless of the presence/absence of the -G flag. There exists in Parrot a category of segfaults that I now refer to as "-G bugs", because they magically disappear when Parrot is run with the -G option. Unfortunately, they also magically disappear if you make seemingly any sort of minor change to the source code (either PIR or HLL) or input data, which makes them very difficult to track or locate. This is likely the case for RT#54116 and RT#55782, both of which report segfaults that disappear with -G. In each of those tickets chromatic asks an appropriate question -- "Can you reproduce it with the generated PIR?" -- and this goes unanswered. In the general case I speculate (and will confirm shortly in each of those tickets) that the segfault will _not_ appear when run from the generated PIR, because running the generated PIR directly will be a sufficient enough change in the order of operations that the -G bug disappears. In other words, these bugs often act like true "heisenbugs" -- they disappear as soon as you start perturbing the system to find them. I grant that they probably are trackable using the --gcdebug runcore, but for Rakudo-compiler-related segfaults that can take a _really_ long time. It has also been my experience that the -G bugs appear and disappear in the normal course of development -- when a -G bug appears, it sticks around only until something else is changed in the source, at which point it disappears again. So, the only way to reproduce the error is to use the exact same Parrot revision as the original, and it may even require the same build platform. In the case of the r28816 patch, I chose to add -G to the test_summary.pl script because my primary use of that script is to measure how Rakudo is performing with respect to the official test suite. The -G bugs distort that measurement a fair bit, since they aren't really bugs with Rakudo, and since they cause test files to abort early. However, having the the -G option in test_summary.pl doesn't cause them to go completely hidden, because they still show up with the standard "make spectest_regression" and "make fulltest" targets, and of course someone running rakudo from a command line will still be exposed to any bugs. I agree entirely with the concept that we should not be working around problems -- and I even hesitated for a week or so on this very point before adding the -G to test_summary.pl . But ultimately I decided that since we still have the bugs appearing via normal usage and the standard 'make spectest_regression' and 'make fulltest' targets, it wouldn't be a big problem to have -G here. If after reading the above the hardcoded -G in test_summary.pl is still seen as a problem, then I'll see about switching it to be a command line option or environment variable for my purposes. Or, even better, if we finally track down the source of the -G bugs, then I'm sure we'll see -G much less often. :-) Thanks, Pm
