Re: Improved stacks in Linux crash reports

On 2020/11/10 14:49, Gabriele Svelto wrote: On 10/11/20 05:57, ISHIKAWA,chiaki wrote: Does this support split dwarf object files? Not yet, but it should be possible to add support easily because the crates we depend on for parsing DWARF debuginfo have just been updated to support split DWARF

Re: Improved stacks in Linux crash reports

On 2020/11/06 17:56, Gabriele Svelto wrote: [cross-posting to dev-platform] Hello all, I'm glad to announce that we switched our symbol scrapers for Linux distributions to our new and improved Rust-based tooling [1]. This means that when looking at crash reports or profiling you will not find

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

I think I have found an inconsistency in TB's pref setting during mochitest regarding e10s. The gory detail is in https://bugzilla.mozilla.org/show_bug.cgi?id=1629433#c10 Major find (excerpt from the above bugzilla.) --- begin quote --- 1) Dynamically generated user.js files during tests of

Re: Proposal: remove support for running desktop Firefox in single-process mode (e10s disabled) anywhere but in tests

I can't speak for what TB development plan is. One thing I observe as an occasional submitter of TB patches is this. Thunderbird ditched |mozmill| test December 2019, and switched to mochitest in place of mozmill test. Unfortunately, valgrind no longer works locally for mochitest. This is

Re: Cargo.lock in hg repository?

I have rebased and the changes are gone. Thank you for keeping the tree in good shape. Chiaki On 2020/05/19 18:35, Emilio Cobos Álvarez wrote: On 5/19/20 3:11 AM, ISHIKAWA,chiaki wrote: Thank you for the feedback. So I am not alone in seeing this. I will ignore the anomaly for now although

Re: Cargo.lock in hg repository?

1636068.  -- Emilio On 5/17/20 2:44 PM, ISHIKAWA,chiaki wrote: I am developing TB patches locally on my linux PC. Have anyone noticed mozilla/Cargo.lock seems to be in mercurial repository and that it got updated during development? That is, as far as *I* am concerned, I never tough it directly

Cargo.lock in hg repository?

I am developing TB patches locally on my linux PC. Have anyone noticed mozilla/Cargo.lock seems to be in mercurial repository and that it got updated during development? That is, as far as *I* am concerned, I never tough it directly. But, it seems |mach clobber|, |mach configure|, |mach build|

Re: Is --disable-libjpeg-turbo gone?

