Valgrind 1.0.0 Released

Anonymous Lazy Boy writes "Yesterday saw the official release of Valgrind 1.0.0. Valgrind is a C/C++ programmer's dream come true: effortless memory allocation checking, uninitialized memory access, leaks etc. Purify for Linux has arrived, only better: contrary to its commercial (non-Linux) sibling, checking is performed directly on the executable, no re-linking necessary. The technology behind Valgrind is highly fascinating and explained down to the very gory details in the documentation."

Comments

wow, top ten

[snitman]

sorry, that was off topic, but this C++ this is happy news for me

Any reviews?

[ergo98]

One thing I've found with automated QA products is that usually they have critical faults that prevent them from being realistically useful (for instance many of them grind to a halt or give false positives in multithreaded apps). How's this product for real world use? (And no this isn't a "Read the Article!" question...the article is like a press release and hence doesn't answer my question).

Re:Any reviews?

[Charles Kerr]

I've been using Valgrind on Pan, which is multithreaded, and it works fine. Maybe given more time I'll find features that I miss from Purify, but for now I'm very happy.

Things I like better in Valgrind:

• Valgrind works on Linux.
• Valgrind doesn't require instrumenting each object file and library at build time. (This is a biggie)
• Valgrind's run-time options are more flexible.
• Valgrind works with both gcc 2 and 3.
• Valgrind seems to run faster than Purify. (Different hardware and OSes, so this is a guess.)
• Valgrind doesn't have a Motif GUI. ;)
• Valgrind doesn't have an insane, broken license manager.
• Valgrind's technical support is better. (Yes, I've dealt with both.)
• Valgrind doesn't cost $2,364 per seat.

Things I like better in Purify:

• Purify can handle static libraries.
• Purify makes it easier to disable errors/warnings from libraries out of your scope.
• Valgrind doesn't work on Solaris, so I'm stuck with Purify for my day job. :)

Re:Any reviews?

[cant_get_a_good_nick]

Valgrind doesn't work on Solaris, so I'm stuck with Purify for my day job.

Is it possible to have your code portable to both OSes so you can run the tool, or will the higher ups feel this isn't a workable solution. I obviously have no idea of what you're doing, nor the effort of porting, just an idea to throw out. You might be able to say that you save debug time, and get a Linux version of their software in the process.

Re:Any reviews?

[Anonymous Coward]

valgrind seems faster? bullshit! It's implemented as an x86 emulator (*cough* bochs *cough*). It slows down code by 20-50x.

Re:Any reviews?

[Kiwi]

We've been using Valgrind to find memory leaks in my open source project; it caught a few subtle memory leaks which we didn't catch in our six months of testing by hand.

I've been very pleased with it.

I can not comment on how easy it is to use because other developers on the team have been using it instead of myself.

- Sam

Re:Any reviews?

[Green Light]

Perhaps he does not even have a Linux box at work?

Re:Any reviews?

[Charles Kerr]

On a Pentium 450 running Limbo, I can start up Pan 0.12.91 with valgrind --num-callers=16 --leak-check=yes --leak-resolution=med in one minute, nine seconds. On an otherwise-idle Sparc Ultra 10 running Solaris 7, it takes Pan built with "purify -chain-length=7 -cache-dir=/tmp -always-use-cache-dir=yes" more than 15 minutes to start up, with the CPU pegged at 100% the entire time.

If there's a secret "Don't Run Slow" switch to Purify, let me know what it is.

Re:Any reviews?

[Citizen of Earth]

Things I like better in Valgrind... Things I like better in Purify

I've used Valgrind and Purify before and I find Valgrind much more useful. The big thing for me is that it runs on Linux, which is what I use for development at the office. This is the death of Purify for me, because I can get much higher performance Linux boxes than Solaris boxes for a reasonable price. The additional price of Purify to me is just adding insult to injury.

I'm not sure what you by "Purify can handle static libraries" because I use static libraries with Valgrind all the time.

The only thing that concerns me about Valgrind is the strange way that it tracks uninitialized varliable references: it only checks values when they are used for an index or a branch (the last time I read the documentation). Apparently it restricts to this case because people may copy around values or arrays that are uninitialized. I certainly don't do this. And I do really want to know when an uninitialized variable is first read.

Re:Any reviews?

[Mark J Tilford]

According to the article, compilers will pad out the size of structs to be a multiple of the word size. When that's done, copying one padded struct to another will cause the compiler to put in code for uninitialized reads into the end product.

Re:Any reviews?

[Sanga]

# Purify makes it easier to disable errors/warnings from libraries out of your scope.

Details about Valgrind suppressions at:
http://developer.kde.org/~sewardj/docs/manual .html #suppfiles

sweet, better debuggers == better code

[laymil]

the better the debugger, the more errors its gonna catch. hopefully it'll be easier for people to catch and fix memory leaks now.

sigh...the only thing is...i wish it were for windows...thats where i have problems with people writing programs with memory leaks (at least moreso than on my linux boxes)

Re:sweet, better debuggers == better code

[Ataru]

Well, I have a clue, and I almost never have memory leaks. Some of my colleagues are not so fortunate. I'm a bit of a fan of garbage collection because it removes the problem (almost() completely. But will that make them better programmers? Probably not. Will it matter? Well, they will have no memory leaks I don't know. Discuss?

Re:Valgrid is not as complete as Purify

[MisterBlister]

Agreed. I use Purify constantly for my day job. I took a look at this hoping to find something nearly as good as Purify (since they advertise it as being BETTER!) and free, but there's a long long list of ways in which it is vastly inferior to Purify right now.

Beware of gratiutious hype.

And, btw, Purify (never used it under Linux so maybe it is different there) can also work on executables (and DLLs/SOs, etc) without a relinking. When's the last time the person who posted used Purify? 1996?

Re:What's the fun in that?

[MisterBlister]

This may be a practical tool in some respects, but I would not have so much respect for someone who depended on that to have any working code. As the old saying goes, "real programmers read core dumps."

Are you trolling? Or stupid? Or have you never used Purify? I've yet to meet a developer who used Purify (or in some cases BoundsChecker or similar tools, though IMO Purify is hands down the best if you can afford it) that decided it wasn't really helpful and then stopped using it.

These tools give you SO MUCH more than just simple stack tracing after a crash. Foolish is the developer who ignores their benefits.

If you're worried about threading/memory bugs

[adam_megacz]

You could write your code in Java (shuder!), and then use the Java frontend to GCC to compile it down to a blazingly fast 100% native-code binary. And you can do it all without ever using non-free software (unlike Sun's compilers/JVMs).

Re:If you're worried about threading/memory bugs

[balthan]

If you were going to do something like that, wouldn't it be easier to use Eiffel.

Re:If you're worried about threading/memory bugs

[adam_megacz]

you obviously have no idea what you're talking about

$ grep Megacz /usr/src/gcc-3.1/MAINTAINERS

Adam Megacz adam@xwt.org

Yeah, I probably know absolutely nothing about gcj...

Re:If you're worried about threading/memory bugs

[10Ghz]

0wn3d!

Re:If you're worried about threading/memory bugs

[affenmann]

If you're worried about threading/memory bugs, you rather want to compile ML or HASKELL to a blazingly fast 100% native-code binary, without ever using non-free software.

Java's type system still allows wrong type casts, which can only be checked at runtime, and this gives essentially memory bugs. I wish Java had a better type system with proper polymorphism (like Generic Java) instead of these ugly casts to Object and back...

Re:Valgrid is not as complete as Purify

[mce]

The bad thing about Purify is that there ain't no Linux version.

I have used Purify ever since it was first put onto the market by Pure Software about a decade ago. But nowadays, Linux is becoming our real development platform, so if Rational ain't careful: exit Purify. Yes, it's sad, but I've told them often enough that Linux support is what they should bring me, not yet another rewrite of their licensing scheme.

An excellent tool

[alriddoch]

Valgrind really is an amazing bit of software. Working on large application which use many different libraries it becomes harder and harder to work out where those bugs are, and all the free tools I have tried so far have done a very poor job of finding them. I have now been using valgrind for several months, and got 1.0 straight from the author by mail having reported a few bugs in earlier versions. It speeds up finding those hard to reproduce bugs, and often shows up memory errors which you didn't even know were there. It is also excellent for detecting memory leaks as it knows the difference between memory that has been genuinly leaked, and memory which is not freed, but still has a reference to it stored when the program exits. All the software I work on is now much more robust than it was a few months ago, and much of this I can put down to valgrind being available. This is the only free tool that comes close to the commercial tools like Purify, and in many ways it is superior to some of the expensive high end tools. The author is extremely responsive and helpful, and has been developing valgrind full time self funded.

Re:An excellent tool

[soulcuttr]

I'm not sure why, but I find it amusing to picture the author trying to find bugs in Valgrind, actually using Valgrind.

Perhaps it shouldn't seem as funny to me in days when Subversion is self-hosting, and GCC compiles itself.

-Sou|cuttr

Re:An excellent tool

[sir99]

Valgrind doesn't require you to recompile/relink your code. Also, Valgrind allows you to do extra runtime checking on specified areas of memory, which I don't think checkergcc provides.

Re:Title confusion

[Soul-Burn666]

Nope, sorry!

But I guess that's what happens when you only develop software and not see girls...

Valgrind

[jj666]

I bet you can't say that backwards ;o)

Re:Valgrind

[Nighttime]

What's so funny about dnirglaV?

Wow!

[jelle]

I've been waiting for this. I've seen the malloc debuggers and the like (electric-fence, gccchecker, etc), but they're all incomplete, have problems with C++ code, or are just for allocated memory ('new'-ed objects, malloc()-ed data, etc), not for regular vairables: statics, local variables, etc.

But valgrind seems to be just right I gave it a quick tryout and it is looking good!

Wow.

apt-get install valgrind.

And all we need now is a gvalgrind, and/or a kvalgrind gui interface just like purify has and I'm all happy.

Re:this rocks run your desktop apps

[jelle]

"companys should employ this man"

I know my company will be employing this on every project I work on ;-))

Re:Valgrid is not as complete as Purify

[jelle]

"but there's a long long list of ways in which it is vastly inferior to Purify right now"

How about showing us that list?

Re:What's the fun in that?

[superpeach]

Good programmers will not depend on something like this to get their code working, but it will still be a great tool for them to make sure they didnt mess up somewhere in the last 9hours of solid coding. Its probably kind of like wearing seatbelts, you dont need them to be able to drive but if something goes wrong they come in quite handy.

Too slow to always enable

[GGardner]

One of the many great things about purify is that (IME) it only slows down your code by 10-20%, which is small enough that you can always leave it in your code. Leaving it in for unit testing, integration testing, system testing, beta testing, etc., can make your life much easier.

Valgrind, however, runs your code 20-50 times slower, which means you can't have it on all the time. This is unfortunately, for it looks like a great tool, otherwise.

Re:Too slow to always enable

[cant_get_a_good_nick]

