Whine.pl doesn't seem to work from command line nor cron.

RESOLVED INVALID

Status

()

Bugzilla
Whining
P1
major
RESOLVED INVALID
12 years ago
11 years ago

People

(Reporter: Paul, Unassigned)

Tracking

Bug Flags:
blocking2.22.2 -
blocking2.22.1 -

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
[bugzilla]# ./whine.pl
[Fri Aug 18 15:57:10 2006] whine.pl: DBI::db=HASH(0xa0ba7bc)->disconnect invalidates 3 active statement handles (either destroy statement handles or call finish on them before disconnecting) at Bugzilla.pm line 298.

Comment 1

12 years ago
Can I see the output of checksetup.pl for your installation?

Comment 2

12 years ago
Also, does sanitycheck complain about anything?

Comment 3

12 years ago
I know whine.pl on 2.22 is working correctly, because I have it in a cron job on landfill.
(Reporter)

Comment 4

12 years ago
bug 349026, comment 6 has my checksetup output.

sanitycheck has no complaints.

Comment 5

12 years ago
Okay. Well, this is completely unreproduceable from my end. It works on all the installations I know of, running 2.22.

Those error messages indicate that at some point the database is returning more data than we expected, which should never happen. That is, sometimes when we expect one row it's returning more than one row. That looks to be a local problem.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

12 years ago
As discussed on IRC, Colin's having the same troubles.  

So it's not a local problem.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 7

12 years ago
I can reproduce as well.

Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.56
Checking for             CGI (v2.93)   ok: found v3.19
Checking for    Data::Dumper (any)     ok: found v2.121_08
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.12
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 v2005.082401
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 Template::Plugin::GD::Image (any)     ok: found v1.56
Checking for     Chart::Base (v1.0)    ok: found v2.4.1
Checking for       XML::Twig (any)     ok: found v3.26
Checking for       GD::Graph (any)     ok: found v1.43
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.2.8
Status: REOPENED → NEW

Comment 8

12 years ago
Created attachment 234717 [details] [diff] [review]
Patch avoids the warning

This avoids the message. Not exactly sure why it works.

Comment 9

12 years ago
Not sure if I'm having the problem with whine - it was cropping up for me in process_bug.cgi. 

Comment 10

12 years ago
Created attachment 234803 [details]
Checksetup Output

Looks like whine is affected, attached is the checksetup output.

Comment 11

12 years ago
That's extremely strange. Basically, if you have to call ->finish on an sth, it means that it contains data that was never used. We should never be getting into that situation.

Comment 12

12 years ago
I'm seeing the same thing on a Bugzilla installation. See also bug 261821 .

Comment 13

12 years ago
Comment on attachment 234717 [details] [diff] [review]
Patch avoids the warning

This looks good. That's how we fixed it in bug 261821 AFAIK.
Attachment #234717 - Flags: review?
(Reporter)

Comment 14

12 years ago
(In reply to comment #13)
> This looks good. That's how we fixed it in bug 261821 AFAIK.

bug 261821 wasn't backported to 2.22 :(

Comment 15

12 years ago
By looking at your patch, the problem seems to only occur with ->fetch, ->fetchrow and ->fetchall in loops. If you use ->selectrow and ->selectall instead, does it fix the problem for you?

Comment 16

12 years ago
I first thought there could be a relation between this bug and bug 306036, but I'm not sure (it's hard to investigate when your installation is working fine ;)).

Comment 17

12 years ago
Comment on attachment 234717 [details] [diff] [review]
Patch avoids the warning

It's true that this patch fixes the problem. However, before we accept this patch, we should have an explanation of *why* the problem is occuring. That is, why do these statement handles still have data in them?

In bug 261821 there was a good reason. I'd like to know the reason here before we accept this patch.
Attachment #234717 - Flags: review? → review-

Comment 18

12 years ago
Comment on attachment 234717 [details] [diff] [review]
Patch avoids the warning

Agreed.

Sorry, if you want to review- it, you'll actually have to go look for the reason yourself. If you don't do that you can't know if this is the right fix or not, so review- is unappropiate.
Attachment #234717 - Flags: review- → review?
(Reporter)

Updated

12 years ago
Flags: blocking2.22.1?

Comment 19

12 years ago
We're really close to release, and there's been very little action on this bug. I'd be willing to block 2.22.2 on it, but I'm hesitant to block 2.22.1 this close to release, when we're not even certain of the root cause of the bug, yet.
Flags: blocking2.22.1? → blocking2.22.1-
Priority: -- → P1
Target Milestone: --- → Bugzilla 2.22

Comment 20

11 years ago
I'm seeing this problem now too, after recently having moved our bugzilla installation from a RedHat 9 server to a Fedora Core 5 server.

