303903 - Displaying an existing bug always leads to 15+ lines of error messages similar to "show_bug.cgi: Use of uninitialized value in .... at C:/Perl/lib/Time/Local.pm"

Status: VERIFIED DUPLICATE of bug 281920

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Edward Chan]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Bugzilla Version 2.20rc2

Environment is: WinXP 2002 SP1
Version: 2.20rc2
Previous version: 2.18 (which worked perfectly)

Displaying any existing bug, under any condition, always leads to over 15 
lines or error messages similar to "show_bug.cgi: Use of uninitialized value 
in .... at C:/Perl/lib/Time/Local.pm" prefixing the Bugzilla bug details.  All 
details shows up correctly and with the correct values.

This is replicated 100% of the time, even using the default templates, and is 
a serious issue preventing us from releasing the new version of Bugzilla.  A 
screenprint has been attached.

Reproducible: Always

Steps to Reproduce:
1.Display an existing bug (by any means including selecting it directly or 
picking it off of a list)

Actual Results:  
Over 15 lines similar to "show_bug.cgi: Use of uninitialized value in .... at 
C:/Perl/lib/Time/Local.pm" were displayed prior to the details of the bug 
being displayed "correctly".

Expected Results:  
Just displayed the bug details (only) without the 15 lines of error messages,

previous version 2.18 worked fine.

Comment 1

[Edward Chan]

Attachment: Screenshot of error with Version 2.20rc2 (on WinXP 2002, SP1).

This used to work fine with 2.18.

Comment 2

[Olav Vitters]

Did you run checksetup.pl? Are you sure all modules are the correct versions?
Did you change any of the templates or Bugzilla? Version of Perl?

Comment 3

[Frédéric Buclin]

Next time, please attach an image instead of a MS Word document so that we can
display it from the browser directly.

I have never seen this error on my local installation (MySQL/Linux) and it
doesn't appear on landfill.

glob, is that something you can reproduce on Windows?

Comment 4

[Edward Chan]

Yes I ran checksetup.pl.  Yes this problem occurs with the standard templates as
well as with our own customized templates.  We are running the recommended
active perl version of around three months ago (it was the latest version back
then - I have to check the exact version when I get back to work).  Regardless,
switching back to the 2.18.2 version (after installing 2.20rc2)  results in
everything working fine with this version of perl.  Switch back to 2.20 rc2 and
the problem continues.  Perl seems fine.

I am wondering if my data (from my 2.18 format) has issues when it is converted
from 2.18 to 2.20rc2 format.  We did use the OS and hardware fields for our own
purposes and this is an area that was directly affected with this new release.

As a "workaround", I have added the "-X" parameter (i.e. surpresses perl error
messages) to the perl commandline that is called within Windows IIS. 
Superficially, everything works, but the errors are still occuring.

Comment 5

[Max Kanat-Alexander]

This is a known bug in ActiveState Perl 5.8.6, from what I know. Try using some
other version. I believe this is mentioned either in the docs or in the Release
Notes.

Comment 6

[Edward Chan]

Thanks for this.  I cannot see this in the release notes anywhere but will have
another look.  The Bugzilla documentation (i.e. 2.4.1.1. under 2.4 OS specific
installations) specifically recommends using ActiveState Perl so I went out and
installed the latest version, which worked fine with 2.18.  Other people may do
the same.

Are you recommending I downgrade Active Perl from 5.8.6 to 5.8.1 in order to
upgrade Bugzilla or jump to a different perl compiler entirely?  Also, is the
error serious or can I get away with simply surpressing all the error messages
using the -X parameter when calling the perl comipler?

Comment 7

[:glob ✱]

*** This bug has been marked as a duplicate of 281920 ***

Comment 8

[Edward Chan]

Upgraded to Perl 5.8.7 and it works.  Thanks.