302202 - "Odd number of elements in anonymous hash" error when loading query.cgi

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Rob Siklos [:robzilla]]

When you load query.cgi to create a brand new query, or edit a saved query with
no boolean charts, you get the error message:

Odd number of elements in anonymous hash at
/home/rsiklos/src/mozilla/bugzilla/query.cgi line 386

Comment 1

[Rob Siklos [:robzilla]]

Attachment: robzilla_v1

trivial fix

Comment 2

[Frédéric Buclin]

I cannot reproduce the bug, and I don't think this is the right fix. Which
version of Bugzilla have you got?

Comment 3

[Rob Siklos [:robzilla]]

actually, I can no longer reproduce according to the criteria I specified - go
figure.  

However, I do have a saved search (that has no charts), and either through some
other bug, URL optimization, or through URL hacking, there is a field0-0-0 param
and a type0-0-0 param, but no value0-0-0 param.

The absence of value0-0-0 is what was causing the error.

I'm not sure any more if this is a bug, but since URL hacking isn't altogether
discouraged, I think it can't hurt to put the fix in.  That way, if field0-0-0
is present but not type0-0-0 or value0-0-0, there won't be any errors.

Here is the query that I'm using:

query.cgi?bug_file_loc_type=allwordssubstr&bugidtype=include&chfieldto=Now&component=TestComponent&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailqa_contact2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field0-0-0=noop&long_desc_type=substring&product=TestProduct&query_format=advanced&short_desc_type=allwordssubstr&status_whiteboard_type=allwordssubstr&type0-0-0=noop

Comment 4

[Frédéric Buclin]

(In reply to comment #3)

> I'm not sure any more if this is a bug, but since URL hacking isn't altogether
> discouraged, I think it can't hurt to put the fix in.  That way, if field0-0-0
> is present but not type0-0-0 or value0-0-0, there won't be any errors.

I'm not a big fan of this kind of hack. If the URL is corrupted, the right fix
is to find which part of the code is the culprit. If you hacked the URL
manually, that's your problem and having a line or two in your apache error_log
file doesn't hurt.

I also have saved searches which do not use boolean charts, but all fields are
present.

/me hesitates to invalidate or wontfix this bug.

Comment 5

[Rob Siklos [:robzilla]]

> If you hacked the URL manually, that's your problem and having a line or two 
> in your apache error_log file doesn't hurt.

I disagree.  In my opinion, in an ideal world there should be no way to cause a
perl error to appear the error log.  No matter what Joe User does (url fiddling,
hacking attempts, etc), everything should be handled in a graceful way.

The error log needs to be as clean as possible (no matter what your stupid users
try and do) so that REAL errors don't get lost in all the clutter.

I agree, this is a minor issue, but clean error logs (aside from 404 and 403
errors) are really nice.

Comment 6

[Teemu Mannermaa (:wicked)]

I have run across this error. When I simply 1) select only one item from any of
the selection boxes (bug status, resolution, severity, product...) on search, 2)
click Search and then 3) click on the Edit Search link following error is
recorded in the error log every time:

[Wed Aug 17 07:42:44 2005] [error] [client 192.168.1.5] [Wed Aug 17 07:42:44
2005] query.cgi: Odd number of elements in anonymous hash at
/var/www/html/workcopies/cvstip/query.cgi line 386., referer:
http://bugserv.int.etlicon.net/cvstip/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I end up in URL
http://bugserv.int.etlicon.net/cvstip/query.cgi?bug_file_loc_type=allwordssubstr&bug_status=REOPENED&bugidtype=include&chfieldto=Now&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_status&field0-0-0=noop&keywords_type=allwords&long_desc_type=substring&query_format=advanced&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type0-0-0=noop&value-1-0-0=REOPENED
Note how the value-1-0-0= gets value of the selected item!

This happens only on tip so seems not to affect the 2.20 branch.

Comment 7

[Teemu Mannermaa (:wicked)]

Comment on attachment 190558 [details] [diff] [review]
robzilla_v1

This does indeed fix the error log entry, hence r+. I'm not quite sure if this
is the right fix, though. Also it doesn't fix URL corruption.

Comment 8

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

Sounds like this isn't a question of URL hacking but rather a bug in Bugzilla. 
If so, we should find that bug.

Comment 9

[Dave Miller [:justdave]]

This patch does indeed do what I would expect Bugzilla to do upon getting a URL
in this condition (treat the unpassed fields as if they were passed blank).  On
the premise of removing garbage from the error log, approving also for 2.20 (the
patch applies cleanly).

Comment 10

[Frédéric Buclin]

tip:

Checking in query.cgi;
/cvsroot/mozilla/webtools/bugzilla/query.cgi,v  <--  query.cgi
new revision: 1.149; previous revision: 1.148
done

2.20rc2:

Checking in query.cgi;
/cvsroot/mozilla/webtools/bugzilla/query.cgi,v  <--  query.cgi
new revision: 1.146.2.1; previous revision: 1.146
done