(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 on the
(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).
But
I think I got a little confused.
--read-var-info=yes will eat up all your memory (at least with libxul.so)
for very little benefit. I suggest not using it.
But ithout --read-var-info=yes, it is a little difficult to
--track-origins=yes provides you with useful information. If that
doesn't
I think I got a little confused.
I was thinking of --read-var-info=yes
instead of --track-origins=yes.
Sorry about the confusion.
memgrind can grok --track-origins=yes with (debug build) of TB
in 64 bit linux fine.
It is --read-var-info=yes
that causes a big problem.
I allocated 6GB to my 64
On (2013年01月30日 04:30), Gary Kwong wrote:
--enable-valgrind --smc-check=all-non-file
I was not clear enough.
I was compling with --enable-valgrind,
and uses --smc-check=all-non-file when TB was executed
under valgrind/memcheck already.
The only missing piece was --track-origins=yes, which
I
On (2013年01月29日 19:02), 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 the problematic code quickly enough in
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 the problematic code quickly enough in
(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 the
(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
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/mozilla/security/nss/lib/base/hash.c#53
(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.
(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
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...
--
Warning: May contain traces of nuts.
___
dev-platform
On 01/28/2013 10:08 PM, L. David Baron wrote:
On Tuesday 2013-01-29 11:04 +0900, ISHIKAWA, Chiaki wrote:
We need to know which javascript file generated the
uninitialized value usage to figure out the problem and fix it.
That is, we need to find out the Context within JavaScript itself.
I
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 memory, and
--enable-valgrind turns on
(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
Running with --track-origins=yes should help with debugging this problem.
-Gary
Below are some lines from memcheck session log of running TB under it.
The number of such usages recorded in one session log is
68 Memcheck:Cond
Close to 60 of them are related to
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 the stack trace when this condition is noticed.
(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 the
20 matches
Mail list logo
