(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 stack trace when this condition is noticed. However,
we only get the traceback of the javascript interpreter itself in this
case. This is not very useful.
In general, as Gary said, running with --track-origins=yes can make
memcheck's warnings about use of uninitialized variables much more
useful.
Thank you for the pointers.
In this case, I am stuck.
My machine has 8 GB memory and I run linux images in VM Player for testing.
I am using 32 bit linux (Debian GNU/Linux) mostly. But in this setup, I hit the
limit of
2GB memory space somehow. During the startup, memcheck barfs, if I specify
--track-origins=yes,
saying that about 300MB of memory was necessary to load the additional symbols, but already it had used pretty close to
2GB of memory space and could not proceed.
(Oh well. I thought full 4GB space is available for linux 32bit, but maybe not. I don't know if my kernel has PTE
enabled or not.)
Without --track-origins=yes, I can run debug build of TB under memcheck but it
requires almost half a day to
finish "make mozmill" test run of debug build under memcheck on my machine.
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)
to be very lage and I could not get debug build of TB run under memcheck in 64 bit linux run reasonably fast enough.:
lots of paging even in 6GB assigned to the 64 bit linux image. (I saw the execution looked stuck without any progress
for half and our so, and notice so many paging activity, and I gave up before. Very slow progress is almost equal to no
progress to me practically speaking.)
This happens despite the fact that 64 bit compilation ought to reduce the
runtime memory access usage.
(Maybe the increase of symbole table due to 64bit vs 32 bit address difference
is large enough to
offset the reduced memory access of 64 bit compilation.)
Aside from the slowness [my CPU is not the latest generation CPU, too bad.],
another reason I don't usually use 64 bit compilation
is that I see some code most notably LDAP code in comm-central is not 64bit
clean and
so I stayed away from 64 bit compilation for now :-(
I think we need someone with much more powerful (more specifically more memory,
say 16GB or something like that)
to track this down then :-(
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 don't think this is the case; there shouldn't be JavaScript code
that can lead to valgrind uninitialized memory usage warnings. The
behavior of uninitialized variables in JavaScript is well-defined.
Does JavaScript interpreter throws an error when "undefined" value is evaluated
and expected to produce valid
value?
If so, then it is indeed the JavaScript interpreter that seems to have the
uninitialized value problems because such JavaScript interpreter error is not
observed.
In any case, the sudden surge of such warnings
of uninitialized value usages make me uncomfortable anyway.
I didn't see it toward the end and the new year.
Just for a remote possibility:
Is there any chance that there is a standalone smaller executable that has the
JavaScript interpreter in it.
(I often see XULrunner mentioned, and I wonder what that is, and I wonder if it is a smallish execution environment with
JavaScript interpreter in it. If so, such an executable might be debugged on my resource-poor PC (well 8GB and 3GHz CPU
is not a resource-poor PC in general sense, but I digress), though I am not sure if I can re-create the similar error
conditions to produce the errors reported in such execution target. Hmm...
-David
Thank you again.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
