Item1303: Parser uninited var in concat errormessages filling my disk

[Sun Mar 15 12:33:08 2009] [error] [client 10.10.10.22] [Sun Mar 15 12:33:08 2009] view: Use of uninitialized value in concatenation (.) or string at /Users/svend/Sites/foswiki/core/lib/Foswiki/Prefs/Parser.pm line 76., referer: http://macpro/~svend/foswiki/core/bin/view/FoswikiApplicationData/TodoApplication0007
[Sun Mar 15 12:33:08 2009] [error] [client 10.10.10.22] [Sun Mar 15 12:33:08 2009] view: Use of uninitialized value in concatenation (.) or string at /Users/svend/Sites/foswiki/core/lib/Foswiki/Prefs/Parser.pm line 76., referer: http://macpro/~svend/foswiki/core/bin/view/FoswikiApplicationData/TodoApplication0007
[Sun Mar 15 16:23:50 2009] [error] [client 10.10.10.22] [Sun Mar 15 16:23:50 2009] view: Use of uninitialized value in concatenation (.) or string at /Users/svend/Sites/foswiki/core/lib/Foswiki/Prefs/Parser.pm line 76., referer: http://macpro/~svend/foswiki/core/bin/view/FoswikiApplicationData/TodoApplication0007
[Sun Mar 15 16:23:50 2009] [error] [client 10.10.10.22] [Sun Mar 15 16:23:50 2009] view: Use of uninitialized value in concatenation (.) or string at /Users/svend/Sites/foswiki/core/lib/Foswiki/Prefs/Parser.pm line 76., referer: http://macpro/~svend/foswiki/core/bin/view/FoswikiApplicationData/TodoApplication0007
[Sun Mar 15 16:25:51 2009] [error] [client 10.10.10.22] [Sun Mar 15 16:25:51 2009] view: Use of uninitialized value in concatenation (.) or string at /Users/svend/Sites/foswiki/core/lib/Foswiki/Prefs/Parser.pm line 76.
[Sun Mar 15 16:25:51 2009] [error] [client 10.10.10.22] [Sun Mar 15 16:25:51 2009] view: Use of uninitialized value in concatenation (.) or string at /Users/svend/Sites/foswiki/core/lib/Foswiki/Prefs/Parser.pm line 76.

Crawford, I think you 'll need to re-poke this change, as it doesn't seem to happen on the release branch. The refactoring you did on trunk probably has something missing from it.

-- SvenDowideit - 15 Mar 2009

Interesting; this is coming from a piece of code marked with the following comment:

        # SMELL: What is this mysterious undocumented code for? It inserts
        # PREFERENCE_<pref title> but that's all I can work out :-(
        # I can't find any clues in Codev either.

it's untouched from TWiki days, and adds the title of a META:PREFERENCE as a preference. For example, if you have META:PREFERENCE{name="Cheese" title="Fromage" value="Mimolette"} you will end up with a preference called "Cheese" with the value "Mimolette" and a preference called "PREFERENCE_Fromage" with the value "Mimolette". Obviousy if you have a preference with no title field, you will get this uninitialized variable, which is what I suspect is the cause of your message.

I'm really surprised you are not seeing this on Release01x00, because the code is very similar there.... can you check again please?

-- CrawfordCurrie - 16 Mar 2009

mmm, 'similar', and yet, i don't get this issue on the release branch.

< sub parseMeta {
<     my ( $this, $meta, $prefs, $keyPrefix ) = @_;
94c65,66
<     my @fields = $meta->find('PREFERENCE');
---
>     # Now process PREFERENCEs
>     my @fields = $topicObject->find('PREFERENCE');
96,104c68,77
<         my $title         = $field->{title};
<         my $prefixedTitle = $settingPrefPrefix . $title;
<         my $value         = $field->{value};
<         my $type          = $field->{type} || 'Set';
<         $prefs->insert( $type, $prefixedTitle, $value );
< 
<         #SMELL: Why do we insert both based on title and name?
<         my $name = $field->{name};
<         $prefs->insert( $type, $keyPrefix . $name, $value );
---
>         my $type  = $field->{type} || 'Set';
>         my $value = $field->{value};
>         my $name  = $field->{name};
>         $prefs->insert( $type, $name, $value );
> 
>         # SMELL: What is this mysterious undocumented code for? It inserts
>         # PREFERENCE_<pref title> but that's all I can work out :-(
>         # I can't find any clues in Codev either.
>    # (later) added ifdefined, to remove error log line
>         $prefs->insert( $type, 'PREFERENCE_' . $field->{title}, $value ) if (defined($field->{title}));
109c82
<     my $form = $meta->get('FORM');
---
>     my $form = $topicObject->get('FORM');
111c84
<         my @fields = $meta->find('FIELD');
---
>         my @fields = $topicObject->find('FIELD');
113d85
<             my $title      = $field->{title};

-- SvenDowideit - 16 Mar 2009

By creating a topic that has a META:PREFERENCE with a missing title I can reproduce this on Release 01x00. So there has to be data somewhere on your system that has such a preference tag. So, how can that have been created? The only place a PREFERENCE is written is in Manage.pm, and the code that does it is identical on both Release01x00 and trunk, so I can only assume something else outside the core, and independent of the refactoring, generated such a topic.

Recommend you investigate your data further and find where this is coming from. I will keep your change in the core code because it is inoffensive, though should be removed if we ever get round to validating the content of %META tags.

At the same time I discovered that the editing of preferences on trunk isn't working correctly, so checking in that fix against this report.

-- CrawfordCurrie - 16 Mar 2009

Can we close this?

-- KennethLavrsen - 22 Apr 2009

yup, Crawford explanation gels with me

-- SvenDowideit - 01 May 2009