Closed Bug 1045980 Opened 5 years ago Closed 5 years ago

[MTBF][B2G][Stability] 319 Flame failed and homescreen button doesn't work

Categories

(Firefox OS Graveyard :: Stability, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+)

RESOLVED FIXED
2.1 S2 (15aug)
blocking-b2g 2.0+

People

(Reporter: wachen, Unassigned)

References

Details

Attachments

(1 file)

http://mtbf-1:8080/view/v2.0/job/flame.v2.0.mtbf.319/44/label=mtbf-6/

Gaia      8cb1a949f2e9650bb2c5598e78a6f24a58bbaf97
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/4bd4b0ae7bbe
BuildID   20140721000201
Version   32.0a2
ro.build.version.incremental=109
ro.build.date=Mon Jun 16 16:51:29 CST 2014

STR: 
Setup MTBF test
Test suite including keyboard, sms, music
Randomly run automation test cases for about 2~6 hours.

EXPECT: Home button works

ACTUAL: It stucked in Contacts app (keyboard test case). Home button doesn't work
Attached file logcat_44.txt
Blocks: MTBF-B2G
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
I've seen this bug happened in full memory, 273, and 319
Walter - This is a MTBF-blocker gaia/gecko bug that's causing us to not hit 100 MTBF on 319 MB right now, right? If so, should we nominate this to block 2.0?
Flags: needinfo?(wachen)
dolphin v1.4 also meet this issue.
Depends on: 1031225
Depends on: 1019419
Hi, Jason, sorry for the late replying of this.

I think it's a critical bug since I encountered this more than once, and it prevent us from being in shape of releasing 319.

[Blocking Requested - why for this release]:
1. Prevent 319 from getting better
2. Partner indicate that they encounter the same issue in dolphin v1.4 (also low mem device)
blocking-b2g: --- → 2.0?
Flags: needinfo?(wachen)
blocking-b2g: 2.0? → 2.0+
Is this a duplicate of bug 1019419, which has WIP patch?
Flags: needinfo?(wachen)
I am not sure about that due to its not using the same program and we didn't engaged. However, it might be similiar bug. How about...we take this bug as a meta bug of those and we can update any mtbf-related bug here.
Flags: needinfo?(wachen)
Looks like it can't be reproduced always.
QA Whiteboard: [2.0-signoff-need]
QA Whiteboard: [2.0-signoff-need] → [2.0-signoff-need+]
Same issue that bug 1047645 will fix.
Assignee: nobody → kgrandon
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1047645
Sorry, this is not acceptable since this directly affecting MTBF testing, and we need to bug to trace all related issues. Let's mark this bug resolved AFTER THE OTHER BUG FIXED AND I VERIFY IT IN MTBF RUN.

Thanks.
Status: RESOLVED → REOPENED
Depends on: 1047645
Resolution: DUPLICATE → ---
(In reply to Walter Chen[:ypwalter][:wachen] from comment #10)
> Sorry, this is not acceptable since this directly affecting MTBF testing,
> and we need to bug to trace all related issues. Let's mark this bug resolved
> AFTER THE OTHER BUG FIXED AND I VERIFY IT IN MTBF RUN.
> 
> Thanks.

Can't you add some flag to track this like 2.0-signoff-need+? This is clearly a duplicate, there is no reason to have multiple bugs open.
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
No longer depends on: 1047645
Resolution: --- → DUPLICATE
Duplicate of bug: 1047645
Also why not just have bug 1047645 block the MTBF-B2G bug? Is there some reason you don't want to mark this as a duplicate for metrics reasons? It is very confusing to have multiple bugs open for the same issue, so we should figure out a better solution.
THAT'S A CODEAURORA BUG. And, THAT'S IN THEIR META BUG. THIS MTBF BUG IS TO TRACK AND GET INFORMATION OF ALL OTHER RELATED BUGS THAT MAKE HOMESCREEN BUTTONS NOT WORKING.

> Also why not just have bug 1047645 block the MTBF-B2G bug? 
This is something that covers a large scale. You run few hours to get into this point. No single STR can reproduce it. Sound fair to make this some kind of meta bug?

> Is there some reason you don't want to mark this as a duplicate for metrics reasons?
ARE YOU SURE THAT IT IS A DUPLICATE? FROM WHAT I SAW IN THE BUG 1047645:
--------------------------------------------------------------------------------------
Observations:
1. Complete black screen is displayed.    <- not happening here
2. Short press of power key is showing display down and up. <- not happening here
3. Volume up and down keys are updating the UI.  <-the same behavior
4. Device condition is shared in a video. <- not happening here
5. If we kill homescreen |adb shell kill pid| then homescreen is not restarted again. <- not sure
--------------------------------------------------------------------------------------
In this bug, only (3) matches the issue. Also, this is a 319MB bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → NEW
Do what you want with this bug, but this report is not actionable as is.  It's either a dupe of bug 10470645 or it's missing a lot of required information to make any progress as you point out in comment 13.
blocking-b2g: 2.0+ → 2.0?
Whatever.
Assignee: kgrandon → nobody
Here's what i think.

walter is right that this shouldn’t block a CAF meta bug.  CAF doesn’t want us to mess with their meta and queries.    At the same time, this bug should block the general mozilla MTBF bug (1034485), which it does.

kevin is also right if this bug is a clear duplicate and is fixed by bug 1047645.   The entry point to reproducing the issues differ for both this bug and bug 1047645, but the fix may remain the same.   So making it a dupe is not irrational.

My suggestion to resolve this problem of terminology and losing tracking information, is to make THIS BUG also set to block Bug 1047645.   since Bug 1047645 is already marked fixed, the best thing to do is retest THIS BUG against trunk tomorrow, and then mark this resolved fixed if retesting it passes.  If not, reopen this bug and treat this as a separate moz-MTBF blocker.  Any problems with that?
Don't flick the switch of 2.0+ to 2.0?. bug 10470645 might be one way of making similiar bug. However, it is not fair to say that. I know you people want to quickly "solve" things, but that's not how it works. We see problems, and we need more time to see how it reproduce and if it keep reproduce.

You may say this is the only cause of home button not working, and it will fix everything. Nevertheless, think about this: Your phone crashed, and you filed a bug. Another person's phone crashed, and he or she filed a bug. Will the root cause of it be the same? Doesn't that take more time for a Endurance/Stability type of test runner more time to see and get more information for you people?

If there is a bug like this, there should always be block. 2.0+ is the correct one and I will insist on that. It was + alrdy, and there is not any fixes out there including the bug 10470645. How would you just do that?? I doubt that it is a good action.
I agree with Tony about that action since the patch is in, we will start MTBF next week and see if it reproduce. That should be almost the only way out.
We can't block on this because there's nothing useful in this bug.  "Home button doesn't work" is not enough for engineering to make any progress on.
yeah, I know. How about just saying that nothing is useful by doing MTBF? We are not expecting things like closing of a bug 2 weeks after a bug opened. We are keep running and see if it reproduce. You may ask us to put on things to verify if it is the same bug or more information.

When we found issues of black screen or home screen stucked, do you think that's invalid, too? We have our server set up here for logcat or other memery information. Did anyone ask more information before closing? I only see one comment here: Same issue that bug 1047645 will fix. and resolved duplicated.
That's just the nature of MTBF test is. If you need more information, there are just way toooo big to upload here. We can show you where it is, but no one asks.
Bug 1047645 has landed so this should be fixed now, please verify. This is clearly a dupe unless you provide some additional information that shows it isn't. Arguing this isn't going to get us anywhere though. I still don't understand your workflow, but to each his own.
Status: NEW → RESOLVED
Closed: 5 years ago5 years ago
Keywords: verifyme
Resolution: --- → FIXED
Actually, before the patch of bug 1047645 fixed, we didn't encounter that ever again for last 2 runs. Also, in the recently started run, we havn't seen it yet. I doubt it is the same issue, and it might be related with 2 bugs fixed in end of July. In any aspects, I won't and don't think it is the same bug.

Again, I won't and don't think it is the same bug.
Then provide something that shows it's different instead of just arguing with us.  A screenshot that doesn't look like the one in bug 1047645 or bug 1050751 would be a good start.
I'd like to take a screenshot if I can at that moment, but the screenshot doesn't work at the specific time point.
However, from I see in screenshots, it definitely not the black screen one. Also, I can't recall clearly, but it is not stucked in the screen of browser.
Kevin, again, please do recognize bugs sometimes are different. For example, another one you dup - bug 1031225 is now reopened...

Per comment 15, WHATEVER.
no verification till things cleared out.
Keywords: verifyme
(In reply to Walter Chen[:ypwalter][:wachen] from comment #28)
> no verification till things cleared out.

Walter, have you had a chance to verify if the patch on m-c fixed this?
Flags: needinfo?(wachen)
As we all know, MTBF took days to finish. However, before the bug 1047645 patch came in. It is actually not reproducible for last run. I wanted to verify it this this round (end tomorrow). 

I may be able to start another run on Wed to see if it reproduces with the new patch tomorrow. However, I will not verify this since bug 1031225 reopened, and I think that having related bug fixed is important.

It shouldn't be just closing bugs around. It's like fixing a car. You fix one part and think that this is fixed, but no one knows when it comes to a complex combination of different stuffs.
blocking-b2g: 2.0? → 2.0+
Target Milestone: --- → 2.1 S2 (15aug)
removing fixed status of b2g v2.0 & v2.1
again, bug 1056216 is opened by QC.
I don't mind keep this bug resolved fixed, but please do remember next time...

DON'T MESS AROUND WITH BUG WHEN YOU HAVE A FIX THAT HAVEN'T VERIFIED YET.
(In reply to Walter Chen[:ypwalter][:wachen] from comment #31)
> removing fixed status of b2g v2.0 & v2.1
> again, bug 1056216 is opened by QC.
> I don't mind keep this bug resolved fixed, but please do remember next
> time...
> 
> DON'T MESS AROUND WITH BUG WHEN YOU HAVE A FIX THAT HAVEN'T VERIFIED YET.

There's no need for shouting here. Please read the bugzilla etiquette at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Thanks for reminding. 

1. No pointless comments:
That comment is about current bug status: There is no patch in this bug, the status shouldn't be changed to fixed. My point is don't close/resolved the bug until it really solved, and people should come up with evidence.
2. No obligation: not applicable
3. No abusing people: this is a general information needed to deliver to other people. no person is attacked under this situation only if he/she wants to admit that.
4. No private email: not applicable
Flags: needinfo?(wachen)
Flags: needinfo?(wachen)
Cleared Ni? since it not reproduced.
However, I do want to bring up again that don't jump into conclusion too fast.
Flags: needinfo?(wachen)
You need to log in before you can comment on or make changes to this bug.