Closed
Bug 878577
Opened 11 years ago
Closed 10 years ago
Provide a hard limit for decoded image buffer
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
FIXED
mozilla31
People
(Reporter: schien, Assigned: schien)
References
(Depends on 1 open bug)
Details
Attachments
(3 files, 10 obsolete files)
24.38 KB,
image/png
|
Details | |
12.65 KB,
patch
|
schien
:
review+
|
Details | Diff | Splinter Review |
56.66 KB,
patch
|
schien
:
review+
|
Details | Diff | Splinter Review |
For a device had very limited memory, we could provide a hard limit of decoded image buffer. Bug 860818 and Bug 867264 show that oom killer might wake up and kill the foreground app if the allocation of image buffer is faster than discarding by lowmem killer (since we only have 5MB margin between lowmem and oom killer for foreground process). The hard limit can be calculated per process, it'll act like a global limitation since all the background process will be killed first under low memory scenario. It should be in preference, so that device manufacturers can adjust the value along with the prefs of lowmem/oom/DiscardTracker based on the hardware capability of each device. The attachment shows the memory usage of a scenario that a giant foreground app consumed all available memory. Normally the memory used other than image buffer is less than 40MB, so I think 40MB is a reasonable hard limit on 256MB handset.
Assignee | ||
Comment 1•10 years ago
|
||
Setup a hard limit for decoded image buffer size can prevent content process kill itself by displaying too much image at the same time. Displaying a image placeholder might be UX-friendly for user than process crash. Here is the test case: http://people.mozilla.org/~schien/image_memory_presure.html Unagi with this patch can survive without killing the content process.
Assignee: nobody → schien
Attachment #8347988 -
Flags: feedback?(seth)
Attachment #8347988 -
Flags: feedback?(khuey)
Comment 2•10 years ago
|
||
Comment on attachment 8347988 [details] [diff] [review] setup hard limit for decoded image buffer size Review of attachment 8347988 [details] [diff] [review]: ----------------------------------------------------------------- Looks good! I like where you're going with this. I'm marking this f- because I think some details need to be reworked, but the general approach is great. ::: image/src/DiscardTracker.cpp @@ +148,5 @@ > + if (!sHardLimitDecodedImageKB) { > + return true; > + } > + > + PR_Lock(sAllocationLock); This approach is not thread-safe, because you do not check whether we're under the hard memory limit and "allocate" the memory atomically. (I realize that we presently only allocate imgFrame memory on the main thread, but I don't think this is a safe assumption for the future.) I'd recommend going ahead and updating sCurrentDecodedImageBytes inside the lock if this function would return true. The caller should then be responsible for calling InformAllocation with a negative value to *remove* the allocated bytes if it later fails to successfully allocate the surface. You'll need to modify the control flow in imgFrame::Init to make this work, but it would make me much more comfortable with this design. @@ +150,5 @@ > + } > + > + PR_Lock(sAllocationLock); > + bool enoughSpace = > + (sHardLimitDecodedImageKB * 1024) >= (sCurrentDecodedImageBytes + bytes); Regarding this expression, I'd prefer "(sHardLimitDecodedImageKB * 1024 - sCurrentDecodedImageBytes) >= bytes" to reduce the risk of overflow. That's probably be made more readable by separating it into two statements. > int64_t availableBytes = sHardLimitDecodedImageKB * 1024 - sCurrentDecodedImageBytes; > bool enoughSpace = availableBytes >= bytes;
Attachment #8347988 -
Flags: feedback?(seth) → feedback-
Assignee | ||
Comment 3•10 years ago
|
||
update patch according to review comment.
Attachment #8347988 -
Attachment is obsolete: true
Attachment #8347988 -
Flags: feedback?(khuey)
Attachment #8351282 -
Flags: review?(seth)
Assignee | ||
Updated•10 years ago
|
Attachment #8351282 -
Flags: feedback?(khuey)
Comment on attachment 8351282 [details] [diff] [review] setup hard limit for decoded image buffer size Review of attachment 8351282 [details] [diff] [review]: ----------------------------------------------------------------- ::: image/src/DiscardTracker.cpp @@ +139,5 @@ > DisableTimer(); > } > > +/* static */ bool > +DiscardTracker::TryAllocation(int64_t bytes) aBytes is Gecko style @@ +161,5 @@ > + return enoughSpace; > +} > + > +/* static */ void > +DiscardTracker::InformDeallocation(int64_t bytes) here too. @@ +173,1 @@ > MOZ_ASSERT(sCurrentDecodedImageBytes >= 0); After we change the signedness this should just become an assertion at the beginning of this function that aBytes <= sCurrentDecodedImageBytes ::: image/src/DiscardTracker.h @@ +81,5 @@ > */ > static void DiscardAll(); > > /** > + * Inform the discard tracker that we are going to allocat some memory allocate @@ +84,5 @@ > /** > + * Inform the discard tracker that we are going to allocat some memory > + * for a decoded image. We use this to determine when we've allocated > + * too much memory and should discard some images. This function can > + * be called from any thread and is thread-safe. Also note that if this function succeeds the caller is now responsible for ensuring that InformDeallocation is called. @@ +89,2 @@ > */ > + static bool TryAllocation(int64_t bytes); These functions should both take unsigned integers. @@ +122,5 @@ > static nsCOMPtr<nsITimer> sTimer; > static bool sInitialized; > static bool sTimerOn; > static mozilla::Atomic<int32_t> sDiscardRunnablePending; > static int64_t sCurrentDecodedImageBytes; And sCurrentDecodedImageBytes should become unsigned too.
Attachment #8351282 -
Flags: feedback?(khuey) → feedback+
Comment 5•10 years ago
|
||
Comment on attachment 8351282 [details] [diff] [review] setup hard limit for decoded image buffer size Review of attachment 8351282 [details] [diff] [review]: ----------------------------------------------------------------- Looks much better! Almost there. I agreed with everything khuey said, as well. Please rerequest review when you've addressed both of our concerns. ::: b2g/app/b2g.js @@ +302,5 @@ > pref("image.mem.decodeondraw", true); > pref("image.mem.allow_locking_in_content_processes", false); /* don't allow image locking */ > pref("image.mem.min_discard_timeout_ms", 86400000); /* 24h, we rely on the out of memory hook */ > pref("image.mem.max_decoded_image_kb", 30000); /* 30MB seems reasonable */ > +pref("image.mem.hard_limit_decoded_image_kb", 60000); /* 60MB seemes reasonable */ "seems" ::: image/src/DiscardTracker.cpp @@ +147,5 @@ > + PR_Lock(sAllocationLock); > + bool enoughSpace = > + (!sHardLimitDecodedImageKB) ? true > + : (sHardLimitDecodedImageKB << 10 - sCurrentDecodedImageBytes) > + >= bytes; This means the same thing as: !sHardLimitDecodedImageKB || (sHardLimitDecodedImageKB << 10) - sCurrentDecodedImageBytes >= bytes which I'd prefer. Also, "+" and "-" have higher precedence than "<<" and ">>", IIRC, so I think you need parens around the left shift expression. I've corrected that in my suggested replacement. What might be even better is to compute it in a separate statement. Also note that we use "* 1024" rather than "<< 10" all over the place in this file, and it's probably better to be consistent. ::: image/src/imgFrame.cpp @@ +173,5 @@ > if (!mPalettedImageData) > NS_WARNING("moz_malloc for paletted image data should succeed"); > NS_ENSURE_TRUE(mPalettedImageData, NS_ERROR_OUT_OF_MEMORY); > } else { > + // Inform the discard tracker that we are going to allocated some memory. "allocate" ::: modules/libpref/src/init/all.js @@ +4012,5 @@ > // The maximum amount of decoded image data we'll willingly keep around (we > // might keep around more than this, but we'll try to get down to this value). > pref("image.mem.max_decoded_image_kb", 51200); > > +// Hard limit for the amount of decoded image data, 0 meas we don't have the "means"
Attachment #8351282 -
Flags: review?(seth) → review-
Assignee | ||
Comment 6•10 years ago
|
||
Update according to review comments.
Attachment #8351282 -
Attachment is obsolete: true
Attachment #8362412 -
Flags: review?(seth)
Attachment #8362412 -
Flags: review?(khuey)
Assignee | ||
Comment 7•10 years ago
|
||
I found it's pretty hard to test a preference that only loads at start-up. I'm trying to test it by changing the pref and opening a remote browser that runs the actual test code. Do you guys have any suggestion on how we can test it?
Comment 8•10 years ago
|
||
How are we going to maintain this hardcoded limit of 60MB? Should it be a percentage of the total size, rather than a fixed value? Is this going to limit our performance on better phones?
(In reply to Shih-Chiang Chien [:schien] from comment #7) > I found it's pretty hard to test a preference that only loads at start-up. > I'm trying to test it by changing the pref and opening a remote browser that > runs the actual test code. Do you guys have any suggestion on how we can > test it? It's not really possible to test preferences that are not "live". (In reply to Milan Sreckovic [:milan] from comment #8) > How are we going to maintain this hardcoded limit of 60MB? Should it be a > percentage of the total size, rather than a fixed value? Is this going to > limit our performance on better phones? OEMs will set the pref based on how much memory the device has, presumably.
Comment on attachment 8362412 [details] [diff] [review] setup hard limit for decoded image buffer size Review of attachment 8362412 [details] [diff] [review]: ----------------------------------------------------------------- I'm not a peer, but it looks good to me!
Attachment #8362412 -
Flags: review?(khuey) → feedback+
Assignee | ||
Comment 11•10 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #9) > (In reply to Milan Sreckovic [:milan] from comment #8) > > How are we going to maintain this hardcoded limit of 60MB? Should it be a > > percentage of the total size, rather than a fixed value? Is this going to > > limit our performance on better phones? > > OEMs will set the pref based on how much memory the device has, presumably. Yes, OEMs might fine tune this configuration during their internal QC process. We should maintain a wiki for this kind of device-specific preferences. It's nice to provide a heuristic of guessing the hard limit instead of a hard-coded one, but I think we should file a follow-up bug for it without blocking the entire feature.
Assignee | ||
Comment 12•10 years ago
|
||
With this patch, Gecko will not abort the image decoding while exceeding the buffer limit. We should be able to suspend the image decoding and resume it after we get enough buffer. I think it should be also a follow-up bug for improving the user experience.
Assignee | ||
Comment 13•10 years ago
|
||
try result here https://tbpl.mozilla.org/?tree=Try&rev=f0291749857c
Comment 14•10 years ago
|
||
(In reply to Shih-Chiang Chien [:schien] from comment #12) > With this patch, Gecko will not abort the image decoding while exceeding the > buffer limit. We should be able to suspend the image decoding and resume it > after we get enough buffer. I think it should be also a follow-up bug for > improving the user experience. That's a good idea! Worth filing.
Comment 15•10 years ago
|
||
Comment on attachment 8362412 [details] [diff] [review] setup hard limit for decoded image buffer size Review of attachment 8362412 [details] [diff] [review]: ----------------------------------------------------------------- Looks good!
Attachment #8362412 -
Flags: review?(seth) → review+
Assignee | ||
Comment 16•10 years ago
|
||
One reftest on emulator is broken by this patch because we exceed the image buffer limit. http://dxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/370629-1.html embeded a 4000*4000 png which is slightly exceed the 60000KB buffer limit. I think we should disable the buffer limit in our test environment in general. We can do this by setting up a user preference in http://dxr.mozilla.org/mozilla-central/source/testing/profiles/prefs_b2g_unittest.js. In that case, I'll try to add some test cases for the hard limit even if we need to some hacky things in the testcase.
Assignee | ||
Comment 17•10 years ago
|
||
(In reply to Seth Fowler [:seth] from comment #14) > (In reply to Shih-Chiang Chien [:schien] from comment #12) > > With this patch, Gecko will not abort the image decoding while exceeding the > > buffer limit. We should be able to suspend the image decoding and resume it > > after we get enough buffer. I think it should be also a follow-up bug for > > improving the user experience. > > That's a good idea! Worth filing. I've filed Bug 962384 for it.
Comment 18•10 years ago
|
||
(In reply to Shih-Chiang Chien [:schien] from comment #16) > One reftest on emulator is broken by this patch because we exceed the image > buffer limit. > http://dxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/370629-1. > html embeded a 4000*4000 png which is slightly exceed the 60000KB buffer > limit. I think we should disable the buffer limit in our test environment in > general. We can do this by setting up a user preference in > http://dxr.mozilla.org/mozilla-central/source/testing/profiles/ > prefs_b2g_unittest.js. In that case, I'll try to add some test cases for the > hard limit even if we need to some hacky things in the testcase. Not testing what we run seems wrong. Changing the limit to account for the extra size (you'd need <62000KB?) seems like a much better approach.
Assignee | ||
Comment 19•10 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #18) > Not testing what we run seems wrong. Changing the limit to account for the > extra size (you'd need <62000KB?) seems like a much better approach. I tried increasing the hard limit for Firefox OS, however, it still showed intermittent orange on try. My guess is gecko cannot guarantee all the image buffers are released before starting a test case.
Assignee | ||
Comment 20•10 years ago
|
||
Create a content process with buffer size limit and use mozbrowser API as the IPC channel to verdict the result.
Attachment #8366595 -
Flags: feedback?(seth)
Attachment #8366595 -
Flags: feedback?(khuey)
Comment 21•10 years ago
|
||
(In reply to Shih-Chiang Chien [:schien] from comment #19) > (In reply to Milan Sreckovic [:milan] from comment #18) > > Not testing what we run seems wrong. Changing the limit to account for the > > extra size (you'd need <62000KB?) seems like a much better approach. > I tried increasing the hard limit for Firefox OS, however, it still showed > intermittent orange on try. My guess is gecko cannot guarantee all the image > buffers are released before starting a test case. If we can't figure out a solution for this, in my opinion we'd be better off marking that one test random for affected platforms. I concur with Milan that I'd prefer the testing environment mirror the actual runtime environment as closely as possible.
Comment 22•10 years ago
|
||
Comment on attachment 8366595 [details] [diff] [review] Part 2 - testcase.patch Review of attachment 8366595 [details] [diff] [review]: ----------------------------------------------------------------- Very nice! ::: image/test/mochitest/file_image_buffer_limit.html @@ +69,5 @@ > + document.body.removeChild(img_8m); > + document.body.removeChild(another_img_8M); > + > + // Spin the event loop a few times to give the image in the display:none > + // iframe a chance to be discarded. This is the only part that makes me a bit nervous. It seems like a recipe for intermittent oranges. Is one spin definitely not enough? If not, I'd prefer to just do this (in pseudocode): while(true) { spinEventLoop(); retryImageLoad(); } This way we retry an infinite number of times until we succeed. This is more robust than hard-coding either a timeout or a set number of event loop spins. We already use this approach in a lot of the layout tests that have to deal with nondeterminism, so there's plenty of precedent. ::: testing/profiles/prefs_b2g_unittest.js @@ +7,5 @@ > user_pref("dom.ipc.browser_frames.oop_by_default", false); > user_pref("dom.mozBrowserFramesWhitelist","app://test-container.gaiamobile.org,http://mochi.test:8888"); > user_pref("marionette.force-local", true); > user_pref("dom.testing.datastore_enabled_for_hosted_apps", true); > +user_pref("image.mem.hard_limit_decoded_image_kb", 0); I don't understand why this line is in the patch. Maybe I'm just missing something?
Attachment #8366595 -
Flags: feedback?(seth) → feedback+
Assignee | ||
Comment 23•10 years ago
|
||
(In reply to Seth Fowler [:seth] from comment #22) > Comment on attachment 8366595 [details] [diff] [review] > Part 2 - testcase.patch > > Review of attachment 8366595 [details] [diff] [review]: > ----------------------------------------------------------------- > > Very nice! > > ::: image/test/mochitest/file_image_buffer_limit.html > @@ +69,5 @@ > > + document.body.removeChild(img_8m); > > + document.body.removeChild(another_img_8M); > > + > > + // Spin the event loop a few times to give the image in the display:none > > + // iframe a chance to be discarded. > > This is the only part that makes me a bit nervous. It seems like a recipe > for intermittent oranges. > > Is one spin definitely not enough? I just copy these code from image/test/mochitest/test_drawDiscardedImage.html. One spin works on my local machine and I'll push it to try server to see if we can have a stable green. > > If not, I'd prefer to just do this (in pseudocode): > > while(true) { > spinEventLoop(); > retryImageLoad(); > } > > This way we retry an infinite number of times until we succeed. This is more > robust than hard-coding either a timeout or a set number of event loop > spins. We already use this approach in a lot of the layout tests that have > to deal with nondeterminism, so there's plenty of precedent. > > ::: testing/profiles/prefs_b2g_unittest.js > @@ +7,5 @@ > > user_pref("dom.ipc.browser_frames.oop_by_default", false); > > user_pref("dom.mozBrowserFramesWhitelist","app://test-container.gaiamobile.org,http://mochi.test:8888"); > > user_pref("marionette.force-local", true); > > user_pref("dom.testing.datastore_enabled_for_hosted_apps", true); > > +user_pref("image.mem.hard_limit_decoded_image_kb", 0); > > I don't understand why this line is in the patch. Maybe I'm just missing > something? This line is for turning off hard limit in emulator mochitest/reftest. I'll remove this line because we already have a consensus on testing with hard limit. I did an experiment today and found we need 62M of decoded buffer to pass the reftest.
Comment 24•10 years ago
|
||
(In reply to Shih-Chiang Chien [:schien] from comment #23) > I just copy these code from > image/test/mochitest/test_drawDiscardedImage.html. One spin works on my > local machine and I'll push it to try server to see if we can have a stable > green. Sounds great! One spin is the ideal solution. > I did an experiment today and found we need 62M of decoded buffer to > pass the reftest. Excellent. It'd probably be a good idea to add a comment for the user_pref stating that the layout/reftests/bugs/370629-1.html is the limiting factor and you experimentally determined that 62M was enough.
Comment on attachment 8366595 [details] [diff] [review] Part 2 - testcase.patch I think seth's review is sufficent here.
Attachment #8366595 -
Flags: feedback?(khuey)
Assignee | ||
Comment 26•10 years ago
|
||
Unagi with 256MB RAM can survive with 65MB decoded buffer limit. I'll use this value for now and file a follow-up bug for the smart hard limit suggested by @milan in comment #8.
Assignee | ||
Comment 27•10 years ago
|
||
Set buffer size limit to 65M on Firefox OS.
Attachment #8362412 -
Attachment is obsolete: true
Attachment #8371314 -
Flags: review?(seth)
Assignee | ||
Comment 28•10 years ago
|
||
Directly test the buffer limit on b2g emulator. It tooks me some time to find out imgFrame is not locked on B2G and It will cause imgFrame create/release repeatitively for the 10M-pixel image. try result: https://tbpl.mozilla.org/?tree=Try&rev=33026c682e03
Attachment #8366595 -
Attachment is obsolete: true
Attachment #8371317 -
Flags: review?(seth)
Assignee | ||
Comment 29•10 years ago
|
||
I forgot that TBPL doesn't include "image" folder on b2g-emulator. https://tbpl.mozilla.org/?tree=Try&rev=76ccbe398f59
Attachment #8371317 -
Attachment is obsolete: true
Attachment #8371317 -
Flags: review?(seth)
Attachment #8372105 -
Flags: review?(seth)
Comment 30•10 years ago
|
||
Comment on attachment 8371314 [details] [diff] [review] Part 1 - setup hard limit for decoded image bufer size Review of attachment 8371314 [details] [diff] [review]: ----------------------------------------------------------------- Nice.
Attachment #8371314 -
Flags: review?(seth) → review+
Comment 31•10 years ago
|
||
Comment on attachment 8372105 [details] [diff] [review] Part 2 - testcase.patch Review of attachment 8372105 [details] [diff] [review]: ----------------------------------------------------------------- This looks good! Still seems like there's a failure on try, though. I'm going to assume it's a trivial issue and r+ this. If you have to make big changes, please rerequest review.
Attachment #8372105 -
Flags: review?(seth) → review+
Comment 32•10 years ago
|
||
This is the failure I'm talking about, on B2G ICS Emulator Opt, from the try job in comment 29: > 621 ERROR TEST-UNEXPECTED-FAIL | /tests/image/test/mochitest/test_image_buffer_limit.html | should fail to load due to image buffer size limit
Assignee | ||
Comment 33•10 years ago
|
||
Loading a single image exceeding the "image.mem.max_decoded_image_kb" (30000KB in b2g) will cause all the image been discarded at next DiscardNow() cycle [1]. If the second huge image decoding task comes later than DiscardNow(), it'll have a chance to allocate the requested decoded buffer and cause the intermittent failure. I workaround this problem by loading a smaller image as the first image, so the DiscardNow() won't be activate after the first image for sure. We can observe the images are blinking in http://people.mozilla.org/~schien/image_memory_presure.html on B2G because the imgFrames are continuously been discarded and recreated. We could fix the discarding algorithm in a separate bug. @seth, how do you think? try result: https://tbpl.mozilla.org/?tree=Try&rev=c3a4eea422fe [1] http://dxr.mozilla.org/mozilla-central/source/image/src/DiscardTracker.cpp?from=DiscardTracker.cpp#277
Attachment #8372105 -
Attachment is obsolete: true
Attachment #8373020 -
Flags: review?(seth)
Comment 35•10 years ago
|
||
Sorry for the slow response time! I got backed up and I'm digging my way out now. (In reply to Shih-Chiang Chien [:schien] (UTC+8) from comment #33) > I workaround this problem by loading a smaller image as the first image, so > the DiscardNow() won't be activate after the first image for sure. Yeah, that makes sense. Sounds like a good approach. > We can observe the images are blinking in > http://people.mozilla.org/~schien/image_memory_presure.html on B2G because > the imgFrames are continuously been discarded and recreated. We could fix > the discarding algorithm in a separate bug. @seth, how do you think? We definitely do not want that behavior, as that sounds like a battery killer in addition to being a poor experience for the user. Possibly we should have an exponential backoff on redecoding discarded images? I agree that we should save that for a separate bug, though; please CC me on any related bugs you create.
Flags: needinfo?(seth)
Comment 36•10 years ago
|
||
Comment on attachment 8373020 [details] [diff] [review] Part 2 - testcase.patch, v2 Review of attachment 8373020 [details] [diff] [review]: ----------------------------------------------------------------- Looks good!
Attachment #8373020 -
Flags: review?(seth) → review+
Assignee | ||
Comment 37•10 years ago
|
||
rebase to latest m-c, carry r+.
Attachment #8371314 -
Attachment is obsolete: true
Attachment #8403734 -
Flags: review+
Assignee | ||
Comment 38•10 years ago
|
||
rebase to latest m-c, carry r+. try result: https://tbpl.mozilla.org/?tree=Try&rev=f3b11007343d
Attachment #8373020 -
Attachment is obsolete: true
Attachment #8403739 -
Flags: review+
Comment 40•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/c9b8283fd770 https://hg.mozilla.org/integration/mozilla-inbound/rev/5c52ec9e5a3d
Updated•10 years ago
|
Keywords: checkin-needed
Comment 41•10 years ago
|
||
Backed out for B2G emulator timeouts in mochitest-8 after test_drawDiscardedImage.html: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&jobname=b2g_emulator_vm%20mozilla-inbound%20opt%20test%20mochitest-8&fromchange=9eb226f6ac34&tochange=4248c6482e33 eg: https://tbpl.mozilla.org/php/getParsedLog.php?id=37551656&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=37578888&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=37579882&tree=Mozilla-Inbound remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/a6f8b01e4146 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/4248c6482e33
Comment 42•10 years ago
|
||
(This failure occurred on 3 out of the 5 try jobs of the same type)
Assignee | ||
Comment 43•10 years ago
|
||
Hmm...It's weird that enabling |test_drawDiscardedImage.html| on b2g emulator will cause the connection loss. I'll find out the root cause and post a new patch later this day.
Assignee | ||
Comment 44•10 years ago
|
||
Bug 997034 is filed for the test timeout mentioned in comment #41.
Assignee | ||
Comment 45•10 years ago
|
||
rebase to latest m-c, carry r+.
Attachment #8403734 -
Attachment is obsolete: true
Attachment #8408990 -
Flags: review+
Assignee | ||
Comment 46•10 years ago
|
||
rebase to latest m-c, carry r+. try result is stable: https://tbpl.mozilla.org/?tree=Try&rev=db08b202d308
Attachment #8403739 -
Attachment is obsolete: true
Attachment #8408991 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 47•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/2fcd144a6282 https://hg.mozilla.org/integration/mozilla-inbound/rev/dc2154549c66
Flags: in-testsuite+
Keywords: checkin-needed
Comment 48•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2fcd144a6282 https://hg.mozilla.org/mozilla-central/rev/dc2154549c66
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
You need to log in
before you can comment on or make changes to this bug.
Description
•