Closed Bug 347938 (burrito-overflow) Opened 18 years ago Closed 16 years ago

Cannot eat 10 burritos in 2 hours without vomiting

Categories

(mozilla.org Graveyard :: Server Operations: Projects, task, P1)

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: preed, Assigned: sparky)

References

()

Details

(Keywords: dataloss, dogfood)

Attachments

(2 files)

Firefox cannot handle eating 10 Taco Bell Burrito Supremes without vomiting.

Everything starts out rendering correctly, but as time progresses, the rendering slows down... and then about 90 minutes in, Firefox just barfs.

I think this is a problem with the front-end to back-end migration code.

Seth, can you take a look?
yes, matt has been able to reproduce this bug.

matt, can I get a screen shot?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dogfood
Attached image Pre-crash
This was a screenshot from right before it just barfed...
can we get some more info on this?  how many burritos does firefox handle before it barfs?
(In reply to comment #3)
> can we get some more info on this?  how many burritos does firefox handle
> before it barfs?

Looks like it can handle about three bites shy of seven burritos before biffing it.
Did the burritos talk back before it barfed? See http://kb.mozillazine.org/Talkback or http://en.wikipedia.org/wiki/Burping
(In reply to comment #3)
> can we get some more info on this?  how many burritos does firefox handle
> before it barfs?
> 

I wonder what does PETA (www.peta.org) have to say about this. Force-feeding a poor animal :-)
Is this in the test-suite yet?  This seems like the kinda thing that should be run on a regular basis.
Flags: in-testsuite?
Looks like firefox will barf on 4 Burger King Whoppers in < 3 hours, too.

Upping severity.
Severity: critical → blocker
Hardware: Macintosh → Other
Should we add this to the Tinderbox?
I think you are premature in setting the severity to blocker... that really won't be known for at least a few hours.
Priority: -- → P1
Hardware: Other → All
Summary: Cannot eat 10 burritos in 2 hours without vomitting → Cannot eat 10 burritos in 2 hours without vomiting
Firefox shouldn't be trying to force 4 of the 10 whoppers through in the first 3 hours of 8 allotted.  Clearly smarter CPU usage handling is required.  Firefox should know it's using 100% CPU and queue the rest of the whoppers rather than locking up and crashing.
Which developer should we assign to fix this bug?
Another screenshot: upon launch, everything looks good...
WFM two days ago with homemade burritos, so it must be something specific to Taco Bell. Unfortunately, I don't have access to such a platform for testing here in London..
(In reply to comment #15)
> Created an attachment (id=232817) [edit]
> All smiles and sunshine...
> 
> Another screenshot: upon launch, everything looks good...
> 

Nice Power Book / Mac Book Pro.
(In reply to comment #14)
> Which developer should we assign to fix this bug?

Unfortunately, other than bz, who wrote mozFlushType.h, we don't have a lot of developer expertise in this area, and I strongly doubt he'd touch this problem with a ten foot pole.
gives everybody antacid pill and says there problem fixed
Attachment #232817 - Attachment description: All smiles and sunshine... → All smiles and sunshine... (a.k.a. you got your whopper on my burrito. no, you got your burrito on my whopper).
Alias: burrito-overflow
-> Autocomplete.
Component: Migration → Autocomplete
Product: Firefox → Toolkit
Version: 2.0 Branch → 1.8 Branch
As this bug causes the loss of data that (hopefully) cannot be recovered, it should be marked security.
Keywords: dataloss
Nobody in their right mind would verify the outcome of this bug; changing qa contact accordingly.
QA Contact: migration → nobody
Note that the digestive system has been fixed on trunk, but due to frequent and repeated API changes to nsICalorieProcessor, no patch from trunk can land on the 1.8 branch.
With a reduced testcase, my system quickly dumps core. However, I don't see any recognizable symbols... Best I can make out is that the function at 0xFEEDFACE overflowed a buffer with repeated instances of 0xDEADBEEF.
--> Gecko 1.9a1, as per comment 23. I think that this might be something for the reflow branch to handle, so cc'ing dbaron ...
Target Milestone: --- → mozilla1.9alpha1
Version: 1.8 Branch → Trunk
I think the problem is with the ingredients in the ingested foods.

We now have demonstrable success at digesting an entire 21-piece* loaf of Wonder Classic bread in an hour, which contains a full 44% of a 2000-calorie diet's daily value of fiber.  Clearly high-speed fiber is the key to success, and adding some would speed things up immensely.  Over to Server Operations Projects to handle installation...

* mscott and sspitzer feel cheated out of the 22nd slice
Component: Autocomplete → Server Operations Projects
Flags: in-testsuite?
Product: Toolkit → mozilla.org
Target Milestone: mozilla1.9alpha1 → ---
Version: Trunk → other
*** Bug 350104 has been marked as a duplicate of this bug. ***
As sad as I am to do it, it looks like no one has been able to eat 10 burritos in 2 hours yet.

Resolving WONTFIX.

Reopen if you think you can prove us all wrong.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
interesting that someone put the dogfood keyword on this bug and didn't give it to sparky to test.  his version of fx3 can easily digest 10 burritos in about 20 minutes.  
Resolution: WONTFIX → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
sparky can you work with sspitzer to get your patch in?
Assignee: sspitzer → sparky
Status: REOPENED → NEW
performance after that 10th burrito isn't really great, but still functional

http://flickr.com/photos/41711850@N00/398221766/
Status: NEW → RESOLVED
Closed: 18 years ago16 years ago
Resolution: --- → WORKSFORME
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.