Closed Bug 349210 Opened 18 years ago Closed 18 years ago

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

Categories

(Bugzilla :: Whining, defect, P1)

Product:
Bugzilla
Component:
Whining
Version:
2.22
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: pjdemarco, Unassigned)

Details

Attachments

(2 files)

Patch avoids the warning
1.09 KB, patch
LpSolit
: review-
Details | Diff | Splinter Review
Checksetup Output
2.72 KB, text/plain
Details
[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.
Can I see the output of checksetup.pl for your installation?
Also, does sanitycheck complain about anything?
I know whine.pl on 2.22 is working correctly, because I have it in a cron job on landfill.
bug 349026, comment 6 has my checksetup output. sanitycheck has no complaints.
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
Closed: 18 years ago
Resolution: --- → WORKSFORME
As discussed on IRC, Colin's having the same troubles. So it's not a local problem.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
This avoids the message. Not exactly sure why it works.
Not sure if I'm having the problem with whine - it was cropping up for me in process_bug.cgi.
Attached file Checksetup Output —
Looks like whine is affected, attached is the checksetup output.
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.
I'm seeing the same thing on a Bugzilla installation. See also bug 261821 .
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?
(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 :(
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?
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 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 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?
Flags: blocking2.22.1?
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
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.
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?
Yep, blocker, just like I said in comment 19. :-)
Flags: blocking2.22.2? → blocking2.22.2+
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. :(
(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.
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. :)
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.
(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
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
Closed: 18 years ago → 18 years ago
Resolution: --- → INVALID
Target Milestone: Bugzilla 2.22 → ---
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-
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.

Attachment

General

Creator:
Created:
Updated:
Size: