Closed Bug 349026 Opened 14 years ago Closed 14 years ago

Find a Specific Bug for Closed bugs returns NO ROWS with perl-CGI 3.18 - 3.20

Categories

(Bugzilla :: Query/Bug List, defect, major)

2.22
defect
Not set
major

Tracking

()

RESOLVED FIXED
Bugzilla 2.22

People

(Reporter: pjdemarco, Assigned: bugzilla-mozilla)

References

Details

Attachments

(2 files, 1 obsolete file)

WFM on both tip and 2.22
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Sorry but it's not my imagination.

I've tried 3 searches from "Find a Specific Bug"

Open
Closed
All

Now searching for the word "figure" because I know there is bug 2031 that is RESOLVED FIXED that has the word "figure" in it.

Open - does not return 2031
Closed - does not return 2031
All - returns 2031
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Are you sure you have installed the most recent version of 2.22, i.e. from CVS?
Not from CVS.
I downloaded from http://www.bugzilla.org/download/
[root@lgofbgz1 bugzilla]# cvs -n update -r BUGZILLA-2_22
cvs update: Updating .
cvs update: Updating Bugzilla
cvs update: Updating Bugzilla/Auth
cvs update: Updating Bugzilla/Auth/Login
cvs update: Updating Bugzilla/Auth/Login/WWW
cvs update: Updating Bugzilla/Auth/Login/WWW/CGI
cvs update: Updating Bugzilla/Auth/Verify
cvs update: Updating Bugzilla/Config
cvs update: Updating Bugzilla/DB
cvs update: Updating Bugzilla/DB/Schema
cvs update: Updating Bugzilla/Search
cvs update: Updating Bugzilla/Template
cvs update: Updating Bugzilla/Template/Plugin
cvs update: Updating Bugzilla/User
cvs update: Updating contrib
cvs update: Updating contrib/bugzilla-submit
cvs update: Updating contrib/cmdline
cvs update: Updating contrib/gnatsparse
cvs update: Updating docs
cvs update: Updating docs/images
cvs update: Updating docs/images/callouts
cvs update: Updating docs/xml
cvs update: Updating images
cvs update: Updating js
cvs update: Updating skins
cvs update: Updating skins/standard
cvs update: Updating skins/standard/global
cvs update: Updating skins/standard/index
cvs update: Updating t
cvs update: Updating t/Support
cvs update: Updating template
cvs update: Updating template/en
cvs update: Updating template/en/default
cvs update: Updating template/en/default/account
cvs update: Updating template/en/default/account/auth
cvs update: Updating template/en/default/account/email
cvs update: Updating template/en/default/account/password
cvs update: Updating template/en/default/account/prefs
cvs update: Updating template/en/default/admin
cvs update: Updating template/en/default/admin/classifications
cvs update: Updating template/en/default/admin/components
cvs update: Updating template/en/default/admin/fieldvalues
cvs update: Updating template/en/default/admin/flag-type
cvs update: Updating template/en/default/admin/groups
cvs update: Updating template/en/default/admin/keywords
cvs update: Updating template/en/default/admin/milestones
cvs update: Updating template/en/default/admin/params
cvs update: Updating template/en/default/admin/products
cvs update: Updating template/en/default/admin/products/groupcontrol
cvs update: Updating template/en/default/admin/settings
cvs update: Updating template/en/default/admin/users
cvs update: Updating template/en/default/admin/versions
cvs update: Updating template/en/default/attachment
cvs update: Updating template/en/default/bug
cvs update: Updating template/en/default/bug/activity
cvs update: Updating template/en/default/bug/create
cvs update: Updating template/en/default/bug/process
cvs update: Updating template/en/default/bug/votes
cvs update: Updating template/en/default/email
cvs update: Updating template/en/default/flag
cvs update: Updating template/en/default/global
cvs update: Updating template/en/default/list
cvs update: Updating template/en/default/pages
cvs update: Updating template/en/default/reports
cvs update: Updating template/en/default/request
cvs update: Updating template/en/default/search
cvs update: Updating template/en/default/whine
cvs update: Updating template/en/extension
Here's some more information that might help.

