You are here: Foswiki>Tasks Web>Item12616 (19 Nov 2013, GeorgeClark)Edit Attach

Item12616: Foswiki encounters perl errors in 5.18, 5.19

pencil
Priority: Urgent
Current State: Closed
Released In: 1.1.9
Target Release: patch
Applies To: Engine
Component: PlatformPerl518
Branches: Release01x01 trunk
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
Syntax errors and other problems running Foswiki under 5.18 & 5.19.5

Testing Foswiki under new perls:

perlbrew install 5.18.1
perlbrew switch 5.18.1

curl -L http://cpanmin.us | perl - App::cpanminus
cpanm --interactive -v App::cpanoutdated
cpan-outdated
cpanm --interactive -v App::CPAN::Fresh
cpan-outdated -p | cpanm
cpanm Devel::Symdump
cpanm Alien::Tidyp
cpanm HTML::Tidy
cpanm HTML::TreeBuilder

cd tools
perl -I ../lib rewriteshebang.pl 

cd ../test/unit
perl -wT ../bin/TestRunner.pl -clean LoggerTests.pm 

49 tests failing, all pass on 5.16.

  • lib/Foswiki/Attach.pm fails with perl Possible precedence issue with control flow perator on the following statement return $info->{attr} or " ";
  • test/unit/LoggerTests.pm fails because foreach my $lt qw(File FileRolling) { needs parenthesis around the qw() construct.
  • Large number of failures might be due to hash ordering changes in 5.19
  • HTMLValidation tests fail with HTMLValidation_compareauth_plain (116:3444) Warning: replacing invalid UTF-8 bytes (char. code U+00A0) HTMLValidation_compareauth_plain (116:4645) Warning: replacing invalid UTF-8 bytes (char. code U+00A0) at /var/www/foswiki/trunk/core/lib/Unit/TestCase.pm line 240.

----------------------------
---++ Module Failure summary
Fn_QUERY has 1 unexpected results (of 15):
   * F: Fn_QUERY::test_perl
Fails because of hash ordering. The Data::Dumper code used by Foswiki::Macros::QUERY to seralize the attachment data returns a different hash ordering every time it's run. Here are the results from 3 consecutive tests:
[{'size' => '4586','name' => 'whatsnot.gif','date' => '1266942905','version' => '1'},{'date' => '1266943219','name' => 'World.gif','size' => '2486','version' => '1'}]
[{'name' => 'whatsnot.gif','date' => '1266942905','size' => '4586','version' => '1'},{'size' => '2486','version' => '1','date' => '1266943219','name' => 'World.gif'}]
[{'name' => 'whatsnot.gif','size' => '4586','version' => '1','date' => '1266942905'},{'size' => '2486','name' => 'World.gif','version' => '1','date' => '1266943219'}]
We could get consistent results by sorting the dumper output. Not sure if this is desirable or not, or if we just fix the test to be insensitive to the returned key order.

ViewScriptTests has 1 unexpected results (of 4):
   * F: ViewScriptTests::test_render_raw
I suspect that CGI::textarea() (and other tag generation code driven from a hash) will return the attributes in changing order. ViewScriptTests::test_render_raw fails because it's sensitive to the contents of the <textarea ... attributes, which are shifting around. We'll need to make that test less specific, or change from a regex matching the page, to something more sophisticated that parses apart the tag. At least that failure seems to be a test issue, and not foswiki.

TopicUserMappingAsGuestTests has 1 unexpected results (of 20):
   * F: TopicUserMappingAsGuestTests::verify_secretGroupIsHiddenFromGROUPINFO_useHtpasswdMgr_NamedTopicUserMapping
The list of groups returned changes with each execution. TopicUserMapping does a web search, returning a list which is returned as a ListIterator. There doesn't seem to be any sort that I can find, so the order shifts around. The search doesn't specify a sort order for the results.
RegisterTests has 1 unexpected results (of 185):
   * F: RegisterTests::verify_rejectEvilContent_NoLoginManager_DontAllowLoginName_HtPasswdManager_TopicUserMapping
This again is output order, probably a hash. The confirmation email, the "submitted content"" appears to display data in a varying order. When the test failed, the results * Organization: <script>Bad stuff</script> * Comment: <blah> were tested against a regex that expected Comment before Oganization: (?^ms:.*Comment: <blah>.*Organization: <script>Bad stuff</script>)'
Fn_USERINFO has 1 unexpected results (of 8):
   * F: Fn_USERINFO::test_isadmin
Fails again due to inconsistent ordering. Running the individual test, it passed twice, and then failed:
Expected:'WTemporaryUSERINFOUsersWeb.AdminUserUAdminUserNrootEemail not setGAdminGroup, BaseGroup, FriendsOfFriendsOfGropeGroup, FriendsOfGropeGroupAtrueIAtrueIGfalseE
'
 But got:'WTemporaryUSERINFOUsersWeb.AdminUserUAdminUserNrootEemail not setGBaseGroup, AdminGroup, FriendsOfFriendsOfGropeGroup, FriendsOfGropeGroupAtrueIAtrueIGfalseE
We really need to know if these differences are significant to user applications, or if it's merely test design.
RenameTests has 1 unexpected results (of 29):
   * F: RenameTests::test_renameTopic_with_lowercase_first_letter
Rendering order again. The order of the HTTP headers is shifting. It might be a test issue, as it's doing a "s" search without the multiline option. Changing the regex to (?^ms:^Status... should resolve this, if it's acceptable to return the headers in any order.

In reading RFC2616, I think I've answered my own question. Header order shouldn't matter, Best practice specifies that General headers shoud be first, followed by Request/Response headers, then entity headers. But I don't think we've every worried about that.
Expected:'(?^s:^Status:\s+302)'
Set-Cookie: FOSWIKISID=7126d8771d85ee0133ba28b0033cbd6a; path=/; HttpOnly
Location: /foswiki/bin/view/TemporaryRenameTestsTestWebRenameTests/UpperCase
Date: Sat, 26 Oct 2013 23:14:05 GMT
Status: 302
Content-Type: text/html; charset=ISO-8859-1
SaveScriptTests has 1 unexpected results (of 28):
   * F: SaveScriptTests::test_addform
Tag rendering order again. <input tag tested for name= value=, but was rendered as value=, name=.
RenderTests has 2 unexpected results (of 3):
   * F: RenderTests::test_TOOLTIPS_on
   * F: RenderTests::test_TOOLTIPS_on_space
Tag rendering order yet again. the order of title and href has been flipped in one of the link tags.
Expected:' <ol>
<li> <a href="/foswiki/bin/view/TemporaryRenderTestsTestWebRenderTests/OkTopic" title="on ">OkTopic</a>
</li> <li> <a href="/foswiki/bin/view/TemporaryRenderTestsTestWebRenderTests/OkATopic" title="on ">OkATopic</a>
</li> <li> <a href="/foswiki/bin/view/TemporaryRenderTestsTestWebRenderTests/OkBTopic" title="on ">Ok'Topic'</a>
...'
 But got:' <ol>
<li> <a title="on " href="/foswiki/bin/view/TemporaryRenderTestsTestWebRenderTests/OkTopic">OkTopic</a>
</li> <li> <a title="on " href="/foswiki/bin/view/TemporaryRenderTestsTestWebRenderTests/OkATopic">OkATopic</a>
</li> <li> <a href="/foswiki/bin/view/TemporaryRenderTestsTestWebRenderTests/OkBTopic" title="on ">Ok'Topic'</a>
...
UIFnCompileTests has 2 unexpected results (of 78):
   * F: UIFnCompileTests::verify_switchboard_function_nonExistantTopic_login
   * F: UIFnCompileTests::verify_switchboard_function_nonExistantTopic_viewauth
This one fails when the Status: line is the last line in the headers. The regex ends in a (.) single character match which matches the last character of the status.
     if ( $header =~ /Status: (\d*)./ ) {
        $status = $1;
    }
Changing the match to /Status: (\d*).*?/ as a non-greedy match fixes the issue.
ZoneTests has 4 unexpected results (of 21):
   * F: ZoneTests::test_7
   * F: ZoneTests::test_HEAD_merged_with_SCRIPT
   * F: ZoneTests::test_HEAD_split_from_SCRIPT
   * F: ZoneTests::test_legacy_tag_param_compatibility
All related to rendering order.
UploadScriptTests has 4 unexpected results (of 10):
   * F: UploadScriptTests::test_imagelink
   * F: UploadScriptTests::test_linkformat
   * F: UploadScriptTests::test_propschanges
   * F: UploadScriptTests::test_simple_upload
The upload script test all assume that the Status is the first header. Changing to a ms multiline match fixes the tests.
Fn_SEARCH has 5 unexpected results (of 360):
   * F: Fn_SEARCH::test_format_tokens_topic_truncated
   * F: Fn_SEARCH::test_orderTopic
   * F: Fn_SEARCH::verify_pager_off_pagerformat_pagerinall_BruteForceQuery
   * F: Fn_SEARCH::verify_pager_off_pagerformat_pagerinall_ForkingSearch
   * F: Fn_SEARCH::verify_pager_off_pagerformat_pagerinall_PurePerlSearch
The search issues are topic ordering, and in one case, a very inconsistent Could not perform search. Error was: Undefined subroutine &Foswiki::Render::breakName called at /var/www/foswiki/trunk/core/lib/Foswiki/Search.pm line 1157. This failure seems to be related to test execution order, which changes on each run. Running perl  ../bin/TestRunner.pl -clean  Fn_SEARCH::test_format_token seems to fail one of the tests most of the time, but it's inconsistent.
HTMLValidationTests has 9 unexpected results (of 106):
   * F: HTMLValidationTests::verify_switchboard_function_compare_default
   * F: HTMLValidationTests::verify_switchboard_function_compare_pattern
   * F: HTMLValidationTests::verify_switchboard_function_compare_plain
   * F: HTMLValidationTests::verify_switchboard_function_compare_print
   * F: HTMLValidationTests::verify_switchboard_function_compareauth_default
   * F: HTMLValidationTests::verify_switchboard_function_compareauth_pattern
   * F: HTMLValidationTests::verify_switchboard_function_compareauth_plain
   * F: HTMLValidationTests::verify_switchboard_function_compareauth_print
   * F: HTMLValidationTests::verify_switchboard_function_save_plain
The compare* tests all fail with HTMLValidation_compareauth_print (116:3444) Warning: replacing invalid UTF-8 bytes (char. code U+00A0) consistently.

The save* tests are inconsistent. When they fail, the html status appears to be truncated:
Expected:'302'
 But got:'30'
 at /var/www/foswiki/trunk/core/lib/Unit/TestCase.pm line 325.
        Unit::TestCase::assert_num_equals(HTMLValidationTests=HASH(0x845e620), 302, 30) called at /var/www/foswiki/trunk/core/test/unit/HTMLValidationTests.pm line 376
This is the same regex bug as in the UIFnCompileTests. When Status is the very last line in the headers, the string doesn't end in a newline, and the regex looses a character of the status.
CacheTests has 19 unexpected results (of 20):
   * F: CacheTests::verify_view_DB_File_BDBMeta_Compress
   * F: CacheTests::verify_view_DB_File_BDBMeta_NoCompress
   * F: CacheTests::verify_view_DB_File_DBFileMeta_Compress
   * F: CacheTests::verify_view_FileCache_BDBMeta_Compress
   * F: CacheTests::verify_view_FileCache_BDBMeta_NoCompress
   * F: CacheTests::verify_view_FileCache_DBFileMeta_Compress
   * F: CacheTests::verify_view_FileCache_DBFileMeta_NoCompress
   * F: CacheTests::verify_view_MemoryCache_BDBMeta_Compress
   * F: CacheTests::verify_view_MemoryCache_BDBMeta_NoCompress
   * F: CacheTests::verify_view_MemoryCache_DBFileMeta_Compress
   * F: CacheTests::verify_view_MemoryCache_DBFileMeta_NoCompress
   * F: CacheTests::verify_view_MemoryHash_BDBMeta_Compress
   * F: CacheTests::verify_view_MemoryHash_BDBMeta_NoCompress
   * F: CacheTests::verify_view_MemoryHash_DBFileMeta_Compress
   * F: CacheTests::verify_view_MemoryHash_DBFileMeta_NoCompress
   * F: CacheTests::verify_view_MemoryLRU_BDBMeta_Compress
   * F: CacheTests::verify_view_MemoryLRU_BDBMeta_NoCompress
   * F: CacheTests::verify_view_MemoryLRU_DBFileMeta_Compress
   * F: CacheTests::verify_view_MemoryLRU_DBFileMeta_NoCompress
----------------------------
3103 of 3155 test cases passed(3095)+failed(8) ok from 3277 total, 122 skipped
0 + 52 = 52 incorrect results from unexpected passes + failures
1..78749


Status 2 Nov 2013


Module Failure summary

Fn_QUERY has 1 unexpected results (of 15):
  • F: Fn_QUERY::test_perl

This is due to order of hash generated by Data::Dumper. Could be resolved by adding a sort callback.

Fn_USERINFO has 1 unexpected results (of 8):
  • F: Fn_USERINFO::test_isadmin

Group order is unpredictable due to hash ordering.

Fn_SEARCH has 1 unexpected results (of 360):
  • F: Fn_SEARCH::test_orderTopic

Order of topics with a duplicate search order key is unpredictable.

HTMLValidationTests has 8 unexpected results (of 106):

UTF-8 issues.

CacheTests has 20 unexpected results (of 20):
  • F: CacheTests::verify_view_DB_File_BDBMeta_Compress
  • F: CacheTests::verify_view_DB_File_BDBMeta_NoCompress
  • F: CacheTests::verify_view_DB_File_DBFileMeta_Compress
  • F: CacheTests::verify_view_DB_File_DBFileMeta_NoCompress
  • F: CacheTests::verify_view_FileCache_BDBMeta_Compress
  • F: CacheTests::verify_view_FileCache_BDBMeta_NoCompress
  • F: CacheTests::verify_view_FileCache_DBFileMeta_Compress
  • F: CacheTests::verify_view_FileCache_DBFileMeta_NoCompress
  • F: CacheTests::verify_view_MemoryCache_BDBMeta_Compress
  • F: CacheTests::verify_view_MemoryCache_BDBMeta_NoCompress
  • F: CacheTests::verify_view_MemoryCache_DBFileMeta_Compress
  • F: CacheTests::verify_view_MemoryCache_DBFileMeta_NoCompress
  • F: CacheTests::verify_view_MemoryHash_BDBMeta_Compress
  • F: CacheTests::verify_view_MemoryHash_BDBMeta_NoCompress
  • F: CacheTests::verify_view_MemoryHash_DBFileMeta_Compress
  • F: CacheTests::verify_view_MemoryHash_DBFileMeta_NoCompress
  • F: CacheTests::verify_view_MemoryLRU_BDBMeta_Compress
  • F: CacheTests::verify_view_MemoryLRU_BDBMeta_NoCompress
  • F: CacheTests::verify_view_MemoryLRU_DBFileMeta_Compress
  • F: CacheTests::verify_view_MemoryLRU_DBFileMeta_NoCompress

The order of the script and css zones is unpredictable.


3126 of 3157 test cases passed(3119)+failed(7) ok from 3278 total, 121 skipped 0 + 31 = 31 incorrect results from unexpected passes + failures 1..79397


You marked this as waiting for my feedback .... well, I don't believe any of these should block a 1.1.9 release. There are few (if any) distros shipping with these perls, and they are really just cosmetic issues that should be fixed, but are not release blockers.

-- CrawfordCurrie - 11 Nov 2013
Topic revision: r32 - 19 Nov 2013, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy