Closed Bug 148993 Opened 24 years ago Closed 24 years ago

debug flag in buglist not working. (2.16 hack)

Categories

(Bugzilla :: Query/Bug List, defect)

Product:
Bugzilla
Component:
Query/Bug List
Version:
2.16
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.16

People

(Reporter: mat, Assigned: bbaetz)

Details

(Keywords: regression)

Attachments

(1 file)

v1
819 bytes, patch
gerv
: review+
myk
: review+
Details | Diff | Splinter Review
Sorry I forgot the comments. I get this error when $debug = 1 in buglist.cgi : malformed header from script. Bad header=<P><CODE> SELECT bugs.bug_id, : /var/www/html/bugzilla/buglist.cgi each time my server tries to execute buglist.cgi
Confirming. This isn't the debug=1 url param, but the separate flag for query generation We're not pushing out the content-type header for the $debug case. -> 2.16, cause its a regression with a 3 line patch. I'm not sure why this doesn't key off $::FORM{'debug'}, and display where the sql query does, though. It would make it easier to debug bmo if I could do that, I suspect.
Assignee: endico → bbaetz
Keywords: regression
Target Milestone: --- → Bugzilla 2.16
Attached patch v1 — — Splinter Review
OK, 7 lines, including whitespace + comments
Status: NEW → ASSIGNED
Keywords: patch, review
Shouldn't we be building a debug string and passing it to the template to print? This way, it all gets printed before <html>, which is a bit bad. Gerv
You didn't read the comment properly. At the end of GenreateHTML, we exit the perl script, entirely. No templates involved. Yes, this should probably be done with the rest of the debug stuff, rather than a variable in teh source - see my earlier comment. I guess we cna leave this for 2.16, since its not exactly a user accessible feature.
Comment on attachment 86204 [details] [diff] [review] v1 r=gerv for 2.16 only. If we want people to send us debug info (in response to an NG query, for example), then we should make this work. Gerv
Attachment #86204 - Flags: review+
Do I understand correctly that you want this on 2.16 but not on the trunk? Do we have something else planned for the trunk?
OS: Linux → All
Hardware: PC → All
Well, the 'better' fix is to push this into the template. I do note that the old pre-template code displayed this stuff on the 'please wait' page, so that you could see what was taking so long before the query timed out. I think thats a better solution. Given that, I'll check in this patch to the branch when I get home (or someone can do it for me), and work out a better patch for the trunk.
...but dn't let this stop rc2
Checking in buglist.cgi; /cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v <-- buglist.cgi new revision: 1.169.2.5; previous revision: 1.169.2.4 done Checked in to 2.16 branch. Leaving bug report open for a better fix for the trunk.
Bumping out a milestone now that a fix has been checked in for 2.16.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
let's open a new bug to continue. I hate leaving bugs open that have checkins because it makes it difficult to get stats. (Not that the stats are that meaningful - but still, if bzbot keeps telling us we have patches to check in when we really don't it gets confusing :-)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Summary: debug flag in buglist not working. → debug flag in buglist not working. (2.16 hack)
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: