Re: Valgrind-on-TBPL
On Thu, Dec 12, 2013 at 9:48 AM, Nicholas Nethercote n.netherc...@gmail.com wrote: Unfortunately, on December 5th, just before the changes were enabled, something else happened that caused the Valgrind jobs to start timing out all the time. This is being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=948145. I now have a loaner build slave on which I can reproduce the problem. All indications are that the Quitter extension, which the pgo-profile runs use to quit the browser, is not loading properly -- there's a Quitter is not defined error message. As a result, Firefox never quits, and the run hangs. I tracked this down to one of the Quitter files being a symlink with a relative path, and that path was going awry when the file was copied elsewhere within the chroot that the tests run in on the build slaves(!) And by the time I worked this out, glandium had inadvertently fixed the problem by landing an unrelated patch that happened to change that symlink to one with an absolute path. Weird, but at least the Valgrind builds are working again. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Improvements to the Sphinx in-tree documentation generation
After I announced the in-tree build docs powered by Sphinx a few months ago [1], a few people came to me and said that's really cool - I want something like that for my module. I'm pleased to announce that as of bug 939367 landing in inbound a few hours ago, you can now deposit Sphinx docs anywhere in the tree and they will get picked up during `mach build-docs`. This feature is self-documenting and you can find the instructions in the output of `mach build-docs` or at [2]. See build/docs or services/docs in the tree for what this looks like in practice. Yes, the docs use the old MDN theme. They will use the new theme once someone updates [3]. For all I know, someone is already hard at work doing that. We also have bug 920314 tracking getting these docs published on MDN. Sphinx is extremely extensible. If you have ideas for better integrating it with anything, let me know! Please report any issues or questions you may have. Core :: Build Config for now. [1] https://groups.google.com/d/msg/mozilla.dev.platform/HQOL8YKiJmE/wlvktOlQSpIJ [2] https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.html [3] https://github.com/lmorchard/mozilla-mdn-sphinx-theme ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Valgrind-on-TBPL
On 12/12/2013 3:43 AM, Nicholas Nethercote wrote: I tracked this down to one of the Quitter files being a symlink with a relative path, and that path was going awry when the file was copied elsewhere within the chroot that the tests run in on the build slaves(!) And by the time I worked this out, glandium had inadvertently fixed the problem by landing an unrelated patch that happened to change that symlink to one with an absolute path. Weird, but at least the Valgrind builds are working again. I find it odd that we didn't see this in any other scenario, since the PGO builds use this same script for the profiling run. Anyway, glad it's fixed! -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Should we disable autoplay feature of HTMLMediaElement on mobile?
Hi, I think two prefs are needed. In addition to the pref discussed in this topic, make all media on any tabs be click-to-play is needed to ensure the Web Accessibility. UAAG2 (User Agent Accessibility Guidelines 2.0) LCWD [1] contains two Level A success criteria related to this topic. - 2.11.1 Time-Based Media Load-Only The user can override the play on load of recognized time-based media content such that the content is not played until explicit user request. - http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/#sc_2111 - 2.11.2 Execution Placeholder The user can request a placeholder instead of executable content that would normally be contained within an on-screen area (e.g. Applet, Flash), until explicit user request to execute. - http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/#sc_2112 # Please refer Implementing UAAG 2.0 for user scenarios of each success criterion. IMHO, to comply UAAG2 (LCWD), we need only one pref: make all media be click-to-play. However I think lexer prefs are preferred for general cases and I agree that we implement such prefs. To summarize my opinion, make all media be click-to-play should be implemented when we implement the prefs (or features) that control autoplay/play(). Best wishes, Takeshi [1] User Agent Accessibility Guidelines (UAAG) 2.0 http://www.w3.org/TR/2013/WD-UAAG20-20131107/ Implementing UAAG 2.0 http://www.w3.org/TR/2013/WD-IMPLEMENTING-UAAG20-20131107/ Robert Kaiser: Henri Sivonen schrieb: If autoplay is disabled by default, Web authors will take counter-measures and start playback from JavaScript. However, if autoplay is honored by default but the user can turn in off as a pref, it could be that Web authors won't bother to take counter-measures. It probably should be a visual pref somewhere, but I agree that the default should be to enable autoplay on foreground tabs. On background tabs, I think all media should be click-to-play by default though, if possible - both for not needlessly waste power (which might be just as precious on a laptop than a mobile device, the lines are blurry anyhow) and for not surprising people (or making multiple tbas that one opens in the background all run autostarted media elements at the same time, creating a big jumble on the speakers). KaiRo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
= Data and Background = See, as some anecdotal evidence: Bug 930797 is a user who just upgraded to Firefox 25 and is seeing these a lot. dmajor tracked this down to our video implementation creating many threads, each of which has an x86 stack as well as a 1MB memory reservation for the wow64 stack. At the point of the crash, there are 330 threads, which collectively uses about 400MB of address space just for the thread stacks. Many of these threads appear to be created by the Windows media platform code, although there are some Mozilla media threads as well. cpearce is currently looking at this. Bug 937290 is another user who just upgraded to Firefox 25 Nobody is currently helping this user. It doesn't look consistent enough to do easy nightly bisection, unfortunately. There was also a bug which was showing up as an OOM crash but was in fact a a memory corruption issue. == Measurement == * Move minidump collection out of the Firefox process. Turns out this wasn't necessary (although it would still be a good thing to do): dmajor figured out that there was a bug in the code I originally wrote to reserve memory for the crash reporter, and that is now fixed and our empty-dump crash rate is very much reduced. * Develop a tool/instructions for users to profile the VM allocations in their Firefox process. dmajor has some instructions for doing this using xperf at https://etherpad.mozilla.org/sOCISHDFSm which we'll clean up and put in a more permanent home in a bit. It does involve installing xperf and setup and know-how, so it's not something we could give to ordinary users. But for fairly technical users this may be a way to identify issues. * The about:memory patches which add contiguous-vm measurement should probably be uplifted to Fx26, and any other measurement tools that would be valuable diagnostics. This is done, and we also discovered that the breakpad reserved memory was breaking this data so we fixed that in crash-stats also. Also, we now have the ability to use DMD builds on Windows; so in the cases where memory usage shows up in about:memory as heap-unclassified, we can profile the memory usage that way. Huge shout-outs to dmajor, nick nethercote, and Catalin Iacob for making all these tools better! == Graphics Solutions == The issues reported in bug 930797 at least appear to be related to HTML5 video rendering. The STR aren't precise, but it seems that we should try and understand and fix the issue reported by that user. Disabling hardware acceleration does not appear to help. The thread issue mentioned above with video decoding appears to be at least partly to blame for this, but we're not sure how much. == Dealing with OOM crash sites == I am working on generating some reports on existing crashes where OOMAllocationSize is variable, and also crash signatures that correlate highly with OOM conditions. We should fix these sites. These bugs are being filed as blockers of tracking bug 943017: https://bugzilla.mozilla.org/showdependencytree.cgi?id=943017hide_resolved=0 Thanks to Ehsan, Peiyong Lin, and Allessio Placitelli who have fixed several already and are working on a few more. I'll continue to file the most common sites as I discover them. == New Data == With the empty-dump count reduced and the breakpad reservation excluded, I have some new data from nightly builds: https://docs.google.com/spreadsheet/ccc?key=0Ag3-54eJ7D8OdDJSV2xaeEROdjRIM1FzYmdjY1QwclEusp=sharing This is a dump of the Windows crash from this morning which *either* have an OOMAllocationSize annotation indicating that jemalloc couldn't allocate memory, *or* have less than 50MB of contiguous free VM space. The most important columns to track are LargestVirtualBlock, OOMAllocationSize, AvailableVirtualMemory and AvailablePageFile. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reacting more strongly to low-memory situations in Firefox 25
On Fri, Dec 13, 2013 at 2:53 AM, Benjamin Smedberg benja...@smedbergs.us wrote: Also, we now have the ability to use DMD builds on Windows DMD works on Windows debug builds, but doesn't currently work on opt builds. But https://bugzilla.mozilla.org/show_bug.cgi?id=947117 (compile-time) and https://bugzilla.mozilla.org/show_bug.cgi?id=948621 (run-time) are tracking the problems and shouldn't take long to fix. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Disabling Mac builds/tests for mozilla-b2g18 and mozilla-b2g18-v1.1.0hd
Hello all, After disabling the Win7 tests on those b2g18 trees, I was told by the sheriffs that the MacOS X testing is redundant. Again: * these are repositories where only security fixes are being landed * this is not about b2g26 * we have testing coverage through Linux, Linux64, Android Noion + B2g emulator test jobs If you have any concerns/questions/objections please raise them up in: https://bugzilla.mozilla.org/show_bug.cgi?id=949522 cheers, Armen https://tbpl.mozilla.org/?tree=Mozilla-B2g18 https://tbpl.mozilla.org/?tree=Mozilla-B2g18-v1.1.0hd ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
(un)safety of NS_LITERAL_STRING(...).get()
Recently bug 539710 landed[0] to fix an unnecessary and apparently unsafe operation: const PRUnichar *comma = NS_LITERAL_STRING(,).get(); Curious, I did a quick search for other examples of NS_LITERAL_STRING combined with .get() and found that this appears to be common[1]. So, I have a few questions for anyone with some insight: - Is this pattern always unsafe? - Is it sometimes unsafe? (if so, when/why?) - Should we do some cleanup and avoid things like this? (or maybe this is an outdated concern and isn't an issue anymore?) Cheers, David [0] https://bugzilla.mozilla.org/show_bug.cgi?id=539710 [1] https://mxr.mozilla.org/mozilla-central/search?string=NS_LITERAL_STRING.*getregexp=1case=1find=findi=filter=^[^\0]*%24hitlimit=tree=mozilla-central ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (un)safety of NS_LITERAL_STRING(...).get()
On 12/12/2013 6:52 PM, David Keeler wrote: Recently bug 539710 landed[0] to fix an unnecessary and apparently unsafe operation: const PRUnichar *comma = NS_LITERAL_STRING(,).get(); Curious, I did a quick search for other examples of NS_LITERAL_STRING combined with .get() and found that this appears to be common[1]. So, I have a few questions for anyone with some insight: - Is this pattern always unsafe? - Is it sometimes unsafe? (if so, when/why?) NS_LITERAL_STRING creates a temporary object that is cleaned up at the end of the statement. So it's a safe pattern for passing as an argument to a function, but not for initializing a variable. - Should we do some cleanup and avoid things like this? (or maybe this is an outdated concern and isn't an issue anymore?) Given that PRUnichar is now unconditionally typedef'd to our version of char16_t (and the patch has landed for a long while without being backed out yet), I think we should now be able to use MOZ_UTF16(,) instead of NS_LITERAL_STRING(,).get(). MOZ_UTF16 is basically a choice between using L or U depending on compiler support for char16_t and thus is always safe. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (un)safety of NS_LITERAL_STRING(...).get()
On Thursday 2013-12-12 16:52 -0800, David Keeler wrote: Recently bug 539710 landed[0] to fix an unnecessary and apparently unsafe operation: const PRUnichar *comma = NS_LITERAL_STRING(,).get(); Curious, I did a quick search for other examples of NS_LITERAL_STRING combined with .get() and found that this appears to be common[1]. So, I have a few questions for anyone with some insight: - Is this pattern always unsafe? - Is it sometimes unsafe? (if so, when/why?) - Should we do some cleanup and avoid things like this? (or maybe this is an outdated concern and isn't an issue anymore?) It used to be unsafe on platforms where we didn't use wide string literals. We've since dropped support for such platforms (in bug 904985), so it's no longer unsafe. However, given that we no longer support such platforms, it's also a bunch of extra complexity that we no longer need. The preferred form would now be: #include mozilla/Char16.h const PRUnichar *comma = MOZ_UTF16(,); -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (un)safety of NS_LITERAL_STRING(...).get()
On Thu, Dec 12, 2013 at 07:01:18PM -0600, Joshua Cranmer ? wrote: On 12/12/2013 6:52 PM, David Keeler wrote: Recently bug 539710 landed[0] to fix an unnecessary and apparently unsafe operation: const PRUnichar *comma = NS_LITERAL_STRING(,).get(); Curious, I did a quick search for other examples of NS_LITERAL_STRING combined with .get() and found that this appears to be common[1]. So, I have a few questions for anyone with some insight: - Is this pattern always unsafe? - Is it sometimes unsafe? (if so, when/why?) NS_LITERAL_STRING creates a temporary object that is cleaned up at the end of the statement. So it's a safe pattern for passing as an argument to a function, but not for initializing a variable. certainly theoretically unsafe, but I'd expect practically its fine. - Should we do some cleanup and avoid things like this? (or maybe this is an outdated concern and isn't an issue anymore?) Given that PRUnichar is now unconditionally typedef'd to our version of char16_t (and the patch has landed for a long while without being backed out yet), I think we should now be able to use MOZ_UTF16(,) instead of NS_LITERAL_STRING(,).get(). MOZ_UTF16 is basically a choice between using L or U depending on compiler support for char16_t and thus is always safe. yeah, I just ran sed -i 's/NS_LITERAL_STRING(\(.*\)).get()/MOZ_UTF16(\1)/' $(find -name *.cpp) and the same for *.h and *.cc I'm building it now. Trev -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (un)safety of NS_LITERAL_STRING(...).get()
On 12/12/13, 5:09 PM, L. David Baron wrote: The preferred form would now be: #include mozilla/Char16.h const PRUnichar *comma = MOZ_UTF16(,); I think char16_t is preferred over PRUnichar for new code. chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (un)safety of NS_LITERAL_STRING(...).get()
On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson cpeter...@mozilla.comwrote: On 12/12/13, 5:09 PM, L. David Baron wrote: The preferred form would now be: #include mozilla/Char16.h const PRUnichar *comma = MOZ_UTF16(,); I think char16_t is preferred over PRUnichar for new code. Someone take bug 927728! Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: (un)safety of NS_LITERAL_STRING(...).get()
On 12/12/2013, 9:18 PM, Robert O'Callahan wrote: On Fri, Dec 13, 2013 at 3:02 PM, Chris Peterson cpeter...@mozilla.comwrote: On 12/12/13, 5:09 PM, L. David Baron wrote: The preferred form would now be: #include mozilla/Char16.h This #include is actually not needed. That header is available everywhere. const PRUnichar *comma = MOZ_UTF16(,); Yes please! I think char16_t is preferred over PRUnichar for new code. Yessir! Someone take bug 927728! I have taken it! I'm waiting for the mingw situation to clear up before going ahead with the conversion. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
WebIDL Windows clobber issue hopefully resolved
Just landed in inbound are patches that hopefully resolve the issue where WebIDL changes required a clobber on Windows. Please stop touching CLOBBER when modifying WebIDL files. Please be on the lookout for WebIDL build system oddities. Please be advised that developer workflow for updating WebIDL files has changed slightly. See [1]. Report issues in bug 928195. FWIW, WebIDLs are a complicated aspect of the build system and I wouldn't be surprised if there are rocky times for the next few days. I apologize in advance for any rough sailing. [1] https://bugzilla.mozilla.org/attachment.cgi?id=8346405 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebIDL Windows clobber issue hopefully resolved
On 12/12/2013 10:34 PM, Gregory Szorc wrote: Just landed in inbound are patches that hopefully resolve the issue where WebIDL changes required a clobber on Windows. Please stop touching CLOBBER when modifying WebIDL files. Please be on the lookout for WebIDL build system oddities. Please be advised that developer workflow for updating WebIDL files has changed slightly. See [1]. Report issues in bug 928195. FWIW, WebIDLs are a complicated aspect of the build system and I wouldn't be surprised if there are rocky times for the next few days. I apologize in advance for any rough sailing. [1] https://bugzilla.mozilla.org/attachment.cgi?id=8346405 Thanks for all the hard work on this Greg. I know you've been busting your rear on this and it's very much appreciated. -Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: WebIDL Windows clobber issue hopefully resolved
On 12/12/13 10:34 PM, Gregory Szorc wrote: Just landed in inbound are patches that hopefully resolve the issue where WebIDL changes required a clobber on Windows. Thank you again for picking this up and getting it done! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
