Closed Bug 92905 Opened 19 years ago Closed 18 years ago

editusers.cgi errors in apache errorlog: fetchrow_array failed

Categories

(Bugzilla :: Administration, task, P3)

2.12
x86
Linux

Tracking

()

RESOLVED FIXED
Bugzilla 2.16

People

(Reporter: tbjoern, Assigned: bbaetz)

References

Details

Attachments

(1 file)

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.
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.
Target Milestone: --- → Bugzilla 2.16
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.
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
Version: Bugzilla 2.12 → 2.12
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
*** Bug 131519 has been marked as a duplicate of this bug. ***
*** Bug 130166 has been marked as a duplicate of this bug. ***
Attached patch patchSplinter Review
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
simple patch (if you ignore teh indenting changes I made) with a couple of
dupes, so -> 2.16
Keywords: patch, review
Priority: -- → P3
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
-> patch author (me)
Assignee: justdave → bbaetz
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.
Attachment #74585 - Flags: review+
Checked in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Blocks: 119485
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.