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 bit linux image in VMPlayer and instead of about 3.9GB image of "--track-origins=yes" run, the image grows close to 6GB (or more, not sure because of heavy paging) when I added --read-var-info=yes, and due to heaving paging nothing proceeds reasonably fast. Actually it causes too many software interrupts, and hardware interrupts and linux kernel prints some warnings. But ithout --read-var-info=yes, it is a little difficult to figure out which variable/memory area is to blame when an initialization value access occurs (yes, the numerical address is printed, but not quite helpful unless we know the exact stack layout, etc.) I wonder if valgrind can be told to call "abort()" in the context of calling program when it notices an non-initialization value access. [Or for that matter, any function that user specifies, but "abort()" seems to be a good choice due to the following reason.] "make mozmill" test suite recognizes "abort" condition, i.e, when a program terminates with NULL pointer dereferencing, etc., and suggests that the user can connect to the terminated program from gdb using its remote debugging feature and waits for like 300 seconds before proceeding to run the next test target. During that time, I can connect to the terminated program image using gdb and obtain stack trace with symbol information. So if I can tweak memgrind to call abort() in the context of the instrumented program, I can obtain a stack trace with symbolic dump when a non-initialized value access is observed. Just a thought. (Yes, the stack immediately before the call to abort needs to be carefully constructed, but calling abort is doable, that is worth doing in my situation.) I don't have to monitor "make mozmill" run all the time manually, but probably can run "make mozmill" using TCL/Expect and monitor the condition, and run gdb and invoke stack tracing dump command (bt), etc. automatically. I read the valgrind man page and didn't find anything resembling this feature. TIA On (2013年01月29日 16:37), ISHIKAWA, Chiaki wrote: > > (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
