threads / discuss / 15885

Puzzled by a t9500 test failure

Subject: Puzzled by a t9500 test failure

## tl;dr

6 messages between Oct 13, 2008 and Oct 15, 2008.

replies: 5people: 2as markdown or json

Shawn O. Pearce· Oct 13, 2008, 23:48 UTC · re: Junio C Hamano · lore

Re: Puzzled by a t9500 test failure

Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
> With recent tip of 'master':
> 
>     $ make
>     $ mkdir t/trash
>     $ cd t && sh t9500-*.sh -i
> 
> fails at the very first test.  Can anybody figure out why?
Hmmph.  Near as I can tell its because gitweb.log has this in it:

$ cat gitweb.log [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in scalar chomp at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 1811. [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in addition (+) at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 3772. HASH..

The test does a grep for '[[]' and if it matches, fails. I'm not sure why this started showing up now. Obviously I merged something that failed the test suite, but I was pretty sure I had run the full set before publishing anything.

-- 
Shawn.
Shawn O. Pearce· Oct 14, 2008, 00:08 UTC · re: Shawn O. Pearce · lore

Re: Puzzled by a t9500 test failure

"Shawn O. Pearce" <spearce@spearce.org> wrote:
Show 15 quoted lines
> Junio C Hamano <gitster@pobox.com> wrote:
> > With recent tip of 'master':
> > 
> >     $ make
> >     $ mkdir t/trash
> >     $ cd t && sh t9500-*.sh -i
> > 
> > fails at the very first test.  Can anybody figure out why?
> 
> Hmmph.  Near as I can tell its because gitweb.log has this in it:
> 
> $ cat gitweb.log
> [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in scalar chomp at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 1811.
> [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in addition (+) at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 3772.
> HASH..

bisect says its aed93de428d7d12ee23d84d27265af1e37eb348f, "gitweb: Support for tag clouds".

This appears to fix it. As for how I missed this, I do not know. I usually tested topic branches pretty heavily before merging them to next, and I tested both master and next daily. So I thought the topic was ready to merge into master. Apparently it was not. How I missed the failed merge, I don't know. :-\

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..793166e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1808,7 +1808,7 @@ sub git_get_project_ctags {
 	foreach (<$git_dir/ctags/*>) {
 		open CT, $_ or next;
 		my $val = <CT>;
-		chomp $val;
+		chomp $val if defined $val;
 		close CT;
 		my $ctag = $_; $ctag =~ s#.*/##;
 		$ctags->{$ctag} = $val;
@@ -1822,7 +1822,11 @@ sub git_populate_project_tagcloud {
 	# First, merge different-cased tags; tags vote on casing
 	my %ctags_lc;
 	foreach (keys %$ctags) {
-		$ctags_lc{lc $_}->{count} += $ctags->{$_};
+		if (defined ($ctags_lc{lc $_}->{count})) {
+			$ctags_lc{lc $_}->{count} += $ctags->{$_};
+		} else {
+			$ctags_lc{lc $_}->{count} = $ctags->{$_};
+		}
 		if (not $ctags_lc{lc $_}->{topcount}
 		    or $ctags_lc{lc $_}->{topcount} < $ctags->{$_}) {
 			$ctags_lc{lc $_}->{topcount} = $ctags->{$_};
@@ -3769,7 +3773,11 @@ sub git_project_list_body {
 		my %ctags;
 		foreach my $p (@projects) {
 			foreach my $ct (keys %{$p->{'ctags'}}) {
-				$ctags{$ct} += $p->{'ctags'}->{$ct};
+				if (defined $ctags{$ct}) {
+					$ctags{$ct} += $p->{'ctags'}->{$ct};
+				} else {
+					$ctags{$ct} = $p->{'ctags'}->{$ct};
+				}
 			}
 		}
 		my $cloud = git_populate_project_tagcloud(\%ctags);

-- 
Shawn.
Junio C Hamano· Oct 15, 2008, 04:27 UTC · re: Shawn O. Pearce · lore

[PATCH] Fix reading of cloud tags

The projectroot path could have SP in it, in which case iterating over <$git_dir/ctags/*> does not correctly enumerate the cloud tags files at all.

This can be observed by creating an empty t/trash directory and running t9500 test. The $projectroot ends with "trash directory.t9500-gitweb-/" and <$glob> would give "trash", which can be opened and reading from it immediately yields undef, which in turn gives an undef value warning to the standard error stream upon attempt to chomp it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 gitweb/gitweb.perl |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)
diff --git c/gitweb/gitweb.perl w/gitweb/gitweb.perl
index 1116800..577c041 100755
--- c/gitweb/gitweb.perl
+++ w/gitweb/gitweb.perl
@@ -1805,7 +1805,8 @@ sub git_get_project_ctags {
 	my $ctags = {};
 
 	$git_dir = "$projectroot/$path";
-	foreach (<$git_dir/ctags/*>) {
+	opendir D, "$git_dir/ctags";
+	foreach (grep { -f $_ } map { "$git_dir/ctags/$_" } readdir(D)) {
 		open CT, $_ or next;
 		my $val = <CT>;
 		chomp $val;
@@ -1813,6 +1814,7 @@ sub git_get_project_ctags {
 		my $ctag = $_; $ctag =~ s#.*/##;
 		$ctags->{$ctag} = $val;
 	}
+	closedir D;
 	$ctags;
 }
Junio C Hamano· Oct 14, 2008, 00:13 UTC · re: Shawn O. Pearce · lore

Re: Puzzled by a t9500 test failure

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 20 quoted lines
> Junio C Hamano <gitster@pobox.com> wrote:
>> With recent tip of 'master':
>> 
>>     $ make
>>     $ mkdir t/trash
>>     $ cd t && sh t9500-*.sh -i
>> 
>> fails at the very first test.  Can anybody figure out why?
>
> Hmmph.  Near as I can tell its because gitweb.log has this in it:
>
> $ cat gitweb.log
> [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in scalar chomp at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 1811.
> [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in addition (+) at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 3772.
> HASH..
>
> The test does a grep for '[[]' and if it matches, fails.  I'm not
> sure why this started showing up now.  Obviously I merged something
> that failed the test suite, but I was pretty sure I had run the full
> set before publishing anything.
Nothing as far as I can tell changed while you were the pumpking.

I was just wondering why the presense of that extra, should-be-unused, t/trash directory affects the outcome of the test.

Shawn O. Pearce· Oct 14, 2008, 00:22 UTC · re: Junio C Hamano · lore

Re: Puzzled by a t9500 test failure

Junio C Hamano <gitster@pobox.com> wrote:
Show 27 quoted lines
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> With recent tip of 'master':
> >> 
> >>     $ make
> >>     $ mkdir t/trash
> >>     $ cd t && sh t9500-*.sh -i
> >> 
> >> fails at the very first test.  Can anybody figure out why?
> >
> > Hmmph.  Near as I can tell its because gitweb.log has this in it:
> >
> > $ cat gitweb.log
> > [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in scalar chomp at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 1811.
> > [Mon Oct 13 23:43:36 2008] gitweb.perl: Use of uninitialized value in addition (+) at /home/sop/local/maint-git/t/../gitweb/gitweb.perl line 3772.
> > HASH..
> >
> > The test does a grep for '[[]' and if it matches, fails.  I'm not
> > sure why this started showing up now.  Obviously I merged something
> > that failed the test suite, but I was pretty sure I had run the full
> > set before publishing anything.
> 
> Nothing as far as I can tell changed while you were the pumpking.
> 
> I was just wondering why the presense of that extra, should-be-unused,
> t/trash directory affects the outcome of the test.
Seriously?
Oh.  Some time with strace later...

Its because Perl totally borked the $projectroot path when it was looking at $GIT_DIR/ctags. $GIT_DIR has a space in the path and Perl bound the first aprt, opened it, but cannot open the second part of the $GIT_DIR/ctags string because it doesn't exist.

The code in question is the new tag cloud code in gitweb that Peter added. So bisect is still correct.

My guess is its the code in git_get_project_ctags(), around l.1804-1816.

-- 
Shawn.

← back to recent threads