92905 - editusers.cgi errors in apache errorlog: fetchrow_array failed

Status: RESOLVED FIXED

(Bugzilla :: Administration, task, P3)

Description

[Thorbjørn Weidemann]

Whenever I edit a user (select a userentry from the list of users shown by a
query to enter the user-edit page) I get this in the apache errorlog:
DBD::mysql::st fetchrow_array failed: fetch() without execute() at globals.pl
line 195.
[Tue Jul 31 08:37:07 2001] editusers.cgi: DBD::mysql::st fetchrow_array failed:
fetch() without execute() at globals.pl line 195.
In my globals.pl it is this line:
------
sub MoreSQLData {
    if (defined @::fetchahead) {
    return 1;
    }
FAILS HERE->    if (@::fetchahead = $::currentquery->fetchrow_array) {
    return 1;
    }
    return 0;
}
---------
I traced the problem to line 163 in editusers.cgi (the original 2.12 version)
which looks like this:
 while (MoreSQLData()) {
The problems seems to be that this while comes just after an if like this:
if (MoreSQLData()) {
...
}
while (MoreSQLData()) {
...
It seems that MoreSQLData() gives this error if it is called twice when there is
no more sqldata. So either the bug is that MoreSQLData does not support being
called twice in this case, or the bug is that editusers.cgi does it. The problem
occurs when the user is not a member of any isbuggroup groups.
I solved the problem at my installation by putting the whileloop inside the if
loop. I guess a more elegant solution would be to rewrite MoreSQLData so it
supports being called repeatedly even if there is no more data, but I did not
know how to do this.

Comment 1

[Dave Miller [:justdave]]

MoreSQLData() can be called repetitively.  It only looks once and caches it, and 
if it hasn't been reset, it returns the cached value on successive calls instead 
of checking the database.  The problem is elsewhere.  It may be gone, too, 
there's been a lot of changes to editusers.cgi since 2.12 came out.

Comment 2

[Thorbjørn Weidemann]

I don't think that is correct. The only way MoreSQLData can return 0 (no more
data) is in the last line, which means that fetchrow_array is called first. I
just wrote a small testprogram to confirm that fetchrow_array gives the
mentioned error if it is called after there is no more data, ie. if you do
while(MoreSQLData() {
}
if(MoreSQLData())
you get the error in the if statement.
So in short - if you call MoreSQLData() and it returns 0, and you then call
MoreSQLData again, you get the fetch without execute error.

Comment 3

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 4

[Bradley Baetz (:bbaetz)]

*** Bug 131519 has been marked as a duplicate of this bug. ***

Comment 5

[Bradley Baetz (:bbaetz)]

*** Bug 130166 has been marked as a duplicate of this bug. ***

Comment 6

[Bradley Baetz (:bbaetz)]

Attachment: patch

dave: No, MoreSQLData only caches positive results. Thats related ot the
problem we have with calling MoreSQLData but not actually rading the data if
there was any.

So if there is no data the first if returns false, then the second one tries to
read empty data.

This patch fixes that

Comment 7

[Bradley Baetz (:bbaetz)]

simple patch (if you ignore teh indenting changes I made) with a couple of
dupes, so -> 2.16

Comment 8

[Bradley Baetz (:bbaetz)]

-> patch author (me)

Comment 9

[Dave Miller [:justdave]]

Comment on attachment 74585 [details] [diff] [review]
patch

r= justdave x 2

passes tests, and seems to work just fine on my local install.	Pretty simple
change.

Comment 10

[Bradley Baetz (:bbaetz)]

Checked in.