263448 - internal error querying a bug when its component has been deleted

Status: RESOLVED WORKSFORME

(Bugzilla :: Query/Bug List, defect)

Description

[Andy Brook]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 StumbleUpon/1.998
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 StumbleUpon/1.998

Internal site, no link sorry.

I have about 100bugs, when I list them I see greyed background, except this one
issue, currently marked as Resolved/Fixed.  If I try and drill down, oh boy, I
get the 'red screen of death' RSOD, will be attached.  So I cannot see what was
done under the issue.

Error starts with:

'undef error - DBD::mysql::st execute failed: You have an error in your SQL
syntax. Check the manual that corresponds to your MySQL server version for the
right syntax to use near 'WHERE isbuggroup = 1' at line 1 [for Statement "SELECT
DISTINCT groups.id, name, description'

I have 2.18rc2 running on Suse UnitedLinux 1.0, SMP. 
MySql version is 4.0.21 i686, downloaded from mysql site.
Perl Versions,
AppConfig 1.56
CGI 3.05
Data::Dumper 2.12
Date::Format 2.22
DBI 1.43
DBD::mysql 2.9004
File::Spec 3.01
File::Temp 0.14
Template 2.13
Text::Wrap 2001.0131


Reproducible: Always
Steps to Reproduce:
Its specific to this one bug.  I've ruled out any tweaks Ive made to bugzilla
templatess by using a fresh 2.18rc2 zip

1. enter the bug id or navigate to it
2. observe RSOD
3.

Actual Results:  
RSOD

Expected Results:  
Show me the bug

default config with only global 'Bug' -> 'Ticket' kind of translations

Comment 1

[Andy Brook]

Attachment: Red Screen of Death, bug query failure

Comment 2

[Andy Brook]

Ive just done a sanity check, it tells me the following:

Bad values 4, 16 found in bugs.product_id / bugs.component_id (bug 51) 
Bad values 3, 17 found in bugs.product_id / bugs.component_id (bug 78) 

a) I dont know how they got there
b) how to fix...

Comment 3

[Andy Brook]

The problem was that two of the most recent components had been deleted, but I'm
confused as to how can this happen 'normally'? If I try to delete the component
through bugzilla I am required to move the bug first, this obviously didnt occur.  

So, I've recreated the categories and all is wellm, for now.

Comment 4

[Dave Miller [:justdave]]

ok, looking at the query that it attempted to run in the error, this is
definitely a result of the database corruption that you found.  On the one hand,
it'd be nice to make it do something sane when it runs into this, but on the
other hand, all kinds of weird things can happen when there's hanging references
in the database.

Since it was a corruption issue, this won't block 2.18.  We should probably
investigate how it's looking up the product_id here, since that's obviously
being queried before the main query is generated.  The place where it's looking
up the product needs to throw some kind of error that the ID doesn't exist
instead of blindly using an empty string (or probably even an undef?)

Comment 5

[Dave Miller [:justdave]]

We have people around that like to hack on little stuff like this now, let's see
if we can get it in for 2.20

Comment 6

[GavinS]

I've had a look at this -- the question is: Should the bug object creation fail
if the product_id is not found, or should everywhere which uses the product_id
check it?

Comment 7

[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 8

[Frédéric Buclin]

(In reply to comment #3)
> The problem was that two of the most recent components had been deleted, but I'm
> confused as to how can this happen 'normally'? If I try to delete the component
> through bugzilla I am required to move the bug first, this obviously didnt
occur.  

The problem is that prior to 2.19.3, deleting a component only deleted bugs if
Param("allowbugdeletion") was turned on; else bugs were left in the DB with an
invalid reference to a deleted component, see bug 86328! In other words,
component deletion was buggy.

Btw, I cannot reproduce your RSOD. The bug is displayed in buglist and viewing
it shows all fields empty. But no error is generated.


(In reply to comment #6)
> I've had a look at this -- the question is: Should the bug object creation fail
> if the product_id is not found, or should everywhere which uses the product_id
> check it?

That's the reason I'm CCing mkanat, myk and justdave. The actual behavior of
"new Bugzilla::Bug" is to return an empty object if the bug object creation was
not successful, meaning that additional checks have to be done outside Bug.pm to
make sure that this bug object is valid.

Discussing this point with mkanat and myk shows that we all agree that this is
not an acceptable solution. Maybe it was fine for 2.20, but now we have to think
what we really expect when either a bug is not accessible by the user or the bug
contains corrupted data as in the example above.

I see no reason why we would need to return an empty object, but assuming there
is a good reason for that (mkanat, can you develop what you told me in IRC
yesterday), here is what I suggest:

- new Bugzilla::Bug silently fails if there is an error of any kind as it
actually does;
- Bugzilla::Bug::ValidateBugID() calls new Bugzilla::Bug instead of having its
own code and complains if the bug object is empty.

What I have in mind is something similar to CanEnterProduct() (silently "fails")
and CanEnterProductOrWarn() (displays an error if the product is not accessible
for some reason).

Any comment?

Comment 9

[Max Kanat-Alexander]

(In reply to comment #8)
  As far as the behavior of Bugzilla::Bug, most of that should probably be
discussed in a different bug. But the problem is that ThrowUserError won't
produce valid XML for the XML ctype for show_bug. In fact, if we ever had
another show_bug ctype, it wouldn't produce anything valid for that, either.

Comment 10

[Frédéric Buclin]

As I said in comment 8, I cannot reproduce this problem and thanks to bug 86328
and bug 288461, bug deletion now works correctly. Moreover, "corrupted" DB can
now be fixed by running sanitycheck.cgi. Marking WFM.