Can't use an undefined value as a HASH reference at userprefs.cgi line 142.

RESOLVED FIXED in Bugzilla 2.20

Status

()

--
critical
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: cso, Assigned: Tomas.Kopal)

Tracking

({regression})

2.19.2
Bugzilla 2.20
regression
Bug Flags:
approval +
blocking2.20 +

Details

(Whiteboard: [wanted for 2.20])

Attachments

(1 attachment, 1 obsolete attachment)

3.15 KB, patch
mkanat
: review+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
I saw this error on landfill when testing for regressions for LpSolit.

Line 142 appears to be:

my @setting_list = keys %{Bugzilla->user->settings};

and according to lxr it was due to bug 98123.
(Reporter)

Comment 1

14 years ago
Note that this bug still exists despite the bug 98123 comment 27 saying it would
be resolved with another patch landing.

[Mon Apr 04 14:02:29 2005] [error] [client a.b.c.d] [Mon Apr  4 14:02:29 2005]
userprefs.cgi: Can't use an undefined value as a HASH reference at
/var/www/html/bugzilla-tip/userprefs.cgi line 142., referer:
http://landfill.bugzilla.org/bugzilla-tip/userprefs.cgi?tab=permissions

Updated

14 years ago
Flags: blocking2.20?
OS: Windows XP → All
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.20

Comment 2

14 years ago
Colin: do you see this anymore? If not, what fixed it?
(Reporter)

Comment 3

14 years ago
I think its because there now exists an option that a user can pick the value
of. I'm suspecting this is caused when there are no user-selectable settings -
which means this should be fixed as an admin can turn them all off.

I'll try and confirm this is the case later on with my test install.
(Reporter)

Comment 4

14 years ago
Not seeing this now; and not sure exactly what fixed it either; can't reproduce
it on my test install either.
"If it's not a regression from 2.18 and it's not a critical problem with
something that's already landed, let's push it off." - Dave
Flags: blocking2.20?
Whiteboard: [wanted for 2.20]
Flags: blocking2.20-
(Assignee)

Comment 6

14 years ago
I am seeing it now, on my test install (Windows, PostgreSQL). It may be
incorrect DB upgrade, as checksetup is not fully fixed for PostgreSQL yet though.
I don't have any settings (User Settings page shows "There are no settings to
edit."), and Prefs->General settings shows the same error.
I will try to investigate further, time permitting.
(Assignee)

Comment 7

14 years ago
It looks that it happens always if the 'setting' table is empty. So the question
is if it is valid to have settings table empty? I haven't found any code in
checksetup populating the table, so it's probably valid.
I guess that 'get_all_settings' and 'get_defaults' in Bugzilla::User::Settings
should return empty hash if the table is empty...
Comments?
(Assignee)

Comment 8

14 years ago
OK, I found the code to populate the table in checksetup. For some reason, it's
placed inside of the block with MySQL legacy checks and upgrade code, which is
wrong. It needs to be executed even for fresh new installs and on all DBs.
I would still like to return empty hash from the two mentioned functions, as it
will make them more robust.
I think I can do the patch now :-).
Assignee: user-accounts → Tomas.Kopal
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

14 years ago
Created attachment 181487 [details] [diff] [review]
V1

This seems to do the job...
(Assignee)

Updated

14 years ago
Attachment #181487 - Flags: review?(vladd)

Updated

14 years ago
Attachment #181487 - Flags: review?(vladd) → review+
(Assignee)

Updated

14 years ago
Flags: approval?
Flags: approval? → approval+

Comment 10

14 years ago
Comment on attachment 181487 [details] [diff] [review]
V1

Yeah, this is correct. But I can guarantee that it's been bitrotted by 285722,
because bz_change_field_type (which is in the patch context) doesn't even exist
anymore. :-)

Just a bitrot fix should do it.
Attachment #181487 - Flags: review-
(Assignee)

Comment 11

14 years ago
Created attachment 181738 [details] [diff] [review]
V1.1

Well, it still applied cleanely for me... But here it is unbitrotted anyway.
Attachment #181487 - Attachment is obsolete: true
Attachment #181738 - Flags: review?(mkanat)
(Assignee)

Updated

14 years ago
Blocks: 98304

Comment 12

14 years ago
Comment on attachment 181738 [details] [diff] [review]
V1.1

Cool. Yeah, that looks like the correct fix. :-)
Attachment #181738 - Flags: review?(mkanat) → review+

Updated

14 years ago
Flags: approval?

Updated

14 years ago
Severity: normal → major

Updated

14 years ago
Keywords: regression

Comment 13

14 years ago
Oh, common, I can't believe we're doing this now with approval+ bugs. Sheesh.

Comment 14

14 years ago
At least on Pg, this makes Bugzilla totally unusuable (show_bug is completely
broken), so I'm going to up the severity for stats.
Severity: major → critical
show_bug doesn't even work if you're logged in.  I think that counts as a
release blocker ;)
Flags: blocking2.20-
Flags: blocking2.20+
Flags: approval?
Flags: approval+

Comment 16

14 years ago
Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.400; previous revision: 1.399
done
Checking in Bugzilla/User/Setting.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/User/Setting.pm,v  <--  Setting.pm
new revision: 1.2; previous revision: 1.1
done
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Version: unspecified → 2.19.2
You need to log in before you can comment on or make changes to this bug.