Dear Steve,
Thank you for the feedback.
Also I would like to thank other people whose e-mails
also give an glimpse of the depth of the problem.
On 2014/10/03 4:49, Steve Fink wrote:
On 10/02/2014 11:59 AM, ISHIKAWA,chiaki wrote:
Hi,
I was looking at a large number of JavaScript (strict
Hi,
I was looking at a large number of JavaScript (strict) warnings, and
errors from the recording of |make mozmill| test run of locall-built
DEBUG BUILD of TB last several days after a refresh of C-C source tree.
The number of such has increased very much both
- due to the seemingly stricter
(2014/05/22 22:40), thills wrote:
Hi All,
I'm facing an error when downloading the latest code from mercurial,
doing a build and then trying to run the mochitest-browser tests.
I face the following error about 6 minutes into the test run.
console.error:
6:30.14 [CustomizableUI]
6:30.14
Hi,
This was discussed before somewhere (in bugzilla ?) although I could not
find it now)
I noticed a rather slow processing of POP3 e-mail fetching on a PC with
scsi disk.
At each message download, I can hear a clicking sound coming from a SCSI
disk suggesting a large amount of disk activity.
(2014/04/24 21:49), Till Schneidereit wrote:
(CC'ing people who have worked on the ICU integration)
On Thu, Apr 24, 2014 at 2:31 PM, Henri Sivonen hsivo...@hsivonen.fi wrote:
However, especially in the context of slimming down our own set of
encoding converters, it's rather demotivating to
(2014/04/22 2:09), Joshua Cranmer wrote:
On 4/21/2014 11:50 AM, Ehsan Akhgari wrote:
You can check CONFIG['MOZ_BUILD_APP'] against what you pass to
--enable-application in mozconfig files. So that would be 'mailnews' (or
'mail'?) and 'suite' for Thunderbird and Seamonkey respectively.
Hi,
I have been analyzing warning/error/assertion lines produced
by full debug version of TB (comm-central).
To facilitate the analysis I created a few scripts to
process the error statistically.
Staring 1Q of 2014, I think such lines are prefixed with [pid] .
Now that probably is very good, but
(2014/04/07 14:27), Karl Tomlinson wrote:
It is allowed in N3242. I think the relevant sections are
5.2.9 Static cast
Thank you for the pointer.
I found a floating copy of n3242.pdf at the following url.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
I think 7.2 10 is
(2014/04/07 10:16), Karl Tomlinson wrote:
because enumeration types may hold values that don't match any of
their enumerator values.
Is this allowed by C (or C++) specification today?
[Yes, I know the compiler in the past did not care much.]
I thought the stricter warnings of compilers today
Recently after a refesh of code from comm-central,
I noticed that running |make mozmill|
TB test suite using full DEBUG BUILD of TB produced the
following warning lines:
System JS : WARNING
file:///REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/components/steelApplication.js:783
- mutating the
(2014/03/29 12:27), Boris Zbarsky wrote:
On 3/28/14 6:42 PM, Neil wrote:
Boris Zbarsky wrote:
But slow here is a relative term. Last I measured, something like a
basic property get in Ion code went from 2-3 instructions to 20-30
instructions when we deoptimize.
...
What about calls from
(2014/02/08 0:31), David Rajchenbach-Teller wrote:
When we encounter main thread I/O, most of the time, it is something
that should be rooted out. However, in a few cases (e.g. early during
startup, late during shutdown), these pieces of I/O should actually be
left untouched.
Since main thread
(2014/02/08 4:13), David Keeler wrote:
On 02/07/14 10:31, ISHIKAWA, Chiaki wrote:
Message:
[10549] WARNING: Security network blocking I/O on Main Thread: file
/REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp,
line 422
This generally happens when javascript
(2014/01/16 2:07), ISHIKAWA, Chiaki wrote:
...
Since refreshing my local copy of comm-central tree a couple of days
ago (my previous update was around Dec 25+ last year), I have not been
able to run the test suite |make mozmill| for TB (local DEBUG BUILD)
under valgrind (Debian GNU/Linux
for this.)
(2014/01/17 18:39), Henri Sivonen wrote:
On Thu, Jan 16, 2014 at 7:28 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote:
(2014/01/16 12:22), Zack Weinberg wrote:
On 2013-11-26 5:40 AM, Neil wrote:
Henri Sivonen wrote:
On Windows, do we really need to pay homage to the pre-NT legacy when
(2014/01/16 12:22), Zack Weinberg wrote:
On 2013-11-26 5:40 AM, Neil wrote:
Henri Sivonen wrote:
On Windows, do we really need to pay homage to the pre-NT legacy when
doing Save As? How about we just use UTF-8 for HTML Page, complete
reserialization like on Mac?
You'll need a BOM, of
nvoking |make mozmill| TB test suite by running DEBUG BUILD of TB
under valgrind has turned out to be useful in finding memory-related
errors, AND timing-related thread race issues. The issues of second
kind, i.e., timing issues, are not usually noticed, but often they
become obvious due to the
(2013/09/10 19:17), ishikawa wrote:
[ omissions ]
I am getting the hang of emacs mode line.
/* -*- Mode: javascript; tab-width: 8; indent-tabs-mode: nil;
c-basic-offset: 2 ; js-indent-level : 2 ; js-curly-indent-offset: 0 -*- */
/* vim: set ts=2 et sw=2 tw=80: */
seem to do the job.
For quite some time (a few months at least), I noticed during the build
of thunderbird (comm-central) that shows the memory reduction by
elf-hack is NEGATIVE value.
For example, the following is from the compilation of latest source
(refreshed in the last 72 hours or so).
[...]
=== If you get
I am trying to create a low-disk condition for testing I/O errors during
|make mozmill| test suite run of thunderbird.
I am not sure where the various files are stored during |make mozmill|.
I can think of TMP, TMPDIR, and a few other
settings.
Does anyone have an idea of overview of the file
(2013/11/22 1:47), Ehsan Akhgari wrote:
On 2013-11-21 11:41 AM, ISHIKAWA,chiaki wrote:
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds
work is
by using
(2013/11/22 2:17), Ehsan Akhgari wrote:
FWIW if this proves to be common, it's a huge problem since it would
affect our crash stats etc... :(
Well, if the problem is related to the symptom
that I observed with the use of -gsplit-dwarf option
with ccache, then we may be in for a big surprise.
(2013/11/15 7:49), Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds work is
by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build
files. With that, the build system
(2013/11/14 9:18), Ted Mielczarek wrote:
On 11/13/13 3:34 PM, Mike Habicher wrote:
Hello everyone,
I'm working on automated tests for Gecko's camera code on B2G, and I
want to replace different pieces of the implementation with fake
objects that return one or more injected error codes so that
Hi,
I noticed that either mxr behaves erratically,
or there is a single incorrect entry for HG blame.
Case in point:
From mxr's comm-central page
https://mxr.mozilla.org/comm-central/
I searched for an ID:
nsresultForErrno
and obtained a few lines of listing.
There is only one definition.
(2013/09/21 9:03), Gregory Szorc wrote:
The mach script in the root directory of mozilla-central is a generic
command dispatching tool. Have a piece of commonly used functionality
useful to many people? Create a mach command so others can use it easily!
While mach started with commands dealing
(2013/09/14 13:37), Reuben Morais wrote:
On Sep 11, 2013, at 12:04 PM, Scott Johnson sjohn...@mozilla.com wrote:
I understand the merit of leaving the code as is since hg blame won't work
nicely with such file-wide format change as in step-1.
(Or maybe we can teach hg blame to ignore such
(2013/09/09 21:18), Dao wrote:
On 09.09.2013 05:15, ishikawa wrote:
I have been recently editing javascript files to
reduce warnings but found an issue of adopted styls in comm-central
thunderbird codes.
I checked for the preferred style:
[1] I found one reference here:
(2013/04/11 4:24), Mihai Sucan wrote:
Hello Joshua!
Le 10/04/2013 20:41, Joshua Cranmer a écrit :
On 4/10/2013 12:05 PM, Mihai Sucan wrote:
If anyone has any concerns about us replacing the Error Console, please shout
loud and clear! We plan to do the
aforementioned steps to replace the
(2013/04/11 23:43), Joshua Cranmer wrote:
On 4/11/2013 2:43 AM, ishikawa wrote:
Has anyone seen the problem of the patches to M-C portion of the
COMM-CENTRAL not accepted by Thunderbird TryServer because the patches
fail although linux32 and linux64 work as expected?
The bug is that the
(2013/04/03 16:32), ishikawa wrote:
On (2013年04月03日 15:32), Mike Hommey wrote:
On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote:
FYI: Upgrading binutils to 2.23.2 did not help.
(Well, at least I got a better memory usage report when
memory was exhausted. ld printed out that it fails
(2013/03/19 2:31), Mark Banner wrote:
On 18/03/2013 16:27, Jason Smith wrote:
- BootToGecko - Big focus at Mozilla with a lot of people working on
this project, so I think this could benefit greatly from being on the
front page.
This should be Firefox OS as that's what the users will know it
(2013/03/01 11:10), ISHIKAWA, Chiaki wrote:
(2013/02/27 22:35), ISHIKAWA, Chiaki wrote:
(2013/02/27 0:53), Neil wrote:
ishikawa wrote:
By the way, does looking at IDL header/declaration files help me to figure out
where the double is returned?
You would have to peek in the locals
This is a report of a possible bug related to this.
It also has the serious disadvantage that
mistakes result in exploitable use-after-frees, rather than unexploitable
leaks. It also causes various problems with the WebIDL binding
codegenerator in its current incarnation.
I just ran across an
(2013/02/01 11:47), ISHIKAWA, Chiaki wrote:
(2013/02/01 11:34), Joshua Cranmer wrote:
On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote:
(2013/02/01 1:48), Joshua Cranmer wrote:
On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote:
Sorry, it may not have been ldap code (my memory is now hazy
(2013/01/31 19:46), Neil wrote:
ishikawa wrote:
Neil wrote:
ISHIKAWA, Chiaki wrote:
I see some code most notably LDAP code in comm-central is not 64bit clean
Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time
now...
Now I cannot seem to find
(2013/02/01 0:41), ISHIKAWA, Chiaki wrote:
(2013/01/31 19:46), Neil wrote:
ishikawa wrote:
Neil wrote:
ISHIKAWA, Chiaki wrote:
I see some code most notably LDAP code in comm-central is not 64bit clean
Really? Thunderbird has been releasing 64-bit Mac and Linux code for some time
now
(2013/02/01 1:48), Joshua Cranmer wrote:
On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote:
Sorry, it may not have been ldap code (my memory is now hazy).
But please take a look at this code. I am using comm-central code
for development/debugging TB.
https://mxr.mozilla.org/comm-central/source
(2013/02/01 11:34), Joshua Cranmer wrote:
On 1/31/2013 8:26 PM, ISHIKAWA, Chiaki wrote:
(2013/02/01 1:48), Joshua Cranmer wrote:
On 1/31/2013 9:41 AM, ISHIKAWA, Chiaki wrote:
Sorry, it may not have been ldap code (my memory is now hazy).
But please take a look at this code. I am using comm
(2013/01/30 4:30), Gary Kwong wrote:
There should be very few warnings within the current Spidermonkey. I
suspect you may not be compiling with --enable-valgrind. This is
necessary because Spidermonkey uses a conservative garbage collector
that intentionally accesses lots of uninitialized
(2013/01/29 19:03), Julian Seward wrote:
From: Chiaki ISHIKAWA ishik...@yk.rim.or.jp
I could allocate 6 GB to linux 64 bits images for ordinary program
execution on my PC
But debug build of TB with all the symbols and such causes the memory
usage (including the loading of symbols)
I am
I noticed many uninitialied value usage warnings from the execution of
TB under valgrind (memcheck).
Many such usages, today, are related to JavaScript interpreter. memcheck
can print the stack trace when this condition is noticed. However,
we only get the traceback of the javascript
(2013/01/29 15:08), L. David Baron wrote:
On Tuesday 2013-01-29 11:04 +0900, ISHIKAWA, Chiaki wrote:
I noticed many uninitialied value usage warnings from the execution of
TB under valgrind (memcheck).
Many such usages, today, are related to JavaScript interpreter. memcheck
can print
(2013/01/08 13:13), ishikawa wrote:
On (2013年01月08日 13:03), Joshua Cranmer wrote:
On 1/7/2013 10:00 PM, ishikawa wrote:
If we can coerce the built-in traceback function to print something more
meaningful, or
if someone can suggest a way to attach gdb to a run of TB during make
mozmill
101 - 144 of 144 matches
Mail list logo