On 2020/05/16 7:51, Mike Hommey wrote: On Sat, May 16, 2020 at 07:24:44AM +0900, ISHIKAWA,chiaki wrote: I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB locally). After an update of the local source tree this morning, it is no longer recognized? (The last update

Is --disable-libjpeg-turbo gone?

I have --disable-libjpeg-turbo in my mozconfig for many years (I build TB locally). After an update of the local source tree this morning, it is no longer recognized? (The last update was several days ago.) Has anyone also experienced this? Traceback (most recent call last):   File

Re: New and improved stack-fixing

that the stack trace thus obtained was trash. (See https://bugzilla.mozilla.org/show_bug.cgi?id=1621274 ) Strange. linux-stack-fix.py  used to work when the output was not modified by the recent fix-stack. That is what I used to for many years. TIA Chiaki On 2020/04/30 3:07, ISHIKAWA,chiaki wrote

Re: New and improved stack-fixing

Thank you for the tips. I will have a go to incorporate the logic of old fix_linux_stack.py into fix-stacks. TIA Chiaki On 2020/04/29 13:11, Nicholas Nethercote wrote: On Wed, 29 Apr 2020 at 02:32, ISHIKAWA,chiaki wrote: Ouch, I am using -gsplit-dwarf to make gdb startup time faster

Re: New and improved stack-fixing

On 2020/04/28 18:13, Nicholas Nethercote wrote: On Tue, 28 Apr 2020 at 17:50, ISHIKAWA,chiaki wrote: 0:28.98 GECKO(727384) #01: ??? (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so + 0x5ab5921) 0:28.99 GECKO(727384) #02: ??? (/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so

Re: New and improved stack-fixing

16:50, ISHIKAWA,chiaki wrote: Dear Nick, I must have been doing something very stupid, but can't figure out exactly. I think after this change of fix-stack script(s), the local TB's mochitest log's NS_ASSERTION (or is it MOZ_ASSERT?) stack trace cannot be decoded. I scratched my head

Re: New and improved stack-fixing

Dear Nick, I must have been doing something very stupid, but can't figure out exactly. I think after this change of fix-stack script(s), the local TB's mochitest log's NS_ASSERTION (or is it MOZ_ASSERT?) stack trace cannot be decoded. I scratched my head and figured out that there is

Re: Deprecation notice - change to Treeherder's jobdetail API

On 2020/04/11 3:03, Steve Fink wrote: On 4/10/20 10:06 AM, Andrew McCreight wrote: On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements wrote: Hello, As part of maintenance work and performance improvements to Treeherder, we're making changes to some of the data that's stored in our database. On

Re: Bugzilla posting failure.

Dear Emma, Thank you very much for your e-mail. I see. - Now I understand "resolved as dup" hides the post. (Just an idea: We may want to consider an option to see the original post instead of our own posts [duped to the original] if the original post is not resolved yet.) Bugzilla is a

Bug 1578296 JavaScript error: resource://gre/modules/SessionStoreFunctions.jsm, line 392: NS_ERROR_FILE_NOT_FOUND

Hi, I filed the following entry to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1578296 Bug 1578296 Many errors of the form JavaScript error: resource://gre/modules/SessionStoreFunctions.jsm, line 392: NS_ERROR_FILE_NOT_FOUND during |make mozmill| testing of Full Debug of C-C TB.

Re: Help: why won't Thunderbird display mail in mochitest conditions?

Hi, those familiar with test infrastructure I am sorry that I am piggybacking my question/comment on a not directly related topic. During xpcshell test of TB, no display (of X11, say, under linux) is shown. Is this a design decision and is to be expected? If TB tries to show an error

Re: Must we rebuild all our rust code constantly?

to be compiling TB. I added the following in my mozconfig for TB, but I am not sure if this is the right way to disable incremental compilation. mk_add_options "export CARGO_INCREMENTAL=0" TIA On 2019/08/22 11:22, ISHIKAWA,chiaki wrote: Well, I have a problem now after trying to upda

Re: Must we rebuild all our rust code constantly?

Well, I have a problem now after trying to update sccache just in case I need a new version in the future. I did the following: cargo install --force sccache (I was not so sure of what the proper update procedure of already installed package. sccache 2.0.8-alpha-something was already

Re: Must we rebuild all our rust code constantly?

On 2019/08/21 3:52, Eric Rahm wrote: mach clobber --full Thank you for the tips. I will try this. At the same time, I have a feeling that the debug symbol that rustc generates may be a tad bigger than I would like it to be, but I need to investigate more about this. Chiaki

Re: Must we rebuild all our rust code constantly?

On 2019/08/20 14:32, Kris Maglione wrote: On Tue, Aug 20, 2019 at 02:23:06PM +0900, ISHIKAWA,chiaki wrote: On 2019/08/20 9:11, Dave Townsend wrote: Thanks to a tip I've tracked this down. This seems to only be the case when I have sccache enabled. Disabling it gives me nice quick incremental

Re: Must we rebuild all our rust code constantly?

On 2019/08/20 9:11, Dave Townsend wrote: Thanks to a tip I've tracked this down. This seems to only be the case when I have sccache enabled. Disabling it gives me nice quick incremental builds again. Of course that isn't an ideal solution but it will do for now. On Mon, Aug 19, 2019 at 1:55 PM

Re: clang version on tryserver?

024 );   mCopyState->m_fileStream = tmp_out; On 2019/07/31 5:45, ISHIKAWA,chiaki wrote: Dear Steve, Thank you for your analysis and suggestion for moving to gcc-8. I would change my local GCC compiler to gcc-8, and g++-8. Also, I would modify the offending code so that the evaluation

Re: clang version on tryserver?

0:15, Steve Fink wrote: On 7/30/19 6:20 AM, Jan de Mooij wrote: On Tue, Jul 30, 2019 at 1:51 PM ISHIKAWA,chiaki wrote:     nsresult rv2   = NS_NewBufferedOutputStream(getter_AddRefs(mCopyState->m_fileStream), mCopyState->m_fileStream.forget(),  <=== It seems this can be nullptr

Re: clang version on tryserver?

PM ISHIKAWA,chiaki wrote: nsresult rv2 = NS_NewBufferedOutputStream(getter_AddRefs(mCopyState->m_fileStream), mCopyState->m_fileStream.forget(), <=== It seems this can be nullptr in clang-8 version??? 64 * 1024 ); This looks like it could

clang version on tryserver?

Hi, What is the version of clang used on tryserver? The local clang-8 I have on my linux PC crashes due to internal compiler error during optimization pass, and I want to know what version is used on tryserver. I have been using GCC for compiling TB locally and intend to do so just because

Re: HG problem: abort: decoding near '9: error: ‘sse2::l': 'ascii' codec can't decode byte 0xe2 in position 213: ordinal not in range(128)

re local memo files. It is very annoying and again the problem was traced to encode/decode in python runtime. Thank you again. On Sat, Dec 1, 2018 at 11:53 PM ISHIKAWA,chiaki wrote: Hi, I am developing mozilla patches locally under my local PC running linux. I often include the GCC's e

HG problem: abort: decoding near '9: error: ‘sse2::l': 'ascii' codec can't decode byte 0xe2 in position 213: ordinal not in range(128)

Hi, I am developing mozilla patches locally under my local PC running linux. I often include the GCC's error/warning message in the mercurial commit message (in the second and subsequent lines, the first line is for usage by mozilla's bugzilla procedure.) when my local patch is created to

Re: Prefs overhaul

On 2018/03/07 12:08, Nicholas Nethercote wrote: Hi, I've been doing a lot of work to improve libpref recently, and there is more in the pipeline. I've written a brief roadmap that might be of interest to people: https://wiki.mozilla.org/Platform/PrefsOverhaul I'd be happy to hear feedback, via

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 2017/12/06 1:04, Jonathan Kew wrote: On 05/12/2017 15:16, Henri Sivonen wrote: On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: There are other non-ASCII character issues such as https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 Very weird bug! (S

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 2017/12/05 22:24, Henri Sivonen wrote: On Mon, Dec 4, 2017 at 2:04 PM, Masatoshi Kimura wrote: * If by any chance a profile path contains non-ASCII characters on non-UTF-8 UNIX systems, Firefox 57.0.1 must have broken the profile just like 57.0 broke it on Windows. But

Re: We need better canaries for JS code

I am for stricter checks and crashing the test when some of the errors discussed here are detected. I have been puzzled when some attributes are undefined as such when I ran tests for Thunderbird in the past. The bugs are found non-Thunderbird-specific code often times. Crashing the tests

Re: Intent to require `mach try` for submitting to Try

Does "mozilla/mach try" will work for try-comm-central? (Well, I know there has been a general talk of moving thunderbird to somewhere else, but it is not going to happen overnight.) TIA ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to ship: Changing default Japanese fonts to modern fonts

as default settings). FYI: We still need to keep using legacy "MS Gothic" font for default Japanese monospace font since Windows doesn't have modern monospace font. On 8/24/2017 7:47 AM, ISHIKAWA,chiaki wrote: Hi, I use firefox under Windows most of the time, and so it will be

Re: Intent to ship: Changing default Japanese fonts to modern fonts

Hi, I use firefox under Windows most of the time, and so it will be very nice. But obviously this is only for Windows platform, and does not affect linux or OSX versions. Correct? On 2017/08/23 14:19, Masayuki Nakano wrote: Hi, We decided that we should change our default Japanese fonts

Re: sccache as ccache

On 2017/08/06 2:06, ISHIKAWA,chiaki wrote: On 2017/08/04 20:46, Simon Sapin wrote: On 04/08/2017 13:02, Mike Hommey wrote: On Fri, Aug 04, 2017 at 11:25:52AM +0200, Simon Sapin wrote: `mk_add_options export RUSTC_WRAPPER=sccache` causes an error: It's `mk_add_options "export RUSTC_WR

Re: sccache as ccache

On 2017/08/04 20:46, Simon Sapin wrote: On 04/08/2017 13:02, Mike Hommey wrote: On Fri, Aug 04, 2017 at 11:25:52AM +0200, Simon Sapin wrote: `mk_add_options export RUSTC_WRAPPER=sccache` causes an error: It's `mk_add_options "export RUSTC_WRAPPER=sccache"`. That worked, thanks! I now have:

Re: Shipping Headless Firefox on Linux

On 2017/06/16 6:47, Mike Hommey wrote: On Thu, Jun 15, 2017 at 04:51:48PM -0400, Ben Kelly wrote: On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: Headless will run less of the platform specific

Re: Shipping Headless Firefox on Linux

On 2017/06/16 5:33, Andrew Sutherland wrote: On Thu, Jun 15, 2017, at 03:27 AM, ishikawa wrote: On local machine, when I added a modal error dailog as a response to an error condition, which happens to be artificially created and tested in xpcshell test, the test fails because the screen or

Re: Shipping Headless Firefox on Linux

On 2017/06/16 0:52, Brendan Dahl wrote: Depending on how the dialog was triggered, it may just work in headless mode. To run the test in headless mode, add "headless = true" to the test in your xpcshell.ini. Also, if you're in headless mode you can check it by calling gfxPlatform::IsHeadless()

Re: Improving visibility of compiler warnings

Hi, On 2017/05/20 19:36, Martin Thomson wrote: On Sat, May 20, 2017 at 4:55 AM, Kris Maglione wrote: Can we make some effort to get clean warnings output at the end of standard builds? A huge chunk of the warnings come from NSS and NSPR, and should be easily fixable.

Re: Should &&/|| really be at the end of lines?

On 2017/02/18 7:28, Bobby Holley wrote: On Fri, Feb 17, 2017 at 2:18 PM, wrote: Hi again Nick, Someone made me realize that I didn't fully read your message, sorry for that. I now see that as well as &&/||, you have grepped for other operators, and shown that the

Re: Changing the representation of rectangles in platform code

On 2017/02/14 8:37, gsquel...@mozilla.com wrote: On Tuesday, February 14, 2017 at 3:25:05 AM UTC+11, Ehsan Akhgari wrote: On 2017-02-11 3:27 AM, ISHIKAWA,chiaki wrote: On 2017/02/11 7:07, Botond Ballo wrote: On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic <msrec...@mozilla.com> wrote:

Re: A reminder about MOZ_MUST_USE and [must_use]

On 2017/01/20 8:10, Nicholas Nethercote wrote: There are lots of functions where not checking the return value is reasonable, such as close(). A file opened for writing and is buffered will flush pending data to disk upon Close() and may encounter the error such as disk full AT THAT POINT,

Re: GCC 4.9 now required to build on Linux/Android

On 2016/12/24 1:54, Nathan Froyd wrote: On Fri, Dec 23, 2016 at 11:37 AM, Mike Hoye wrote: On 2016-12-23 11:08 AM, Nathan Froyd wrote: Bug 1322792 has landed on inbound, which changes configure to require GCC 4.9 to build; our automation switched over to GCC 4.9 for our

Re: hg.mozilla.org certificate fingerprint changed?

the fingerprints for the servers when some mismatch is reported by tools like ssh/https-related tools, and decide to update the local check/verification data assuming that they have missed the update announcements. TIA -r On Fri, Sep 30, 2016 at 12:18 PM, ISHIKAWA,chiaki <ishik...@

hg.mozilla.org certificate fingerprint changed?

In the last few days, hg.mozilla.org certificate fingerprint seems to have changed. I noticed this because the trial to update local copy of mozilla-central repository within C-C repository failed due to m-central/mozilla', 'https://hg.mozilla.org/mozilla-central/'] pulling from

Strange error message on try-comm-central: Error: Invalid addon ID: expected addon ID specialpow...@mozilla.org, found special-pow...@mozilla.org in manifest

While perusing error log of try-comm-central run of Windows 7 debug version run of |make mozmill| test on try-comm-central treeherder, I noticed a strange error message. 3:07:56 INFO - 1474488476446 addons.xpi-utils WARN addMetadata: Add-on specialpow...@mozilla.org is invalid: Error:

Re: NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

On 2016/09/22 5:56, Daniel Holbert wrote: On 09/21/2016 12:48 PM, ISHIKAWA,chiaki wrote: In the following URL about coding style, https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style --- begin quote --- if (NS_WARN_IF(somethingthatshouldbetrue)) { return

Re: NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

On 2016/09/02 16:02, Nicholas Nethercote wrote: Greetings, NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION. See https://bugzilla.mozilla.org/show_bug.cgi?id=1299727 for details, including the justification. See https://bugzilla.mozilla.org/show_bug.cgi?id=137 for a bug that this

Re: All profile settings lost in new version

On 2016/09/02 20:15, Wayne wrote: I'm wondering, under what circumstances would a user have a prefs.js-1 and prefs.js be missing? ref https://support.mozilla.org/en-US/questions/1136992 ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Heads up: valgrind/memcheck issues

and Valgrind on mozilla-central, so it seems likely this is Thunderbird specific. Please file security bugs in bugzilla with any reports you have found. Andrew On Thu, Aug 25, 2016 at 10:59 AM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: Hi, I occasionally check C-C TB by running |make m

Heads up: valgrind/memcheck issues

Hi, I occasionally check C-C TB by running |make mozmill| test suite under valgrind/memcheck for detecting memory issues. I ran such a test the day before and saw a flurry of memcheck warnings which I did not see in the test that was run back on May 12th. So in three months between, some

Re: New [must_use] property in XPIDL

On 2016/08/25 6:38, Mike Hommey wrote: On Mon, Aug 22, 2016 at 04:39:15PM -0700, R Kent James wrote: On 8/21/2016 9:14 PM, Nicholas Nethercote wrote: I strongly encourage people to do likewise on any IDL files with which they are familiar. Adding appropriate checks isn't always easy Exactly,

Re: mach and ccache failure?

On 2016/08/20 10:03, Jan Varga wrote: I see the same problem on my mac, but I didn't investigate why it's not working anymore. Did ccacge ever work on the Mac to support two directories? (I mean the compilation result in one object directory could be substituted for the other object

Re: Using rr chaos mode to find intermittent bugs

On 2016/02/11 5:47, Robert O'Callahan wrote: On Thu, Feb 11, 2016 at 9:32 AM, Ted Mielczarek wrote: BenWa tried doing some work on this but kept getting hung up on hitting test failures unrelated to the ones we see in production, possibly due to environment issues. Yes.

Re: Using rr chaos mode to find intermittent bugs

On 2016/02/11 7:04, Robert O'Callahan wrote: rr should work fine with c-c xpcshell tests (and most other Linux programs). This sounds great! CI ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Strange errors n OS X platform

On 2015/12/15 23:40, Philip Chee wrote: On 13/12/2015 16:26, ISHIKAWA, Chiaki wrote: {"fun":"getCurrentDirectory","id":2} 14:54:20 INFO - PROCESS | 5963 | OS Controller Message posted 14:54:20 INFO - PROCESS | 5963 | OS Controller Expecting reply

Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

On 2015/11/24 20:21, Philip Chee wrote: On 22/11/2015 03:20, ISHIKAWA,chiaki wrote: 35 Chrome file doesn't exist: /NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/toolkit/skin/classic/global/icons/information-64.png information-64.png only exists in the osx theme http://mxr.mozilla.org

Re: Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

On 2015/11/23 14:00, Philip Chee wrote: On 22/11/2015 03:20, ISHIKAWA,chiaki wrote: 100 Chrome file doesn't exist: /NREF-COMM-CENTRAL/objdir-tb3/dist/bin/chrome/classic/skin/classic/messenger/icons/dropbox.png Was removed in Bug 763471 - Convert Dropbox Filelink provider code to addon

Question: why an external DTD is accessed (or not)? (svg11.dtd)

Hi, I have been puzzled at a pair of strange warning messages over the last few years, but can't hold the curiosity any longer. So here is my question. During the invocation of TB |make mozmill| test suite by running locally produced DEBUG version of C-C test, I have seen the following

Re: Question: why an external DTD is accessed (or not)? (svg11.dtd)

Thank you for the clarification. It is assuring to know that some people are aware of the issue. On 2015/11/22 3:59, Kyle Huey wrote: Bug 994305 is on file for this. - Kyle On Sat, Nov 21, 2015 at 10:57 AM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: Hi, I have been puzzled at

Question: "Chrome file doesn't exist: ..." in |make mozmill| log by running DEBUG versions of C-C TB

Here is another question of mine that has bothered me for a long time. During the invocation of TB |make mozmill| test suite by running locally produced DEBUG version of C-C test, I have seen the following WARNING messages in the log regarding "Chrome file doesn't exist". I checked the

Re: Error of OS X build (c-c TB)

On 2015/11/16 17:03, ISHIKAWA,chiaki wrote: On 2015/11/15 14:28, Xidorn Quan wrote: On Sun, Nov 15, 2015 at 1:05 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: On 2015/11/14 12:31, Xidorn Quan wrote: Have you checked your log here: https://treeherder.mozilla.org/logviewer.html#?

Re: Error of OS X build (c-c TB)

On 2015/11/15 14:28, Xidorn Quan wrote: On Sun, Nov 15, 2015 at 1:05 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: On 2015/11/14 12:31, Xidorn Quan wrote: Have you checked your log here: https://treeherder.mozilla.org/logviewer.html#?job_id=11934=try-comm-central - Xidorn Yes,

Re: Error of OS X build (c-c TB)

On 2015/11/15 11:05, ISHIKAWA,chiaki wrote: On 2015/11/14 12:31, Xidorn Quan wrote: Have you checked your log here: https://treeherder.mozilla.org/logviewer.html#?job_id=11934=try-comm-central - Xidorn Yes, I have looked at it. The information there is sparse. The error indicates

Re: Error of OS X build (c-c TB)

not sure why others don't bump into this issue under OS X. My patch does NOT touch anything related to "TextArea", etc. TIA On Sat, Nov 14, 2015 at 1:05 PM, ISHIKAWA,chiaki <ishik...@yk.rim.or.jp> wrote: Hi, I am trying to test my patches by building C-C TB under OS X using try

Error of OS X build (c-c TB)

Hi, I am trying to test my patches by building C-C TB under OS X using try server. However, the build fails with the following compilation error. Since I don't have OS X (my local PC runs linux), I have no idea why the error occurs under OS X. BTW, I can build C-C TB under linux on my local PC,

Re: Merging comm-central into mozilla-central (summary v1)

On 2015/10/27 9:06, Philipp Kewisch wrote: Hi all, I'd love to see if we can move towards an agreement. For those of you that would prefer not to merge, I'd love to hear what your absolute minimum requirements would be that you'd accept a merge with. Changes to hg? Changes to dxr? A policy

Re: Strange Error: Reentrancy error: some client, attempted to display a message to the console while in a console,listener

On 2015/07/02 4:30, Andrew Sutherland wrote: This is probably due to https://dxr.mozilla.org/comm-central/source/mailnews/test/resources/logHelper.js that registers itself as a console listener and its low-tech feedback loop prevention. (NB: The quippy file-level comment should be

Re: Strange Error: Reentrancy error: some client, attempted to display a message to the console while in a console,listener

On 2015/07/01 15:53, Robert Strong wrote: I've only seen those when anything tries to print to the console after a test has called do_test_finish and in that case I suspect it is due to xpcshell shutting down, etc. Robert Thank you for your observation. I will investigate if this happens

Re: The War on Warnings

On 2015/06/17 8:29, Eric Rahm wrote: An update on progress. I've landed bugs which should clean up ~180,000 warnings. I have bugs pending for another ~26,000. The latest top 40: *Note: I improved my normalization a bit so it might look a bit different Are there documents explaining why

Re: Revisiting modelines in source files

Assessing style compliance as == clang-format(whole file) is by far the easiest to implement. I'd be in favor of a flag day (or set of mini flag days) where we mass rewrite the tree with clang-format's output. To be honest, I don't care WHICH particular style we follow, but please set the

Re: The War on Warnings

Hi, On 2015/06/06 2:39, Eric Rahm wrote: On Friday, June 5, 2015 at 8:23:53 AM UTC-7, ISHIKAWA,chiaki wrote: After coping with voluminous messages in C-C TB |make mozmill| test suite log [much smaller volume than full FF logs], I think we should have NS_INFORMATION() macro that prints out

Re: The War on Warnings

On 2015/06/04 21:38, Robert O'Callahan wrote: Usually I use NS_WARNING to mean something weird and unexpected is happening, e.g. a bug in Web page code, but not necessarily a browser bug. Sometimes I get useful hints from NS_WARNING spew leading up to a serious failure, but for those usages

DBM code too old (Re: mozmill test: Hightail ???)

I changed the subject: Followup-to: mozilla.dev.platform On 2015/05t/29 16:41, ishikawa wrote: Hi, I have been testing locally built FULL DEBUG C-C thunderbird using |make mozmill| test suite. When I tinkered with low-level I/O testing by simulating short read, I saw about a couple of

Re: Replacing Mozmill driven tests for Firefox with Marionette

Ouch, there was a line near the end. Successfully installed jsbridge-2.4.14 mozmill-1.5.16 This is from a local C-C TB build. CI ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

A question about do_QueryInterface()

Lately, I refreshed comm-central thunderbird code and tested my local modification to enable buffering of writing downloaded message to a local mail store. (This is about when one uses POP3. Please bear this in mind. Imap testing is further along.) I noticed a couple of things: (1) File API

Re: A question about do_QueryInterface()

Thank you for the clarification. On 2015/05/01 3:38, Boris Zbarsky wrote: On 4/30/15 2:25 PM, ISHIKAWA, Chiaki wrote: Is this to be expected? Sure. You're taking an _output_ stream and QIing it to nsI_Input_Stream. Yes, that is how the original code was written. It might happen

Re: Excessive inbound bustage

On 2015/04/22 22:15, Ehsan Akhgari wrote: Note that it's not just the turn around time that can become an issue. For me personally the reasons I choose to not use the try server are: 1) If I have ~20 unlanded patches in my queue (which is normal for my workflow on an average day), I need to

Re: Running C-C TB under valgrind during mozmill test: extending timeout values (but where?)

(Just this once, I post to m.d.platform and m.d.a.firefox) I found out that firefox's mochitest can be run under valgrind according to How Do I Run A Mochitest Under Valgrind? in https://developer.mozilla.org/en-US/docs/Mozilla/Testing/Valgrind e.g.: ./mach mochitest-plain --debugger=valgrind

Re: Using address sanitizer with GCC 4.9 to compile C-C TB

on Linux are a supported and tested Firefox configuration so there is a good chance that it works well for Thunderbird as well. ASAN builds using gcc is neither tested nor supported as far as I know. On 2015-03-24 10:15 PM, ISHIKAWA,chiaki wrote: Hi, I filed the following bugzilla to share my

Using address sanitizer with GCC 4.9 to compile C-C TB

Hi, I filed the following bugzilla to share my experience of using address sanitizer with GCC 4.9 (*NOT CLANG*) to compile C-C TB. Bug 1147248 - GCC 4.9 + Address Sanitizer + C-C TB: Compiling comm-central thunderbird using address sanitizer, -fsanitize=address using GCC 4.9 I wonder what I did

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On 2015/02/03 15:24, Mike Hommey wrote: On Tue, Feb 03, 2015 at 02:27:52PM +0900, ISHIKAWA,chiaki wrote: I did a non-unified build and saw the expected failure. This is a summary of what I saw. Background: I may need to modify and debug basic I/O routines on local PC, and so want to avoid

Re: Memory management in C programs

On 2015/01/12 22:46, Philip Chee wrote: One large difference between C and most other programming languages is that in C, you have to handle memory yourself rather than having a garbage collector do it for you. Ensuring that memory is allocated at the correct moment is not very difficult (and

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

On 2015/01/15 10:37, Steve Fink wrote: On 01/14/2015 11:26 AM, Ehsan Akhgari wrote: From now on, the only supported build mode is unified compilation. I am planning to follow-up with removing support for the --disable-unified-compilation configure option altogether in bug 1121000. I

C-C TB performance issue: unbuffered write where it can use buffering.

(I posted this to https://bugzilla.mozilla.org/show_bug.cgi?id=558528#c46 as a permanent record, but I am posting this to a couple of newsgroups with a few typo fixes and added comments to solicit a solution re how to fix this performance issue from a wider audience.) I have spotted a very

Re: Is anyone still using JS strict warnings?

(2014/12/20 5:19), Jason Orendorff wrote: So if you go to about:config and set the javascript.options.strict pref, you'll get warnings about accessing undefined properties. js Math.TAU undefined /!\ ReferenceError: reference to undefined property Math.TAU (It says

Re: Unified compilation is going to ride the train

On 2014/11/28 18:26, Mike Hommey wrote: On Fri, Nov 28, 2014 at 11:57:56AM +0900, ISHIKAWA,chiaki wrote: On 2014/11/28 10:12, Mike Hommey wrote: Hi, A year ago, when unified compilation was introduced to speed up builds, a couple issues were raised and we conservatively restricted them out

Re: Unified compilation is going to ride the train

On 2014/11/28 10:12, Mike Hommey wrote: Hi, A year ago, when unified compilation was introduced to speed up builds, a couple issues were raised and we conservatively restricted them out of aurora/beta/release/esr. A year later, it's time to revisit this decision, and since afaik we haven't had

profiler in TB

Hi, I thought I try profiler to see how it works in TB, but I get the following error. It looks a module called |panel| is not usable in TB. I looked at jetpack-panel-apps web page noted in the message, but am clueless. Error Message: error: geckoprofiler: An exception occurred. Error: The

Re: profiler in TB

, and I could not create a new message any more. I had to restart TB. I was checking the issue, and left an empty composite window lying around, and I must have used THAT window for this message. Sorry about broken threading info.) On 2014/10/26 11:48, ISHIKAWA,chiaki wrote: Hi, I thought I

Re: MSE WebM/VP9 enabled on nightly

On 2014/10/24 13:46, Anthony Jones wrote: I just wanted to give a heads up to everyone that we enabled Media Source Extensions on nightly for WebM/VP9. This brings Adaptive Streaming capability to Firefox video playback. The feature is not complete so the pref will automatically turn off when it

Has something changed about nsITreeView (nsItreeView.setTree) lately?

Hi, I posted the following message to mozilla.dev.builds newsgroup, but I wonder if there is a mozilla-wide change to nsITreeView lately? I noticed this while testing a patch to C-C TB locally. (Considering that COMM-CENTRAL may have a slight delay in getting M-C changes, it may be that

Incorrect line number reported by JS engine for warnings?

Lately, the stricter checks from JS engines produced many warnings during the test suite run (|make mozmill|) of locally built DEBUG BUILD of C-C thunderbird. These in themselves are very good to make code better, more robust, etc. However, today I noticed a few problems of line numbers thus

Re: Incorrect line number reported by JS engine for warnings?

warning: resource://gre/modules/FormHistory.jsm, line 639: ReferenceError: reference to undefined property change.guid TIA On 2014/10/13 11:45, Boris Zbarsky wrote: On 10/12/14, 9:54 PM, ISHIKAWA, Chiaki wrote: In this bugzilla, line 693 is actually out of range for the file reported. The file

Re: Removing ancient and unused code from tools/

On 2014/10/13 13:36, Nicholas Nethercote wrote: - tools/rb/ -- most, if not all, scripts actively used Thank you for the clean up work. I am using fix_linux_stack tool under tools/rb/ for cleaning up non symbolic stack trace in the log of DEBUG BUILD of TB when I am testing

Testing framework does not wait for correct dialog sometimes.

Hi, I am not sure where to post, but since this affects every platform, here it goes. I noticed several months ago that some javascript test programs that run during |make mozmill| test suite wait for dialogs during the execution. But I also realized that there is no distinction for dialogs.

Re: Fwd: JavaScript (strict) Warning from FF mochitest-plain test.

I am for this proposal, too. We need to spend a little man-power in the areas other than implementing new features :-) Fixing seemingly innocent warnings, etc. may not look a glorious task, but we need to do this to ship quality software (not that today's versions are not good quality, but we

  1   2   >