I think this is a bit misleading, it's actually a Linux/x86 virtual machine. valgrind is an environment, not just a library you link to. You don't "enable" it on your binary, you need to specifically run something under this VM. It's more akin to running something through the debugger "hey, lets do our daily/weekly valgrind run" than something you could run all the time. Or maybe do it when you have specific errors and wnat to smoke them out. It's a totally different type of tool.

I think the VM concept is quite clever. It would be interesting to see debates about it. On the good side, it cheks EVERYTHING, not just stuff you turned the switch on for. Even bad system libraries (it has switches to turn these off so you don't get deluged by them). On the bad side, it's obviously Linux/x86 only. I guess it pays to keep your code portable. I'm in a SPARC/Solaris only shop, but I could see myself keeping things portable to linux enough to run this, say once a week to ferret out bugs.

Re:Too slow to always enable

[mce]

While I agree with the unlerlaying message of your post, it must also be pointed out that the slowdown that Purify causes depends a lot on the nature of the code at hand. If the program does nothing but address memory, it will be large (especially if it uses pointers all the time). If the program spends its time performing arithmetic on registers or waiting for disk I/O to finish, it won't be.

From what I read about how Valgrind works, it will also slow down non-memory instructions.

Re:Too slow to always enable

[GGardner]

For my real code, big applications only slow down 10-20%. I've measured it. Now, this is on Solaris/SPARC, which I suspect is a much more efficient platform than x86. How much slowdown do others see?

Re:Too slow to always enable

[mce]

For my current project (a source code transformation system operating on C code), it depends on the input that I feed the program.

Typical Purify slowdowns are in the 25% range (e.g. when we're processing the MPEG-4 VM).

But I have one pathological test case that reached over 50% before I rewrote part of the code. This test case was quite interesting, actually: in causing such a big slowdown, Purify in fact pointed out a performance bottleneck (albeit a somewhat "irrelevant" one that I only fixed once I had to fix a real bug in the same file anyway).

recursivity

[alvi]

Hum,

[chicken]~> vagrind valgrind

seems to work ok. But valgrinding a valgrinded valgrind causes some ugly errors and asks for a bug report. Well, I know this isn't fair. :)

Anyways, this looks like a really sweet tool.

x86 VM

[Mike McTernan]

They've made a virtual machine that copies x86 architecture - all the benefits of Java debugging bought to C/C++. Nice.

Re:x86 VM

[j3110]

Except that for Java it doesn't need to be debugged, the JRE does all the memory allocation and deallocation for you. If C/C++ is to last into the future, it really is going to have to handle the memory allocation fiasco at run-time. While OSS has the advantage of infinite codeing time, in the real world, coders have a salary. It takes time to debug memory leaks. I don't think that there are many developers out there that can program good enough to make up the cost in added hardware it would take to run Java at the same speed. Even if they could, their talants would be much better spent adding new features to compete than slaving over a memory leak. Before I write code, I ask myself if 20% faster code is justification for all the work of porting my app to other hardware, hours (if not days) debugging memory leaks, and hours of recoding the functionality of the java class library that I need. Tools like this and LGPL'd libraries adjust the equation, but they won't tip it until I can depend on ANSI C/C++ compiling my code on virtually every platform (including the GUI) and there is a garbage collection system set up for C++ that doesn't cut performance by more than that same 20%.

Languages shouldn't be free as in beer. There needs to be one standard in Java, and SUN provides just that. Just like Larry Wall controls Perl and guides it into the 21st Century, there has to be some organization to do the same for C/C++ or it will surely grow old and die. C was a good language for it's time, but if it is as rigid as assembler, it will suffer the same fate. Ask yourself how difficult it is to write a GUI in C/C++ that will work on more than one platform. GUI's are as standard as iostreams now, yet there is no standard for programming GUI's.

This is just a bandaid over a severed limb, and there are several more limbs that aren't looking to good either.

Re:x86 VM

[XO]

You say:

It takes time to debug memory leaks.

I wonder: Is there really any commercial, say Windows based, software developer that gives one rat's ass about memory leaks? Just throw more memory at the problem. When I'm in Windows, this is what I run, continuously:

ICQ, Yahoo, MSN Messenger, Mozilla, Outbreak Express.

The only other program i occasionally use is telnet.

I would expect ANY system could handle this for days, weeks, even MONTHS .. after 2-3 days in windows, suddenly all my icons and controls and gagets disappear, the screen won't re-draw anymore, and if i try to open anything, I get "There are not enough resources to run this program." (then closing programs tends to crash the OS)

It'd sure be nice if more developers DID care about memory issues. I don't think that's nearly as much of a problem on Unix based systems, because the developers care more about their code.

Re:x86 VM

[macrom]

there has to be some organization to do the same for C/C++ or it will surely grow old and die

It's called the ISO C++ Standard Committee. The members meet regularly and are comprised of the world's C++ experts.

GUI's are as standard as iostreams now, yet there is no standard for programming GUI's

If you are looking for a C++ standard in GUIs, then you will most likely go to the grave with that wish. C++ (like it's older sibling, C) is not designed as a language to handle these platform-specific functions. Many people (yourself seemingly included) seem to think that this means C++ is somehow defunt, archaic, useless, etc. The fact is that the language is actually designed to decouple itself from such functionality, leaving the major platfom-specifics up to the implementer of the compiler/environment. I like it this way, many C++ developers the world over like it this way, and I think we all would be upset if it changed.

Read The Design and Evolution of C++ sometime. It will open your eyes to the realization that C++ is not an environment like Java, but just a basic language to assist you in creating your environment.

Re:x86 VM

[XO]

That is EXACTLY what I am saying. Now, 1MB per MINUTE is -nuts-, but my primary machine has 512MB and I realise that '98 still has other issues besides just "total free ram" that affect "Total System Resources", but having to reboot every 2-3 days just because the programs that are running suck everything down in that time. and all i basically use is messengers!

GDB is BIG and old valgrind help's

[johnjones]

I Had to debug GDB and Valgrind helped me find memory leaks in this and gdbTK

GDB is pretty icky so thats a ugly program for you it also managed to debug my ARM/MIPS sim which is small

overall I give it 5 stars

regards

john jones

Re:Valgrid is not as complete as Purify

[Polo]

Especially since purify doesn't run on linux...

Re:What's the fun in that?

[mce]

Not only that. There aren't enough good programers to go around (I'll admit that my criteria for this label are extremely stringent, but still). So we need the average ones. And those need a lot of support.

Besides, I've seen Purify detect errors in code written by the best programer I've ever met. This guy is way beyond what most fellow programers can imagine both in terms of architecture/design and in terms of attention do detail in implementation. But just like the rest of us he's not infallible.

Re:BACKDOOR in Valgrind - Please Read

[michael]

Please don't feed the trolls. All the posts claiming a backdoor in Valgrind and supposedly responding to each other ("Hey, I found it too!" "Me too!" "Here's what I got!") were all posted by the same person.

Re:Strangeness

[mrm677]

I do hope that the moderator whom is labeling these posts as "trolls" has done his/her homework regarding the accuracy of this and following posts...

What the...

[handsomepete]

I was just reading this thread and everything was +2/+3 informative. Suddenly everything has been knocked to 0/-1. Did we discover some relevant piece of information about the posting ACs that made that a wise decision? This sounds like it's at least kind of important. What's going on?

Re:What the...

[dvdeug]

Did we discover some relevant piece of information about the posting ACs that made that a wise decision

You mean besides the fact that everyone reporting a problem is Anonymous Coward, except for Theo deRaadt (hint: look at the OpenBSD webpages - it's Theo de Raadt.) Considering a #5000 level user says there's no problem; well, I know who I believe.

Use garbage collection

[WanderingGhost]

If you're woried about memory allocation, use garbage collection:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_so urce

And contrary to what you may think, it's qiute easy to use:

variable = new (GC) my_class;

Or even easier: make your classes derived from gc.

In C, you just replace malloc.

And I have found that there is no slowdown wen using a garbage collector. It's nice, and keeps the code clean. Try it someday.

Re:Use garbage collection

[HuguesT]

There may be no slowdown for you but that may not be true in all cases.

Moreover using GC does not protect you from off-by-one addressing type of error, which Valgrind is designed to help you with.

Re:Use garbage collection

[WanderingGhost]

There may be no slowdown for you but that may not be true in all cases.

Yes, I think using garbage collection for most parts of your program, and then just controlling it by hand in performance-critical places is a nice hing. That's why I don't like Java (Java doesn't let you choose).

Moreover using GC does not protect you from off-by-one addressing type of error, which Valgrind is designed to help you with.

Sure, agreed. But GC still makes your program more readable and easier to debug... :-)

Re:Use garbage collection

[jreiser]

When pointers are not opaque and/or not traceable except by knowing the additional structure of the allocator (in contrast to the simplicity of malloc/free), then GC presents practical problems.

Re:Use garbage collection

[ceswiedler]

There are two camps when it comes to this sort of thing. One says that developer time is more important than processor time (you seem to fall into this one) and therefore GC is a great thing. I would say that 80% of development projects fall into this category.

But in the other 20%, performance is more important than development time, and for these projects, GC is clearly a bad idea. In some situations even C++ is a bad idea. You really really wouldn't want to write an operating system with C++, much less with GC. There are times when developers need complete control, and high-level languages and features like GC take that away.

Re:Use garbage collection

[p3d0]

You really really wouldn't want to write an operating system with C++, much less with GC.

Bull.

Be was written in C++, and so is K42, IBM's next big massively scalable Linux-compatible kernel. Some of the smartest people I have ever met work on K42, and these guys know C++.

Also, GC doesn't necessarily add any overhead to programs: it depends on memory usage patterns, but clearly, being forced to free everything chunk-by-chunk as it's no longer needed can't always be the most efficient policy. (Otherwise, why do program call stacks use special-purpose storage management instead of the heap?)

Having said that, it is true that a conservative collector is not suitable for all memory allocation needs.

Re:Use garbage collection

[cpeterso]

The Be kernel was written in C, not C++. Be's user libraries were written in C++.

Interestingly though, Apple does use (a simplified subset of) C++ for Mac OS X device drivers. See the Apple IOKits.

Re:Use garbage collection

[abdulla]

I actually use the Hans Boehm garbage collector as a leak detector, but Valgrind goes way beyond what garbage collectors offer, it tells you errors in your coding that would be _very_ hard to spot otherwise, this is my experience at any rate.

Re:Use garbage collection

[Lothar]

I thought Apple preferred ObjectC? I mean thats their language of choice it seems.

Re:Use garbage collection

[sethg]

Some folks on the lightweight-languages list have pointed out that malloc/free are not instantaneous, either, so if a program needs to allocate and deallocate lots of memory, using a GC can be more efficient than using malloc/free -- it all depends on the subtleties of the algorithm you use and the way your GC or malloc library is tuned.

In any case, a GC doesn't always save you from memory leaks. Contemplate the difference between live and reachable objects. A live object is one that the program will actually use at some point in the future. A reachable object is one that the program could use. GCs reclaim un-reachable objects, not un-live ones.

Re:Use garbage collection

[Christov]

It's called Objective-C and sometimes ObjC.

Yes, NeXT/Apple prefers ObjC for the Cocoa userland libraries. Embedded C++ is used in the IOKit layer of the kernel because it was hoped that it would fix some shortcomings of the Objective C based DriverKit. IOKit is really quite nice once you get your mind wrapped around it, but the advantages of Embedded C++ haven't really shown up.

They had to disable templates, exceptions, and some other advanced features to embed a stable runtime in the kernel. Then Apple had to re-invent a lot of the dynamic dispatch stuff that ObjC uses. Drivers have been quite sensitive to changes in the IOKit base classes (fragile base class syndrome) that ObjC is mostly immune to.

It's hard to tell which is really better, because Apple has a lot more resources dedicated to kernel and driver programming than NeXT ever did.

Re:Use garbage collection

[ceswiedler]

Just because it's been done doesn't make it a good idea. You obviously know something about OS programming (though someone corrected you about the Be kernel). But you can't deny that the majority of modern operating systems are written in C, and not C++.

My point is that there is no GC algorithm which you can write (ahead of time) for a given application that is better than the GC implementation I can custom-write for my application. I can analyze my code and decide for myself when memory should be freed. It's the same thing with compilers; compiler-generated code is never going to be better than the hand-written code of a good programmer.

Now, everything is a tradeoff, and I'm all for compilers and GC when appropriate. But another thing I've noticed is that programmers get dependent on GC. More than that, a program written for GC (i.e., without any free() or delete calls) cannot be ported to a system which doesn't support GC.

Re:Use garbage collection

[p3d0]

My point is that there is no GC algorithm which you can write (ahead of time) for a given application that is better than the GC implementation I can custom-write for my application.

Agreed. My point is that malloc+free is rarely the ideal answer. In fact, I'd be willing to wager that most applications don't get any performance benefit from malloc+free versus a well-tuned conservative GC.

More than that, a program written for GC (i.e., without any free() or delete calls) cannot be ported to a system which doesn't support GC.

Amen. I just spent several months trying to do just that.

Re:Strangeness

[Rob Kaper]

Hi. KDE developer here. We've checked developer.kde.org (the machine hosting Valgrind) and the md5sums. So far this looks like a hoax, so please move on. We will stay on the alert and continue investigating, but to quote one of my favourite authors: don't panic.

Re:Strangeness

[HalcyonBlue]

I'm on a bellsouth adsl connection

halcyon:~$ md5sum valgrind-1.0.0.tar.bz2
76c59f7f9c57ca78d733bd956b4d94ae valgrind-1.0.0.tar.bz2
halcyon:~$

Re:Strangeness

[Charles Kerr]

I know I shouldn't feed the trolls, but just for fun:

(18:14:38)(~/src/valgrind-1.0.0): grep open vg_scheduler.c
(18:14:45)(~/src/valgrind-1.0.0): grep 11 vg_scheduler.c
02111-1307, USA.
(18:14:52)(~/src/valgrind-1.0.0):

Re:What's the fun in that?

[Greg Lindahl]

I am neither trolling nor stupid, and I don't find Purify that useful. I am also not as insulting to people who don't agree with me.

In the 60's, we programmed in Fortran, and debugged with PRINT statements.

In the 70's, we programmed in Pascal, and debugged with WRITE statements.

In the 80's, we programmed in C, and debugged with printf statements.

In the 90's, we programmed in C++, and debugged with >>.

hooray!

[j1mmy]

i've been using valgrind for a couple months now. it's great!

Why your post is a troll

[Vicegrip]

valgrind is freely downloadable *with* the source. Here we have someone that has put toghether a very impressive tool which, you admit yourself, does things that require 3rd party tools to do on Windows, and all you find to say "I don't care because stuff on Windows sorta maybe does it anyways".

Instead of commending somebody on their very talented effort and for making it all Free, all you do is make loud claims that memory management isn't the way of the future for "us l33t modern day programmers"-- followed by the amazing claim that C memory allocation is somehow sub-optimal.

The fact is that for all that vaunted "10 years" advance you claim the Microsoft C runtime has, memory management has been the bane of every product Microsoft ever produced.... I still get company wide emails twice/thrice weekly of this or that exchange server needing to be rebooted again.

If I had mod points, I most certainly would have modded you a troll.

Re:Strangeness

[Old Wolf]

Even open source developers get mod points sometimes...

Re:Valgrid is not as complete as Purify

[XaXXon]

And, btw, Purify (never used it under Linux so maybe it is different there) can also work on executables (and DLLs/SOs, etc) without a relinking.

You wanna know why you've never used Purify under Linux? Cuz it's not available. AFAIK, no Rational tools are available for Linux. When I was looking for Linux tools at my previous job, the only memory checker available for Linux was insure++. I also found that there were no commercial profilers available for Linux. gprof just doesn't cut the mustard, especially in multithreaded apps, and Rational's Quantify wasn't available for Linux. When I called Rational to ask if they planned on supporting Linux, they said "Maybe sometime in the future", but when I continued questioning them, they said they had no immediate plans to start working on Linux versions of any of their software.

So, while Valgrind may not be as complete as Purify (I don't know if it is or not), it's a helluva lot cheaper than insure++ (~$4K license -- well worth it if it's not your money), and better than any other Free software I've seen.

Correct md5sum

[Anonymous Coward]

Hi,

I have just verified that we have no evidence of
a backdoor in valgrind.
This is the correct md5sum
76c59f7f9c57ca78d733bd956b4d94ae valgrind-1.0.0.tar.bz2

I will put this information also online on
http://www.kde.org/md5sums/valgrind-1.0.0.tar. bz2. md5sum

So you can check this information via a second channel.

Yours,
-- martin
P.S.: The AC claims incorrectly that exact the above md5sum indicates a compromised archive which is plain wrong!

Re:PurifyPlus+MSDEV.EXE+icl.exe has yet to be beat

[joss]

oh please... SGI had fix and continue plus debuggers way better than VS7 8 years ago. Proper interactive debugging (type call blabla::XX(5,8) to step into member function etc and purify hasn't improved since rational bought it.

I think you're confused

[adam_megacz]

There is no "GNU version of Java".

GCJ supports everything in Java 1.2 except for AWT (most people aren't using Java for GUIs anyways), almost all of the 1.3 stuff, and a large portion of the 1.4 stuff.

Most Java software out there today (Tomcat, etc) is designed for Java 1.2. Not much changed in 1.3/1.4.

In a pinch, you can actually take the .jar's from Sun's Java distro, run them through GCJ, and get native code binaries. You can't redistribute these, but it's handy if you're writing server code rather than shrinkwrapped software.

Could Valgrind be an alternative to Bochs?

[splorf]

It looks like it has its own instruction level simulator that does binary translation and runs a lot faster than Bochs. It may not try to simulate privileged instructions, but maybe that could be added, so you could run operating systems under Valgrind.

Could some kind of merge be possible, adapting Bochs to use Valgrind's simulator without the malloc-checking stuff? Also, I wonder if Valgrind could be adapted to simulate other CPU's besides the x86.

Re:Could Valgrind be an alternative to Bochs?

[JFMulder]

Nah, I don't think so. I've read a bit about Valgrind and I'd be surprised if it emulated all the PC hardware like Bochs does. Bochs is interresting because it emulates an entire PC, so it's ideal for OS development.

Re:Strangeness

[Old Wolf]

The source I downloaded (http://developer.kde.org/~sewardj/valgrind-1.0.0. tar.bz2) didn't have a 'vg_schedular.c' ; and the closest-looking filename ('vg_scheduler.c') did not contain any calls to socket or bind, or the strings 11, 0B or 0xB. Of course this is not to say that the file does not do this, because any backdoor-writer worth his salt would obfuscate it under lots of #defines and such. I would like to see the original poster (or anyone else with the same compiler) paste the compiler output, including the line numbers involved, and also say where he got the source from.

Re:Strangeness

[idealego]

Trolls are busy at work today I see.

I actually wasted about 15 minutes looking into this.

Re:Call me ignorant if you like...

[Alan Cox]

They only apply to USSA citizens and other backward nations. I would not be suprised if Valgrind had US patent issues, but then so does just about anything but breathing

Re:Strangeness

[rjh]

I've just grepped through vg_scheduler.c looking for `bind', `sock', `11', `RAW', `raw', and several others. I've come up with absolutely nothing. Admittedly, I haven't checked out the entire source--at 3500 lines, it'd take me several days to do a proper audit--but so far I haven't found any references to socket calls anywhere.

Still, I would appreciate it if the maintainer could check out vg_scheduler.c and see if there's something amiss there. Thanks. :)

Garbage collection vs direct allocation/release

[Anonymous Brave Guy]

In our world, we are moving towards garbage collection. It rocks. The simple truth is that C-style memory allocation is well understood, sub-optimal, and obsolete.

C-style memory allocation is the basis for any garbage collection system. It may not be the right tool for every job -- certainly it is smart to build a more powerful system atop it -- but it is not obsolete, and never will be as long as programming remains in an environment similar to what we have today. And it is optimal for what it does. That's why you build a GC on top of it, and not the other way around.

And of course, you have to be careful with claims that garbage collection is some sort of panacea. I almost never use new and delete in C++, for example, because I have automatic local variables, implicit temporaries, and deterministic destruction at the point where either go out of scope. People somehow think that it's clever that you can write

Blah x = new Blah(10);

in Java, and that if you write

Blah *x = new Blah(10);

in C++ it's inferior because you have to delete it afterwards. They ignore the fact that the vasty majority of the time, you're actually going to write simply

Blah x(10);

instead, and have no worries about releasing memory, or failing that, you're going to use a suitable smart pointer class and similarly have no worries. And in languages with "low level" allocation like C++, you get deterministic destruction in the picture as well, which is a massive advantage over the GC approach as evidenced in languages such as Java (and many others, too).

Re:Garbage collection vs direct allocation/release

[mce]

In fairness, if the language protects them from their own incompetence, it can rightfully be said to be superior in some sense. :-)

Ideally there would be no incompetent programmers, but ideally there wouldn't be any bugs either.

Re:Garbage collection vs direct allocation/release

[Anonymous Brave Guy]

In fairness, if the language protects them from their own incompetence, it can rightfully be said to be superior in some sense. :-)

That is certainly true. OTOH, if using a feature restricts what you can do (e.g., using a GC typically prevents deterministic destruction) then it is not necessarily superior overall.

Re:Garbage collection vs direct allocation/release

[mce]

Oh, I absolutely agree with that. I use GC in a C++ context, but definitely not exclusively. Sometimes you need to have more control than precooked GC schemes will give you.

As a side note, I wrote my own malloc/free replacement library with some custom extensions to provide better allocation control ande debugging. Just for the fun of it. For our purposes it beats the pants of the versions that come with HP-UX, Solaris, and Linux in terms of speed as well as memory usage. Later on a a collegue built the GC framework that I'm using on top of my custom malloc in such a way that it coexists very nicely with it. This gives the developers the best of both worlds.

Re:PurifyPlus+MSDEV.EXE+icl.exe has yet to be beat

[Anonymous Coward]

Fix and continue is a bit of a joke. I'd like to think that I don't write software so poor that it actually saves time to be able to fix a bug and move immediately onto the next one without stopping, thinking, and rebuilding. ;)

At any rate, I've yet to see an IRIX debugger 'way better than VS7'. How is it way better?

Speedshop sucks ass compared to a Quantify/VTune combo.

SGI don't have a compiler even close to the Intel compiler (I'm talking C++ compliance, here.), despite the fact that they both use the EDG front end.

As for purify... how would you improve it? It's one of the few pieces of software around that is just.. done? It's complete. I use it, and I've never thought 'argh, I wish it could do..' Seriously, what is purify lacking?

P.S. the dev team (who I email from time to time) have stayed completely intact (save for the odd "background" coming and going)) from the time they were Pure, through Pure/Atria, and now Rational. Purify is the result of corporate takeover done right. ;)

Can you imagine what would've happened if MS bought purify? ;)

Re:Valgrid is not as complete as Purify

[Pauly]

Especially since purify doesn't run on linux...

Excellent point. It's also another reason why I've found Parasoft's Insure++ to be superior to Purify.

I'm sincerely looking forward to checking out Valgrind. Can someone post a feature comparison of these three?

Re:BACKDOOR in Valgrind - Please Read

[michael]

True. I suppose my comment should be something along the lines of, "Please don't use your user accounts to raise the awareness of something posted anonymously unless you, personally, have verified it and vouch for it."

Wow, Debian version already updated

[Anonymous Coward]

1.0 is available in unstable.

Cool.

Re:What's the fun in that?

[MisterBlister]

In the 80's, we programmed in C, and debugged with printf statements. In the 90's, we programmed in C++, and debugged with >>.

So you *are* stupid after all!

Buy a faster computer?

[Ramses0]

Seriously... This is about the only *useful* thing that I can see using processor power for. I'd much rather make a weekly run-through with this type of software rather than having transparent menus or chirpy paperclips saying "you might have leaked memory, would you like to learn how to write a memo?"

Developers workstations are *supposed* to be bigger better faster more than those of the plebes, and don't you forget it! :^)

--Robert

Re:Buy a faster computer?

[mcfiddish]

Developers workstations are *supposed* to be bigger better faster more than those of the plebes, and don't you forget it! :^)

Don't laugh, but I think the opposite is true. I do all of my development on a 600Mhz Pentium II, because if I can get my code to perform well on that box, it'll be that much faster on most machines in the "real world".

Re:Buy a faster computer?

[WNight]

I agree. Perhaps let developers perform compiles on a very fast remote box, but make them use and test the system on a computer that is the "minimum recommended". If they can't do it, the stated minimums are wrong.

Re:Valgrid is not as complete as Purify

[mce]

When I called Rational to ask if they planned on supporting Linux, they said "Maybe sometime in the future", but when I continued questioning them, they said they had no immediate plans to start working on Linux versions of any of their software.

Franckly, I have the impression that Rational regard Purify and Quantify as cash cows that should not be touched unless absolutely required. All they ever did since they bought them was:

• implement a Windows version (there's more cash at hand in that world);
• change the licensing scheme to be ever more annoying;
• fix minor annoyances after HP or Sun released new compiler versions;
• finally add gcc support for version 2.95 when 3.0 had already been released for some time.

Other than the gcc 2.95 thing, I have seen no real improvements in years (I don't use Windows). Over the years, we forked over a lot of money for "support", though.

It's a great tool, but I'm not impressed with the company behind it.

Market for commercial programming tools for Linux

[jreiser]

I developed a product for Linux/x86 with functionality similar to Purify and valgrind, and offered it for sale three years ago (June 1999) at $99 per user. Market response was underwhelming: in eleven weeks only seven licenses were purchased, and three of those were by competitors or academics who ran the tool only to find out how it worked, and never used it beyond that.

Today BitWagon offers a profiling product tsprof which requires no recompile and no relink, and handles main programs, shared libraries, dynamic modules, pthreads, and SMP; does direct time and event measurement based on hardware counters (no sampling) and provides highly effective interactive graphic output in addition to tabular text. So far, response again lags. Maybe Rational is onto something.

C/C++?

[Stiletto]

What is this "C/C++" language? I've heard of C, and I've heard of C++, but not C/C++.

Re:C/C++?

[istartedi]

What is this pedantry regarding "C/C++"? I've heard of / used for "and/or" meaning that you may be using one, the other, or both, but I haven't heard of anyone having a problem with that outside of pedants on comp.lang.c and this /. posting.

Re:C/C++?

[Anonymous Brave Guy]

What is this pedantry regarding "C/C++"?

It's an attempt by those who understand the languages to stop the propagation of the myth that they are somehow inherently related such that a comment about one necessarily applies to the other. The two languages look superficially similar, and indeed for some time C++ was almost a superset of C. However, idiomatically, they are used quite differently, and there are now significant features in each language that are absent in the other.

The vast majority of comments I see where someone writes "C/C++", they really mean one of "C" or "C++", and they are trying to arbitrarily extend an argument inappropriately using proof by hand-waving. It has been noted by many pedants who object to this use that writing "C/C++" is almost surely a sign that you don't know one or other, and so far, I have yet to see many people breaking that rule.

Re:C/C++?

[istartedi]

It's an attempt by those who understand the languages to stop the propagation of the myth that they are somehow inherently related such that a comment about one necessarily applies to the other

Ummm... wasn't the first C++ "compiler" just a preprocessor that converted the code to C? Regardless, C and C++ are closely related, and C can often be pasted into C++ with little or no modification. Also, those who are familiar with one are often familiar with the other, even if they have a strong preference for one over the other. Although I would never say "my code is written in C/C++" I have no problem putting "C/C++" on a resume, talking to employers who are looking for someone with skills in "C/C++", or making arguments about "C/C++" vs. Java. We know what is meant, even if others insist that it's meaningless.

Re:C/C++?

[Anonymous Brave Guy]

Ummm... wasn't the first C++ "compiler" just a preprocessor that converted the code to C?

Yes, it was. And do you know how long ago that was, and how much the languages have both changed since then?

Also, those who are familiar with one are often familiar with the other, even if they have a strong preference for one over the other.

Those who are familiar with one often think they're familiar with the other, and draw false conclusions based on assumptions of similarity. This is exactly the reason why people who are genuinely familiar with both languages often dislike the use of "C/C++".

I would never say "my code is written in C/C++" I have no problem putting "C/C++" on a resume, talking to employers who are looking for someone with skills in "C/C++", or making arguments about "C/C++" vs. Java.

Sorry, but I don't think the term "C/C++" is useful in any of those situations. If you have skills in C and/or C++, say so. Writing "C/C++" suggests that you've learned some hybrid out of a Schildt book and don't actually know the difference. As for making arguments comparing "C/C++" with Java, I'm afraid that's just silly. C, C++ and Java have syntactic similarities, but C and C++ are no more similar than C and Java or C++ and Java.

Re:C/C++?

[istartedi]

Sorry, but I don't think the term "C/C++" is useful in any of those situations. If you have skills in C and/or C++, say so. Writing "C/C++" suggests that you've learned some hybrid out of a Schildt book and don't actually know the difference. As for making arguments comparing "C/C++" with Java, I'm afraid that's just silly. C, C++ and Java have syntactic similarities, but C and C++ are no more similar than C and Java or C++ and Java.

It doesn't matter what you or I think. The PHBs say "C/C++" so when I speak with them I use it too. If I came at them with pedantry about the difference between the two, the response would be predictable: they would either say "I know that" or they would label me as "technicly competent but unable to work well with others".

Re:C/C++?

[istartedi]

Oh, I forgot to add (since I pasted in your whole last paragraph). That C and C++ most certainly *are* more similar to eachother than they are to Java. If you can't see how, I think you're a poser.

Re:C/C++?

[Anonymous Brave Guy]

It doesn't matter what you or I think. The PHBs say "C/C++" so when I speak with them I use it too.

The good PHBs don't. In fact, I judge (with considerable accuracy so far, I might add) the competence of those who interview me for jobs based on precisely this sort of detail. If I come across a company where the staff conducting a technical interview or running the projects don't know the difference (or -- another favourite -- think JavaScript and Java are somehow the same thing), I run away as fast as I can.

And in response to your other reply...

That C and C++ most certainly *are* more similar to eachother than they are to Java. If you can't see how, I think you're a poser.

No, I'm an experienced programmer with knowledge of all three and a different opinion. Calling me names won't change that.

C is fundamentally a procedural language. While it can host OO and generic programming approaches, it provides no particular support for them. OTOH, for the low-level bit-twiddling approach, there's nothing to beat it. It is very much characterised by the use of compact, precise code.

Java is the equivalent but for OO: it can do procedural and (when the generics finally arrive in routine use) generic, but OO is its only real forte. The emphasis in typical Java programming -- though this is probably more to do with what it's used for than any inherent limitation in the language -- is much more in stringing together bits of the vast standard library it ships with than in low-level bit-twiddling.

C++ can surely do procedural or OO, but at its best it is characterised by the use of complementary procedural and OO approaches, with generics allowing some very helpful techniques in supporting that mix.

To me, these languages have obvious parallels in syntax, but in style, they are all worlds apart. What is it that you think is more similar in C and C++ than the links between C and Java or C++ and Java?

Re:C/C++?

[istartedi]

The good PHBs don't

"good PHB" is an oxymoron. :) Note, I used "say" in an overly broad sense. I should have explicitly stated that I was referring to printed ads and/or online job postings. I'm not sure if I've ever heard anybody say "C C++" in an interview.

To me, these languages have obvious parallels in syntax, but in style, they are all worlds apart. What is it that you think is more similar in C and C++ than the links between C and Java or C++ and Java?

C and C++ compilers are often packaged together (or maybe even integrated into the same executable with different action taken depending on file extension).

Java compilers, OTOH, often stand alone or are sold as an add-on.

The biggest difference is this: C and C++ compilers target various processors; both produce system-specific binaries. Java compilers target a VM designed to run cross-platform. The output of a Java compiler is a .class file. Further refinement of the way that .class file is handled takes place in the JVM implementation, sometimes with JIT compiling. This is in stark contrast to both C and C++ where the binary output by the compiler is fully optimized for the target platform.

C and C++ *both* excel at low-level "bit shuffling" when compiled with the right tools, and when proper techniques are used. Many C code-snippets for this purpose can be pasted directly into C++ code with little or no modification.

I could see how you could argue for a stronger link between Java and C++ since they are both OO, but C++ is C's child (note, I know C is not a subset of C++, but C++ is C's progeny) whereas Java is more like a close friend of both. Native methods for Java could be implemented in either C or C++, but they could also be implemented in other languages. However, the goal of Java is not to have very many people using native methods. Their ideal is to build a very large equivalent of C's "standard library" whereas C and C++ define a relatively small core standard and let us pick and choose libraries.

C++ programs often link to C libraries. I call this a "mongrel". Let me reiterate--"C/C++" is an expression that can be easily abused, and if somebody called a specific mongrel a "C/C++" program I would want to know what parts were written in what language.

C++ grew out of C. In another part of this thread, it was stated that the developer of C++ disliked having the two lumped together. Well... he called it C++ because he knew that by tying it to something familiar he would gain acceptance. Now that C has lost ground in some circles he wants to take that association away. This strikes me as a case of someone who made their marketing bed and now has to lie in it.

Looking over your response, it appears that you are focusing just on a strict academic analysis of what each language strives to do. I'm thinking more of the environments in which the languages are used, what's going on under the hood with each of them, and the history of them.

I could probably come up with more but... Oh well, enough of this... I have to go annoy some "shell/Perl" scripters.

Re:C/C++?

[Anonymous Brave Guy]

I guess the thing is that you're looking at the programming and run-time environment, where clearly Java is very different to any completely compiled language, whereas I'm looking at the programming style, where C, C++ and Java are all quite different.

To me as a developer, the former might sway my decision about which language to use, but is otherwise irrelevant; I could take a C++ guy familiar with classes and OO design, teach him Java's minor syntactic differences and let him go, and he'd be producing results. Of course, the difference between that guy and a skilled Java programmer is (mostly) the latter's knowledge of a few Java idioms and its standard library.

In contrast, you cannot take a good C programmer, show him a couple of minor syntactic changes and a command-line switch, and turn him into a good C++ programmer. The difference in programming idioms -- whole paradigms, even -- is much greater. OTOH, of course, C++ inherits much of C's standard library, and he could continue to use that until he was up to speed with the C++ equivalents, and when to use each.

Re:What's the fun in that?

[Anonymous Coward]

So, basically, you are saying that you work in the most inefficent way possible because it makes you more manly. I tire of people who will try new tools and techniques because it isn't the way our forefathers did it. Bottom line: I can find and fix defects faster with a debuggers and such than with prinln/>>/printf etc. Hence, the reason we call it a "Poor Man's Debugger." As an engineer, you should always be looking to improve the efficency with which you work. End of discussion.

Whether or not you like Purify and its ilk are inconsequential, but your refusal to open your mind to new methods and techniques are what repulses people. Attitudes like yours create COBOL and FORTRAN system maintainers -- not true software engineers.

Re:What's the fun in that?

[iabervon]

Read the core dump? Ha! Good programmers know what's wrong from when the segfault occured.

But if you're going to use tools, having a tool that tells you when a value gets written somewhere wrong is far better than one that tells you what was going on when the program actually crashed.

This is actually vital for bugs where an uninitialized value is assumed to be zero, and it always is zero in your tests, but...

Re:What's the fun in that?

[nr]

True, the only things I need and use is gcc, vi and make, but gdb and ddd comes handy sometimes then you have to track down some nasty bug that causes coredumps. Highlevel debug tools is good, sometime in the future they may help you.

vi and gcc are my two top favorite applications that I love to use.

Awesome tool!

[Jacek Poplawski]

I run it on my game ( Escape Of the Unicorn ) and found first memory bugs. This tool is great - we will fix a lot of leaks now!

Valgrind is very slow, but it's worth to run it on all programs you are writting. It even displays some bugs related to SDL/XFree86, but a lot of its output is usable.

re: speed

[Nick Mitchell]

Hi, if you have them handy, I'd totally appreciate if you can share any performance numbers. I'm not being facetious at all, I am the anti-slashdot, and am truly interested! I'm doing research on memory leak debugging, so data is the drug I desire. :D thanks! nick

Re:Call me ignorant if you like...

[XO]

You probably didn't read the Technical Documentation, which I wouldn't necessarily have expected, particularly for someone with a legalish background.. so don't consider this a flame at all. Normal conversational tone applies here:

The technical documentation basically implies that there is no MODIFICATION going on. valgrind simulates an x86 processor, and while it does it, keeps tallies on all sorts of debugging statistical stuff like that.

No "modifying relocatable object code".

I guess technically, just by reading the title, that patent would also apply to operating systems, since Operating SYstems modify relocatable object code and monitor the programs.

Re:Market for commercial programming tools for Lin

[movement]

Here's some suggestions :

1) don't charge such an absurdly large price
for software mostly built on free software
(Mikael's perfctr)

2) accept that when you have competition that
is free software, it's gonna beat you.

[Disclaimer: I am indeed the lead developer for
your competition]

Re:What can I say: Linux is the best

[istartedi]

That's why they are holding on to their pile of cash. There is talk of them forming "Microsoft Capital" which would provide financial services like GE Capital does.

So, the Linux crowd might get their wish and find that one day MSFT is a bit player in OS software, or perhaps even discontinues their OS someday. In fact, I wouldn't be a bit surprised if Bill Gates actually dreams of discontinuing Windows so that he can just own shares in a nice reliable big banking and financial services conglomerate during his golden years.

This will leave a bitter taste in the mouths of those who are truly vengeful and hate "M$". Like most people who have the winning way, BG and company will go on about enjoying their lives scarcely even conscious of those who hate. Meanwhile, the hateful will continue eating ramen and lamenting what they see as the injustice of the world. Those who simply wanted a better OS will probably eat ramen too. The difference is that they will do it with contentment, because they too have the winning way.

Where have you been?(wasRe:x86 VM)

[HuguesT]

OK,so you're a Java programmer, fine, continue to use it, no worries there.

Reasons for using C/C++ include complete control over execution, deterministic behaviour of application and raw speed. For memory allocation in C++ malloc() is no longer necessary, use , , etc. The reason why C++ does not have a standard garbage collector is that the ISO committee thought that adding one would hamper performances too much for little return.

FYI C and C++ actually have an ISO/ANSI standard, so does C, unlike Java. The last revision of C was in 1999 and it includes variable length array (VLAs). Personally I will not touch Java for anything important until it is standardised.

You are right about a standard GUI though, that would be nice. However existing GUIs aren't `standard'. The difference in the way of thinking and in general appearance between, say, MacOS/X and Windows is still big. Sure they both have buttons, dialogs and lists but the similarity end pretty quick. If you wanted an advanced application that looked native and worked on both you would be severely limited in your choice of widgets.

Re:Where have you been?(wasRe:x86 VM)

[j3110]

yea, a clever reply! :)

I'll just start by saying that I'm not just a Java programmer. I have about 5 years of experience in C++. I did mainly server side programming and no real GUI, just moving around data.

C/C++ do not give you complete control over execution. You can't tell me you don't link to libraries. If you don't, then you are throwing away hours of time that your competition is adding features. At some level, you have to deal with an OS that may or may not work the way you expact as well.

Java does manage to do garbage collection for about 20% penalty, and LISP isn't bad at all itself. If other people can do it right, then why not C/C++? It really doesn't have to be as bad as people make it out to be. Think about the logistics of it sometime. It wouldn't be difficult or too taxing to keep a hierarchy of pointers in a central class/table and call a cleanup function every 10 seconds or so to check where pointers have changed and which memory addresses allocated are no longer being referenced. I would like for it to be done at the language level because frankly, the people who would care enough to do such a thing to begin with would probable not have memory leaks anyhow. Those that do debug their software should be writting more good software and features instead of debugging something that is unneccisary. Not that GC should be forced, but it should at least be an option!

Just because there is an ISO/ANSI standard for C/C++ doesn't mean that people follow it, yet they still call it C or C++. At least with Java, if it has the cup, you know it passed the certification. Don't get me wrong though, it's not that I don't think it should be open to the public, I just don't think it should be called C or C++ when it isn't really. Honestly, do you think that GCC is perfectly ANSI compliant? I don't see how since v3 caused everyone to fix some of their non-ANSI code. It still supports multi-line string literals despite the ANSI standard. There's as much of an ANSI standard for C/C++ as there is for SQL. It's very difficult to write SQL or C/C++ code that works on multiple compilers in the way you intend. ISO/ANSI has been a complete failure in ensuring that the standard is followed.

I think that even for the user's sake there needs to be some consistancy between GUI's. Native GUI's are a terrible thing in most cases. Just because it looks like the host operating system doesn't make it a good thing. Really, the most successful programs are skinnable and look nothing like the host OS. Winamp and Trillian are good examples on the windows side where massive amounts of people have adopted programs that don't look like windows. Also, I would say, gkrellm is a great example for Linux. Native GUI's aren't really all that good of a thing.

Don't be so afraid of Java. ISO/ANSI are independant companies for profit themselves. I fail to see the difference between them and the JCP. Java applets that I wrote as a student 6 years ago still work today, can you say the same for all of your C++ programs? Do they still compile? Do they still run in binary form? Yes to both on the Java side of things. The world is going to GC whether C/C++ wants to go or not. Micrsoft, IBM, SUN, Apple, and even Oracle know it.

Re:Where have you been?(wasRe:x86 VM)

[elflord]

Not that GC should be forced, but it should at least be an option!

gc is an option, because there are gc implementations for C++. It's not in the standard, but the standard doesn't say that you can't use gc.

Just because there is an ISO/ANSI standard for C/C++ doesn't mean that people follow it, yet they still call it C or C++.

There's no rule saying that you have to follow the standard, but there are standards compliance test suites, and in practice, implementations are good enough that you can usually code to the standard and expect your code to work.

Honestly, do you think that GCC is perfectly ANSI compliant? I don't see how since v3 caused everyone to fix some of their non-ANSI code.

gcc had substantial standards compliance issues prior to the release of gcc 3.0.

There's as much of an ANSI standard for C/C++ as there is for SQL. It's very difficult to write SQL or C/C++ code that works on multiple compilers in the way you intend. ISO/ANSI has been a complete failure in ensuring that the standard is followed.

Sorry, completely and utterly false. The standard has been succesful, and because of it, there are a number of compiler vendors who are rapidly converging to conforming implementations. It's taken some time for vendors to implement the C++ standard, because it is a very complex standard that is difficult to implement correctly. But to dismiss it as a "failure" on the grounds that it took a while to implement is dishonest or stupid.

I think that even for the user's sake there needs to be some consistancy between GUI's. Native GUI's are a terrible thing in most cases. Just because it looks like the host operating system doesn't make it a good thing. Really, the most successful programs are skinnable and look nothing like the host OS.

False, false and false. Native GUIs are good, because platforms need a consistent interface, and what's appropriate on one platform may not be appropriate on another (eg PDA vs PC). Consistent look is not the issue, consistent feel is. Most succesful programs are not skinnable (but even then, that's a change of look and not feel.

Don't be so afraid of Java. ISO/ANSI are independant companies for profit themselves.

No, they aren't "companies".

I fail to see the difference between them and the JCP.

Apparently Sun does see a substantial difference, because it was not willing to accept the loss of control that would have resulted from turning Java over to a non-partisan standards organisation.

Java is a great technology, but that doesn't excuse your ignorance about ANSI/ISO.

Re:Where have you been?(wasRe:x86 VM)

[j3110]

Implementations are NOT good. Take the top compilers used today, (Intel's, MS VC++, GCC, Borland) and see how many programs compile on all of them! This is precisely why it's a failure. ISO/ANSI itself is a failure because there are relatively no standards that they have produced that have been followed such that code is portable.

GC that isn't at least a compile time option (preferably a run-time option), is useless to those who actually need it. One spec implementation is worth a hundred good other implementations. Reasons: 1) Not tied to different licences. 2) All compilers will support it on all platforms. 3) It would actually be used where needed.

In the example that you site as a good place for native GUI's is the most ignorant arguement I've seen on slashdot to date. Not even Java promised that you wouldn't have to rewrite the GUI for PDA's. (Don't quote hype, find a trusted source where SUN claimed you could run the same code on a PDA) The GUI's are fundamentally different in that case. The look AND the feel of the program should be customizable by the user. That is the promise of Java's LNF. You can choose native if you want, but the LNF is seperate from the code, therefore, you don't have to rewrite the GUI to make it look or feel different. The user ultimately should decide how the program behaves. Any arguement to the contrary is ridiculous.

http://www.iso.ch/iso/en/aboutiso/annualreports/ 20 01/index.html
excuse me but I think the fact that they have a financial statement is enough proof that they are a for profit entity. Though ANSI is nonprofit, the only real spec they are known for is the one that causes my ls to be colorful :) At least it seems to be the only one that stuck. Besides, if the ANSI standard was so hard to implement, one could argue that the tools used to implement it where inferior. Just think about that one for a moment.

This loss of control as you would call it is what ensures that my program will run on ANY Java runtime environment. Can you say that your C/C++ code will compile on ANY C/C++ compiler??? Don't be so ignorant to ask SUN to destroy something good. They have a JCP that decides the fate of Java, and SUN makes sure that it is implemented properly or not at all. If SUN wasn't in control, C# would have been J++ and not a single thing SUN or the JCP would have done could have mattered. SUN has and is making it possible for open source implementations of Java to be certified. Have you not been reading the Apache-Sun conversations? Soon there will be free test suites for nonprofit and open source implementations of the Java specs. Not that you can't implement the spec all you want, you just can't say it's certified if it isn't. You can create uncertified open source java all day, Apache and JBoss has been doing it for years. You can derive it to be whatever you want. You just can't call it certified until it passes the tests. I only wished C/C++ was like that. That alone would be enough that I would still be using it. There's the difference that SUN sees between ISO/ANSI and the JCP.

C++ was a great technology and may be again someday and still has it's place, but that doesn't excuse your ignorance about the JCP/SUN.

Re:Where have you been?(wasRe:x86 VM)

[elflord]

Implementations are NOT good. Take the top compilers used today, (Intel's, MS VC++, GCC, Borland) and see how many programs compile on all of them!

A lot of programs compile on all of them. Pick a random C++ textbook, and nearly all the code in that book will compile on all major compilers. I'm not sure what your complaint is.

Of course, there are extensions, and one vendors extensions will not be the same as another vendors, but this doesn't mean that the standard "is a failure". Actually, it's just a reflection of the fact that in C++, there is a clear distinction between "language" and "platform", while in Java there is not. This is a design tradeoff that java makes, not a free lunch.

In the example that you site as a good place for native GUI's is the most ignorant arguement I've seen on slashdot to date. Not even Java promised that you wouldn't have to rewrite the GUI for PDA's. (Don't quote hype, find a trusted source where SUN claimed you could run the same code on a PDA) The GUI's are fundamentally different in that case. The look AND the feel of the program should be customizable by the user. That is the promise of Java's LNF.

Try to understand my argument before launching into name-calling. I know Sun didn't promise that you could use the same GUI code for PDAs and desktops. But different platforms do have different looks and feels Claims that these "should" be customisable by the user are contentious at best. I'm not going to get drawn into this argument, but it's certainly not as obvious as you make it sound.

excuse me but I think the fact that they have a financial statement is enough proof that they are a for profit entity.

Not at all. You can have financial statements without being for profit. Financial statements imply revenue and operating costs, but not profit.

ANSI is nonprofit, the only real spec they are known for is the one that causes my ls to be colorful :)

They are also known for C and C++ (-;

Besides, if the ANSI standard was so hard to implement, one could argue that the tools used to implement it where inferior. Just think about that one for a moment

Seriously, the spec is hard to implement because of its complexity. There are a lot of good tools available (including java, which apparently didn't prove to be useful to any known implementor)

This loss of control as you would call it is what ensures that my program will run on ANY Java runtime environment.

No it doesn't. The JVM spec is what provides this assurance. Submitting java to a non-partisan standards body would not hurt this goal.

If SUN wasn't in control, C# would have been J++ and not a single thing SUN or the JCP would have done could have mattered.

Do you think it is better that we have C# as opposed to J++ ?

You just can't call it certified until it passes the tests. I only wished C/C++ was like that. That alone would be enough that I would still be using it. There's the difference that SUN sees between ISO/ANSI and the JCP.

Regarding C, all recent compilers should be able to compile conforming ANSI 1990 C code. Portability issues have to do with platform specific code (eg implementation defined extensions), not the language itself. Regarding C++, the main issue here is that it has taken a long time to implement the standard. A certification process would not have resulted in vendors implementing the standard any faster.

Valgrind Rox

[msevior]

Hi everyone,
I'd just like to reitterate the "Valgrind rox" sentiment flowing through here. We've used valgrind extensively on AbiWord with excellent effect.

This is a great program. BTW the $0 price really helps us as where 100% volenteer.

The author is great too. He is very quick to respond to issues.

Cheers

Martin Sevior
AbiWord Eveloper

Re:Valgrind Rox

[msevior]

He He :-) Spellecking is one reason I use AbiWord at work everyday.

What a hammer!

[Animats]

Valgrind makes you realize how much excess CPU time and memory we have available today. The thing has huge memory and speed overheads, yet today's machines are fast enough, and have enough memory, that valgrind's big-hammer approach to the problem works.

Still, why not do it that way? Machine resources are cheap.

Re:What a hammer!

[MassacrE]

It is much more stupid to throw developers (money) at a problem. Premature optimization is a problem many developers face. Write the code first, then optimize areas your profiling tools say are hotspots if you need more performance. Assembly is often overkill, even though it quite '1337.

Re:What a hammer!

[cant_get_a_good_nick]

From The Art of Unix Programming, Chapter 1

Programmer time is expensive; conserve it in preference to machine time,

In the early minicomputer days of Unix, this was still a fairly radical idea (machines were a great deal slower and more expensive then). Nowadays, with every development shop and most users (apart from the few modeling nuclear explosions or doing 3D movie animation) awash in cheap machine cycles, it may seem too obvious to need saying.

Somehow, though, practice doesn't seem to have quite caught up with reality. If we took this maxim really seriously throughout software development, the percentage of application written in higher-level languages like Perl, TCL, Python, Java, and Lisp that ease the programmer's burden by doing their own memory management would be rising fast.

And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++). Later in this book we'll discuss this strategy and its tradeoffs in detail.

One other obvious way to conserve programmer time is to teach machines how to do more of the low-level work of programming. This leads to...

Re:What a hammer!

[elflord]

Somehow, though, practice doesn't seem to have quite caught up with reality. If we took this maxim really seriously throughout software development, the percentage of application written in higher-level languages like Perl, TCL, Python, Java, and Lisp that ease the programmer's burden by doing their own memory management would be rising fast.

Many of these high level languages have problems of their own. Languages like Python, Perl, and TCL lack any sort of compile time checking, which makes them error prone, and less scalable. This is why you don't see many applications that are millions of lines long developed in these languages. Simply put, memory management is not the only issue that programmers deal with maintainability is very important, and robust compile time checks, and the clarity that comes from having to explicitly declare interfaces and having the compiler check types is a maintenance benefit.

And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++).

Another fallacy -- that C++ is somehow "equivalent" to C. C++ does not make memory management as simple as java, but it is certainly simpler than C, and arguably, for nontrivial applications, it is at least as good as languages that force a reference counted system on the user (python, perl) as reference counting is often not an appropriate memory management model.

Re:What a hammer!

[BillGodfrey]

Eric Reymond clearly isn't an embedded programmer.

Re:What a hammer!

[dvdeug]

Eric Raymond may not be an embedded programmer, but neither are most of the programmer's he's talking to. He clearly recognizes there are exceptions to the rule - "Nowadays, with every development shop and most users (apart from the few modeling nuclear explosions or doing 3D movie animation) awash in cheap machine cycles". In any case, embedded programming tends to worry about trading cycles for reliability, which has some of the same principles.

Re:What a hammer!

[elflord]

I can make changes and have them online in 3 minutes tested and all! Now try that with your favourite compiled language ;-)

Easy to do with good design. Use dynamically loaded modules. Decouple interface from implementation by using "handle" classes. Use interpreted languages to write "outer layers" of your application, etc. Minor changes in implementation do not require big recompiles. Changes in important interfaces do (but then, they usually also require code updates.)

40MB of perl, huh ? Just thinking about that makes my head hurt. Perl was the first language I learned, but I'm glad to have left it behind.

Re:What a hammer!

[BillGodfrey]

Well, so much for distributed computing.

I'm hoping that soon, someone will run a distributed project, paying people for work done instead of just a chart of top workers.

Idle cycles would be worth something.

Bill, ho hum.

Being wrong != being a troll

[Sanity]

You give a great explanation of why he is wrong, but I don't think that justifies a troll moderation. In fact, I really wish that Troll and Flamebait moderations were removed, since they are just begging people to moderate based on agreement/disagreement, rather than their actual intent.

Moderation privs should not be used to suppress opinions with which you disagree.

I don't know about you...

[Akardam]

... but I try not to dream in and/or about C/C++. It hurts. :)

On the other hand, dreaming in perl is probably pretty close to the programmers version of an acid trip. The colors!

Re:what purify lacks

[jreiser]

Even better than the last piece of code to touch the leak, would be the exact instant when the block became unreachable. It can be done!

Of course you can just avoid those errors...

[voodoo1man]

For most applications, it just makes better sense to avoid these errors altogether by using a good garbage collector.

An excellent implementation is the Boehm-Demers-Weiser (commonly referred to as just "Boehm gc") conservative gc. It can be used for C/C++, and is highly portable. It's a real-time, non-compacting (so you still get heap fragmentation like managing memory by hand, but the collection time is shorter and it's more portable), and uses a conservative mark-sweep algorithm (briefly, treats anything that looks like a pointer as a pointer, to avoid costly checks or increase portability in the case of C/C++.)

For a moderately large amount of garbage, the incremental collection pauses take less than about 5-10 milliseconds (hence why it's a real-time collector) on a PIII-500, the algorithm scales fairly well, and it's suitable for all but the most time-critical (anything video related) or memory-thrashing (I really don't know of any app that needs to be) programs. GC will speed up development time tremendously, and can eliminate segmentation faults and memory leaks for most programs. I really don't understand why more projects don't use it.

That being said, Valgrind does seem extremely useful for projects that do need to allocate memory manually. It looks very convenient to use, and the thoroughness of the checks is impressive. The implementation does seem a little uncomfortable to me - it's certainly a lot of effort to write a whole virtual machine just for the task! The portability prospects aren't appealing either.

Re:Of course you can just avoid those errors...

[JoeBuck]

valgrind isn't just a GC, it detects use of unitialized variables as well, and that is, if anything, more important.

Re:Of course you can just avoid those errors...

[clard11]

Not that there is anything wrong with using a garbage collector, but my experience with customer applications based on java application servers is that you are really exchanging one set of C/C++ memory errors for another type (object leaks where you still maintain references to a portion of the object graph, preventing the objects from being collected, through application errors) and in a lot of production type environment the tools for figuring out object leaks either don't exist or are not as mature as those for figuring out "traditional" storage leaks.

Re:Valgrid is not as complete as Purify

[leob]

There are two important features of Purify that are most notably absent in valgrind:
- the ability to specify user's memory allocators/deallocators (it is mentioned in the documentation, though)
- the ability to detect array bound violations (Purify's ABR/ABW).

You decide which of the two is more important for you.

Re:what purify lacks

[mce]

But the overhead would make it near unusable.

Tracking the last access can be done with reasonable overhead. I know this for sure, because I actually worked on stuff that can track all accesses (full stack trace) and that could easily be altered to single out the final one.

But deciding when something became unreachable is a whole lot harder. Even more so if, as is the case with Purify, you do not know the semantics of of the blobs of memory that you're toying with.

excuse me, but...

[sinserve]

(let ((I (get '*lisp* 'programmer)))
`(been I ,no-worry-about-GC)
(setf (get 'I 'skill) '(good programming techniques))
(with-carelessness
(learnt (have I) 'to-code
(with-no-worry-about
:memory-management
:optimization
:ease-of-use t))))

Re:excuse me, but...

[jtdubs]

Amen brother...

Justin Dubs

Re:excuse me, but...

[PissingInTheWind]

Cheers to that.

If only they knew too...

Re:what purify lacks

[mce]

It is the same thing.

No, it's not. Time of last access to an dynamically allocated block is when you last directly accessed it. Time of leaking is when you, possibly indirectly, caused it to become unreachable by accesssing some other block that looks totally unrelated unless you know a lot more about the program than Purify does.

Re:Anyone Tried Mozilla with Valgrind?

[mce]

The Mozilla people use Purify.

Re:What's the fun in that?

[unoengborg]

You mean just like real programmers don't use, editors
but write the code directly to the compiler input stream. They don't need debugging tools either.

More than just a GC.

[sconeu]

A lot of people seem to be saying, "Just use a good GC".

But from reading the Valgrind docs, it's more than just a GC. It checks for accessing memory through uninitalized variables, too... Very cool.

Disclaimer: I have not used valgrind yet, just read the online docs

Re:More than just a GC.

[HalcyonBlue]

How can it be more than just a GC when it's not a GC at all? A GC is totally different approach to solving this problem by preventing it before it happens as opposed to detecting the problem and then fixing it. I'm sure you probably already know this.. and if you do - fantastic. I have used valgrind.. and I'm wondering if there's any way to get it to tell us what line of code the leaked block was allocated on. I know it shows the function it was allocated in- but is this thing capable of telling me more? I've used tools like dbx and purify.. (dbx far more recently) and dbx could definitely give me this kind of info.

Linux and glibc impediments to programming tools

[jreiser]

Win32 has a not-so-secret advantage: VirtualQuery(), a random-access, binary structure interface to /proc/pid/maps. It's painful being required to parse a sequential text file that does not quote filenames in order to ascertain the status of the address space.

And wouldn't you really rather be told when the dynamic linker has added or removed modules? The current interface to DT_DEBUG, _r_debug.r_brk, _dl_debug_state might be suitable for a controlling process, but it's painful for a same-process debugger. For instance, on x86 there might be only one byte of code at _dl_debug_state(), so you cannot easily overwrite it with an arbitrary transfer of control. And if you use an int3 and SIGTRAP handler, then you cannot run gdb at the same time.

Re:what purify lacks

[jreiser]

No, "the last touch" and "becoming unreachable" are distinctly different, and a suitable tool could tell the difference. For instance, a memory read operation [in and of itself] cannot cause an allocated block to become unreachable, but it could be the last touch. Think about exactly what causes leaks of allocated blocks.

Re:what purify lacks

[mce]

Indirectly or directly - from the point of view of a malloc debugger it is the same thing. A malloc debug tool cannot make these subtle distinctions.

The (in)directness has nothing to do with the core point I was making. It's just an additional example of why tracking point-of-leak also is computationally more difficult than tracking point-of-access.

My real point is that to track point-of-leak, you need to cover at a lot more possibilitties. For instance, you need to cover the case where A leaks because B, which happens to hold a pointer a A hidden in between a lot of ints, chars, floats, structs, and unions (!) leaks. But B might leak only at the point where part of C is accidently overwritten (note: not freed or leaked!) due to some dangling pointer D being followed. In contrast, to just only track the location of the last access to B, you only need to worry about code that accesses B directly on the one hand, and dangling pointers "into B" (yes, I'm simplifying for the sake of not turning this post into an essay) on the other. Tools such as Purify could relatively easily be extended to give you the last access. The same does not hold for the exact location of the leak. The latter functionality can be implemented, but it's a lot more involved.

Trust me, I do know what I'm talking about. I've been writing tools to track and optimise memory accesses for a living for nearly 5 years now and have actually implemented a lot of the stuff that I mention above.

Re:Wrong solution

[sir99]

Umm, that paper barely mentions memory management, except to say that 1: C++'s destructors make things possible that other languages don't, and 2: garbage collection can't be guaranteed in C++. It has little to do with this discussion on memory leaks.

Re:Market for commercial programming tools for Lin

[jreiser]

(1) What would you say is a reasonable price for tsprof today?

(2) In the case of valgrind and my other tool, it looks like it takes free software about 2.5 to 3 years to catch up. So such a tool is worth only $30 to $40 per year?

Re:What's the fun in that?

[mcfiddish]

What about libraries that are doing all kinds of memory allocation behind the scenes? I'll be jiggered if I know what the hell XAlloc-this and XFree-that are doing.

Using valgrind, I've found several memory leaks in my code using the libX11 and the FreeType libraries that strictly were my fault, but were counterintuitive and I never would have found them solely reading the documentation and using print statements.

I'm thrilled to have a tool like valgrind on linux, finally. Thanks Julian!

Re:Awesome

[nathanh]

We have had this in the Microsoft runtime library for umm... ten years or something...

No we haven't. MSRT bundles a fairly normal bounds checker. From reading the documentation it seems valgrind is a CPU emulator with memory read/writes logged and analysed.

I can see a troll moderation coming on.

And you deserved it.

In our world, we are moving towards garbage collection. It rocks. The simple truth is that C-style memory allocation is well understood, sub-optimal, and obsolete.

Perhaps, but until we have finished moving there will be a need for tools like this.

Re:Valgrid is not as complete as Purify

[Citizen of Earth]

the ability to detect array bound violations (Purify's ABR/ABW)

Practically speaking, I think that it frequently does. It allocates memory blocks in such a way that writing beyond the end of an array (or before the start) is detected as a bad-memory access, so it will catch array-bounds problems for dynamically-allocated 1D arrays and frequently n-D arrays.

Re:PurifyPlus+MSDEV.EXE+icl.exe has yet to be beat

[Doomdark]

nothing beats an XP box with Visual Studio 7, Intel C/C++ 6 and Rational PurifyPlus.

Valgrind, alas, does nothing much to help.

Um, Valgrind apparently can more or less replace PurifyPlus, which is not available on Linux. PP was one of 3 dev components you mentioned. Thus, one third of the problem solved (or alleviated).

So how is not doing much to help?!?! You think it's ok to have have 3 (somewhat) separate tools on Windows, but in Linux one tool needs to do it all? What am I missing herE?

valgrind can handle static libraries

[JoeBuck]

I've used Purify for nearly a decade, and have been banging on valgrind for several months as well. I think that two of your three criticisms of valgrind are off base.

valgrind copes with static libraries. The only requirement is that the executable be linked to at least one dynamic library, and glibc will do. This is needed to allow valgrind to get control. Since for Purify you need to have the .o files so you can link, in the analogous situation with valgrind you can always link dynamically with the C library.

Valgrind has a suppression file that is much like that of Purify.

The only point you raise that is completely valid is that valgrind is x86-only. Those who really care might want to work on a port to other architectures, though it's a big job: you need a complete virtual processor.

Purify's GUI can be quite useful, but it would be preferable, if someone wants to do the same for valgrind, to implement any GUI as a completely separate program. That way the KDE and Gnome people can assure that there are at least two of them. :-)

Finally, to be fair I suspect that a Purify'd executable is faster. But then, you don't have to do a special, expensive link step, so the compile-debug-recompile flow feels faster with valgrind.

Re:Market for commercial programming tools for Lin

[Wumpus]

I've never heard of tsprof until I read your post here. Maybe that's part of your problem. When I searched Google for 'Linux profiler', It didn't show up in the first fifty results or so. This means I wouldn't have found it had I been looking for a profiler right now. Maybe the text on your web page should include the word "profiler"? I would assume that most people looking for a profiler would search for it by that name.

You could try getting more people to link to your web page, or find other ways to get the word out. Unfortunately, you have pretty tough competition, and you can't beat their price. I don't know what you've done to market tsprof, but it was probably not enough, or it was done the wrong way.

Your Flat profile window looks awsome, by the way. Would have been cool if you colored it using only 4 colors, though...

Good luck!

Servlets/J2EE/JDBC are the dominant use for Java

[adam_megacz]

The amount of Servlet/J2EE/JDBC Java code out there vastly exceeds the amount of AWT code.

Sun's entire java.sun.com site runs on J2EE, which does not use AWT. Sure, the applets use AWT, simply because it's impossible to create an applet that doesn't use AWT (java.applet.Applet extends java.awt.Component).

Re:Wrong solution

[elflord]

Could it be that there is something wrong with the languages which we use? You know darn well that there's something wrong! I invite you to explore the dark side of C/C++ in this timely paper [virginia.edu] by Mark Sakkinen.

Timely ? It may have been at the time of writing. It's out of date now, and a lot of the complaints it raises have been addressed by the addition of templates, STL, etc. C compatibility features that the author complains about are still included in the language, but they are primarily there to support legacy code-- for example, there's no reason to use arrays in new code.

I'm not sure what you consider to be "the underlying problem". There is no programming language that provides the guarantee that programmers will write bug-free code. Where is this "better" technology that is "inherently safer" that you speak of ? If it really is "better", why isn't everyone using it ?

Re:Valgrid is not as complete as Purify

[jelle]

IIRC purify also doesn't guarantee to catch all oob accesses, so they probably use a similar technique.

No silver bullet

[Pseudonym]

OK, first, what we seem to agree on...

• Yes, GC makes your code cleaner.
• Yes, GC is easy to use.
• Yes, GC usually does not slow down your code. (That is, what you gain in the ability to use better algorithms is usually greater than the cost of running a garbage collector.)

However:

• It does not solve all of your memory problems. C++ still lets you write out of the end of memory blocks. (Not that you should be using C-style arrays in C++ if you can at all avoid it.)
• It does not interact well with several well-used C++ idioms, such as the resource acquisition is object creation idiom.

The latter, IMO, is the more serious of the two. If an object holds a resource, then until it is destroyed, the resource is held. Even the best general-purpose garbage collectors you can find today do not guarantee a maximum time between an object becoming unreferenced and being cleaned up. This goes double for conservative GC, where the resource might not be freed until everything which looks like a pointer to the resource-holding object disappears.

So in summary: I'm a big fan of GC, but it doesn't solve all my problems, and that's especially true in C++.

Re:Linux and glibc impediments to programming tool

[spitzak]

I'm not sure if this is the same as VirtualQuery() but I think it would be nice if a lot of the structured files were divided down into many more and much smaller files. So for instance that filename you want is actually the contents of a single file. I would expect this is easy with proc(). It should also be done with all the machine configuration but I expect reiserfs would be needed for that to be efficient. This would give the few advantages of the Windows calls (ie the registry calls do get you a single field without any more parsing needed) but also allow normal filesystem tools to be used.

Of course I'm not sure if there is any chance of this happening because it will break all the tools everybody is using now...

Hey cool, Pan for OSX .. [OT]

[torpor]

This is pretty dope:

http://pan.rebelbase.com/screenshots/osx.png

Gotta say, OSX seems sexier and sexier, every day ...

This shows the weak spot of C++

[Otis_INF]

No offence, but if you need a 3rd party tool to check if the output of the compiler, which was produced after the compiler found that the input (your code) was correct, is correct, perhaps it's time to take a step back and think about a better solution that will fix what I call the 'weak spot' of C++: you have too many stuff to take care of, it backfires on you.

Today, the software that's used to develop software should be there to help developers write solid code from the start without overhead, without the necessity to program the plumbing code which makes your program logic run in the first place.

Some people here have suggested that GC is a better solution than just feed your compiled binary to another tool in the chain of tools and I agree. When you look at .NET and the Java platform, you'll see that there isn't a necessity for the overhead you have to program with C++, so there's also no need for tools like purify or valgrind.

For solutions where C++ is the only way to go, it's probably a welcome addition to the set of tools to work with, but for C++ in general it isn't IMHO, it only shows where C++ should be improved, or better: where the RTE of C++ should be improved so these tools are obsolete in the future.

Re:This shows the weak spot of C++

[Gumpu]

It's not so much a problem of C++ as a problem of the sloppyness of the programmer. Keep track of all the new and deletes in C++ is difficult. However GC, as found in Java, is not a magic bullet.

It is possible to leak memory in Java too (by making circular structures).

Even worse, because objects stay around until the last reference to it is gone, it is possible to have several copies of the same object lying around. This can lead to very hard to find errors.

For instance:

An object A might contain a reference to object B.
An object A2 might also contain a reference to object B, but to an older version. (Due to update error or so).

You think they both point to the same object B, and use A and A2 accordingly. Your program will not crash, because both references point to a valid object, but it won't function correctly either. It might fail only after a very long time, due to other errors that are induced by this error. This will make it very hard to find the error.

Have fun,
Frans.

Re:This shows the weak spot of C++

[Shillo]

> It is possible to leak memory in Java too (by making circular structures).

GC present in just about any Java VM handles circular structures just fine (hint: They don't use refcounting).

--

Re:This shows the weak spot of C++

[Otis_INF]

It's not a magic bullet as in 'take this pill and you're free of trouble!', but it's a great start to finally do something about it.

What I find fascinating is that when it comes to the lack of help provided by C++ for the programmer, the frase 'but it's the sloppy programmer!' comes up a lot as the possible reason why programs written in C++ have memleaks and other crappyness.

This is totally a proof a lot of people are 'in denial'. True, memory leaks are possible in Java and f.e. also in .NET (CLR boxing stuff can lead to memleaks, albeit small), but most developers using these platforms like Java and .NET will not create code that can lead to a memleak or buffer overflows, stackcorruption, memory corruption etc.

C++ forces the developer to create EXTRA code to make it run perfectly (i.e.: without memleaks, stack corruption etc). To me, that's fine when there is no other choice (read: technology isn't on a level where a RTE can be fault tolerant and fault preventing) but in 2002, technology IS at that level where RTE's will make sure developers don't make mistakes and languages using these RTE's are nowadays able to provide a working environment for the developer where that developer doesn't have to write that EXTRA code to make the logic run correctly, that's already in place, provided by the language/compiler combo and / or the RTE.

Perhaps C++ will get extended to meet those requirements, but I fear a lot of those self-called 'Elitists' now using C++ will not use these extra features simply because (according to them) then 'everybody' can use C++ and thus C++ will 'degrade' to a language of choice for the 'average' programmer, not stay a divider of who's good and who's not.

Re:This shows the weak spot of C++

[Gumpu]

So why do they have tools to find:
Leaks them? They are mentioned at the bottom of the page. The main text of the page explains how memory leaks in Java can occur.

Don't get me wrong, Java is a wonderful language, but every solution to sloppy programmers will also have disadvantages....

Re:This shows the weak spot of C++

[Shillo]

Checked the article. They describe the case where a program inadvertantly builds a (potentially) infinite data structure - they plonked every object (of a certain kind) into a hashtable that wasn't weak. This isn't a memory leak, really, just shoddy logic - I'd prefer if the article called it for what it really was.

Furthermore, GC is not a solution for shoddy programming, it's a tool that allows a different approach to programming (my favorite feature: exceptions become *VERY* cheap, as they reduce to, basically, a longjmp - no stack rollbacks). And it does make memory-related bugs very rare (modulo programmer stupidity :) ).
--

Re:This shows the weak spot of C++

[Gumpu]

Agree with all points.

> Furthermore, GC is not a solution for shoddy programming

That was the point I was trying to make.
(But didn't really succeed in :)

Both GC and explicit memory allocation have their place...

I think the real weak spots of C++ are:
(1) the very cryptic error messages you get when using the STL, and (2) having to figure out, over and over again, which files to include where... one would think an compiler could take care of that.

Have fun,
Frans.

Re:What's the fun in that?

[stekman]

Real programmers does not use compilers, they program using small magnets directly on the harddisk surface. :-)

Re:Anyone Tried Mozilla with Valgrind?

[Salsaman]

But according to trhe story, Purify only works with 'doze.

Re:PurifyPlus+MSDEV.EXE+icl.exe has yet to be beat

[Shillo]

> Sorry guys, but as far as C/C++ development goes, nothing beats an XP box with Visual Studio 7, Intel C/C++ 6 and Rational PurifyPlus.

How about XEmacs, gcc 3.1, Valgrind and a summer vacation on a tropical island of your choice, for the same price?

--

Re:What's the fun in that?

[Guillaume Laurent]

> In the 90's, we programmed in C++, and debugged with >>.

If you debug C++ with '>>', it's no wonder you have problems. Try '<<' next time. Works a lot better when applied to std::cout.

Just like ZeroFault

[Mask]

ZeroFault on AIX has been using a virtual machine for ages. I first came across ZeroFault around 96-97, so you can't say this technology is extremely new.

It is a nice technology and execution speed is reasonable. Yet, it has several gotchas. Most of them due to semantics lost at compilation:

• The compiler may generate code that speculatively accesses/mutate data. This operation is later discarded if the speculation was wrong. The speculative access/mutation may result in uninitialized data access.
• In C++, empty classes are common (e.g. functors). These classes have sizeof > 0. Now, the compiler may generate code to copy these dummy structures. Because these structures are not initialized, you may get lots of warnings on uninitialize access.
• ZeroFault has pending patents. This puts Valgrind in a dangerous position.

No debug cycle

[Per Abrahamsen]

I used valgrind for a heavy numeric program, and while it took hours to run even a simple test case, I don't consider it much of a problem given the alternative. Tracking down memory errors can take days and is extremely frustrating.

Valgrind is a program I run if I suspect a memory error, and maybe every half year just to feel safe. It is used a lot less than the debugger, as memory errors are far less common than logical errors, at least for me. But when I need valgrind, it is godsend.

And of course, the really cool thing about valgrind is that it takes no human time to use. You just type

valgrind yourprogram -your arguments

in some terminal window, and go back to working on something else. No special compile or build options, or any manual intervention needed. When it is finished, maybe next day, you read the problem repport.

Re:What's the fun in that?

[fredrik70]

printf's and such are not all bad. Sometimes you get errors that only pop up if running at full speed, not stepping through the code. I usually use the good old fprintf() and/or cerr in order to track it down.
But true, debuggers and tools such as Boundchecker does help shitloads when hunting down some stuff.

Re:Call me ignorant if you like...

[jpmorgan]

The patent on breathing was awarded to IBM last year. They make you sign license agreements when you go through customs.

Offtopic

[Dacobi]

> VisualStudio.NET bombs the Linux developer right back to the stone age.

I've seen your signature many times, but I've never understood what you mean.
What exactly does VisualStudio.NET have to do with Linux developers?

Re:Market for commercial programming tools for Lin

[jreiser]

Thank you for the suggestions.

Those who actually search for software can also look in freshmeat.net and newsgroup comp.os.linux.announce and linuxapps.com and a buyer's guide.

Re:What's the fun in that?

[ajs]

Debugging problems that you're aware of is one thing, and yes I just print status messages to find that kind of problem most of the time too. Memory checkers are more useful for finding the kinds of bugs that you don't know are there. It's a sanity check, if you will. If you run one, and it doesn't find anything, all the better!

Re:Market for commercial programming tools for Lin

[Wumpus]

True, but searching freshmeat for "profiler" doesn't bring up your project. OProfile does show up, though, so I guess most people don't go any further.

Re:Anyone Tried Mozilla with Valgrind?

[mce]

Nope. Purify works with several commercial Unices: HP-UX, Solaris, AIX, and I think even SGI's concoction. And with 'doze, of course, but who cares about those guys. :-)

Re:Too slow to always enable (correction)

[mce]

Now that I am awake again, I have to correct the above figures: please read 250 instead of 25 and 500 instead of 50. Those are the ones I meant to post in the first place anyway.

Sorry.

Definately

[adam_megacz]

Yep, I much prefer Haskell to Java. Only problem is that every time I mention it, I spend the next hour explaining what it is and why functional programming is a good idea =)

Re:What's the fun in that?

[Greg Lindahl]

I said nothing of the sort. I have tried many debuggers, and the reason that I debug with print statements is that it works. I do a lot of parallel and distributed programming; I don't make a lot of elementary mistakes when I program.

Please stop jumping to conclusions so quickly.

Re:Idiot

[mrm677]

If you are going to be a pretentious fuckhead and insult someone on Slashdot, at least use an actual account instead of AC.

Re:What's the fun in that?

[G0SP0DAR]

Not using debugging tools is only stupid when done on someone else's time. Dehumanization may not be an issue for them. This won't even matter when computers can program themselves. However, letting the computer do everything else for you is no way to impress your friends. It's called taking unnecessary risks. If you have nothing to lose, then why the hell not? If you want the same shock value as code proofed with Valgrind, try impressing a 1337 group of web designers using MS Frontpage. Never going to happen. And sometimes, doing things the hard way is the only good way to get things done.