Here's the error I get from the cron job:
[Thu Oct  5 04:00:06 2006] whine.pl: DBI::db=HASH(0x92808b0)->disconnect invalidates 3 active statement handles (either destroy statement handles or call finish on them before disconnecting) at Bugzilla.pm line 298, <NOMAIL> line 1.

And here's my checksetup output:
Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.63
Checking for             CGI (v2.93)   ok: found v3.15
Checking for    Data::Dumper (any)     ok: found v2.121_08
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.12
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 v2005.082401
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.35
Checking for     Chart::Base (v1.0)    ok: found v2.4.1
Checking for       XML::Twig (any)     ok: found v3.23
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.2.5

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v3.0004
Checking for           MySQL (v4.0.14) ok: found v5.0.22
Checking for        GraphViz (any)     ok: found

My data/nomail file has a single address in it on a single line.  Not sure if that's relevant, but it might be as the error has NOMAIL in it.
(Reporter)

Comment 21

11 years ago
I honestly don't know how we can release any more 2.22 versions with this known bug.
Severity: normal → major
Flags: blocking2.22.2?

Comment 22

11 years ago
Yep, blocker, just like I said in comment 19. :-)
Flags: blocking2.22.2? → blocking2.22.2+

Comment 23

11 years ago
I upgraded my distro which now contains MySQL 5.0.24 instead of 4.1.12, and I now get similar messages in my web server error log, but for all CGI scripts. Does MySQL 5.x requires us to explicitly close handles before disconnecting? I would hate to add $sth->finish everywhere in all scripts. :(
(Reporter)

Comment 24

11 years ago
(In reply to comment #23)
> I upgraded my distro which now contains MySQL 5.0.24 instead of 4.1.12, and I

I don't think it's MySQL.  You probably upgraded other packages along with it.  Check those.

Comment 25

11 years ago
Well, if it's not MySQL, then it's either DBI or DBD::mysql. As I updated my distros, *all* modules have been upgraded. This doesn't help to find the culprit. :)

Comment 26

11 years ago
I cannot reproduce the problem running PostgreSQL 8.1.5 so DBI is probably not the problem. Looking at the changelog for DBD::mysql, I can read:

(3.0007_1)

  * Make sure to call dbd_st_finish when all rows from a statement handle
    have been fetched. (Bug #20153, Bug #21607, RT #20464, RT #21241)

The user in comment 20 reported he is using DBD::mysql 3.0004, and I'm using 3.0006. This could be the reason.

Comment 27

11 years ago
(In reply to comment #26)
> The user in comment 20 reported he is using DBD::mysql 3.0004, and I'm using
> 3.0006. This could be the reason.
> 

I'm pretty sure it's DBD::mysql.  I recently upgraded our Bugzilla server from Fedora 5 to Fedora 6.  That included DBD::mysql 3.0007 and I'm no longer seeing that error.  Here's my checksetup.pl output now, so you can compare it to that of my earlier post in comment 20.  Notice that DBI didn't change versions, and actually not much did...but DBD::mysql is one of the things that did.

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

Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.63
Checking for             CGI (v2.93)   ok: found v3.15
Checking for    Data::Dumper (any)     ok: found v2.121_08
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.12
Checking for      File::Temp (any)     ok: found v0.16
Checking for        Template (v2.10)   ok: found v2.15
Checking for      Text::Wrap (v2001.0131) ok: found v2005.082401
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.35
Checking for Template::Plugin::GD::Image (any)      not found
Checking for     Chart::Base (v1.0)    ok: found v2.4.1
Checking for       XML::Twig (any)     ok: found v3.26
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.2.8
Checking for    HTML::Parser (v3.40)   ok: found v3.55
Checking for  HTML::Scrubber (any)     ok: found v0.08

If you you want to see graphical bug reports (bar, pie and line charts of
current data), you should install libgd and the following Perl modules:

Template::Plugin::GD: /usr/bin/perl -MCPAN -e 'install "Template::Plugin::GD"'

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v3.0007
Checking for           MySQL (v4.0.14) ok: found v5.0.22
Checking for        GraphViz (any)     ok: found

Comment 28

11 years ago
OK, this is a bug in DBD::mysql 3.0003 - 3.0006 and has been fixed in 3.0007:

http://bugs.mysql.com/bug.php?id=20153

So either downgrade to 3.0002 or upgrade to 3.0007. So this is not a bug in Bugzilla => INVALID.
Status: NEW → RESOLVED
Last Resolved: 12 years ago11 years ago
Resolution: --- → INVALID
Target Milestone: Bugzilla 2.22 → ---

Comment 29

11 years ago
Comment on attachment 234717 [details] [diff] [review]
Patch avoids the warning

Per my previous comment, this is not a bug in Bugzilla but in DBD::mysql.
Attachment #234717 - Flags: review? → review-

Comment 30

11 years ago
And INVALID means that this is not a blocker.
Flags: blocking2.22.2+ → blocking2.22.2-
You need to log in before you can comment on or make changes to this bug.