Closed Bug 465375 Opened 16 years ago Closed 15 years ago

please create a 'checked-in' flag for attachments in all of the Release Engineering components

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: timeless)

References

Details

To be clear, that is the following components:
Release Engineering
Release Engineering: Talos
Release Engineering: Maintenance
Release Engineering: Future
Please read bug 115514 first, and if you still think this is the best way to do this at this time, then we'll be happy to implement this for you.
OS: Mac OS X → All
Hardware: PC → All
I've read the majority of that bug and I can say that we want exactly that.
Do you need a 'requested' state for this, or just grant/deny/nothing?

Also, a description would be useful.
?, +, -, and null would be great.

As for description........"When set to '+' it indicates that the patch or file has been checked into version control." ?
created
Assignee: marcia → timeless
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Thanks!
Status: RESOLVED → VERIFIED
Not sure what happened here but when I tried to use the checked-in flag today I got the following error page:
Software error:

Insecure dependency in parameter 9 of DBI::db=HASH(0xa35d180)->do method call while running with -T switch at /data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm line 633.

For help, please send mail to the webmaster (bugzilla-admin@mozilla.org), giving this error message and the time and date of the error.

--

Note that if I unset the checked-in flag I don't get an error.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
So, this flag works fine on newer bugs (ones created after the flag was created?), but doesn't on older ones.

For example, works on:
https://bugzilla.mozilla.org/show_bug.cgi?id=465352

