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

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Colin Ogilvie [:cso]]

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.

Comment 1

[Colin Ogilvie [:cso]]

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

Comment 2

[Vlad Dascalu]

Colin: do you see this anymore? If not, what fixed it?

Comment 3

[Colin Ogilvie [:cso]]

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.

Comment 4

[Colin Ogilvie [:cso]]

Not seeing this now; and not sure exactly what fixed it either; can't reproduce
it on my test install either.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

"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

Comment 6

[Tomas Kopal]

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.

Comment 7

[Tomas Kopal]

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?

Comment 8

[Tomas Kopal]

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 :-).

Comment 9

[Tomas Kopal]

Attachment: V1

This seems to do the job...

Comment 10

[Max Kanat-Alexander]

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.

Comment 11

[Tomas Kopal]

Attachment: V1.1

Well, it still applied cleanely for me... But here it is unbitrotted anyway.

Comment 12

[Max Kanat-Alexander]

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

Cool. Yeah, that looks like the correct fix. :-)

Comment 13

[Vlad Dascalu]

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

Comment 14

[Max Kanat-Alexander]

At least on Pg, this makes Bugzilla totally unusuable (show_bug is completely
broken), so I'm going to up the severity for stats.

Comment 15

[Dave Miller [:justdave]]

show_bug doesn't even work if you're logged in.  I think that counts as a
release blocker ;)

Comment 16

[Max Kanat-Alexander]

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