Talk:Valgrind

x86 Code, Not Always...

In the first few paragraphs is talks about the ucode being turned back into x86 code and vice versa, which is not strictly true, as valgrind does run on PPC processors as well, which means that the code is being turned into PPC assembly, rather than x86. Can someone correct this?

POV issues

Isn't a phrase like "It has an excellent reputation" without any kind of reference a highly POV statement? Arthurrh 20:47, 31 October 2006 (UTC)

I have added the supporting references, check the list of projects! --vineeth 07:24, 1 November 2006 (UTC)

yeah this project is great. we use it at work all the time. Elie 19:28, 19 January 2007 (UTC)

The term excellent reputation also made me think of the POV issue. Although valgrind is very useful, the article would do well to mention one serious limitation: valgrind cannot detect errors in the stack usage, including automatic arrays. (And I know about annelid, based on an older version of valgrind, but the existance of this package does not really help).

Lklundin 23:13, 4 April 2007 (UTC)

On Portal:Free software, Valgrind is currently the featured article

(2006-12-28) Just to let you know. The purpose of selecting an article is both to point readers to the article and to highlight it to potential contributors. It will remain on the portal for a week or so. The previous selected article was GNU Radio. Gronky 16:21, 28 December 2006 (UTC)

The selected article has now moved on. The current selectee is Advanced Packaging Tool (apt-get). Gronky 15:06, 12 January 2007 (UTC)

NPOV improvement

The phrase an excellent reputation and is widely used uses valgrind.org as reference, which is hardly sufficient.

In spite of all its qualities, valgrind does not at all see a use as wide as for example gcc nor the LAMP components.

The praise has been moderated accordingly.

Secondly, the awards appear to be two Open Source Awards won not by valgrind, but by its original author for his work on valgrind. This distinction is now made.

Lastly, the important limitation that valgrind cannot detect even the most trivial errors in stack usage is mentioned. —The preceding unsigned comment was added by Lklundin (talk • contribs) 13:08, 5 April 2007 (UTC).

Limitations

The Limitations section doesn't mention any specific limitation. It gives a small example but doesn't explain why it can't detect the problem. Suggest that an explanation be included or the section removed. Eric.frederich 19:48, 6 June 2007 (UTC)

Actually, I just compiled that example code and ran it in valgrind and I did get an error about returning an uninitialized value. It is interesting to see that if I add the code ten[10] = 1; before the return there is no error and there should be. I guess what I'm trying to say is that it is a bad example because it contains an error. I'm going to add that piece of code I just mentioned to the example because then it is a piece of code that should be complained about but isn't.

—Preceding unsigned comment added by Eric.frederich (talk • contribs) 19:55, 6 June 2007 (UTC)

I am the author of section on the Limitations. Thanks for pointing out this problem. The original example of code contains two errors, namely an out-bounds-access and a return of an undefined value. On a 64-bit Athlon running Ubuntu 7.04 using the Ubuntu-supplied valgrind version valgrind-3.2.1-Debian, that piece of code causes no errors. But on a P4 running valgrind 3.2.3 under RH 9.0, one of the two errors is found, namely the one mentioned in the previous post.

The current example only has one bug (that demonstrates the lack of detection of an error in stack usage), thus the sentence above it no should not contain the plural in 'such as these'.

Valgrinds ability to detect both types of errors appears to depend on the actual array size and/or the platform. I think this additional problem is worth mentioning as well as the limitation regarding stack allocated memory. I have therefore modified the original example to one that still contains two errors which are not detected on the above two platforms. The surrounding text has been updated accordingly (with a caveat that some systems may detect the return of an undefined value). Lklundin 22:08, 6 June 2007 (UTC)

On second thought, I take the point made by Eric.frederich: the example should contain an error in the stack usage which causes no error report by valgrind.

Additionally, I introduced one extra variable to the example, in an attempt to better demonstrate the impact of such an undetected error. Lklundin 11:49, 7 June 2007 (UTC)

Thanks for updating it. I appreciate it. I've only been using valgrind for a couple of days now. It appears to work pretty well with dynamically allocated memory and not too well with declared arrays and the limitations section of this article seems to convey that message now and more importantly explains why (inability to detect errors in stack usage). Eric.frederich 17:42, 7 June 2007 (UTC)

There's a difference in C between static variables and plain old globals. The example code shows only a plain old global, but it's called 'Static'. I don't know what Valgrind's behavior is, but it's not clear from the article whether Valgrind has a limitation catching bounds errors on any global array, in which case the text referring to 'static arrays' should be changed, or if Valgrind has a limitation catching bounds errors on static arrays, in which case the C code needs the static qualifier before the "int Static[5];". I realize the same error was made in Valgrind's FAQ, but that doesn't make it right. Beyondo (talk) 12:50, 14 May 2008 (UTC)

