×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

C# Memory Leak Torpedoed Princeton's DARPA Chances

Zonk posted more than 6 years ago | from the omg-a-tumbleweed dept.

560

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.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

560 comments

I'll show you mine if you.. (4, Funny)

king-manic (409855) | more than 6 years ago | (#21388563)

I'll show you my perpetual motion machines if you show me your perfect autonomous garbage collector. You go first.

Re:I'll show you mine if you.. (5, Insightful)

El Lobo (994537) | more than 6 years ago | (#21388699)

The problem was not the garbage collector if you read TFA. The articule is just a shameless plug, some ad spam for some very obscure profile.

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....

Well, there's your problem! (5, Funny)

feepness (543479) | more than 6 years ago | (#21388573)

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 may be the least effective method of debugging in existence.

Re:Well, there's your problem! (4, Funny)

johannesg (664142) | more than 6 years ago | (#21388797)

No no, that would be something along the lines of printing out the code and then throwing darts at the listing to figure out the incorrect line. I hear it is popular in Redmond, although they reputedly use chairs instead of darts.

Re:Well, there's your problem! (5, Funny)

maxwell demon (590494) | more than 6 years ago | (#21388831)

No no, that would be something along the lines of printing out the code and then throwing darts at the listing to figure out the incorrect line. I hear it is popular in Redmond, although they reputedly use chairs instead of darts.
That makes sense: Since chairs are larger than darts, you have a much greater chance to hit the bugs.

LOL??? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21388575)

LOL???

Slashvertisement (5, Informative)

shartte (1002567) | more than 6 years ago | (#21388579)

The linked "article" is just a "sponsored review" for a C# profiler...

Re:Slashvertisement (5, Interesting)

JanusFury (452699) | more than 6 years ago | (#21388607)

The sad thing is that Microsoft offers a perfectly servicable profiler for free that can be used on any C# application and is better than most commercial native Win32 profilers...

Re:Slashvertisement (3, Insightful)

ceeam (39911) | more than 6 years ago | (#21388685)

Of course it has nothing to do with differences between "managed code" and native, right?

Re:Slashvertisement (1)

moogs (1003361) | more than 6 years ago | (#21388867)

no, no, the whole point of this is to imply that m$ is teh evil1!!!!, no matter what the facts really are. You must be new here :)

Re:Slashvertisement (2, Informative)

Etrigoth (1119741) | more than 6 years ago | (#21388975)

Indeed it's a great piece of code; the only thing that puts people off is it's apparent complexity - the whitepiper that accompanies it, is a bit offputting too...

I've had my fair share of experience with ANTs and to be honest, it's been useless in my application. We load controls dynamically in an ASP.Net environment and ANTs refuses to profile them. I've been backwards and forwards with their support team, to no avail. In fact the only thing that happened was me blocking their sales rep from emailing asking if I was prepared to make a purchase yet, when it was plainly obvious it didn't work right for us!

I've had much better experience with, and strongly recommend, the .Net Memory Profiler, from Scitech software.
It's saved me so much headache :)

Re:Slashvertisement (4, Insightful)

slashdot.org (321932) | more than 6 years ago | (#21388701)

Yeah, it's kind of bizarre. I'm not part of the crowd that actually believes the /. people get anything for posting these articles.

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 ..." credit come from? Some random line towards the bottom of what appears a highly edited blurb?

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.

Re:Slashvertisement (1)

Florian Weimer (88405) | more than 6 years ago | (#21388759)

All this stuff sounds either very naive or very marketing. You choose.

Can't you just create a heap dump at two or three points in time, create a histogram of object types, look at the types whose objects are apparently growing unbound, and examine what kind of objects are pointing to such objects, keeping them alive? No need for fancy, invasive tools.

Or doesn't Microsoft's C# come with a built-in heap dump facility and some analysis/browser software? This would be a pitty because such problems do occur in practice and are rather difficult to debug without proper tools.

Tying the reboot to time elapsed, and not working set size is a serious WTF, though. Rebooting as some sort of uber-garbage collector makes a lot of sense, but you really should make sure that you do it if and only if you actually need it.

Re:Slashvertisement (3, Insightful)

WeirdJohn (1170585) | more than 6 years ago | (#21388835)

The whole 'reboot to fix it' is a methodology that we're going to see more and more of, as students who have only ever been exposed to windows platforms become more and more pervasive.

Kinda scary when they start writing systems for medical applications, industrial controllers and power supply chain management, let alone nationwide air traffic monitoring or emergency services interactions management.

  "Hang on, we have to reboot our systems every 6 hours in order to manage this natural disaster - You can be advised when the flood waters will peak in about 15 minutes - did you say the bridge is washing away, and your phone lines are about to fall down? Ring us back in 15 minutes after the systems finish rebooting"

Re:Slashvertisement (5, Insightful)

jmccay (70985) | more than 6 years ago | (#21388969)

I think this is just poor code debugging skills. The new garbage collected languages (C# and Java) seem to be creating coders that don't know the basics of debugging. If this was C++, the bug would have shown up when an event occurred and the code called a deleted object. It would have been harder to track down. In any case, I would have added code to analyze the state of the stack and it's objects since it only occurred after the program/car had been running for a while. Also, had it not occurred to them to increase the number of obstacles beyond the "controlled" environment? You can easily write test code to to add a lot of objects into the stack without the use of the car.

Our cars used an asynchronous event-based code stack written from scratch by us.
They wrote their code stack from scratch. They should have modified an existing one that was proven to work. Either way, I think this is a case of sloppy programming. I don't think it is worth mention aside from the case what the closest thing to a memory leak is that you can have. Unfortunately, that too should have come to mind from them. They ruled that out because "most of [their] code is written in garbage-collected C#". Just because a language is garbage collected, it doesn't mean you can just ignore the issues. All reference to the object must be removed for it to be deleted. This is definitely a case of sloppy programming. I would be embarrassed if my name were attached to this.

      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.

Re:Slashvertisement (1)

Etrigoth (1119741) | more than 6 years ago | (#21389001)

You make a good point, but I've just got to say that you don't need a Microsoft Language / OS / IDE to be a bad or lazy programmer.
In fact, you simply need to not bother trying to understand what you're doing :) ... and be too proud to admit it or realise it :)

Look around in Googles code search, there are some shockingly bad examples of code in any language you can think of :)

Re:Slashvertisement (1)

GrievousMistake (880829) | more than 6 years ago | (#21388909)

All this stuff sounds either very naive or very marketing. You choose.
I choose to think it's very naive of them to agree to be very obvious marketing shills.
Personally I think it reflects badly on the writer to appear so excited over being able to diagnose a simple dangling reference bug. Maybe they figured no-one would ever see it.
It's fine to have sponsors (the company in question is an official PAVE sponsor), but cheapening yourself like this.. cheapens you.

As a C kernel programmer... (-1)

Ben Jackson (30284) | more than 6 years ago | (#21388581)

...I plan to put this URL on a shirt so I can point to it whenever anyone tells me I shouldn't be writing in C because it makes me manage my own memory!

Re:As a C kernel programmer... (2, Insightful)

JanusFury (452699) | more than 6 years ago | (#21388615)

It's not as if C doesn't leak memory when you mishandle resources. All these people needed to do was spend 5 minutes with the (free) MS .NET profiler and look at the allocation and GC graphs, and they'd be done.

Re:As a C kernel programmer... (1)

aproposofwhat (1019098) | more than 6 years ago | (#21388689)

Yes, but if you spend your time coding in C, you learn (over time, admittedly) to take care to manage resources properly.

Garbage collection invites laziness and mistakes, and is generally a bad thing.

:P

Re:As a C kernel programmer... (4, Funny)

cyber-vandal (148830) | more than 6 years ago | (#21388727)

That's why there are no memory leaks in C/C++ code [/sarcasm]

Re:As a C kernel programmer... (0, Offtopic)

ozzee (612196) | more than 6 years ago | (#21388985)

That's why there are no memory leaks in C/C++ code

The last few large projects I have worked on with C++ had no issues with memory leaks on product release and these were servers that run for months. Proper use of smart pointers and correctly designed classes is not that hard. The last Java based product I worked on had all kinds of leaks and issues.

Re:As a C kernel programmer... (0)

Anonymous Coward | more than 6 years ago | (#21388647)

So you think you're better than a garbage collector at preventing memory leaks? Well, maybe you are, but the chance that that is the case (and the chance that that would actually matter) is exceedingly close to 0%. Why stop at memory management? Why not write everything in assembly? Or machine language? People who avoid using useful tools merely because those tools aren't 100% perfect are almost always arrogant idiots who will get left behind as progress marches on.

Re:As a C kernel programmer... (2, Insightful)

maxwell demon (590494) | more than 6 years ago | (#21388751)

As user of programs written in GCed languages, in my experience usually they are bad memory hogs. And don't tell me that memory is cheap. People constantly forget that we are not any more in the days of DOS, where there was essentially only one program running at any time.

Re:As a C kernel programmer... (1)

MacDaffy (28231) | more than 6 years ago | (#21388681)

I'll do the same and when people ask me what language they should use, I'll answer "Pascal."

Re:As a C kernel programmer... (2)

owlstead (636356) | more than 6 years ago | (#21388725)

In C#, the problem manifests itself as a memory leak. In C/C++ however, you would have freed the memory even while the listeners were still active. Now you have a reference to previously freed memory. I know what I would prefer. The only advantage is that - maybe - the C/C++ error would show up earlier, but the form of the manifestation might vary.

Re:As a C kernel programmer... (1)

toad3k (882007) | more than 6 years ago | (#21388851)

Well the program would have crashed. And they would have known where the problem was instantly instead of requiring a debugger.

Also, what is the point of having an explicit delete if C# just ignores it? This is asked by a person who has never used C#. If I say to delete something, delete it. The program should halt if I try to use an object that has been deleted, or at least it should halt during the next gc when it discovers something has a pointer to it.

Re:As a C kernel programmer... (1)

toad3k (882007) | more than 6 years ago | (#21388863)

Edit: Nevermind, I should have read further down the page before I commented. I guess my language biases are showing.

Ahahaha! (2, Interesting)

19thNervousBreakdown (768619) | more than 6 years ago | (#21388889)

This kind of thing makes me so happy. Sure, it's not really a bug in C#, but this is even better, a perfect demonstration of how GC does next to nothing to prevent this type of bug, and instead fools people into complacency while making the bug much more subtle.

In my opinion there is a proper language level for nearly any task. For kernel programming, drivers, or RT stuff, C. User-level stuff is usually better in C++. Well, I'm a big fan of C++ and more comfortable there so I'll usually extend its range down to some lower-level work and sometimes I'll bang out a quick-and-dirty app or script type thing (lots of user input parsing and other things C++ isn't great at) in it too, even if it could be done better (yes, better as in higher quality) or faster in another language.

Anyway, although I could be making incredibly wrong assumptions about the nature of the problem, I'm pretty sure that C# wasn't the right language for the job. C# very nicely occupies the space between C++ level languages and scripting languages, but for a problem that involves probably no parsing whatsoever (it shouldn't, anyway), needs to be perfectly stable (in my experience GC apps are buggier, I'm not going to go off on that tangent now and explain, but it's been my experience), and have as deterministic runtime as possible, it's C or a subset of C++ (little to no STL) all the way. This paragraph was brought to you by Lisp.

This problem was caused by, I'm going to go out on a limb here and say the wrong language choice. If this was C/C++, there would have been a segfault (easy to debug--usually) or the old reference wouldn't have mattered at all. C#'s real strong point, its huge and well-integrated library, probably didn't help them out very much.

Every programmer who wants to call themselves a real programmer should learn as many languages in as wide a range as possible. Sure, have favorites, but that should mean trying to work in your language's realm, not extending it way beyond its range.

Friends do not let Friends use Windows and Drive (0, Troll)

WindBourne (631190) | more than 6 years ago | (#21388585)

There is your problem. Quit using systems that yield blue screams of death (literally).

Stupid Slashdot headline (5, Interesting)

RzUpAnmsCwrds (262647) | more than 6 years ago | (#21388587)

This is a stupid, stupid article headline. Of course you can have a memory leak in a managed language! Any Java programmer who's decent understands that.

It's not C#'s fault. The team had references to the obstacle list (event handlers), which prevented garbage collection. The .NET CLR did its job, just like it was supposed to.

Re:Stupid Slashdot headline (3, Interesting)

dgun (1056422) | more than 6 years ago | (#21388637)

Maybe so. But if they explicitly call delete to invoke the garbage collection of an object, would it not be better for the system to destroy the object and then throw an exception when it tried to send an event notification to a non-existing object?

Furthermore, if delete is called and the garbage collector does not delete the object because it realizes that the object is registered on certain events, would it not be just as easy to then un-register the object for the event? Or at least report it? After all, the GC already went to the trouble of checking to see if the object was registered with an event notification.

Re:Stupid Slashdot headline (4, Interesting)

cnettel (836611) | more than 6 years ago | (#21388755)

There is no explicit delete in C#. They may have added something in their framework, or they're just saying that they called delete on the collection where they thought they stored all objects. The GC isn't psychic. (It could be a good thing to ask the GC to delete an object explicitly and get an exception if it's indeed still referenced elsewhere, but that's not possible in C#, or Java for that matter.)

Re:Stupid Slashdot headline (5, Insightful)

blowdart (31458) | more than 6 years ago | (#21388789)

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.

Re:Stupid Slashdot headline (0)

Anonymous Coward | more than 6 years ago | (#21388813)

Hence the explicit part. TBQH something can probably be hacked together in .net 2.0 w/ reflection etc. to "make" the GC delete an object, even if you can't remember if it's subscribed to any events..

Re:Stupid Slashdot headline (3, Insightful)

multi io (640409) | more than 6 years ago | (#21389081)

You could just use weak references (does C# support that?) for all references that the event sender uses to reference its event receivers. In that case, as soon as a receiver has been removed from all those "obstacle lists" and all other objects that held references to it, the weak reference would be the only reference pointing to the receiver, which would make the receiver eligible for garbage collection.

Re:Stupid Slashdot headline (3, Insightful)

MathFox (686808) | more than 6 years ago | (#21388653)

I do think that this "object lifetime" bug is NOT a memory leak, but that does not change the effects (crash) of the system.
What is interesting is to see that garbage collection changes one class of bugs (forgetting to explicitly deallocate memory) to another one: unintentionally keeping objects around. Princeton's "obstacle object" lifetime policy was stepped upon by a Dotnet library; Java has similar problems in its libraries. For the Princeton car software, an explicit deallocation routine (like in C/C++) would have been easy to implement.

Problem is that both C/C++ style memory leaks and C#/Java hidden reference bugs usually remain hidden until the system crashes or trashes after some time. It makes them hard to find in the course of ordinary testing.

Re:Stupid Slashdot headline (0)

Anonymous Coward | more than 6 years ago | (#21388837)

Quite... imagine my disappointment when reading an article whose title suggests every mug using C# is going to get hit with a problem they have no control over and no way to fix whereas in fact it's just a classic programming error in a single app. It's like y2k all over again for me. No flames, no explosions, just one lousy program telling me the year is 19100.

One interesting facet to this, though, is that although GC languages are touted as safer, the consequences can be just as dire as others; here you have a potentially life-threatening machine running about without much control because it's getting slower and slower either because it's started paging or just got to traverse so many references each time it has to make a decision. No fail-safe kicks in because everything's working and so this alzheimer's death machine winds up running people over after 40 minutes of operation.

Compare the equivalent in C/C++: the programmer explicitly frees the memory and as soon as the object is referenced after the program is killed. Failsafes then kick in so you don't have a bunch of students running after a rogue machine trying to pull the plug whilst avoiding its twin anti-aircraft cannons or whatever.

Re:Stupid Slashdot headline (5, Insightful)

slashdot.org (321932) | more than 6 years ago | (#21388833)

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++.

Re:Stupid Slashdot headline (1)

nwbvt (768631) | more than 6 years ago | (#21389037)

Just because garbage collection doesn't prevent memory leaks doesn't mean that it isn't a good thing. It does make them harder to create. And given the level of skill the average programmer has, anything that makes memory leaks less likely (though not impossible) has got to be seen as a good thing.

Re:Stupid Slashdot headline (0)

Anonymous Coward | more than 6 years ago | (#21388861)

I agree. It's ridiculous how the summary tries to spin this so it seems like a C# bug.

But it turns out it was a bug in an application which happened to be written in C#. The garbage collector worked as advertised. If an object can still be accessed (in this case through an event handler) then it cannot be garbage collected (even if the event handler isn't actually called). It's unfortunate if Princeton's students didn't realize this, and I'm sorry for them, but in no way is this a bug in C#. A program written in Java would exhibit the same behaviour.

In contrast, thousands of applications written in C and C++ contain memory leaks. They never make the headlines. It may be a surprise to some naive programmers who think that a garbage collector could solve all their memory bugs, and even if this is an interesting case study, I do not think it qualifies as "news".

C# Garbage... (1)

dgun (1056422) | more than 6 years ago | (#21388591)

collection

because the objects were still registered as subscribers to an event, they were never getting deleted.

I wonder if the Java garbage collector does this also?

Re:C# Garbage... (1)

elFarto the 2nd (709099) | more than 6 years ago | (#21388621)

More than likely. Basically they're saying "C# didn't garbage collect objects that were still in use!", which is quite obvious. I've been caught out a couple of times by not thinking through which object have references to other objects, and end up leaking memory. Other times I've come across bugs in the JDK where a class refuses to let go of an object, causing a leak (In fact, it was something todo with the focus manager IIRC, keeping a reference to a GUI component that I had disposed of).

Regards
elFarto

Re:C# Garbage... (2, Informative)

JanusFury (452699) | more than 6 years ago | (#21388629)

It would have to, because otherwise you could register an anonymous class or other similarly constructed object as an event handler, release all your other references, and the GC would collect it while it still needs to be able to recieve messages. (That, or the GC would unregister the event handler, which would be utterly mysterious to debug if you didn't already know the intricacies of the GC, especially since you have no way of predicting when your event handler is collected).

This problem is actually less drastic in C#, since you have the ability to instantiate anonymous methods (delegates) instead of anonymous classes when doing event handling, and they have lower overhead. So even if you mess up your resource management, it's still much easier to control your resource usage because you have access to cheaper primitives to work with.

Re:C# Garbage... (1)

dgun (1056422) | more than 6 years ago | (#21388715)

because otherwise you could register an anonymous class or other similarly constructed object as an event handler, release all your other references

Oh. * scratches head *

But in this case, they were asking the GC to destroy the object. So why could that not be a special case?

Computerz are hard.

Re:C# Garbage... (1)

cnettel (836611) | more than 6 years ago | (#21388777)

They did no such thing, because there is no such thing in C#. They might have implemented IDisposable and called Dispose, but then they had done it incorrectly if the event handlers still worked...

Re:C# Garbage... (4, Informative)

Weedlekin (836313) | more than 6 years ago | (#21388865)

As is the case with Microsoft's GC, Java's won't delete things that are still being referenced by other things, because it quite reasonably assumes that an object which is referenced by another object that hasn't itself been marked for collection isn't garbage.

The main problem with garbage collectors (I like GCs, so this isn't a diatribe against them) is that far too many mediocre programmers assume they have a magical ability to know precisely what they want their code to do. The reality of course is that they use algorithms to decide what should be collected, when it should be collected, and how it should be collected, and those who are unfamiliar with the particular strategies that their GC uses can therefore not only write code with more than a few memory leaks, but also code that results in the GC being used so inefficiently that it does vastly more work than would be necessary if the same functionality was implemented in a slightly different way.

There are plenty of articles about Java memory leaks that can be found by Googling "java memory leaks". Googling "java GC tuning" will produce some useful links to articles containing tips on ensuring that it's not used inefficiently.

Re:C# Garbage... (0)

Anonymous Coward | more than 6 years ago | (#21388955)

In Java you can use WeakReference which were created for use in things like listener and subscriber patterns.

The C# dispose method is for cleaning up unmanaged resources. Memory is a managed resource and the GC takes care of that. Using dispose also presupposes that you know what you are doing since using such an object after it has been disposed is going to cause bad things to happen when you try to use those disposed resources, much like using a deallocated object in an unmanaged language will cause bad things to happen.

This just proves the saying that if you try to make something idiot proof, the world will create a better idiot.

no one claims C# prevents wasting memory... (3, Informative)

saurik (37804) | more than 6 years ago | (#21388597)

Just because a language is garbage collected doesn't mean you can't "leak" memory (in the more standard definition of "waste memory over time"), it only means you can't completely lose track of references to objects (which is often used as a more technical definition of "leak"). It is quite common for people coding in such languages to accidentally generate live object structures that are mostly made up of garbage that they should have released their references to. Put another way: these people's program was legitimately claiming memory and never releasing it due to their limited understanding of how event handlers work.

Re:no one claims C# prevents wasting memory... (1)

someone1234 (830754) | more than 6 years ago | (#21388733)

Well, it seems like these event handlers need to be reworked so people who "don't care with pointers" can use them effectively.
I personally prefer using C++ with Valgrind not some fancy language with garbage collection.

This is not a C# memory leak! (5, Informative)

Tim C (15259) | more than 6 years ago | (#21388601)

This is a programming error, plain and simple. From TFA:

Though we thought we had cleared all references to old entries in the list, because the objects were still registered as subscribers to an event, they were never getting deleted.

So references were held to the objects in two places - the list of encountered obstacles, and the list of event subscribers. They were being removed from the list of encountered obstacles, but not being unsubscribed from the event.

How do you think event subscription works? Something has to hold a reference to the objects that are subscribed to the event! That thing is going to hold a reference until you unsubscribe the object - it neither knows nor cares about any other list of references you may be maintaining separately, how could it?

This is a coding error. A subtle, non-obvious one perhaps, but a bug nevertheless. It is not an error in the CLR, and in fact the article never paints it as such. That particular bit of spin is wholly down to the submitter.

Hard/weak references for event handlers (4, Interesting)

djinnn (1064652) | more than 6 years ago | (#21388677)

I see quite a few comments from C/C++ coders who wonder whether managed memory people know how event handling works. If they knew a little more about managed memory languages, they'd know a reference does not have to be "hard": you can have a reference to an object that does *not* prevent garbage collection.

So I guess the real question here is whether event handlers should be hard-referenced (as they are here), or just soft/weak referenced...
From a developer perspective it's quite natural to think that, as long as his code doesn't hold any reference to an object, it should be garbage collectable. If registerEvent() shall hard-reference handlers, documentation should be *very* explicit about it (and the need to unregister a handler for GC to work on it).
On the other hand, if handlers are not hard-referenced you can no longer register anonymous class event handlers...

Re:Hard/weak references for event handlers (5, Interesting)

tgd (2822) | more than 6 years ago | (#21388929)

Weak references also incur the overhead of a check on every call to ensure the object hasn't been cleaned up. This was sloppy, poorly tested code. The engineers on it made a mistake and caught it too late. It happens.

The poster of the article was trolling, and not only trolled with the post, managed to get a troll posted to a slashvertisement which was not even trolling.

Impressive on the part of the person who submitted it, but disappointing considering Taco's comments a few weeks back about articles that are truly nothing but advertisements.

3 seconds with valgrind (0, Flamebait)

nyet (19118) | more than 6 years ago | (#21388603)

AND there's no need for this "trial" version bullshit.

What a bunch of noobs.

Shasdotvertisiment at is best (3, Insightful)

mariuszbi (1113049) | more than 6 years ago | (#21388605)

I've RTFA, is wasn't a memory leak caused by C#, is was caused by bad programming. After that,the whole article starts to advertise some obscure profiling tool. Maybe they should should have written the whole thing in C++ and use valgrind instead. Just an ideea...

Re:Shasdotvertisiment at is best (1)

Jartan (219704) | more than 6 years ago | (#21388747)

Was there somewhere that something claimed it was a leak caused by C#? I think this was more of a "Oh look garbage collection doesn't save you from crappy memory mangement after all". Something all of us who have a clue already knew.

Pretty useless point to make though. People aren't using C# for memory management. They are using it because Microsoft basically no longer does any worthwhile C/C++ gui development.

Re:Shasdotvertisiment at is best (0)

Anonymous Coward | more than 6 years ago | (#21388927)

Headline: C# Memory Leak Torpedoed Princeton's DARPA Chances

Re:Shasdotvertisiment at is best (3, Insightful)

Bill Dog (726542) | more than 6 years ago | (#21388757)

...the whole thing in C++ and use valgrind instead.

Or better yet, in C++ and use the RAII idiom. I.e. utilize the power of deterministic destruction, that C# and Java lack, to arrange it so that resources, including but not limited to just memory, are auto-freed. (You *can* run into this same kind of problem using reference-counted smart pointers in C++, but happily much of the time they aren't needed.)

Re:Shasdotvertisiment at is best (1)

MikkoApo (854304) | more than 6 years ago | (#21388999)

utilize the power of deterministic destruction, that C# and Java lack, to arrange it so that resources, including but not limited to just memory, are auto-freed.
That is incorrect. Java has had WeakReference [sun.com] since 1.2 release which was in 1998.

Weak reference objects, which do not prevent their referents from being made finalizable, finalized, and then reclaimed.
The catch is that all code registering disposable objects like events and listeners should use references or objects which use refences, like the WeakHashMap [sun.com]. Sometimes getting that kind automation to work _right_ requires a bit of thought though but abstracting the functionality behind a suitable interface makes things easier to figure out. A generic Eventbroker which uses a Map to hold eventlisteners would enable easy switching between gc'ed (WeakHashMap) and non-gc'ed (any other Map) functionality.

Re:Shasdotvertisiment at is best (0)

Anonymous Coward | more than 6 years ago | (#21389021)

I'm not that familiar with RAII, but isn't that for 'allocate at procedure start and deallocate at procedure end' drudgework, and useless for things like keeping a variable set of allocated objects which are also referenced elsewhere?
I don't see how it would apply for the problem described in the 'article', care to go more in detail?

Re:Shasdotvertisiment at is best (2, Informative)

HangingChad (677530) | more than 6 years ago | (#21388763)

I've RTFA, is wasn't a memory leak caused by C#, is was caused by bad programming

We've had similar trouble trying to build big systems on an MS platform. Stubborn memory leaks that don't seem to have a common cause. It's happened in VB and C#. You can't blame them all on bad programming because we've had similar problems from completely different groups of programmers with varying skill levels. We build mainly web apps and this was a desktop app but their description was strangely familiar.

It's pretty callous to blame the programmer when they trust garbage collection to do its job. That was one of the big selling points of the whole .NET framework from day one. This great tool that manages memory for you. Like a lot of what MS sells it turned out to me more of a false sense of security.

Hotfix from Tech Support! (1)

Sun Tzu (41522) | more than 6 years ago | (#21389079)

Ok, so the headline is bogus...

But what a lost opportunity for a Reboot Fix, in the grand tradition of MSware throughout history. Just think, an automatic reboot for your robot car, plane, spaceship... and it just keeps going! (or, more properly, starts going again -- now, where was I?)

Serves them right... (0, Flamebait)

Anonymous Coward | more than 6 years ago | (#21388619)

For attempting to use Windows to drive a car. What? are they fucking crazy?

Categorization of Resource Management Issues (3, Funny)

mr_mischief (456295) | more than 6 years ago | (#21388635)

This section totals 15 points.

Background:

There are more types of resource leaks than just memory leaks. A memory leak is when your program keeps hold of memory it's not using. An object leak is when your program keeps hold of objects it's not using. A file descriptor leak is when your program fails to reuse the descriptors for files it has closed and will not reopen. Many other types of leaks could be considered.

Exercises:

  1. Determine which issue this scenario describes.
  2. Figure out which issue can be handled by automatic memory management.
  3. Discuss whether, and if so why, the answers to Exercises 1 and 2 mean there is some conceptual discord between the wording of the scenario and the use of the term "memory leak".

stop programming hardware, please! (1)

QuantumG (50515) | more than 6 years ago | (#21388639)

Wow. This is just totally incompetent. I know you're students and all and have no real world experience, but this is just frightening. Stay away from the hardware please, you'll get someone killed one day.

After (0, Troll)

EEPROMS (889169) | more than 6 years ago | (#21388657)

hundreds of man hours and a few hundred thousand dollars we have finally put our finger on the problem "It was written in Microsoft's C#"...

c#? (3, Interesting)

nekozid (1100169) | more than 6 years ago | (#21388665)

I don't see why they just didn't write it in C.
They were using massive cooling systems and having very thorough code reviews, sounds like a perfect reason to use C over C#.

Re:c#? (0)

Anonymous Coward | more than 6 years ago | (#21388791)

If they made an error this stupid when writing C#, how do you expect them to even begin writing C code?

Why MS Windows? (1)

belmolis (702863) | more than 6 years ago | (#21388667)

The immediate problem here was evidently a programming error, not a bug in C#, but I do wonder why they are using C# for this. That forces everybody involved to use MS Windows and eliminates the possibility of hacking the system if they need to as well as the source as documentation. If they want a C-level language with garbage collection, why not Java or D or any of several others?

Re:Why MS Windows? (1)

GrievousMistake (880829) | more than 6 years ago | (#21388817)

Sounds like a software developer's decision, picking the language/environment you're familiar with rather than the one appropriate for the job. You wouldn't normally make a control system that depended on a specific OS that was expensive and unsuitable for embedding.
"If only we'd studied cybernetics..." is more like it. At least, I don't think they teach cybernetics with C# anywhere, but who knows what kind of crazy things they get up to at Princeton.

only 10KLOC? (4, Interesting)

basiles (626992) | more than 6 years ago | (#21388673)

What surprises me most is the small size of their software, only 10 thousands lines of source code (I think that the average car processor already have these for today's cars -ignition & braking systems-). Given a team of a dozen programmers working for a year, I was expecting at least 50KLOC, or maybe 200KLOC (for example, the GCC compiler is 3MLOC, and the linux kernel has comparable size.)

Of course memory leaks can happen with garbage collected languages, but these leaks are a little easier to find....

Maybe they should have coded in a higher level language like Ocaml, Haskell.

And yes, I'm sure most of an autonomous vehicle software is not low-level drivers, but in the planification & perception tasks. On such tasks, higher-level languages definitely make sense.

I also did not understood what kind of libraries these teams are using.

I'm also surprised that it is apparently so easy to get funded to have only 10KLOC inside a car!

Re:only 10KLOC? (0)

Anonymous Coward | more than 6 years ago | (#21388787)

What surprises me most is the small size of their software, only 10 thousands lines of source code (I think that the average car processor already have these for today's cars -ignition & braking systems-). Given a team of a dozen programmers working for a year, I was expecting at least 50KLOC, or maybe 200KLOC

And there you have it, ladies and gentlemen, the type of attitude that is behind the vastness known today as Windows Vista.

Nothing new here move along....OH Wait? (2, Funny)

Anonymous Coward | more than 6 years ago | (#21388719)

Just like most windows machines it bogs down and starts crashing after about 40 minutes of hard use.

Re:Nothing new here move along....OH Wait? (0)

Anonymous Coward | more than 6 years ago | (#21388941)

Wow, another /. anti-Windows comment. !Hilarious as usual.

The other other problem here (1)

Dachannien (617929) | more than 6 years ago | (#21388769)

There's one other huge huge glaring problem here. You have a system with real-world dangerous consequences that is dependent upon the continued proper operation of the software. When the software fails, the hardware apparently has no safe failure mode. This is a serious no-no in system design where improper operation of the hardware could create a hazard.

It's easy to solve. The hardware should be designed with a watchdog timer that, if it ever expires without being reset, triggers a failsafe mode such as releasing the throttle and applying the brakes. Each mission-critical thread should be required to regularly notify a watchdog thread that it is still running, and the watchdog thread sends the watchdog reset signal to the hardware if all of the mission-critical threads are still running. If any thread exits inappropriately, enters an infinite loop, or otherwise stops being able to respond at an acceptable rate, the watchdog timer times out, and the vehicle stops.

I realize that there is a manual system for stopping these vehicles if something goes awry, but as several teams found out the hard way, safety is absolutely paramount. Belt-and-suspenders is the way to go.

C# does have direct memory pointers (1)

alancjohnson (1166659) | more than 6 years ago | (#21388805)

C# does have the facility to use direct memory pointers. The memory these pointers point to is never garbage collected. They are mostly used when access to unmanaged code's object is required i.e com and dcom.

Not saying they were using these, but pointing out that the .net garbage collector doesn't clean everything.

Stupid slashvertisement (1)

Alkonaut (604183) | more than 6 years ago | (#21388847)


Lots of bashing about their design decision to use C#, about C# in general and so on. Their decision to use C# seems perfectly logical. Using a high level language to me seems like the ideal choice when writing complex control code. Perhaps a functional language could be even better. .NET will allow you to even mix languages as much as you want.
I would have used a modern high level language (java, c# or a specialized language) for the high level control, and I assume that the lower level code device driver and control was written in, for example, c. Makes perfect sense. The fact that the code is described as containing only 10k lines of code just makes the point even more clear. Use the right tool for the job. Use several tools if you need to.



The crash they experienced was because they didn't pay attention to their references properly. Garbage collection isn't any more magic than manual memory management. If you are sloppy the program will fail. The CLR worked exactly like it is supposed to. Unfortunately the fact that having an event handler on an object means that you are referencing it, is sometimes overlooked. If they had been as sloppy while using c/c++, they would have gotten some other problem instead, but the program would have crashed all the same. All this (slashvertisement!) shows is that doing memory profiling and long test runs is important, regardless of which language you have used.

Re:Stupid slashvertisement (0)

Anonymous Coward | more than 6 years ago | (#21388981)

You'd think that, but that's because you're a software developer. Any OS you can run C# on would probably not be a good choice for this system, though I can see using Linux for ease of development. Ideally though, a vehicle control system should have real-time capabilites and excellent fail-safe capabilities. AFAIK, that means no Windows and no C#.
The fact that a simple memory leak caused the program "slow down until the car just simply stopped responding" just makes the point even more clear. That's not the right tool for the job. If they had been somewhat competent and knowledgeable about control systems, a program crash wouldn't have been a fatal error.

don't these kids learn anything anymore? (5, Interesting)

m2943 (1140797) | more than 6 years ago | (#21388857)

(1) You are supposed to test your software.

(2) You are particularly supposed to test your software if you send $200k and 1 ton of hardware careening through the street on autonomous real-time control.

(3) Garbage collectors do not prevent memory leaks.

(4) Garbage collected systems can be good for building real-time systems, but you need a real-time garbage collector or you need to treat the system as if it didn't have a garbage collector at all.

What "ruined their chances" was not that they overlooked a memory leak, what ruined their chances was that they didn't know what they were doing.

I think they just learnt something (3, Informative)

driddint (928814) | more than 6 years ago | (#21389013)

They did do testing - (1) above - because they knew there was a problem that they could repeat. They just tried to pretend it wasn't happening.

... Because we didn't know why this problem kept appearing at 40 minutes, we decided to set a timer. After 40 minutes, we would stop the car and reboot the computer to restore the performance. ...

They also didn't pick a very good hack because it didn't leave the car in a safe state when the software broke.

Lack of practical experience I'd say. A few more events like that and they'll make decent devs one day.

Re:don't these kids learn anything anymore? (2, Insightful)

MajorCatastrophe (662787) | more than 6 years ago | (#21389035)

What "ruined their chances" was not that they overlooked a memory leak, what ruined their chances was that they didn't know what they were doing.

Whereas code written by people who "know what they're doing" has zero bugs - ever. Right. And to assert that they didn't test their software is ludicrous.

Another similar Problem... (4, Informative)

Raven737 (1084619) | more than 6 years ago | (#21388891)

Well the Event Subscribed 'problem' is well known and makes sense if you think about it. I mean subscribing to an Event means placing a pointer to a delegate of a method in a event subscriber list.. when someone raises that event then each delegate in the list is invoked... so basically it is an implicit reference and hence can prevent the it from being marked for garbage collection.

However, i had another memory 'leak' problem where the Garbage Collector simply didn't collect in time which caused my application to use more and more memory until it reached the system limit and crashed... i found that simply calling
GC.Collect();
GC.GetTotalMemory(true);// (the true 'forces' collection ;)
once would fix this problem... i though i needed to call it every minute or so... but when calling just once it did SOMETHING that prevented this problem from occurring again.. no idea exactly what.. but it works :)

Why allocate memory on the fly? (1)

metalmario (717434) | more than 6 years ago | (#21388907)

Instead of doing lots of news and deletes on the fly, why not allocate enough memory when the program starts and use that instead? That way you won't fragment your memory pool either, or have those age long garbage collection sessions. Anyway, the topic of today is bad programming, move on, nothing to see here.

One word (0)

Anonymous Coward | more than 6 years ago | (#21388921)

Spit!

Blatant slashvertisment and also a misleading title trying to blame stupid programmers' mistakes on Microsoft and C#. Spit! Spit! And... spit!

A managed leak (1)

Caesar Tjalbo (1010523) | more than 6 years ago | (#21388923)

It was the closest thing to a memory leak that you can have in a managed language.
That's one way of putting it, I'd say if your code drives off in a car it's hardly a "leak" and certainly not "managed".

In other words (0)

Anonymous Coward | more than 6 years ago | (#21388925)

After being convinced by salesmen telling it will solve all your problems, you spend money on a proprietary development system/language coming from a company well known for anticompetitive practices and tied to a closed platform. Then, when your code bites you in the ass, someone tells you another proprietary software would have solved all problems, and you're forced to waste more money. Sounds familiar?
Of course it does! It's the L. Ron Hubbard way of doing business, applied to the IT field.

No thanks, I'll stick with GCC: it's way more productive than the above stuff, unless one thinks productivity is just a matter of doing the same thing in two lines of code instead of five, regardless of performance, optimization, peer reviewing, being in control of what the software does, etc.

It a coding error. But C# dumbs down coders. (0, Troll)

140Mandak262Jamuna (970587) | more than 6 years ago | (#21388957)

Looks like they can't directly blame C# for not releasing memory while they are still holding references to the supposedly deletable objects. But I have seen appallingly low understanding of OO principles among the candidates I interview who had grown up in C# environment. My big grouse is that even in C++ Visual Studio and .NET IDEs inhibit a big "picture" understanding of large and complex code. The number of times I had to berate newbies for including afx.h in a "platform independent" base class headers ...

Swing (3, Informative)

Tim Ward (514198) | more than 6 years ago | (#21388997)

They can't have had anyone on the team with experience of coding for Swing in Java then - you get these all the time, sometimes hanging tens of megabytes of unwanted GUI objects off a single listener registration, and learn how to spot and fix them.

Designed for safety ? (2, Insightful)

Ihlosi (895663) | more than 6 years ago | (#21389009)

usually with the gas pedal down, and would just drive off into the bush until we pulled the plug.

Yikes. So these guys have the smarts to make a computer drive a car on its own, but managed to forget some basic safety mechanisms such as a watchdog and other failsafe mechanisms ?

Geez guys - real world engineering 101: Do not let a computer control anything that might have a remote chance of harming someone without appropriate safety mechanisms.

Repeat after me (1)

nwbvt (768631) | more than 6 years ago | (#21389019)

Every half way decent programming language will allow you to leak memory.

Its trivial to show this as long as the language supports some sort of array. Garbage collection is useful, but it does not save you from memory leaks. I don't know how many times I've told some retard JavaScript "programmer" that yes, they do have to be mindful of memory leaks even though their language has a garbage collector.

but did they end up buying the software?! (0)

Anonymous Coward | more than 6 years ago | (#21389045)

I'm not convinced that the company got any cash out of the coders given it exposed the problem straight away...

Holly Crap! Manslaughter 101 (1)

MasterOfGoingFaster (922862) | more than 6 years ago | (#21389051)

From TFA:

"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."

Whatever issues the software guys had, the hardware control guys are the real story. They designed a machine that they KNEW would run out of control with potentially deadly results. If it had run over someone, these guys would surely be arrested for manslaughter. Now imagine they can't "pull the plug" because they dropped the remote control, AA batteries died, got out of range, etc. Now you have a out of control truck heading for that group of Boy Scout hikers, a highway or other contestants.

Who the hell was supervising these students? I want to make sure I don't hire anyone from THAT school.

yeah. sure. (0)

Anonymous Coward | more than 6 years ago | (#21389057)

It is a poor carpenter that blames his tools.

Ob. Eric Sink quote (1)

MK_CSGuy (953563) | more than 6 years ago | (#21389075)

A nice quote from Eric Sink's Source Control HOWTO [ericsink.com]:

Recently when I asked my fifth grade daughter what she had learned in school, she proudly informed me that "everyone in Korea eats kimchi at every meal, every day". In the world of a ten-year-old, things are simpler. Rules don't have exceptions. Generalizations always apply.

This is how we learn. We understand the basic rules first and see the finer points later. First we learn that memory leaks are impossible in the CLR. Later, when our app consumes all available RAM, we learn more.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...