[root@lgofbgz1 bugzilla]# ./checksetup.pl

Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.63
Checking for             CGI (v2.93)   ok: found v3.20
Checking for    Data::Dumper (any)     ok: found v2.121
Checking for    Date::Format (v2.21)   ok: found v2.22
Checking for             DBI (v1.38)   ok: found v1.52
Checking for      File::Spec (v0.84)   ok: found v3.19
Checking for      File::Temp (any)     ok: found v0.16
Checking for        Template (v2.08)   ok: found v2.15
Checking for      Text::Wrap (v2001.0131) ok: found v2006.0711
Checking for    Mail::Mailer (v1.67)   ok: found v1.74
Checking for    MIME::Base64 (v3.01)   ok: found v3.07
Checking for    MIME::Parser (v5.406)  ok: found v5.420
Checking for        Storable (any)     ok: found v2.15

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v2.34
Checking for     Chart::Base (v1.0)    ok: found v2.3
Checking for       XML::Twig (any)     ok: found v3.13
Checking for       GD::Graph (any)     ok: found v1.4308
Checking for GD::Text::Align (any)     ok: found v1.18
Checking for     PatchReader (v0.9.4)  ok: found v0.9.5
Checking for   Image::Magick (any)     ok: found v6.0.7

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v3.0006
Checking for           MySQL (v4.0.14) ok: found v4.1.12
(In reply to comment #5)
> [root@lgofbgz1 bugzilla]# cvs -n update -r BUGZILLA-2_22

If you use -n, you are not updating your code. Update it for real and try again.
(In reply to comment #7)
> (In reply to comment #5)
> > [root@lgofbgz1 bugzilla]# cvs -n update -r BUGZILLA-2_22
> If you use -n, you are not updating your code. Update it for real and try
> again.

I did it.  No changed files just as "cvs -n update -r BUGZILLA-2_22" said.

No changes.
Severity: blocker → major
Status: REOPENED → NEW
Okay, I've compared the queries and not surprizingly they differ in where clauses only.
-------------------------------------------------
When I search for "All"
-------------------------------------------------
WHERE (((MATCH(longdescs_0.thetext)
AGAINST('figure' ) > 0) OR (bugs.short_desc REGEXP
'(^|[^a-z0-9])figure($|[^a-z0-9])'))) AND bugs.creation_ts IS NOT NULL AND
((bug_group_map.group_id IS NULL) OR (bugs.reporter_accessible = 1 AND
bugs.reporter = 1) OR (bugs.cclist_accessible = 1 AND cc.who IS NOT NULL)
OR (bugs.assigned_to = 1) ) GROUP BY bugs.bug_id ORDER BY relevance desc
LIMIT 200

-------------------------------------------------
When I search for "Closed"
-------------------------------------------------
WHERE ((bugs.bug_status IN
('__closed__'))) AND (((MATCH(longdescs_0.thetext) AGAINST('figure' ) > 0)
OR (bugs.short_desc REGEXP '(^|[^a-z0-9])figure($|[^a-z0-9])'))) AND
bugs.creation_ts IS NOT NULL AND ((bug_group_map.group_id IS NULL) OR
(bugs.reporter_accessible = 1 AND bugs.reporter = 1) OR
(bugs.cclist_accessible = 1 AND cc.who IS NOT NULL) OR (bugs.assigned_to =
1) ) GROUP BY bugs.bug_id ORDER BY relevance desc LIMIT 200


What is __closed__ ?  It looks wrong.
Whiteboard: This is more serious than major. It should at least be critical.
WFM. Unless you can reproduce this on landfill, this is not a bug.

Here's the SQL that should be generating:

SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.bug_status, bugs.resolution, map_products.name, bugs.bug_severity, bugs.priority, bugs.op_sys, map_assigned_to.login_name, bugs.bug_status, bugs.resolution, bugs.short_desc, (SUM(MATCH(longdescs_0.thetext) AGAINST('tofu' ))/COUNT(MATCH(longdescs_0.thetext) AGAINST('tofu' )) + MATCH(bugs.short_desc) AGAINST('tofu' )) AS relevance FROM bugs INNER JOIN profiles AS map_assigned_to ON (bugs.assigned_to = map_assigned_to.userid) INNER JOIN products AS map_products ON (bugs.product_id = map_products.id) INNER JOIN longdescs AS longdescs_0 ON (bugs.bug_id = longdescs_0.bug_id ) LEFT JOIN bug_group_map ON bug_group_map.bug_id = bugs.bug_id AND bug_group_map.group_id NOT IN (8,16,4,9,14,2,17,3,12,10,11,13,1,6,15,5,7) LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who = 6777 WHERE ((bugs.bug_status IN ('RESOLVED','VERIFIED','CLOSED')) AND (bugs.product_id IN (2))) AND (((MATCH(longdescs_0.thetext) AGAINST('tofu' ) > 0) OR (bugs.short_desc REGEXP '(^|[^a-z0-9])tofu($|[^a-z0-9])'))) AND bugs.creation_ts IS NOT NULL AND ((bug_group_map.group_id IS NULL) OR (bugs.reporter_accessible = 1 AND bugs.reporter = 6777) OR (bugs.cclist_accessible = 1 AND cc.who IS NOT NULL) OR (bugs.assigned_to = 6777) OR (bugs.qa_contact = 6777) ) GROUP BY bugs.bug_id ORDER BY relevance desc LIMIT 200

That is directly from the landfill 2.22 installation, on a Closed bug search for "tofu" which returns the correct results.
Status: NEW → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → WORKSFORME
Target Milestone: Bugzilla 2.22 → ---
>> What is __closed__ ?  It looks wrong.

Closed is the option value in "Find a Specific Bug" that we use in order to indicate the user has selected a "closed" state.

There is code in Bugzilla/Search.pm that replaces "__closed__" with the actual statuses that are "closed". Here's the code taken from that file on my 2.22 installation:


    # If the user has selected all of either status or resolution, change to
    # selecting none. This is functionally equivalent, but quite a lot faster.
    # Also, if the status is __open__ or __closed__, translate those
    # into their equivalent lists of open and closed statuses.
    if ($params->param('bug_status')) {
        my @bug_statuses = $params->param('bug_status');
        if (scalar(@bug_statuses) == scalar(@::legal_bug_status)
            || $bug_statuses[0] eq "__all__")
        {
            $params->delete('bug_status');
        }
        elsif ($bug_statuses[0] eq '__open__') {
            $params->param('bug_status', map(&::IsOpenedState($_) ? $_ : undef,
                                             @::legal_bug_status));
        }
        elsif ($bug_statuses[0] eq "__closed__") {
            $params->param('bug_status', map(&::IsOpenedState($_) ? undef : $_,
                                             @::legal_bug_status));
        }
    }

(In reply to comment #11)
> >> What is __closed__ ?  It looks wrong.
> Closed is the option value in "Find a Specific Bug" that we use in order to
...
I guess I should have been more specific... WHAT'S IT DOING IN MY SQL QUERY ?
(In reply to comment #10)
> WFM. Unless you can reproduce this on landfill, this is not a bug.
nice policy.
>> I guess I should have been more specific... WHAT'S IT DOING IN MY SQL QUERY ?

Paul -- could you grep for "__closed__" in your code and make sure that it's in the same place as the code that I've pasted?

If it is, then try to see why it's not working. You know, add a "die()" in that if; I assume it never reaches there since it remains in your SQL --since you fixed some Bugzilla bugs already probably this should be pretty trivial to debug.

Also try a "cvs diff" and review that for possible issues.

>> WFM. Unless you can reproduce this on landfill, this is not a bug.
> nice policy.

We should probably do more to help with the investigation until the reporter ends up with a resolution (more details in order to be able to reproduce on landfill or detection of a local customization that's causing the effect, or maybe an upgrade issue and so on...).

Max and others have been "abused" by people who do local customizations and then use b.m.o. as a way to solve their problems, so support is nowadays "not tolerated" in b.m.o., and that's even an official thing. I don't like very much either this setup, but it's the best we have so far compared to the other alternatives :-)

Let us know what you find out!
This bug will come back up.  I never changed any code on my bugzilla installation.  And I think it's quite impossible to be *abused* if you are a volunteer.
And I don't think it's a good idea to slam the door in my face, if some feel that they're being abused.. maybe someone who thinks there could be a problem could help.

Landfill is 1 installation with 1 set of modules.  When I turn a bug in like this it should be investigaged b/c it could start showing up for others.

Vladd, thanks for the encouragement.
P.S. there's an extra die in the patch
just delete it
Comment on attachment 234582 [details] [diff] [review]
Patch for a bug that does not exist.

>+die $params->param('bug_status');
>         }
>         elsif ($bug_statuses[0] eq "__closed__") {
>-            $params->param('bug_status', map(&::IsOpenedState($_) ? undef : $_, 
>-                                             @::legal_bug_status));
>+       # PJD I had to patch this
>+       # Nobody would believe me that this wasn't working
>+       # It seemed to have to do with the leading "undef"s on the array
>+       # stored in 'bug_status'

@::legal_bug_status you mean? It should not have any undefs. Look into bug_status table and see if there is something with an undef / NULL there.

Anyway, this patch is wrong. Do not comment out code, just remove it. Further this is just a workaround and not a real fix.

>+       #  reversing the array puts the closed status types up-front
>+       # and then the search works perfectly
>+       # My guess is that it has something to do with the template code.
>+       # but I don't want to dive into it.
>+       $params->param('bug_status', map(&::IsOpenedState($_) ? undef : $_, 
>+               reverse( @::legal_bug_status)));
>+
>+# The original code doesn't work.
>+# orig $params->param('bug_status', map(&::IsOpenedState($_) ? undef : $_, 
>+# orig         @::legal_bug_status));
>         }
>     }
Attachment #234582 - Flags: review-
2.18 reports from the bug table:
| bug_status          | enum('UNCONFIRMED','NEW','ASSIGNED','REOPENED','RESOLVED','VERIFIED','CLOSED')

2.22 reports:
mysql> select * from bug_status;
+----+-------------+---------+----------+
| id | value       | sortkey | isactive |
+----+-------------+---------+----------+
|  1 | UNCONFIRMED |     100 |        1 |
|  2 | NEW         |     200 |        1 |
|  3 | ASSIGNED    |     300 |        1 |
|  4 | REOPENED    |     400 |        1 |
|  5 | RESOLVED    |     500 |        1 |
|  6 | VERIFIED    |     600 |        1 |
|  7 | CLOSED      |     700 |        1 |
+----+-------------+---------+----------+
7 rows in set (0.01 sec)
This works on 3.16. I upgraded to match the version reported here, and now it fails.

During the debug session we found out that:
  buglist.cgi?bug_status=__closed__&debug=1
produces the correct result / SQL. However, once bug_status is not the first param it fails. Eg the following does NOT work ('__closed__' in the SQL):
  buglist.cgi?debug=1&bug_status=__closed__

Perhaps we need to blacklist this version. Or find a workaroun
Summary: Find a Specific Bug for Closed bugs returns NO ROWS → Find a Specific Bug for Closed bugs returns NO ROWS with perl-CGI 3.20
Whiteboard: This is more serious than major. It should at least be critical. → Fails in perl-CGI 3.20. Works in 3.16
Works in 3.17. 3.18 was never released. Fails in 3.19+.
Summary: Find a Specific Bug for Closed bugs returns NO ROWS with perl-CGI 3.20 → Find a Specific Bug for Closed bugs returns NO ROWS with perl-CGI 3.19+
Whiteboard: Fails in perl-CGI 3.20. Works in 3.16 → Fails in perl-CGI 3.19+. Works in 3.17
Created a ticket for the CGI.pm bug:
http://rt.cpan.org/Ticket/Display.html?id=21092

The following fails to work in perl-CGI 3.18+:
  $cgi->param('foo', undef, 'C', 'D', undef);

This is due to the first undef. I think we should work around this bug.
Status: RESOLVED → REOPENED
OS: Windows 2000 → All
Hardware: PC → All
Resolution: WORKSFORME → ---
The only other theoretical problems I saw are in:
./Bugzilla/Search/Quicksearch.pm:        $cgi->param('bug_status', keys(%states));
./Bugzilla/Search/Quicksearch.pm:        $cgi->param('resolution', keys(%resolutions));

Although I do not think that will ever happen (even when the resolution has NULL/undef instead of "").

About the patch: This works around the bug and IMO is a bit cleaner.
Assignee: query-and-buglist → bugzilla-mozilla
Attachment #234582 - Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #234668 - Flags: review?(LpSolit)
Comment on attachment 234668 [details] [diff] [review]
Workaround perl-CGI bug, v1

Yeah, it makes much more sense to use grep() than map() anyway. r=LpSolit
Attachment #234668 - Flags: review?(LpSolit) → review+
Flags: approval?
Flags: approval2.22?
Target Milestone: --- → Bugzilla 2.22
Attachment #234672 - Flags: review?(LpSolit)
Comment on attachment 234672 [details] [diff] [review]
2.22 branch backport

r=LpSolit
Attachment #234672 - Flags: review?(LpSolit) → review+
Flags: approval?
Flags: approval2.22?
Flags: approval2.22+
Flags: approval+
According to the author this should be fixed in the not-yet-released 3.21.

2.22:
Checking in Search.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search.pm,v  <--  Search.pm
new revision: 1.121.2.3; previous revision: 1.121.2.2
done

tip:
Checking in Search.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search.pm,v  <--  Search.pm
new revision: 1.136; previous revision: 1.135
done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Summary: Find a Specific Bug for Closed bugs returns NO ROWS with perl-CGI 3.19+ → Find a Specific Bug for Closed bugs returns NO ROWS with perl-CGI 3.18 - 3.20
Whiteboard: Fails in perl-CGI 3.19+. Works in 3.17
*** Bug 360228 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.