History

There is none. When did valgrind first appear? When and how did it get developed? 128.187.80.2 —Preceding comment was added at 21:12, 3 November 2007 (UTC)

Done, per https://nnethercote.github.io/2022/07/27/twenty-years-of-valgrind.html

— FlashSheridan (talk) 21:38, 4 August 2023 (UTC)

And where are the reliable sources, at the moment all sources mentioned are the valgrind website. Arthur 22:12, 11 November 2007 (UTC)

that "Primary Sources are Evil" template

The documents being cited here - FAQ's, online documentation, etc - are secondary sources, as the primary source for Valgrind is in fact the source code itself. Unless someone can raise cogent issues about why the online doco for Valgrind is in some way inherently unreliable, can that nasty looking template be removed? mdf (talk) 22:18, 6 December 2007 (UTC)

The meaning of the template is that we need some non-self-published sources about valgrind. Until then the template is appropriate. As the templates says "This article or section needs sources or references that appear in reliable, third-party publications." WP:VER explains this in more detail. Arthurrh (talk) 23:21, 6 December 2007 (UTC)

Fine. However, the "self published sources" you are talking about are effectively user manuals. FAQ's. Documentation. They are, by this nature, inherently "reliable": why would the authors create inaccurate documentation? mdf (talk) 01:34, 7 December 2007 (UTC)

It's not that it's not reliable, it's that it's one-sided, as well as the issue of notability. Read the part I quoted from the policy, it says "reliable, third-party publications." The addition of such sources would improve this article. Surely someone can find some third-party source talking about valgrind, if not it has a notability problem. Arthurrh (talk) 01:36, 7 December 2007 (UTC)

Who is going to talk about Valgrind's behavior when Valgrind is describing itself? This is what user manuals are for, after all. mdf (talk) 01:44, 7 December 2007 (UTC)

Things like product reviews, case studies, etc. For example Microsoft Word#References. Arthurrh (talk) 01:46, 7 December 2007 (UTC)

I also checked into this WP:VER stuff, and found the section on "self published sources". Presently, it says that self-published stuff is acceptable in some cases "when produced by an established expert on the topic of the article whose work in the relevant field has previously been published by reliable third-party publications."

I'm going to go out on a limb here and simply assert that this is such a case, because Julian Seward -- multiple Open Source Award winner -- and his associates are, beyond any reasonable doubt, "established experts" not only on the subject of Valgrind itself, but also software analysis tools in general. The likelihood they are some fly-by-night group babbling into a blog, trying to bootstrap balderdash into the encyclopedia, is zero. (That is the group being targetted by WP:VER.)

With that in mind, as it currently sits, the article is just a run-down of the feature set, top-level implementation details, and so forth, and, as far as I have been able to tell, are all adequately sourced by direct reference to Valgrind's doco. I doubt a third-party source could add any more accuracy to the information.

However, that said, if there are other references to valgrind in the manner you suggest, reviews, commentary, and so forth, who am I to argue their admission? But that such things may not exist is probably a reflection of the fact that most users of this sort of thing are busy using the stuff. It certainly doesn't justify a template suggesting the entire article's credibility is suspect. mdf (talk) 02:19, 7 December 2007 (UTC)

And, in a related issue, in their FAQ, a limitation to their program, along with a working demonstration, is given. Being straight from the authors, this is effectively an adverse admission. This makes the argument about "competitors" you are making in your edit summary all the more difficult to follow. Are you reading the cited reference? mdf (talk) 01:44, 7 December 2007 (UTC)

Sorry, it was a naming confusion. There are many products called memcheck. Perhaps we need to adjust this paragraph to make it clear they're talking about their own memcheck. Arthurrh (talk) 01:46, 7 December 2007 (UTC)

Memcheck is a named feature of Valgrind, described in the preceeding paragraphs. It's difficult to imagine how a confusion can arise, but maybe that's just me. mdf (talk) 01:48, 7 December 2007 (UTC)

If you were familiar with one of the other memchecks, you might read it differently. At any rate, such ambiguity can easily be addressed. Arthurrh (talk) 01:56, 7 December 2007 (UTC)

I am familiar with at least one other tool by that name or similar. However, I suggest that context -- we are editing an article on 'valgrind', not 'memcheck' -- should be sufficient here. But, as I said, maybe I'm missing something. mdf (talk) 02:21, 7 December 2007 (UTC)

Looks like maybe we can pull some potential sources from here. Anyone have access to #18 for example? Arthurrh (talk) 02:04, 7 December 2007 (UTC)

