Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

C# Memory Leak Torpedoed Princeton's DARPA Chances 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.'"
This discussion has been archived. No new comments can be posted.

C# Memory Leak Torpedoed Princeton's DARPA Chances

Comments Filter:
  • by king-manic ( 409855 ) on Saturday November 17, 2007 @06:25AM (#21388563)
    I'll show you my perpetual motion machines if you show me your perfect autonomous garbage collector. You go first.
    • by El Lobo ( 994537 ) on Saturday November 17, 2007 @07:03AM (#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....

      • by bhima ( 46039 ) <Bhima.Pandava@gmail. c o m> on Saturday November 17, 2007 @10:32AM (#21389587) Journal
        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...
        • by nil0lab ( 94268 ) on Saturday November 17, 2007 @07:02PM (#21393137)
          Slashdot has editors. I know this, because the stuff below "nil0lab writes..." is heavily editted from what I actually submitted! In fact, I started my actual submission with something like "in a shameless plug for some code analysis product..."

      • in the URL (Score:5, Insightful)

        by HeroreV ( 869368 ) on Saturday November 17, 2007 @11:31AM (#21390007) Homepage
        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:
        "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.
      • 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.

        I suspect it is the fault of slashdot user base as much as the editors. I bet a lot of users were in the firehose, saw the sensationalist title, etc, and rated it highly. The editor comes in, sees it has a sensationalist title and is now colored read, meaning users really think it is great, and posts it.

      • Re: (Score:3, Insightful)

        You are right, the wording of this article is extremely misleading.

        There was a memory leak but it was due to their code, not with the Microsoft .NET Framework. Specifically their code was creating objects that were never being garbage collected as they were still being referenced in their code, i.e. they forgot to dispose and unsubscribe from events to objects that were still active. This is a really simple mistake you'd probably find in 40% of newbie programmers C# or Java code. Yes... this sort of prob
    • by Anonymous Coward on Saturday November 17, 2007 @08:55AM (#21389121)
      It's not the garbage collector's fault. If an object is still in use, it can't be collected and destroyed. Managed memory only prevents the kind of memory leak where the programmer "loses" all references to the memory and thus never frees it. It also prevents the kind of bug where memory which is still in use is freed. Programs usually crash when that happens (either the OS terminates them due to a memory protection violation or they overwrite their own data and crash later on). That is also what would likely have happened in this case if it weren't for managed memory, because obviously the programmers mistakenly thought that these objects were no longer in use, so they would have freed them when they were still handling events.
    • Re: (Score:3, Insightful)

      by Anonymous Coward
      Sad story, but it was THEIR fault. The story title "C# Memory Leak ..." is flat out wrong.

      There is no leak in C# per se. They kept a reference to the objects, so the CLR wasn't even supposed to delete them.

      Morons shouldn't be making car software.

    • by Dr. Cody ( 554864 ) on Saturday November 17, 2007 @09:56AM (#21389379)
      A funny thing happened with during my co-op this summer:

      I was working at a coal-fired power plant which needed a new pollution control device before 2010. There, I would dig through the literature, and try to find suitable products and operating conditions for this device. Anyway, this involved a lot of meetings, conference calls, and business lunches with the suppliers in question.

      Then there was Joe.

      Joe was our Alstom sales rep: portly, humorless, slow to speak and slower to understand. He was also a devote Utahnian.

      Well, one day, we were killing time while waiting on a conference call, my supervisor left the room, and we started talking about universities. Then he dropped the bomb:

      "In my Senior year, I worked on developing perpetual motion machines."

      My supervisor then reentered the room, and we got back to work. I felt like I'd just seen a dancing frog.
    • Re: (Score:3, Interesting)

      by astrosmash ( 3561 )
      It really has nothing to do with running out of memory. Their event dispatcher needs to notify a rapidly increasing number of listeners for each event, and eventually cannot keep up. Hence, their system slows over time and eventually stops.

      A moderately experienced programmer would recognize the problem very easily by, say, noticing that a listener method is getting called 100,000 times for each event.
      • by fitten ( 521191 ) on Saturday November 17, 2007 @11:57AM (#21390189)
        There's also the issue where you need to explicitly remove your event listeners when you no longer need the object. The listener keeps a reference to the object (via the interface) so even if it goes out of scope or what-have-you, YOU may think you don't have any references to the object but it implicitly does, through the listener you handed to the system. So... if you're using event listeners, make sure you explicitly remove them in your object's destructure... or else you'll end up with a memory 'leak'.
        • by TheRaven64 ( 641858 ) on Saturday November 17, 2007 @12:02PM (#21390227) Journal
          Mod parent up, and anyone doing any AJAX coding pay attention. This is one of the easiest bugs to create in JavaScript. JS is a very powerful language with a Self-like object model which a lot of people seem to treat as a basic variant. This means that they create closures when they intend to pass function pointers and end up creating large numbers of object references (the closure itself is an object and it retains a lot of references) preventing the garbage collector from doing anything useful. This is particularly common with AJAX where closures are often used for handling asynchronous events (which would be a gorgeous coding style if the syntax were slightly less ugly).
  • by feepness ( 543479 ) on Saturday November 17, 2007 @06:27AM (#21388573) Homepage

    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.
    • by johannesg ( 664142 ) on Saturday November 17, 2007 @07:26AM (#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.
    • by _merlin ( 160982 ) on Saturday November 17, 2007 @09:16AM (#21389191) Homepage Journal
      I'm guessing you wanted me to laugh, but in a highly parallel system, going through the code line by line is often the most effective way of finding a problem. When you catch the bug on a running system, you can see the state it's got itself into. But to figure out how it could have got there, you need to read and analyse the code. People are often far too eager to jump into the debugger when critically analysing the code is often a better solution.

      It obviously doesn't work in situations like this where the bug is in the runtime and not the application.
      • by __aasmho4525 ( 13306 ) on Saturday November 17, 2007 @09:45AM (#21389305)
        just to be clear, THE BUG WAS NOT IN THE RUNTIME, not by any stretch.

        there are very clear constructs in place in the language/runtime to allow any object to unregister itself from event registrations it initiated.

        this was VERY MUCH a bug in the end-user software, not the runtime (i've written code almost IDENTICALLY to this and blew lots of time having made this same mistake).

        the only thing the runtime could do to protect the idiot developer (myself included) is automagically make all event references WEAK references, but that has plenty of undesirable side-effects too... in clr, you can do this yourself if you're so inclined... (just like in a JVM)


        • Re: (Score:3, Insightful)

          by budgenator ( 254554 )
          hopefully you programmed things so if the accelerator_actuator object hasn't heard from the speed_control object in a while it returns to an idle mode rather than bizercko autonomus vehicle peddle to the metal mode, like the Princeton guys did.
      • by FreeGamer ( 1001924 ) on Saturday November 17, 2007 @11:21AM (#21389947) Homepage

        It obviously doesn't work in situations like this where the bug is in the runtime and not the application.
        RTFA. FTFA:

        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. We added one line of code to remove the event subscription and, over the next three days, we successfully ran the car for 300 miles through the Mojave desert.
        As another poster points out, this is just an advert for a profiler, which helps people who use coding practises that they did not initially fully understand. As much as I wanted it to be a bug in the C# runtime, it's just another PEBKAC issue. The /. article introduction was wonderfully ambiguous on this point, if anything it was inflammatory ("C# memory leak"). Poor article selection if you ask me, but it's been many years since the /. editors genuinely cared about the content on this site rather than the number of hits/adclicks.
      • Re: (Score:3, Informative)

        by smallpaul ( 65919 )
        First: The bug was not in the runtime. It was a simple programming bug. Second: the bug had nothing to do with parallel processing. It was an object leak due to event handling. The fastest way to solve it would have been to print out the object graph of the program after it had started running and then again after it had "slowed down". They would have seen a particular class of object had become much more numerous over time. That's you're leaker. Memory leaks ARE often easier to track down empirically rat
  • Slashvertisement (Score:5, Informative)

    by shartte ( 1002567 ) on Saturday November 17, 2007 @06:28AM (#21388579)
    The linked "article" is just a "sponsored review" for a C# profiler...
    • Re:Slashvertisement (Score:5, Interesting)

      by JanusFury ( 452699 ) <> on Saturday November 17, 2007 @06:36AM (#21388607) Homepage Journal
      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...
    • by ( 321932 ) on Saturday November 17, 2007 @07:04AM (#21388701) Homepage Journal
      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?


      "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.
      • by spun ( 1352 ) <loverevolutionar ... m ['oo.' in gap]> on Saturday November 17, 2007 @12:14PM (#21390299) Journal
        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.
    • Re:Slashvertisement (Score:4, Informative)

      by Ronin Developer ( 67677 ) on Saturday November 17, 2007 @11:39AM (#21390077)
      It might be slashvertisement, but it also speaks a painful truth that many developers seem to forget.

      The company I worked for, in the efforts to get something out the door, deployed a product to a customer site that had a similar flaw (but, not a .Net app). Every hour or so, it would simply lock up. The solution that was proposed was a script to restart the application at a specific interval rather than track down the actual bug itself and fix it. And, like the Princeton team, they underestimated the time interval when the system was put into a real production environment and more users came online.

      In my own work, I wrote NT services that HAD to run 24x7 and were not allowed to crash - especially due to memory leaks. The components we purchased and used, contrary to their marketing ploy, often had memory and resource leaks - we won't even begin to talk about the runtime library that shipped with the compiler.

      I used a variety of freely available memory managers and commercial QA tools to track down most of the "leaks" and fixed them. If I didn't have source to the component in question, I replaced them or rewrote them from scratch taking time to make sure it didn't leak. Guess what? It worked and those applications/services run 24x7 (well, until they restart server for some other reason).

      Moral of the story - if something is critical - take the time to profile your code and use QA tools to find other potential problems BEFORE you deploy.

  • by RzUpAnmsCwrds ( 262647 ) on Saturday November 17, 2007 @06:29AM (#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: (Score:3, Interesting)

      by dgun ( 1056422 )

      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 al

      • by cnettel ( 836611 ) on Saturday November 17, 2007 @07:18AM (#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.)
      • by blowdart ( 31458 ) on Saturday November 17, 2007 @07:25AM (#21388789) Homepage

        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.

        • by multi io ( 640409 ) <> on Saturday November 17, 2007 @08:46AM (#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.
          • by Mr. Shiny And New ( 525071 ) on Saturday November 17, 2007 @11:52AM (#21390143) Homepage Journal
            You might not be able to use weak references since they introduce (at least in Java) a layer of indirection. For example, an addListener method usually takes an interface of some kind of Listener, not a WeakReference (to a listener).

            Now, if you have control of the implementation of the object who accepts Listeners you can store them internally in a weak collection, which allows them to be garbage-collected. This would work but may not be what the programmer intends. Actually in a language like Java I'd hazard that usually the programmer wouldn't want that at all: consider an application that listens to UI events. As a programmer I want to be able to stick listeners wherever they are needed and leave them there permanently. If I don't need a pointer to the object, I don't want to keep it around, and thus may not have a reference to the listener EXCEPT in the event-management collection. That's the advantage of GC languages: as soon as the object which creates those events (say, a dialog box) goes away, the objects it refers to have one fewer pointer and may be eligible for GC.

            Anyway, lots of code has issues like this: we had a problem at my work where an Apache taglib was caching some compilation in a cache that would grow for ever. It was a simple code fix to solve that problem, but there was no way for us to even SEE the problem until we ran our application under load in a profiler. Fun fun fun.
    • by MathFox ( 686808 ) on Saturday November 17, 2007 @06:52AM (#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.

    • by ( 321932 ) on Saturday November 17, 2007 @07:34AM (#21388833) Homepage Journal
      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++.
      • by porpnorber ( 851345 ) on Saturday November 17, 2007 @02:57PM (#21391345)

        I must apologise in advance if this is a bit of a rant. I have a graduate degree in, well, programming language design, and I find some things close to my field just very upsetting. You wrote:

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

        Perhaps you write very C++-adapted, boilerplate code. The reason garbage collection is essential in a programming language is that without it (a) you cannot provide a safe implementation of first-class functions, since they implicitly grant indefinite lifespan to arbitrary objects; and (b) you cannot build an abstract data type, whose implementation is hidden from the user, since no matter what other features the language may have, you can always tell whether the type a library has handed you is an automatically managed 'atomic' object, or a 'reference type.'

        But why get so upset about weird advanced programming techniques not coming out quite right?

        Because the kicker is, that to those of us who grew up with garbage collected languages, first class functions and abstract data types are elementary programming techniques. They are the bricks and mortar of which everything else is made. "Data structures + Algorithms," you see. Sure, C++ programmers consider it rocket science and discuss ad nauseum their clever smart pointer techniques and their baroque fifty-line function object implementations (or, if they advocate Boost, their two line function object implementation that requires a five thousand line header file and employs a completely different syntax from everything else they do). That's because they're now used to getting through life with no arms and artificial legs.

        The sense in which garbage collected languages make memory leaks a thing of the past is this: that if you received a non-C++-adapted education, focussed on data structures and algorithms and not the fifty-three (or five thousand and six - they make money, let's invent more) Programming Patterns that help you evade the design flaws of the One True Language, and so you are in the habit of thinking and coding using callbacks, strategy functions, abstract types, state encapsulators - all those basic things that (unless the goal is avoiding the shortcomings of C++) are taught in school, and, indeed, all those things that both functional programming and object oriented programming were invented to make notationally direct, then you can just go ahead and code what you think, and you won't be bitten on the bum. The abstract model of computation comes reasonably close to matching the reality. Without it, you're still tracing through the execution in your mind at every step, because relying on the abstraction itself will get you burned.

        Yes, a competent programmer can adapt. Yes, a competent programmer can think at the level of assembly language and either work out exactly the lifetime of the data, or do a second explicit computation, woven in with the main one, to determine it dynamically. A competent programmer can also deal with a language having divergent notations for data, expressions, statements, type expressions, templates, and type expressions within templates; or to phase of the moon dependent name resolution (templates again!); or to notational 'abstractions' requiring manual instantiation in real implementati

  • by saurik ( 37804 ) on Saturday November 17, 2007 @06:34AM (#21388597) Homepage
    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.
    • 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.
  • by Tim C ( 15259 ) on Saturday November 17, 2007 @06:35AM (#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.
    • by djinnn ( 1064652 ) on Saturday November 17, 2007 @06:56AM (#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...
      • by tgd ( 2822 ) on Saturday November 17, 2007 @08:00AM (#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.
  • by mariuszbi ( 1113049 ) on Saturday November 17, 2007 @06:36AM (#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...
    • by Jartan ( 219704 )
      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: (Score:3, Insightful)

      by Bill Dog ( 726542 )
      ...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.)
  • by mr_mischief ( 456295 ) on Saturday November 17, 2007 @06:45AM (#21388635) Journal
    This section totals 15 points.


    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.


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

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

  • c#? (Score:3, Interesting)

    by nekozid ( 1100169 ) on Saturday November 17, 2007 @06:54AM (#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#.
  • 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?

  • only 10KLOC? (Score:4, Interesting)

    by basiles ( 626992 ) <basile@starynkev[ ] ['itc' in gap]> on Saturday November 17, 2007 @06:55AM (#21388673) Homepage
    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? (Score:4, Insightful)

      by dkf ( 304284 ) <> on Saturday November 17, 2007 @09:35AM (#21389261) Homepage

      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.)
      Ah, but that 10kLOC needs to be the right 10k, and not all lines of code are the same (incrementing a variable is quite a bit simpler than calling a complex method). Plus you also don't know how many lines of code they threw away.
    • Re:only 10KLOC? (Score:5, Insightful)

      by comp.sci ( 557773 ) on Saturday November 17, 2007 @03:37PM (#21391629)
      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.)
  • by Anonymous Coward
    Just like most windows machines it bogs down and starts crashing after about 40 minutes of hard use.
  • by m2943 ( 1140797 ) on Saturday November 17, 2007 @07:39AM (#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.
    • 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

  • by Raven737 ( 1084619 ) on Saturday November 17, 2007 @07:51AM (#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.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 :)
  • Swing (Score:4, Informative)

    by Tim Ward ( 514198 ) on Saturday November 17, 2007 @08:22AM (#21388997) Homepage
    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.
  • by Ihlosi ( 895663 ) on Saturday November 17, 2007 @08:26AM (#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.

  • by Jugalator ( 259273 ) on Saturday November 17, 2007 @10:32AM (#21389585) Journal
    Just read the CodeProject article to see why:
    - "so it wasn't a memory leak per se"
    - "It was the closest thing to a memory leak that you can have in a "managed" language. "
    - "Unfortunately, our system was seeing and cataloging every bit of tumbleweed and scrub that it could find along the side of the road."

    So they just goofed up.

    The objects didn't get deleted in time, because there were always ( literally ;-) )junk near them in the game, hence not getting garbage collected due to their object detection algorithm.

    Bad Slashdot. Bad Slashdot.
  • Wow, how embarassing (Score:3, Interesting)

    by TummyX ( 84871 ) on Saturday November 17, 2007 @10:43AM (#21389653)
    If I was one of the team members, I wouldn't want my photo up there next to an article that documents my mediocre programming skills.

    Criticisms of the team aside, I would like to say that neither Java nor C# have made any steps to remedy problems like this with seem to be all too common with inexperienced developers. Both Java and C# need to support attaching to event handles with "weak" handlers. That is, the handler will not hold onto the object which defines the handler (and will automatically deregister itself sometime after the object has been collected). In many cases, there is a need for an object to listen and handle an event from another object, but only whilst the object that is listening is still referenced (with the exception of the reference held by the object firing the event).

    In C#, the (admittedly ugly) way to implement this is to use an anonymous method and a weak reference:

    // Need a weak reference to the current object (we want it collected)
    WeakReference weakRef = new WeakReference(this);
    // Need a local (not field) reference to object that raises the event
    SomeClass someObject = this.SomeObject;
    EventHandler eventHandler = null;
    eventHandler = delegate
      ThisClass _this = (ThisClass)weakRef.Target;
      if (_this == null)
          someObject.SomeEvent -= eventHandler;
    someObject.SomeEvent += eventHandler;
    The "closure" that is created for the anonymous method does not hold a reference to "this" as it does not access any of "this"'s fields or methods unless it's through the weakreference.

    The code has a flaw where the event handler code (only a few bytes to hold the closure) will never deregistered be collected unless the event is fired sometime after the owner object has been collected. This can be fixed by using a NotifyingWeakReference (a weak reference that raises an event when it has been collected).

  • by simonech ( 229668 ) on Saturday November 17, 2007 @12:11PM (#21390281) Homepage
    I usually like /. articles, even the ones against MS, but I cannot just skip over this one:
    if the moderator read the article he would have noticed that the article was an advertisement for the profiler product, not just a review of it (it was written directly by Red Gate).
    Second, the article itself says that they found that the error was in how they coded the application, because they left some reference so the garbage collector didn't trow away the objects.
    This is a really bad article and bad information.
  • by Animats ( 122034 ) on Saturday November 17, 2007 @02:24PM (#21391131) Homepage

    There's actually an accepted safe way to do memory management - reference counts and weak references. That's what both Perl and Python have settled on, and it's worth noting that programmers in those languages seldom have serious memory management problems. In C and C++, one has to obsess on memory management issues, and even in Java and C#, which are garbage collected, it takes more attention than it should.

    Reference counts have the advantage of repeatability - deletion will occur at predictable times. This allows the use of destructors. You can safely use destructors to manage other assets, like windows, open files, network connections, and such.

    Destructors in systems with garbage collection make for an unhappy marriage. Calling a destructor or finalizer from the garbage collector is essentially equivalent to calling it at some random time from another thread. So race conditions are possible. Check out Microsoft's "managed C++" for an attempt to get all the cases for this right. It's not pretty.

    The classic complaint about reference counts is "what about cycles"? There's a simple answer - cycles, that is, loops of strong pointers, are errors. This isn't a severe restriction; it just requires some data structure design. With trees, for example, links towards the leaves are strong pointers, and links towards the root are weak. (I've revised Python's BeautifulSoup HTML parser to work that way; "down" and "forward" links are strong, while "up" and "backwards" links are weak. It took about 20 lines of code and eliminated annoying problems in programs dealing with HTML trees.)

    If you really need a symmetrical circular list, which might happen in, say, a window library with many links between widgets, there's a simple solution. Have all the objects owned by some collection, then use weak pointers between them. When the collection is dropped, all the bits and pieces go away, in a well defined order.

    In Python, you can turn off garbage collection while leaving reference counting active, then list any orphaned cycles at program end for debugging purposes. This is a practical way to program without leaks or garbage collection. It's generally easy to find cycles, because cycles are created by data structure design, not by bugs. So if a program has cycles, it will probably have them every time, and thus they can be found early in debugging. With better language support for debugging, cycles could be caught at the moment of creation, which would make it easy to eliminate them.

    Now if we could get this into a hard-compiled language, we'd have the problem solved. Repeated attempts to bolt reference counting onto C++ via templates have resulted in fragile systems. The fundamental problem is that C++ still requires access to raw pointers to get anything done, and this puts a hole in the protection provided by the reference counting system. It takes language support to make this work right.

  • by Brett Buck ( 811747 ) on Saturday November 17, 2007 @04:39PM (#21392061)
    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.


Forty two.