[webkit-dev] webkit debug build error - memory exhausted even on 32GB Ram
Hello webkit.org community, i am trying to build webkit in debug mode on server that is 64bit and 32GB RAM system. Inspite of having such large ram it is showing following memory exhausted error : /usr/bin/ld: failed to set dynamic section sizes: Memory exhausted collect2: ld returned 1 exit status make[1]: *** [libwebkitgtk-3.0.la] Error 1 Hope to get a satisfactory response. Thanks Regards. Navanshu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit debug build error - memory exhausted even on 32GB Ram
En 13/06/12 10:25, Navanshu Mahor escribiu: Hello webkit.org http://webkit.org community, i am trying to build webkit in debug mode on server that is 64bit and 32GB RAM system. Inspite of having such large ram it is showing following memory exhausted error : /usr/bin/ld: failed to set dynamic section sizes: Memory exhausted collect2: ld returned 1 exit status make[1]: *** [libwebkitgtk-3.0.la http://libwebkitgtk-3.0.la] Error 1 Hope to get a satisfactory response. I can build debug wk builds with no problems with 8GB of RAM. What exact build options are you using? Have you tried to use the gold linker (binutils-gold package on debian for example) ? BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
Hi, The bug report about fastMalloc(0): https://bugs.webkit.org/show_bug.cgi?id=55097 Brewmp had conditions for fastMalloc(0) earlier, but it was removed in: http://trac.webkit.org/changeset/9/trunk/Source/JavaScriptCore/wtf/FastMalloc.cpp Cheers, Zoltan On Wed, 13 Jun 2012 00:08:48 +0200, Adam Barth aba...@webkit.org wrote: There was some discussion about how to handle malloc(0) a year or so ago. I don't remember if it was on webkit-dev, but you might want to check the archives. Eric Seidel might remember what conclusions (if any) we came to. Adam On Tue, Jun 12, 2012 at 3:03 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Hello, I'm compiling WebKit with a malloc() implementation that returns NULL for malloc(0). According to C99, this is valid: If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. I noticed that this caused a problem in one particular place (WTF::StringImpl::getData16SlowCase()) where the code allocates (constant * length) bytes for an (empty) string, and provides an accessor that exposes this pointer. This pointer was being passed to ICU, which didn't perform the requested function because it looked like one of the arguments was invalid, even though it was just empty. I have worked around this one particular occurrence in my local version of WebKit fork, but I'm wondering how often this pattern occurs. Is my fix worth upstreaming? Is it worth trying to find, fix, and upstream every occurrence of this pattern? Or is this particular behavior of malloc() an unstated requirement of building WebKit? If the latter is true, perhaps it's worth explicitly stating this somewhere? What is the opinion of the community? Thanks, Myles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build.webkit.org down for upgrade
Hi, Sorry for the late response, I didn't have to much time last week. But fortunately I managed to fix it today, and uploaded the proposed patches: - Unhide login form on the build.webkit.org - https://bugs.webkit.org/show_bug.cgi?id=88981 - Update buildbot master in autoinstaller to match build.webkit.org - https://bugs.webkit.org/show_bug.cgi?id=88992 - Add ForceScheduler to build.webkit.org - https://bugs.webkit.org/show_bug.cgi?id=88982 - master.cfg cleanup, remove unnecessary workaround - https://bugs.webkit.org/show_bug.cgi?id=88994 br, Ossy Lucas Forschler írta: Hi Ossy, Can you send me the bugzilla link for the ForceScheduler work? Thanks, Lucas On May 31, 2012, at 9:22 AM, Lucas Forschler wrote: HI Ossy, I did notice the display order change as well. I think I am going to open a bug to rename all of the Apple bots to prefix them with 'Apple'. We (at Apple) would like to get our bots into a more conforming naming convention. I realize that won't solve the problem with having a specific order for your bots, but it will at least get everything grouped together. I'm slightly opposed to rolling out the natural sorting as you suggest below... I think that will be short-lived and when buildbot 0.9.x is available, we may not have this option. I think we should be forward thinking here and try not to work around this. I can be convinced to make the change if there is additional support for rolling out the natural sorting. Thanks for looking into the ForceScheduler. Hopefully we can get that up and running quickly. So far it appears we don't have any bots stuck in trigger mode. Please let me know if you see any. I am hoping that issue is now solved for good. Thanks, Lucas On May 31, 2012, at 3:32 AM, Osztrogonac Csaba wrote: Lucas Forschler írta: to 0.8.6p1 Will be back online when complete. Lucas Hi All, Unfortunately there are too annoying bugs introduced with upgrading build master to 0.8.6p1 : Problem 1 -- Builders are alphabetically ordered on http://build.webkit.org/waterfall instead of the given order in our config.json. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Builders are no longer displayed in the order they were configured. This was never intended behavior, and will become impossible in the distributed architecture planned for Buildbot-0.9.x. As of 0.8.6p1, builders are sorted naturally: lexically, but with numeric segments sorted numerically. I think the new alphabetical order is so confusing. For example Apple's Lion bots are between GTK and Qt bots, but SnowLeopard bots are after the Qt bots. I know that we can see category=AppleMac, category=Qt, ... , but the order of the bots in a given category is important for us too. I don't think that an artifical renaming would be a good solution to get the order what we want. (Because we would have to rename bots in all scripts, we would have loose the history, ...) What about if we revert the buildbot-0.8.6p1 change in buildmaster caused this bug/feature? Here is a simple patch to do it: diff --git a/buildbot-0.8.6p1/buildbot/status/master.py b/buildbot-0.8.6p1/buildbot/status/master.py index e803133..e60ab06 100644 --- a/buildbot-0.8.6p1/buildbot/status/master.py +++ b/buildbot-0.8.6p1/buildbot/status/master.py @@ -200,7 +200,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): def getBuilderNames(self, categories=None): if categories == None: -return util.naturalSort(self.botmaster.builderNames) # don't let them break it +return self.botmaster.builderNames # don't let them break it l = [] # respect addition order @@ -208,7 +208,7 @@ class Status(config.ReconfigurableServiceMixin, service.MultiService): bldr = self.botmaster.builders[name] if bldr.config.category in categories: l.append(name) -return util.naturalSort(l) +return l def getBuilder(self, name): Problem 2 -- There isn't force build possibility anymore. http://buildbot.net/buildbot/docs/0.8.6p1/release-notes.html Forced builds now require that a ForceScheduler be defined in the Buildbot configuration. It can be solved simple with adding ForceScheduler. I'm going to file a bug report and prepare a patch to fix it soon. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
On Jun 12, 2012, at 5:17 PM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=87772. It's great to use a fuzzer in order to find cases where we're broken and then make reduced layout tests from those. The viewspec-parser tests are themselves just a fuzzer though. Granted, they are deterministic by avoiding using an actual random function, but I don't think throwing randomly generated bits at a parser is appropriate for layout testing. If nothing else it's very slow. These tests regularly timeout on the Chromium debug bots and occasionally timeout on the Apple Lion bots. Even on the bots where they don't timeout, they're slow. I don't it makes sense to spend 1+ minutes running these 5 tests when more targeted reductions could get the same effective coverage much faster. Am I wrong? If not, does anyone object to moving these tests over to ManualTests or just deleting them entirely? I am not familiar with the viewspec-parser tests and their history, but I agree in principle that fuzzers and their raw output rarely make for the best way to regression test. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
On Jun 12, 2012, at 5:17 PM, Ojan Vafai o...@chromium.org wrote: It's great to use a fuzzer in order to find cases where we're broken and then make reduced layout tests from those. Generally we do require a test each time we fix a bug. So it’s a strategy for the project to always make reduced tests when we find a bug. But using a fuzzer to find bugs and then making a regression test for each bug we find will not give us great coverage. We’d like tests that cover lots of the code paths in WebKit, even the ones without bugs. I’m not saying we should necessarily keep fuzzer-style tests, but to replace them we would need to add tests with good coverage, going beyond regression tests for bugs that existed in the project at one point. At one point, I remember Geoff Garen encouraging a fuzzer-type approach to making some tests for an SVG path parser, as an alternative to my plan of making a test that covered every branch in the parser code. I don’t remember what we ended up doing in that case. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
On Wed, Jun 13, 2012 at 12:05 PM, Darin Adler da...@apple.com wrote: On Jun 12, 2012, at 5:17 PM, Ojan Vafai o...@chromium.org wrote: It's great to use a fuzzer in order to find cases where we're broken and then make reduced layout tests from those. Generally we do require a test each time we fix a bug. So it’s a strategy for the project to always make reduced tests when we find a bug. But using a fuzzer to find bugs and then making a regression test for each bug we find will not give us great coverage. We’d like tests that cover lots of the code paths in WebKit, even the ones without bugs. I’m not saying we should necessarily keep fuzzer-style tests, but to replace them we would need to add tests with good coverage, going beyond regression tests for bugs that existed in the project at one point. I have always been under the impression that LayoutTests were not just intended for preventing regressions to bugfixes, but that we should also be adding tests to establish correctness (and hopefully achieve good coverage) there. Is that not the case? Certainly I would expect the imported test suites to be testing correctness and not just be regression bug fixes. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
On Jun 13, 2012, at 12:12 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 13, 2012 at 12:05 PM, Darin Adler da...@apple.com wrote: On Jun 12, 2012, at 5:17 PM, Ojan Vafai o...@chromium.org wrote: It's great to use a fuzzer in order to find cases where we're broken and then make reduced layout tests from those. Generally we do require a test each time we fix a bug. So it’s a strategy for the project to always make reduced tests when we find a bug. But using a fuzzer to find bugs and then making a regression test for each bug we find will not give us great coverage. We’d like tests that cover lots of the code paths in WebKit, even the ones without bugs. I’m not saying we should necessarily keep fuzzer-style tests, but to replace them we would need to add tests with good coverage, going beyond regression tests for bugs that existed in the project at one point. I have always been under the impression that LayoutTests were not just intended for preventing regressions to bugfixes, but that we should also be adding tests to establish correctness (and hopefully achieve good coverage) there. That’s right. Did my words above give an impression to the contrary? I am trying to say that we should be sure to keep good coverage when we remove a fuzzer-style test, possibly by adding tests that cover the same code in a different way. I’m not making some kind of global statement about all the tests. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
Are we sure that we want to make this a general rule? We have two profitable fuzzers in fast/js that I believe deserve to be in LayoutTests and should be run every time you make any JSC change: LayoutTests/fast/js/dfg-double-vote-fuzz.html LayoutTests/fast/js/dfg-poison-fuzz.html Both are somewhat long-running (I seem to recall some buzz about them being marked either SLOW or TIMEOUT on Chromium) but both have caught lots of bugs in the JSC optimizing JIT. They generate ~1000 simple programs and eval them, each program differing in the position of some evil operation. When you get a crash or a fail, it's pretty easy to use them to quickly identify what went wrong since the offending code is nice and tidy. On the other hand, if it wasn't for their use of fuzzing, they would certainly have reduced coverage because the exact shape of a program that would cause a failure depends on number of registers available and compiler heuristics, both of which can change with unrelated changes to the JIT or if you switch hardware targets. So these tests are great for testing things like register allocation, OSR, and type inference. Even seemingly unrelated changes to JSC, or possibly even JSC bindings, could either cause or reveal bugs that these tests would catch. Hence it would be bad if they were not part of the LayoutTests. We would lose coverage while gaining very little in return, since although these tests are on the slower end of the execution time spectrum, the other fast/js tests put together take much longer and probably don't catch as many juicy bugs. Certainly no other test in LayoutTests/fast/js does nearly as good of a job in covering the code paths that deal with register allocation under register pressure, or type inference under evil control flow, in the presence of an operation that would cause an OSR exit. More broadly, I think this is a question of test economics. Does this particular fuzzer test catch enough bugs to justify its run-time? If yes then we should keep it. And if nobody can recall a time when the test saved them from making a broken commit, or when it helped a bot watcher identify a genuinely broken changeset, then we should probably get rid of it. -F On Jun 13, 2012, at 11:58 AM, Dirk Pranke wrote: I agree that the fuzzer should be used to create dedicated layout tests, but we shouldn't run the fuzzer itself as part of the layout test regression. I would have no objection to it being a separate test step. -- Dirk On Tue, Jun 12, 2012 at 5:17 PM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=87772. It's great to use a fuzzer in order to find cases where we're broken and then make reduced layout tests from those. The viewspec-parser tests are themselves just a fuzzer though. Granted, they are deterministic by avoiding using an actual random function, but I don't think throwing randomly generated bits at a parser is appropriate for layout testing. If nothing else it's very slow. These tests regularly timeout on the Chromium debug bots and occasionally timeout on the Apple Lion bots. Even on the bots where they don't timeout, they're slow. I don't it makes sense to spend 1+ minutes running these 5 tests when more targeted reductions could get the same effective coverage much faster. Am I wrong? If not, does anyone object to moving these tests over to ManualTests or just deleting them entirely? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
I guess I was saying two slightly different things ... 1) I have a strong bias for individual tests that are fast 2) I have a strong bias for individual tests that are simple, focused, easy to understand, and are predictable. All other things being equal (which of course they never are), I would prefer 100 different tests that can fail individually to 1 test that tests 100 different things. Of course you have to weigh this against coverage and establishing correctness; I wouldn't want to lose coverage, either. -- Dirk On Wed, Jun 13, 2012 at 12:17 PM, Filip Pizlo fpi...@apple.com wrote: Are we sure that we want to make this a general rule? We have two profitable fuzzers in fast/js that I believe deserve to be in LayoutTests and should be run every time you make any JSC change: LayoutTests/fast/js/dfg-double-vote-fuzz.html LayoutTests/fast/js/dfg-poison-fuzz.html Both are somewhat long-running (I seem to recall some buzz about them being marked either SLOW or TIMEOUT on Chromium) but both have caught lots of bugs in the JSC optimizing JIT. They generate ~1000 simple programs and eval them, each program differing in the position of some evil operation. When you get a crash or a fail, it's pretty easy to use them to quickly identify what went wrong since the offending code is nice and tidy. On the other hand, if it wasn't for their use of fuzzing, they would certainly have reduced coverage because the exact shape of a program that would cause a failure depends on number of registers available and compiler heuristics, both of which can change with unrelated changes to the JIT or if you switch hardware targets. So these tests are great for testing things like register allocation, OSR, and type inference. Even seemingly unrelated changes to JSC, or possibly even JSC bindings, could either cause or reveal bugs that these tests would catch. Hence it would be bad if they were not part of the LayoutTests. We would lose coverage while gaining very little in return, since although these tests are on the slower end of the execution time spectrum, the other fast/js tests put together take much longer and probably don't catch as many juicy bugs. Certainly no other test in LayoutTests/fast/js does nearly as good of a job in covering the code paths that deal with register allocation under register pressure, or type inference under evil control flow, in the presence of an operation that would cause an OSR exit. More broadly, I think this is a question of test economics. Does this particular fuzzer test catch enough bugs to justify its run-time? If yes then we should keep it. And if nobody can recall a time when the test saved them from making a broken commit, or when it helped a bot watcher identify a genuinely broken changeset, then we should probably get rid of it. -F On Jun 13, 2012, at 11:58 AM, Dirk Pranke wrote: I agree that the fuzzer should be used to create dedicated layout tests, but we shouldn't run the fuzzer itself as part of the layout test regression. I would have no objection to it being a separate test step. -- Dirk On Tue, Jun 12, 2012 at 5:17 PM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=87772. It's great to use a fuzzer in order to find cases where we're broken and then make reduced layout tests from those. The viewspec-parser tests are themselves just a fuzzer though. Granted, they are deterministic by avoiding using an actual random function, but I don't think throwing randomly generated bits at a parser is appropriate for layout testing. If nothing else it's very slow. These tests regularly timeout on the Chromium debug bots and occasionally timeout on the Apple Lion bots. Even on the bots where they don't timeout, they're slow. I don't it makes sense to spend 1+ minutes running these 5 tests when more targeted reductions could get the same effective coverage much faster. Am I wrong? If not, does anyone object to moving these tests over to ManualTests or just deleting them entirely? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
Thanks for the quick responses and the bug link about fastMalloc(0). In comment 11 https://bugs.webkit.org/show_bug.cgi?id=55097#c11, Eric Seidel says that he was going to start a discussion on webkit-dev, but I haven't been able to find such a conversation (by looking both on gmane and on google). All I've been able to find is this threadhttps://lists.webkit.org/pipermail/webkit-dev/2011-June/016967.html, which is only a single post. Does anyone know where this conversation takes place? That being said, Darin Adler is right; the original patch was intended to improve performance, not because something was breaking. It seems like most of the conversation regarding that patch is about any possible performance increase. In addition, Eric Seidel's patch was to guarantee that no one tries to call fastMalloc with a size of 0; I'm merely concerned about the value of the pointer returned when someone does call that. I think the fact that ICU thinks that a null pointer is an invalid string isn't necessarily an incorrect one. It's just a quirk of an interface to a library. I don't think that a good solution is to change the interface of ICU and try to upstream a patch to ICU - I think a better solution would be to work around this requirement of ICU inside WebKit. I see two different solutions: 1) Document the fact that, in order to use webkit, you need an implementation of malloc(0) that doesn't return null pointers. This way, the burden of solving this problem is pushed downstream. 2) Find some place along the every pipeline from malloc(0) to ICU, and arbitrarily modify the pointer to a non-zero value. This is probably the best solution, but a real fix of this nature requires finding all the places where pointers can be passed into ICU. If I solve (via option 2) just my one particular occurrence of this problem, I see three different places to arbitrarily modify the pointer given to ICU: 1) change the m_copyData16 pointer in StringImpl to an arbitrary value, and check for that arbitrary value on destruction 2) change the characters() accessor to check if m_copyData16 is null, and return an arbitrary value if it is. This works because callers of characters() shouldn't ever delete the pointer nor dereference the pointer (since the string's length is 0) 3) check for null at the call site of the ICU function. I (perhaps prematurely) uploaded a CL implementinghttps://bugs.webkit.org/show_bug.cgi?id=88936option 2. What do you think? --Myles On Wed, Jun 13, 2012 at 2:09 AM, Zoltan Horvath zol...@webkit.org wrote: Hi, The bug report about fastMalloc(0): https://bugs.webkit.org/show_bug.cgi?id=55097 Brewmp had conditions for fastMalloc(0) earlier, but it was removed in: http://trac.webkit.org/changeset/9/trunk/Source/JavaScriptCore/wtf/FastMalloc.cpp Cheers, Zoltan On Wed, 13 Jun 2012 00:08:48 +0200, Adam Barth aba...@webkit.org wrote: There was some discussion about how to handle malloc(0) a year or so ago. I don't remember if it was on webkit-dev, but you might want to check the archives. Eric Seidel might remember what conclusions (if any) we came to. Adam On Tue, Jun 12, 2012 at 3:03 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Hello, I'm compiling WebKit with a malloc() implementation that returns NULL for malloc(0). According to C99, this is valid: If the size of the space requested is zero, the behavior is implementation- defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object. I noticed that this caused a problem in one particular place (WTF::StringImpl::getData16SlowCase()) where the code allocates (constant * length) bytes for an (empty) string, and provides an accessor that exposes this pointer. This pointer was being passed to ICU, which didn't perform the requested function because it looked like one of the arguments was invalid, even though it was just empty. I have worked around this one particular occurrence in my local version of WebKit fork, but I'm wondering how often this pattern occurs. Is my fix worth upstreaming? Is it worth trying to find, fix, and upstream every occurrence of this pattern? Or is this particular behavior of malloc() an unstated requirement of building WebKit? If the latter is true, perhaps it's worth explicitly stating this somewhere? What is the opinion of the community? Thanks, Myles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
These tests regularly timeout on the Chromium debug bots and occasionally timeout on the Apple Lion bots. WebKit has a clear policy about this: Tests must be fast enough not to time out. We can fix this issue by making these tests shorter. I don't really see the connection to an abstract debate about fuzzers. Fuzzers can be short-running, and non-fuzzers can be long-running. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
On Wed, Jun 13, 2012 at 12:48 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I don't think that a good solution is to change the interface of ICU and try to upstream a patch to ICU - I think a better solution would be to work around this requirement of ICU inside WebKit. What is exactly the problem with that? That would greatly simplify your problem and that does not sound like a bad thing to have for ICU. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
There is still the question of if I can upstream this to ICU, which I'm checking on. In the meantime, Ryosuke Niwa has a good argument for option 3) above. I have uploaded a new patch to https://bugs.webkit.org/show_bug.cgi?id=88936that moves the NULL pointer check to inside the ICU-specific collator class. On Wed, Jun 13, 2012 at 1:14 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 13, 2012 at 12:48 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: I think the fact that ICU thinks that a null pointer is an invalid string isn't necessarily an incorrect one. It's just a quirk of an interface to a library. I don't think that a good solution is to change the interface of ICU and try to upstream a patch to ICU Certainly not since not all browsers ship with their own ICU embedded inside. I see two different solutions: 1) Document the fact that, in order to use webkit, you need an implementation of malloc(0) that doesn't return null pointers. This way, the burden of solving this problem is pushed downstream. I don't think we should impose arbitrary requirements like this. 2) Find some place along the every pipeline from malloc(0) to ICU, and arbitrarily modify the pointer to a non-zero value. This is probably the best solution, but a real fix of this nature requires finding all the places where pointers can be passed into ICU. We already have an abstraction layer for all ICU functions in WTF and WebCore/platform because not all ports use ICU (e.g. Qt port). It should be fairly easy to add an extra code there to check whether a null pointer is passed in or not and bail out as appropriate. If I solve (via option 2) just my one particular occurrence of this problem, I see three different places to arbitrarily modify the pointer given to ICU: 1) change the m_copyData16 pointer in StringImpl to an arbitrary value, and check for that arbitrary value on destruction 2) change the characters() accessor to check if m_copyData16 is null, and return an arbitrary value if it is. This works because callers of characters() shouldn't ever delete the pointer nor dereference the pointer (since the string's length is 0) 3) check for null at the call site of the ICU function. I (perhaps prematurely) uploaded a CL implementinghttps://bugs.webkit.org/show_bug.cgi?id=88936option 2. What do you think? Adding any code to characters() will likely impact performance because it tends to be used in hot code paths so I'd rather avoid that. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
On Jun 13, 2012, at 2:24 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: There is still the question of if I can upstream this to ICU, which I'm checking on. I was not proposing changing ICU. In the meantime, Ryosuke Niwa has a good argument for option 3) above. Yes, that’s what I was suggesting; I am glad that Ryosuke stated it more clearly than I did. I have uploaded a new patch to https://bugs.webkit.org/show_bug.cgi?id=88936 that moves the NULL pointer check to inside the ICU-specific collator class. Seems good. Not sure it should be a null pointer check, though. A zero length check would work too. -- Darin___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler da...@apple.com wrote: There is still the question of if I can upstream this to ICU, which I'm checking on. I was not proposing changing ICU. I did. In addition to changing WebKit, not using the pointer when the length is zero does not necessarily seem like a bad idea to me. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] malloc(0)
I started a thread on icu-design (mailing list) about it. As soon as it appears in the archives, I'll post a permalink to the thread. The null pointer check shouldn't matter - if the pointer isn't null, then it's valid anyway :-) --Myles On Wed, Jun 13, 2012 at 3:37 PM, Benjamin Poulain benja...@webkit.orgwrote: On Wed, Jun 13, 2012 at 3:27 PM, Darin Adler da...@apple.com wrote: There is still the question of if I can upstream this to ICU, which I'm checking on. I was not proposing changing ICU. I did. In addition to changing WebKit, not using the pointer when the length is zero does not necessarily seem like a bad idea to me. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
Hi all, Because I have infinite patience for bikeshedding, I thought I would send out Yet Another note on the proposed changes to the expectation syntax. Based on the last thread, I'm planning to change ORWT so that it will recognize the syntax in the TestExpectations files and treat any non-PASS entry as Skipped, so we will be able to switch over to TestExpectations files wholesale, so you might want to care about this ... I would also like to batch all of the changes up at once and then defer any changes for a month or more, just so the syntax isn't changing frequently and we have to retrain everyone. I'm of course open to changing things whenever we need to :). The current syntax is documented here: http://trac.webkit.org/wiki/TestExpectations In https://bugs.webkit.org/show_bug.cgi?id=86796 , we are proposing to change it to something like: webkit.org/12345 WIN MAC DEBUG \ animations/stop-animation-on-suspend.html \ CRASH TEXT PASS * the left hand side of the test now just contains the bug link and keywords that modify which configurations the line applies to. * You may use bug(dpranke) instead of a URL on the left hand side of the expression. * The REBASELINE, SLOW, SKIP, WONTFIX keywords will move to the right-hand side (note that REBASELINE doesn't ever actually get checked in). * we use \ (backslash) as a delimiter instead of : and = * The FAIL keyword is being removed as we speak. * We'll probably rename IMAGE+TEXT to IMAGE_AND_TEXT. * WONTFIX will have the same effect as SKIP but has a different meaning: we don't plan on passing the test at all; SKIP is intended to work around temporary bugs or problems. * As of now the keywords remain all UPPERCASE. I'm happy to change them to all lowercase or mixed case if there's a consensus that such a change is desired. Speak now if you really don't like these proposals, or hold your peace for at least a month ;) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] are fuzzer tests appropriate layout tests?
On Jun 13, 2012, at 1:32 PM, Geoffrey Garen gga...@apple.com wrote: These tests regularly timeout on the Chromium debug bots and occasionally timeout on the Apple Lion bots. WebKit has a clear policy about this: Tests must be fast enough not to time out. We can fix this issue by making these tests shorter. I don't really see the connection to an abstract debate about fuzzers. Fuzzers can be short-running, and non-fuzzers can be long-running. Also, if a fuzzer is deterministic (which it should be, if it's going to be in LayoutTests), there is probably a fairly mechanical way to split it into multiple faster tests. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 3:58 PM, Darin Adler da...@apple.com wrote: On Jun 13, 2012, at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: * we use \ (backslash) as a delimiter instead of : and = Seems worse to me. When I see a backslash I assume it’s a line continuation character or a C escape sequence. Gotta admit this one mystifies me too. I must have missed where someone suggested this in the last thread. * As of now the keywords remain all UPPERCASE. I'm happy to change them to all lowercase or mixed case if there's a consensus that such a change is desired. Given the last thread it seems clear there will not be consensus on any outcome of this particular question. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 4:12 PM, Benjamin Poulain benja...@webkit.orgwrote: On Wed, Jun 13, 2012 at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: webkit.org/12345 WIN MAC DEBUG \ animations/stop-animation-on-suspend.html \ CRASH TEXT PASS My bikeshedding: -In my opinion, the backslash is not any better than the old delimiter. It looks like we are escaping something. I liked better the proposal to have platform and results grouped instead of the delimiter. e.g: webkit.org/12345 (WIN MAC DEBUG) animations/stop-animation-on-suspend.html (CRASH TEXT PASS) -I prefer lowercase keywords, possibly with the first character uppercase (Crash, Text, Pass, Fail, Win, Mac, Debug). Do we use all uppercase keywords somewhere else in the project? So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 3:58 PM, Darin Adler da...@apple.com wrote: On Jun 13, 2012, at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: * we use \ (backslash) as a delimiter instead of : and = Seems worse to me. When I see a backslash I assume it’s a line continuation character or a C escape sequence. On the other hand, neither the : nor the = meant anything to me either, and I suggested dropping the delimiter entirely, so I’m not sure my feedback will get listened to! That's a bit harsh. listened to does not necessarily mean will do what you ask :). Plenty of other people have said that they liked delimiters, so I think you just got outvoted. Are there other delimiters you might prefer to ':' and '=' ? Others suggestions have included bracketing the test name , and or uniformly using one of : , = - ; , or as Benjamin or Ryoskue have suggested, bracketing the keywords ... For the record, I didn't like bracketing the test name since brackets make it look optional. I could be open to bracketing the modifiers and keywords, since the modifiers are optional, and it would seem reasonable to make the absence of keywords equivalent to SKIP ... * As of now the keywords remain all UPPERCASE. I'm happy to change them to all lowercase or mixed case if there's a consensus that such a change is desired. I DON'T LIKE READING THINGS IN ALL UPPERCASE AND WOULD VERY MUCH LIKE THAT TO CHANGE. Would you prefer lowercase, lowercase_with_underscores, Initialcaps, MixedCase ... ? On Wed, Jun 13, 2012 at 4:12 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jun 13, 2012 at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: webkit.org/12345 WIN MAC DEBUG \ animations/stop-animation-on-suspend.html \ CRASH TEXT PASS My bikeshedding: -In my opinion, the backslash is not any better than the old delimiter. It looks like we are escaping something. I liked better the proposal to have platform and results grouped instead of the delimiter. e.g: webkit.org/12345 (WIN MAC DEBUG) animations/stop-animation-on-suspend.html (CRASH TEXT PASS) -I prefer lowercase keywords, possibly with the first character uppercase (Crash, Text, Pass, Fail, Win, Mac, Debug). Do we use all uppercase keywords somewhere else in the project? C++ macros are the only place I know of. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 4:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 13, 2012 at 4:12 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jun 13, 2012 at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: webkit.org/12345 WIN MAC DEBUG \ animations/stop-animation-on-suspend.html \ CRASH TEXT PASS My bikeshedding: -In my opinion, the backslash is not any better than the old delimiter. It looks like we are escaping something. I liked better the proposal to have platform and results grouped instead of the delimiter. e.g: webkit.org/12345 (WIN MAC DEBUG) animations/stop-animation-on-suspend.html (CRASH TEXT PASS) -I prefer lowercase keywords, possibly with the first character uppercase (Crash, Text, Pass, Fail, Win, Mac, Debug). Do we use all uppercase keywords somewhere else in the project? So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! This seems quite readable to me as well. As mentioned above, I'd be inclined to make the absence of [] on the right hand side mean SKIP. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 13, 2012 at 4:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 13, 2012 at 4:12 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jun 13, 2012 at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: webkit.org/12345 WIN MAC DEBUG \ animations/stop-animation-on-suspend.html \ CRASH TEXT PASS My bikeshedding: -In my opinion, the backslash is not any better than the old delimiter. It looks like we are escaping something. I liked better the proposal to have platform and results grouped instead of the delimiter. e.g: webkit.org/12345 (WIN MAC DEBUG) animations/stop-animation-on-suspend.html (CRASH TEXT PASS) -I prefer lowercase keywords, possibly with the first character uppercase (Crash, Text, Pass, Fail, Win, Mac, Debug). Do we use all uppercase keywords somewhere else in the project? So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! This seems quite readable to me as well. As mentioned above, I'd be inclined to make the absence of [] on the right hand side mean SKIP. That sounds very reasonable. In fact, I'd argue that it should be the only way to skip tests. It makes no sense to have any other test expectation when a test is skipped because the types of failures of skipped tests (when actually ran) will very likely change over time, and there is no way to track them. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 4:38 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 13, 2012 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jun 13, 2012 at 4:26 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 13, 2012 at 4:12 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jun 13, 2012 at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: webkit.org/12345 WIN MAC DEBUG \ animations/stop-animation-on-suspend.html \ CRASH TEXT PASS My bikeshedding: -In my opinion, the backslash is not any better than the old delimiter. It looks like we are escaping something. I liked better the proposal to have platform and results grouped instead of the delimiter. e.g: webkit.org/12345 (WIN MAC DEBUG) animations/stop-animation-on-suspend.html (CRASH TEXT PASS) -I prefer lowercase keywords, possibly with the first character uppercase (Crash, Text, Pass, Fail, Win, Mac, Debug). Do we use all uppercase keywords somewhere else in the project? So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! This seems quite readable to me as well. As mentioned above, I'd be inclined to make the absence of [] on the right hand side mean SKIP. That sounds very reasonable. In fact, I'd argue that it should be the only way to skip tests. It makes no sense to have any other test expectation when a test is skipped because the types of failures of skipped tests (when actually ran) will very likely change over time, and there is no way to track them. There's still a distinction between SKIP (temporary) and WONTFIX (permanent until some plan changes) that we should preserve, I think. It could be useful to indicate SKIP CRASH or SKIP TIMEOUT as well, but I agree that the type of failure will probably change over time. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! This seems quite readable to me as well. As mentioned above, I'd be inclined to make the absence of [] on the right hand side mean SKIP. I like that. Maybe TestExpectations is not the right name because of Skip? TestExceptions would be better? I don't care about the name of the file, this is just a random idea. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
As long as we're considering TitleCase for the keywords, could we use it to keep all of them as single words? WontFix, SkipCrash, SkipTimeout --Tom On Jun 13, 2012, at 4:46 PM, Dirk Pranke wrote: There's still a distinction between SKIP (temporary) and WONTFIX (permanent until some plan changes) that we should preserve, I think. It could be useful to indicate SKIP CRASH or SKIP TIMEOUT as well, but I agree that the type of failure will probably change over time. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev On Jun 13, 2012 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! This seems quite readable to me as well. As mentioned above, I'd be inclined to make the absence of [] on the right hand side mean SKIP. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
Skip and WontFix have a different purpose than Crash and timeout; the first two (like slow) tell you what to do with the test, and the latter tell you what you expect the test to result in. I don't want to combine them into single tokens because that would cause an explosion of tokens :). -- Dirk On Wed, Jun 13, 2012 at 4:55 PM, Tom Zakrajsek t...@codeaurora.org wrote: As long as we're considering TitleCase for the keywords, could we use it to keep all of them as single words? WontFix, SkipCrash, SkipTimeout --Tom On Jun 13, 2012, at 4:46 PM, Dirk Pranke wrote: There's still a distinction between SKIP (temporary) and WONTFIX (permanent until some plan changes) that we should preserve, I think. It could be useful to indicate SKIP CRASH or SKIP TIMEOUT as well, but I agree that the type of failure will probably change over time. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev On Jun 13, 2012 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! This seems quite readable to me as well. As mentioned above, I'd be inclined to make the absence of [] on the right hand side mean SKIP. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 4:55 PM, Tom Zakrajsek t...@codeaurora.org wrote: As long as we're considering TitleCase for the keywords, could we use it to keep all of them as single words? WontFix, SkipCrash, SkipTimeout For skipped tests, it doesn't make sense to have crash, timeout, etc... because we wouldn't know even if failure types changed from text to crash, or from timeout to image. It's just a pure noise as far as I'm concerned. On Jun 13, 2012, at 4:46 PM, Dirk Pranke wrote: There's still a distinction between SKIP (temporary) and WONTFIX (permanent until some plan changes) that we should preserve, I think. The way I see it, WontFix and NotImplemented, like bug URL, are orthogonal to other test expectations. They tell us why we have a given test expectation but doesn't define the expectation itself. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 5:05 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Jun 13, 2012 at 4:55 PM, Tom Zakrajsek t...@codeaurora.org wrote: As long as we're considering TitleCase for the keywords, could we use it to keep all of them as single words? WontFix, SkipCrash, SkipTimeout For skipped tests, it doesn't make sense to have crash, timeout, etc... because we wouldn't know even if failure types changed from text to crash, or from timeout to image. It's just a pure noise as far as I'm concerned. Well, when you add the skip rule, you presumably know what happens when you run the test. Since you can actually run tests that are skipped using --force or --skipped=ignore/only (which I'm adding to NRWT as we speak), it's not quite noise, but I agree that it's pretty close. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Jun 13, 2012, at 3:58 PM, Darin Adler da...@apple.com wrote: On Jun 13, 2012, at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: * we use \ (backslash) as a delimiter instead of : and = Seems worse to me. When I see a backslash I assume it’s a line continuation character or a C escape sequence. On the other hand, neither the : nor the = meant anything to me either, and I suggested dropping the delimiter entirely, so I’m not sure my feedback will get listened to! * As of now the keywords remain all UPPERCASE. I'm happy to change them to all lowercase or mixed case if there's a consensus that such a change is desired. I DON'T LIKE READING THINGS IN ALL UPPERCASE AND WOULD VERY MUCH LIKE THAT TO CHANGE. I also hate all-caps keywords and would prefer mixed case or all-lowercase, but I'm willing to discuss that for a future round of changes if we can't get agreement now. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Wed, Jun 13, 2012 at 5:42 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 13, 2012, at 3:58 PM, Darin Adler da...@apple.com wrote: On Jun 13, 2012, at 3:53 PM, Dirk Pranke dpra...@chromium.org wrote: * we use \ (backslash) as a delimiter instead of : and = Seems worse to me. When I see a backslash I assume it’s a line continuation character or a C escape sequence. On the other hand, neither the : nor the = meant anything to me either, and I suggested dropping the delimiter entirely, so I’m not sure my feedback will get listened to! * As of now the keywords remain all UPPERCASE. I'm happy to change them to all lowercase or mixed case if there's a consensus that such a change is desired. I DON'T LIKE READING THINGS IN ALL UPPERCASE AND WOULD VERY MUCH LIKE THAT TO CHANGE. I also hate all-caps keywords and would prefer mixed case or all-lowercase, but I'm willing to discuss that for a future round of changes if we can't get agreement now. I think most of the people who liked all-caps mostly wanted there to be *some* sort of delimiter. Anyone not okay with: webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...
On Jun 13, 2012, at 4:26 PM, Ryosuke Niwa rn...@webkit.org wrote: So something like webkit.org/12345 [Win Mac Debug] animations/stop-animation-on-suspend.html [Crash Text Pass] ? I like that! Yes, looks good to me too. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] editbugs permission
Hi there, I'd like to ask for EditBugs permission for dstockw...@chromium.org, who has already landed a couple of patches and is helping us triage bugs. thanks! mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] editbugs permission
On Jun 13, 2012, at 9:25 PM, Mike Lawther wrote: Hi there, I'd like to ask for EditBugs permission for dstockw...@chromium.org, who has already landed a couple of patches and is helping us triage bugs. Done ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] editbugs permission
On Jun 13, 2012, at 9:25 PM, Mike Lawther wrote: I'd like to ask for EditBugs permission for dstockw...@chromium.org, who has already landed a couple of patches and is helping us triage bugs. Someone must have seen this and granted permission, because I went to do so and he already had it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
