Who's afraid of memory leaks?
-
Do you think it is strange that people are so afraid of memory leaks? They go so far to introduce garbage collectors X| and similar performance killers. Memory leaks can be bad, but I had much more problems with other kinds of bugs - especially when it comes to multithreading. Multiple threads can introduce subtle and hard to find bugs, and require far more time and effort to debug. How do you feel about this? I vote pro drink X|
-
Do you think it is strange that people are so afraid of memory leaks? They go so far to introduce garbage collectors X| and similar performance killers. Memory leaks can be bad, but I had much more problems with other kinds of bugs - especially when it comes to multithreading. Multiple threads can introduce subtle and hard to find bugs, and require far more time and effort to debug. How do you feel about this? I vote pro drink X|
if your app has to run 24/7, memory leaks are a serious issue. plus, memory leaks are often indicative of some other problem. it pays to fix them. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
-
Do you think it is strange that people are so afraid of memory leaks? They go so far to introduce garbage collectors X| and similar performance killers. Memory leaks can be bad, but I had much more problems with other kinds of bugs - especially when it comes to multithreading. Multiple threads can introduce subtle and hard to find bugs, and require far more time and effort to debug. How do you feel about this? I vote pro drink X|
Memory leaks are bad, very very bad. First, it shows sloppy programming. Second, for applications that have to run 24/7, even a tiny memory leak can cause a program to crash. Heck, with 24/7 programs, your program can consume all available process space even though you don't have any memory leaks. I have had to rewrite some software when the address space had become so badly fragmented that it ran out of address space. Tim Smith Descartes Systems Sciences, Inc.
-
if your app has to run 24/7, memory leaks are a serious issue. plus, memory leaks are often indicative of some other problem. it pays to fix them. -c ------------------------------ Smaller Animals Software, Inc. http://www.smalleranimals.com
I agree they are bad. I just think that they can be located and fixed easier than some other bugs (like thread synch bugs). I vote pro drink X|
-
Do you think it is strange that people are so afraid of memory leaks? They go so far to introduce garbage collectors X| and similar performance killers. Memory leaks can be bad, but I had much more problems with other kinds of bugs - especially when it comes to multithreading. Multiple threads can introduce subtle and hard to find bugs, and require far more time and effort to debug. How do you feel about this? I vote pro drink X|
Memory leaks and related problems such as memory corruption are responsible for a large amount of the consultancy work I do. People hire me to fix memory leak problems their own staff can't fix, or don't have the time to fix. For example, people using CAD systems are often willing to wait over an hour for extremely large models to load into memory. Personally I wouldn't wait that long, but that isn't the point, I've heard about such people from support staff. When they do this, they may schedule the document to load an hour before they arrive at work, intending to work all day modifying the document, before saving when they leave the office. The last thing they want to is to run out of memory part way through the day, spend an hour saving and then another hour reloading the document. It doesn't have to be 24/7 apps that are critical. The above example is real and I found out about whilst beta testing a related product. Also, consider this, when your application uses more virtual memory than physical memory, the operating system must page data out and page data in from disk each time your application references memory that is not in physical storage. This is a serious performance killer. Garbage collected programs always perform badly in such scenarios. Programs with bad memory leaks usually end up in this scenario. If you get to this stage, tuning your algorithms won't help one bit, you need to address the memory usage. If memory leaks are the reason for the memory usage, you need to address the memory leaks. Multi-threaded bugs are just as important, possibly more important if your application consumes very little memory and runs for short time durations. Its like comparing apples and oranges, rather than comparing Granny Smiths with Golden Delicious - Granny Smith every time! Cheers Stephen Stephen Kellett -- C++/Java/Win NT/Unix variants Memory leaks/corruptions/performance/system problems. UK based. Problems with RSI/WRULD? Contact me for advice.
-
Do you think it is strange that people are so afraid of memory leaks? They go so far to introduce garbage collectors X| and similar performance killers. Memory leaks can be bad, but I had much more problems with other kinds of bugs - especially when it comes to multithreading. Multiple threads can introduce subtle and hard to find bugs, and require far more time and effort to debug. How do you feel about this? I vote pro drink X|
Now, have you guys even read my post? .:mad: I don't claim that memory leaks are good, or that they should be left in the code. All that I claim is that it is often easier to fix memory leaks than bugs related to multiple thread synchronization (BTW, I dealt with both kinds of bugs). I vote pro drink X|
-
Now, have you guys even read my post? .:mad: I don't claim that memory leaks are good, or that they should be left in the code. All that I claim is that it is often easier to fix memory leaks than bugs related to multiple thread synchronization (BTW, I dealt with both kinds of bugs). I vote pro drink X|
I have it the other way around. I think it's easier to fix thread releated bugs. (Maybe I have just been lucky ;)) - Anders Money talks, but all mine ever says is "Goodbye!"
-
Now, have you guys even read my post? .:mad: I don't claim that memory leaks are good, or that they should be left in the code. All that I claim is that it is often easier to fix memory leaks than bugs related to multiple thread synchronization (BTW, I dealt with both kinds of bugs). I vote pro drink X|
I agree with you in that it is reasonable simple to stay away from memory leaks as compared with the sort of problems introduced by even the most simple multithreaded program. IMHO, lack of multithreading support (apart from tiny wrappers around the system multithreading primitives) stems from the fact that we do not have yet any sound theoretical foundation upon which to base the design of multitherading issues. Compare the number and popularity of garbage collection, creation, and behavioral design patterns with those devoted to multithreading design. When it comes to managing threads, one is pretty much on his/her own and usually relies on some rules of thumb, common sense and a lot of spaghetti tracing. PS: Douglas Schmid has documented a nice collection of design paterns for concurrent programming that you might find interesting to look at. He also put them together in a book. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
I agree with you in that it is reasonable simple to stay away from memory leaks as compared with the sort of problems introduced by even the most simple multithreaded program. IMHO, lack of multithreading support (apart from tiny wrappers around the system multithreading primitives) stems from the fact that we do not have yet any sound theoretical foundation upon which to base the design of multitherading issues. Compare the number and popularity of garbage collection, creation, and behavioral design patterns with those devoted to multithreading design. When it comes to managing threads, one is pretty much on his/her own and usually relies on some rules of thumb, common sense and a lot of spaghetti tracing. PS: Douglas Schmid has documented a nice collection of design paterns for concurrent programming that you might find interesting to look at. He also put them together in a book. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
The link you posted is great :cool: ! Thanks a lot. :) :) I vote pro drink X|
-
I agree with you in that it is reasonable simple to stay away from memory leaks as compared with the sort of problems introduced by even the most simple multithreaded program. IMHO, lack of multithreading support (apart from tiny wrappers around the system multithreading primitives) stems from the fact that we do not have yet any sound theoretical foundation upon which to base the design of multitherading issues. Compare the number and popularity of garbage collection, creation, and behavioral design patterns with those devoted to multithreading design. When it comes to managing threads, one is pretty much on his/her own and usually relies on some rules of thumb, common sense and a lot of spaghetti tracing. PS: Douglas Schmid has documented a nice collection of design paterns for concurrent programming that you might find interesting to look at. He also put them together in a book. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Now, have you guys even read my post? .:mad: I don't claim that memory leaks are good, or that they should be left in the code. All that I claim is that it is often easier to fix memory leaks than bugs related to multiple thread synchronization (BTW, I dealt with both kinds of bugs). I vote pro drink X|
-
Do you think it is strange that people are so afraid of memory leaks? They go so far to introduce garbage collectors X| and similar performance killers. Memory leaks can be bad, but I had much more problems with other kinds of bugs - especially when it comes to multithreading. Multiple threads can introduce subtle and hard to find bugs, and require far more time and effort to debug. How do you feel about this? I vote pro drink X|