threads / discuss / 20451

Gitweb giving me some warnings in Apache's error_log

Subject: Gitweb giving me some warnings in Apache's error_log

## tl;dr

4 messages between Aug 7, 2009 and Aug 10, 2009.

replies: 3people: 2as markdown or json

Mark A Rada· Aug 7, 2009, 13:00 UTC · lore

It doesn't seem to cause any other problems, but I don't know if it is significant or not.

[Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth" may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2296. [Fri Aug 7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.

Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8

-- Mark A Rada (ferrous26) marada@uwaterloo.ca

Jakub Narebski· Aug 7, 2009, 14:14 UTC · re: Mark A Rada · lore

Re: Gitweb giving me some warnings in Apache's error_log

Mark A Rada <markrada26@gmail.com> writes:
Show 11 quoted lines
> It doesn't seem to cause any other problems, but I don't know if it is
> significant or not.
> 
> [Fri Aug  7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth"
> may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line
> 2296.
> [Fri Aug  7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be
> unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.
> 
> 
> Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8
>From perldiag(1) manpage:
  Variable "%s" may be unavailable
    (W closure) An inner (nested) anonymous subroutine is inside a
    named subroutine, and outside that is another subroutine; and the
    anonymous (innermost) subroutine is referencing a lexical variable
    defined in the outermost subroutine.  For example:
      sub outermost { my $a; sub middle { sub { $a } } }
    If the anonymous subroutine is called or referenced (directly or
    indirectly) from the outermost subroutine, it will share the
    variable as you would expect.  But if the anonymous subroutine is
    called or referenced when the outermost subroutine is not active,
    it will see the value of the shared variable as it was before and
    during the *first* call to the outermost subroutine, which is
    probably not what you want.
    In these circumstances, it is usually best to make the middle
    subroutine anonymous, using the "sub {}" syntax.  Perl has
    specific support for shared variables in nested anonymous
    subroutines; a named subroutine in between interferes with this
    feature.

The warning is about 'wanted' anonymous subroutine passed to File::Find::find. The "middle" subroutine is git_get_projects_list, and the "outermost" is mod_perl / ModPerl::Registry request loop.

We can't make git_get_projects_list anonymous, but anonymous subroutine is not called or referenced outside git_get_projects_list, nor it is called or referenced outside mod_perl request/event loop.

This warning is harmless... but I do not know how to silence it.
-- 
Jakub Narebski
Poland
ShadeHawk on #git
Mark Rada· Aug 7, 2009, 17:56 UTC · re: Jakub Narebski · lore

Re: Gitweb giving me some warnings in Apache's error_log

Let me double check my understanding.

The warnings will not occur if Gitweb is run as a regular CGI script because then it won't be nested inside a call from ModPerl::Registry?

Will it also not complain if I provided my own $project_list in the first place?

Also, I looked at some examples from the second and third page of an article on the subject, http://www.perl.com/pub/a/2002/05/07/mod_perl.html? and it looks "fixable". Is there a particular reason why any of them are not desirable?

Note: I haven't tried anything yet, just wondering if you know off hand

-- Mark A Rada (ferrous26) marada@uwaterloo.ca

On Fri, Aug 7, 2009 at 10:14 AM, Jakub Narebski<jnareb@gmail.com> wrote:
Show 54 quoted lines
> Mark A Rada <markrada26@gmail.com> writes:
>
>> It doesn't seem to cause any other problems, but I don't know if it is
>> significant or not.
>>
>> [Fri Aug  7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth"
>> may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line
>> 2296.
>> [Fri Aug  7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be
>> unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.
>>
>>
>> Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8
>
> From perldiag(1) manpage:
>
>  Variable "%s" may be unavailable
>
>    (W closure) An inner (nested) anonymous subroutine is inside a
>    named subroutine, and outside that is another subroutine; and the
>    anonymous (innermost) subroutine is referencing a lexical variable
>    defined in the outermost subroutine.  For example:
>
>      sub outermost { my $a; sub middle { sub { $a } } }
>
>    If the anonymous subroutine is called or referenced (directly or
>    indirectly) from the outermost subroutine, it will share the
>    variable as you would expect.  But if the anonymous subroutine is
>    called or referenced when the outermost subroutine is not active,
>    it will see the value of the shared variable as it was before and
>    during the *first* call to the outermost subroutine, which is
>    probably not what you want.
>
>    In these circumstances, it is usually best to make the middle
>    subroutine anonymous, using the "sub {}" syntax.  Perl has
>    specific support for shared variables in nested anonymous
>    subroutines; a named subroutine in between interferes with this
>    feature.
>
> The warning is about 'wanted' anonymous subroutine passed to
> File::Find::find.  The "middle" subroutine is git_get_projects_list,
> and the "outermost" is mod_perl / ModPerl::Registry request loop.
>
> We can't make git_get_projects_list anonymous, but anonymous
> subroutine is not called or referenced outside git_get_projects_list,
> nor it is called or referenced outside mod_perl request/event loop.
>
> This warning is harmless... but I do not know how to silence it.
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
Jakub Narebski· Aug 10, 2009, 14:57 UTC · re: Mark Rada · lore

Re: Gitweb giving me some warnings in Apache's error_log

On Fri, 7 Aug 2009, Mark Rada wrote:
Show 23 quoted lines
> On Fri, Aug 7, 2009 at 10:14 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>> Mark A Rada <markrada26@gmail.com> writes:
>>
>>> It doesn't seem to cause any other problems, but I don't know if it is
>>> significant or not.
>>>
>>> [Fri Aug  7 08:51:13 2009] gitweb.cgi: Variable "$project_maxdepth"
>>> may be unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line
>>> 2296.
>>> [Fri Aug  7 08:51:13 2009] gitweb.cgi: Variable "$projectroot" may be
>>> unavailable at /var/www/private/gitweb/cgi-bin/gitweb.cgi line 2304.
>>>
>>>
>>> Apache 2.2.12/ mod_perl 2.04/ perl 5.8.8
>>
>> From perldiag(1) manpage:
>>
>>  Variable "%s" may be unavailable
>>
>>    (W closure) An inner (nested) anonymous subroutine is inside a
>>    named subroutine, and outside that is another subroutine; and the
>>    anonymous (innermost) subroutine is referencing a lexical variable
>>    defined in the outermost subroutine.
[...]
Show 9 quoted lines
>> The warning is about 'wanted' anonymous subroutine passed to
>> File::Find::find.  The "middle" subroutine is git_get_projects_list,
>> and the "outermost" is mod_perl / ModPerl::Registry request loop.
>>
>> We can't make git_get_projects_list anonymous, but anonymous
>> subroutine is not called or referenced outside git_get_projects_list,
>> nor it is called or referenced outside mod_perl request/event loop.
>>
>> This warning is harmless... but I do not know how to silence it.
> Let me double check my understanding.
> 
> The warnings will not occur if Gitweb is run as a regular CGI script
> because then it won't be nested inside a call from ModPerl::Registry?

Yes, it is true that this happens only when running gitweb as mod_perl legacy script using ModPerl::Registry. Otherwise it would be caught when running t/t9500-gitweb-standalone-no-errors.sh test.

> 
> Will it also not complain if I provided my own $projects_list in the
> first place?

Yes, it would not, because the code is run only when $projects_list is a directory to search for git repositories. If $projects_list is a file you wouldn't get this warning (and it might be slightly faster, if less flexible, as you would need to regenerate this file when adding or removing, or renaming, or changing owner of repositories).

-- 
Jakub Narebski
Poland

← back to recent threads