doesn't work on:
https://bugzilla.mozilla.org/show_bug.cgi?id=462320
(In reply to comment #8)
> doesn't work on:
> https://bugzilla.mozilla.org/show_bug.cgi?id=462320

WFM
OK, it must be intermittent then. Because I've hit it on various bugs today...
Maybe justdave hacked the SQL statement in Bugzilla::Flag::update_activity()? I doubt this is an upstream bug.
BTW, this seems a much better use-case to use the new attachment-specific "Fixed In" field. But it does sound like there's some bug in the customizations here.
What does:

/data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm line 633.

match with? in bzr its:

    my ($bug_id, $attach_id, $timestamp, $old_summaries, $new_summaries) = @_;

at the top of update_activity, which is obviously not going to cause taint issues.
Yeah, that's the same as it is in production currently.
Just noticed the timestamps... the original report of this bug was before we upgpraded.  Prior to the upgrade, line 633 was this:

        $dbh->do('INSERT INTO bugs_activity
                  (bug_id, attach_id, who, bug_when, fieldid, removed, added)
                  VALUES (?, ?, ?, ?, ?, ?, ?)',
                  undef, ($bug_id, $attach_id, Bugzilla->user->id,
                  $timestamp, $field_id, $removed, $added));
bhearsum says in comment 12 that he hit this again since the upgrade.
Gentle ping...any idea when someone will be able to investigate this? Should I file it upstream?

I hit it again today
(In reply to comment #18)
> Gentle ping...any idea when someone will be able to investigate this? Should I
> file it upstream?

I really don't think it's an upstream bug.
Was anything else being changed at the same time (eg added comment, 'edit attachment as comment', another flag, etc)

Its weird - its not like attachment flags are uncommon, and if r+ was broken I assume that we would have heard about it by now.
Hmm, the - in 'checked-in' isn't a -; its some unicode character. I wonder if
thats confusing some regexp somewhere? Ben, what OS are you on?
(In reply to comment #21)
> Hmm, the - in 'checked-in' isn't a -; its some unicode character.

  I think that's only true in the UI, not in the backend. It's going through FILTER no_wrap.
oh, hmm. about all I can think of is adding some if(is_tainted($added)) wrapped debug code.
Alright, just hit this again, but the conditions are different (here's the traceback, once more):
Software error:

Insecure dependency in parameter 8 of DBI::db=HASH(0xaeb8250)->do method call while running with -T switch at /data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm line 641.

For help, please send mail to the webmaster (bugzilla-admin@mozilla.org), giving this error message and the time and date of the error.



---

This time, I had just modified an attachment to grant the 'checked-in' flag. Then, I went back to the attachment to add a comment and grant the review flag. When I tried to submit that change, I got the above error. Maybe this has something to do with multiple flags in a non null state? Dunno.
(In reply to comment #7)
> Insecure dependency in parameter 9 of DBI::db=HASH(0xa35d180)->do method call
> while running with -T switch at /data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm
> line 633.

(In reply to comment #24)
> Insecure dependency in parameter 8 of DBI::db=HASH(0xaeb8250)->do method call
> while running with -T switch at /data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm
> line 641.

How can the line and parameter ID change between both comments??


> This time, I had just modified an attachment to grant the 'checked-in' flag.
> Then, I went back to the attachment to add a comment and grant the review flag.

Went back how? By clicking the "Back" button of Firefox?
(In reply to comment #25)
> How can the line and parameter ID change between both comments??

Bugzilla 3.2rc2+ upgrade happened between the two comments.
I'm pretty sure I've narrowed this down to only happening when I change two flags at once. For example, granting review and checked-in at the same time. This just happened to me in https://bugzilla.mozilla.org/attachment.cgi?id=349244&action=edit. I tried to grant review, checked-in, and add a comment at the same time -- which caused me to get a traceback.

To work around, I granted review, added the comment, and submitted - which worked. Then I granted 'checked-in' separately -- which also worked.
If it fails, and you go back and try the exact same change again, does it still fail?
If I go back and try again, it still fails.
Alright, I just hit this again.
STR:
granted r+, checked-in+, and added a comment to https://bugzilla.mozilla.org/attachment.cgi?id=350146&action=edit

Got this traceback:
Software error:

Insecure dependency in parameter 9 of DBI::db=HASH(0xbaf52a8)->do method call while running with -T switch at /data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm line 641.

For help, please send mail to the webmaster (bugzilla-admin@mozilla.org), giving this error message and the time and date of the error. 

Hit back, tried to do it again, got the exact same traceback

Navigated away, and back to the page (not using the back button) - performed the same thing - got the same traceback.

Hit back, changed checked-in to a null state, submitted - no traceback.

Clicked 'details' for the attachment again, granted checked-in, submitted - no traceback.
So the problem only occurs with the checked-in flag, and only when this flag was set to "?" initially? Or does this crash also occur when going from blank to + directly? I tried locally, but I really cannot reproduce the error.
Sorry, I didn't see your comment Frederic. I don't think I get this when going from blank -> +.

Here's a good example:
On https://bugzilla.mozilla.org/attachment.cgi?id=353943&action=edit I want to grant review, but when I try to I get a traceback. (Insecure dependency in parameter 8 of DBI::db=HASH(0x9fc48a8)->do method call while running with -T switch at /data/www/bugzilla.mozilla.org/Bugzilla/Flag.pm line 641.)

Note that checked-in has been granted previously and the initial state of the review flag is '?'.

Can you reproduce with that attachment?
(In reply to comment #32)
> Can you reproduce with that attachment?

I can. If I try to comment while granting review, it crashes. If I only grant review, it works fine. Also, if I comment while moving from r+ to r-, it works fine; but it fails if I comment while requesting review, or if I go from r? to r+. So the problem seems related to comments and the request state. This doesn't make sense at all as comments are not inserted by Bugzilla::Flag::update_activity(), and other field data come from the DB, which cannot be tainted.

Is there some extension applied to bmo which interacts with flags and which could taint data (I have the PGP code in mind)?
(In reply to comment #33)
> Is there some extension applied to bmo which interacts with flags and which
> could taint data (I have the PGP code in mind)?

  The GPG patch was applied after this started happening, so it can't be the culprit. You can check out the current bmo code from here using bzr:

   http://dm-bugstage01.mozilla.org/bmo/3.2/
FWIW I hit this today trying to set review+, checked-in+ and adding a comment to bug 433595.
hit this today on bug 459269 trying to add attachment with checked-in? and replacing a previous patch.  Couldn't get it to work at all after that even with cache cleared and not setting checked-in? - ended up working with checked-in? and *not* replacing the patch.
This is still routinely a problem for us. https://bugzilla.mozilla.org/show_bug.cgi?id=502608 / https://bugzilla.mozilla.org/attachment.cgi?id=389558&action=edit is a big offender right now. I'm trying to add a comment and grant checked-in on that attachment and most of the time I get a traceback. It finally just worked for me after 5 attempts.
For some reasons, bmo also reports some "Insecure dependency" errors when viewing some attachments in diff mode with context=file while they load correctly locally. I don't know what's wrong with bmo. Maybe a too old Perl module somewhere (maybe DBI or DBD::mysql?).
(In reply to comment #39)
> For some reasons, bmo also reports some "Insecure dependency" errors when
> viewing some attachments in diff mode with context=file while they load
> correctly locally. I don't know what's wrong with bmo. Maybe a too old Perl
> module somewhere (maybe DBI or DBD::mysql?).

Dave, is there any way to test for this?
I wonder if bug 506978 has anything to do with this. I'll try modifying the hyphen used.
(In reply to comment #41)
> I wonder if bug 506978 has anything to do with this. I'll try modifying the
> hyphen used.

I haven't seen this yet today, fwiw.
(In reply to comment #41)
> I wonder if bug 506978 has anything to do with this. I'll try modifying the
> hyphen used.

I still haven't seen any more occurrences, it looks like this fixed it.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → FIXED
(In reply to comment #43)
> I still haven't seen any more occurrences, it looks like this fixed it.

This is not fixed, see bug 509794 comment 9.
Depends on: 509794
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.