C# Memory Leak Torpedoed Princeton's DARPA Chances
nil0lab writes "In a case of 20/20 hindsight, Princeton DARPA Grand Challenge team member Bryan Cattle
reflects on how their code failed to forget obstacles it had passed. It was written in Microsoft's C#, which isn't supposed to let you have memory leaks. 'We kept noticing that the computer would begin to bog down after extended periods of driving. This problem was pernicious because it only showed up after 40 minutes to an hour of driving around and collecting obstacles. The computer performance would just gradually slow down until the car just simply stopped responding, usually with the gas pedal down, and would just drive off into the bush until we pulled the plug. We looked through the code on paper, literally line by line, and just couldn't for the life of us imagine what the problem was.'"
This just tells us once again that our wonderful editors on /. don't even try to understand what's behind an article, but they just find some sensationalistic title (the more AntiMS, the better) and done. This results in more comments of the type... "See, M$ id teh SuCkS", or "thanks god for my Linuzzz."..., so they got more profit for their /. ads (oh, the irony often MS ads, BTW).
Yellow press..... yes, I know, /. is not supposed to have any credibility like any other parasite news sites, but anyway....
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
Yeah, it's kind of bizarre. I'm not part of the crowd that actually believes the /. people get anything for posting these articles.
/.
..." credit come from? Some random line towards the bottom of what appears a highly edited blurb?
But I do believe that articles written by companies pretending to be written by end-users are not terribly useful and probably shouldn't end up on
I mean, the article clearly states at the top "By Red Gate Software.".
So where did the "Bryan Cattle reflects on
Seriously.
"One of our team members downloaded the 14-day trial of ANTS Profiler"
"To our amazement, it was only minutes before we realized that our list of detected obstacles was never getting garbage collected"
"If Only We Had Used It Earlier..."
ANTS Profiler helped us fix a problem in minutes that would have taken us weeks to track down. If only we'd thought of it before the competition, we would most likely have finished the entire race and had a chance at the top prize money.
All this stuff sounds either very naive or very marketing. You choose.
I think you're getting hung up on the method name. There is no standard "delete" function that marks something as unused (dispose on the other hand sort of gets there). The article itself is unclear but I would assume that they were simply deleting the collision objects from a collection of potential hazards. Whilst that would remove the object from the collection itself it is *not* a delete. As references to the object existed elsewhere the object still exists (look ma, no null pointer exceptions) no delete happens. You cannot specifically say to the GC "We're done with this, delete it", the GC sweeps on a regular basis looking for objects with no references.
Would you really want the GC deciding that just because an object is no longer part of a collection it's safe to unsubscribe it from events and delete it? I know I wouldn't.
Of course you can have a memory leak in a managed language! Any Java programmer who's decent understands that.
Decent programmers might understand that, but let's be honest, it's not like Java (and other GC languages) haven't been presented as if memory leaks were a thing of the past.
As a matter of fact, some people will probably still claim that it's technically not a memory leak, but instead an object life-span issue.
What surprises me is that outspoken proponents of managed languages use the garbage collection so often as a good thing, as if now you can be a sloppier programmer and get away with it.
In reality you have to identify/control the lifespan of objects anyway, so I personally never understood what the big deal is about freeing memory manually. Not to mention that memory leaks in say, C++ code, really aren't that hard to find. The tools have become pretty freakin decent.
And also not to mention that garbage collection might be handy for memory, but memory is only one of a plethora of resources that can be leaked. And since for many resources it isn't nearly as appropriate to 'lazy' free them, as a programmer you still have to be aware of the allocate/free paradigm. (as just one silly example, it would suck if you wouldn't be able to explicitly close a file, because you can't delete it before it's closed)
In other words, you are right. Of course you can have memory leaks in garbage collected languages. And I wish people would stop using GC as an argument why languages as Java are so much better to use than C++.
Some old Visual Basic programmer jokes come to mind when I read this article. People use to make fun of Visual Basic programmers because it was to easy to write programs in VB. They thought it would produce sloppy code with errors, and other similar things. To some extent, it appears that same case could be made for C#, and to a lesser extent Java. In the end this is simply a case of not stress testing their event stack.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
Agreed. I was a good VB programmer. But my VB experience was an eight-month interval between C++ jobs. I've knocked out minor MS Office applications when needed since then, but that's it. I'm sorry to say that most of the VB programmers I've worked with were very poor engineers. Admittedly I've not worked in VB for wealthy companies whilst I have in C++, so that colours things somewhat. I don't doubt that there are some good VB programmers out there. But in the cases of most of those I worked with, I could very clearly see how VB led them to be poor engineers. The amount of shortcuts and wizards and instances where they would start their program by dragging a form object onto the design panel and dumping form objects onto it was obviously a leading reason for their poor skills. VB *led* them to take this approach. It works for small Excel apps, barely for database front-ends and not well at all for large projects.
As is common with the lower end of Microsoft products, the selling point is that they make it very easy to do what they think you want to do. The ability of VB to knock out an interactive form with near-zero knowledge of programming has encouraged a lot of colleges to sell people the idea that a ten-week course of dragging and dropping text box objects is programming whilst a lot of cheap or ignorant employers have taken the graduates at their word and plunged them in over their heads.
VB is a poor language in many ways and not, imo, suited to a large or sophisticated project. But you can find good VB programmers (was one). It's just that it encourages bad ones.
Oh, the summary is also wrong. C# hasn't started springing leaks. The programmers missed a reference to objects that they were creating and the garbage collection therefore never triggered to unallocate the memory. I don't doubt it's not easy to automate a vehicle to drive any even 9 miles, but this could have been detected with more thorough debugging. At any rate, the article submitter and overseeing editor should be ashamed of twisting this into an anti-Microsoft jab. I'm a Linux programmer. I can tell you that Linux can compete happily without sinking to the level of lies and misinformation.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
Fuck. You are so right. This article is just some advertisement for some obscure profiler.
However I take exception to your use of the world "Editor". Slashdot does not have Editors. They have guys who accept submissions.
They don't read The Fucking Articles, They don't check links, The don't edit submissions...
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
Slashdot editors are even more pathetic than I thought they were. It's bad enough that they didn't skim through the article, but they apparently didn't even take a look at the URL. Look at this thing:
http://www.codeproject.com/showcase/IfOnlyWedUsedANTSProfiler.asp
"IfOnlyWedUsedANTSProfiler"? That didn't raise any flags?
Of course, I'm trying to assume good faith and not just conclude that the editors knew this was an advertisement, but they sure are making that difficult.
Come on. Really. What kind of idiot marketer sends in stories like this to Slashdot? We know what happens. First, you get derided mercilessly for trying to sway us with your ridiculously transparent attempt at marketing. Then, the real experts come out and poke holes in everything you've said. Then everyone else chimes in with better (and often free) alternatives. You and your company end up looking like buffoons, and your product ends up looking like utter garbage.
You may think you're pulling one over on the editors, and maybe you are. But you aren't pulling one over on us, and I think after all these years, the editors know this. So, just don't. Unless your product or service is absolutely bulletproof people here are more likely to shoot it full of holes than rush out and buy it.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
...
O.K., I'll bite, what part of that line do you not understand? If /. billed itself as a "blog" then I'd understand your point. However, /. is a corporate based, self-billed "News" site. Whether reader submission driven or not, it is a news site. You are wrong. But, thanks for your thoughts.
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
It's amusing to see that there are still people who believe in the old "more lines of code means better performance".
Seriously, the performance of these cars is amazing, a huge step from just a few years ago. The hard part of this project was certainly not the programming, but the concepts behind the obstacle detection and such. This is not an implementation exercise, but more of an academic experiment to test out new ideas.
(Nice work on mentioning Haskell to guarantee an upmod btw.)
Hey, here's a wacky idea that's just crazy enough to work - DON"T USE DYNAMIC MEMORY ALLOCATION! Why in holy hell would someone construct what amount to an embedded real-time system using dynamic memory. Define fixed memory allocations for everything. Run tests. If the memory is insufficient, the program crashes. Then you can see where the program crashes and why. Then you can fix it.
Just because you *can* do something doesn't mean you should.
Brett