Yes, self-published sources can be used. It doesn't mean that we shouldn't strive toward an improved article using third-party sources where available. I've added a couple, the link above lists more for someone who has time to chase down some of the refs. It's all about making the article better, not about attacking the subject of the article. Arthurrh (talk) 02:23, 7 December 2007 (UTC)

IBM Rational Purify

(This is in contrast to IBM Rational Purify, which can only detect "uninitialized memory copy", which is in itself a valid operation. For instance, the X Window System client libraries frequently copy partly uninitialized structures around, which trigger large numbers of spurious alerts with Purify, forcing programmers to turn off the warnings for uninitialized memory copying.)

I'm not entirely certain this appropriate. While the argument may be valid, it sounds like someone's being defensive/expressing frustration. I've reworded it, but I'm not very happy with my result.

Can anyone thing of a way to say this and still sound neutral, but not confuse the reader? --JamesBrownJr (talk) 16:06, 12 December 2007 (UTC)

Maybe it's more appropriate on the Purify page? Arthurrh (talk) 19:37, 12 December 2007 (UTC)

JIT vs binary translation vs binary recompilation

The first sentence in the Overview section confuses concepts. JIT is not binary translation, and besides, although Valgrind could do binary translation, it doesn't (see page 4 of Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation). Instead, it uses binary recompilation (explicitly mentioned in page 3 of said page). By the way, page 4 also mentions that Valgrind uses a JIT (just confirming the existing info). I'm changing the text accordingly.--Bauermann (talk) 13:10, 6 April 2009 (UTC)

Ptrcheck

The section 'Limitations of Memcheck' currently states that 'the Valgrind experimental tool Ptrcheck can detect errors like this as can many other static code analysis tools'. However I took the example source code, stuck it together with a 'return func();' in main() and ran 'valgrind --tool=exp-ptrcheck' on it (under Ubuntu Karmic). No errors were reported. Can others reproduce that? In that case the description of the Ptrcheck tool seems to be incorrect. Lklundin (talk) 15:37, 30 March 2010 (UTC)

I wanted to, but my installation doesn't have ptrcheck. However, I'm removing the phrase as can many other static code analysis tools since ptrcheck clearly is a dynamic tool, like the rest of valgrind. (And in case someone wants to gloat over the fact that valgrind cannot do all things that expensive static tools can, you'll have to formulate it differently.) JöG (talk) 20:31, 7 October 2010 (UTC)

Pronunciation

While the Valgrind FAQ does give the /ˈvælɡrɪnd/ pronunciation (as in "grinned") as the correct one, the /ˈvælɡraɪnd/ pronunciation (as in "grind") is also widely used. For instance, I just attended a presentation in which the speakers and attendees all used the latter pronunciation. Wondering whether the first sentence should be modified to indicate this. - AlanUS (talk) 17:12, 29 April 2014 (UTC)

supported languages

C and C++? Any other? PER9000 (talk) 16:43, 21 February 2017 (UTC)

Valgrind works on executable binaries and is not language-specific. LiberatorG (talk) 17:38, 21 February 2017 (UTC)

Correct. So if you run for example an interpreted program (e.g. perl) through valgrind, you will be analyzing the interpreter executable (e.g. /usr/bin/perl) with only the opportunity of getting a rather indirect if any information relevant to the interpreted program itself. In principle the article could try and explain that. Lklundin (talk) 18:23, 21 February 2017 (UTC)

In the case of interpreters, Valgrind will see which interrpreter need to run and then execute the binary of the interpreter in Valgrind. For binaries, any resonably standard ELF binary should work. Error information comes from DWARF debuginfo, so any language that uses it should get info about the source locations of variables. The last thing is name mangling. Valgrind imports its demangling code from libiberty. Not all languages are supported - C++, D and Rust should work. There's code for ADA amd Java there as well, but it's not active. Probably. 146.122.203.38 (talk) 15:46, 24 May 2024 (UTC)

References

" Even though it could use dynamic translation (that is, the host and target processors are from different architectures), it doesn't."

I've just removed this sentence. Perhaps it could become relevant if accompanied by further explanation (What would the benefits be? Does 'it could use' mean it'd be trivial to implement, or just theoretically possible at great difficulty?). As it stood, it seemed to add nothing to the article other than a definition of something Valgrind doesn't do. — Preceding unsigned comment added by 62.112.55.5 (talk) 11:49, 12 April 2017 (UTC)

I'd put this in the "great difficulty" category. It would require: coping with cross-platform ELF differences, translation of syscalls, ensuring that the intermediate representation codes are available for the target processor, no use of functions wrapping target processor instructions and probably quite a lot more. 146.122.203.38 (talk) 15:35, 24 May 2024 (UTC)